Почему запросы могут быть разными и уходить с разными параметрами?
Что проверяют
Смотрите ли вы во вкладку сети, когда тестируете, и понимаете ли, что одно и то же действие в интерфейсе не обязано порождать одинаковый запрос. Проверяют умение объяснить разницу, а не просто её заметить.
Как отвечать
Перечислите причины, по которым внешне одинаковые сценарии дают разные запросы:
- состояние клиента: сохранённые фильтры, сортировка, размер страницы, ранее выбранная валюта или язык подмешиваются в параметры;
- версия и платформа: веб и мобильное приложение ходят в разные версии эндпойнта, старый клиент шлёт устаревший набор полей;
- эксперименты и фича-флаги: часть пользователей попадает в другую ветку, запрос уходит по другому адресу или с лишним параметром;
- авторизация: роль и права влияют и на состав параметров, и на ответ;
- окружение и время: часовой пояс, формат даты, идентификатор трассировки, ключ идемпотентности генерируются на клиенте и меняются от запуска к запуску;
- кэш и повторы: условные заголовки, повторная отправка после таймаута.
Для тестирования вывод простой: параметры делятся на значимые, влияющие на ответ, и служебные. Сравнивать запуски надо по значимым, а проверки строить на границах: отсутствующий параметр, пустое значение, лишний параметр, неверный тип, превышение лимита. Отдельно проверяется, что сервер не доверяет клиентским параметрам вроде идентификатора пользователя.
Где спотыкаются
Заводят баг с формулировкой «запросы разные», не сверив, что именно различается. Такой отчёт вернут: трассировка и время отличаются в каждом запуске по определению.
Второе: фиксируют в автотестах тело запроса целиком. Такой тест краснеет от добавления безобидного поля, поэтому сверяют нужные поля, а не байты.
Третье: путают отсутствующий параметр с пустым. На сервере это разные ветки: пропуск обычно означает значение по умолчанию, а пустая строка это явно переданное значение, и проверять надо обе.