С какими протоколами передачи данных вы работали
Что проверяют
Не список аббревиатур, а умеете ли вы смотреть под интерфейс. Тестировщик, который видит только экран, пропускает половину дефектов, поэтому спрашивают, чем вы ловите трафик, что проверяете в ответе и как проверяете то, что поверх HTTP не ходит.
Как отвечать
Называйте только то, что правда трогали, и сразу говорите, как проверяли:
- HTTP и HTTPS. Коды ответов, заголовки, кэширование, идемпотентность методов. Инструменты:
curl, коллекции запросов, перехватывающий прокси, автотесты. Интересны негативные проверки: битое тело, неверный тип содержимого, отсутствующее обязательное поле, чужой токен, слишком большой запрос; - WebSocket. Порядок сообщений, поведение при обрыве, переподключение, дубли после восстановления связи;
- gRPC. Свой набор кодов статуса, схема обязательна, проверяется сгенерированным клиентом;
- очереди сообщений. Тут проверяется не факт доставки, а повторная доставка и порядок: обычно гарантируется доставка не менее одного раза, значит потребитель обязан переваривать дубли;
- файловый обмен. Кодировки, недописанный файл, повторная выкладка того же имени.
Отдельно скажите про уровень ниже: сброшенное соединение и истёкший таймаут в логах приложения выглядят одинаково невнятно, а в перехваченном трафике видно, кто именно закрыл соединение.
Где спотыкаются
Перечисляют протоколы, но не могут назвать ни одной проверки. Ответ становится содержательным только вместе с тест-кейсом: что подали на вход и какой ответ считаете верным.
Второе: путают уровни. Ставят в один ряд REST, HTTP и TCP, хотя первое это стиль построения API, второе протокол прикладного уровня, а третье транспорт.
Третье: проверяют только счастливый путь на стабильной сети. Обрывы, повторы и таймауты дают самые дорогие дефекты, и воспроизводить их надо намеренно, а не ждать случая.