Разрабатываем тестовый стенд с автономным ИИ-агентом QA, способным заменить тестировщика в команде разработки бэкенда

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

Как родилась идея?

Я занимаюсь разработкой ПО около 8 лет, имею опыт работы в нескольких крупных российских компаниях, за годы работы с разными бэкенд сервисами мне не раз приходилось плотно работать над тестированием и взаимодействовать с QA. Не скажу, что я безумно люблю покрывать бизнес логику тестами, искать баги и уязвимости, скорее наоборот каждый раз это вызывает "боль" и "страдания", особенно в условиях отсутствия инфраструктуры для тестирования или сложности коммуникации с QA.

Во всех командах, в которых я работал, тестировщики выполняли очень схожие задачи, но каждый делал это по-своему, и большинство тестировщиков каждый раз начинали с нуля выстраивать свой особый пайплайн, используя свой язык программирования, фреймворки, утилиты, "костыльные" скрипты, спорный форматы документации. Причем, часто тесты выглядели как черный ящик, понимание которых имело большой порог вхождения. Даже если в компании были общие рекомендации и подходы, тестировать сервис внутри команды было "больно".
Главное, что меня заинтересовало в тестировании - это неоптимизированные процессы, которые мне каждый раз хотелось 'хакнуть', сделать понятными, прозрачными и автономными, из этого и родилась идея построить свою концепцию тестирования бэкенда с поддержкой ИИ.

Какие проблемы решаем?

Тестирование бэкенд приложений занимает значительное время и ресурсы. Так по моей оценке тестирование занимает 10-15% времени разработчика при наличии QA в команде или до 30-35% времени разработчика при его отсутствии. По моим наблюдениям, ресурса QA всегда не хватает, один QA на команду, это минимум, который хотела бы иметь команда в своем распоряжении, но реальность не соответствует данным ожиданиям, в итоге приходится выбирать средние значения качества и покрытия бизнес логики тестами, такой подход не исключает возможность появления багов на проде. Как я уже говорил выше, чаще всего отсутствует единый прозрачный подход к тестированию сервисов, в итоге хранителем тайных знаний о тестировании и кейсах является ограниченная группа лиц, что приводит к сложности поддержки и понимании логики сервиса и тестов.

Что хотим получить?

Приложение должно представлять собой многофункциональный тестовый стенд, который имеет следующие функции:

• приложение предоставляет всю информацию о сервисе и его зависимостях, в том числе информацию о контрактах и АПИ

• приложение позволяет производить дебаг поведения сервиса и его зависимостей

• приложение предоставляет возможность формировать, выполнять, дебажить и хранить кейсы тестирования сервиса

• приложение имеет автономного ии-агента QA, умеющего покрывать приложение тестами, выполнять и анализировать тесты, предоставлять любую запрашиваемую информацию о поведении сервиса.

Демонстрационный сервис

В этой главе я хочу поделиться логикой демо сервиса courier-service, на примере которого буду объяснять концепцию разработанной системы. Сourier service - это бэкенд сервис, который специально был разработан для демонстрации работы стенда. На рисунке ниже представлена схема. Основная задача сервиса - создание курьеров с привязанными к ним транспортными средствами. Сервис имеет следующие зависимости: kafka, postgresql, внешние http сервер и grpc сервер и http/grpc апи. Я взял такой сервис за основу, так как 90% сервисов, с которыми я работал, выглядели именно так, это хороший пример для разработки и отладки агента.

Подробнее про зависимости и АПИ.

Пример выполнения grpc запроса CreateCourier

Все контракты сериализованы в json для удобства.
Запрос:

{ "courier": { "name": "Denis", "surname": "Kulikov", "courier_type": "CAR_COURIER_TYPE", "drive_license": { "number": "3536", "serial": "7544" }, "passport": { "number": "7655", "serial": "5435" }, "phone": "24235345", "vehilce_id": "100" } }

Ответ:

{ "courier": { "id": 12, "name": "Denis", "surname": "Kulikov", "courier_type": "CAR_COURIER_TYPE", "drive_license": { "number": "3536", "serial": "7544" }, "passport": { "number": "7655", "serial": "5435" }, "phone": "24235345", "vehilce_id": "100", "updated_at": "2025-09-21T18:33:02", "created_at": "2025-09-21T18:33:02" } }

На схеме зелеными линиями выделены задействованные компоненты

Запрос в accounting service, который выполняет courier-service при создании курьера:

POST /api/v1/user-status Запрос: { "name":"Denis", "surname":"Kulikov", "passport_serial":"5435", "passport_number":"7655" } Ответ: {"status":"ACTIVE"}

Запрос в car service, который выполняет courier-service при создании курьера:

GRPC CarService.GetDriveLicense Запрос: { "drive_license_serial":"7544", "drive_license_number":"3536" } Ответ: {"status":"ACTIVE_DRIVE_LICENSE_STATUS"}

Появившиеся записи в таблице couriers:

[ { "name":"Denis", "surname":"Kulikov", "drive_license_number":3536, "drive_license_serial":7544, "passport_number":7655, "passport_serial":5435, "phone":"24235345", "type":"CAR", "vehilce_id":100 } ]

Появившиеся сообщения в топике couriers.upd

[ { "id": 12, "name": "Denis", "surname": "Kulikov", "courier_type": "CAR_COURIER_TYPE", "drive_license": { "number": "3536", "serial": "7544" }, "passport": { "number": "7655", "serial": "5435" }, "phone": "24235345", "vehilce_id": "100", "updated_at": "2025-09-21T18:33:02", "created_at": "2025-09-21T18:33:02" } ]

Пример выполнения grpc запроса GetCourier

Здесь не буду вдаваться в подробности, логика достаточно очевидна, по схеме ясно, что сервис просто достает нужного курьера по id из таблицы couriers.

Пример консюма топика vehicles.upd

Здесь тоже не буду вдаваться в подробности, по схеме ясно, что консюмер при получении нового сообщения сохраняет новое транспортное средство в таблицу vehicles.

Тестовый стенд

Начнем с того, что для комфортного тестирования нужен изолированный тестовый стенд, то есть для каждой отдельной тестируемой версии приложения нужен отдельно задеплоенный сервис и зависимости, к которым имеет доступ только сервис. Если мы используем k8s, то в случае нашего courier-service необходим отдельный namespace courier-service-stable-stage, в котором развернут courier-service, postgresql, kafka и моки внешних сервисов, для моков я использую smocker и gripmock. Так же для каждого отдельного релиза или фичи нужен отдельный namespace с тестируемым сервисом (пр-р: courier-service-stage-release-2.2.1). Все дальнейшие предложения будут вестись в рамках того, что мы тестируем сервис в изолированном тестовом стенде.

myuser@MacBook-Pro ~ % kubectl get pods -n courier-service-stable-stage NAMESPACE NAME READY STATUS RESTARTS AGE default courier-service-74c9cfv-vkjfg 1/1 Running 0 3h18m default postgresql-74c9cfv-jhgkd 1/1 Running 0 3h18m default kafka-74c9cfv-koled 1/1 Running 0 3h18m default smocker-74c9cfv-nnjfd 1/1 Running 0 3h18m default gripmock-74c9cfv-lleod 1/1 Running 0 3h18m

Приложение stand-manager (раздел Service)

В этой главе я поделюсь разработанным приложением StandManager, которое отвечает за управление тестовыми стендами. Предполагается, что для каждого отдельного сервиса будет задеплоен отдельный stand-manager, который будет управлять всеми версиями стендов сервиса.

На рисунке представлен пример стенда Courier Service Stand Stable, это стенд стабильной версии приложения. В основном блоке указана ссылка на репозиторий проекта, ниже представлена схема сервиса со всеми компонентами сервиса courier-service, справа есть кнопка, с помощью которой можно добавлять новые компоненты. При нажатии на компонент открываются его настройки, в которых указываются необходимые креды, хосты, пути к контрактам в репозитории кода. Например, в настройках компонента kafkaproducer с названием couriers_data можно добавить информацию о kafka брокерах, креды, название топика и путь к proto контракту в репозитории кода - meta/contracts/events/courier/courier.proto. При нажатии кнопки reindex происходит проверка корректности параметров компонентов и генерация мета информации, которая понадобится в следующих разделах приложения.

Ниже представлен следующий раздел приложения API Examples & Contracts. В этом разделе представлена информация о всех АПИ приложения и о контрактах всех компонентов. На рисунке представлено grpc API компонента courier_service_front, который имеет 2 метода - CreateCourier и GetCourier, также представлены примеры контрактов, сериализованных в json. Все контракты сервиса сериализованы в json для удобства читаемости.

Примеры контрактов таблиц couriers и vehicles компонента postgres_db.

Ниже представлено grpc АПИ компонента car_service.

Следующий раздел приложения - Debug. Данный раздел позволяет дебажить запросы АПИ приложения в рамках тестового стенда. Слева представлены доступные шаги для дебага, шаги позволяют делать запросы в postgresql, писать и читать сообщения из kafka, мокать мок сервера, делать http и grpc запросы.

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

После нажатия кнопки Execute приложение выполнит запросы к тестовому стенду и автоматически добавит шаги с проверкой изменений состояний хранилищ. В данном случае добавится шаг checkPostgresqlTablesDiff, в котором есть информация о том, что после консюма сообщения в таблице vehicles добавилась новая запись - {"ID":100500,"Name":"BWM","Type":"CAR", "CreatedAt":"2025-09-21T21:34:03.136398+00:00","UpdatedAt":"2025-09-21T21:34:03.136398+00:00"}. Также ниже появится trace каждого шага дебага с временной меткой и подробной информацией.

Данный раздел позволяет дебажить любые запросы к АПИ и автоматически фиксировать все изменения стенда и ответы АПИ.

Что происходит под капотом?

Приложение stand-manager имеет бэкенд - stand-manager-generator (generator). При построении схемы сервиса в разделе Stand Service Visualization generator составляет json контракт сервиса с конфигурацией каждого компонента и хранит данные в бд. Пример json контракта сервиса ниже.

{ "name": "CourierService", "dependencies": [ { "postgresqlDependency": { "name": "postgres_db", "host": "localhost", "port": "5432", "user": "postgres", ... }, "kafkaProducerDependency": { "name": "couriers_data", "brokers": ["localhost:29092"], "topicName": "courier.upd", "contractPath": "meta/contracts/events/courier/courier.proto", ... }, ...

Также generator проверяет доступ к зависимостям и сервису стенда, собирает информацию об АПИ сервиса, генерит примеры запросов и контрактов, сохраняет мета информацию о сервисе для дальнейших шагов. Сгенеренные данные об АПИ и контрактах отображаются в разделе API Examples & Contracts.
В разделе Debug generator так же собирает json контракт из представленных действий, пример контракта c кейсом создания транспортного средства ниже.

{ "steps": [ { "postgresqlStepExec": { "depName": "postgres_db", "index": 1, "query": "truncate vehicles restart identity cascade" } }, { "kafkaConsumerStepSendMessages": { "depName": "vehicles_data", "index": 2, "messages": [ { "serializedBody": "{\"id\":\"100500\",\"name\":\"BWM\", \"vehicle_type\":\"CAR_VEHICLE_TYPE\"}" } ] } }, ...

После нажатия кнопки Execute generator генерит из шагов дебага и схемы сервиса golang скрипт, который выполняет все заданные шаги, фиксирует ответы и изменения состояний хранилищ. Финальный результат дебага отображается в Scenario Sequence. Если в бд появились новые записи или в kafka появились новые сообщения, в Scenario Sequence появляются дополнительные шаги, также вся подробная информация отображается в Execution Trace.

Приложение stand-manager (раздел HumanQA)

Прежде чем переходить к разбору следующего раздела stand-manager необходимо определиться и зафиксировать задачу тестирования. Если говорить в общем, задача тестирования сводится к проверке корректности выполнения бизнес логики сервиса. Можно разделить компоненты сервиса на несколько групп: входные точки(апи), хранилища, внешние сервисы. Исходя из такого разделения можно обозначать техническую задачу тестирования как следующие этапы:

1. Подготовка состояний хранилищ и зависимостей

2. Вызов АПИ с определенными входными параметрами

3. Фиксация ответа АПИ и оценка результатов

4. Фиксация изменений состояния хранилища и оценка результатов Набор таких кейсов позволит проверить всю бизнес логику сервиса.

Давайте разберем реализацию конкретного тестового кейса courier-service в stand-manager. Разберем тестовый кейс создания курьера с помощью grpc метода CreateCourier. Ниже представлена вкладка HumanQA, в разделе Test Groups хранятся все группы тестов сервиса, в разделе Execution History хранится история всех запусков тестов, справа в разделе Tests показаны все тесты группы create_courier_grpc, в тестовой группе один тест create_valid_courier. Также можно увидеть кнопки для копирования тестов из других групп и стендов, кнопка добавления новых тестов и кнопки запусков тестов.

Ниже представлены шаги тест кейса create_valid_courier. В соответствии с этапами обозначенными выше шаги 1-7 реализуют подготовку состояний хранилищ и зависимостей. А именно производится подготовка мок серверов, очистка баз данных и запись в таблицу vehicles транспортного средства, которое понадобится при создании курьера. Шаг 8 реализует вызов АПИ метода CreateCourier и валидацию ответа, ожидаемое тело ответа представлено в поле serializedExpectedResponse. В serializedExpectedResponse специально пропущены поля id, updated_at, created_at, так как эти поля будут иметь нестабильные значения. Шаги 9-10 реализуют фиксацию изменений состояния хранилища и оценку результатов. А именно шаг 9 получает сообщения из топика, в который пишет компонент сервиса couriers_data, ожидаемое сообщение для валидации представлено в поле expectedSerializedBodyArray. Шаг 10 реализует чтение всех записей из таблицы couriers, ожидаемые записи для валидации представлены в поле expectedSerializedBodyArray.

Также приложение позволяет дебажить тесты по принципу, который был представлен во вкладке Service/Debug, то есть достаточно написать шаги 1-8, запустить дебаг, и приложение автоматически добавить шаг с валидацией ответа АПИ и шаги с валидацией новых сообщений в топике и записей в бд (шаги 8-10).
При нажатии кнопки Execute происходит выполнение теста, результат которого - trace с подробной информацией каждого шага.

Что происходит под капотом?

Реализация процесса тестирования схожа с процессом дебага, который мы разбирали в предыдущей главе. Каждая группа тестов представлена в виде json контрактов и хранится в бд. При запуске или дебаге тестов stand-manager-generator генерит из конфигов тестовых групп и схемы сервиса golang приложение, которое реализует шаги взаимодействия с тестовым стендом и сохраняет результат выполнения тест кейсов.

Приложение stand-manager (раздел AIAgentQA)

Прежде чем переходить к разбору следующего раздела stand-manager важно зафиксировать возможности приложения, которые есть на данный момент. Фактически процесс тестирования сводится к подбору определенных шагов взаимодействия с АПИ и зависимостями сервиса с различными параметрами. Такой подход подготавливает идеальную базу для тестирования сервиса с помощью ИИ. А именно уменьшается вариативность такой неопределенной задачи для ИИ как покрытие кода тестами. ИИ уже имеет подробную спецификацию сервиса и зависимостей в виде json контрактов, также ИИ имеет инструмент в виде stand-manager-generator, который предоставляет строгое АПИ для формирования и выполнения тест кейсов. В итоге, финальная задача для ИИ упрощается, минимизируется и формализуется. В работе ИИ агента есть еще несколько важных особенностей, о которых поговорим позже.

Переходим к разделу AIAgentQA. Данный раздел похож на раздел HumanQA, только процесс формирования и выполнения тестов происходит через диалоговое окно с помощью ии-агента. В разделе Test Groups представлены 3 тестовые группы, которые были сгенерены с помощью агента. Выбранная тестовая группа get_courier_grpc была сформирована ии-агентом по запросу "сгенери тестовую группу с 3-мя тестами для grpc метода GetCourier". Флоу работы с тестами точно такой же как в разделе HumanQA, можно выполнять тесты в тестовой группе полностью или по отдельности, результат выводится в виде трейса, все запуски тестов с результатами хранятся во вкладке ExecutionHistory. ИИ-агент имеет доступ ко всем тестовым группам и истории выполнения тестов, так что агент может формировать, исполнять тесты и анализировать результаты выполнения. Так же ии-агент имеет доступ к тестам других тестовых стендов, это может быть актуально для выполнения регресс тестов на релизной версии приложения.

Ниже представлены запросы и результат выполнения агента.

Что происходит под капотом?

Ниже представлена схема Stand Manager. Главный компонент, через который происходит взаимодействие пользователя с системой - Stand Manager Frontend. Фронтенд по запросу пользователей общается со Stand Manager Generator, который отвечает за выполнение всех тест кейсов и дебаг на тестовом стенде. В файловой системе хранится код репозитория, который необходим для сбора мета информации об АПИ и контрактах сервиса.

В текущей главе нас больше всего интересует флоу работы Stand Manager через ии-агента. ИИ-агент имеет системный промт, в котором изложена вся информация о задаче агента и инструментах для ее решения. У ии-агента есть 3 основных инструмента, работа с которыми позволит выполнять задачи QA. А именно Stand Manager Generator, взаимодействие с которым позволяет получать всю информацию о сервисе и его зависимостях, дебажить и выполнять тест кейсы на тестовом стенде. Вторым инструментом является Code Analysis AI Agent, технически это очень урезанный аналог cursor, который может читать код проекта, анализировать его и предоставлять информацию о выполнении кода. Третьим инструментом агента является LLM, которая позволяет решать все смежные задачи агента.

Важной особенностью агента является следующий механизм: генерация тест кейсов происходит на основе информации о выполнении различных строк кода, которые в итоге формируют бизнес логику сервиса. Рассмотрим подробнее. С помощью Code Analysis AI Agent код проекта размечается на кейсы выполнения строк кода, пример представлен ниже. В данном случае представлен один из вариантов выполнения кода в обработчике grpc метода CreateCourier. Фактически данный контракт демонстрирует построчный дебаг выполнения кода в обработчике. Code Analysis AI Agent размечает весь код проекта по данному принципу и сохраняет его в json файле. В результате задачи AI Agent QA по генерации тестов сводятся к анализу разметки и подбору определенных входных параметров для АПИ и зависимостей для выполнения нужных строк кода. Построчная разметка выполнения кода является ключевым вспомогательным компонентом для работы AI Agent QA.

{ "case_idx": 2, "entry_point": "/internal/handlers/grpc/server.go", "func_name": "CreateCourier", "lines": [ { "file_path": "/internal/handlers/grpc/server.go", "line_numbers": { "start": 27, "end": 31 } }, { "file_path": "/internal/service/courier/service.go", "line_numbers": { "start": 41, "end": 42 } }, { "file_path": "/internal/service/courier/service.go", "line_numbers": { "start": 97, "end": 97 } }, { "file_path": "/internal/repository/vehicle/vehicle.go", "line_numbers": { "start": 25, "end": 37, "return_line": 37 } }, { "file_path": "/internal/service/courier/service.go", "line_numbers": { "start": 98, "end": 99, "return_line": 99 } }, { "file_path": "/internal/service/courier/service.go", "line_numbers": { "start": 43, "end": 44, "return_line": 44 } }, { "file_path": "/internal/handlers/grpc/server.go", "line_numbers": { "start": 32, "end": 39, "return_line": 39 } } ] }

Рассмотрим поэтапное выполнение простой задачи ии-агента с примерами. Этапы работы ии-агента при выполнении запроса "Напиши тесты на grpc метод CreateCourier":

• Считать и проанализировать схему тестового стенда, получить информацию об АПИ и контрактах сервиса и зависимостей.

• В разметке выполнения кода найти все кейсы для обработчика grpc метода CreateCourier

• Написать тест для каждого кейса в разметке Дальше будем рассматривать разработку теста для кейса в разметке, представленного ниже. Суть данного кейса заключается в создании курьера с транспортным средством, которого нет в таблице vehicles.

{ "case_idx": 2, "entry_point": "/internal/handlers/grpc/server.go", "func_name": "CreateCourier", "lines": [ { "file_path": "/internal/handlers/grpc/server.go", "line_numbers": { "start": 27, "end": 31 } }, { "file_path": "/internal/service/courier/service.go", "line_numbers": { "start": 41, "end": 42 } }, { "file_path": "/internal/service/courier/service.go", "line_numbers": { "start": 97, "end": 97 } }, { "file_path": "/internal/repository/vehicle/vehicle.go", "line_numbers": { "start": 25, "end": 37, "return_line": 37 } }, { "file_path": "/internal/service/courier/service.go", "line_numbers": { "start": 98, "end": 99, "return_line": 99 } }, { "file_path": "/internal/service/courier/service.go", "line_numbers": { "start": 43, "end": 44, "return_line": 44 } }, { "file_path": "/internal/handlers/grpc/server.go", "line_numbers": { "start": 32, "end": 39, "return_line": 39 } } ] }

• Проанализировать зависимости и АПИ сервиса, дополнить каждый фрагмент кода небольшим описанием(поле description) с помощью LLM. Пример ниже.

{ "case_idx": 2, "case_name": "vehicle not found", "entry_point": "/internal/handlers/grpc/server.go", "func_name": "CreateCourier", "lines": [ ... { "file_path": "/internal/service/courier/service.go", "line_numbers": { "start": 41, "end": 42 }, "description": "..." }, { "file_path": "/internal/repository/vehicle/vehicle.go", "line_numbers": { "start": 25, "end": 37, "return_line": 37 }, "description": "Выполнение SQL запроса к PostgreSQL для получения транспорта по ID, название зависимости - postgres_db, Использует библиотеку goqu для построения SQL запроса SELECT FROM vehicles WHERE id = ?. Выполняет запрос ..." }, ...

• Подобрать входные параметры для АПИ и запросы для зависимостей для выполнения строк кода(поле params) с помощью LLM. Пример ниже.

{ "case_idx": 2, "case_name": "vehicle not found", "entry_point": "/internal/handlers/grpc/server.go", "func_name": "CreateCourier", "lines": [ { "file_path": "/internal/handlers/grpc/server.go", "line_numbers": { "start": 27, "end": 31 }, "description": "...", "params": "gRPC запрос CreateCourier с ... {\"courier\": {\"name\":\"John\",\"surname\":\"Doe\", \"phone\":\"+1234567890\",\"passport\": {\"serial\":1234,\"number\":567890}, \"drive_license\":{\"serial\":0,\"number\":0}, \"courier_type\":2, \"vehilce_id\":99999}}" }, ... { "file_path": "/internal/repository/vehicle/vehicle.go", "line_numbers": { "start": 25, "end": 37, "return_line": 37 }, "description": "...", "params": "Перед вызовом API необходимо выполнить DELETE запрос к PostgreSQL для удаления транспорта с id=99999 из таблицы vehicles, чтобы запрос SELECT вернул ErrNotFound. SQL запрос: DELETE FROM vehicles WHERE id = 99999; Альтернативно можно очистить всю таблицу: DELETE FROM vehicles; ..." }, ...

• Дебаг предложенного варианта входных параметров. В случае несостыковок, выполнить шаг 5 еще раз.

• Собрать все условия выполнения кода (входные параметры, запросы в БД...). Сгенерить с помощью LLM action.json на основе файла с условиями выполнения кода для последующего выполнения в Stand Manager Generator. Пример ниже. LLM сгенерила тест кейс с 2-мя шагами. Первый шаг удаляет из таблицы vehicles транспортное средство с id 99999. Вторым шагом происходит создание курьера с vehilce_id 99999.

[ { "actions_group_name": "debug_case_2", "actions": [ { "name": "vehicle_not_found", "steps": [ { "postgresqlStepExec": { "depName": "postgres_db", "index": 1, "query": "DELETE FROM vehicles WHERE id = 99999;" } }, { "appStepMakeGrpcRequest": { "depName": "courier_service_api", "index": 2, "service": "CourierService", "method": "CreateCourier", "serializedRequest": "{\"courier\":{ \"name\":\"John\",\"surname\":\"Doe\", \"phone\":\"+1234567890\",\"passport\": {\"serial\":1234,\"number\":567890}, \"drive_license\":{\"serial\":0,\"number\":0}, \"courier_type\":2,\"vehilce_id\":99999}}" } } ] } ] } ]

• Выполнить предложенный тест в режиме debug с помощью Stand Manager Generator. Результат выполнения ниже (добавлена дополнительная валидация ошибки "rpc error: code = InvalidArgument desc = vehicle not found"). В итоге получился тест кейс, при выполнении которого метод CreateCourier возвращает ошибку при создании курьера.

[ { "actions_group_name": "debug_case_2", "actions": [ { "name": "vehicle_not_found", "steps": [ { "postgresqlStepExec": { "depName": "postgres_db", "index": 1, "query": "DELETE FROM vehicles WHERE id = 99999;" } }, { "appStepMakeGrpcRequest": { "depName": "courier_service_api", "index": 2, "service": "CourierService", "method": "CreateCourier", "serializedRequest": "{\"courier\":{ \"name\":\"John\",\"surname\":\"Doe\", \"phone\":\"+1234567890\",\"passport\": {\"serial\":1234,\"number\":567890}, \"drive_license\":{\"serial\":0,\"number\":0}, \"courier_type\":2,\"vehilce_id\":99999}}" }, "expectedError": "rpc error: code = InvalidArgument desc = vehicle not found" } } ] } ] } ]

• Сохранить тест кейс. Ниже представлен сгенеренный тест кейс во вкладке AIAgentQA.

• Перейти к следующему кейсу разметки.

  Результатом выполнения данной задачи ии-агента будет набор тест кейсов для grpc метода CreateCourier. Важной особенностью данного подхода является то, что ии-агенту не нужно понимать всю бизнес логику сервиса, ии-агент решает обратную задачу. Он подбирает шаги теста исходя из выполнения строк кода, набор таких тестов в итоге покроет всю бизнес логику сервиса.

Заключение

В этой статье я представил концепцию многофункционального тестового стенда, предназначенного для эффективного и качественного решения любых задач тестирования бэкенда. Это решение позволяет создавать, запускать, отлаживать и хранить тестовые сценарии для сервиса без необходимости заботиться о инфраструктуре, контрактах API и других характеристиках сервиса. Важным преимуществом приложения является автономный ии-агент QA, который может решать до 85% задач тестировщика и в перспективе может полноценно заменить QA в команде разработки бэкенда. Также есть множество идей по развитию приложения, которые необходимо исследовать: объединение тестовых стендов нескольких сервисов для межсервисного тестирования, интеграция с системами CI/CD и корпоративными мессенджерами, а также поддержка работы с новыми зависимостями, такими как redis, cassandra, mysql и тд.

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