Основой любого мониторинга являются метрики. Allure генерирует отчет в виде набора статических файлов (JSON, XML), но для мониторинга нам нужен доступ к данным программно. Первый шаг — это настройка CI/CD пайплайна (Jenkins, GitLab CI, GitHub Actions) для сохранения артефактов отчета в известное и доступное место после каждого запуска тестов. Эксперты рекомендуют не просто хранить последний отчет, а вести историю, например, используя систему артефактов CI или объектное хранилище (S3, MinIO) с структурированными по дате путями.
Следующий шаг — извлечение ключевых метрик. Для этого можно написать простой скрипт на Python или Node.js, который будет парсить файл `allure-report/data/test-cases/*.json`. Рассмотрим ключевые метрики, которые стоит отслеживать:
- **Общее количество тестов** (total).
- **Количество упавших тестов** (failed) и их процент от общего числа.
- **Количество сломанных тестов** (broken) — тестов с ошибкой в коде, а не в утверждении (assertion).
- **Количество "хлопковых" тестов** (flaky). Для их определения нужна история нескольких запусков. Тест, который то проходит, то нет при неизменном коде — флейки.
- **Среднее и перцентильное (p95, p99) время выполнения тестов**.
- **Распределение тестов по статусам и severity** (логическая важность).
```python
import json
import os
from pathlib import Path
def parse_allure_results(results_dir: Path):
total = 0
failed = 0
broken = 0
passed = 0
durations = []
for file_path in results_dir.glob('*.json'):
total += 1
with open(file_path) as f:
data = json.load(f)
status = data.get('status')
if status == 'failed':
failed += 1
elif status == 'broken':
broken += 1
elif status == 'passed':
passed += 1
# Сбор времени выполнения
if 'time' in data:
durations.append(data['time'].get('duration', 0))
avg_duration = sum(durations) / len(durations) if durations else 0
p95_duration = sorted(durations)[int(len(durations) * 0.95)] if durations else 0
return {
'total': total,
'failed': failed,
'broken': broken,
'passed': passed,
'failure_rate': (failed + broken) / total if total else 0,
'avg_duration_ms': avg_duration,
'p95_duration_ms': p95_duration
}
```
После извлечения метрик их нужно куда-то отправлять. Опытные инженеры используют системы мониторинга, такие как **Prometheus** или **Datadog**. Для Prometheus можно создать простой экспортер, который будет предоставлять метрики в формате, понятном Prometheus. Затем эти метрики можно визуализировать в Grafana, создав дашборд "Health of Automated Tests".
Пример алертинга: если процент упавших тестов (failure_rate) превышает 10% за последние 3 запуска, или если среднее время выполнения тестов выросло на 20% по сравнению с прошлой неделей — отправить оповещение в Slack или Telegram. Это позволяет реагировать не только на поломку функциональности (тесты упали), но и на деградацию производительности тестовой системы.
Отдельная задача — мониторинг флейки-тестов. Для этого нужно сравнивать результаты нескольких последовательных запусков. Можно хранить историю в простой базе данных (SQLite, PostgreSQL) или в том же объектном хранилище. Алгоритм: если тест меняет статус между 'passed' и 'failed'/'broken' при неизменном коде (определяется по хешу коммита), то пометить его как подозрительный. При превышении порога (например, 3 смены статуса за 10 запусков) — создать тикет в Jira на исследование.
Интеграция с системами управления тест-кейсами (Test Management Systems) — еще один уровень. Можно автоматически обновлять статус тест-кейса в Xray или Zephyr на основе результата в Allure, используя их API. Это закрывает цикл от автоматического выполнения до обновления отчетности для менеджмента.
В заключение, мониторинг Allure превращает разовые отчеты в живую систему метрик качества. Это позволяет перейти от реактивного ("тесты упали, надо чинить") к проактивному ("процент флейки-тестов растет, нужно стабилизировать среду") подходу. Внедрение таких практик требует начальных усилий по настройке скриптов и дашбордов, но окупается значительным повышением стабильности и предсказуемости процесса тестирования.
Комментарии (7)