Метрики качества ПО

Качество ПО поддаётся не только субъективной оценке. Метрики помогают командам количественно оценить состояние кода, отслеживать прогресс и выявлять потенциальные проблемы на ранних стадиях. В этой статье я расскажу о ключевых метриках и покажу, как их правильно применять.

Коротко о главном

• Метрики делают качество ПО объективным и сравнимым.
• Code-Coverage, цикломатическая сложность, частота ошибок, MTTR и Technical Debt — это центральные показатели.
• Метрики всегда нужно анализировать в контексте, никогда изолированно.
• Комбинация технических, процессных и операционных метрик даёт полную картину.

Определение

Метрика — это количественная мера, которая отражает определённый аспект качества ПО. Она может измерять технические характеристики кода, например сложность, или процессные параметры, например время до исправления ошибки. Важно помнить, что метрики служат индикаторами, а не единственным основанием для принятия решений.

Основные метрики

Технические метрики

• Code-Coverage: доля кода, покрытого автоматизированными тестами. Обычно целевой диапазон находится между 70 и 90 процентами в зависимости от контекста проекта.
• Cyclomatic Complexity: измеряет количество независимых путей выполнения в функции. Значения выше 10 часто считаются критическими.
• Cognitive Complexity: оценивает, насколько сложно человеку понять код.
• Code Duplicates: выявляет повторяющиеся блоки кода, требующие обслуживания.
• Technical Debt Ratio: соотношение между объёмом “долга” и общей базой кода.

Процессные метрики

• Defect Density: количество ошибок на единицу размера кода, например на 1000 строк.
• Bug Escape Rate: ошибки, которые прошли контроль качества и попали в production.
• Test Failure Rate: доля неудачных прогонов тестов за определённый период.
• Code Review Turnaround Time: время, прошедшее до завершения ревью.

Операционные метрики

• MTTR (Mean Time To Recovery): среднее время восстановления системы после сбоя.
• MTBF (Mean Time Between Failures): среднее время между двумя сбоями.
• Availability: процент времени, в течение которого система работает.
• Error Rate: доля неудачных запросов в production.
• Latency: время отклика интерфейсов или транзакций.

Пример: информационная панель для разработчиков

Панель качества команды:

Тесты:
- Code-Coverage: 82 процента
- Unit Test Failure Rate: 1,2 процента
- Integration Test Failure Rate: 0,5 процента

Качество кода:
- Средняя Cyclomatic Complexity: 6
- Code Duplicates: 2,1 процента
- Technical Debt Ratio: 4,5 процента

Операционная работа:
- Availability: 99,95 процента
- MTTR: 18 минут
- Error Rate: 0,3 процента

Процесс:
- Code Review Turnaround Time: 4 часа
- Bug Escape Rate: 3 за спринт
- Defect Density: 0,8 на 1000 строк

Плюсы и минусы

Плюсы

• Объективность: решения основаны на данных, а не на интуиции.
• Ранние предупреждения: отрицательные тренды становятся видны до того, как они станут критическими.
• Сравнимость: команды и проекты могут измеряться по единым критериям.
• Мотивация: чёткие цели повышают внимание команды к качеству.

Минусы

• Неправильные приоритеты: высокий Code-Coverage сам по себе ничего не говорит о качестве тестов.
• Игра по метрикам: показатели можно манипулировать, чтобы достичь целей без реального улучшения.
• Затраты: сбор и анализ требуют инструментов и времени.
• Отсутствие контекста: одна и та же метрика может означать разное в разных проектах.

Ключевые пункты

• Определение и назначение метрик ПО.
• Различие между техническими, процессными и операционными метриками.
• Значение и интерпретация Code-Coverage и Cyclomatic Complexity.
• Связь между MTTR, MTBF и Availability.
• Риски использования изолированных или манипулируемых метрик.

Типичные вопросы и короткие ответы

1. Что измеряет Code-Coverage? Долю кода, который выполняется при прогоне тестов.

2. Что такое Cyclomatic Complexity? Количество независимых путей выполнения в функции или модуле.

3. Что означает MTTR? Mean Time To Recovery, среднее время восстановления.

4. Почему метрики нельзя рассматривать изолированно? Потому что они легко могут быть неправильно интерпретированы или манипулированы.

5. Приведи пример операционной метрики. Availability, Error Rate или Latency.

Продолжение в разделе “Качество ПО”

Следующая статья в этом разделе посвящена основам Software Testing — Unit Tests, Integration Tests, E2E Tests, TDD и BDD как основе качественного ПО.

Основные источники

1. https://iso25000.com
2. https://martinfowler.com/bliki/CannotMeasureProductivity.html
3. https://en.wikipedia.org/wiki/Software_metric