Ce este densitatea defectelor? Formula de calculat cu Exemplu

Ce este densitatea defectelor?

Densitatea defectelor este numărul de defecte confirmate într-un software sau într-un modul în timpul unei anumite perioade de operare sau dezvoltare, împărțit la dimensiunea software-ului sau modulului respectiv. Acesta permite unei echipe să decidă dacă un software este gata de lansare.

Densitatea defectelor este calculată la o mie de linii de cod, cunoscută și sub numele de KLOC. Deoarece numărarea este normalizată în funcție de dimensiune, un modul mare cu multe defecte și un modul mic cu puține defecte pot fi comparate la aceeași scară, lucru pe care un număr brut de erori nu îl permite niciodată.

Metrica este raportată în mod normal la sfârșitul unui ciclu de testare și traclansare peste lansare, deci se află alături de restul procesul de management al defectelor în ciclul de viață al testării software.

Cum se calculează densitatea defectelor

O formulă pentru măsurarea densității defectelor:

Defect Density = Defect count/size of the release

Mărimea lansării poate fi măsurată în termeni de linie de cod (LOC).

Trei detalii decid dacă numărul rezultat are vreo semnificație:

• Unitatea de mărime. LOC și KLOC sunt cele mai comune unități. Punctele funcționale sunt utilizate acolo unde echipele doresc o măsură de dimensiune care nu se modifică odată cu limbajul de programare, iar unele echipe normalizează în funcție de modul sau de componentă.
• Ceea ce se califică drept defect. Doar defectele confirmate aparțin numărătorului. Duplicatele, rapoartele respinse și solicitările de îmbunătățire trebuie excluse, altfel cifra crește fără nicio modificare a calității codului.
• Fereastra de măsurare. Defecte descoperite în timpul testării sistemului, în timpul testarea regresieiși după lansare descriu lucruri diferite, așa că perioada trebuie indicată cu numărul.

Exemplu de densitate a defectelor

Să presupunem că aveți 3 module integrate în produsul dvs. software. Fiecare modul are următorul număr de erori descoperite:

• Modulul 1 = 10 bug-uri
• Modulul 2 = 20 bug-uri
• Modulul 3 = 10 bug-uri

Total erori = 10 + 20 + 10 = 40

Numărul total de linii de cod pentru fiecare modul este:

• Modulul 1 = 1000 LOC
• Modulul 2 = 1500 LOC
• Modulul 3 = 500 LOC

Linie totală de Code = 1000+1500+500 = 3000

Densitatea defectului se calculează astfel:

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

Același calcul aplicat per modul este mai util decât cifra combinată, așa cum arată graficul de mai jos: Modulul 2 are 20 de defecte în 1500 LOC, iar Modulul 3 are 10 defecte în doar 500 LOC, deci Modulul 3 este cel mai dens și mai riscant dintre cele două, chiar dacă a raportat mai puține erori.

Un standard pentru densitatea defectelor

Nu există un standard fix pentru densitatea defectelor. Studiile sugerează că este posibil să defect Valoarea per mia de linii de cod este în general considerată un semn al calității bune a proiectului, iar această cifră este regula generală cea mai citată în industrie.

Așteptările se modifică odată cu domeniul. Software-ul critic pentru siguranță și reglementat, cum ar fi avionica și dispozitivele medicale, este limitat la o țintă mult sub un defect per KLOC, în timp ce aplicațiile de business obișnuite se situează în mod obișnuit peste aceasta. Deoarece regulile de numărare, unitățile de dimensiune și profunzimea testelor diferă între organizații, un criteriu de referință preluat dintr-un studiu publicat este comparabil doar cu un proiect care măsoară în același mod. Prin urmare, utilizarea practică a metricii este internă: comparați o versiune cu versiunea anterioară a aceluiași produs, măsurată identic.

Factorii care afectează densitatea defectelor

Aceeași bază de cod poate produce cifre foarte diferite privind densitatea defectelor, în funcție de următorii factori:

• Code complexitate. Logică profund imbricată și înaltă complexitate ciclomatică produce mai multe defecte pe linie decât codul simplu.
• Tipul de defecte luat în considerare. Luând în considerare doar defectele funcționale sau incluzând utilizabilitatea, documentația și nefuncțional constatări, modifică substanțial numărătorul.
• Durata de timp considerată. O cifră măsurată pe parcursul unui ciclu de testare de două săptămâni nu este comparabilă cu una măsurată pe parcursul a șase luni de utilizare în producție.
• Abilități de dezvoltator și tester. Dezvoltatorii experimentați injectează mai puține defecte, iar testerii experimentați găsesc mai multe dintre cele existente, astfel încât cele două efecte trag metrica în direcții opuse.
• Acoperire de testare. Defectele care nu au fost niciodată căutate nu sunt niciodată luate în considerare, așadar acoperirea testului limitează în tăcere cât de mare poate ajunge densitatea măsurată.

Densitatea defectelor vs. alte metrici ale defectelor

Densitatea defectelor răspunde la o întrebare: cât de concentrate sunt defectele cunoscute. Trei metrici însoțitoare răspund la întrebările pe care nu le poate răspunde, iar majoritatea echipelor le raportează împreună.

Citite împreună, cele patru oferă o imagine mai completă: o densitate scăzută a defectelor cu puncte de scurgere a defectelor ridicate la testarea superficială, mai degrabă decât la cod curat, exact interpretarea greșită despre care avertizează secțiunea următoare.

Avantajele densității defectelor

Următoarele sunt avantajele densității defectelor:

• Ajută la măsurarea eficacității testării.
• Ajută la diferențierea concentrației de defecte între componente și modulele software.
• Este util în identificarea domeniilor care necesită corecții sau îmbunătățiri.
• Este util în indicarea componentelor cu risc ridicat, care influențează direct testarea bazată pe risc.
• Ajută la identificarea nevoilor de formare ale diferitelor resurse.
• Poate fi util în estimarea efortului de testare și refacere cauzat de defecte.
• Poate estima defectele rămase în software.
• Înainte de lansare, acest lucru ajută la determinarea dacă testele efectuate până în prezent sunt suficiente.
• Construiește o bază istorică în raport cu care pot fi comparate versiunile ulterioare.

Limitările densității defectelor

Metrica este ușor de calculat și ușor de interpretat greșit. Următoarele limitări decid câtă importanță are în luarea unei decizii de lansare:

• Defectele nedetectate sunt invizibile. Numărătorul conține doar defectele pe care testarea le-a găsit efectiv, astfel încât un modul slab testat raportează o cifră favorabilă.
• Severitatea este ignorată. Un defect care corupe o plată și o problemă de aliniere cosmetică sunt considerate la fel, motiv pentru care este necesară o vizualizare ponderată în funcție de severitate alături de acestea.
• Definițiile defectelor variază. Două echipe care numără diferit produc numere care nu pot fi comparate, nici măcar în cadrul aceleiași organizații.
• Liniile de cod sunt un proxy de dimensiune slabă. Codul detaliat reduce densitatea fără a îmbunătăți nimic, iar unitatea nu este comparabilă între limbaje de programare.
• Metrica poate fi manipulată. Respingerea rapoartelor la limită sau umflarea numărului de linii îmbunătățesc cifra fără a îmbunătăți produsul.

Nimic din toate acestea nu face Densitatea Defectelor inutilă. O transformă într-un indicator de tendință pentru un produs măsurat constant, mai degrabă decât într-un scor pentru a compara echipele între ele.

Cum să reduci densitatea defectelor

Reducerea densității defectelor, mai degrabă decât pe hârtie, înseamnă prevenirea defectelor mai devreme și găsirea restului înainte de lansare. Practicile de mai jos sunt cele care se regăsesc în ghidurile publicate:

• Mută ​​testarea mai devreme. Implicarea testerilor în etapa de cerințe și proiectare depistează ambiguitatea înainte ca aceasta să devină cod, acesta fiind punctul în care defectele sunt cel mai ieftin de eliminat.
• RevVizualizați codul înainte de a se îmbina. Evaluarea inter pares identifică erorile logice, cerințele interpretate greșit și defectele de proiectare pe care nu le poate identifica. test de unitate a fost scris pentru a căuta.
• Automatizați suita de regresie. Rularea verificărilor la fiecare commit prin integrare continuă împiedică reapariția defectelor vechi în timp ce se scrie cod nou.
• Scrieți teste mai întâi. Dezvoltare bazată pe teste obligă fiecare comportament să fie specificat înainte de a fi implementat și testarea mutațiilor poate apoi confirma că testele rezultate afirmă într-adevăr ceva.
• Folosește analiza statică. Scanarea automată a codului semnalează dereferențele nule, scurgerile de resurse și punctele sensibile la complexitate înainte de rularea unui singur test.
• Refactorizați modulele dense. Odată ce Densitatea Defectelor a identificat cele mai nefavorabile componente, divizarea și simplificarea acestora reduce de obicei atât complexitatea, cât și numărul de defecte.
• Introduceți defectele înapoi în proces. Analiza cauzelor principale în cadrul retrospectivelor transformă defectele individuale în remedieri de proces, mai degrabă decât în ​​corecții unice.

Traclansare ked peste lansare alături de tehnici de testare a software-ului și datele de acoperire, Densitatea Defectelor devine un sistem de avertizare timpurie, mai degrabă decât un raport.

Întrebări frecvente