Я Анна Круглова, в Диасофт занимаюсь развитием инструментов автоматизации тестирования на базе искусственного интеллекта.
В нашей компании процесс создания тестов для API и событий полностью автоматизирован с помощью ИИ. В этой статье расскажу, как это устроено и влияет на подход к работе тестировщика.
Особенности сложных API и событий
Для создания микросервисов и проектирования межсервисных взаимодействий (контракты API и событий) в Диасофт используется low-code платформа Digital Q.Archer, на базе которой генерируется код сервисов.
Ранее было автоматизировано создание автотестов только на стандартные CRUD API и события. Такие операции типовые и легко поддаются шаблонизации. Руками же приходилось создавать автотесты для API и событий, содержащих уникальную бизнес-логику.
Основная проблема заключалась в том, что стандартные CRUD-операции покрывали лишь малую часть функциональности реального продукта. Самая ценная и сложная часть – это как раз уникальные бизнес-процессы (расчет процентов, применение комиссий, обработка лимитов и т.д.). Ручное написание тестов для сотни таких сценариев требовало огромных трудозатрат и сдерживало скорость выхода релизов.
Сложные API и события не просто управляют данными, а реализуют конкретные бизнес-операции. Их «сложность» заключается в нетривиальной логике внутри: они могут менять состояние множества объектов, запускать цепочки связанных событий, требовать специфической последовательности вызовов и проверки особых условий. Просто проверить, что API вернул код 200, недостаточно. Нужно проверять, как именно изменились данные в системе, соответствуют ли эти изменения заложенной бизнес-логике.
ИИ пишет тест как опытный разработчик: как так получилось?
Мы не просто точечно взяли ИИ и «прибили гвоздями» к процессу выпуска продукта. Мы встроили его в существующий технологический конвейер платформы Digital Q.DevOps. Это не отдельный инструмент, а полноценный Агент автотестирования, являющийся частью платформы.
Весь процесс – это инженерно выверенная последовательность шагов, где ИИ (LLM) используется как «интеллектуальное ядро», но строго направляется и контролируется нашей платформой. Ключевой принцип — итеративность и обратная связь от реального окружения. ИИ не просто пишет код «в стол», он сразу же запускает его на тестовом стенде, анализирует результаты ошибок и на их основе дорабатывает тест. Это превращает его в подобие опытного разработчика, который не только пишет код, но и отлаживает его.
Особенности Digital Q.DevOps, которые упростили контроль ИИ:
Использование Digital Q.Archer как единый источник правды: Поскольку все контракты API и событий хранятся в Digital Q.Archer, у нас есть эталонное описание того, как должны взаимодействовать сервисы. Оркестратор ИИ берет контракты именно оттуда, что исключает работу с устаревшей или неверной документацией.
Встроенная инфраструктура запуска: В Digital Q.DevOps уже есть сервисы для запуска автотестов на тестовых стендах. Агенту не приходится их создавать с нуля – он просто вызывает их по HTTP, передавая сгенерированный код и параметры подключения. Это позволило легко и безопасно дать ИИ возможность выполнять код в изолированном окружении (пода).
Доменные правила (Domain Rules): Мы научили Оркестратор проверять код теста на соответствие нашим внутренним стандартам (например, обязательное использование библиотечного класса SpecBase). Если тест не соответствует правилам, он отправляется ИИ на доработку с указанием, что именно нужно исправить.
Как это работает
Процесс состоит из четких шагов, где тестировщик и ИИ взаимодействуют через Оркестратор:
-
Старт: Тестировщик выбирает целевой тестируемый сервис (модель) и указывает тест-кейс на бизнес-языке.
-
Получение контрактов: Оркестратор по модели сервиса загружает Swagger (API) и JSON-схему событий, парсит и фильтрует их.
-
Отбор эндпоинтов и событий: Оркестратор отдает в LLM список отформатированных и отфильтрованных эндпоинтов и тест-кейс. LLM отбирает релевантные для сценария эндпоинты. Затем процесс повторяется для событий. Пользователь видит и может подтвердить отобранные сущности.
-
Генерация: Оркестратор передает в LLM список отобранных эндпоинтов и событий, тест-кейс и наши доменные правила. LLM генерирует код автотеста на Groovy.
-
Валидация кода: Оркестратор проверяет код на соответствие правилам (например, импорты, использование нужных базовых классов). Если есть ошибки, код возвращается в LLM на доработку с указанием причины.
-
Запуск и итеративная отладка: Оркестратор отправляет код в сервис запуска, который выполняет тест на реальном стенде. Результат (успех/неудача с логами) возвращается в Оркестратор. Если тест упал, Оркестратор снова отправляет в LLM код и ошибку для исправления. Этот цикл повторяется заданное число раз (RepeatTimes), пока тест не будет стабильно проходить. Обычно хватает 2-3 итераций.
-
Финальная обработка и публикация: После успешного прохождения Оркестратор добавляет в код служебную информацию (AI-лейбл, импорты, пакет), сохраняет статистику и коммитит готовый тест в Git-репозиторий продукта.
Язык кода автотеста
ИИ генерирует исполняемый код автотеста на Groovy. Groovy выбран как основной язык для тестов, так как он Java-подобный, а продукты в микросервисной архитектуре в Диасофт как раз создаются в основном на Java. При этом сама технология генерации не привязана жестко к языку – при необходимости мы можем адаптировать ее для Python или Java.
Отдельно про тестирование событий
Тестирование событий (асинхронного взаимодействия) сложнее, чем API. При вызове API мы сразу видим синхронный ответ. При работе с событиями нужно: 1) инициировать действие, которое породит событие; 2) «поймать» это событие в брокере сообщений; 3) проверить его структуру и содержимое. В нашем процессе ИИ справляется с этим благодаря тому, что на этапе отбора эндпойнтов и событий он получает формализованное описание событий (из того же Digital Q.Archer), а на этапе запуска и итеративной отладки сервис запуска автотестов уже умеет подписываться на нужные топики и валидировать пришедшие сообщения. ИИ генерирует код, который использует эти возможности инфраструктуры.
Как использование ИИ меняет подход к работе тестировщиков
С технической точки зрения происходит фундаментальный сдвиг: мы переходим от написания кода к управлению требованиями на языке бизнеса.
Что теперь делает тестировщик?
-
Готовит качественную инструкцию для ИИ (тест-кейс). Чем четче и детальнее сформулирован сценарий на бизнес-языке («Создать вклад, начислить проценты по ставке 5% и проверить, что итоговая сумма равна …»), тем точнее и быстрее ИИ подберет нужные эндпоинты и сгенерирует корректный код. Это требует от тестировщика глубокого понимания продукта и умения формализовать бизнес-требования.
-
Верифицирует готовый автотест. Тестировщик превращается в «приемщика» работы ИИ. Ключевой вопрос теперь не «правильно ли написан код?», а «соответствует ли этот код исходному бизнес-сценарию?». Ответить на него может только специалист, который досконально знает логику работы продукта.
Советы по работе в новых условиях
При составлении тест-кейса:
– Описывайте бизнес-процесс, а не последовательность нажатия кнопок в UI или вызовов API. Указывайте цели и ожидаемый бизнес-результат.
– Используйте терминологию предметной области, понятную и бизнес-аналитику, и (как показывает практика) ИИ.
При проверке сгенерированного теста:
– Сосредоточьтесь на логике проверок (assertions).
– Убедитесь, правильно ли ИИ понял, что именно нужно проверить в ответе или в событии.
– Выясните, достаточно ли этих проверок для подтверждения бизнес-сценария.
– Не пытайтесь вычитывать код построчно – оценивайте его смысловое соответствие задаче.
ИИ не заменяет тестировщика, а снимает с него рутину по кодингу, позволяя сконцентрироваться на сути – глубоком анализе качества продукта с точки зрения бизнеса. Требования к квалификации становятся выше, но и ценность такой работы возрастает многократно.
Согласны с этим? Буду рада обсудить в комментариях.
Автор: diasoft
