Тестирование веб-сокетов: опыт QA-инженера Creative

Всем привет! Меня зовут Дархан, я QA-инженер компании Creative. Сегодня хочу поднять тему протоколов связи, и как тестировщик может увидеть их в действии. Подробно разберём примеры тестирования, разложим по полочкам базу. Статья будет полезна всем, кто хочет разобраться в теме. В конце материала буду рад ответить на ваши вопросы! Итак, погнали.

WebSocket — это протокол связи, система правил, которые позволяют двум или более устройствам обмениваться информацией и данными.

Хорошо известные интернет-стандарты http и https также являются коммуникационными протоколами, которые отправляют и получают информацию через запросы и ответы.

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

Чтобы помочь WebSocket создавать и управлять своим подключением к серверу, необходим объект API WebSocket (WS). После создания соединения WS API также отправляет и получает данные о созданном им соединении.

API WebSocket отличается от стандартного API SOAP или REST характером трафика.

Если бы я тестировал REST API, я бы отправлял запрос, «ждал» ответа и опрашивал его, чтобы убедиться, что у него есть код ответа, данные, формат и время ответа, которые я ожидал (илл. 1):

Хороший простой тест REST API в REST Assured на Java будет выглядеть примерно так (илл.2):

Я отправляю запрос с некоторыми параметрами и ожидаю возврата кода состояния. Тест либо проходит, либо не проходит, и работа выполняется. С WebSocket API мы смотрим на другую проблему из-за постоянного характера соединений. Нам нужен метод для поддержания открытого соединения, и нам нужен способ увидеть сообщения, которые приходят в ответ на сообщения, которые вы отправляете (илл.3):

Прежде чем мы перейдем к механике создания любой автоматизации, нам полезно увидеть простой WebSocket в действии. Хорошие люди из Websocket.org создали веб-приложение, которое позволяет вам играть с их WebSocket или вставлять URL-адрес для вашего собственного.

Он обеспечивает простой интерфейс ввода данных, чтобы вы могли видеть, как WebSocket открывает соединения, отправляет сообщения и закрывает соединения.

1. Определите, что приложение использует WebSockets:

Проверьте исходный код на стороне клиента для схемы ws://или wss://URI.
Используйте инструменты разработчика Google Chrome для просмотра сетевого соединения WebSocket.

2. Источник:

Используя клиент WebSocket, попытайтесь подключиться к удалённому серверу WebSocket. Если соединение установлено, сервер может не проверять исходный заголовок рукопожатия WebSocket.

3. Конфиденциальность и честность:

Убедитесь, что соединение WebSocket использует SSL для передачи конфиденциальной информации wss://.
Проверьте реализацию SSL на наличие проблем с безопасностью (действительный сертификат, BEAST, CRIME, RC4 и т. д.).

4. Аутентификация и авторизация:

Веб-сокеты не обрабатывают аутентификацию, следует проводить обычные тесты аутентификации чёрного ящика.

Как только мы определили, что приложение использует WebSockets (как описано выше), мы можем использовать https://www.piesocket.com/socketio-tester для перехвата запросов и ответов WebSocket. Добавляем наш url по которому обращаемся в веб-сокету

Всегда, когда нужно проверять веб-сокеты, нельзя забывать кейс, когда он может потерять связь. Для избежания этого нужно добавлять условие переподключения в случае потери связи (илл. 4, 5):