Testarea software-ului

De la Wikipedia, enciclopedia liberă.
Salt la navigare Salt la căutare
Notă despre dezambiguizare.svg Dezambiguizare - "Testare" se referă aici. Dacă sunteți în căutarea albumului ASAP Rocky din 2018, consultați Testarea (albumul) .

Testarea software (numită și testare sau testare software conform denumirilor în limba engleză ), în informatică , indică o procedură, care face parte din ciclul de viață al software-ului , utilizată pentru a identifica deficiențele de corectitudine , completitudine și fiabilitate ale componentelor software în curs de desfășurare de dezvoltare. Acesta constă în executarea software-ului de către tester, singur sau în combinație cu alte software-uri de servicii și în evaluarea dacă comportamentul software-ului îndeplinește cerințele . Testarea, care face parte din procedurile de asigurare a calității , este uneori confundată cu depanarea , profilarea sau analiza comparativă .

Descriere generala

În general, este necesar să se facă distincția între „defecțiunile” software-ului (în engleză, „failure”), de „defectele” (sau „erorile” sau „bug-urile”) ale software-ului (în limba engleză, „fault” sau „defect” sau „eroare”). O defecțiune este un comportament software care se abate de la cerințele explicite sau implicite. În practică, apare atunci când, în absența defecțiunilor platformei (hardware + software de bază), sistemul nu face ceea ce se așteaptă utilizatorul.

Un defect este o secvență de instrucțiuni, sursă sau executabil, care, atunci când este executată cu anumite date de intrare, generează o defecțiune. În practică, o defecțiune apare numai atunci când codul care conține defectul este executat și numai dacă datele de intrare sunt de natură să evidențieze eroarea. De exemplu, dacă în loc să scrie „a> = 0”, programatorul a scris greșit „a> 0” într-o instrucțiune, o defecțiune poate apărea numai atunci când acea instrucțiune este executată în timp ce variabila „a” este zero. Scopul testării este de a detecta defectele prin defecțiuni, pentru a minimiza probabilitatea ca software-ul distribuit să funcționeze defectuos în funcționare normală.

Niciun test nu poate reduce această probabilitate la zero, deoarece combinațiile posibile de valori de intrare valide sunt enorme și nu pot fi reproduse într-un timp rezonabil; cu toate acestea testarea bună poate face ca probabilitatea de eșec să fie suficient de scăzută pentru a fi acceptabilă pentru utilizator. Acceptabilitatea unei probabilități date de eșec depinde de tipul aplicației.

Software-ul pentru care este necesară cea mai înaltă calitate este așa-numitul „critic de viață” („critic de siguranță”), adică în care o defecțiune poate pune în pericol viața umană, precum cea pentru echipamentele medicale sau aeronautice. Pentru un astfel de software, este acceptată doar o probabilitate foarte mică de defecțiune și, prin urmare, testarea este foarte amănunțită și riguroasă. Pentru a detecta cât mai multe defecte posibil, software-ul este îndemnat la testare să execute cât mai mult cod posibil cu o varietate de date de intrare.

De asemenea, se poate întâmpla ca o eroare în codul sursă să provoace o defecțiune numai dacă utilizați un anumit compilator sau interpret , sau numai dacă rulați pe o anumită platformă. Prin urmare, poate fi necesar să testați software-ul cu diverse medii de dezvoltare și cu diverse platforme de utilizare.

Tehnicile de testare pot fi clasificate în multe moduri. Principalele sunt următoarele:

  • După modelul de dezvoltare: cascadă, condus de testare.
  • După nivelul de cunoaștere a funcțiilor interne: casetă albă, casetă neagră.
  • Indiferent dacă testerii aparțin sau nu organizației care modifică sursele, precum și după faza de dezvoltare: Alpha, Beta.
  • După gradul de automatizare: manual, semiautomat, complet automatizat.
  • Prin granularitate: testarea modulelor, testarea sistemului.
  • După gradul de formalitate: de la informal la formal.

Verificare si validare

Faza de verificare și validare servește pentru a se asigura că software - ul reflectă cerințele și că le respectă în mod corespunzător.

Exact:

  • verificarea servește pentru a stabili dacă software-ul îndeplinește cerințele și specificațiile, astfel încât, de exemplu, să nu lipsească cerințele,
  • în timp ce validarea servește pentru a se asigura că cerințele și specificațiile sunt, de asemenea, respectate în mod corect.

Această fază, de fapt, este foarte delicată deoarece, dacă software-ul trece verificarea, dar nu validarea, după întregul proces este posibil să se obțină un software perfect funcțional, fără erori, dar complet inutil, deoarece nu reflectă ceea ce a fost solicitat. la început (în acest caz, nu îndeplinește setul complet de funcționalități așteptate și, prin urmare, nu servește scopului proiectului, poate exista riscul ca acesta să fie respins de client).

Conform modelului aplicat, această fază se aplică etapelor intermediare sau întregului software.

Verificarea poate fi statică , dacă este realizată pe hârtie, adică în proiect, sau dinamică , dacă este efectuată prin testarea aceluiași software cu date de testare.

Model de dezvoltare

Dezvoltare în cascadă

Metoda tradițională de dezvoltare a software-ului , numităcascadă ” (în engleză „cascadă”), prescrie începerea testului finalizat imediat după prima versiune a produsului. Rezultatele testului sunt folosite pentru a revizui cerințele sau designul sau codul și, astfel, să producă următoarea versiune.

Acest proces a fost criticat sever deoarece prezintă următoarele dezavantaje:

  • Dacă a venit data preconizată pentru finalizarea produsului, există tendința de a-l livra chiar dacă testul nu a fost finalizat sau a eșuat, ceea ce înseamnă că probabil livrați un produs slab.
  • Probabil, cerințele nu includeau „testabilitatea” (în engleză, „ testabilitatea ”), adică proiectul și codul nu conțin dispozitive care să faciliteze testarea. În acest caz, testarea va fi mult mai scumpă și mai puțin eficientă.
  • Cu cât trece mai mult timp între introducerea unei erori într-un sistem și raportarea unei defecțiuni datorate acestei erori, cu atât este mai dificil și mai costisitor să o remediați.
  • Deoarece se așteaptă ca software-ul dintr-un astfel de model să fie testat numai după finalizarea fazei de dezvoltare, orice feedback colectat în faza de testare nu poate fi utilizat pentru a alimenta cu promptitudine învățarea echipei de dezvoltare, astfel încât calitatea codului să poată fi îmbunătățită ca în metode iterative și incrementale (așa cum se poate întâmpla de exemplu în metodele „ agile ”). Prin urmare, în modelul de dezvoltare în cascadă, „lecțiile învățate” pot fi utilizate numai în orice proiecte de dezvoltare ulterioare, care limitează adesea valoarea adăugată reală, deoarece distanța în timp de la faza de colectare nu facilitează aplicarea.

Dezvoltare bazată pe test

Pictogramă lupă mgx2.svg Același subiect în detaliu: Test Driven Development .

O procedură mai recentă, numită „ test driven development ” (în engleză, „ test driven development ”), propusă de la începutul anilor 1990, constă în luarea în considerare a testării ca parte integrantă a produsului:

  • Când se analizează cerințele software care urmează să fie produse, sunt analizate cerințele de testare.
  • La proiectarea arhitecturii software care urmează să fie produsă, arhitectura de testare este proiectată.
  • Când scrieți codul software care urmează să fie produs, scrieți codul rutinelor automate de testare sau pregătiți datele și scrieți instrucțiunile pentru testerul manual.
  • Când construiți executabile prin compilarea surselor, dacă compilarea are succes, rutinele de testare automată sunt executate automat. Cu toate acestea, testele interactive inerente sunt relegate la o procedură parțial manuală.
  • Când arhivați sau recuperați o versiune a surselor, arhivați sau recuperați toate documentele de testare menționate anterior. Într-adevăr, aceste documente trebuie înțelese ca părți integrante ale surselor.

Etape de distribuție

Testul de tip Alpha

Pictogramă lupă mgx2.svg Același subiect în detaliu: versiunea Alpha .

De îndată ce un software a fost construit, înainte de a-l distribui în afara companiei, acesta este în mod normal supus testării interne în cadrul companiei.

Testarea alfa poate fi efectuată chiar de către programatori sau de către personalul companiei.

Adesea, software-ul produs pentru testarea Alpha este îmbogățit cu instrucțiuni de control în timp de rulare care facilitează detectarea erorilor. Exemple de astfel de instrucțiuni sunt:

  • verificarea faptului că nu sunt accesate indexuri nevalide ale matricelor;
  • verificarea faptului că toată memoria alocată nu este alocată înainte de terminare;
  • declarații declarative scrise de programator.

În unele cazuri, în special pentru dezvoltarea de software de sistem sau software încorporat , se utilizează un mediu de execuție hardware care acceptă în mod specific depanarea și testarea.

Testarea beta

Pictogramă lupă mgx2.svg Același subiect în detaliu: versiunea beta .

Adesea, când un produs a trecut testarea Alpha, acesta este distribuit în afara companiei către câțiva clienți selectați sau chiar către toți clienții, avertizând utilizatorii că produsul distribuit poate să nu fie de înaltă calitate și poate necesita corecții suplimentare.

Utilizatorii versiunii beta pot simula utilizarea software-ului în cazuri realiste și pot trimite rapoarte producătorului despre defecțiunile constatate. Acest tip de testare efectuată gratuit de utilizatori se numește „testare beta”.

Pot exista mai multe versiuni beta, deoarece erorile sunt remediate. Când frecvența rapoartelor de erori scade, este timpul să distribuiți versiunea oficială.

Chiar și după lansarea versiunilor beta și, prin urmare, testarea beta este în desfășurare, testarea Alpha poate continua în cadrul companiei.

Automatizarea testării

Dacă testul constă în utilizarea produsului aproape ca și când ar fi funcționat normal, vorbim de „testare manuală”.

Dacă testul constă în dezvoltarea unui software specific care interacționează cu software-ul care urmează să fie testat și oferă un raport de calitate în absența personalului, vorbim de „testare automată”.

Granularitate

Testarea unitara

Pictogramă lupă mgx2.svg Același subiect în detaliu: testarea unității .

Când construiți un produs complex ca un automobil, nu doar construiți și asamblați piesele și, în cele din urmă, întoarceți cheia pentru a vedea dacă totul funcționează. Aceasta este din trei motive:

  • Unele defecte produc defecțiuni numai după utilizare prelungită, dar sunt ușor de identificat examinând piesele individuale înainte de asamblare.
  • Dacă mașina nu pornește după ce ați rotit cheia, este foarte dificil să înțelegeți care este vina.
  • Dacă mașina nu pornește după ce ați rotit cheia, este foarte scump să demontați mașina, să înlocuiți piesa defectă și să o reasamblați.
  • În unele cazuri, ar putea exista riscul de a provoca daune oamenilor sau bunurilor din cauza funcționării defectuoase a unei componente critice.

Argumente similare se aplică software-ului. Prin urmare, la fel cum părțile individuale ale unei mașini sunt supuse controlului calității înainte de asamblare, tot așa are sens să testăm separat componentele individuale ale unui sistem software.

Componentele testabile ale unui sistem software se numesc „module” sau „unități”, motiv pentru care vorbim de „modul de testare” (în engleză se folosește termenul „unitate de testare”).

Un modul poate varia în granularitate de la o singură rutină, la un set de câteva zeci de rutine, la un subsistem care cuprinde mii de rutine. În programarea orientată obiect, componenta tipică de testat este clasa .

Deoarece un modul, prin definiție, nu este un program complet, în timp ce însăși conceptul de testare necesită executarea unui program, pentru a efectua testarea modulului, trebuie construit un program special care să conțină modulul de testat.

Într-un program complet, toate modulele, cu excepția celor de nivel inferior, apelează rutine de la alte module și toate modulele, cu excepția celor de cel mai înalt nivel, conțin rutine disponibile pentru alte module.

Pentru a construi un program în jurul unui modul, trebuie să furnizați rutine banale care pot fi apelate de modul, până când rutinele complete sunt gata. Astfel de rutine banale se numesc stubs (care în limba engleză înseamnă „butt”, „stump”).

Pentru a executa codul conținut în modul, este necesar să invocați rutinele acestuia. Prin urmare, este scris un program special care apelează rutinele modulului, trecându-le în ordine diferiți parametri și verificând dacă rutinele redau valorile așteptate. Acest program se numește „driver” (care în engleză înseamnă „driver”, „conductor”).

În mod normal, pentru a face testarea mai flexibilă și modificabilă, șoferul preia parametrii dintr-un fișier de date pe care va trebui să le transmită rutinelor modulului care urmează să fie testat și compară rezultatele obținute cu conținutul unui alt fișier de date. Pentru fiecare discrepanță constatată între datele obținute și datele așteptate, se generează un mesaj de eroare într-un al treilea fișier de raport.

Cu această arhitectură, dacă doriți să adăugați o combinație de valori la cele existente, trebuie doar să editați fișierele de date.

Testarea sistemului

Chiar dacă modulele individuale sunt corecte, este posibil ca sistemul obținut prin integrarea lor să nu fie. Prin urmare, este întotdeauna necesar să testați sistemul complet.

Pentru a testa un sistem complet, software-ul trebuie utilizat într-un mod cât mai similar cu modul în care va fi utilizat în funcționare normală, dar cu următoarele diferențe:

  • Pentru software-ul interactiv, funcționarea normală constă în faptul că o persoană interacționează cu software-ul. Acest lucru se realizează cu testarea manuală, care este întotdeauna utilă, dar are diferite dezavantaje. Testarea automată a unui program interactiv este dificil de realizat, cu excepția renunțării la o parte din conceptul de funcționare normală .
  • În funcționarea normală a unui sistem software, pentru fiecare instalare unică a sistemului, utilizarea urmează o anumită tendință repetitivă. Deoarece la testare trebuie simulat cel mai mare număr posibil de situații, în mod normal se renunță la repetitivitatea tipică situațiilor reale și, în schimb, se simulează utilizări foarte variate.

Cunoașterea funcțiilor interne

Testul cutiei albe

Testarea în cutie albă, cunoscută și sub denumirea de testare a cutiei albe britanice sau testarea cutiei transparente / de sticlă („testare în cutie transparentă”) sau testare structurală („testare structurală”) este o formă de testare care verifică funcționarea interioară a unui componentă software, mai degrabă decât funcționalitatea sa. Deoarece necesită cunoașterea și înțelegerea structurii interne a software-ului supus testării (posibil și a codului sursă ), această formă de testare este de obicei responsabilitatea unui programator, adesea același care a scris codul. Deși conceptul poate fi aplicat la diferite niveluri, testarea cutiei albe este de obicei uniformă . Testarea cutiei albe poate facilita sarcina de a asigura o acoperire cuprinzătoare a cazurilor de test împotriva codului sursă; principala sa contraindicație este aceea că constituie o excepție de la principiul încapsulării : în special, un caz de test existent poate eșua în urma unei modificări structurale a unei componente (de exemplu în urma refactorizării ) chiar și atunci când această modificare păstrează corect funcționalitatea componentei în sine.

Testul cutiei negre

Testarea efectuată prin accesarea software-ului numai prin interfața cu utilizatorul sau prin interfețele de comunicații între procese, se numește „testare cutie neagră”.

Poate fi manual sau automat și este de obicei utilizat pentru testarea sistemului, deoarece de obicei nu este necesar să apelați rutine individuale pentru a testa întregul sistem.

Dacă este un test automat, rutinele de testare sunt în mare parte scrise într-un limbaj de nivel superior decât limba în care a fost scrisă aplicația, uneori într-un limbaj conceput special pentru testare.

Software-ul care urmează să fie testat și software-ul de testare sunt procese de comunicare distincte.

Un programator nu este necesar pentru testarea manuală a cutiei negre, iar un programator modest calificat este suficient pentru testarea automată. Adesea testarea cutiei negre este făcută de persoane care nu fac parte din organizația care dezvoltă software-ul; aceștia sunt utilizatorii înșiși care efectuează testarea beta.

Un exemplu de tehnică de testare automată a cutiei negre este de a înregistra interacțiunea utilizatorului într-un fișier și apoi de a repeta înregistrarea simulând comportamentul utilizatorului.

Un avantaj al testării cutiei negre este, în cazurile în care codul sursă și documentația proiectului sunt secrete comerciale, faptul că astfel de testări pot fi efectuate și de persoane din afara companiei.

Un alt avantaj este că nu sunt necesari programatori experți pentru acest tip de testare și că știu aspectele interne ale software-ului care urmează să fie testat. Prin urmare, se pot găsi mai mulți testeri, fără a fi nevoie să investească în formare.

Testarea formală și informală

Testarea informală

În organizațiile mici sau pentru produsele software de mică valoare, testarea este de obicei informală, adică nu există un loc de muncă recunoscut la nivel organizațional ca „testare software”.

Programatorul, imediat după ce a făcut o modificare a software-ului, rulează software-ul modificat și verifică interactiv dacă operația este așa cum era de așteptat. Dacă comportamentul este nesatisfăcător, faceți mai multe modificări și repetați procesul.

Când programatorul este mulțumit de comportamentul software-ului, acesta trimite software-ul către supervizorul său, care efectuează un test manual rapid suplimentar. În acest moment, dacă nu este vorba de modificări care trebuie implementate urgent, noua versiune este trimisă utilizatorilor și personalului de asistență („help desk”) ca versiune beta. Utilizatorii și personalul sunt instruiți cu privire la noile modificări, iar această instruire oferă o oportunitate de a detecta alte defecțiuni.

În această procedură de testare informală, raportarea defecțiunilor și a noilor versiuni nu urmează o procedură bine definită. Sunt utilizate comunicări în persoană, apeluri telefonice, e-mailuri și note despre bilete.

Testarea formală

Testarea unor programe software importante în organizațiile mari, pe de altă parte, urmează procese procedurale mai riguroase, similare cu cele ale proiectelor de inginerie.

Pentru a efectua un test formal, adică strict planificat, este scris un „plan de testare” (în limba engleză, „test plan”), care descrie în detaliu modul în care urmează să fie efectuat testul.

Există două strategii de bază pentru organizarea testării: „suita de teste” și „scenariul de testare”. Adesea sunt utilizate în combinație, adică una sau mai multe baterii de testare și sunt planificate o serie de scenarii de testare.

O baterie de testare este un set de teste elementare, fiecare dintre ele fiind numit „ caz de testare ”. Fiecare test are cel puțin următoarele atribute:

  • Are adesea un identificator sau un număr de serie.
  • Uneori are o descriere a scopului testului.
  • O succesiune de operații necesare pentru a aduce sistemul la condițiile inițiale pentru test.
  • O succesiune de operații necesare pentru readucerea sistemului la condițiile sale de bază după test.
  • Dependențe, adică identificatorii cazului de test care trebuie să fi avut succes pentru ca acest test să aibă sens. De exemplu, dacă un test trebuie să deschidă un fișier și să îl închidă, iar un alt test este să citească același fișier, al doilea test depinde de primul, deoarece nu are sens să încercați să citiți un fișier care nu a putut fi deschis. .
  • Operațiuni care solicită testarea software-ului.
  • Rezultatul scontat.
  • Uneori, timpul maxim permis pentru a primi rezultatul.

Adesea se adaugă alte atribute.

În cazul testării manuale, aceste informații pot fi tipărite și păstrate ca ghid pentru tester. În cazul testării automate, aceste informații sunt specificațiile pentru programatorul care trebuie să implementeze software-ul de testare.

Când se execută un test, se înregistrează alte informații, inclusiv următoarele:

  • Autorul testului.
  • Data și ora execuției.
  • Identificator de versiune testat.
  • Rezultat (succes sau eșec).
  • În caz de faliment, o scurtă descriere a tipului de faliment.

Un scenariu de testare este o utilizare realistă, non-banală a software-ului care urmează să fie testat. În timp ce testele de acceptare iau în considerare funcționalitățile elementare, fiecare scenariu ia în considerare un tip de utilizator și o situație probabilă și complexă în care utilizatorul respectiv se poate găsi. Testarea scenariului parcurge toți pașii pe care i-ar urma utilizatorul într-o astfel de situație. Testarea beta este de fapt un test de scenariu, deși unul informal. Testarea scenariului este în mod necesar un test de sistem și este de obicei manuală sau semi-automată.

Alte tipuri de testare

Test de performanță

Printre cerințele de calitate ale unei aplicații, există nu numai corectitudine, ci și eficiență sau, în orice caz, sunt definite cerințe de performanță a căror îndeplinire trebuie verificată înainte de a utiliza software-ul produs. Activitățile care vizează stabilirea dacă un anumit produs software îndeplinește cerințele de performanță specificate se numesc „teste de performanță” (sau „teste de performanță”). Prin urmare, scopul său nu este de a detecta erorile din aplicație, ci de a verifica dacă aplicația îndeplinește cerințele de performanță solicitate în procesul de explicare a cerințelor.

De obicei, timpii de execuție maximă sunt definiți pentru diferite tipuri de operații (adică sunt definite „linii de bază”) și se verifică dacă produsul software nu depășește aceste limite limită. Pe măsură ce software-ul și hardware-ul evoluează, liniile de bază se pot schimba, de asemenea. De exemplu, dacă software-ul este dezvoltat prin adoptarea unei biblioteci mai puțin eficiente, este admis că diferitele operațiuni pot fi puțin mai lente; pe de altă parte, dacă testul se efectuează pe un sistem multiprocesor, este necesar ca, cu aceeași viteză a procesorului, diferitele operațiuni să fie mai rapide. Liniile de bază pot fi obținute pur și simplu prin măsurarea duratei de rulare a unui sistem existent. Din punct de vedere al testării, aceste activități sunt toate de tipul cutiei albe, unde sistemul este inspectat și controlat „din interior spre exterior” și din diferite unghiuri. Odată ce măsurătorile au fost colectate și analizate, ca rezultat, se efectuează o reglare a aplicației.

Cu toate acestea, uneori o abordare cu cutie neagră este utilizată și prin efectuarea unui test de sarcină pe sistem. Pentru o aplicație web, de exemplu, sunt utilizate instrumente care simulează un anumit număr de utilizatori / conexiuni http concurente și se măsoară timpul de răspuns.

Testarea performanței poate fi integrată în testarea de regresie pentru a verifica dacă modificările nu au introdus încetiniri.

Test de încărcare / volum

Acest tip de testare face parte în mod obișnuit din testarea și reglarea performanței. În acest context, înseamnă creșterea constantă a sarcinii pe sistem prin instrumente automate. Pentru o aplicație web, de exemplu, încărcarea este numărul de utilizatori / conexiuni HTTP concurente.

În literatură, termenul de testare a sarcinii este de obicei definit ca procesul de operare a sistemului testat prin alimentarea acestuia pentru a-l face să îndeplinească cele mai mari sarcini cu care poate opera. Testarea sarcinii se numește uneori și testarea volumului sau testarea longevității / rezistenței.

Exemple de testare a volumului:

  • testați un procesor de text editând un document foarte mare;
  • testați o imprimantă trimițându-i o lucrare foarte mare;
  • testați un server de e-mail cu mii de cutii poștale de utilizator;
  • un caz specific de testare a volumului este așa-numita "testare a volumului zero", în care sistemul este alimentat cu sarcini "goale".

Exemple de teste de longevitate / rezistență:

  • testați o aplicație client-server executând clientul într-o buclă de acces pentru componente pentru o perioadă extinsă de timp.

Scopurile testării sarcinii:

  • descoperiți erori care nu au apărut în timpul testării, cum ar fi erori precum "gestionarea memoriei", "scurgerile de memorie", "depășirea bufferului" etc;
  • asigurați-vă că aplicația respectă performanța „de bază” stabilită în timpul „testării performanței”. Acest lucru se realizează prin efectuarea unui test de regresie pe aplicație cu o sarcină maximă specifică.

În timp ce „testarea performanței” și „testarea sarcinii” pot părea similare, scopul lor este diferit. Pe de o parte, „testarea performanței” utilizează tehnici și instrumente de „testare a sarcinii” pentru măsurare și în scopul efectuării măsurilor de „evaluare comparativă” utilizând diferite niveluri de sarcină. Pe de altă parte, testarea sarcinii funcționează la un nivel de sarcină predefinit, de obicei sarcina maximă pe care sistemul o poate accepta continuând să funcționeze în mod regulat. Scopul nu este de a „sparge” sistemul prin supraîncărcarea acestuia, ci de a încerca să mențină sistemul în funcțiune constantă ca o „mașină bine unsă”. Este necesar să subliniem importanța acestui tip de test. De fapt, experiența a arătat că multe erori importante nu apar atâta timp cât sistemul nu trebuie să se ocupe de o cantitate cu adevărat vastă de date, cum ar fi mii de utilizatori din depozite precum LDAP / NIS / Active Directory, mii de căsuțe poștale utilizator pe server de mail, tabele multi-gigabyte în baze de date, ierarhii de fișiere / directoare foarte lungi pe sisteme de fișiere etc. În aceste cazuri, este aproape întotdeauna nevoia de a utiliza instrumente automate care generează o cantitate atât de mare de date, dar din fericire, cu un limbaj de scriptare bun, aceasta este o sarcină foarte ușoară.

Test de stres

„Testul de stres” este destinat să încerce să „spargă” sistemul supus supraîncărcării resurselor sau eliminând resursele (în acest caz se mai numește și „testare negativă”). Scopul principal al acestor activități este de a verifica dacă sistemul intră în „eroare” și ulterior (posibil) se recuperează într-un mod „nedureros” - acest aspect calitativ este cunoscut sub numele de recuperabilitate ( sisteme tolerante la erori ).

În timp ce „testul de performanță” necesită un mediu controlat și măsurători repetabile, testul de stres provoacă haos și imprevizibilitate. Pentru a reface un alt exemplu pentru o aplicație web, câteva moduri în care puteți stresa sistemul:

  • dublați numărul de utilizatori / conexiuni HTTP așteptați în linia de bază
  • opriți și reporniți aleatoriu porturile comutatoarelor / routerelor de rețea care conectează serverele (de exemplu, prin comenzi SNMP)
  • luați baza de date offline și reporniți-o
  • reconstruiți o matrice RAID în timp ce sistemul rulează
  • executați procese care consumă resurse (CPU, memorie, disc, rețea) pe serverele web de pe serverele de baze de date.

Lista poate fi evident îmbogățită. Cu toate acestea, testul de stres nu se face exclusiv în scopul prăbușirii sistemului, ci mai degrabă este destinat să observe cum reacționează sistemul la eșecuri. Reușește să-și salveze starea sau se blochează din nou / continuu? Se oprește brusc, îngheață sau într-un mod controlat? La repornire, este capabil să se recupereze din ultima stare corectată? Afișează mesaje de eroare ușor de înțeles de utilizator sau afișează doar liste de coduri hexagonale zgârcite? Este compromisă securitatea sistemului din cauza eșecului neașteptat? Si asa mai departe.

Testarea regresiei

Un scop al testării este de a verifica dacă produsele noi și noile caracteristici adăugate produselor vechi sunt de înaltă calitate. Cu toate acestea, în software este adesea cazul ca introducerea unei noi caracteristici unui produs vechi să compromită calitatea caracteristicilor preexistente ale produsului în sine. Pertanto, per assicurarsi la qualità del prodotto bisognerebbe ripetere l'intero collaudo ad ogni modifica. Il collaudo di funzionalità preesistenti e già collaudate, eseguito per assicurare che modifiche al prodotto non ne abbiano compromesso la qualità, si chiama "collaudo di regressione" (in inglese, "regression testing"), in quanto si vuole verificare se la qualità sia regredita .

Se sono stati predisposti dei collaudi automatizzati, tramite appositi strumenti software e script dedicati, il collaudo di regressione ha normalmente un basso costo, in quanto si tratta solo di lanciare le procedure di collaudo esistenti, eventualmente ritoccate e confrontare i risultati prodotti con quelli corretti. Un completo collaudo di regressione manuale sarebbe invece enormemente costoso, soprattutto se il sistema deve essere collaudato con molti utenti simultanei.

Per tale motivo normalmente il collaudo di regressione manuale è più sbrigativo del collaudo originale e anche molto più pericoloso.

Metriche

Ci sono metriche che vengono sviluppate per misurare l'efficacia del collaudo. La principale è l'analisi della copertura del codice ottenuta tramite un profiler. Il profiler indica quante volte è stata eseguita ogni istruzione durante il collaudo. Le istruzioni eseguite almeno una volta sono dette "coperte". L'obiettivo è coprire il maggior numero possibile di istruzioni.

Un'altra metrica utile è il rapporto tra il numero di difetti trovati in un modulo e il numero di istruzioni modificate. Se si trova che in un modulo sono state modificate molte istruzioni ma sono stati trovati pochi difetti, si può dubitare dell'efficacia del collaudo di tale modulo.

Certificazioni

Il software testing sta assumendo sempre di più il ruolo centrale nell'ambito dell'ingegneria del software. È quindi sempre più importante riuscire a qualificare, in maniera oggettiva, professionisti nell'ambito del testing. Sono quindi nati a livello mondiale percorsi di certificazione delle conoscenze. L' International Software Testing Qualifications Board (ISTQB) è l'ente più importante a livello mondiale che si occupa di queste certificazioni.

I software critici sviluppati per gli aeromobili devono rispettare le norme DO-178 , standard de facto del mondo dell'aviazione.

Voci correlate

Altri progetti

Collegamenti esterni

Informatica Portale Informatica : accedi alle voci di Wikipedia che trattano di informatica