Как протестировать онлайн-чат: чек-лист для QA-инженеров

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

Начнем с теории и обсудим,

Протокол WebSocket (веб-сокет) предназначен для обмена данными между браузером и сервером в режиме реального времени. Данные передаются по протоколу в обоих направлениях без разрыва соединения и без дополнительных HTTP-запросов.

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

На примере веб-приложения, WebSocket-соединение устанавливается путем отправки HTTP-запроса:

Клиент отправляет HTTP-запрос с передачей специфичных заголовков. Среди этих заголовков присутствует заголовок Upgrade: websocket, он как раз указывает серверу на то, что клиент желает переключиться с обычного HTTP-соединения на WebSocket-протокол.
Сервер подтверждает запрос, возвращая Response Code: 101 Switching Protocols.
После успешного переключения клиент и сервер могут обмениваться данными в реальном времени через WebSocket-соединение.

Пример запроса клиента для установки WebSocket-соединения с использованием библиотеки Socket.IO:

GET /socket.io/?EIO=4&transport=websocket HTTP/1.1
GET - это HTTP-метод, который используется для WebSocket соединения.
/socket.io/?EIO=4 - путь на ресурс на сервере и его используемая версия протокола, в качестве примера показан сервис Socket.io.
&transport=websocket - могут передаваться необходимые параметры запроса, в качестве примера приведен параметр, указывающий, что транспортный протокол, используемый для соединения это WebSocket.
Host: devexample.com
Здесь указывается домен сервера, к которому происходит подключение.
Connection: Upgrade
Upgrade: websocket
Обязательные заголовки, указывающие, что клиент желает перейти на новый протокол с HTTP на WebSocket.
Sec-WebSocket-Key: oLhMxYk788RTlBoiJesy7A==
Обязательный заголовок, в котором передается уникальный ключ, генерируемый клиентом для подтверждения того, что он имеет право запросить соединение у сервера.
Sec-WebSocket-Version: 13
Обязательный заголовок, в котором передается версия WebSocket-протокола.

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

Accept-Encoding: gzip, deflate, br, zstd
В заголовке указываются методы сжатия, которые поддерживает клиент. Он полезен для оптимизации передачи данных, но его отсутствие не помешает установлению WebSocket-соединения.
User-Agent: Mozilla/5.0 (Windows NT; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/xx.x.x.x Safari/537.36 Edg/xx.x.x.x
В этом заголовке передается информация о браузере и устройстве клиента. Бывает полезен для сбора статистики.

Как сказано выше, WebSocket обеспечивает обмен данными в режиме реального времени, а это значит, что тестировать необходимо не только connect и disconnect, но и корректную работу на протяжении длительного времени использования, проверить, что соединение остается стабильным и сообщения обрабатываются успешно.
Прежде чем данные начнут передаваться, у WebSocket есть стадия рукопожатия (handshake). Это тоже важно тестировать, чтобы убедиться, что соединение корректное и безопасное.
WebSocket-соединения могут быть уязвимы к различным атакам, таким как перехват сообщений, подмена пользователей. Тестирование должно учитывать сценарии на проникновение и на наличие уязвимостей.
Помимо этого нужно проверять корректность передаваемых данных между клиентом и сервером. Следует убедиться, что данные не искажаются и не теряются, и если мы говорим про чаты, то сюда относятся проверки отправки-получения разных типов сообщений: текст, разные допустимые и не допустимые форматы вложений, ссылки и прочее. Потребуется генерация большого количества различных сообщений и проверка на соответствие их содержимого.
Необходимо учитывать сценарии дублирования или недоставки сообщений, так как WebSocket не использует механизмы подтверждения доставки сообщений.
Также WebSocket не гарантирует порядок доставки сообщений (особенно при высоких нагрузках) это чревато рассинхроном данных. При тестировании стоит обращать внимания на порядок отправленных и полученных сообщений, ситуации когда сообщения приходят одновременно и прочее.
Необходимо тщательное тестирование функциональности, разрабатывать подробные тестовые сценарии для каждой функции.
Требуется анализ скорости передачи данных на предмет соответствии с требованиями программного продукта.
Необходимо проверять, что ошибки корректно отрабатывают и не приводят к сбоям.
Тестирование должно охватить все популярные платформы, устройства и браузеры.
Требуются проверки на производительность и нагрузку.

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

Давайте кратко рассмотрим процесс взаимодействия на практике:

Когда пользователь открывает чат, браузер отправляет WebSocket-запрос на сервер. После подтверждения сервером - устанавливается постоянное соединение.
Пользователь пишет сообщение в чате - текст мгновенно отправляется на сервер через WebSocket, а сервер сразу передает его менеджеру (как пример).
И наоборот, менеджер отправляет сообщение - пользователь мгновенно получает это сообщение в чате.

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

Чек-лист приведен именно к пользовательской части рассматриваемого приложения.

Я не буду подробно касаться проверок по API-запросам, так как эта тема заслуживает отдельного поста.

Представим, что разработана функциональность онлайн-чата клиента с менеджером сайта. Имеются следующие бизнес-требования:

Чат доступен всем пользователям веб-приложения с момента регистрации в личном кабинете. Пользователь может открыть чат кликая на иконку с конвертом в личном кабинете. После нажатия открывается окно чата, в котором пользователь может напечатать сообщение текстом (до 255 символов) и отправить вложение до 10Мб (jpg, png, docx, doc, txt, pdf, csv). Пользователь может отредактировать отправленное, но не прочитанное текстовое сообщение неограниченное кол-во раз, но не может его удалить или отменить отправку. В чате фиксируется дата отправки сообщения и статус прочтения администратором.

Менеджер открывает чат через админ-панель (взаимодействие двух сервисов происходит посредством API-запросов). Менеджер также может отправить текстовое сообщение (до 255 символов) и вложение до 10Мб (jpg, png, docx, doc, txt, pdf, csv). Помимо этого, у менеджера есть дополнительные возможности по взаимодействию: менеджер может отметить сообщение флагом “избранное”, а также снять флаг. В чате фиксируется дата отправки сообщения и статус прочтения пользователем.

1. Функциональное тестирование.

Проверьте доступность чата в веб-приложении.

На этом шаге примените технику тест-дизайна разбиения по классам эквивалентности: авторизованный (чат доступен) и неавторизованный пользователь (чат не доступен).

Проверьте, что WebSocket-соединение успешно устанавливается (получение статуса 101, корректность заголовков запроса).
Отправка валидных текстовых сообщений.
Проверьте корректную обработку сервером сообщений, содержащих спецсимволы и/или эмодзи.
Удостоверьтесь, что сообщения со спецсимволами и эмодзи корректно отображаются в чате.
Проверьте отображение разных типов эмодзи (Unicode, emoji-смайлики).
Проверьте, что при отправке ссылок они преобразовываются в кликабельные.
Проверьте, что обрабатываются разные типы ссылок (http, https, ftp, внутренние ссылки).
Проверьте отправку сообщений с переносами строк.
Проверьте отправку пустых сообщений/содержащих один пробелы.
Проверьте обработку ошибок при переходе по некорректным или недействующим ссылкам.

Техника граничных значений: проверьте минимальную и максимальную длину текста.

Редактирование текстовых сообщений. Удостоверьтесь, что текст можно отредактировать, после редактирования.
Проверьте редактирование от лица разных пользователей (пользователь, менеджер).
Проверьте редактирования сообщений разной длины, в том числе граничные значения длины.
Проверьте редактирование сообщения в момент, когда второй участник чата его читает.
Удостоверьтесь, что редактирование можно отменить.
Проверьте, функцию удаления (в зависимости от требований).

При выполнении этих проверок полезно использовать технику попарного тестирования. Она позволит охватить разные сценарии редактирования сообщений.

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

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

Проверьте функцию предварительного просмотра вложения.
Проверьте функцию загрузки нескольких файлов одновременно (разных размеров и форматов).
Проверьте обработку вложений с одинаковыми названиями файлов.
Проверьте получение ошибки при отправке недопустимого формата файлов.
Проверьте получение ошибки при отправке файла с размером более 10Мб.
Проверьте статус прочтения. Убедитесь, что синхронизация работает без задержек и в интерфейсе корректно отображается статус прочтения.
Проверьте доступные функции: добавление флага «избранное», добавление сообщения в избранное и т. д.

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

Проверьте, что история сообщений сохраняется и доступна пользователю и менеджеру.
Удостоверьтесь, что история сообщений не теряется после перезагрузки страницы/разлогина или закрытия браузера.
Проверьте функцию поиска по истории сообщений.
Проверьте скорость загрузки чата и отправки сообщений.
Сэмулируйте разрыв соединения и проверьте переподключение WebSocket-соединения.
Проверьте корректную обработку ошибки подключения к серверу.
Проверьте корректную обработку ошибок при отправке сообщений (например, поведение когда превышен размер файла или недопустимый.

2. Нефункциональное тестирование.

Разграничим их на подвиды тестирования:

2.1. Тестирование пользовательского интерфейса (Usability testing)

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

2.2. Тестирование совместимости (Compatibility testing)

Проверьте работу чата в разных браузерах (при выборе браузеров ориентируйтесь на требования от бизнеса)
Проверьте работу чата на разных устройствах (ПК, смартфоны, планшеты).

2.3. Тестирование локализации (Localization testing)

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

2.4. Тестирование безопасности (Security testing)

Удостоверьтесь, что чаты доступны только авторизованным пользователям.
Проверьте устойчивость к SQL-инъекциям в сообщениях.
Проверьте, что используется защищенное соединение (wss://) для передачи данных.
Проверьте ограничение запросов (rate limiting) для исключения спама.

2.5. Тестирование надежности и восстановления после сбоев (Reliability testing)

Сэмулируйте разрыв соединения и проверьте корректное восстановление чата после разрыва.
Удостоверьтесь, что сохраняется вся история сообщений после разрыва соединения и обновления страницы.
Проверьте сценарии сохранения и повторной отправки неотправленных сообщений после восстановления соединения.

2.6. Нагрузочное тестирование (Load testing)

Проверьте обработку большого количества сообщений (например 100+ подряд)
Проверьте обработку отправки и получения большого количества вложений с максимальным размером
Проверьте загрузку чата и историю сообщений при наличии большого количества записей.

2.7. Стресс-тестирование (Stress testing)

Проверьте поведение системы в условиях превышения допустимой нагрузки (например, 10000 пользователей одновременно).

Следующий список поможет вам в дополнении пользовательских сценариев для тестирования.

Проблемы с установкой соединения - разрыв WebSocket-соединения.
Возможна проблема дублирования сообщений из-за двойного подключения пользователя (используются две или несколько вкладок браузера или два устройства одновременно).
Проблемы с отправкой или получением сообщений. Сообщения могут дублироваться, не доставляться, отображаться в неправильном порядке или в некорректном виде.
Проблемы с своевременным обновлением при поступлении новых сообщений и проблемы с уведомлениями.
Проблемы с отображением даты и времени (формат, временные зоны).
Сообщения могут быть не видны при определенных размерах экрана (например, при узком экране текст может выйти за границы и скрываться или длинные сообщения не переносится на новую строку).
Проблема потери сообщений при разрыве соединения. Сервер может не подтвердить получение.

Поделитесь в комментариях: какие баги 🐞 встречались вам в вашей практике? Как вы их устранили и предотвратили дальнейшее возникновение? 🙂

Мои рекомендации будут стандартизированными:

Используйте в работе инструменты для тестирования WebSocket. Например Postman хорошо справляется с такой задачей.
Используйте снифферы трафика, например Charles Proxy или Fiddler. Они помогут анализировать WebSocket-трафик.
Введите тестовую документацию, пишите подробные тест-кейсы.
Автоматизируйте тестирование, чтобы ускорить процесс тестирования и повысить его эффективность.
Проводите регулярно регрессионное тестирование онлайн-чатов, чтобы убедиться, что новые изменения не привели к новым дефектам или ухудшению имеющейся функциональности.
Приоритезируйте тесты для регресса, чтобы сосредоточиться на наиболее важных функциях и сценариях по работе с чатами.

Как протестировать онлайн-чат: чек-лист для QA-инженеров

Что такое WebSocket?

Особенности тестирования WebSocket.

Как WebSocket используется в онлайн-чатах?

Чек-лист тестирования онлайн-чатов:

Типичные и нетипичные баги в онлайн-чатах.

Рекомендации по проведению тестирования.