Я — Анна Круглова, в Диасофт занимаюсь развитием инструментов автоматизации тестирования на базе искусственного интеллекта. В нашей компании процесс создания тестов для API и событий полностью автоматизирован с помощью ИИ. В этой статье расскажу, как это устроено и как изменился подход к работе тестировщиков.

Особенности сложных API и событий

В Диасофт для проектирования микросервисов и межсервисных взаимодействий используется low-code платформа Digital Q.Archer. На её основе генерируется код сервисов.

Раньше автоматизировали только автотесты для стандартных CRUD-операций. Они типовые и легко шаблонизируются. А вот тесты для API и событий с уникальной бизнес-логикой приходилось писать вручную.

Проблема в том, что CRUD-операции охватывают лишь малую часть функциональности продукта. Основная ценность — в сложных бизнес-процессах: расчёте процентов, применении комиссий, обработке лимитов и других нетривиальных сценариях. Ручное тестирование сотен таких кейсов требовало огромных ресурсов и замедляло релизы.

Сложные API и события не просто передают данные — они реализуют бизнес-операции. Их логика может затрагивать множество объектов, запускать цепочки событий и требовать строгой последовательности вызовов. Проверки должны учитывать не только статус ответа, но и то, как изменилось состояние системы и соответствует ли это бизнес-правилам.

ИИ пишет тест как опытный разработчик: как так получилось?

Мы не просто подключили ИИ к процессу — мы интегрировали его в технологический конвейер платформы Digital Q.DevOps. Теперь ИИ — это полноценный Агент автотестирования, встроенный в платформу.

Процесс построен как чёткая последовательность шагов. ИИ (в виде LLM) выступает как «интеллектуальное ядро», но его действия строго контролируются платформой. Ключевой принцип — итеративность и обратная связь от реального окружения. ИИ не просто генерирует код, а сразу запускает его, анализирует ошибки и улучшает тест. Это делает его похожим на опытного разработчика, который умеет отлаживать свои решения.

Три особенности Digital Q.DevOps, которые помогают контролировать ИИ:

Единый источник правды — Digital Q.Archer: Все контракты API и событий хранятся в одной системе. Оркестратор берёт оттуда актуальные спецификации, исключая работу с устаревшими данными.

Встроенная инфраструктура запуска: В платформе уже есть сервисы для выполнения автотестов на тестовых стендах. Агент ИИ использует их через HTTP, передавая сгенерированный код. Это позволяет безопасно запускать код в изолированной среде (пода).

Доменные правила (Domain Rules): Оркестратор проверяет, соответствует ли сгенерированный код внутренним стандартам — например, использованию базового класса SpecBase. Если нет — отправляет тест на доработку с указанием ошибок.

Как это работает

Процесс состоит из нескольких этапов, где тестировщик и ИИ взаимодействуют через Оркестратор:

1. Старт: Тестировщик выбирает сервис и описывает тест-кейс на бизнес-языке.
2. Получение контрактов: Оркестратор загружает Swagger (API) и JSON-схемы событий, парсит и фильтрует их.
3. Отбор эндпоинтов и событий: Оркестратор передаёт LLM отфильтрованные эндпоинты и тест-кейс. LLM определяет релевантные сущности. Процесс повторяется для событий. Пользователь видит и подтверждает выбор.
4. Генерация: Оркестратор передаёт LLM отобранные эндпоинты, события, тест-кейс и доменные правила. LLM генерирует код автотеста на Groovy.
5. Валидация кода: Оркестратор проверяет соответствие кода стандартам. При ошибках — возвращает ИИ на исправление.
6. Запуск и итеративная отладка: Код запускается на стенде. При падении теста — ошибка возвращается в LLM. Цикл повторяется до стабильного прохождения (обычно 2–3 итерации).
7. Финальная обработка и публикация: После успеха Оркестратор добавляет служебную информацию, сохраняет статистику и коммитит тест в Git-репозиторий продукта.

Язык кода автотеста

ИИ генерирует код на Groovy — языке, близком к Java. Это удобно, так как микросервисы в Диасофт в основном на Java. Однако архитектура не привязана жёстко к языку — при необходимости можно адаптировать её под Python или Java.

Отдельно про тестирование событий

Тестирование событий сложнее API: нужно инициировать действие, перехватить событие в брокере и проверить его структуру. ИИ справляется благодаря формализованным описаниям из Digital Q.Archer. Сервис запуска умеет подписываться на топики и валидировать сообщения. ИИ генерирует код, использующий эти возможности.

Как ИИ меняет работу тестировщиков

Происходит сдвиг от написания кода к управлению требованиями на бизнес-языке.

Что теперь делает тестировщик?

1. Готовит инструкцию для ИИ (тест-кейс). Чем точнее описан сценарий (например, «Создать вклад, начислить проценты по ставке 5%, проверить итоговую сумму»), тем быстрее и точнее ИИ сгенерирует тест. Это требует глубокого понимания продукта и умения формализовать бизнес-логику.
2. Верифицирует готовый автотест. Тестировщик теперь — «приёмщик» результата. Важно не то, как написан код, а соответствует ли он исходному сценарию. Только специалист с пониманием бизнес-логики может это оценить.

Советы по работе в новых условиях

При составлении тест-кейса:

• Описывайте бизнес-процесс, а не последовательность действий в UI или вызовов API.
• Указывайте цели и ожидаемый результат.
• Используйте терминологию предметной области — она понятна и бизнес-аналитикам, и ИИ.

При проверке сгенерированного теста:

• Сосредоточьтесь на логике проверок (assertions).
• Убедитесь, что ИИ правильно понял, что именно нужно проверить.
• Оцените, достаточно ли проверок для подтверждения сценария.
• Не вычитывайте код построчно — оценивайте его смысловое соответствие задаче.

ИИ не заменяет тестировщика. Он снимает рутину по написанию кода, позволяя сосредоточиться на главном — глубоком анализе качества продукта с точки зрения бизнеса. Требования к квалификации растут, но и ценность работы возрастает в разы.

Привет, Хабр!Я Анна Круглова, в Диасофт занимаюсь развитием инструментов автоматизации тестирования на базе искусственного интеллекта.В нашей компании процесс создания тестов для 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). Если тест не соответствует правилам, он отправляется ИИ на доработку с указанием, что именно нужно исправить.

Как это работает

Процесс состоит из четких шагов, где тестировщик и ИИ взаимодействуют через Оркестратор:

1. Старт:Тестировщик выбирает целевой тестируемый сервис (модель) и указывает тест-кейс на бизнес-языке.
2. Получение контрактов:Оркестратор по модели сервиса загружает Swagger (API) и JSON-схему событий, парсит и фильтрует их.
3. Отбор эндпоинтов и событий:Оркестратор отдает в LLM список отформатированных и отфильтрованных эндпоинтов и тест-кейс. LLM отбирает релевантные для сценария эндпоинты. Затем процесс повторяется для событий. Пользователь видит и может подтвердить отобранные сущности.
4. Генерация:Оркестратор передает в LLM список отобранных эндпоинтов и событий, тест-кейс и наши доменные правила. LLM генерирует код автотеста на Groovy.
5. Валидация кода:Оркестратор проверяет код на соответствие правилам (например, импорты, использование нужных базовых классов). Если есть ошибки, код возвращается в LLM на доработку с указанием причины.
6. Запуск и итеративная отладка:Оркестратор отправляет код в сервис запуска, который выполняет тест на реальном стенде. Результат (успех/неудача с логами) возвращается в Оркестратор. Если тест упал, Оркестратор снова отправляет в LLM код и ошибку для исправления. Этот цикл повторяется заданное число раз (RepeatTimes), пока тест не будет стабильно проходить. Обычно хватает 2-3 итераций.
7. Финальная обработка и публикация:После успешного прохождения Оркестратор добавляет в код служебную информацию (AI-лейбл, импорты, пакет), сохраняет статистику и коммитит готовый тест в Git-репозиторий продукта.

Язык кода автотеста

ИИ генерирует исполняемый код автотеста на Groovy. Groovy выбран как основной язык для тестов, так как он Java-подобный, а продукты в микросервисной архитектуре в Диасофт как раз создаются в основном на Java. При этом сама технология генерации не привязана жестко к языку – при необходимости мы можем адаптировать ее для Python или Java.

Отдельно про тестирование событий

Тестирование событий (асинхронного взаимодействия) сложнее, чем API. При вызове API мы сразу видим синхронный ответ. При работе с событиями нужно: 1) инициировать действие, которое породит событие; 2) «поймать» это событие в брокере сообщений; 3) проверить его структуру и содержимое. В нашем процессе ИИ справляется с этим благодаря тому, что на этапе отбора эндпойнтов и событий он получает формализованное описание событий (из того же Digital Q.Archer), а на этапе запуска и итеративной отладки сервис запуска автотестов уже умеет подписываться на нужные топики и валидировать пришедшие сообщения. ИИ генерирует код, который использует эти возможности инфраструктуры.

Как использование ИИ меняет подход к работе тестировщиков

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

Что теперь делает тестировщик?

1. Готовит качественную инструкцию для ИИ (тест-кейс).Чем четче и детальнее сформулирован сценарий на бизнес-языке («Создать вклад, начислить проценты по ставке 5% и проверить, что итоговая сумма равна ...»), тем точнее и быстрее ИИ подберет нужные эндпоинты и сгенерирует корректный код. Это требует от тестировщика глубокого понимания продукта и умения формализовать бизнес-требования.
2. Верифицирует готовый автотест.Тестировщик превращается в «приемщика» работы ИИ. Ключевой вопрос теперь не «правильно ли написан код?», а «соответствует ли этот код исходному бизнес-сценарию?». Ответить на него может только специалист, который досконально знает логику работы продукта.

Советы по работе в новых условиях

При составлении тест-кейса:- Описывайте бизнес-процесс, а не последовательность нажатия кнопок в UI или вызовов API. Указывайте цели и ожидаемый бизнес-результат.- Используйте терминологию предметной области, понятную и бизнес-аналитику, и (как показывает практика) ИИ.

При проверке сгенерированного теста:- Сосредоточьтесь на логике проверок (assertions).- Убедитесь, правильно ли ИИ понял, что именно нужно проверить в ответе или в событии.- Выясните, достаточно ли этих проверок для подтверждения бизнес-сценария.- Не пытайтесь вычитывать код построчно – оценивайте его смысловое соответствие задаче.

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

Согласны с этим? Буду рада обсудить в комментариях.