Как автоматизировать проверку большого количества запросов на ответ 200

Что проверяют

Умеете ли вы превратить рутинную проверку в воспроизводимый автотест и понимаете ли, что статус 200 ещё не значит «работает». Следом обычно спрашивают, что делать, если 200 пришёл с ошибкой в теле, и как не положить стенд.

Как отвечать

Сначала уточните масштаб: пятьдесят эндпоинтов API или десять тысяч адресов из sitemap. От этого зависит инструмент.

• данные отдельно от кода: список запросов лежит в CSV или JSON либо собирается из OpenAPI-спецификации, тест только читает его;
• параметризация: каждый запрос становится отдельным тест-кейсом. В Python это pytest с @pytest.mark.parametrize и requests или httpx, в Java JUnit 5 с @ParameterizedTest, @CsvFileSource и RestAssured, в Postman коллекция с файлом данных через newman run collection.json -d data.csv;
• параллельность с ограничением: для тысяч адресов httpx.AsyncClient и asyncio.Semaphore, чтобы одновременно шло, скажем, 20 запросов, или k6 с check() по статусу;
• таймауты: у requests таймаута по умолчанию нет, запрос может висеть бесконечно, поэтому timeout задаётся явно;
• запуск и отчёт: тесты уходят в CI по расписанию или после деплоя, результат в JUnit XML или Allure, упавшие адреса видны списком.

Проверять стоит не только код ответа. Минимум: статус, Content-Type, время ответа и один ключевой признак в теле, например поле id в JSON или заголовок страницы.

Где спотыкаются

Пишут один тест с циклом внутри. Он падает на первом плохом адресе, остальные не проверяются, а в отчёте одна красная строка без подробностей.

Доверяют статусу. Сервер может вернуть 200 со страницей ошибки или с {"error": ...} в теле, а requests по умолчанию проходит редиректы, и 302 на страницу логина превращается в 200. Для таких проверок нужен allow_redirects=False или сравнение итогового адреса.

Запускают тысячи запросов разом на прод. Итог: ответы 429, блокировка на WAF, а смоук превращается в нагрузочный тест, о котором никто не договаривался.