Testare White-Box

Testarea în cutie albă este o tehnică de verificare pe care inginerii software o pot folosi pentru a examina dacă codul lor funcționează așa cum este de așteptat. În acest capitol, vom explica următoarele:

- o metodă de scriere a unui set de cazuri de testare pentru cutii albe care exercită căile din cod

- utilizarea partiționării echivalenței și a analizei valorilor de graniță pentru a gestiona numărul de cazuri de testare care trebuie scrise și pentru a examina cazurile de testare „colț” predispuse la erori / extreme

- modul de măsurare a modului în care cazurile de testare exercită codul

Testarea la cutie albă este testarea care ține cont de mecanismul intern al unui sistem sau componentă (IEEE, 1990). Testarea în cutii albe este cunoscută și sub denumirea de testare structurală, testare în cutii clare și testare în cutii de sticlă (Beizer, 1995). Conotațiile „cutiei clare” și „cutiei de sticlă” indică în mod corespunzător că aveți o vizibilitate deplină a funcționării interne a produsului software, în special, logica și structura codului.

Folosind tehnicile de testare în cutie albă prezentate în acest capitol, un inginer software poate proiecta cazuri care (1) să exercite căi independente în cadrul unui modul sau unitate; (2) să exercite decizii logice atât pe partea lor adevărată, cât și pe cea falsă; (3) să execute bucle la granițele lor și în limitele lor operaționale; și (4) să exercite structuri interne de date pentru a le asigura validitatea (Pressman, 2001).

Există șase tipuri de testare de bază: unitate, integrare, funcție / sistem, acceptare, regresie și beta. Testarea în cutie albă este utilizată pentru trei dintre aceste șase tipuri:

- Testarea unităților, care testează unități hardware individuale sau software sau grupuri de unități conexe (IEEE, 1990). O unitate este o componentă software care nu poate fi împărțită în alte componente (IEEE, 1990). Inginerii software scriu cazuri de testare în cutie albă pentru a examina dacă unitatea este codată corect. Testarea unității este importantă pentru asigurarea codului solid înainte de a fi integrat cu alt cod. Odată ce codul este integrat în baza codului, cauza unui eșec observat este mai dificil de găsit. De asemenea, din moment ce inginerul software scrie și execută teste ale unității, el de multe ori companiile nu urmăresc defecțiunile de testare a unității, ceea ce face ca aceste tipuri de defecte să fie cele mai „private” pentru inginerul software. Cu toții preferăm să ne găsim propriile greșeli și să avem ocazia să le remediem fără ca alții să știe. Aproximativ 65% din toate erorile pot fi surprinse în testarea unității (Beizer, 1990).

- Testarea integrării, care este testarea în care componentele software, componentele hardware sau ambele sunt combinate și testate pentru a evalua interacțiunea dintre ele (IEEE, 1990). Sunt scrise cazuri de test care examinează în mod explicit interfețele dintre diferitele unități. Aceste cazuri de testare pot fi cazuri de testare la cutie neagră, prin care testatorul înțelege că un caz de testare necesită mai multe unități de program pentru a interacționa. În mod alternativ, sunt scrise cazuri de testare în cutii albe care exercită explicit interfețele care sunt cunoscute de către tester.

- Testarea de regresie, care este testarea selectivă a unui sistem sau componentă pentru a verifica dacă modificările nu au provocat efecte neintenționate și că sistemul sau componenta respectă în continuare cerințele specificate (IEEE, 1990). La fel ca în cazul testării de integrare, testarea de regresie poate fi făcută prin teste cu cutie neagră, cazuri de testare cu cutie albă sau o combinație a celor două. Cazurile albe și testele de integrare pot fi salvate și reluate ca parte a testelor de regresie.

1. Testarea în cutie albă de către stube și șoferi

Cu testarea în caseta albă, trebuie să rulați codul cu intrare predeterminată și să vă asigurați că codul produce ieșiri prestabilite. Adesea, programatorii scriu butoane și drivere pentru testarea în cutii albe. Un driver este un modul software utilizat pentru a invoca un modul testat și, adesea, furnizează intrări de testare, controlează și monitorizează execuția și raportează rezultatele testelor (IEEE, 1990) sau cel mai simplu o linie de cod care apelează o metodă și trece acea metodă o valoare. De exemplu, dacă doriți să mutați o instanță Player, Player1, două spații pe placă, codul driverului ar fi

movePlayer (Player1, 2);

Probabil că acest cod de driver va fi apelat din metoda principală. Un caz de test cu cutie albă ar executa această linie de cod a driverului și ar verifica Player.getPosition () pentru a vă asigura că jucătorul este acum pe celula așteptată de pe placă.

Un stub este o declarație de program computer care înlocuiește corpul unui modul software care este sau va fi definit în altă parte (IEEE, 1990) sau o componentă sau obiect manechin folosit pentru a simula comportamentul unei componente reale (Beizer, 1990) până la acea componentă a fost dezvoltat. De exemplu, dacă metoda movePlayer nu a fost încă scrisă, s-ar putea utiliza temporar un ciot cum este cel de mai jos - care mută orice jucător pe poziția 1.