Rigor în captarea cazurilor de testare pentru testarea unității

Să presupunem că avem o funcție simplă definită într-o limbă pseudo.

List SortNumbers(List unsorted, bool ascending);

Trecem într-o listă nesaturată de numere și o ordine booleană specificând ordinea de sortare ascendentă sau descendentă. În schimb, primim o listă sortată de numere.

Din experiența mea, unii oameni sunt mai buni la capturarea condițiilor de graniță decât alții. Întrebarea este: "De unde știi când ești" făcut "capturarea cazurilor de testare"?

Putem începe să enumerăm cazuri acum și un om inteligent se va gândi, fără îndoială, la un caz "încă unul" care nu este acoperit de nici unul dintre cei precedenți.

 0
adăugat editat
Vizualizări: 3
sursa
fr hi bn
Cu o metodă simplă, autonomă, încercați să o executați prin intermediul lui Pex. S-ar putea să vă surprindeți ce poate găsi. research.microsoft.com/en-us/projects/pex
adăugat autor Dan Bryant, sursa

5 răspunsuri

@Keith

Cred că ați bătut-o, acoperirea codului este importantă pentru a vă uita dacă doriți să vedeți cât de "făcut" sunteți, dar cred că 100% este un scop puțin nerealist. Sustinând 75-90% vă va oferi o acoperire destul de bună fără a trece peste bord ... nu testați pentru motivele pure de a lovi 100%, pentru că în acest moment vă pierdeți doar timpul.

0
adăugat
sursa

Nu pierdeți prea mult timp încercând să vă gândiți la starea de limitare every . Testele dvs. nu vor putea prinde prima eroare fiecare . Ideea este să aveți teste care sunt destul de bune și apoi de fiecare dată când o eroare face suprafața, scrieți un test nou specific pentru acea eroare, astfel încât să nu mai auzi din nou .

O altă notă pe care vreau să o fac despre instrumentele de acoperire a codului. Într-o limbă precum C# sau Java în cazul în care aveți multe metode de obținere/setare și metode similare, trebuie să nu să fotografiați pentru o acoperire de 100%. Asta înseamnă că pierzi prea mult timp scriind teste pentru codul banal. Doar numai doriți o acoperire de 100% pe logica dvs. complexă de afaceri. Dacă baza dvs. de cod completă este mai aproape de acoperirea de 70-80%, faceți o treabă bună. Dacă instrumentul de acoperire a codului permite metrici de acoperire multiple, cea mai bună este "acoperirea blocurilor" care măsoară acoperirea "blocurilor de bază". Alte tipuri sunt acoperirea claselor și a metodei (care nu vă oferă prea multe informații) și acoperirea liniilor (care este o granulă prea fină).

0
adăugat
sursa

Un bun instrument de acoperire a codului vă ajută într-adevăr.

Acoperirea de 100% nu înseamnă că este cu siguranță testată în mod adecvat, dar este un indicator bun.

Pentru .Net NCover este destul de bun, dar nu mai este open source.

@Mike Stone - Da, poate că ar fi trebuit să fie "acoperire înaltă" - ne propunem un minim de 80%, în jur de 95%, de obicei se diminuează întoarcerea, mai ales dacă aveți codul "n".

0
adăugat
sursa

Din punct de vedere practic, creez o listă de teste care cred că trebuie să treacă înainte de acceptare. Le testez și automatizez acolo unde este posibil. În funcție de cât timp am estimat pentru sarcină sau cât timp am fost dat, mă întind acoperirea de testare pentru a include elemente care ar trebui să treacă înainte de acceptare. Desigur, linia dintre must și ar trebui să fie subiectivă. După aceasta, actualizez testele automate ca fiind detectate bug-uri.

0
adăugat
sursa

De unde știți când ați terminat capturarea cazurilor de testare?

Tu nu poți ajunge la 100%, cu excepția cazurilor cele mai banale. De asemenea, acoperirea de 100% (de linii, căi, condiții ...) nu vă spune că ați atins toate condițiile limită.

Cel mai important, cazurile de testare nu sunt scrise și uitate. De fiecare dată când găsiți o eroare, scrieți un test suplimentar. Verificați dacă eșuează cu programul original, verificați dacă trece cu programul corectat și adăugați-l în setul dvs. de testare.

Un extras din Arta testării software de Glenford J Myers:

  1. Dacă o condiție de intrare specifică o gamă de valori, scrieți cazuri de testare pentru capetele intervalului și cazuri de teste de intrare nevalidă pentru situații care se află la limită.
  2. Dacă o condiție de intrare specifică un număr de valori, scrieți cazuri de testare pentru numărul minim și maxim de valori și unul sub și peste aceste valori.
  3. Utilizați indicația 1 pentru fiecare condiție de ieșire.
  4. Utilizați indicația 2 pentru fiecare condiție de ieșire.
  5. Dacă intrarea sau ieșirea unui program este o atenție a focalizării setată pe primul și ultimul element al setului.
  6. În plus, folosiți ingeniozitatea dvs. pentru a căuta alte condiții limită

( Am lipit doar minimul gol din motive de copyright. )

Punctele 3. și 4. de mai sus sunt foarte importante. Oamenii tind să uite condițiile limită pentru ieșiri. 5. este OK. 6. într-adevăr nu ajută :-)

Scurt examen

Acest lucru este mai dificil decât pare. Myers oferă acest test:

Programul citește trei valori întregi dintr-un dialog de intrare. Cele trei valori reprezintă lungimile laturilor unui triunghi. Programul afișează un mesaj care precizează dacă triunghiul este scalene, isoscele sau echilateral.

     

Amintiți-vă că un triunghi cu scală este unul în care nici două laturi nu sunt egale, în timp ce un triunghi isoscel are două laturi egale, iar un triunghi echilateral are trei laturi de lungime egală. Mai mult decât atât, unghiurile opuse laturilor egale într-un triunghi isoscel sunt, de asemenea, egale (de asemenea, rezultă că laturile opuse unghiurilor egale într-un triunghi sunt egale), și toate unghiurile într-un triunghi echilateral sunt egale.

Scrieți cazurile de testare. Cât de multe aveți? Myers solicită 14 întrebări despre setul dvs. de testare și raportează că programele profesionale înalt calificate medie 7,8 dintr-un posibil 14.

0
adăugat
sursa