Test de software

Un test software verifică și evaluează software-ul pentru îndeplinirea cerințelor definite pentru utilizarea acestuia și măsoară calitatea acestuia . Cunoștințele acumulate sunt utilizate pentru identificarea și corectarea erorilor software . Testele din timpul dezvoltării software-ului sunt utilizate pentru a pune software-ul în funcțiune cu cât mai puține erori posibil.

Acest termen, care desemnează o singură măsură de testare, trebuie să se distingă de denumirea identică „test” (de asemenea, „testare”), sub care totalitatea măsurilor de verificare a calității software-ului (inclusiv planificarea, pregătirea, controlul, implementarea, documentație etc; vezi și definiții ).

Testarea software-ului nu poate oferi dovezi că nu există (mai multe) erori. Poate determina doar în mod sensibil la majuscule că anumite cazuri de testare au avut succes. Edsger W. Dijkstra a scris: "Testarea programului poate fi utilizată pentru a arăta prezența bug-urilor, dar nu arăta niciodată absența lor!" Motivul este că toate funcțiile programului și, de asemenea, toate valorile posibile din datele de intrare ar trebui să fie testate în toate combinațiile lor - ceea ce este practic imposibil (cu excepția obiectelor de testare foarte simple ). Din acest motiv, diverse strategii și concepte de testare se ocupă de modul în care se poate realiza o acoperire de testare mare cu un număr cât mai mic de cazuri de testare .

Pol, Koomen, Spillner explică „testarea” după cum urmează: „Testele nu sunt singura măsură în managementul calității în dezvoltarea de software, dar sunt adesea ultimele posibile. Cu cât sunt descoperite erorile ulterioare, cu atât este mai mult consumator de timp pentru a le corecta, ceea ce duce la concluzia opusă: Calitatea trebuie implementată (pe tot parcursul proiectului) și nu poate fi „testată”. ”Și:„ La testare în dezvoltarea de software, i. d. De obicei, un număr mai mult sau mai puțin mare de erori este presupus sau acceptat ca „normal”. Există o diferență semnificativă aici în comparație cu industria: în secțiunea procesului „controlul calității”, erorile sunt adesea așteptate numai în situații extreme. ”

definiție

Există diferite definiții pentru testul software:

Conform ANSI / IEEE Std. 610.12-1990, testarea este „procesul de operare a unui sistem sau componentă în condiții specificate, observarea sau înregistrarea rezultatelor și efectuarea unei evaluări a unor aspecte ale sistemului sau componentei.”

Ernst Denert oferă o definiție diferită , conform căreia "testul [...] este dovada verificabilă și repetabilă a corectitudinii unei componente software în raport cu cerințele definite anterior" .

Pol, Koomen și Spillner folosesc o definiție mai extinsă: Testarea este procesul de planificare, pregătire și măsurare cu scopul de a determina proprietățile unui sistem IT și de a arăta diferența dintre starea reală și cea necesară. Demn de remarcat aici: Variabila măsurată este „starea necesară“, nu doar (eventual incorectă) caietul de sarcini .

„Testarea“ este o parte esențială a managementului calității de proiecte de dezvoltare de software .

standardizare

În septembrie 2013 a fost publicat standardul ISO / IEC / IEEE 29119 Software Testing . B. IEEE 829 , rezumat și înlocuit. Seria de standarde ISO / IEC 25000 completează partea de inginerie software ca ghid pentru criteriile de calitate (comune) și înlocuiește standardul ISO / IEC 9126 .

motivare

„Niciun sistem extins nu este lipsit de erori.” Orice sistem software cu o complexitate suficientă este defect . În plus față de multe alte motive pentru erori, acestea se pot baza pe situații excepționale care nu au fost luate în considerare sau condiții marginale care nu au fost luate în considerare.

În dezvoltarea de software , testul este utilizat pentru a reduce la minimum pierderea de bani, timp, viață umană sau alte bunuri materiale sau imateriale cauzate de calitatea slabă a unui sistem software. Prin testarea sistematică a software-ului în timpul dezvoltării, erorile pot fi identificate devreme, ceea ce deseori minimizează costurile de eroare conform regulii.

obiective

Scopul global al testării software este de a măsura calitatea sistemului software . Cerințele definite servesc drept referință de test prin intermediul cărora pot fi descoperite orice erori care pot fi prezente . ISTQB : Efectul erorilor (în operație productivă) este astfel prevenit .

Un cadru pentru aceste cerințe poate fi parametrii de calitate conform ISO / IEC 9126 . B. poate fi atribuit funcționalității, utilizabilității, securității etc. În special, trebuie dovedită îndeplinirea cerințelor legale și / sau contractuale.

Rezultatele testelor (care sunt obținute prin diferite proceduri de testare) contribuie la evaluarea calității reale a software-ului - ca o condiție prealabilă pentru lansarea sa pentru utilizare operațională. Testarea este concepută pentru a crea încredere în calitatea software-ului .

Obiective individuale de testare: întrucât testarea software constă în numeroase măsuri individuale pe care i. d. De obicei efectuate pe mai multe niveluri de testare și pe multe obiecte de testare , există obiective individuale de testare pentru fiecare caz de testare individual și pentru fiecare nivel de testare - cum ar fi B. Funcția aritmetică X testată în programul Y, testarea interfeței reușită, repornirea testată, testarea sarcinii reușită, programul XYZ testat etc.

Niveluri de testare

Nivelurile modelului V.

Clasificarea nivelurilor de testare (uneori numite și cicluri de testare) urmărește starea de dezvoltare a sistemului conform modelului V. Conținutul lor se bazează pe etapele de dezvoltare ale proiectelor. În fiecare nivel de testare (partea dreaptă în „V”) se efectuează teste în raport cu proiectarea sistemului și specificațiile nivelului de dezvoltare asociat (partea stângă), i. Adică, obiectivele și cazurile de testare se bazează pe rezultatele dezvoltării respective. Cu toate acestea, acest principiu de proces poate fi utilizat numai dacă modificările aduse în etapele ulterioare de dezvoltare au fost actualizate în specificațiile mai vechi.

În realitate, aceste caracteristici sunt în continuare subdivizate în funcție de dimensiunea și complexitatea produsului software. De exemplu, testele pentru dezvoltarea sistemelor relevante pentru siguranță în tehnologia de securitate a transportului ar putea fi împărțite după cum urmează: testarea componentelor pe computerul de dezvoltare, testarea componentelor pe hardware-ul țintă, teste de integrare a produsului, teste de produs , teste de validare a produselor , integrarea sistemului teste, teste de sistem, teste de validare a sistemului , teste de teren și test de acceptare .

În practică, nivelurile de test descrise mai jos nu sunt adesea delimitate brusc unele de altele, dar pot, în funcție de situația proiectului, să se desfășoare fără probleme sau prin niveluri intermediare suplimentare. De exemplu, sistemul ar putea fi acceptat pe baza rezultatelor testelor (recenzii, protocoale de testare) din testele de sistem.

Test de unitate

Testul modulului și testul de unitate sau testul de unitate numit este un test pentru nivelul fiecăruia dintre modulele software. Subiectul testului este funcționalitatea în părțile definibile individual ale software-ului ( module , programe sau subprograme , unități sau clase ). Scopul acestor teste, care sunt adesea efectuate de dezvoltatorul de software însuși, este de a dovedi operabilitatea tehnică și de a corecta rezultatele tehnice (parțiale).

Test de integrare

Testul de integrare sau testul de interacțiune testează cooperarea componentelor interdependente. Accentul testului se pune pe interfețele componentelor implicate și ar trebui să dovedească rezultate corecte în procesele întregi.

Test de sistem

Testul sistemului este nivelul de testare la care întregul sistem este testat în funcție de toate cerințele (cerințe funcționale și nefuncționale). De obicei, testul are loc într-un mediu de testare și se efectuează cu date de testare . Mediul de testare este destinat să simuleze mediul productiv al clientului, i. H. să fie cât mai asemănător cu ea. De regulă, testarea sistemului este efectuată de către organizația de implementare.

Test de admitere

Un test de acceptare, test de proces, test de acceptare sau test de acceptare a utilizatorului (UAT) este testarea software-ului furnizat de client. Finalizarea cu succes a acestui nivel de testare este de obicei o condiție prealabilă pentru preluarea efectivă din punct de vedere legal a software-ului și plata acestuia. În anumite circumstanțe (de exemplu, pentru aplicații noi), acest test poate fi deja efectuat în mediul de producție cu copii ale datelor reale.

Metoda cutiei negre este utilizată în special pentru teste de sistem și de acceptare , adică Cu alte cuvinte, testul nu se bazează pe codul software - ului , ci doar pe comportamentul software-ului în timpul proceselor specificate (intrări de utilizator, valori limită pentru achiziția de date etc.).

Procesul de testare / fazele de testare

Pol, Koomen și Spillner descriu în Cap. 8.1 „TMap” o procedură bazată pe un model de fază . Numiți această procedură procesul de testare , care constă în fazele testului pregătirea testului, specificațiile testului, execuția și evaluarea testului, finalizarea testului. În același timp, procesul de testare oferă funcțiile cadru de planificare și administrare. Procedura este generică , adică Cu alte cuvinte, este utilizat - în funcție de cerințe - pentru diferite niveluri, pentru proiectul general, pentru fiecare nivel de testare și în cele din urmă pentru fiecare obiect de testare și caz de testare.

La alți autori sau instituții , parțial, alte grupuri și alte nume, dar sunt aproape identice în conținutul găsit. De exemplu, la ISTQB procesul fundamental de testare este definit cu următoarele activități principale: planificarea și controlul testelor, analiza testelor și proiectarea testelor, implementarea testelor și executarea testelor, evaluarea criteriilor finale și a raportului, finalizarea activităților de testare. Activitățile individuale și ordinea lor care (determinate în procesul de testare) trebuie efectuate pentru fiecare obiect de testare - de mai multe ori dacă este necesar, de ex. B. în cazul repetărilor testelor / testelor de regresie - ISTQB le numește „ciclu de testare”

Activitățile de testare sunt grupate (conform lui Pol, Koomen și Spillner) specifice rolului așa-numitelor funcții de testare : Testare, management test, suport metodic, suport tehnic, suport funcțional, administrare, coordonare și consultanță, integrator de aplicații, arhitect TAKT și TAKT inginer (atunci când se utilizează automatizarea testelor; TAKT = testare, automatizare, cunoștințe, instrumente). Aceste funcții (roluri) se concentrează pe anumite faze de testare; pot fi înființate în proiectul în sine sau pot fi incluse prin intermediul unităților organizatorice specializate.

Legat de persoană poate include se poate face o distincție între următoarele roluri în testare:

  • Manager de testare (leadership): Managerul de testare dezvoltă strategia de testare, planifică resursele și servește ca persoană de contact pentru managementul și managementul proiectelor. Trăsăturile de caracter importante sunt fiabilitatea și integritatea.
  • Arhitect de testare, inginer de testare: inginerul de testare sprijină managerul de testare în dezvoltarea strategiei de testare. El este, de asemenea, responsabil pentru selecția optimă a metodelor de testare și a instrumentelor de testare. Planificarea și dezvoltarea unei infrastructuri de testare specifice proiectului se află, de asemenea, în aria sa de responsabilitate.
  • Analist de testare: analistul de testare determină scenariile de testare necesare derivându-le din cerințe. De asemenea, el definește datele de testare care sunt necesare.
  • Manager de date de testare: Managerul de date de testare are grijă de achiziționarea și actualitatea datelor de testare. Lucrează îndeaproape cu analistul de testare. Acest rol este subestimat în mare parte, dar fără datele de testare corecte, declarația cazului de testare este inutilă.
  • Tester (specialist): Sarcina testerului este de a efectua testele în mod fiabil și precis. În plus, ar trebui să documenteze rezultatele testului cu precizie și fără valoare. El poate sprijini analiștii de testare și specialiștii IT în depanarea. În general, acest rol este adesea privit ca un tester, uitând celelalte roluri.

Planificarea testelor

Rezultatul acestui lucru i. d. Faza care are loc de obicei paralel cu dezvoltarea software-ului este i. W. planul de testare . Este dezvoltat pentru fiecare proiect și este destinat să definească întregul proces de testare. În TMap se execută acest lucru: Atât importanța crescândă a sistemelor de informații pentru procesele operaționale, cât și costul ridicat al testării justifică un proces de testare perfect gestionabil și structurat. Planul poate și trebuie actualizat și specificat pentru fiecare nivel de testare, astfel încât testele individuale să poată fi efectuate în mod corespunzător și eficient.

Conținutul din planul de testare ar trebui, de ex. B. următoarele aspecte: strategia testului (sfera testului, acoperirea testului, evaluarea riscurilor); Obiectivele și criteriile testului pentru începutul testului, sfârșitul testului și terminarea testului - pentru toate nivelurile testului Procedură (tipuri de teste); Instrumente și ajutoare pentru testare; Documentație (definiția tipului, structurii, nivelului de detaliu); Mediul de testare (descriere); Date de testare (specificații generale); Organizarea testelor (numiri, roluri), toate resursele, nevoile de instruire; Valori de testare ; Managementul problemelor.

Pregatire pentru test

Pe baza planificării testelor, faptele specificate acolo sunt pregătite și puse la dispoziție pentru utilizare operațională.

Exemple pentru sarcini individuale (globale și pe nivel de test): Furnizarea documentelor bazei testului; Punerea la dispoziție (de exemplu, personalizarea ) instrumentelor pentru gestionarea cazurilor de testare și a erorilor; Configurarea mediului ( mediilor) de testare (sisteme, date); Transferul obiectelor de testare ca bază pentru cazurile de testare din mediul de dezvoltare în mediul de testare; Creați utilizatori și drepturi de utilizator; ...
Exemple pentru pregătiri (pentru teste individuale): Transfer / furnizare de date de testare sau date de intrare în mediul ( mediile) de testare .

Specificația testului

Aici sunt făcute toate specificațiile și pregătirile care sunt necesare pentru a putea executa un anumit caz de testare (diferențiați între cazul de testare logic și concret).

Exemple de activități individuale: identificarea cazului de testare și optimizarea cazului de testare (pe baza obiectivelor testelor și a categoriilor de trasee de testare , dacă este cazul ); Descrieți fiecare caz de testare (ce anume urmează să fie testat); Condiții prealabile (inclusiv definirea dependențelor de alte cazuri de testare); Definirea și crearea datelor de intrare; Specificații pentru procedura de testare și secvența de testare; Stabilirea rezultatului țintă; Condiții pentru „testul îndeplinit”; ...

Executarea testului

În testele dinamice, programul de testat este executat, în testele statice face obiectul testelor analitice.

Exemple de activități individuale: selectarea cazurilor de testare care urmează să fie testate; Lansarea elementului de testare - manual sau automat; Furnizarea datelor de testare și a rezultatului efectiv pentru evaluare; Arhivați informațiile de mediu pentru testarea, ...

Notă suplimentară: Un obiect de testare nu ar trebui testat de dezvoltator însuși, ci de alte persoane, dacă este posibil, independente.

Evaluarea testului

Rezultatele testelor efectuate (pentru fiecare caz de testare) sunt verificate. Rezultatul real este comparat cu rezultatul țintă și apoi se ia o decizie cu privire la rezultatul testului (ok sau eroare ).

  • În cazul unei erori: clasificare (de exemplu, în funcție de cauza erorii, severitatea erorii etc., vezi și clasificarea erorii ), descrierea și explicația corespunzătoare a erorii, transferul la gestionarea erorii ; Cazul de testare rămâne deschis
  • Dacă este OK: cazul testului este considerat finalizat
  • Pentru toate testele: documentare, istoricarea / arhivarea documentelor

Finalizarea testului

Activitățile de închidere au loc la toate nivelurile de testare: caz de testare, obiect de testare, nivel de testare, proiect. Starea finalizării nivelurilor testului este documentată și comunicată (de exemplu, cu ajutorul statisticilor testelor), trebuie luate decizii și arhivate documente. Trebuie făcută o distincție de bază între:

  • Concluzia regulii = obiectivele atinse, faceți pașii următori
  • Alternativ posibil: încheiați sau întrerupeți etapa de testare prematur dacă este necesar (din diverse motive care trebuie documentate); în cooperare cu managementul proiectului

Clasificarea tipurilor de testare

În aproape orice altă disciplină a dezvoltării software-ului există o varietate atât de mare de termeni dezvoltați ca în testarea software-ului, corespunzând complexității sarcinii „testării”. Acest lucru se aplică în special termenilor folosiți pentru a denumi tipurile de testare / variantele de testare.

Ele sunt de obicei derivate din diferitele situații în care sunt realizate și obiectivele de testare pe care le vizează. Acest lucru are ca rezultat un număr mare de termeni. În conformitate cu această multidimensionalitate, denumirile mai multor tipuri de test se pot aplica unui test specific. Exemplu: Un test de dezvoltator poate fi un test dinamic, test de cutie neagră, test de eroare, testul de integrare, test de clasa de echivalență, test de lot, testul de regresie, etc , în același timp .

În literatură și practică, acești termeni sunt folosiți în cea mai mare parte doar parțial, uneori cu detalii diferite. În practică, anumite teste (de exemplu) ar putea fi pur și simplu denumite funcționale teste - și nu ca eroare teste , teste de lot, teste de nivel înalt, etc. testare eficienta nu este afectata de acest lucru - în cazul în care testele sunt în alt mod adecvat planificat și realizat. În sensul proceselor de testare eficiente, este important să acoperim mai multe obiective de testare cu un singur caz de testare, e. B. pentru a verifica interfața cu utilizatorul, o formulă de calcul, verificări corecte ale intervalului de valori și consistența datelor.

Un mijloc de a înțelege această varietate de termeni este clasificarea utilizată mai jos - în care tipurile de testare sunt defalcate în funcție de diferite criterii, sunt enumerate tipurile de testare adecvate și obiectivele lor de testare sunt explicate pe scurt.

Clasificare conform tehnicii de testare

Calitatea și metodele de testare în cursul proiectului

Măsuri analitice

Testele software care pot fi efectuate numai după crearea elementului de testare sunt definite ca măsuri analitice. Liggesmeyer clasifică aceste metode de testare după cum urmează (prescurtat și parțial comentat):

Test static (test fără executarea programului)

Test dinamic (test cu executarea programului)

Măsuri constructive

Măsurile analitice în care obiectele de testare sunt „verificate” sunt precedate de așa-numitele măsuri constructive, care sunt deja efectuate în cursul creării software-ului pentru asigurarea calității. : Exemple de gestionare a cerințelor , realizarea de prototipuri , de revizuire a foii de specificații .

Tehnici de specificare

Mai mult, tehnicile de specificații trebuie să se distingă de tehnicile de testare: nu denotă niciun tip de test cu care obiectele testate sunt testate activ, ci doar procedurile conform cărora testele sunt pregătite și specificate.

Exemplele de nume sunt testul clasei de echivalență și testul de acoperire ; Cazurile de testare sunt identificate și specificate conform acestei proceduri, dar verificate în mod specific, de ex. B. într-un test de integrare , test de lot, test de securitate etc.

Clasificare în funcție de tipul și domeniul de aplicare al obiectelor testate

Depanare
Pentru părți de cod individuale: Verificarea codului programului sub control pas cu pas sau secțiune cu secțiune și, dacă este necesar, modificarea de către dezvoltator.
Test de modul, test de unitate sau test de componentă
Testarea celor mai mici funcționalități testabile posibile izolate de altele; este, de asemenea, considerat un nivel de testare.
Test de integrare
Testarea funcționalității atunci când componentele reciproc independente funcționează împreună; se mai numește și test de interoperabilitate ; este, de asemenea, considerat un nivel de testare.
Test de sistem
Nivel de testare cu teste pe întregul sistem.
Test de interfață
Testarea dacă interfețele dintre componentele care apelează reciproc sunt implementate corect (adică în special în ceea ce privește combinațiile posibile de parametri); mai ales conform specificațiilor, de exemplu cu ajutorul unor obiecte simulate .
Test lot / test dialog
Testele programelor în serie sau testele pentru programele de dialog se numesc teste .
Test web
Testarea funcțiilor Internet sau Intranet; numit și test de browser .
Test hardware
Testarea sarcinii specifice și a altor criterii referitoare la componentele hardware - cum ar fi încărcarea rețelei, timpul de acces, tehnologia de stocare paralelă etc.

Clasificare în funcție de puncte de vedere speciale

Testele de testare respective ...

Vizualizare funcțională a utilizatorilor / utilizatorilor

  • Test de proces de afaceri: ... interacțiunea părților programului unui proces de afaceri.
similar cu testul end-to-end : ... funcțiile sistemului în toți pașii (de exemplu, de la interfața utilizatorului la baza de date).
  • Test de comportament (test de comportament ): ... aplicația din perspectiva utilizatorilor; Se face distincția între:
  • Test de funcții (sau test de funcții ): ... o singură funcție care poate fi executată de utilizator.
  • Test de capacitate : ... dacă o anumită activitate a utilizatorului i. Z. poate fi efectuat cu funcțiile testate.
  • Test de acceptare (de asemenea testul de acceptare a utilizatorului UAT ): ... dacă software-ul îndeplinește cerințele / așteptările definite, în special în ceea ce privește interfața sa de utilizator.
  • Test de suprafață: ... interfețele utilizator ale sistemului (de exemplu, înțelegerea, dispunerea informațiilor, funcțiile de ajutor); numit și test GUI sau test UI pentru programele de dialog .

Relații software-tehnice

  • Test de consistență a datelor: ... Efectul funcției testate asupra corectitudinii seturilor de date (nume de teste: testul ciclului de date, testul intervalului de valori, testul semantic, testul CRUD )
  • Reporniți testul: ... dacă un sistem poate fi repornit după o oprire sau întrerupere (de exemplu, declanșat de un test de stres).
  • Test de instalare: ... rutine pentru instalarea software-ului, dacă este necesar în medii de sistem diferite (de exemplu, cu hardware diferit sau versiuni diferite de sistem de operare)
  • Test de stres: ... comportamentul unui sistem în situații excepționale.
  • Crash test: este un test de stres care încearcă să blocheze sistemul .
  • Test de încărcare : ... comportamentul sistemului în condiții deosebit de mari de memorie, CPU sau cerințe similare. Tipuri speciale de teste de sarcină pot fi teste cu mai mulți utilizatori (mulți utilizatori accesează un sistem, simulat sau real) și teste de stres , în care sistemul este împins la limitele performanței sale.
  • Test de performanță: ... dacă este asigurat un comportament corect al sistemului pentru anumite cerințe de memorie și CPU.
  • Testarea rețelei de calculatoare : ... comportamentul sistemului în rețelele de calculatoare (de exemplu, întârzieri în transmiterea datelor, comportament în cazul apariției unor probleme în transmiterea datelor ).
  • Test de securitate : ... potențiale găuri de securitate.

Caracteristici de calitate software

Un număr mare de teste pot fi derivate din caracteristicile de calitate ale software-ului (de exemplu, în conformitate cu ISO / IEC 9126 - care pot forma cadrul pentru majoritatea cerințelor de testare). Numele tipurilor de teste conform acestei clasificări sunt, de exemplu:

  • Test funcțional și test funcțional : ... un sistem în ceea ce privește caracteristicile cerințelor funcționale, cum ar fi corectitudinea și completitudinea .
  • Test nefuncțional: ... cerințele nefuncționale, cum ar fi B. securitatea , utilizabilitatea sau fiabilitatea unui sistem. Exemple de tipuri de teste specifice pentru aceasta sunt testele de securitate, testele de repornire, testele GUI, testele de instalare și testele de încărcare . Accentul nu se pune pe funcția software-ului (ce face software-ul?), Ci pe funcționalitatea acestuia (cum funcționează software-ul?).
  • Test de eroare: ... dacă procesarea situațiilor de eroare este corectă, i. H. așa cum este definit, are loc.

Alte clasificări pentru tipurile de test

Ora executării testului
  • Cele mai importante denumiri de tipuri de testare în conformitate cu acest aspect și utilizate mai ales în limbajul comun sunt nivelurile de testare , care sunt denumite test de componentă, test de integrare, test de sistem, test de acceptare .
  • Un tip de test timpuriu este testul alfa ( testele inițiale ale dezvoltatorului). Un test pregătitor verifică inițial doar funcțiile esențiale. În testul beta ulterior , utilizatorii selectați verifică dacă sunt adecvate versiunile preliminare ale software-ului aproape terminat.
  • Testele de producție se efectuează în medii de testare configurate similar cu producția sau chiar în mediul de producție în sine, uneori chiar și atunci când software-ul este în funcțiune productivă (potrivit numai pentru funcții non-critice). Cauză posibilă: Numai mediul de producție are anumite componente necesare testării.
  • Repetițiile testelor sunt, de asemenea, o parte a aspectului de sincronizare a testului: astfel de teste se numesc teste de regresie , retestări sau similare .
  • Indirect cu o referință de timp, trebuie menționate următoarele: testul dezvoltatorului (înainte de testul utilizatorului ...), testarea statică (înainte de testarea dinamică).
Abordări metodologice selectate pentru testare
  • Strategii speciale de testare: testare SMART, testare bazată pe risc, testare bazată pe date, testare exploratorie , de sus în jos / de jos în sus, cel mai greu în primul rând, big-bang.
  • Metodele speciale stau la baza desemnărilor tipului de test pentru testele tabelului de decizie , testele de caz de utilizare sau de aplicație, testele de tranziție de stare / testele legate de stare, testele de clasă de echivalență, testele de mutație (schimbarea țintită a detaliilor codului sursă în scopul testării) și perechea -teste în sens .
Intensitatea testului
  • Diferite grade de acoperire a testului ( acoperirea testului sau acoperirea codului) sunt amestecate cu testarea acoperirii realizate care (datorită dimensiunii reduse a obiectelor de testare), în special pentru testele componentelor, sunt potrivite. Denumiri de tip test pentru aceasta: instrucțiuni (test C0, test C1), ramură, condiție și test de parcurs .
  • Deocamdată, numai funcțiile principale importante sunt testate cu teste pregătitoare .
  • Fără date / -cazuri de testare specificate în mod sistematic, testele de fum au efectuat teste pentru a fi testate numai dacă obiectul testului, orice lucru care se face - fără abzurauchen '- de exemplu ca parte a testelor pregătitoare sau ca eșantion final la încheierea unui test nivel.
  • În presupunerea erorilor, testerii (experimentați) provoacă în mod deliberat erori.
Starea informațiilor despre componentele de testat

... care este utilizat la specificarea / efectuarea testelor:

  • Testele de cutie neagră sunt dezvoltate fără a cunoaște structura internă a sistemului de testat, dar pe baza documentelor de dezvoltare. În practică, testele cutiei negre nu sunt de obicei dezvoltate de dezvoltatorii de software, ci de testeri orientați tehnic sau de departamente speciale de testare sau echipe de testare. Această categorie include, de asemenea, teste de cerințe (bazate pe cerințe speciale) și teste stocastice (informații statistice ca bază de testare)
  • Testele cu cutie albă , numite și teste orientate către structură, sunt dezvoltate pe baza cunoștințelor despre structura internă a componentei de testat. Testele dezvoltatorului sunt i. d. R. Testarea cutiei albe - când dezvoltatorul și testerul sunt aceeași persoană. Există riscul ca neînțelegerile din partea dezvoltatorului să conducă inevitabil la cazuri de testare „greșite”, adică eroarea nu va fi recunoscută.
  • Testele cutiei gri sunt uneori numite teste în care o combinație de teste cutie albă și neagră sunt practicate în paralel sau care se bazează doar pe cunoașterea parțială a codului.
  • Test de nivel scăzut / test de nivel înalt: rezumă conceptual tipurile de test în funcție de faptul că acestea vizează componente tehnice specifice (cum ar fi depanarea, testul cutiei albe pentru niveluri scăzute) sau sunt efectuate / specificate pe baza cerințelor de implementare, de exemplu B. Testul cerințelor , testul cutiei negre pentru nivel înalt.
Cine rulează sau specifică testele?
  • Testele dezvoltatorilor (testele programatorului), testele utilizatorilor, testele utilizatorilor, testele de acceptare a utilizatorilor (UAT) sunt efectuate de grupul de testare respectiv.
  • Departamentele responsabile pentru software efectuează teste de acceptare .
  • Testul operațional , testele de instalare, testele de repornire, testele de urgență , printre altele. de asemenea, reprezentanți ai „centrului de date” - pentru a asigura disponibilitatea operațională conform specificațiilor definite.
  • Testarea mulțimii ; Conform principiului crowdsourcing , sarcinile de testare sunt externalizate către un număr mare de utilizatori de pe Internet (mulțimea).
Tipul acțiunii software

Această categorie are o importanță minoră; rezultă termeni de testare, cum ar fi următorii:

  • În cadrul proiectelor de întreținere se efectuează teste de întreținere și teste de regresie ; eu. d. De obicei sunt utilizate cazurile de testare deja existente și datele de testare.
  • În proiectele de migrație se efectuează teste de migrație ; funcțiile de transfer de date și migrare speciale sunt z. B. Testarea conținutului.

Alte aspecte ale testării

Strategia de testare

Pol, Koomen și Spillner descriu strategia de testare ca o abordare cuprinzătoare: o strategie de testare este necesară deoarece un test complet, adică H. un test care verifică toate părțile sistemului cu toate valorile posibile de intrare în toate condițiile prealabile nu este fezabil în practică. Prin urmare, în planificarea testului, trebuie utilizată o evaluare a riscului pentru a determina cât de critică trebuie evaluată apariția unei defecțiuni într-o parte a sistemului (de exemplu, numai pierderi financiare sau pericol pentru viața umană) și cât de intens (ținând cont de resurse și buget) o parte a sistemului trebuie sau poate fi testată.

În consecință, strategia de testare trebuie să specifice ce părți ale sistemului urmează să fie testate cu ce intensitate, folosind ce metode și tehnici de testare, folosind ce infrastructură de testare și în ce ordine (a se vedea, de asemenea , nivelurile de testare ).

Este dezvoltat de managementul testelor ca parte a planificării testelor, documentat și specificat în planul de testare și utilizat ca bază pentru testare (de către echipele de testare).

Conform unei alte interpretări, „strategia de testare” este înțeleasă ca o abordare metodică conform căreia se aplică testarea.

Deci nume z. B. Specificațiile ISTQB pentru strategiile de testare după cum urmează:

  • de sus în jos: testați funcțiile principale înainte de funcții detaliate; Rutinele subordonate sunt inițial ignorate în timpul testului sau simulate (folosind „stubs” )
  • de jos în sus: testați mai întâi funcțiile detaliate; Funcțiile sau apelurile superordonate sunt simulate folosind „drivere de testare”
  • cel mai greu mai întâi: În funcție de situație, mai întâi sunt cele mai importante lucruri
  • big-bang: deodată

Alte principii și tehnici pentru testarea strategiilor sunt:

  • Testarea bazată pe risc: principiul testului conform căruia acoperirea testului este aliniată cu riscurile care pot apărea în obiectele testate (în cazul în care nu se găsesc erori).
  • Testare bazată pe date: tehnologie de testare cu care constelațiile de date pot fi schimbate într-o manieră direcționată prin intermediul setărilor din scripturile de testare pentru a putea testa eficient mai multe cazuri de testare unul după altul
  • Dezvoltare bazată pe teste
  • SMART : Principiul testului „specific, măsurabil, realizabil, realist, legat de timp”
  • Testare bazată pe cuvinte cheie
  • testare bazată pe cadru: automatizarea testelor folosind instrumente de testare pentru medii specifice de dezvoltare / limbaje de programare
  • Testare conform ISO / IEC 25000 : Standardul ISO / IEC 25000 este un standard pentru criterii de calitate și metode de evaluare pentru software și sisteme. În consecință, o abordare a unei strategii de testare se poate baza pe standardele disponibile în acest standard.

Exemplu de testare bazată pe risc - conform metodei RPI

În principiu, din motive de timp și / sau resurse financiare, nu este niciodată posibilă testarea completă a unui software (sau a unor părți ale acestuia). Din această cauză, este important să acordăm prioritate testelor, astfel încât acestea să aibă sens. O metodă dovedită pentru prioritizarea testelor este abordarea bazată pe risc, numită și metodă RPI, cu RPI pentru R isiko- P rioritäts- I is ndex.

În metoda RPI, cerințele sunt atribuite mai întâi grupurilor. Apoi sunt definite criteriile care sunt importante pentru produsul final. Aceste criterii vor fi utilizate ulterior pentru a evalua grupurile de cerințe. Cele trei criterii care s-au dovedit în practică sunt discutate mai jos. Cu întrebările prezentate, ar trebui să se poată distinge cât mai bine cerințele, ceea ce permite evaluarea.

Relevanța afacerii

  • Cât de mare este beneficiul pentru utilizatorul final?
  • Cât de mare este daunele dacă această cerință nu este îndeplinită?
  • Câți utilizatori finali ar fi afectați dacă această cerință nu este îndeplinită?
  • Cât de importantă este această cerință în comparație cu alte cerințe? Trebuie / ar trebui / se poate împlini?

Descoperire

  • Poate fi găsită rapid eroarea sau nerespectarea cerinței?
  • Este observată chiar eroarea?
  • Cum vedeți eroarea?
  • Găsi toată lumea greșeala sau mai degrabă utilizatorii care au cunoștințe mai extinse despre produs?

complexitate

  • Cât de complexă este cerința?
  • Cât de mult depinde cerința de alte părți? Câte alte cerințe depind de aceasta?
  • Cât de complexă este punerea în aplicare a cerinței?
  • Sunt tehnologiile utilizate destul de simple sau complexe?

Odată ce cerințele au fost grupate și criteriile definite, toate grupurile de cerințe trec prin cele trei criterii. Cerințele sunt evaluate de la 1 la 3, 3 fiind cea mai mare valoare (din punct de vedere al importanței) (scala poate fi ajustată după cum este necesar pentru o distribuție mai largă a cerințelor). Dacă se face acest lucru, produsul se formează din cele trei criterii evaluate - din care rezultă importanța cerințelor.

Explicații ale strategiei de testare conform ISO 25000

ISO 25000 definește 8 dimensiuni pentru caracteristicile de calitate ale software-ului. Aceste dimensiuni sunt următoarele:

  • Potențialitate funcțională (funcționalitatea necesară este în software?):
    • adecvarea
    • precizie
    • Interoperabilitate
    • Corectitudine
  • Fiabilitate (cât de fiabil funcționează software-ul?):
    • Maturitate
    • Toleranță la erori
    • Recuperabilitate
  • Utilizare (software-ul este ușor de utilizat?):
    • Înțelegere
    • Învățabilitate
    • Utilizare
  • Eficiența performanței (cât de eficient funcționează software-ul?):
    • Sincronizare
    • Comportamentul de consum
  • Mentenabilitate (cât de ușor poate fi modificat software-ul?):
    • Analizabilitate
    • Modificabilitate
    • stabilitate
    • Verificabilitate
    • Adaptabilitate
  • Portabilitate (cât de ușor poate fi portat software-ul către alt sistem?):
    • Adaptabilitate
    • Instalabilitate
    • conformitate
    • Intercambiabilitate
  • Securitate (cât de sigure sunt datele și programele noastre de accesul neautorizat?):
    • Securitatea accesului
    • Criptarea datelor
  • Compatibilitate (Cât de compatibil este software-ul atunci când vine vorba de schimbul și prelucrarea datelor cu și de la alte sisteme?):
    • Intercambiabilitate
    • Extensibilitate
    • Compatibilitate inversă

Strategia de testare se bazează pe aceste 8 caracteristici de calitate bazate pe experiență și standarde. Cazurile de testare create special în acest scop sunt destinate să se asigure că aceste criterii sunt respectate / acceptate de software-ul care urmează să fie testat - în măsura în care este relevant.

documentație

Relația dintre documente și pașii procedurali conform IEEE 829

Pregătirea documentației face, de asemenea, parte din planificarea testului. Standardul IEEE 829 recomandă o procedură standardizată pentru acest lucru . Conform acestui standard, documentația completă de testare include următoarele documente:

Planul de testare
Descrie domeniul de aplicare, procedura, programul, elementele de testare.
Specificații de proiectare a testului
Descrie în detaliu procedurile menționate în planul de testare.
Specificațiile cazului de testare
Descrie condițiile de mediu, intrările și ieșirile fiecărui caz de testare.
Specificațiile procedurii de testare
Descrie în etape individuale modul în care trebuie efectuat fiecare caz de testare.
Raport de transfer al obiectelor de testare
Jurnalele când elementele de testare au fost predate către care testeri.
Protocol de testare
Listează toate procesele relevante din timpul testului în ordine cronologică.
Raportul incidentului de testare
Listează toate evenimentele care necesită investigații suplimentare.
Raport rezultat test
Descrie și evaluează rezultatele tuturor testelor.

Automatizarea testelor

Automatizarea acestora este recomandată în special pentru testele care se repetă frecvent. Acesta este în special cazul testelor de regresie și a dezvoltării bazate pe teste . În plus, automatizarea testelor este utilizată pentru teste care nu pot fi efectuate manual sau sunt dificil de realizat (de exemplu, teste de încărcare ).

În cazul testelor neautomatizate, efortul este atât de mare în ambele cazuri, încât testele sunt adesea renunțate.

Prezentări generale / conexiuni

Termeni și contextul acestora

Termeni folosiți în testare

Graficul opus arată termeni care apar în contextul „testării” - și cum se raportează la alți termeni.

Interfețe în testare

Interfețe importante la testare

Graficul prezintă cele mai importante interfețe care apar în timpul testării. În ceea ce privește „partenerii” menționați de Thaller în timpul testării, următorul este un exemplu de ceea ce este comunicat sau schimbat în fiecare caz.

  • Managementul proiectului: cadru de timp și efort, starea fiecărui obiect de testare („test ready”), sisteme de documentare
  • Managementul liniei (și departamentul de linie): Asistență tehnică, acceptarea testelor, furnizarea de testeri tehnici
  • Centrul de date: Furnizați și utilizați mediul (mediile) de testare și instrumentele de testare
  • Administrator bază de date: Instalați, încărcați și gestionați seturi de date de testare
  • Managementul configurației: configurarea unui mediu de testare, integrarea noului software
  • Dezvoltare: documente de testare de bază, elemente de testare, suport pentru testare, discutarea rezultatelor testelor
  • Gestionarea problemelor și a CR : mesaje de eroare, feedback despre retestare, statistici de eroare
  • Comitetul director: decizii privind acceptarea testului (etapa) sau încetarea testului

literatură

  • Andreas Spillner, Tilo Linz: Cunoștințe de bază despre testarea software-ului. Instruire și educație suplimentară pentru a deveni tester certificat. Nivel de fundație conform standardului ISTQB . Ediția a 5-a, revizuită și actualizată. dpunkt.verlag, Heidelberg 2012, ISBN 978-3-86490-024-2 .
  • Harry M. Sneed , Manfred Baumgartner, Richard Seidl : Testul sistemului - de la cerințe la dovada calității . A treia ediție, actualizată și extinsă. Carl Hanser, München 2011, ISBN 978-3-446-42692-4 .
  • Georg Erwin Thaller: test software. Verificare și validare . A doua ediție, actualizată și extinsă. Heise, Hannover 2002, ISBN 3-88229-198-2 .
  • Richard Seidl, Manfred Baumgartner, Thomas Bucsics, Stefan Gwihs: Cunoștințe de bază despre automatizarea testelor - concepte, metode și tehnici . A doua ediție, actualizată și revizuită. dpunkt.verlag, 2015, ISBN 978-3-86490-194-2 .
  • Mario Winter, Mohsen Ekssir-Monfared, Harry M. Sneed, Richard Seidl, Lars Borner: Testul de integrare. De la proiectare și arhitectură la integrarea componentelor și sistemelor . Carl Hanser, 2012, ISBN 978-3-446-42564-4 .
  • Bill Laboon: O introducere prietenoasă la testarea software-ului . CreateSpace Independent, 2016, ISBN 978-1-5234-7737-1 .

Link-uri web

Wikționar: test software  - explicații despre semnificații, originea cuvintelor, sinonime, traduceri

Dovezi individuale

  1. ↑ a b c d e f Martin Pol, Tim Koomen, Andreas Spillner: Managementul și optimizarea procesului de testare. Un ghid practic pentru testarea cu succes a software-ului cu TPI și TMap. Ediția a doua, actualizată. dpunkt.Verlag, Heidelberg 2002, ISBN 3-89864-156-2 .
  2. ^ IEEE Glossary Standard of Software Engineering Terminology . IEEE, doi : 10.1109 / ieeestd.1990.101064 ( ieee.org [accesat la 5 octombrie 2020]).
  3. ^ Ernst Denert : Inginerie software. Managementul metodic al proiectului. Springer, Berlin și colab. 1991, ISBN 3-540-53404-0 .
  4. ↑ a b Andreas Spillner, Tilo Linz: Cunoștințe de bază despre testarea software-ului: Instruire și educație continuă la nivelul certificat al Fundației Tester conform standardului ISTQB . Ediția a 6-a, revizuită și actualizată. dpunk.verlag, Heidelberg 2021, ISBN 978-3-86490-583-4 , p. Al 7-lea ff .
  5. ↑ Costuri de eroare, regula de zece , regula de zece , pe sixsigmablackbelt.de
  6. ↑ ISTQB Certified Tester Foundation Level Syllabus Versiunea 2011 1.0.1 International Board Testing Qualifications Board. Adus pe 20 mai 2019 . , Ediție în limba germană. Publicat de Consiliul de testare austriac, Consiliul de testare german eV & Board de testare elvețian, Cap. 1.4
  7. ^ Peter Liggesmeyer : Calitatea software-ului. Testarea, analizarea și verificarea software-ului. Spektrum Akademischer Verlag, Heidelberg și colab. 2002, ISBN 3-8274-1118-1 , p. 34.
  8. ^ Toby Clemson: Testing Strategies in a Microservice Architecture. În: Martin Fowler. 18 noiembrie 2014, accesat la 13 martie 2017 .
  9. ↑ Tobias Weber, Universitatea din Köln, Planificarea proiectelor software ( Memento din 9 august 2016 în Arhiva Internet ) Test alb negru și gri
  10. ^ Dominique Portmann: Calea Noser de testare . Ed.: Noser Engineering AG. Ediția a VII-a. Ianuarie 2016.
  11. ↑ IEEE Standard pentru Software Test Documentation (IEEE Std. 829-1998)
  12. ↑ IEEE Standard pentru software și documentație de testare a sistemului (IEEE Std. 829-2008)
  13. ^ Georg Erwin Thaller: Test de software. Verificare si validare. A doua ediție, actualizată și extinsă. Heise, Hannover 2002, ISBN 3-88229-198-2 .