Тестирование WebSocket: как проверять real-time соединения вручную и что автоматизировать

Чем WebSocket отличается от обычного API

Когда тестировщик впервые сталкивается с real-time приложением, первый импульс - открыть Postman, отправить запрос и посмотреть на ответ. Но с WebSocket этот подход работает иначе. Здесь нет цикла «запрос - ответ - закрытие». Клиент и сервер устанавливают соединение один раз, и дальше оба могут отправлять сообщения в любой момент, не дожидаясь инициативы другой стороны.

Это меняет всю логику проверки. Вместо статусов HTTP и тела ответа вы наблюдаете за потоком событий: что пришло, в каком порядке, с какой задержкой, что произошло при обрыве сети. Именно поэтому тестирование WebSocket выделяют в отдельную дисциплину, а не сводят к расширению API-тестирования.

Протокол начинается с HTTP-хендшейка: клиент отправляет заголовок Upgrade: websocket, сервер отвечает кодом 101 Switching Protocols, и соединение переходит в режим постоянного канала. Всё, что происходит дальше, - это уже фреймы данных, а не HTTP-запросы.

Что проверять вручную и зачем это вообще нужно

Ручная проверка здесь не формальность. Именно она помогает понять, как система ведет себя в нестандартных ситуациях: что происходит, когда сервер молчит дольше обычного, как клиент реагирует на неожиданное закрытие канала, приходят ли сообщения в правильном порядке при высокой нагрузке.

Начинать стоит с базового сценария: установить соединение, отправить тестовое сообщение, убедиться, что ответ пришел и выглядит корректно. Это занимает пять минут, но сразу показывает, работает ли вообще канал и какой формат данных используется.

Дальше - граничные случаи. Отправьте пустое сообщение. Отправьте очень длинную строку. Попробуйте подключиться без токена авторизации. Закройте вкладку браузера и снова откройте. Отключите сеть на 30 секунд и посмотрите, восстановится ли соединение само.

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

Инструменты для ручной работы

Выбор инструмента зависит от того, насколько глубоко нужно копать и насколько удобен интерфейс.

Postman поддерживает WebSocket начиная с версии 8.5. В интерфейсе нужно выбрать тип запроса WebSocket, указать URL вида ws:// или wss://, подключиться и начать отправлять сообщения. Все входящие события отображаются в панели справа с временными метками.

Браузерная консоль - недооцененный инструмент. Вкладка Network, фильтр WS - и вы видите все фреймы, которые реально проходят между браузером и сервером. Это особенно полезно, когда нужно понять, что именно отправляет фронтенд, а не то, что написано в документации.

Типичные баги: где чаще всего ломается

Real-time соединения создают специфический класс проблем, которые не встречаются в обычном HTTP-взаимодействии.

Разрыв соединения без переподключения

Сервер закрывает канал через таймаут, клиент не получает уведомление и продолжает «работать» - но сообщения уже никуда не уходят. Пользователь видит интерфейс чата, пишет текст, нажимает отправить - и ничего не происходит. Баг проявляется не сразу, а через 5-30 минут неактивности.

Как проверить: откройте соединение, подождите дольше таймаута (обычно это настраивается на сервере, значение можно узнать у разработчика), затем попробуйте отправить сообщение. Если ответа нет - клиент не умеет переподключаться.

Гонки сообщений

Два события генерируются почти одновременно, но приходят в неправильном порядке. Например, пользователь редактирует документ совместно с коллегой: изменение A отправлено раньше изменения B, но на экране появляется сначала B. Итоговый текст оказывается некорректным.

Воспроизвести это вручную сложно, но можно: откройте несколько вкладок и быстро отправляйте сообщения из разных сессий одновременно. Если порядок нарушается - это баг, который нужно фиксировать.

Утечки памяти при долгих сессиях

Соединение живет часами. Каждое входящее событие добавляет обработчик или объект в память, но они никогда не удаляются. Через несколько часов браузер начинает тормозить, вкладка потребляет гигабайт памяти.

Проверяется через DevTools - вкладка Memory. Сделайте снимок памяти сразу после подключения, затем через 30 минут активной работы. Если объем растет без плато - скорее всего, есть утечка.

Проблемы с авторизацией на уровне хендшейка

WebSocket не поддерживает произвольные заголовки при установке соединения так же гибко, как HTTP. Токен авторизации часто передается через query-параметр (wss://example.com/ws?token=abc) или через первое сообщение после подключения. Если сервер не проверяет токен правильно, неавторизованный клиент может подключиться и получать чужие данные.

Проверьте: попробуйте подключиться без токена, с истекшим токеном, с токеном другого пользователя. Сервер должен закрывать соединение с кодом 1008 (Policy Violation) или аналогичным.

Дублирование сообщений

Клиент переподключается после разрыва и получает повторно те сообщения, которые уже были доставлены. Или, наоборот, при переподключении теряет события, которые пришли во время разрыва. Оба варианта - баги, но с разными последствиями.

Некорректная обработка кодов закрытия

WebSocket-соединение закрывается с кодом и причиной. Код 1000 - нормальное закрытие, 1001 - клиент уходит, 1006 - аномальное закрытие без фрейма. Если клиент не различает эти коды, он может пытаться переподключиться там, где не нужно, или не переподключаться там, где это критично.

Тестирование чатов и уведомлений: специфика

Чаты и системы уведомлений - самые распространенные сценарии применения постоянных соединений. У них есть своя специфика, которую стоит проверять отдельно.

Для чатов критично: сообщение должно появляться у получателя без перезагрузки страницы, порядок сообщений должен совпадать с порядком отправки, история должна корректно загружаться при подключении, а набор текста (typing indicator) не должен «застревать» на экране после того, как пользователь перестал печатать.

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

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

Что автоматизировать и как это делать

Автоматизация WebSocket тестов имеет смысл там, где ручная проверка неэффективна: при регрессии, при нагрузочных сценариях, при проверке поведения при разрыве соединения.

Что стоит покрывать автотестами

Вакансии для QA-инженеров

Сбер

вчера

automation qa

~ 305 559 ₽

senior

гибрид Москва

Сбер

сегодня

qa инженер (auto)

от 150 000 ₽

junior

гибрид Москва

Сбер

вчера

automation qa

~ 188 950 ₽

middle

гибрид Москва

Вакансии для QA-инженеров

Сбер

вчера

automation qa

~ 305 559 ₽

senior

гибрид Москва

Сбер

сегодня

qa инженер (auto)

от 150 000 ₽

junior

гибрид Москва

Сбер

вчера

automation qa

~ 188 950 ₽

middle

гибрид Москва

• Успешное установление соединения и получение первого события
• Доставка сообщения от клиента A к клиенту B
• Поведение при закрытии соединения со стороны сервера
• Переподключение после разрыва
• Проверка, что неавторизованный клиент не получает данные
• Проверка формата и схемы входящих сообщений
• Поведение при отправке некорректных данных

Инструменты для автоматизации

Python + websockets - самый простой способ написать тест без лишних зависимостей. Библиотека websockets позволяет подключиться, отправить сообщение и проверить ответ в несколько строк кода. Хорошо интегрируется с pytest.

k6 - инструмент для нагрузочного тестирования, который поддерживает WebSocket из коробки. Позволяет симулировать тысячи одновременных соединений и измерять задержку доставки сообщений. Подходит для проверки, как система ведет себя при пиковой нагрузке.

Playwright и Cypress - если нужно проверить поведение реального браузерного приложения, а не только серверную логику. Playwright умеет перехватывать WebSocket-фреймы через page.on('websocket', ...), что позволяет писать e2e-тесты с проверкой реальных событий.

Postman Collections + Newman - если команда уже использует Postman для API-тестирования, WebSocket-запросы можно включить в коллекцию и запускать через Newman в CI. Подходит для базовой регрессии.

import asyncio
import websockets
import json

async def test_message_delivery():
    async with websockets.connect("wss://example.com/ws?token=test") as ws:
        await ws.send(json.dumps({"type": "ping"}))
        response = await asyncio.wait_for(ws.recv(), timeout=5)
        data = json.loads(response)
        assert data["type"] == "pong"

asyncio.run(test_message_delivery())

Что не стоит автоматизировать

Исследовательские сценарии - когда нужно понять, как система ведет себя в нестандартной ситуации - лучше делать вручную. Автотест проверяет конкретное ожидание, а не исследует поведение. Если вы еще не знаете, что должно происходить при определенном сценарии, сначала проверьте руками.

Также не стоит автоматизировать проверку визуального отображения событий в интерфейсе - это дорого в поддержке и редко оправдывает затраты.

Как наблюдать за соединением в браузере

DevTools - ваш главный инструмент при работе с реальным приложением. Откройте вкладку Network, отфильтруйте по WS. Вы увидите список WebSocket-соединений. Кликните на нужное - откроется панель с фреймами.

Каждый фрейм показывает: направление (входящий или исходящий), время, длину и содержимое. Зеленые стрелки - данные от сервера, серые - от клиента. Если сообщения приходят в бинарном формате, браузер покажет их в hex-представлении.

Полезный прием: откройте DevTools до загрузки страницы, чтобы не пропустить хендшейк. Именно там видно, с каким статусом установилось соединение и какие заголовки были переданы.

Чеклист для проверки WebSocket-функциональности

1. Соединение устанавливается успешно (статус 101 в хендшейке)
2. Неавторизованный запрос отклоняется с корректным кодом закрытия
3. Истекший или некорректный токен не дает подключиться
4. Сообщение от клиента доставляется серверу и обрабатывается
5. Событие от сервера приходит клиенту без задержки
6. При многопользовательском сценарии каждый получает только свои данные
7. После разрыва сети соединение восстанавливается автоматически
8. Сообщения, отправленные во время разрыва, не теряются и не дублируются
9. При долгой сессии (30+ минут) память браузера не растет бесконтрольно
10. Одновременная отправка из нескольких сессий не нарушает порядок событий
11. Сервер корректно закрывает соединение с правильным кодом при выходе пользователя
12. Клиент корректно обрабатывает неожиданное закрытие со стороны сервера

Форматы сообщений и валидация схемы

Один из аспектов, который часто упускают при проверке real-time каналов, - это контракт на уровне данных. В REST-сервисах схема ответа обычно задокументирована и проверяется через JSON Schema или OpenAPI. В постоянных соединениях такой строгости часто нет: сервер может отправить что угодно, и клиент просто попытается это обработать.

Проверяйте несколько вещей. Во-первых, тип поля: если сервер должен отправлять userId как число, убедитесь, что он не присылает строку в некоторых сценариях. Во-вторых, обязательные поля: что происходит, если в событии отсутствует поле type или payload? Клиент должен обрабатывать такие ситуации без падения. В-третьих, неизвестные типы событий: сервер прислал событие с типом, которого нет в документации. Клиент должен игнорировать его, а не ломаться.

Для автоматической валидации схемы удобно использовать библиотеку jsonschema в Python или zod в TypeScript. Вы описываете ожидаемую структуру каждого типа события и проверяете каждое входящее сообщение в тесте. Это особенно полезно при регрессии: если разработчик переименовал поле, тест упадет сразу, а не через неделю, когда пользователь заметит сломанный интерфейс.

Поведение при масштабировании: несколько экземпляров сервера

В продакшне приложение почти никогда не работает на одном сервере. За балансировщиком нагрузки стоят два, три или десять экземпляров. Это создает специфическую проблему для постоянных соединений: клиент A подключен к экземпляру 1, клиент B - к экземпляру 2. Когда A отправляет сообщение, оно попадает на экземпляр 1. Как оно доберется до B на экземпляре 2?

Обычно это решается через брокер сообщений: Redis Pub/Sub, Kafka, RabbitMQ. Но если эта часть настроена неправильно, баг будет воспроизводиться только в определенных условиях: иногда сообщение доходит, иногда нет. Воспроизвести локально сложно, потому что там один экземпляр.

Как проверить это в тестовой среде: уточните у разработчика, есть ли в staging несколько экземпляров сервиса. Если есть, проведите тест с двумя пользователями несколько раз подряд и проверьте, всегда ли сообщение доходит. Если среда однопоточная, попросите добавить хотя бы два экземпляра для нагрузочного теста с k6.

Также проверьте sticky sessions: некоторые балансировщики настроены так, что один клиент всегда попадает на один и тот же экземпляр. Это решает проблему, но создает другую: при падении экземпляра все его клиенты теряют соединение одновременно. Убедитесь, что переподключение в этом случае работает корректно.

Сравнение подходов к проверке разных сценариев

Как документировать результаты проверки

Результаты ручной проверки real-time сценариев сложнее зафиксировать, чем обычные баги. Проблема в том, что поведение часто зависит от времени: сообщение пришло через 3 секунды вместо 0.5, соединение восстановилось через 45 секунд, а не сразу. Без конкретных цифр баг-репорт выглядит размыто.

Несколько правил для документирования таких находок. Записывайте временные метки из DevTools: они показывают точное время каждого фрейма. Делайте скриншот панели WS-фреймов - это наглядно показывает порядок событий. Если воспроизвести баг сложно, опишите условия: через сколько минут проявился, при каком количестве активных вкладок, в каком браузере.

Для нагрузочных тестов k6 генерирует отчет с перцентилями задержки (p95, p99) и количеством ошибок. Прикладывайте этот отчет к задаче, а не просто пишите «при нагрузке тормозит». Разработчику нужны цифры, чтобы понять, где именно узкое место.

Отдельно фиксируйте коды закрытия соединения. Если соединение закрылось с кодом 1006 (аномальное закрытие), это важная информация для отладки. Если с кодом 1008 (Policy Violation) - значит, сервер отклонил соединение по политике. Эти коды видны в DevTools и в логах клиента, и они существенно ускоряют поиск причины проблемы.

FAQ

Чем тестирование WebSocket отличается от тестирования REST API?

REST работает по модели «запрос - ответ»: каждый запрос независим, соединение закрывается. WebSocket - это постоянный канал, где сервер может отправлять данные в любой момент без запроса от клиента. Поэтому проверяют не статус ответа, а поток событий, порядок сообщений, поведение при разрыве и восстановлении соединения.

Можно ли тестировать WebSocket в Postman?

Да, начиная с версии 8.5. В интерфейсе нужно создать новый запрос типа WebSocket, указать URL с протоколом ws:// или wss://, подключиться и отправлять сообщения вручную. Все входящие события отображаются с временными метками. Для автоматизации можно использовать Newman, хотя возможности пока ограничены по сравнению со специализированными инструментами.

Какие баги встречаются чаще всего?

Самые частые проблемы: соединение разрывается по таймауту, но клиент не переподключается; сообщения дублируются при восстановлении соединения; неавторизованный пользователь получает чужие данные из-за некорректной проверки токена на уровне хендшейка; утечка памяти при долгих сессиях из-за накопления обработчиков событий.

Как проверить, что соединение восстанавливается после разрыва?

Самый простой способ вручную: отключите сетевой интерфейс на 15-30 секунд (или используйте DevTools - вкладка Network - режим Offline), затем восстановите соединение и проверьте, появились ли новые события. В автотестах можно использовать прокси вроде Toxiproxy, который умеет симулировать разрывы и задержки сети.

Нужно ли тестировать wss:// отдельно от ws://?

Да, если приложение использует оба протокола в разных средах. Шифрованное соединение (wss) добавляет TLS-рукопожатие, которое может завершаться с ошибкой при проблемах с сертификатом. Проверьте, что соединение устанавливается, сертификат валиден и не истек, а данные не передаются в открытом виде там, где должно быть шифрование.

Как тестировать WebSocket в CI/CD пайплайне?

Для интеграции в CI подходят websocat (CLI-клиент, который можно вызывать из shell-скриптов), Python с библиотекой websockets и pytest, а также k6 для нагрузочных проверок. Важно, чтобы тесты имели явные таймауты - без них зависший тест заблокирует весь пайплайн.

Что делать, если сервер отправляет данные в бинарном формате?

Бинарные фреймы (Binary Message) в DevTools отображаются в hex. Для работы с ними в тестах используйте библиотеки, которые умеют декодировать нужный формат - например, MessagePack или Protocol Buffers. Уточните у разработчика схему данных и проверяйте корректность десериализации.

Итог

WebSocket-соединения проверяют иначе, чем обычные API-запросы. Здесь важен не статус ответа, а поведение канала во времени: как система реагирует на разрыв, не теряет ли сообщения, не смешивает ли данные разных пользователей. Именно эти сценарии чаще всего остаются непроверенными - и именно они всплывают в продакшне в самый неподходящий момент.

Начните с ручной проверки базовых сценариев через Postman или браузерную консоль. Добавьте граничные случаи: разрыв сети, долгая сессия, одновременные подключения. Автоматизируйте то, что нужно проверять при каждом релизе: доставку сообщений, авторизацию, поведение при переподключении. Остальное - исследуйте руками, когда появляются новые фичи или подозрительные баги.