Тестировщик, который умеет открыть DevTools и сказать «баг на бэкенде, вот запрос и ответ», ценится заметно выше того, кто пишет «не работает». Этот модуль про то, как устроено веб-приложение и как локализовать дефект.
Клиент-серверная архитектура
Клиент (браузер, мобильное приложение) отправляет запросы, сервер их обрабатывает, работает с базой и возвращает ответ. Типичный путь запроса:
- Обработчик клика на фронтенде формирует запрос.
- Браузер отправляет HTTP-запрос к API.
- Сервер проверяет токен и права.
- Сервер получает данные из базы.
- Сервер возвращает код ответа и JSON.
- Фронтенд обрабатывает ответ и рисует экран.
Дефект может сидеть на любом шаге. Задача тестировщика найти, на каком.
HTTP за минуту
Запрос: метод, URL, заголовки, тело. Ответ: код статуса, заголовки, тело.
Методы: GET читает, POST создаёт, PUT заменяет, PATCH частично меняет, DELETE удаляет. GET, PUT и DELETE идемпотентны: повтор даёт тот же эффект. POST нет: повтор после обрыва сети может создать второй заказ.
Коды:
| Класс | Смысл | Примеры |
|---|---|---|
| 2xx | Успех | 200 OK, 201 Created, 204 No Content |
| 3xx | Перенаправление, кеш | 301, 302, 304 Not Modified |
| 4xx | Ошибка клиента | 400, 401, 403, 404, 409, 422, 429 |
| 5xx | Ошибка сервера | 500, 502, 503, 504 |
- 401: не аутентифицирован (нет или истёк токен). 403: аутентифицирован, но прав нет.
- 500 на невалидный ввод это дефект: сервер должен был ответить 400 или 422 с понятной ошибкой.
- 200 с текстом ошибки в теле тоже плохо: ломает клиентов и мониторинг.
Как понять, чей баг
Нет запроса в Network → фронт (смотри Console)
Запрос ушёл с неверными параметрами → фронт
Ответ 5xx или неверные данные в ответе → бэкенд или данные
Ответ верный, на экране неверно → фронт
401/403 там, где не ждали → авторизация, токены, права
Для уверенности повтори запрос в обход интерфейса: Copy as cURL или Postman. Если ответ тот же, проблема на сервере.
DevTools: что где
- Network: все запросы, коды, заголовки, тела, тайминги.
- Preserve log: не очищать журнал при переходе (нужно при редиректах после входа).
- Disable cache: отключить кеш при открытых DevTools. Первое, что делать, если «исправили, а у меня по-старому».
- Throttling: медленная сеть или Offline.
- Copy as cURL: повторить запрос в терминале или Postman, приложить к багу.
- Экспорт HAR: журнал всех запросов. Содержит куки и токены, вычищай перед отправкой.
- Console: ошибки JavaScript, предупреждения, ошибки CORS.
- Application (в Firefox Storage): куки с флагами, localStorage, sessionStorage, IndexedDB, Service Worker, очистка данных сайта.
- Elements: DOM и стили, можно поправить на лету и показать разработчику.
- Sources: код и точки останова.
- Lighthouse: быстрый аудит скорости, доступности, SEO.
CORS
Если в консоли «blocked by CORS policy», браузер не дал странице прочитать ответ, потому что сервер не разрешил этот источник заголовками вроде Access-Control-Allow-Origin. Чинится на сервере или прокси. Расширение, отключающее CORS, прячет дефект, а не исправляет.
Кеширование
Браузер, прокси и CDN кешируют ответы. Отсюда два класса багов:
- старая версия стилей или скриптов после выкатки (проверь Disable cache и версию сборки);
- чужие данные: персональный ответ закешировал общий кеш. Ответы с личными данными должны идти с
Cache-Control: privateилиno-store. Такой баг плавающий и очень опасный.
Частые ошибки
- Писать «не работает», не открыв Network и Console.
- Путать 401 и 403.
- Считать 500 на кривой ввод нормой.
- Переоткрывать баг, не проверив кеш и версию сборки.
Что спросят на собесе
- Что происходит после нажатия кнопки до появления данных на экране?
- Как понять, баг на фронте или на бэке?
- Чем 401 отличается от 403? Что значит 500, 502, 503?
- Какие вкладки DevTools используешь и зачем?
- Какие методы HTTP идемпотентны?