Зауважте: коли в 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 тижнів |
Вартість розраховується індивідуально після аудиту. Оцінимо ваш проект за один робочий день — зв'яжіться з нами для консультації. Отримайте демо-доступ до системи та переконайтеся в ефективності на своїх даних.