Какво е плътност на дефектите? Формула за изчисляване с Пример

⚡ Умно обобщение

Плътността на дефектите измерва броя на потвърдените дефекти в софтуерен модул, разделен на размера на този модул, обикновено изразен на хиляда реда код, и сигнализира дали дадена компилация е готова за пускане.

🔘 Формула: Плътността на дефектите е равна на потвърдения брой дефекти, разделен на размера на изпускането, най-често измерван в KLOC.
☑️ Разработен пример: Четиридесет дефекта в три хиляди реда код дават 0.0133 дефекта на LOC или 13.333 дефекта на KLOC.
✅ Бенчмарк: Около един дефект на хиляда реда код се счита за знак за добро качество на проекта.
🧪 Влияния: Code сложността, правилата за броене на дефекти, прозорецът за измерване и уменията на екипа - всички те влияят на числото.
📊 Сравнение: Индексите за изтичане на дефекти, ефективност на отстраняване на дефекти и индексите за тежест не могат да отговорят на въпроси, на които плътността на дефектите сама по себе си не може.
⚠️ Внимание: Ниската стойност може да означава слабо тестване, а не чист код, така че метриката никога не е самостоятелна.

Прочетете повече

Какво е плътност на дефектите?

Плътност на дефекта е броят на потвърдените дефекти в софтуер или модул по време на определен период на работа или разработка, разделен на размера на този софтуер или модул. Това позволява на екипа да реши дали даден софтуер е готов за пускане.

Плътността на дефектите се брои на хиляда реда код, известна още като 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 сложност. Дълбоко вложена логика и високо цикломатична сложност произвеждат повече дефекти на ред, отколкото обикновеният код.
Видът на дефектите, които се вземат предвид. Преброяване само на функционални дефекти или включване на използваемост, документация и нефункционален констатациите, променя числителя съществено.
Разглежданата продължителност от време. Цифра, измерена в рамките на двуседмичен тестов цикъл, не е сравнима с такава, измерена в рамките на шест месеца производствена употреба.
Умения за разработчици и тестери. Опитните разработчици инжектират по-малко дефекти, а опитните тестери намират повече от съществуващите, така че двата ефекта дърпат метриката в противоположни посоки.
Тестово покритие. Дефектите, които никога не са били търсени, никога не се броят, така че покритие на теста тихо ограничава колко високо може да достигне измерената плътност.

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

Плътността на дефектите отговаря на един въпрос: колко концентрирани са известните дефекти. Три съпътстващи метрики отговарят на въпросите, на които не може да отговори, и повечето екипи ги отчитат заедно.

метричен	Какво измерва	Въпрос, на който отговаря
Плътност на дефекта	Потвърдени дефекти, разделени по размер (KLOC или функционални точки)	Кои модули имат най-много дефекти за техния размер?
Дефектно изтичане	Дефекти, открити след пускането на пазара, като дял от всички дефекти	Колко от тях е избегнало тестовия процес и е достигнало до потребителите?
Ефективност на отстраняване на дефекти	Дефекти, отстранени преди пускане в продажба, като дял от всички дефекти	Колко ефективно беше тестването при откриването на дефекти навреме?
Индекс на тежест на дефекта	Дефектите се претеглят по тежест, а не се броят по равно	Колко вредни са дефектите, не просто колко са на брой?

Разгледани заедно, четирите дават по-пълна картина: ниска плътност на дефектите с високо изтичане на дефекти сочи към повърхностно тестване, а не към чист код, което е точно погрешното тълкуване, за което предупреждава следващият раздел.

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

Следните са предимствата на плътността на дефектите:

Това помага да се измери ефективността на тестването.
Това помага да се разграничи концентрацията на дефекти между компонентите и софтуерните модули.
Полезно е за идентифициране на областите, които се нуждаят от корекция или подобрение.
Полезно е при насочване към компоненти с висок риск, което директно се отразява на тестване, основано на риска.
Това помага при идентифицирането на нуждите от обучение на различни ресурси.
Това може да бъде полезно при оценката на усилията за тестване и преработка, причинени от дефекти.
Може да оцени оставащите дефекти в софтуера.
Преди пускането, това помага да се определи дали извършените досега тестове са достатъчни.
Това изгражда историческа базова линия, спрямо която могат да се сравняват по-късните издания.

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

Метриката е лесна за изчисляване и лесна за погрешно тълкуване. Следните ограничения определят каква тежест заслужава при вземането на решение за издаване:

Неоткритите дефекти са невидими. Числителят съдържа само дефекти, които тестването действително е открило, така че слабо тестван модул отчита ласкателна цифра.
Тежестта се игнорира. Един дефект, който поврежда плащането, и един козметичен проблем с подравняването се броят за еднакви, поради което е необходим преглед, претеглен по тежест, заедно с тях.
Дефинициите на дефектите варират. Два екипа, които броят по различен начин, водят до числа, които не могат да бъдат сравнявани, дори в рамките на една и съща организация.
Редовете код са слаб заместител на размера. Многословният код намалява плътността, без да подобрява нищо, а единицата не е сравнима в различните езици за програмиране.
Метриката може да бъде манипулирана. Отхвърлянето на гранични доклади или завишаването на броя на редовете подобряват цифрата, без да подобряват продукта.

Нищо от това не прави плътността на дефектите безполезна. Това я прави индикатор за тенденция за един продукт, измерван постоянно, а не резултат за сравняване на екипи един с друг.

Как да намалим плътността на дефектите

Намаляването на плътността на дефектите реално, а не на хартия, означава предотвратяване на дефектите по-рано и откриване на останалите преди пускането им на пазара. Практиките по-долу са тези, които се повтарят в публикуваните насоки:

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

Tracked освобождаване над освобождаване успоредно техники за тестване на софтуер и данни за покритието, плътността на дефектите се превръща в система за ранно предупреждение, а не в отчетна карта.

Въпроси и Отговори

Повечето екипи го изчисляват в края на системното тестване, когато докладите за дефекти са били сортирани и потвърдени. Измерването в средата на цикъла подценява цифрата, защото докладите все още са отворени, а измерването само след пускането на продукта го превръща в показател за течове.

Не. Бройте само кода, който екипът е написал и може да промени. Включването на генерирани файлове, библиотеки на доставчици или тестов код завишава знаменателя и изкуствено намалява плътността, което скрива модулите, които наистина се нуждаят от внимание.

Да. Екипите обикновено отчитат втора цифра, ограничена до критични и високосериозни дефекти. Модул с умерена обща плътност, но с няколко критични дефекта, представлява по-голям риск от пускане на пазара, отколкото такъв с много козметични проблеми.

Да, с различен знаменател. Подвижни екипи често нормализират дефектите за всяка потребителска история, за всяка точка от историята или за всяка предоставена функция. Единицата има по-малко значение от използването на една и съща последователно в различните спринтове.

Моделите за прогнозиране на дефекти се учат от исторически показатели за код и процес, като сложност, отлив и минали бройки дефекти, за да класират кои файлове е най-вероятно да са дефектни. След това тестерите насочват усилията си към модулите с най-висок риск, преди да се измери компилацията.

Косвено. Copilot бързо изготвя модулни тестове, крайни сценарии и шаблонни твърдения, което увеличава покритието и разкрива дефекти по-рано. Също така генерира код, който се нуждае от същия преглед като всеки друг, така че никога не премахва необходимостта от експертна проверка.

Ръководителят на теста или QA мениджърът обикновено го докладва, но правилата за броене трябва първо да бъдат съгласувани с разработчика и ръководителя на проекта. Без съгласувано определение за потвърден дефект и за броим код, броят не е защитим на среща за пускане на продукта.

Не е задължително. Скокът често означава, че тестването най-накрая е достигнало до модул, който преди това е бил недокоснат, което е добра новина, открита късно. Прочетете го заедно с покритието и тенденцията на дефектите, преди да го третирате като провал на качеството.