Представьте: каждый день ваши автотесты генерируют десятки отчетов об ошибках, QA команда тратит часы на анализ падений, а разработчики получают невразумительные описания в духе "test.feature упал на строке 410". Знакомо?
Мы решили эту проблему, интегрировав AI в процесс анализа тестов, и хотим поделиться опытом.
Проблема: хаос в анализе упавших тестов
В нашем проекте работает комплексная тестовая инфраструктура:
8 параллельных потоков выполнения
650+ автотестов на Cucumber
Ежедневные прогоны с анализом регрессий
Типичный workflow до автоматизации:
Тесты упали → HTML отчет с кучей технических деталей
QA анализирует каждое падение вручную
Создает отчет для разработчиков: "найди строку в step_definitions, посмотри стек, угадай что сломалось"
Разработчик тратит еще время на понимание проблемы
Боль реальная:
🔍 Нет структурированного анализа — каждый отчет уникален
⏰ Огромные временные затраты QA — от 1 до 3 часов на анализ отчетов
📊 Нет приоритизации ошибок — все падения выглядят одинаково критично
Решение: AI как второй тестировщик
Мы решили создать AI помощника, который будет анализировать упавшие тесты и создавать структурированные отчеты в том формате, который понятен разработчикам.
Идея простая: машина делает рутинную работу по анализу технических логов, а человек принимает решения на основе качественных данных.
Архитектура решения
Компоненты системы:
generate_test_failure_report.sh— анализ отчетов и извлечение данныхamp_chat.sh— интеграция с Sourcegraph Amp AIentrypoint.sh— оркестрация всего процессаAGENT.md— основное руководство для AI с правилами проектаCRITICAL_RULES.md— критические правила для обучения AI
Workflow автоматизации:
Тесты упали → HTML отчет → Python парсер → detailed_steps.txt → AI анализ → Структурированный отчет для GitLab
Техническая реализация
1. Интеллектуальный парсер отчетов
Первая задача — извлечь структурированные данные из HTML отчетов Cucumber. Мы создали Python скрипт, который:
# Парсит JSON данные из Cucumber Messages data = json.load(html_embedded_json) failed_tests = extract_failed_scenarios(data) # Анализирует ReRun данные для исключения ложных срабатываний rerun_passed = filter_successful_reruns(rerun_html) real_failures = exclude_false_positives(failed_tests, rerun_passed)
Ключевая фишка: скрипт умеет различать "действительно проблемные тесты" от "случайных падений".
Если тест упал первоначально, но прошел в ReRun — это не настоящая проблема.
2. AI интеграция через Sourcegraph Amp
Для AI анализа использовали Sourcegraph Amp — специализированный AI-инструмент для разработчиков.
Что такое Amp:
AI-powered coding assistant с доступом к лучшим языковым моделям
Неограниченное использование токенов — можем анализировать большие отчеты
Мощный CLI для автоматизации в скриптах и CI/CD
Поддержка кастомных инструментов через AGENT.md файлы
Oracle режим для сложного анализа и рассуждений
Ключевое преимущество — Amp создан именно для технических задач, понимает контекст кода и может работать в неинтерактивном режиме.
Создали обертку amp_chat.sh для взаимодействия с AI:
#!/bin/bash # Неинтерактивный режим для автоматизации echo "$ai_prompt" | ./amp_chat.sh # С защитой от зависания timeout 10m ./amp_chat.sh < detailed_steps.txt
AI промпт инженеринг:
Разработали систему критических правил для AI, чтобы получать качественные отчеты:
создай отчет об ошибках detailed_steps.txt учитывая все правила из AGENT.md с выполнением КРИТИЧЕСКИХ ПРАВИЛ, затем проверь выполнение всех КРИТИЧЕСКИХ ПРАВИЛ и выполни все правила из CRITICAL_RULES.md
3. Интеграция в CI/CD
Встроили AI анализ прямо в entrypoint.sh — главную точку входа тестовой системы.
Два способа запуска AI анализа:
# 1. Автоматический - запускается в ночных и вечерних прогонах case $exec in "gcp-app-testing") # ... обычный workflow тестирования make_report publish_reports # 🤖 AI анализ включается автоматически if [ "$ENABLE_AI_REPORTS" = "true" ]; then generate_failure_report fi ;; # 2. Ручной - для анализа существующих отчетов "failure-report") clear_test_reports generate_failure_report # Анализ последнего отчета с стенда ;; esac
⚡ Оптимизация для больших отчетов
Обнаружили что AI "залипает" на отчетах с 50+ упавшими тестами. Добавили лимитирование:
MAX_TESTS_IN_REPORT = 30 if len(failed_tests) > MAX_TESTS_IN_REPORT: print(f"⚠️ Найдено {len(failed_tests)} упавших тестов, " f"но отчет будет создан только для первых {MAX_TESTS_IN_REPORT}") failed_tests = failed_tests[:MAX_TESTS_IN_REPORT]
Критические правила для AI
Самая важная часть — научить AI создавать качественные отчеты.
Создали файл CRITICAL_RULES.md с обязательными правилами:
🚨 Правило 1: Правильные номера строк
КРИТИЧЕСКИ ВАЖНО: ВСЕГДА ИСПОЛЬЗОВАТЬ НОМЕР СТРОКИ СЦЕНАРИЯ (Scenario:), А НЕ ОТДЕЛЬНОГО ШАГА ❌ features/entrypoint.sh --exec features --feature test.feature:410 # Номер ошибки ✅ features/entrypoint.sh --exec features --feature test.feature:6 # Номер Scenario:
🚨 Правило 2: Визуальные доказательства
ОБЯЗАТЕЛЬНО анализировать: - Скриншоты ошибок из tmp/test_reports/assets/<стенд>_<дата>/error/ - Логи консоли браузера из tmp/test_reports/assets/<стенд>_<дата>/logs/
🚨 Правило 3: Полнота охвата всех сценариев
КРИТИЧЕСКОЕ ПРАВИЛО: НИКОГДА НЕ ПРОПУСКАТЬ НИ ОДНОГО УПАВШЕГО СЦЕНАРИЯ - ОБЯЗАТЕЛЬНО правильно определить количество упавших - Смотреть на "🔴 Упали в ReRun: X сценариев", а НЕ на "Всего фич: Y, Упавших: Z" - НЕДОПУСТИМО описывать только часть сценариев (например, 5 из 7) - ОБЯЗАТЕЛЬНАЯ СТРУКТУРА каждого сценария: "УПАВШИЙ СЦЕНАРИЙ X: [название]"
🚨 Правило 4: Данные из буфера обмена
КРИТИЧЕСКИ ВАЖНО: ВСЕГДА указывать ВСЕ конкретные данные из буфера обмена - При упоминании "Paste bill data from clipboard" - показать таблицу данных - При упоминании "Paste value from Clipboard" - показать конкретное значение - ОБЯЗАТЕЛЬНО найти исходные данные в .feature файле между """ """ - Структурированное отображение по шагам с номерами строк
🚨 Правило 5: Убираем технические команды автотестов
КРИТИЧЕСКИ ВАЖНО убрать ВСЕ технические команды: ❌ "Wait X seconds" ❌ "Define hot table", "Определить таблицу" ✅ Заменять на пользовательские действия: - Авторизация с email и паролем - Клики по кнопкам и ссылкам - Ввод данных в поля
🚨 Правило 6: Приоритеты анализа ошибок
ПРИОРИТЕТ 1: Простые логические ошибки (= → ===, = → ||=) ПРИОРИТЕТ 2: Бизнес-логика (HOT таблицы, математические модели) ПРИОРИТЕТ 3: Сложные архитектурные решения НЕ предлагать общие исправления типа "добавить проверку на undefined" ИСКАТЬ РЕАЛЬНЫЕ ПРИЧИНЫ в специфике технологий
🚨 Правило 7: Структура шагов воспроизведения
ОБЯЗАТЕЛЬНАЯ СТРУКТУРА: Ключевые шаги (10-15) + Детальные шаги (40-80) - НИКОГДА не отходить от этой структуры - Группировать действия по логическим разделам - Указывать пароли при авторизации - Пустая строка после каждого заголовка группы действий
🚨 Правило 8: Анализ корневых причин
ИЗБЕГАТЬ ПОВЕРХНОСТНОГО АНАЛИЗА JAVASCRIPT ОШИБОК ❌ "JavaScript ошибка Cannot read properties of undefined - добавить проверку" ✅ "При сохранении Submission price не обновляются данные в модели индиректов" ❌ "Ошибка в HOT таблице - проверить инициализацию" ✅ "HOT таблица использует loadData() вместо updateData() - перезапись данных"
🚨Правило 9: MARKDOWN ФОРМАТИРОВАНИЕ ТАБЛИЦ
- ОБЯЗАТЕЛЬНО использовать правильный синтаксис: `| Поле | Значение |` - ОБЯЗАТЕЛЬНО добавлять разделители заголовков: `|------|----------|` - ОБЯЗАТЕЛЬНО выравнивать колонки с `|` - ОБЯЗАТЕЛЬНО добавлять пустые строки до и после таблиц
Результаты: цифры говорят сами за себя
Показатель | До AI | После AI |
|---|---|---|
Время анализа отчета | 1-3 часа | 5-10 минут |
Качество описания ошибок | Неструктурированное | Структурированное с кодом |
Конкретные советы по исправлению | Редко | Всегда |
Пример экономии времени:
Раньше: QA тратил от 1 до 3 часов на анализ → разработчик еще час на понимание
Теперь: AI анализирует за 10 минут → разработчик сразу получает готовое решение
Пример AI отчета: от хаоса к структуре
Было (исходный технический лог)
Типичный вывод упавшего теста - набор технических терминов без контекста:
expected to find xpath "//h5[contains(.,"The connection between the BOQ rows from the bid and the project was not found. Would you like to try to find one?")]" but there were no matches
Проблемы каждой роли:
QA:
- Большие Gherkin сценарии на английском языке — уходит много времени на анализ и выделение ключевых шагов
- Нужно вручную извлечь короткие понятные шаги из длинного технического сценария — 30-60 минут на сценарий
- Перевод и адаптация шагов для программистов — 20-40 минут на каждый тест
Разработчик:
- Получает либо сырой стек ошибки, либо огромный Gherkin сценарий — уходит много времени на понимание сути проблемы
Стало (структурированный AI отчет)
AI анализирует тот же самый технический лог и создает подробный отчет:
УПАВШИЙ СЦЕНАРИЙ 1: "Save row values after cutting rows" КЛЮЧЕВЫЕ ШАГИ ВОСПРОИЗВЕДЕНИЯ: 1. Авторизация с пользователем test@user.ru 2. Переход на страницу редактирования заявки 3. Переход в раздел "Bill of quantity" 4. Заполнение HOT таблицы: номер "1.2.1", описание "Аренда оборудования" 5. Нажатие кнопки "Add BOQ from project" 6. ❌ Ожидание модального окна связывания строк проекта - окно не найдено (строка 32) ВИЗУАЛЬНЫЕ ДОКАЗАТЕЛЬСТВА AI анализирует скриншот момента ошибки и видит модальное окно "Add from project BOQ": - Заголовок окна: "Add from project BOQ" - Версия: "Using version #1 03.10.2019" - Выбранные элементы: 2 элемента отмечены галочками - Кнопки управления: "Close" и "Add" доступны ЛОГИ КОНСОЛИ БРАУЗЕРА: Обнаружены предупреждения JavaScript в момент выполнения теста: WARNING (устаревший API): Listener added for a 'DOMNodeInserted' mutation event. This event type is deprecated, and will be removed from this browser VERY soon. КОНКРЕТНЫЕ СОВЕТЫ ПРОГРАММИСТАМ: 1. FRONTEND: /modal_link_project_rows.js // Проблема может быть в логике определения необходимости показа модала Link project rows // Проверить условие, при котором модал должен появляться: if (connectionNotFound || !hasMatchingRows) { showLinkProjectRowsModal(); } else { // Переход напрямую к выбору BOQ - это и происходит в тесте showAddFromProjectBOQModal(); } КОРНЕВАЯ ПРИЧИНА: Изменение бизнес-логики отображения модального окна связывания строк BOQ. Система больше не показывает окно связывания в данном сценарии, вместо этого сразу отображается стандартное окно выбора элементов проекта.
Что изменилось:
- Контекст: вместо сухой ошибки - понятное описание бизнес-сценария
- Визуализация: анализ скриншотов показывает реальное состояние интерфейса
- Действенность: конкретный код для исправления вместо общих советов
- Диагностика: понятная корневая причина с техническим обоснованием
Такой отчет разработчик может сразу использовать для исправления, без дополнительного анализа.
Уроки и выводы
✅ Что сработало хорошо
1. Prompt Engineering критичен для качества
Без четких правил AI создавал общие отчеты. Система критических правил дала конкретные, действенные советы.
2. AI отлично понимает контекст тестов
Prompt с описанием бизнес-логики дает намного лучшие результаты чем просто стек ошибки.
3. Визуальные доказательства критичны
Скриншоты момента ошибки и логи консоли браузера дают AI полную картину для анализа.
⚠️ Подводные камни
1. AI может "зависать" на сложных отчетах
Решение: лимитирование количества тестов + timeout для AI запросов
2. Качество зависит от качества промптов
Решение: итеративная разработка системы правил с тестированием на реальных данных
3. Не все ошибки можно проанализировать автоматически
Решение: fallback на ручной анализ для критически важных случаев
Технические детали реализации
Парсинг Cucumber отчетов
def extract_failed_scenarios(cucumber_json): """Извлекает упавшие сценарии из Cucumber Messages""" failed_tests = [] for test_run in cucumber_json['testRunStarted']: for scenario in test_run['scenarios']: if scenario['status'] == 'FAILED': # Извлекаем детали ошибки error_info = { 'file': scenario['uri'], 'line': scenario['location']['line'], 'name': scenario['name'], 'error': scenario['steps'][-1]['result']['errorMessage'] } failed_tests.append(error_info) return failed_tests
AI промпт система
Создали многоуровневую систему правил:
AGENT.md— общие правила работы с проектомamp_script/CRITICAL_RULES.md— специфичные правила для анализа тестов
Интеграция в systemd сервисы
ExecStart=/bin/bash -c "features/entrypoint.sh --exec gcp-app-testing --TEST_SUITE test_suite_X" # В entrypoint.sh автоматически читаются переменные из environment_variables: # ENABLE_AI_REPORTS=true # TEST_SUITE=part # Логика включения AI анализа: case $exec in "gcp-app-testing") # ... обычный workflow тестирования make_report publish_reports # 🤖 AI анализ включается автоматически после основных отчетов if [ "$ENABLE_AI_REPORTS" = "true" ]; then generate_failure_report --stand $STAND --auto-ai fi ;; esac
Результат: трансформация процессов
📈 Для QA команды
Освобождено время для более важных задач
Автоматическая приоритизация ошибок по сложности исправления
💡 Для разработчиков
Конкретные советы вместо сырых логов — сразу понятно что и где исправлять
Понятные шаги воспроизведения на человеческом языке
Быстрое понимание корневой причины проблемы
🔄 Для процесса
Полная автоматизация — без ручного вмешательства
Стандартизированный формат отчетов
Встроено в существующую инфраструктуру без изменения workflow
Планы развития
Ближайшие планы:
GitLab интеграция — автоматическое создание тикетов с меткой
RegressionМашинное обучение — анализ паттернов ошибок для предсказания проблемных зон
Долгосрочная перспектива:
Автоматическое исправление простых ошибок через AI
Как запустить у себя
Настройка AMP API ключа:
mkdir -p ~/.config/amp echo "amp_sk_YOUR_KEY" > ~/.config/amp/api_key chmod 600 ~/.config/amp/api_key
Запуск с AI анализом:
features/entrypoint.sh --exec failure-report --stand <имя стенда>
Документация
Всю систему мы подробно задокументировали:
Wiki для тестировщиков с примерами использования
AGENT.md с техническими правилами
README файлы для каждого скрипта
Критические правила для обучения AI
Выводы
Интеграция AI в процесс анализа тестов показала отличные результаты:
Время экономится в 8-10 раз (от часов до минут)
Качество анализа выше — AI замечает паттерны, которые могут упустить люди
Меньше человеческих ошибок — стандартизированный формат отчетов
Масштабируемость — AI может анализировать отчеты 24/7
Самое важное — AI не заменяет тестировщика, а усиливает его. Машина делает рутинную работу, человек принимает решения на основе качественных данных.
Результат: QA команда теперь фокусируется на стратегических задачах вместо рутинного анализа логов, а разработчики получают конкретные, действенные рекомендации по исправлению ошибок.
