Метрики тестирования (Software Test Metrics)
Метрика (metric): Шкала измерений и метод, используемый для измерений (ISO 14598)
“Вы не можете контролировать то, что не можете измерить” - Том Демакро.
Основная цель тестирования заключается в предоставлении информации, необходимой для управления рисками. Чтобы контролировать и управлять тестированием, а также предоставлять своевременную информацию заинтересованным сторонам, необходимы эффективные измерения процесса тестирования. Для измерения процесса тестирования нужно определить, какая информация должна быть предоставлена, как ее получить и как она должна быть представлена. Таким образом, для всех действий тестирования необходимо определить и использовать метрики, а также предоставить показатели измерений, как для продуктов, так и для процессов.
Метрики тестирования программного обеспечения подразделяются на два типа:
- Метрики процесса (Process metrics): используются в процессе подготовки и выполнения тестирования.
- Продуктивность подготовки тест-кейсов (Test Case Preparation Productivity): используется для расчета количества подготовленных тест-кейсов и усилий (Effort), затраченных на их подготовку.Test Case Preparation Productivity = (No of Test Case) / (Effort spent for Test Case Preparation)
- Охват тестового дизайна (Test Design Coverage): процент покрытия тест-кейсами требований.Test Design Coverage = ((Total number of requirements mapped to test cases) / (Total number of requirements)*100
- Продуктивность выполнения тестов (Test Execution Productivity): определяет количество тест-кейсов, которые могут быть выполнены в час.Test Execution Productivity = (No of Test cases executed) / (Effort spent for execution of test cases)
- Покрытие выполненных тестов (Test Execution Coverage): предназначено для измерения количества выполненных тест-кейсов по сравнению с количеством запланированных тест-кейсов.Test Execution Coverage = (Total no. of test cases executed / Total no. of test cases planned to execute)*100
- Успешные тест-кейсы (Test Cases Passed): для измерения процента пройденных успешно тест-кейсов.Test Cases Pass = (Total no. of test cases passed) / (Total no. of test cases executed) * 100
- Неуспешные тест-кейсы (Test Cases Failed): для измерения процента заваленных тест-кейсов.Test Cases Failed = (Total no. of test cases failed) / (Total no. of test cases executed) * 100
- Заблокированные тест-кейсы (Test Cases Blocked): для измерения процента блокированных тест-кейсов.Test Cases Blocked = (Total no. of test cases blocked) / (Total no. of test cases executed) * 100
- Метрики продукта (Product metrics):
- Уровень обнаружения ошибок (Error Discovery Rate): для определения эффективности тест-кейсов.Error Discovery Rate = (Total number of defects found /Total no. of test cases executed)*100
- Процент выявления дефектов (Defect Detection Percentage (DDP)): Количество дефектов, выявленных в фазе тестирования, поделенное на число дефектов, найденных в этой фазе тестирования, а также во всех последующих фазах. См. также ускользнувший дефект. (ISTQB)
- Уровень исправления дефектов (Defect Fix Rate): помогает узнать качество сборки (build) с точки зрения устранения дефектов.Defect Fix Rate = (Total no of Defects reported as fixed - Total no. of defects reopened) / (Total no of Defects reported as fixed + Total no. of new Bugs due to fix)*100
- Плотность дефектов (Defect Density): количество дефектов, обнаруженных в компоненте или системе, поделенное на размер компонента или системы (выраженный в стандартных единицах измерения, например строках кода, числе классов или функций). (ISTQB)Defect Density = Total no. of defects identified / Actual Size (requirements)
- Утечка дефектов (Defect Leakage): используется для проверки эффективности процесса тестирования перед UAT.Defect Leakage = ((Total no. of defects found in UAT)/(Total no. of defects found before UAT)) * 100
- Эффективность устранения дефектов (Defect Removal Efficiency): позволяет сравнивать общую (дефекты, обнаруженные до и после поставки) эффективность устранения дефектов.Defect Removal Efficiency = ((Total no. of defects found pre-delivery) /( (Total no. of defects found pre-delivery )+ (Total no. of defects found post-delivery)))* 100
Тестовое покрытие (Test Coverage)
Тестовое Покрытие - это одна из метрик оценки качества тестирования, представляющая из себя плотность покрытия тестами требований либо исполняемого кода. Сложность современного ПО и инфраструктуры сделало невыполнимой задачу проведения тестирования со 100% тестовым покрытием. Поэтому для разработки набора тестов, обеспечивающего более-менее высокий уровень покрытия можно использовать специальные инструменты либо техники тест дизайна.
Существуют следующие подходы к оценке и измерению тестового покрытия:
- Покрытие требований (Requirements Coverage) - оценка покрытия тестами функциональных и нефункциональных требований к продукту путем построения матриц трассировки (traceability matrix).
- Покрытие кода (Code Coverage) - оценка покрытия исполняемого кода тестами, путем отслеживания непроверенных в процессе тестирования частей ПО.
- Тестовое покрытие на базе анализа потока управления - это одна из техник тестирования белого ящика, основанная на определении путей выполнения кода программного модуля и создания выполняемых тест кейсов для покрытия этих путей.
Различия:
Метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту, в то время как анализ покрытия кода - на полноте проверки тестами разработанной части продукта (исходного кода), а анализ потока управления - на прохождении путей в графе или модели выполнения тестируемых функций (Control Flow Graph).
Ограничения:
- Метод оценки покрытия кода не выявит нереализованные требования, так как работает не с конечным продуктом, а с существующим исходным кодом.
- Метод покрытия требований может оставить непроверенными некоторые участки кода, потому что не учитывает конечную реализацию.
Альтернативное мнение
Покрытие кода - совершенно бесполезная метрика. Не существует «правильного» показателя. Это вопрос-ловушка. У вас может быть проект с близким к 100% покрытием кода, в котором по-прежнему остаются баги и проблемы. В реальности нужно следить за другими метриками - хорошо известными показателям CTM (Codepipes testing Metrics).
- PDWT (процент разработчиков, пишущих тесты) - вероятно, самый важный показатель. Нет смысла говорить об антипаттернах тестирования ПО, если у вас вообще нет тестов. Все разработчики в команде должны писать тесты. Любую новую функцию можно объявлять сделанной только если она сопровождается одним или несколькими тестами.
- PBCNT (процент багов, приводящих к созданию новых тестов). Каждый баг в продакшне - отличный повод для написания нового теста, проверяющего соответствующее исправление. Любой баг должен появиться в продакшне не более одного раза. Если ваш проект страдает от появления повторных багов даже после их первоначального «исправления», то команда действительно выиграет от использования этой метрики.
- PTVB (процент тестов, которые проверяют поведение, а не реализацию). Тесно связанные тесты пожирают массу времени при рефакторинге основного кода.
- PTD (процент детерминированных тестов от общего числа). Тесты должны завершаться ошибкой только в том случае, если что-то не так с бизнес-кодом. Если тесты периодически ломаются без видимой причины - это огромная проблема. Если после прочтения о метриках вы по-прежнему настаиваете на установке жесткого показателя для покрытия кода, я дам вам число 20%. Это число должно использоваться как эмпирическое правило, основанное на законе Парето. 20% вашего кода вызывает 80% ваших ошибок
Источники:
Доп. материал: