Ce este densitatea defectelor? Formula de calculat cu Exemplu

⚡ Rezumat inteligent

Densitatea defectelor măsoară numărul de defecte confirmate într-un modul software împărțit la dimensiunea acelui modul, de obicei exprimată la o mie de linii de cod, și semnalează dacă o versiune este gata de lansare.

🔘 Formula: Densitatea defectelor este egală cu numărul de defecte confirmate împărțit la dimensiunea eliberării, cel mai adesea măsurată în KLOC.
☑️ Exemplu lucrat: Patruzeci de defecte pe trei mii de linii de cod dau 0.0133 defecte per LOC sau 13.333 defecte per KLOC.
✅ Etalon: Aproximativ un defect la o mie de linii de cod este considerat, în general, un semn al unei bune calități a proiectului.
🧪 Influențe: Code complexitatea, regulile de numărare a defectelor, fereastra de măsurare și abilitățile echipei - toate influențează numărul.
📊 Comparaţie: Scurgerea defectelor, eficiența eliminării defectelor și indicii de severitate nu pot răspunde la întrebările pe care densitatea defectelor singură nu le poate lua.
⚠️ Prudență: O valoare mică poate însemna o testare slabă, mai degrabă decât un cod curat, astfel încât metrica nu este niciodată independentă.

Citește mai mult

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ă.

metric	Ce măsoară	Întrebare îi răspunde
Densitatea defectelor	Defecte confirmate împărțite în funcție de dimensiune (KLOC sau puncte funcționale)	Care module prezintă cele mai multe defecte pentru dimensiunea lor?
Scurgere de defecte	Defecte găsite după lansare ca pondere din totalul defectelor	Cât a scăpat de procesul de testare și a ajuns la utilizatori?
Eficiența eliminării defectelor	Defecte eliminate înainte de lansare ca parte din toate defectele	Cât de eficientă a fost testarea în detectarea defectelor la timp?
Indicele de severitate a defectelor	Defecte ponderate în funcție de gravitate, mai degrabă decât numărate în mod egal	Cât de dăunătoare sunt defectele, nu doar câte sunt?

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

Majoritatea echipelor calculează acest lucru la sfârșitul testării sistemului, când rapoartele de defecte au fost triate și confirmate. Măsurarea la mijlocul ciclului subestimează cifra, deoarece rapoartele sunt încă deschise, iar măsurarea doar după lansare o transformă într-o metrică a scurgerilor.

Nu. Luați în considerare doar codul scris de echipă și pe care îl poate modifica. Includerea fișierelor generate, a bibliotecilor furnizorilor sau a codului de testare umflă numitorul și reduce artificial densitatea, ceea ce ascunde modulele care au nevoie cu adevărat de atenție.

Da. Echipele raportează de obicei o a doua cifră limitată la defecte critice și de severitate ridicată. Un modul cu o densitate generală moderată, dar cu mai multe defecte critice, prezintă un risc de lansare mai mare decât unul cu multe probleme cosmetice.

Da, cu un numitor diferit. Echipe agile Deseori, se normalizează defectele per poveste utilizator, per punct de poveste sau per funcționalitate livrată. Unitatea contează mai puțin decât utilizarea aceleiași unități în mod constant în sprinturi.

Modelele de predicție a defectelor învață din codul istoric și din metricile de proces, cum ar fi complexitatea, rata de abandon și numărul de defecte din trecut, pentru a clasifica fișierele care sunt cel mai probabil să fie defecte. Apoi, testerii își concentrează eforturile asupra modulelor cu cel mai mare risc înainte de a măsura o versiune.

Indirect. Copilot elaborează rapid teste unitare, scenarii limită și aserțiuni standard, ceea ce crește acoperirea și evidențiază defectele mai devreme. De asemenea, generează cod care necesită aceeași revizuire ca oricare altul, deci nu elimină niciodată necesitatea revizuirii inter pares.

În mod normal, șeful de teste sau managerul de asigurare a calității raportează acest lucru, dar regulile de numărare trebuie convenite mai întâi cu departamentul de dezvoltare și cu managerul de proiect. Fără o definiție convenită a unui defect confirmat și a codului numărabil, numărul nu este justificabil într-o întâlnire de lansare.

Nu neapărat. Un vârf de performanță înseamnă adesea că testarea a ajuns în sfârșit la un modul care anterior nu era afectat, ceea ce este o veste bună descoperită târziu. Citiți-l împreună cu acoperirea și tendința defectelor înainte de a-l trata ca pe o eroare de calitate.