Skip to content

Latest commit

 

History

History
101 lines (69 loc) · 14.8 KB

metriki-testirovaniya-software-test-metrics.md

File metadata and controls

101 lines (69 loc) · 14.8 KB
Raw

Метрики тестирования (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% тестовым покрытием. Поэтому для разработки набора тестов, обеспечивающего более-менее высокий уровень покрытия можно использовать специальные инструменты либо техники тест дизайна.

Существуют следующие подходы к оценке и измерению тестового покрытия:

Различия:
Метод покрытия требований сосредоточен на проверке соответствия набора проводимых тестов требованиям к продукту, в то время как анализ покрытия кода - на полноте проверки тестами разработанной части продукта (исходного кода), а анализ потока управления - на прохождении путей в графе или модели выполнения тестируемых функций (Control Flow Graph).

Ограничения:

  • Метод оценки покрытия кода не выявит нереализованные требования, так как работает не с конечным продуктом, а с существующим исходным кодом.
  • Метод покрытия требований может оставить непроверенными некоторые участки кода, потому что не учитывает конечную реализацию.

Альтернативное мнение

Покрытие кода - совершенно бесполезная метрика. Не существует «правильного» показателя. Это вопрос-ловушка. У вас может быть проект с близким к 100% покрытием кода, в котором по-прежнему остаются баги и проблемы. В реальности нужно следить за другими метриками - хорошо известными показателям CTM (Codepipes testing Metrics).

  • PDWT (процент разработчиков, пишущих тесты) - вероятно, самый важный показатель. Нет смысла говорить об антипаттернах тестирования ПО, если у вас вообще нет тестов. Все разработчики в команде должны писать тесты. Любую новую функцию можно объявлять сделанной только если она сопровождается одним или несколькими тестами.
  • PBCNT (процент багов, приводящих к созданию новых тестов). Каждый баг в продакшне - отличный повод для написания нового теста, проверяющего соответствующее исправление. Любой баг должен появиться в продакшне не более одного раза. Если ваш проект страдает от появления повторных багов даже после их первоначального «исправления», то команда действительно выиграет от использования этой метрики.
  • PTVB (процент тестов, которые проверяют поведение, а не реализацию). Тесно связанные тесты пожирают массу времени при рефакторинге основного кода.
  • PTD (процент детерминированных тестов от общего числа). Тесты должны завершаться ошибкой только в том случае, если что-то не так с бизнес-кодом. Если тесты периодически ломаются без видимой причины - это огромная проблема.

    Если после прочтения о метриках вы по-прежнему настаиваете на установке жесткого показателя для покрытия кода, я дам вам число 20%. Это число должно использоваться как эмпирическое правило, основанное на законе Парето. 20% вашего кода вызывает 80% ваших ошибок

Источники:

Доп. материал: