Как мы автоматизировали анализ упавших тестов с помощью AI: от хаоса к структуре

Представьте: каждый день ваши автотесты генерируют десятки отчетов об ошибках, QA команда тратит часы на анализ падений, а разработчики получают невразумительные описания в духе “test.feature упал на строке 410”. Знакомо?

Мы решили эту проблему, интегрировав AI в процесс анализа тестов, и хотим поделиться опытом.

Проблема: хаос в анализе упавших тестов

В нашем проекте работает комплексная тестовая инфраструктура:

• 8 параллельных потоков выполнения

• 650+ автотестов на Cucumber

• Ежедневные прогоны с анализом регрессий

Типичный workflow до автоматизации:

1. Тесты упали → HTML отчет с кучей технических деталей

2. QA анализирует каждое падение вручную

3. Создает отчет для разработчиков: “найди строку в step_definitions, посмотри стек, угадай что сломалось”

4. Разработчик тратит еще время на понимание проблемы

Боль реальная:

• 🔍 Нет структурированного анализа — каждый отчет уникален

• ⏰ Огромные временные затраты QA — от 1 до 3 часов на анализ отчетов

• 📊 Нет приоритизации ошибок — все падения выглядят одинаково критично

Решение: AI как второй тестировщик

Мы решили создать AI помощника, который будет анализировать упавшие тесты и создавать структурированные отчеты в том формате, который понятен разработчикам.

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

Архитектура решения

Компоненты системы:

• generate_test_failure_report.sh — анализ отчетов и извлечение данных

• amp_chat.sh — интеграция с Sourcegraph Amp AI

• entrypoint.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 ФОРМАТИРОВАНИЕ ТАБЛИЦ

- ОБЯЗАТЕЛЬНО использовать правильный синтаксис: `| Поле | Значение |`
- ОБЯЗАТЕЛЬНО добавлять разделители заголовков: `|------|----------|`
- ОБЯЗАТЕЛЬНО выравнивать колонки с `|`
- ОБЯЗАТЕЛЬНО добавлять пустые строки до и после таблиц

Результаты: цифры говорят сами за себя

Пример экономии времени:

• Раньше: 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 промпт система

Создали многоуровневую систему правил:

1. AGENT.md — общие правила работы с проектом

2. 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

Планы развития

Ближайшие планы:

1. GitLab интеграция — автоматическое создание тикетов с меткой Regression

2. Машинное обучение — анализ паттернов ошибок для предсказания проблемных зон

Долгосрочная перспектива:

• Автоматическое исправление простых ошибок через 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 в процесс анализа тестов показала отличные результаты:

1. Время экономится в 8-10 раз (от часов до минут)

2. Качество анализа выше — AI замечает паттерны, которые могут упустить люди

3. Меньше человеческих ошибок — стандартизированный формат отчетов

4. Масштабируемость — AI может анализировать отчеты 24/7

Самое важное — AI не заменяет тестировщика, а усиливает его. Машина делает рутинную работу, человек принимает решения на основе качественных данных.

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