Проверить отправку данных в базу данных через DevTools
Условие
Вы тестируете веб-приложение. После заполнения формы нужно проверить, что данные были успешно отправлены в базу данных.
У вас нет прямого доступа к бэкенду или базе данных.
Опишите:
- Как проверить отправку данных через DevTools (вкладка Network)?
- Какую информацию вы будете искать в запросе?
- Как интерпретировать коды ответа сервера?
- Какие альтернативные способы проверки существуют?
Комментарии (1)
Ответ сгенерирован нейросетью и может содержать ошибки
Проверка отправки данных в БД через DevTools
1. Как проверить отправку данных через DevTools (вкладка Network)
Шаг 1: Открытие DevTools
- Откройте браузер (Chrome, Firefox, Edge)
- Нажмите F12 или Ctrl+Shift+I (Cmd+Option+I на Mac)
- Перейдите на вкладку Network
- Убедитесь, что запись активна (красная кнопка запуска)
Шаг 2: Заполнение формы и отправка
- В окне браузера заполните форму данными:
- Например, регистрация: Name, Email, Password
- Нажмите кнопку "Submit" или "Отправить"
- В Network панели вы увидите список всех HTTP запросов
Шаг 3: Поиск нужного запроса
-
Отфильтруйте по типу запроса:
- Выберите XHR (XMLHttpRequest) или Fetch для современных приложений
- Это исключит изображения, стили, скрипты
-
Найдите запрос, отправляющий данные формы:
- Обычно имеет название:
submit,api/register,login,/users,/form-data - Метод: POST (редко PUT или PATCH)
- Обычно имеет название:
Шаг 4: Анализ запроса
В панели Network нажмите на запрос, вы увидите:
- General — общая информация (URL, метод, IP адрес сервера)
- Request Headers — заголовки запроса
- Request Body — отправленные данные (ВАЖНО!)
- Response — ответ от сервера
- Response Headers — заголовки ответа
- Timing — время выполнения
2. Какую информацию вы будете искать в запросе?
A. В Request Body (самое важное)
Что смотреть:
{
"name": "Иван Петров",
"email": "ivan@example.com",
"password": "hash_or_plain",
"phone": "+7-900-123-45-67"
}
Проверки:
| Проверка | Что ищем | Хорошо / Плохо |
|---|---|---|
| Данные в запросе | Все поля формы присутствуют | ✓ Если данные совпадают с тем, что ввели |
| Формат данных | JSON, Form-Data или другой | ✓ Зависит от требований API |
| Кодировка пароля | Пароль отправляется в открытом виде? | ✗ КРИТИЧНО: должен быть в HTTPS и не в логах |
| Чувствительные данные | Сокрыты ли карточка, СНП? | ✓ Не должны видны в Network |
| ID пользователя | Добавляется ли в теле запроса? | ? Зависит от дизайна API |
B. В Request Headers
Обратите внимание:
| Заголовок | Что проверяем | Норма |
|---|---|---|
| Content-Type | Тип отправляемых данных | application/json или application/x-www-form-urlencoded |
| Authorization | Токен доступа (если требуется) | Bearer token или Session ID |
| X-CSRF-Token | CSRF защита | Если не используется SameSite=Strict |
| Origin / Referer | Откуда пришел запрос | Должен соответствовать вашему домену |
| User-Agent | Информация о браузере | Стандартный User-Agent |
C. Размер и скорость запроса
- Request Size: должен быть разумного размера (не 10+ MB)
- Time: от 100ms до 5000ms в зависимости от сложности операции
3. Как интерпретировать коды ответа сервера?
Успешные коды (2xx)
| Код | Название | Значение | Что проверить |
|---|---|---|---|
| 200 | OK | Запрос успешен, данные обработаны | Response содержит подтверждение (ID пользователя, сообщение успеха) |
| 201 | Created | Ресурс создан (новый пользователь, новая запись) | Response содержит созданный объект с ID |
| 202 | Accepted | Запрос принят, обрабатывается асинхронно | Возвращается ID задачи для проверки статуса позже |
| 204 | No Content | Успех, но нет тела ответа | Это нормально (например, для DELETE) |
Проверка при 200/201:
-
Response Body: содержит ли подтверждение?
{ "success": true, "user_id": "12345", "message": "User created successfully" } -
Повторная загрузка страницы: исчезла ли форма? Появилось ли сообщение спасибо?
-
Проверка базы: если есть доступ, убедитесь, что пользователь добавлен
Ошибки клиента (4xx)
| Код | Название | Что произошло | Что проверить |
|---|---|---|---|
| 400 | Bad Request | Неверный формат данных | Response содержит сообщение об ошибке, какое поле неверно |
| 401 | Unauthorized | Не авторизован (нет токена) | Требуется логин перед отправкой |
| 403 | Forbidden | Доступ запрещен | Пользователь не имеет прав на эту операцию |
| 404 | Not Found | Endpoint не существует | Проверить URL в запросе |
| 409 | Conflict | Конфликт данных (например, email уже существует) | Зачастую это нормально (дублирование) |
| 422 | Unprocessable Entity | Валидация не прошла | Response показывает какие поля неверны |
| 429 | Too Many Requests | Rate limiting (слишком много запросов) | Подождите и попробуйте снова |
Пример ошибки:
{
"error": "Email already exists",
"field": "email",
"code": 409
}
Ошибки сервера (5xx) — КРИТИЧНЫ
| Код | Название | Проблема |
|---|---|---|
| 500 | Internal Server Error | Ошибка на сервере, логируйте в баг-трекер |
| 502 | Bad Gateway | Сервер недоступен или зависает |
| 503 | Service Unavailable | Сервис на обслуживании |
| 504 | Gateway Timeout | Запрос занял слишком много времени |
Действие: Это баги, требуют инвестигации разработчиков.
4. Альтернативные способы проверки
Способ 1: Проверка Response (если возвращается ID)
В Network → выберите запрос → вкладка Response
Ищите:
"id": "12345"— пользователь создан"success": true— операция завершена"data": {...}— возвращены сохраненные данные
Проверка: Скопируйте ID, перейдите на профиль /users/12345, проверьте данные.
Способ 2: Проверка через Local Storage / Session Storage
DevTools → Application (или Storage) → Local Storage → ваш домен
Что ищем:
user_id,token,user_data— система сохранила данные локально- Если здесь есть ID, значит фронт получил ответ от сервера
Способ 3: Проверка Cookies
DevTools → Application → Cookies → ваш домен
Проверьте:
session_idилиauth_token— появилась ли новая куки?HttpOnlyфлаг — защищена ли от XSS?Secureфлаг — отправляется ли только через HTTPS?
Способ 4: Проверка Console (вкладка Console)
Если приложение выводит логи:
console.log('User created:', userData);
В консоли можете увидеть объект с данными пользователя.
Способ 5: API запрос в терминале (curl)
Если знаете API endpoint:
curl -X GET https://api.example.com/users/12345 \\
-H "Authorization: Bearer YOUR_TOKEN"
Результат: JSON с данными пользователя подтверждает, что данные в БД.
Способ 6: Повторная загрузка страницы
- Заполните форму
- Отправьте
- Перезагрузите страницу (F5)
- Проверьте:
- Если данные все еще там → они сохранены в БД
- Если исчезли → возможно, ошибка
Способ 7: Проверка email / SMS (если применимо)
Для форм регистрации:
- Проверьте почту на письмо подтверждения
- Проверьте SMS на код активации
- Если пришло → данные точно в БД
Матрица проверок
| Что проверяем | Метод | Результат успеха | Результат ошибки |
|---|---|---|---|
| Запрос отправлен | Network tab | Статус 2xx или 3xx | Статус 4xx/5xx |
| Данные в запросе | Request Body | Совпадают с формой | Отличаются или пусты |
| Ответ содержит ID | Response Body | Есть user_id или record_id | Пусто или ошибка |
| Сессия создана | Cookies/LocalStorage | Появился auth_token | Ничего не создано |
| Данные в БД | GET запрос по ID | Возвращаются данные | 404 Not Found |
| Видимость на фронте | Обновление UI | Форма скрыта, появилось спасибо | Форма остается |
Частые ошибки и как их выявить
| Ошибка | Симптом в Network | Как найти | Решение |
|---|---|---|---|
| Запрос не отправляется | Нет POST в Network | Очистить Network, повторить | Проверить JS консоль на ошибки |
| Статус 200, но данные не сохранены | Response 200, нет ID | GET /users/{id} → 404 | Баг на бэке, нужна инвестигация |
| CORS ошибка | Статус 0 или 'preflight' запрос | Network → увидите OPTIONS запрос перед POST | Проверить CORS заголовки на сервере |
| HTTPS не используется | Видно пароли в Network | Plaintext в Request Body | ТРЕБУЕТСЯ HTTPS, серьезный баг |
| Timeout | Статус 0, время > 60 сек | Timing tab | Сервер медленный или на обслуживании |
Итоговый чек-лист для QA Engineer
- Запрос отправлен (есть в Network)
- Метод правильный (POST для создания)
- Статус код 200-201 (успешно)
- Response содержит ID или подтверждение
- Данные совпадают с тем, что ввели
- Пароль/чувствительные данные защищены
- Проверена база данных (если доступ есть)
- Email подтверждение пришло (если требуется)
- Повторная загрузка страницы показывает сохраненные данные