Тестирование Web и API

Почти любой продукт — это клиент и сервер, которые обмениваются сообщениями по протоколу HTTP. Пока UI ещё не собран, API уже можно дёргать напрямую — слать запрос и читать структурированный ответ. Тестировщик, который умеет это делать, находит баги раньше, покрывает негативные и граничные случаи, которые через интерфейс не воспроизвести, и точно говорит, где сломалось — на бэкенде или в UI.

Тема собирает базовый словарь этого слоя — методы и статус-коды HTTP, идемпотентность, форматы JSON и XML, разницу подходов REST и SOAP, заголовки, аутентификацию и инструменты вроде Postman. Ловушки называем сразу — путают код 401 (не аутентифицирован) с 403 (нет прав), считают POST идемпотентным, называют REST протоколом и переворачивают, кто именно шифрует трафик — HTTP или HTTPS. Полная карта — в слоях ниже.

Карта темы

• Что такое API — контракт для обмена данными без экрана и зачем тестировать его отдельно от UI.
• Клиент-серверная архитектура — роли запроса и ответа и что вообще может быть клиентом.
• Методы HTTP — GET/POST/PUT/DELETE/PATCH и их отображение на CRUD.
• GET против POST — параметры в URL против тела, кэширование и видимость в логах.
• Идемпотентные методы — почему повтор запроса безопасен и какие методы это гарантируют.
• Статус-коды HTTP — диапазоны 1xx–5xx и кто виноват по первой цифре.
• Код 401 — неверные учётные данные — 401 против 403 и когда правильнее 400.
• Заголовки запроса — как сервер узнаёт устройство, ОС и язык клиента.
• HTTP против HTTPS — что добавляет TLS и почему структура сообщения не меняется.
• Типы и синтаксис JSON — шесть типов значений и жёсткие правила формата.
• Ошибки синтаксиса JSON — как отличать нарушение синтаксиса от подозрительного значения.
• XML против JSON — вес, схемы, пространства имён и где какой формат уместен.
• REST против SOAP — архитектурный стиль против строгого протокола.
• Проектирование REST API — ресурсы-существительные, глаголы-методы и верные статус-коды.
• Контракт WSDL — машиночитаемое описание SOAP-сервиса в XML.
• Переменные в Postman — переиспользование значений и правило «уже — побеждает».
• Семантика доставки в Kafka — откуда берутся дубли и как их гасят дедупликацией.

Частые ошибки и ловушки

Значение для собеседований

Web/API-блок — любимая проверка на джуна и мидла в тестировании. Интервьюер смотрит не на заучивание кодов, а на то, отличаете ли вы контракт от реализации — метод от эффекта, статус от тела, стиль от протокола. Кандидат, который на «неверный логин» уверенно отвечает 401 и объясняет разницу с 403, сразу опережает того, кто «вернул бы 200 с ошибкой в теле».

Что обычно проверяют:

• Роли клиента и сервера, что клиентом может быть не только браузер.
• Методы HTTP и их отображение на CRUD, разницу GET/POST, идемпотентность.
• Диапазоны статус-кодов и точный код для неверных учётных данных.
• Форматы JSON/XML, правила синтаксиса, разницу REST и SOAP, назначение WSDL.
• Умение прочитать сырой запрос/ответ в Postman или DevTools и найти баг в теле или заголовках.

Типичный неверный ответ: «REST — это протокол, а POST идемпотентен, потому что у него есть тело». На деле REST — архитектурный стиль поверх обычного HTTP, а идемпотентность — про итоговое состояние сервера, а не про наличие тела; POST не идемпотентен именно потому, что каждый вызов создаёт новый ресурс.