Метрики тестирования (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% ваших ошибок
Источники:
Доп. материал:
Last updated
