Сервисы, в которых данные собираются и обрабатываются на основе других сервисов очень чувствительны к интеграциям. Технические решения часто реализованы на брокерах, например таких как Kafka. В нашем случае была задача с финансовой отчетностью и десятками вариантов состояния документов.
В чем особенность: при ручной проверке тестировщику нужно самостоятельно формировать сообщения для Kafka, заполнять их корректными данными и согласовывать значения полей между сообщениями. Это особенно важно в сценариях, где один документ собирается из нескольких событий. Дополнительно, через один и тот же топик могут приходить сообщения, с индивидуальными правилами обработки, в зависимости от значений полей.
Чтобы регулярно проверять такие сценарии и не зависеть от ручной подготовки данных, мы их включили в автотесты и добавили в регрессионные прогоны.
О проекте
Сервис для автоматизации работал с документами бухгалтерского и управленческого учета с интеграцией с 1С УХ.
С точки зрения тестирования проект имеет две особенности:
- backend построен вокруг интеграций через Kafka
- frontend содержит большое количество однотипных форм документов
Формы на UI похожи по структуре, но отличаются набором полей. Этот набор зависит от источника данных, типа и статуса документа, а также от роли пользователя. В системе несколько ролей с разным доступом к данным и действиям.
Такая структура системы приводит к двум типам задач в тестировании:
- На уровне интерфейса нужно проверять множество вариантов отображения документов.
- На уровне интеграций — проверять обработку входящих сообщений и создание документов на их основе.
Почему выбрали автотесты
Обе задачи плохо масштабируются при ручном тестировании. В интерфейсе быстро растет количество комбинаций полей и ролей, а в интеграциях требуется подготовка сообщений и контроль данных.
Поэтому использовали подход с единым сценарием проверки и разными наборами входных данных. Сам тест не меняется, меняются только входные данные и ожидаемый результат. Это позволило покрыть разные варианты отображения документов без дублирования тестов.
Для реализации автотестов использовали Cypress и расширили существующие сценарии проверками интеграций.
Пример теста:
Пример параметров теста:
Бизнес-задача: обработка разных типов сообщений в одном потоке данных
После того как покрыли проверки интерфейса, в регрессе осталась важная часть - создание документов через интеграции. Каждый документ формируется на огромном объёме динамически меняющихся данных, которые включают разную механику обработки.
Прием данных реализован через Kafka, в которую приходят сообщения, на основе которых создаются документы.
Сложность:
- в одном топике приходят данные разных типов
- тип будущего документа определяется значением поля типа документа
- логика обработки зависит от дополнительных параметров сообщения.
В рамках одного сценария система должна:
- отфильтровать часть сообщений
- определить тип создаваемого документа
- разобрать поля по разным правилам в зависимости от типа
- собрать один документ из нескольких сообщений с одинаковыми идентификаторами
Каждое сообщение добавляет строку расхода, а ожидаемое количество строк также приходит в данных. Ошибка на любом из этих этапов критична.
Решение
Задачу не стали решать отдельно от существующих автотестов. Вместо этого расширили уже готовые сценарии проверки документов.
В тесты добавили шаг отправки сообщений в Kafka. Для этого использовали API тестового контура и формировали сообщения с нужными параметрами, включая DocType, идентификаторы и данные строк расходов.
После отправки данных тест выполняет те же действия, что и раньше:
- авторизация под нужной ролью
- поиск документа по номеру
- проверка полей, строк учета и статуса
Таким образом, один сценарий покрывает весь путь от входящего сообщения до отображения документа в интерфейсе.
С какими проблемами столкнулись
Основная сложность - асинхронная обработка сообщений. Документ не появляется сразу после отправки данных, и тест может не найти его в момент проверки.
Чтобы избежать нестабильности, добавили паузу после отправки сообщений и повторные попытки проверки. Тест несколько раз ищет документ по номеру и продолжает выполнение, как только он появляется.
Вторая сложность связана с поиском документа. При создании через интерфейс документ сразу открыт на экране. При создании через интеграцию он появляется в системе после обработки сообщений и не открывается автоматически. Поэтому перед проверкой его нужно сначала найти по номеру.
Результат
После внедрения подхода интеграционные сценарии стали частью регресса и выполняются вместе с остальными тестами. Это дало не только удобство, но и заметный эффект в процессе тестирования.
Во-первых, сократилось время проверки интеграций. Ручная smoke-проверка сценариев с несколькими типами документов сократилась в 5 раз.
Во-вторых, интеграционные проверки стали регулярными. Ранее, если изменения не затрагивали обработку сообщений, эти сценарии могли пропускаться, чтобы сократить время time to market. После автоматизации их стали выполнять в каждом релизе.
Это напрямую повлияло на уверенность в системе. Данные, которые поступают в Kafka, формируются пользователями в других системах и могут содержать ошибки. При сбоях было сложно понять, проблема в данных или в обработке. Регулярные проверки позволили быстрее локализовать причину и сократить время разбора инцидентов.
Кроме того, автотесты помогли обнаружить ошибки, которые не были связаны напрямую с текущими задачами.
Интеграционные сценарии удалось включить в регрессионные проверки без усложнения существующих тестов.
Проверки стали регулярными и не зависят от ручной подготовки данных.