Тестирование веб-сокетов: опыт 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 в действии. Хорошие люди из 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):
Итак, на этом у меня всё, надеюсь, аудитории vc.ru моя статья была полезна. Задавайте свои вопросы по теме, буду рад ответить каждому.