Как вы используете метрики для оценки качества тестов и продукта?

Да ты посмотри, какие мы тут серьёзные собрались! Метрики, блядь, инструмент ключевой, говорят. Ну, а хули, без них-то как? На глазок, что ли, качество мерить? Так и до пиздеца недалеко.

Я их, эти метрики, на нескольких уровнях применяю, чтобы всю картину, сука, как на ладони видеть.

1. Метрики качества кода и покрытия

• Покрытие кода (Code Coverage): Вот это, блядь, классика жанра. JaCoCo, Coverage.py, Istanbul — инструменты на любой вкус и цвет. Цель-то, понимаешь, не гнаться за этими ебучими 100%, как последний идиот. А вот найти эти непокрытые, блядь, критические участки, где баг, как хитрая жопа, может притаиться.

  # Пример генерации отчёта с pytest-cov
  pytest --cov=my_module --cov-report=html --cov-report=term-missing

• Статический анализ: А это уже SonarQube в дело идёт. Технический долг, code smells, уязвимости — вся эта муть. Смотрю на цифры и сразу видно, куда рефакторинг, блядь, впендюрить в первую очередь, чтобы не захлебнуться в этом дерьме.

2. Метрики эффективности тестов

• Стабильность тестов (Flakiness Rate): О, это моя любимая боль, ёпта! Процент падений тестов по недетерминированным причинам. Нашёл такой тест — изолируй его и переписывай, пока он всю пайплайну не обосрал своими случайными фейлами. Доверия к таким тестам — ноль ебать.
• Время выполнения тестовой suites: А тут смотрю, не превратились ли мои тесты в ебучую сагу. Мониторю через CI или свои скрипты. Если тест бежит дольше, чем я до магазина за пивом, — это повод задуматься о параллелизации или оптимизации.
• Соотношение типов тестов: Ну, пирамида тестирования, её все знают. Много юнитов, меньше интеграционных, совсем немного E2E. Если пирамида перевёрнутая — это пиздец, а не архитектура.

3. Метрики качества продукта

• Плотность дефектов (Defect Density): Считаю, сколько багов натыкано на какую-то функциональность. Если в одном модуле дефектов, как говна за баней, — понятно, что там код писал полупидор, и с модулем этим надо что-то делать.
• Эффективность тестов (Test Effectiveness): Смотрю, сколько багов мы ловим ДО продакшена, а сколько уже пользователи нам, как подарок, приносят. Если соотношение хреновое — значит, тесты хуй с горы, а не тесты.
• Время отклика и производительность: А это я уже в сами автотесты встраиваю. Библиотечки типа locust для Python, метрики в Prometheus отправляю. Чтобы не гадать на кофейной гуще, а точно знать, когда система начинает тормозить, как мартышлюшка.

Вот, смотри, как я метрики производительности в автотест засунул, с использованием Allure:

import pytest
import allure
import time
import requests

@pytest.mark.performance
def test_api_response_time():
    """Тест проверяет, что 95-й перцентиль времени ответа API не превышает 200 мс."""
    url = "https://api.example.com/items"
    response_times = []

    for _ in range(100):
        start = time.perf_counter()
        response = requests.get(url)
        response.raise_for_status()
        elapsed = time.perf_counter() - start
        response_times.append(elapsed)

    response_times.sort()
    p95 = response_times[int(0.95 * len(response_times))]

    # Прикрепляем метрику к отчёту Allure
    allure.dynamic.label("component", "API")
    allure.attach(f"95th percentile response time: {p95:.3f}s", name="perf_metrics")

    # Assert для CI
    assert p95 < 0.2, f"P95 response time {p95:.3f}s exceeds 200ms threshold"

А потом всю эту красоту в Grafana загоняю, дабы тренды отслеживать. Сидишь, кофе пьёшь, на графики смотришь. Увидел, что линия поползла вверх — уже знаешь, куда бежать и кому сейчас будет вманжено за деградацию производительности. Красота, блядь!