Що таке щільність дефектів? Формула для обчислення з прикладом
Томас Гамільтон
⚡ Розумний підсумок
Щільність дефектів вимірює кількість підтверджених дефектів у програмному модулі, поділену на розмір цього модуля, зазвичай виражається на тисячу рядків коду, і сигналізує про готовність збірки до випуску.
Що таке щільність дефектів?
Щільність дефектів – це кількість дефектів, підтверджених у програмному забезпеченні або модулі протягом певного періоду експлуатації або розробки, поділена на розмір цього програмного забезпечення або модуля. Це дозволяє команді вирішити, чи готове програмне забезпечення до випуску.
Щільність дефектів вимірюється на тисячу рядків коду, також відома як 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 LOC, а Модуль 3 містить 10 дефектів лише у 500 LOC, тому Модуль 3 є щільнішим та ризикованішим з двох, хоча в ньому повідомляється про менше помилок.
Стандарт щільності дефектів
Немає фіксованого стандарту для щільності дефектів. Дослідження показують, що дефект на тисячу рядків коду зазвичай вважається ознакою гарної якості проекту, і ця цифра є найчастіше цитованим емпіричним правилом у галузі.
Очікування змінюються разом із сферою застосування. Для критично важливого для безпеки та регульованого програмного забезпечення, такого як авіоніка та медичні прилади, цільовий показник є значно нижчим за один дефект на KLOC, тоді як звичайні бізнес-додатки зазвичай перевищують цей показник. Оскільки правила підрахунку, одиниці вимірювання розміру та глибина тестування відрізняються залежно від організації, контрольний показник, взятий з опублікованого дослідження, можна порівняти лише з проектом, який вимірює його однаково. Тому практичне використання метрики є внутрішнім: порівняйте реліз з попереднім релізом того ж продукту, виміряним ідентично.
Фактори, що впливають на щільність дефектів
Одна й та сама кодова база може створювати дуже різні показники щільності дефектів залежно від таких факторів:
- Code складність. Глибоко вкладена логіка та високий цикломатична складність створюють більше дефектів на рядок, ніж простий код.
- Тип дефектів, що враховуються. Враховуючи лише функціональні дефекти, або включаючи зручність використання, документацію та нефункціональний висновки, суттєво змінює чисельник.
- Врахований часовий проміжок. Показник, виміряний протягом двотижневого тестового циклу, не можна порівняти з показником, виміряним протягом шести місяців використання у виробничих умовах.
- Навички розробника та тестувальника. Досвідчені розробники впроваджують менше дефектів, а досвідчені тестувальники знаходять більше існуючих, тому ці два ефекти впливають на метрику в протилежних напрямках.
- Тестове покриття. Дефекти, які ніколи не шукалися, ніколи не враховуються, тому покриття тесту мовчки обмежує, наскільки високо може піднятися виміряна щільність.
Щільність дефектів порівняно з іншими показниками дефектів
Щільність дефектів відповідає на одне питання: наскільки концентровані відомі дефекти. Три супутні метрики дають відповіді на питання, на які вона не може відповісти, і більшість команд повідомляють про них разом.
| Metric | Що він вимірює | Питання, на яке воно відповідає |
| Щільність дефектів | Підтверджені дефекти, поділені за розміром (KLOC або функціональні бали) | Які модулі мають найбільше дефектів для свого розміру? |
| Дефект Витік | Дефекти, виявлені після випуску, як частка від усіх дефектів | Скільки матеріалу вийшло з процесу тестування та дійшло до користувачів? |
| Ефективність усунення дефектів | Дефекти, усунені до випуску, як частка від усіх дефектів | Наскільки ефективним було тестування у своєчасному виявленні дефектів? |
| Індекс серйозності дефектів | Дефекти, зважені за тяжкістю, а не враховані порівну | Наскільки шкідливими є дефекти, а не просто скільки? |
Разом ці чотири приклади дають повнішу картину: низька щільність дефектів з високою витоком дефектів вказує на поверхневе тестування, а не на чистий код, що є саме тим неправильним тлумаченням, про яке попереджає наступний розділ.
Переваги щільності дефектів
Нижче наведено переваги щільності дефектів:
- Це допомагає виміряти ефективність тестування.
- Це допомагає розрізняти концентрацію дефектів між компонентами та програмними модулями.
- Це корисно для визначення областей, які потребують виправлення або покращення.
- Це корисно для вказівки на компоненти високого ризику, що безпосередньо впливає на тестування на основі ризику.
- Це допомагає визначити потреби різних ресурсів у навчанні.
- Це може бути корисним для оцінки зусиль на тестування та переробку, спричинених дефектами.
- Він може оцінити залишки дефектів у програмному забезпеченні.
- Перед випуском це допомагає визначити, чи достатньо проведеного наразі тестування.
- Це створює історичну базову лінію, з якою можна порівнювати пізніші релізи.
Обмеження щільності дефектів
Цей показник легко розрахувати та легко неправильно інтерпретувати. Наступні обмеження визначають, яку вагу він має при прийнятті рішення про випуск:
- Невиявлені дефекти непомітні. Чисельник містить лише ті дефекти, які фактично виявили в результаті тестування, тому слабо протестований модуль показує задовільну цифру.
- Серйозність ігнорується. Один дефект, який пошкоджує платіж, та одна косметична проблема вирівнювання враховуються однаково, тому разом з ними потрібен підхід з урахуванням серйозності.
- Визначення дефектів різняться. Дві команди, які рахують по-різному, дають цифри, які неможливо порівняти навіть в межах однієї організації.
- Рядки коду є слабким показником розміру. Багатослівний код знижує щільність, нічого не покращуючи, а одиницю вимірювання не можна порівнювати між мовами програмування.
- Цю метрику можна підібрати. Відхилення пограничних звітів або завищення кількості рядків покращують показник, не покращуючи продукт.
Ніщо з цього не робить щільність дефектів марною. Це робить її показником тенденції для одного продукту, який вимірюється постійно, а не балом для порівняння команд одна з одною.
Як зменшити щільність дефектів
Зниження щільності дефектів насправді, а не на папері, означає запобігання дефектам раніше та виявлення решти до випуску продукту. Наведені нижче практики повторюються в опублікованих рекомендаціях:
- Перенесіть тестування раніше. Залучення тестувальників на етапі вимог та проектування виявляє неоднозначність ще до того, як вона стане кодом, а саме там, де дефекти найдешевше усунути.
- Revпереглянути код перед його об'єднанням. Експертна оцінка виявляє логічні помилки, неправильно прочитані вимоги та недоліки дизайну, яких немає одиничне випробування було написано для пошуку.
- Автоматизуйте набір регресійних алгоритмів. Виконання перевірок кожного коміту через безперервна інтеграція запобігає поверненню старих дефектів під час написання нового коду.
- Спочатку напишіть тести. Розробка на основі тестування змушує кожну поведінку бути визначеною до її реалізації, та тестування на мутації тоді можна підтвердити, що отримані тести дійсно щось стверджують.
- Використовуйте статичний аналіз. Автоматизоване сканування коду виявляє розіменування null, витоки ресурсів та гарячі точки складності перед запуском одного тесту.
- Рефакторинг щільних модулів. Після того, як метод щільності дефектів визначив найгірші компоненти, їх розділення та спрощення зазвичай зменшує як складність, так і кількість дефектів.
- Поверніть дефекти назад у процес. Аналіз першопричин під час ретроспектив перетворює окремі дефекти на виправлення процесу, а не на одноразові латки.
Tracреліз KED над релізом поряд методи тестування програмного забезпечення та дані про покриття, щільність дефектів стає системою раннього попередження, а не звітною карткою.
