Архитектура системы из 11 AI-агентов для автоматизации тестирования: подробный кейс

Когда тестировщики проигрывают марафон нейросетям

Вспомните статью про то, как AI-агенты генерируют код быстрее, чем вы успеваете его проверить. Картина знакомая: продакт толкает на скорость, инженеры жмут на кнопку "генерировать", а через неделю команда QA тонет в регрессионных тестах. Одна сборка в день - это уже архаизм. Сейчас норма - десятки микросервисов, обновляющихся параллельно.

Классические автотесты здесь ломаются. Они хрупкие, их дорого поддерживать, и они не умеют думать. Нужен другой подход - не набор скриптов, а автономная система, которая сама решает, что тестировать. Я построил такую. 11 AI-агентов, которые заменили 8 тестировщиков в одном из наших продуктовых отделов. Вот как это работает изнутри.

Одиннадцать специалистов вместо одного универсала

Главная ошибка - пытаться создать одного "супер-агента", который умеет все. Он становится монолитом, его сложно поддерживать, и он постоянно путается в контексте. Я пошел другим путем - разделил процесс тестирования на узкие экспертные роли. Каждый агент делает одно дело, но делает его идеально.

Да, 11 агентов звучит как overengineering. Но это только до тех пор, пока вы не увидите, как они работают вместе. Скаут обнаружил изменение в платежном модуле. Архитектор нашел 3 зависимых сервиса. Сценарист придумал 12 пользовательских сценариев (включая краевые случаи). Кодер написал тесты. Рецензент нашел утечку памяти в одном из тестов. Все это заняло 4 минуты. Человек бы потратил 2 дня.

1 С чего начинается хаос: триггер пайплайна

Система запускается от любого события - коммит в GitLab, MR, обновление спецификации в Swagger, даже комментарий в Jira. Главный триггер - это все-таки коммит. Агент Скаут получает diff через вебхук. Он не просто смотрит на измененные файлы. Он анализирует семантику изменений.

# Упрощенная логика агента Скаут (на основе Claude 3.7 Sonnet)
async def analyze_commit_diff(diff_text: str, commit_message: str):
    prompt = f"""
    Ты - senior security researcher. Анализируй git diff.
    Изменения: {diff_text[:5000]}
    Сообщение коммита: {commit_message}
    
    Определи:
    1. Какие модули затронуты (оцени важность от 1 до 10)
    2. Риск регрессии (низкий/средний/высокий)
    3. Нужны ли специфические тесты (API, UI, нагрузка)
    """
    # Вызов Claude через API
    response = await claude_client.complete(prompt)
    return parse_risk_assessment(response)

Скаут передает отчет Архитектору. Тот уже лезет в базу знаний - Confluence, Figma, старые тест-кейсы. Он строит граф: "Изменен метод process_payment в billing_service. От него зависят notification_service, analytics_dashboard и mobile_app версии выше 4.2". Это тот самый контекст, который теряют обычные автотесты.

2 Самая сложная часть: генерация сценариев, которые не придут в голову человеку

Агент Сценарист получает от Архитектора граф зависимостей и техзадание. Его задача - придумать неочевидные сценарии. Не просто "оплата проходит", а "оплата проходит, когда у пользователя ровно 3 активных подписки, время 23:59 UTC, а на счету ровно сумма покупки + 1 цент".

Здесь мы используем технику из мультиагентной системы SAARAM, но доработанную. Сценарист работает в три итерации: генерирует 20 базовых сценариев, затем критикует их сам (внутренний диалог), затем усиливает краевые случаи.

# Промпт для генерации краевых случаев (DeepSeek Coder-V3)
scenario_prompt = """
Ты - тестировщик с 15-летним опытом. Ты специализируешься на поиске багов в платежных системах.

Основной сценарий: пользователь оплачивает подписку через кредитную карту.

Сгенерируй 5 краевых случаев, которые:
1. Редко возникают в продакшене
2. Часто ломают логику
3. Связаны с временными зонами, валютой, сетевыми проблемами
4. Включают специфические данные (карта с истекшим сроком, но валидным CVV)

Формат: JSON список с полями title, steps, expected_result.
"""

Интеграции, которые превращают агентов в часть команды

Агенты живут не в вакууме. Они должны работать с тем же стеком, что и люди. Иначе вы получите еще одну изолированную систему, которую нужно отдельно поддерживать.

Jira: Баг-репорты, которые не стыдно показать менеджеру

Агент Документатор - это наше ноу-хау. Когда тест падает, он не просто пишет "AssertionError". Он создает полноценный баг-репорт: шаги воспроизведения, логи, скриншоты (если это UI), ожидаемый и фактический результат. И самое главное - он предлагает возможную причину. Не гадает, а анализирует стектрейс и изменения в коде.

# Автоматическое создание задачи в Jira через API
async def create_jira_issue(test_failure_data):
    issue_data = {
        "fields": {
            "project": {"key": "QA"},
            "summary": f"[AI-Test] {test_failure_data['component']}: {test_failure_data['error']}",
            "description": agent_documentator.generate_description(test_failure_data),
            "issuetype": {"name": "Bug"},
            "priority": {"name": agent_documentator.assess_priority(test_failure_data)},
            "labels": ["ai-generated", "autotest"]
        }
    }
    # Jira автоматически назначает задачу на тимлида QA
    response = await jira_client.create_issue(issue_data)
    return response

Figma: Визуальное тестирование без селекторов

Агент Визуал берет скриншоты из Figma (ожидаемый дизайн) и скриншоты работающего приложения (фактический результат). Он не сравнивает пиксели - он сравнивает семантику. Кнопка сместилась на 5 пикселей? Это может быть не страшно. Но если кнопка "Удалить аккаунт" стала выглядеть как "Сохранить" - это критично.

Мы используем дообученную Vision модель, которая понимает UI-контекст. Она знает, что чекбокс и радиокнопка - это интерактивные элементы, а логотип - нет. Это решает проблему, описанную в статье Почему GUI-агенты ломаются на чекбоксах.

GitLab: Пул-реквесты с готовыми тестами

Система мониторит создание MR. Если в MR нет тестов, агент Кодер может предложить сгенерировать их. Он анализирует код, понимает, что тестировать, и создает тесты прямо в ветке разработчика. Разработчик видит в MR комментарий: "AI-agent добавил 3 unit-теста для нового метода validate_payment. Проверь и добавь, если нужно".

Цифры, которые заставят финансового директора улыбнуться

Без метрик все это просто игрушка. Вот что система показывает после 6 месяцев работы:

• Время на регрессионное тестирование: с 14 часов до 47 минут (среднее по продукту)
• Покрытие кода тестами: с 62% до 89% (агент нашел код, который никогда не тестировался)
• Баги в продакшене: снижение на 73% (критические баги - на 91%)
• Стоимость одного тест-кейса: с ~$50 (оценка труда QA) до ~$0.30 (стоимость инференса моделей)
• False-positive срабатывания: 4.2% (ниже, чем у многих human QA)

Как внедрить такое без полугода миграции

Не нужно пытаться построить все 11 агентов сразу. Это гарантированный провал. Начните с трех, как описано в статье Как построить самообучающегося ИИ-агента.

1 Фаза 1: Скаут + Кодер + Рецензент (8 недель)

Сфокусируйтесь на unit-тестах. Настройте Скаута на анализ коммитов. Пусть Кодер пишет простые тесты для новых функций. Рецензент проверяет качество. Уже это даст 30% покрытия там, где его не было.

2 Фаза 2: Добавляем Архитектора и Интегратора (6 недель)

Теперь система понимает зависимости между сервисами. Может тестировать API-контракты и находить проблемы интеграции.

3 Фаза 3: Полный цикл с UI и обратной связью (10 недель)

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

Ошибки, которые совершат 90% команд (и как их избежать)

• Ошибка: дать агентам прямой доступ к продакшен-базам данных. Решение: всегда работайте через зеркала данных или снэпшоты. Агент Кодер однажды сгенерировал тест, который запустил DELETE FROM users WHERE id=1. Хорошо, что это была тестовая база.
• Ошибка: использовать одну LLM для всех агентов. Решение: подбирайте модель под задачу. Для кодогенерации - CodeLlama или DeepSeek Coder. Для анализа текста - Claude. Для классификации изображений - специализированные Vision-модели. Экономия на этом выйдет боком.
• Ошибка: игнорировать стоимость инференса. Решение: кэшируйте ответы моделей. Если агент Сценарист уже генерировал тесты для "оплаты кредитной картой", не заставляйте его делать это снова. Создайте векторную базу похожих сценариев.
• Ошибка: не настраивать human-in-the-loop. Решение: всегда оставляйте кнопку "остановить". Агент Аналитик должен показывать отчеты человеку. Иначе вы можете получить 500 автоматических баг-репортов из-за одного сломанного эндпоинта.

Что будет дальше? Агенты, которые тестируют друг друга

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

Самое интересное - это когда вся цепочка от ТЗ до продакшена будет покрыта автономными агентами. Один агент пишет код, второй тестирует, третий деплоит, четвертый мониторит. И где-то в этом цикле есть один человек, который просто смотрит на графики и пьет кофе. Или пишет статьи в блог.

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

Подписаться на канал