Кратко и по делу — структура дашборда, какие метрики визуализировать, какие диаграммы использовать и как интерпретировать сочетания метрик для принятия решений.
1) Основные метрики + формулы (показывать текущие значения + тренд за 7/30/90 дней)
- Покрытие тестов (coverage):
$\text{Coverage}=\frac{\text{covered lines (или branches)}}{\text{total lines (или branches)}}\cdot 100\%$ - Скорость падений сборок (build failure rate):
$\text{Build Failure Rate}=\frac{\text{failed builds}}{\text{total builds}}\cdot 100\%$ - MTTR (mean time to resolve/restore):
$\text{MTTR}=\frac{\sum \text{time to fix incidents}}{N_{\text{incidents}}}$ - Баг‑динамика: новый/закрытый/переоткрытый (counts, velocity), дефектная плотность:
$\text{Defect Density}=\frac{\text{defects}}{\text{KLOC}}$ - Тестовая «ломкость» (flakiness rate):
$\text{Flakiness}=\frac{\text{intermittent test failures}}{\text{total test runs}}\cdot 100\%$ - Время обнаружения (MTTD), время релизной готовности (release readiness score)
- Пороговые/целевые показатели (пример): Coverage target $\ge 80\%$, Build failure target $<5\%$, MTTR target $<4$ часов.
2) Виды диаграмм и где их применять
- Панель “Краткая сводка” (scorecard): ключевые числа + цели (cards).
- Тренды (line charts / area charts): coverage, build failure rate, MTTR, число багов по времени (7/30/90 дней).
- Комбинированный график CI: stacked bar или area по статусам сборок (passed, failed, aborted) + линия для времени сборки.
- Тепловая карта (heatmap): распределение фейлов тестов по тестам/модулям/времени (помогает найти флак‑тесты).
- Диаграмма рассеяния (scatter): дефекты vs. кодовый churn или сложность модулей (выявляет проблемные области).
- Контрольная карта / boxplot: MTTR и время исправления — показывает выбросы и стабильность процесса.
- Столбчатые диаграммы с сортировкой: баги по компонентам/приоритетам/авторам (top N).
- Кумулятивный flow / burndown: прогресс по баг‑беклогу и релизная готовность.
- Таблица с фильтрами + ссылка на воспроизводимость/логи/CI‑артефакты.
3) Интерпретация сочетаний метрик и действия
- Высокое покрытие ($\ge 80\%$) + растущие баги в продакшне → покрытие формальное (нет проверок бизнес‑логики) → добавить интеграционные/е2е тесты, ревью тестов.
- Низкое покрытие + мало багов в проде → возможно тесты недостаточно чувствительны или баги ещё не проявились → увеличить приоритет юнит/интеграционных тестов в критичных модулях.
- Высокий build failure rate + высокая flakiness → фейки в тестах/параметры окружения → приоритизировать фиксы flaky‑тестов и стабилизацию CI (изолировать нестабильные тесты, retry на инфраструктуре).
- Частые падения сборок + низкий MTTR → команда быстро исправляет, но стабильность плоха → короткие действия: автопометки/скорые фиксы; долгосрочно: улучшать качество PR и pre‑merge проверки.
- Высокий MTTR + мало ворк‑ресурсов → узкие места в он‑колле/knowledge transfer → внедрить runbook, on‑call rotation, улучшить логирование/alerting.
- Растущая дефектная плотность в модуле + высокий кодовый churn → проблемный модуль → назначить рефакторинг/тестовую кампанию, код‑ревью фокус.
- Много reopen‑ов или регрессий + низкая стабильность автоматизации → тесты не покрывают регрессии → усилить регрессионный набор и gated‑deploy (blocker для релиза).
- Низкая скорость закрытия багов + большой backlog → приоритизация/тримминг: выделить спринт на технический долг или ввести SLA по приоритетам.
4) Практические правила визуализации и тревог
- Показать текущую метрику + тренд и изменение в процентах (delta за 30 дней). Все критические отклонения подсвечивать (красный/оранжевый).
- Использовать фильтры по командам/модулям/релизам и возможность drill‑down в конкретный провал сборки или теста.
- Настроить alerting для: Build Failure Rate $>$ целевого порога (например $>5\%$), MTTR $>$ SLA, Flakiness $>10\%$, резкий рост дефектов за 7 дней (например $>$ $50\%$ роста).
- Периодичность данных: CI — в реальном времени; баги/coverage — ежедневный апдейт; MTTR — агрегат за 30/90 дней.
5) Что показывать руководству vs команде
- Руководство: KPI‑карточки (coverage, build stability, MTTR), тренды, риски релиза (readiness score).
- Команда: детальные панели по тестам, список flaky tests, топ‑модулей по дефектной плотности, конкретные действия/owner.
Коротко: дашборд должен давать (1) быстрый health‑check (scorecard), (2) тренды для раннего обнаружения деградации, (3) drill‑down для локализации проблем и (4) чёткие правила интерпретации (с порогами и действиями).