Что такое плотность дефектов? Формула для расчета с примером

Что такое плотность дефектов?

Плотность дефектов Это количество подтвержденных дефектов в программном обеспечении или модуле за определенный период эксплуатации или разработки, деленное на размер этого программного обеспечения или модуля. Это позволяет команде решить, готово ли программное обеспечение к выпуску.

Плотность дефектов подсчитывается на тысячу строк кода, также известную как KLOC. Поскольку это число нормализовано по размеру, большой модуль с большим количеством дефектов и небольшой модуль с небольшим количеством дефектов можно сравнивать в одном масштабе, чего никогда не позволит сделать простое подсчет ошибок.

Этот показатель обычно сообщается в конце цикла тестирования. tracВыпуски выходят один за другим, поэтому он стоит в одном ряду с остальными. процесс управления дефектами в жизненный цикл тестирования программного обеспечения.

Как рассчитать плотность дефектов

Формула для измерения плотности дефектов:

Defect Density = Defect count/size of the release

Размер релиза можно измерить в строках кода (LOC).

Три фактора определяют, будет ли полученное число иметь какой-либо смысл:

• Единица измерения размера. LOC и KLOC — наиболее распространенные единицы измерения. Функциональные точки используются там, где командам нужна мера размера, которая не меняется в зависимости от языка программирования, а некоторые команды вместо этого нормализуют данные по модулям или компонентам.
• Что считается дефектом? В числитель следует включать только подтвержденные дефекты. Дубликаты, отклоненные отчеты и запросы на улучшение должны быть исключены, иначе показатель будет завышен без изменения качества кода.
• Диапазон измерений. Дефекты, обнаруженные в ходе тестирования системы, во время регрессионное тестированиеА после выпуска описываются разные вещи, поэтому точку необходимо указывать числом.

Пример плотности дефектов

Предположим, в ваш программный продукт интегрированы 3 модуля. В каждом модуле обнаружено следующее количество ошибок:

• Модуль 1 = 10 ошибок
• Модуль 2 = 20 ошибок
• Модуль 3 = 10 ошибок

Общее количество жуков = 10 + 20 + 10 = 40

Полный код каждого модуля состоит из следующих строк:

• Модуль 1 = 1000 LOC
• Модуль 2 = 1500 LOC
• Модуль 3 = 500 LOC

Общая строка Code = 1000+1500+500 = 3000

Плотность дефектов рассчитывается как:

Defect Density = 40/3000 = 0.013333 defects/loc = 13.333 defects/Kloc

Применение того же расчета ко всем модулям более полезно, чем суммарный показатель, как показывает диаграмма ниже: в модуле 2 обнаружено 20 дефектов на 1500 строк кода, а в модуле 3 — 10 дефектов всего на 500 строк кода, поэтому модуль 3 является более сложным и рискованным из двух, несмотря на то, что в нем обнаружено меньше ошибок.

Стандарт для определения плотности дефектов

Единого стандарта для плотности дефектов не существует. Исследования показывают, что один из них... дефект Показатель количества строк кода на тысячу строк, как правило, считается признаком высокого качества проекта, и это наиболее часто цитируемое эмпирическое правило в отрасли.

Ожидания меняются в зависимости от области применения. Для критически важного с точки зрения безопасности и регулируемого программного обеспечения, такого как авионика и медицинские приборы, целевой показатель значительно ниже одного дефекта на 1000 строк кода, в то время как для обычных бизнес-приложений он обычно выше. Поскольку правила подсчета, единицы измерения и глубина тестирования различаются в разных организациях, эталонный показатель, взятый из опубликованного исследования, сопоставим только с проектом, в котором измерения проводятся аналогичным образом. Поэтому практическое применение этого показателя ограничивается внутренними процессами: сравнение одной версии продукта с предыдущей версией, измеренной идентичным образом.

Факторы, влияющие на плотность дефектов

Одна и та же кодовая база может давать совершенно разные показатели плотности дефектов в зависимости от следующих факторов:

• Code сложность. Глубоко вложенная логика и высокая цикломатическая сложность приводят к большему количеству дефектов на строку кода, чем простой код.
• Типы дефектов, принимаемых во внимание. Учитываются только функциональные дефекты, или же включаются юзабилити, документация и т.д. нефункциональные Полученные результаты существенно меняют числитель.
• Рассматриваемый временной промежуток. Показатель, измеренный в течение двухнедельного тестового цикла, несопоставим с показателем, измеренным в течение шести месяцев эксплуатации в производственных условиях.
• Навыки разработчика и тестировщика. Опытные разработчики вносят меньше дефектов, а опытные тестировщики находят больше существующих, поэтому эти два эффекта тянут показатель в противоположных направлениях.
• Покрытие теста. Дефекты, которые не были замечены, никогда не учитываются, поэтому тестовое покрытие Незаметно ограничивает максимально возможную высоту измеренной плотности.

Плотность дефектов в сравнении с другими показателями дефектов

Показатель плотности дефектов отвечает на один вопрос: насколько сконцентрированы известные дефекты. Три сопутствующих показателя отвечают на вопросы, на которые он ответить не может, и большинство команд сообщают о них вместе.

В совокупности эти четыре показателя дают более полную картину: низкая плотность дефектов в сочетании с высокой утечкой дефектов указывает на поверхностное тестирование, а не на чистый код, что как раз и является ошибочным толкованием, о котором предупреждается в следующем разделе.

Преимущества плотности дефектов

Ниже перечислены преимущества плотности дефектов:

• Это помогает измерить эффективность тестирования.
• Это помогает различать концентрацию дефектов между компонентами и программными модулями.
• Это полезно для выявления областей, требующих исправления или улучшения.
• Это полезно для выявления компонентов высокого риска, что напрямую влияет на тестирование на основе рисков.
• Это помогает определить потребности в обучении различных специалистов.
• Это может помочь оценить объем работ по тестированию и доработке, вызванных дефектами.
• Она может оценить оставшиеся дефекты в программном обеспечении.
• Перед выпуском это помогает определить, достаточно ли проведенного к настоящему моменту тестирования.
• Это позволяет создать историческую основу, по которой можно будет оценивать последующие релизы.

Ограничения плотности дефектов

Этот показатель легко рассчитать, но легко неправильно интерпретировать. Следующие ограничения определяют, насколько он важен при принятии решения о выпуске продукта:

• Необнаруженные дефекты невидимы. В числителе содержатся только дефекты, которые были фактически обнаружены в ходе тестирования, поэтому слабо протестированный модуль показывает завышенные результаты.
• Степень серьезности не учитывается. Один дефект, приводящий к сбою платежа, и одна проблема с выравниванием косметических дефектов учитываются одинаково, поэтому необходимо также учитывать степень серьезности дефекта.
• Определения дефектов различаются. Две команды, использующие разные методы подсчета, дают результаты, которые нельзя сравнивать, даже внутри одной и той же организации.
• Количество строк кода является слабым индикатором размера. Подробный код снижает плотность, ничего не улучшая, и эта единица измерения не сопоставима между разными языками программирования.
• Этот показатель можно подтасовать. Отклонение пограничных отчетов или завышение количества строк улучшают показатели, но не улучшают конечный продукт.

Всё это, однако, не делает показатель плотности дефектов бесполезным. Это превращает его в индикатор тренда для одного продукта, измеряемый последовательно, а не в показатель для сравнения команд между собой.

Как снизить плотность дефектов

Реальное снижение количества дефектов, а не просто формальное его снижение, означает предотвращение дефектов на ранних стадиях и выявление остальных до выпуска продукта. Ниже перечислены методы, которые часто встречаются в опубликованных руководствах:

• Проведите тестирование на более ранних этапах. Привлечение тестировщиков на этапе определения требований и проектирования позволяет выявлять неясности до того, как они превратятся в код, а именно на этом этапе дефекты устраняются дешевле всего.
• RevПросмотрите код перед слиянием. Взаимная проверка выявляет логические ошибки, неверное толкование требований и недостатки проектирования, которые невозможно обнаружить без проверки. модульный тест Было написано, что нужно искать.
• Автоматизируйте набор регрессионных тестов. Выполняет проверки для каждого коммита. непрерывная интеграция предотвращает повторное появление старых дефектов во время написания нового кода.
• Сначала напишите тесты. Разработка через тестирование заставляет указывать каждое поведение до его реализации, и тестирование мутаций Затем можно подтвердить, что полученные в результате тесты действительно что-то утверждают.
• Используйте статический анализ. Автоматизированное сканирование кода выявляет разыменования нулевых ссылок, утечки ресурсов и проблемные места еще до запуска первого теста.
• Проведите рефакторинг сложных модулей. После того как метод Defect Density определил наиболее проблемные компоненты, их разделение и упрощение обычно позволяют снизить как сложность, так и количество дефектов.
• Вносите дефекты обратно в процесс. Анализ первопричин на ретроспективах превращает отдельные дефекты в исправления процесса, а не в разовые заплатки.

Tracked release over release alongside методы тестирования программного обеспечения Благодаря данным о покрытии, показатель плотности дефектов превращается из отчета об оценке в систему раннего предупреждения.

Часто задаваемые вопросы (FAQ)