Какие инструменты используются для тестирования бэка и логирования

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

Умеете ли вы тестировать бэкенд без интерфейса и находить причину ошибки в логах, а не только фиксировать симптом. Следом обычно спрашивают, как вы найдёте в логах конкретный упавший запрос и как ваши API-проверки попадают в CI.

Как отвечать

Разделите ответ на две части. Тестирование API и сервисов:

• Postman и Newman: ручная проверка и коллекции с тестами на pm.test, в CI коллекция запускается через Newman. Если запросы нужно хранить в репозитории, подойдут Bruno или Insomnia;
• автотесты в коде: pytest с requests или httpx, REST Assured для Java, SuperTest для Node. Проверяется не только статус, но и схема ответа, например через JSON Schema или pydantic;
• окружение: Testcontainers поднимает настоящую базу или брокер в Docker на время теста, WireMock подменяет внешние сервисы;
• контракты и нагрузка: Pact для контрактов между сервисами, k6, JMeter или Locust для нагрузки;
• база и очереди: SQL-запросы для проверки записанных данных, клиенты Kafka или RabbitMQ для сообщений.

Логи:

• где читать: Kibana поверх Elasticsearch, OpenSearch Dashboards, Grafana Loki с запросами LogQL, Graylog. На стенде без агрегатора хватает kubectl logs или docker logs;
• ошибки: Sentry группирует исключения со стектрейсом и контекстом запроса;
• связка: каждый запрос несёт идентификатор (X-Request-ID или trace id из заголовка traceparent), по нему находятся все строки лога и спаны в трассировке.

Хороший баг-репорт по бэкенду содержит запрос, ответ, время и этот идентификатор.

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

Называют Selenium инструментом для API. Он управляет браузером, к тестированию API отношения не имеет.

Путают библиотеку логирования с системой сбора логов. Log4j или Winston пишут строки, а искать их вы будете в Kibana или Loki, и тестировщику важнее второе.

Проверяют только код 200. Бэкенд может ответить успехом и записать в базу не то, поэтому проверка побочных эффектов обязательна.