Testarea software este un proces de cercetare, testarea unui produs software , care are ca scop verificarea corespondenței dintre comportamentul real al programului și comportamentul așteptat al acestuia pe un set final de teste selectate într-un anumit mod ( ISO /IEC TR 19759:2005) [ 1] .
Diverse definiții au fost date testării în diferite momente și în diverse surse, inclusiv:
Primele sisteme software au fost dezvoltate ca parte a programelor de cercetare științifică sau a programelor pentru nevoile departamentelor de apărare. Testarea acestor produse a fost efectuată într-o manieră strict formalizată, cu o înregistrare a tuturor procedurilor de testare, a datelor de testare și a rezultatelor obținute. Testarea a fost separată într-un proces separat, care a început după finalizarea codării, dar a fost de obicei efectuat de același personal.
În anii 1960, s-a pus mult accent pe testarea „exhaustivă”, care ar trebui făcută folosind toate căile din cod sau toate intrările posibile. S-a remarcat că în aceste condiții, testarea completă a software-ului nu este posibilă, deoarece, în primul rând, numărul de intrări posibile este foarte mare, în al doilea rând, există multe căi și, în al treilea rând, este dificil să găsiți probleme în arhitectură și specificații. Din aceste motive, testarea „exhaustivă” a fost respinsă și considerată teoretic imposibilă.
La începutul anilor 1970, testarea software-ului era denumită „procesul de demonstrare a corectitudinii unui produs” sau „activitatea de verificare a funcționării corecte a software-ului”. În ingineria software în curs de dezvoltare, verificarea software era denumită „dovada corectitudinii”. În timp ce conceptul a fost teoretic promițător, în practică a fost consumator de timp și nu suficient de cuprinzător. Sa decis că dovada corectitudinii este o metodă ineficientă de testare a software-ului. Cu toate acestea, în unele cazuri, demonstrarea funcționării corecte este folosită și astăzi, de exemplu, testele de acceptare. În a doua jumătate a anilor 1970, testarea a fost văzută ca rularea unui program cu intenția de a găsi erori, fără a dovedi că funcționează. Un test de succes este un test care descoperă probleme necunoscute anterior. Această abordare este direct opusă celei anterioare. Aceste două definiții reprezintă „paradoxul testării”, care se bazează pe două afirmații opuse: pe de o parte, testarea vă permite să vă asigurați că produsul funcționează bine și, pe de altă parte, dezvăluie erori în programe, arătând că produsul nu funcționează. Al doilea obiectiv al testării este mai productiv în ceea ce privește îmbunătățirea calității, deoarece nu permite ignorarea defectelor software.
În anii 1980, testarea s-a extins pentru a include prevenirea defectelor. Proiectarea testului este cea mai eficientă tehnică cunoscută de prevenire a erorilor. În același timp, au început să fie exprimate gânduri că era necesară o metodologie de testare, în special, că testarea ar trebui să includă verificări pe tot parcursul ciclului de dezvoltare, iar acesta ar trebui să fie un proces controlat. În timpul testării, este necesar să se verifice nu numai programul asamblat, ci și cerințele, codul, arhitectura și testele în sine. Testarea „tradițională”, care a existat până la începutul anilor 1980, s-a referit doar la sistemul compilat, terminat (denumit acum în mod obișnuit testarea sistemului), dar de atunci, testerii s-au implicat în toate aspectele ciclului de viață al dezvoltării. Acest lucru a făcut posibilă găsirea mai devreme a problemelor în cerințele și arhitectura, reducând astfel timpul și bugetul de dezvoltare. La mijlocul anilor 1980 au apărut primele instrumente de testare automată. Computerul trebuia să poată efectua mai multe teste decât un om și să facă acest lucru mai fiabil. La început, aceste instrumente erau extrem de simple și nu aveau capacitatea de a scrie scripturi în limbaje de scripting.
La începutul anilor 1990, conceptul de „testare” a început să includă planificarea, proiectarea, crearea, menținerea și executarea testelor și mediilor de testare, iar aceasta a însemnat o tranziție de la testare la asigurarea calității, acoperind întregul ciclu de dezvoltare a software-ului. În acest moment, au început să apară diverse instrumente software pentru a sprijini procesul de testare: medii de automatizare mai avansate, cu capacitatea de a crea scripturi și de a genera rapoarte, sisteme de management al testelor și software de testare a încărcării. La mijlocul anilor 1990, odată cu dezvoltarea Internetului și dezvoltarea unui număr mare de aplicații web, „testarea agilă” (similar cu metodologiile de programare agilă) a început să câștige o popularitate deosebită.
Există mai multe criterii după care se obișnuiește să se clasifice tipurile de testare. De obicei, există următoarele:
După obiectul testăriiAdesea, pentru software-ul gratuit și open source, etapa de testare alfa caracterizează conținutul funcțional al codului, iar testarea beta caracterizează etapa de remediere a erorilor. În același timp, de regulă, în fiecare etapă de dezvoltare, rezultatele intermediare ale muncii sunt disponibile pentru utilizatorii finali.
Tehnicile descrise mai jos - testarea cutiei albe și testarea cutiei negre - presupun că codul se execută, iar diferența este doar în informațiile pe care le are testerul. În ambele cazuri, aceasta este o testare dinamică .
În timpul testării statice, codul programului nu este executat - programul este analizat pe baza codului sursă, care este citit manual sau analizat cu instrumente speciale. În unele cazuri, nu codul sursă este analizat, ci codul intermediar (cum ar fi codul octet sau codul MSIL ).
Testarea statică include, de asemenea, cerințe de testare , specificații , documentație .
După efectuarea modificărilor la următoarea versiune a programului, testele de regresie confirmă că modificările efectuate nu au afectat performanța restului funcționalității aplicației. Testarea regresiei poate fi efectuată atât manual, cât și cu instrumente de automatizare a testelor .
Testerii folosesc scenarii de testare la diferite niveluri: atât în testarea componentelor, cât și în integrarea și testarea sistemului. Scripturile de testare sunt de obicei scrise pentru a testa componentele care sunt cel mai probabil să eșueze, sau o eroare care nu este găsită la timp poate fi costisitoare.
În funcție de accesul dezvoltatorului de testare la codul sursă al programului testat, se face o distincție între „ testarea (prin strategie) a unei cutii albe ” și „ testarea (prin strategie) a unei cutii negre ”.
În testarea cutiei albe (numită și testarea casetei transparente ), dezvoltatorul testului are acces la codul sursă al programelor și poate scrie cod care face legătura cu bibliotecile software-ului testat. Acest lucru este tipic pentru testarea componentelor, în care sunt testate doar părți ale sistemului. Se asigură că componentele structurale sunt funcționale și stabile, într-o anumită măsură. Testarea cutiei albe folosește valorile de acoperire a codului sau testarea mutațiilor .
În testarea cutie neagră, testerul are acces la program numai prin aceleași interfețe ca și clientul sau utilizatorul, sau prin interfețe externe care permit unui alt computer sau alt proces să se conecteze la sistem pentru testare. De exemplu, o componentă de testare poate apăsa virtual tastele sau butoanele mouse-ului în programul testat folosind mecanismul de comunicare a procesului, cu încrederea că totul merge bine, că aceste evenimente provoacă același răspuns ca și apăsările reale de taste și butoanele mouse-ului. De regulă, testarea cutiei negre se efectuează folosind specificații sau alte documente care descriu cerințele pentru sistem. De obicei, în acest tip de testare , criteriul de acoperire este suma acoperirii structurii datelor de intrare, acoperirea cerințelor și acoperirea modelului (în testarea bazată pe model ).
În testarea cu casetă gri, dezvoltatorul testului are acces la codul sursă, dar atunci când rulează teste direct, accesul la cod nu este de obicei necesar.
În timp ce „testarea alfa” și „testarea beta” se referă la etapele înainte de lansarea unui produs (și, de asemenea, implicit, la dimensiunea comunității de testare și la limitările metodelor de testare), testarea cutie albă și cutie neagră se referă la modalitățile în care testerul atinge scopul.
Testarea beta este, în general, limitată la tehnicile cutiei negre (deși un subset consistent de testeri continuă, de obicei, testarea cutiei albe în paralel cu testarea beta). Astfel, termenul „testare beta” poate indica starea programului (mai aproape de lansare decât „alfa”), sau poate indica un anumit grup de testeri și procesul efectuat de acest grup. Adică, un tester poate continua să lucreze la testarea cutie albă chiar dacă programul este deja „beta”, dar în acest caz nu face parte din „testarea beta”.
Acoperirea codului arată procentul din codul sursă al unui program care a fost executat („acoperit”) în timpul testării. În funcție de metodele de măsurare, acoperirea operatorului, acoperirea condiției, acoperirea traseului, acoperirea funcției etc.
| Dezvoltare de software | |
|---|---|
| Proces | |
Concepte de nivel înalt | |
| Directii |
|
| Metodologii de dezvoltare | |
| Modele |
|
Cifre notabile |
|