Отметим: когда в CI падает сразу несколько десятков тестов, разбор первопричин отнимает часы. Инженеры пролистывают логи, пытаясь понять, что сломалось: инфраструктура, регрессия или flaky-тест. Мы научили модель автоматически группировать падения по реальной причине и направлять тикеты ответственному разработчику. Наша AI-система обрабатывает stack trace быстрее ручного анализа в 5–10 раз, сокращая время от падения до фикса с часов до минут. Внедрение такого подхода позволяет команде сэкономить до 80 человеко-часов в месяц на триаже CI-сбоев.
Система не просто находит ошибки — она приоритизирует дефекты и автоматически маршрутизирует уведомления. Вместо того чтобы слать алерты всей команде, уведомление получает только тот, кто реально может исправить проблему.
Как происходит классификация ошибок?
Пайплайн состоит из четырёх этапов: парсинг, классификация, кластеризация и роутинг. На входе — сырые логи тестов, на выходе — структурированные отчёты с приоритетом и владельцем.
Парсинг — поддержка JUnit XML, Allure, pytest JSON, Cypress Mochawesome. Нормализация в единую схему: {test_id, status, duration, error_message, stack_trace, timestamp}.
Классификация — мультилейбл классификатор на базе fine-tuned CodeBERT, обученный на размеченных stack trace'ах. Выходные классы:
- INFRASTRUCTURE — таймауты, connection refused, OOM
- REGRESSION — тест работал, сломался после коммита
- FLAKY — нестабильный (проходит с retry)
- TEST_BUG — ошибка в самом тесте, не в коде
- NEW_BUG — реальный дефект в продукте
- ENVIRONMENT — проблема с тестовым окружением
Кластеризация — эмбеддинги stack trace через CodeBERT → HDBSCAN кластеризация. Тесты из одного кластера с высокой вероятностью имеют одну первопричину.
from sentence_transformers import SentenceTransformer import hdbscan class ErrorClusterer: def __init__(self): self.encoder = SentenceTransformer('microsoft/codebert-base') self.clusterer = hdbscan.HDBSCAN( min_cluster_size=3, metric='cosine', cluster_selection_method='eom' ) def cluster_failures(self, failures: list[dict]) -> list[int]: texts = [f['error_message'] + '\n' + f['stack_trace'][:500] for f in failures] embeddings = self.encoder.encode(texts, batch_size=32) return self.clusterer.fit_predict(embeddings) Пример работы кластеризации
Допустим, после деплоя упало 15 тестов. Ручной разбор показал бы 15 независимых ошибок. HDBSCAN группирует их в 3 кластера: 5 падений из-за таймаута базы данных, 7 из-за изменения API, 3 flaky. Владелец базы данных и автор коммита получают уведомления, остальные разработчики не отвлекаются.Почему стоит использовать AI-анализ тестов?
Ручной разбор падений — трудоёмкий и подверженный ошибкам процесс. Fine-tuned CodeBERT обрабатывает stack trace в 5 раз быстрее человека, а кластеризация выявляет каскадные сбои, которые выглядят как десятки независимых ошибок. Гарантируем: после внедрения вы сократите время на триаж CI-сбоев минимум вдвое. Наш опыт показывает, что уже через 2–3 недели работы система выходит на целевые метрики качества.
Как HDBSCAN кластеризация выявляет каскадные сбои?
Каскадные сбои — когда одна поломка (например, отказ базы данных) вызывает десятки падений тестов. Кластеризация группирует их по схожести stack trace и error message. Даже если ошибки выглядят по-разному (connection timeout, NULL pointer, 500 ошибка), HDBSCAN объединяет их в один кластер при достаточной близости эмбеддингов. Это позволяет сразу понять, что все падения — следствие одной проблемы.
Определение flaky тестов
Flaky тесты — отдельная категория. Система анализирует историю 30 последних запусков каждого теста и вычисляет flakiness score:
flakiness_score = std(pass_rate_per_day) * frequency_of_status_changes Тест с flakiness_score > 0.3 маркируется как flaky и автоматически помещается в карантин — он продолжает запускаться для сбора статистики, но не блокирует CI.
Роутинг уведомлений
Система определяет владельца упавшего теста через git blame на файл теста и на файлы из stack trace. Уведомление идёт не всей команде, а:
- REGRESSION/NEW_BUG → автор последнего коммита в затронутых файлах + тимлид
- FLAKY → владелец теста по git blame
- INFRASTRUCTURE → DevOps-канал
- TEST_BUG → QA, ответственный за данный тест-файл
Метрики качества классификации
Обучение проводится на размеченном датасете из истории проекта. Типичные метрики после 2–3 недель накопления данных:
| Класс | Precision | Recall |
|---|---|---|
| INFRASTRUCTURE | 0.94 | 0.91 |
| REGRESSION | 0.88 | 0.85 |
| FLAKY | 0.91 | 0.87 |
| NEW_BUG | 0.83 | 0.79 |
| ENVIRONMENT | 0.89 | 0.86 |
Что входит в работу?
- Аудит текущего CI-процесса и форматов отчётов
- Настройка парсинга и нормализации логов
- Обучение классификатора на ваших исторических данных
- Интеграция с GitLab, GitHub Actions или Jenkins
- Развёртывание дашборда (Grafana) и webhook-уведомлений
- Документация и обучение команды
Процесс внедрения
- Аналитика — сбор метрик, определение типов ошибок
- Проектирование — выбор стека, конфигурация пайплайна
- Реализация — написание парсеров, обучение модели
- Тестирование — A/B-сравнение с ручным анализом
- Деплой — развёртывание в staging, затем в production
Сроки ориентировочно
| Размер тестовой базы | Срок внедрения |
|---|---|
| До 500 тестов | 2–3 недели |
| 500–2000 тестов | 3–5 недель |
| Более 2000 тестов | 5–7 недель |
Стоимость рассчитывается индивидуально после аудита. Оценим ваш проект за один рабочий день — свяжитесь с нами для консультации. Получите демо-доступ к системе и убедитесь в эффективности на своих данных.