20. Verificare și calificare software
Verificarea și validarea se referă la procesele de verificare și revizuire care verifică dacă software-ul respectă specificațiile și cerințele clientului. Verificarea și calificarea acoperă întreaga ciclu de viață Software - încep în etapa de analiză a cerințelor și se termină cu verificarea codului programului în etapa de testare a sistemului software finit.
Verificarea și atestarea nu sunt același lucru, deși este ușor să le confundăm. Pe scurt, diferența dintre ele poate fi definită după cum urmează:
Verificarea răspunde la întrebarea dacă sistemul este proiectat corespunzător;
Certificarea răspunde la întrebarea dacă sistemul funcționează corect.
Conform acestor definiții, verificarea verifică dacă software-ul este conform cu specificațiile sistemului, în special cu cerințele funcționale și nefuncționale. Certificare – mai mult proces general. În timpul validării, trebuie să vă asigurați că produsul software corespunde așteptărilor clientului. Validarea se efectuează după verificare pentru a determina modul în care sistemul îndeplinește nu numai specificația, ci și așteptările clientului.
După cum sa menționat mai devreme, validarea cerințelor de sistem este foarte importantă în etapele incipiente ale dezvoltării software. Există adesea erori și omisiuni în cerințe; în astfel de cazuri, produsul final probabil nu va satisface așteptările clientului. Dar, desigur, validarea cerințelor nu poate dezvălui toate problemele din specificația cerințelor. Uneori, lacune și erori în cerințe sunt descoperite numai după finalizarea implementării sistemului.
Procesele de verificare și validare folosesc două tehnici principale pentru verificarea și analiza sistemelor.
1. Inspecție software. Analiza și verificarea diferitelor reprezentări ale sistemului, cum ar fi documentația cu specificațiile cerințelor, diagramele arhitecturale sau codul sursă al programului. Inspecția este efectuată în toate etapele procesului de dezvoltare a sistemului software. În paralel cu inspecția, se poate efectua analiza automată a codului sursă al programelor și documentelor aferente. Inspecția și analiza automatizată sunt metode statice de verificare și validare deoarece nu necesită un sistem executabil.
2. Testarea software-ului. Rularea codului executabil cu date de testare și examinarea rezultatelor și a performanței produs software pentru a verifica funcționarea corectă a sistemului. Testarea este o metodă dinamică de verificare și validare deoarece este aplicată sistemului care rulează.
Pe fig. Figura 20.1 arată locul inspecției și testării în procesul de dezvoltare a software-ului. Săgețile indică etapele procesului de dezvoltare în care aceste metode pot fi aplicate. Conform acestei scheme, inspecția poate fi efectuată în toate etapele procesului de dezvoltare a sistemului și testarea - atunci când este creat un prototip sau un program executabil.
Metodele de inspecție includ: inspecția programului, analiza automată a codului sursă și verificarea formală. Dar metodele statice nu pot decât să verifice conformitatea programelor cu specificația; ele nu pot fi folosite pentru a verifica funcționarea corectă a sistemului. În plus, caracteristicile nefuncționale precum performanța și fiabilitatea nu pot fi testate cu metode statice. Prin urmare, pentru a evalua caracteristicile nefuncționale, se efectuează testarea sistemului.
Orez. 20.1. Verificare și atestare statică și dinamică
În ciuda utilizării pe scară largă a inspecției software, testarea este încă metoda predominantă de verificare și certificare. Testarea este o verificare a funcționării programelor cu date similare cu cele reale, care vor fi procesate în timpul funcționării sistemului. Prezența în program a defecte și inconsecvențe cu cerințele este detectată prin examinarea datelor de ieșire și identificarea celor anormale dintre acestea. Testarea este efectuată în timpul fazei de implementare a sistemului (pentru a verifica dacă sistemul corespunde așteptărilor dezvoltatorilor) și după finalizarea implementării acestuia.
În diferite etape ale procesului de dezvoltare software, tipuri diferite testarea.
1. Testarea defectelor efectuate pentru a detecta neconcordanțe între program și specificațiile acestuia, care se datorează erorilor sau defectelor din programe. Astfel de teste sunt concepute pentru a detecta erori în sistem și nu pentru a simula funcționarea acestuia.
2. Testare statistică evaluează performanța și fiabilitatea programelor, precum și funcționarea sistemului în diferite moduri de operare. Testele sunt concepute pentru a imita funcționarea reală a sistemului cu date reale de intrare. Fiabilitatea sistemului este evaluată prin numărul de defecțiuni observate în activitatea programelor. Performanța este evaluată prin măsurarea timpului total de funcționare și a timpului de răspuns al sistemului la procesarea datelor de testare.
Scopul principal al verificării și calificării este de a se asigura că sistemul este „potrivit scopului”. Adecvarea unui sistem software pentru scopul propus nu înseamnă că ar trebui să fie absolut lipsit de erori. Mai degrabă, sistemul ar trebui să fie rezonabil de bine adaptat scopurilor pentru care a fost destinat. Necesar validitatea conformității depinde de scopul sistemului, de așteptările utilizatorilor și de condițiile pieței pentru produsele software.
1. Scopul software-ului. Nivelul de fiabilitate a conformității depinde de cât de critic este software-ul dezvoltat în funcție de anumite criterii. De exemplu, nivelul de încredere pentru sistemele critice pentru siguranță ar trebui să fie semnificativ mai mare decât același nivel de încredere pentru prototipuri. sisteme softwareîn curs de dezvoltare pentru a demonstra câteva idei noi.
2. Așteptările utilizatorilor. Trebuie remarcat cu tristețe că în prezent, majoritatea utilizatorilor au cerințe scăzute pentru software. Utilizatorii sunt atât de obișnuiți cu eșecurile care apar în timpul rulării programelor încât nu sunt surprinși de acest lucru. Sunt dispuși să tolereze defecțiunile sistemului dacă beneficiile utilizării acestuia depășesc dezavantajele. Cu toate acestea, de la începutul anilor 1990, toleranța utilizatorilor pentru defecțiunile sistemelor software a scăzut treptat. Recent, crearea de sisteme nefiabile a devenit aproape inacceptabilă, astfel încât companiile de dezvoltare de software trebuie să acorde din ce în ce mai multă atenție verificării și validării software-ului.
3. Condițiile pieței software. Atunci când evaluează un sistem software, vânzătorul trebuie să cunoască sistemele concurente, prețul pe care cumpărătorul este dispus să-l plătească pentru sistem și timpul așteptat de lansare pe piață pentru acel sistem. Dacă compania de dezvoltare are mai mulți concurenți, este necesar să se determine data intrării sistemului pe piață înainte de încheierea testării complete și a depanării, altfel concurenții pot fi primii care intra pe piață. Dacă clienții nu sunt dispuși să achiziționeze software la un preț ridicat, ei pot fi dispuși să tolereze mai multe defecțiuni ale sistemului. La determinarea costurilor procesului de verificare și calificare trebuie să se țină seama de toți acești factori.
De regulă, erorile sunt găsite în sistem în timpul verificării și atestării. Se fac modificări în sistem pentru a corecta erorile. Acest proces de depanare de obicei integrate cu alte procese de verificare și atestare. Cu toate acestea, testarea (sau mai general, verificarea și validarea) și depanarea sunt procese diferite care au scopuri diferite.
1. Verificarea și validarea este procesul de detectare a defectelor într-un sistem software.
2. Depanare - procesul de localizare a defectelor (erori) și remediere a acestora (Fig. 20.2).
Orez. 20.2. Procesul de depanare
Nu există metode simple de depanare a programelor. Depanatorii experimentați găsesc erori prin compararea tiparelor de ieșire de testare cu rezultatele sistemelor testate. Pentru a localiza o eroare este nevoie de cunoștințe despre tipurile de erori, modelele de ieșire, limbajul de programare și procesul de programare. Cunoașterea procesului de dezvoltare software este foarte importantă. Depanatorii sunt conștienți de cele mai frecvente erori de programare (cum ar fi creșterea unui contor). De asemenea, ia în considerare erorile care sunt tipice pentru anumite limbaje de programare, de exemplu, cele asociate cu utilizarea pointerilor în limbajul C.
Localizarea erorilor în codul programului nu este întotdeauna un proces simplu, deoarece eroarea nu este neapărat localizată în apropierea punctului din codul programului în care a avut loc accidentul. Pentru a izola erorile, depanatorul dezvoltă teste software suplimentare care ajută la identificarea sursei erorii în program. Poate fi necesar să urmăriți manual execuția programului.
Instrumentele interactive de depanare fac parte dintr-un set de instrumente de suport pentru limbaj care sunt integrate cu sistemul de compilare a codului. Acestea oferă un mediu special de execuție a programului prin care puteți accesa tabelul de identificatori, iar de acolo la valorile variabilelor. Utilizatorii controlează adesea execuția unui program într-o manieră pas cu pas, trecând de la instrucțiune la instrucțiune în secvență. După executarea fiecărei instrucțiuni, se verifică valorile variabilelor și se identifică eventualele erori.
Eroarea găsită în program este corectată, după care este necesar să verificați din nou programul. Pentru a face acest lucru, puteți reinspecta programul sau repeta testul anterior. Retestarea este folosită pentru a ne asigura că modificările aduse programului nu introduc noi erori în sistem, deoarece în practică un procent mare de „remedieri de erori” fie nu se completează complet, fie introduc noi erori în program.
În principiu, este necesar să rulați din nou toate testele în timpul retesării după fiecare remediere, dar în practică, această abordare este prea costisitoare. Prin urmare, la planificarea procesului de testare, dependențele dintre părțile sistemului sunt determinate și teste sunt atribuite pentru fiecare parte. Apoi este posibilă urmărirea elementelor programului utilizând cazuri de testare speciale (date de control) selectate pentru aceste elemente. Dacă rezultatele urmăririi sunt documentate, atunci numai un subset din setul total de date de testare poate fi utilizat pentru a testa elementul de program modificat și componentele sale dependente.
Scopul acestui curs este de a oferi o imagine cuprinzătoare a procesului de verificare a software-ului. Subiectul de discuție îl constituie diversele abordări și metode utilizate în domeniul verificării și, în special, al testării software-ului. Se presupune că software-ul în curs de dezvoltare face parte dintr-un program mai mare sistem comun. Un astfel de sistem include componente hardware, informaționale și organizaționale (utilizator uman, operator uman etc.) dezvoltate, eventual, de diferite echipe. Prin urmare, sunt necesare documente de dezvoltare care definesc cerințele pentru diferite componente ale sistemului și regulile de interacțiune a acestora. În plus, se presupune că defecțiunile sistemului pot duce la consecințe de o gravitate sau alta, prin urmare, la dezvoltarea software-ului, eforturile depuse pentru identificarea defectelor ascunse sunt necesare și justificate. În primul rând, se referă la mijloacele și procedurile de verificare a software-ului. Cursul include o serie de exerciții practice care ilustrează tehnicile și metodele de verificare a software-ului în mediul Microsoft Visual Studio 2005 Team Edition for Software Testers folosind un sistem simplu ca exemplu. Această publicație face parte din Biblioteca de curriculum, care este dezvoltată de Programul de colaborare academică MSDN Academic Alliance (MSDN AA).
Textul de mai jos este extras automat din documentul PDF original și este destinat doar pentru previzualizare.
Imaginile (imagini, formule, grafice) lipsesc.
Orez. 7 Testare, verificare și validare Verificarea software-ului este un concept mai general decât testarea. Scopul verificării este de a obține asigurarea că obiectul verificat (cerințe sau cod de program) este conform cerințelor, este implementat fără funcții nedorite și îndeplinește specificațiile și standardele de proiectare. Procesul de verificare include inspecții, testarea codurilor, analiza rezultatelor testelor, generarea și analiza rapoartelor de probleme. Astfel, este general acceptat că procesul de testare este parte integrantă a procesului de verificare, aceeași presupunere fiind făcută și în acest curs de formare. Validarea unui sistem software este un proces al cărui scop este de a demonstra că, ca urmare a dezvoltării sistemului, am atins obiectivele pe care ne-am propus să le atingem prin utilizarea acestuia. Cu alte cuvinte, validarea este verificarea conformității sistemului cu așteptările clientului. Problemele legate de validare sunt în afara domeniului de aplicare al acesteia curs de pregatireși reprezintă un subiect interesant separat pentru studiu. Dacă te uiți la aceste trei procese în ceea ce privește întrebarea la care răspund, atunci testarea răspunde la întrebarea „Cum se face?” sau „Comportamentul programului dezvoltat îndeplinește cerințele?” Verificare - „Ce s-a făcut?” sau „Îndeplinește sistemul dezvoltat cerințele?”, iar validarea este „A făcut ceea ce trebuie să facă?” sau „Sistemul dezvoltat îndeplinește așteptările clientului?”. 1.7. Documentație creată în diferite etape ale ciclului de viață Sincronizarea tuturor etapelor de dezvoltare are loc cu ajutorul documentelor care sunt create la fiecare etapă. În același timp, documentația este creată atât în segmentul direct al ciclului de viață - în timpul dezvoltării unui sistem software, cât și invers - în timpul verificării acestuia. Să încercăm, folosind exemplul unui ciclu de viață în formă de V, să urmărim ce tipuri de documente sunt create pe fiecare dintre segmente și ce relații există între ele (Fig. 8). Rezultatul etapei de dezvoltare a cerințelor sistemului este cerințele formulate pentru sistem - un document care descrie principiile generale ale funcționării sistemului, interacțiunea acestuia cu " mediu inconjurator» - utilizatorii sistemului, precum și software-ul și hardware-ul care asigură funcționarea acestuia. De obicei, în paralel cu cerințele pentru sistem, se creează un plan de verificare și se definește o strategie de verificare. Aceste documente definesc o abordare generală a modului în care va fi efectuată testarea, ce metodologii vor fi aplicate și ce aspecte ale viitorului sistem ar trebui supuse testării riguroase. O altă sarcină rezolvată prin definirea unei strategii de verificare este de a determina locul diferitelor procese de verificare și relațiile acestora cu procesele de dezvoltare. 20 Procesul de verificare care funcționează cu cerințele de sistem este procesul de validare a cerințelor, comparându-le cu așteptările reale ale clientului. Privind în perspectivă, să presupunem că procesul de validare este diferit de testele de acceptare efectuate atunci când sistemul finit este transferat către client, deși poate fi considerat parte a unor astfel de teste. Validarea este un mijloc de a demonstra nu numai corectitudinea implementarii sistemului din punctul de vedere al clientului, ci si corectitudinea principiilor care stau la baza dezvoltarii acestuia. Orez. 8 Procese și documente de dezvoltare a sistemului software Cerințele de sistem stau la baza procesului de dezvoltare a cerințelor funcționale și a arhitecturii proiectului. Pe parcursul acestui proces sunt dezvoltate cerințe generale pentru software-ul sistemului, pentru funcțiile pe care acesta trebuie să le îndeplinească. Cerințele funcționale includ adesea definirea tiparelor de comportament ale sistemului în normal și Situații de urgență , regulile de prelucrare a datelor și definițiile interfeței cu utilizatorul. Textul cerinței, de regulă, include cuvintele „ar trebui, trebuie” și are structura formei „Dacă valoarea temperaturii de pe senzorul ABC atinge 30 de grade Celsius sau mai mult, sistemul trebuie să nu mai emită un semnal sonor. ” Cerințele funcționale stau la baza dezvoltării arhitecturii sistemului - o descriere a structurii sale în termeni de subsisteme și unități structurale ale limbajului în care se realizează implementarea - zone, clase, module, funcții etc. Pe baza cerințelor funcționale sunt scrise cerințele de testare - documente care conțin definirea punctelor cheie care trebuie verificate pentru a se asigura că implementarea cerințelor funcționale este corectă. Cerințele de testare încep adesea cu cuvintele „Verificați ce” și conțin link-uri către cerințele funcționale corespunzătoare. Exemple de cerințe de testare pentru cerința funcțională de mai sus ar fi „Verificați dacă temperatura de pe senzorul ABC scade sub 30 de grade Celsius, sistemul emite un sunet de avertizare” și „Verificați dacă temperatura de pe senzorul ABC depășește 30 de grade Celsius, sistemul nu emite bipuri.” 21 Una dintre problemele care apar la scrierea cerințelor de testare este imposibilitatea fundamentală a unor cerințe, de exemplu, cerința „Interfața cu utilizatorul trebuie să fie intuitivă” nu poate fi testată fără o definiție clară a ceea ce este o interfață intuitivă. Astfel de cerințe funcționale nespecifice sunt de obicei modificate ulterior. Caracteristicile arhitecturale ale sistemului pot servi și ca sursă pentru crearea cerințelor de testare care iau în considerare caracteristicile implementării software a sistemului. Un exemplu de astfel de cerință este, de exemplu, „Verificați dacă valoarea temperaturii la senzorul ABC nu depășește 255”. Pe baza cerințelor funcționale și a arhitecturii, se scrie codul de program al sistemului, iar pentru a-l verifica, pe baza cerințelor de testare, este pregătit un plan de testare - o descriere a secvenței cazurilor de testare care verifică conformitatea implementarea sistemului cu cerințele. Fiecare caz de testare conține o descriere specifică a valorilor furnizate ca intrare în sistem, valorile așteptate ca ieșire și o descriere a scenariului de execuție a testului. În funcție de obiectul testării, un plan de testare poate fi pregătit fie ca program într-un limbaj de programare, fie ca fișier de date de intrare pentru un set de instrumente care execută sistemul testat și îi trece valorile specificate în planul de testare, sau ca instructiuni pentru utilizator.sistem care descrie pasii necesari care trebuie urmati pentru testarea diferitelor functii ale sistemului. Ca urmare a executării tuturor cazurilor de testare, se colectează statistici privind succesul trecerii testului - procentul de cazuri de testare pentru care valorile reale de ieșire au coincis cu cele așteptate, așa-numitele teste trecute. Testele nereușite sunt datele inițiale pentru analizarea cauzelor erorilor și corectarea ulterioară a acestora. În etapa de integrare, modulele individuale ale sistemului sunt asamblate într-un singur întreg și sunt executate cazuri de testare care verifică întreaga funcționalitate a sistemului. În ultima etapă, sistemul finit este livrat clientului. Înainte de implementare, specialiștii clientului, împreună cu dezvoltatorii, efectuează teste de acceptare - verifică funcțiile care sunt critice pentru utilizator în conformitate cu un program de testare pre-aprobat. După finalizarea cu succes a testelor, sistemul este transferat clientului, în caz contrar este trimis pentru revizuire. 1.8. Tipuri de procese de testare și verificare și locul lor în diferite modele de ciclu de viață 1.8.1. Testarea unitară Unitățile mici (proceduri, clase etc.) sunt supuse testării unitare. Când se testează un modul relativ mic de 100-1000 de linii în dimensiune, este posibil să se verifice, dacă nu toate, atunci cel puțin multe ramuri logice în implementare, căi diferite în graficul dependenței de date, valorile limită ale parametrilor. În conformitate cu aceasta, sunt construite criteriile de acoperire a testelor (toți operatorii, toate ramurile logice, toate punctele de limită etc. sunt acoperite). . Testarea unitară se face de obicei pentru fiecare independent modul softwareși este poate cel mai comun tip de testare, în special pentru sistemele mici și mijlocii. 1.8.2. Testarea integrării Verificarea corectitudinii tuturor modulelor, din păcate, nu garantează funcționarea corectă a sistemului de module. Literatura de specialitate discută uneori despre modelul „clasic” de organizare incorectă a testării unui sistem de module, numită adesea metoda „salt mare”. Esența metodei este să testați mai întâi fiecare modul separat, apoi să le combinați într-un sistem și să testați întregul sistem. Pentru sistemele mari, acest lucru este nerealist. Cu această abordare, se va cheltui mult timp pentru localizarea erorilor, iar calitatea testării va rămâne scăzută. O alternativă la „salt mare” este testarea integrării, când sistemul este construit în etape, grupuri de module sunt adăugate treptat. 1.8.3. Testarea sistemului Un produs software complet implementat este supus testării sistemului. În această etapă, testerul nu este interesat de corectitudinea implementării procedurilor și metodelor individuale, ci de întregul program în ansamblu, așa cum îl vede utilizatorul final. Baza pentru teste sunt Cerințe generale la program, incluzând nu numai corectitudinea implementării funcțiilor, ci și performanța, timpul de răspuns, rezistența la eșecuri, atacuri, erori ale utilizatorului etc. Pentru testarea sistemului și a componentelor, sunt utilizate tipuri specifice de criterii de acoperire a testelor (de exemplu, sunt acoperite toate scenariile tipice de lucru, toate scenariile cu situații anormale, compozițiile scenariilor pereche etc.). 1.8.4. Testarea de încărcare Nu numai că testarea de încărcare oferă date predictive asupra performanței sistemului sub sarcină, care se concentrează pe luarea deciziilor arhitecturale, dar oferă și informații operaționale echipelor de suport tehnic, precum și managerilor de proiect și configurație care sunt responsabili pentru crearea celor mai productive. configurații hardware și software... Testarea de încărcare permite echipei de dezvoltare să ia decizii mai informate care vizează dezvoltarea compozițiilor arhitecturale optime. Clientul, la rândul său, are posibilitatea de a efectua teste de acceptare în condiții apropiate de reale. 1.8.5. Inspecții formale Inspecția formală este una dintre modalitățile de verificare a documentelor și a codului de program creat în timpul procesului de dezvoltare a software-ului. În timpul unei inspecții oficiale, un grup de specialiști verifică în mod independent conformitatea documentelor inspectate cu documentele originale. Independența verificării este asigurată de faptul că aceasta este efectuată de inspectori care nu au participat la elaborarea documentului inspectat. 1.9. Verificarea software-ului în curs de certificare Să dăm câteva definiții care definesc structura de ansamblu Procesul de certificare software: Certificarea software este procesul de stabilire și recunoaștere oficială a faptului că dezvoltarea software-ului a fost efectuată în conformitate cu anumite cerințe. În timpul procesului de certificare are loc interacțiunea Solicitantului, Autorității de Certificare și Autorității de Supraveghere.Solicitantul este o organizație care depune o cerere către Autoritatea de Certificare corespunzătoare pentru obținerea unui certificat (conformitate, calitate, adecvare etc.) a unui produs. Organism de Certificare – o organizație care ia în considerare cererea Solicitantului pentru Certificarea Software și, fie independent, fie prin formarea unei comisii speciale, produce un set de proceduri care vizează desfășurarea procesului de Certificare Software al Solicitantului. 23 Organism de supraveghere - o comisie de specialiști care supraveghează procesele de dezvoltare de către Solicitant a unui Sistem informaticși emiterea unui aviz cu privire la conformitatea acestui proces cu anumite cerințe, care este prezentat spre examinare Organismului de Certificare. Certificarea poate avea drept scop obținerea unui certificat de conformitate sau a unui certificat de calitate. În primul caz, rezultatul certificării este recunoașterea conformității proceselor de dezvoltare cu anumite criterii și a funcționalității sistemului cu anumite cerințe. Documentele de orientare pot servi ca exemplu de astfel de cerințe. Serviciul Federal privind controlul tehnic și la export în domeniul securității sistemelor software. În al doilea caz, rezultatul este recunoașterea conformității proceselor de dezvoltare cu anumite criterii, ceea ce garantează un nivel adecvat de calitate a produsului fabricat și adecvarea acestuia pentru utilizare în anumite condiții. Un exemplu de astfel de standarde este o serie de standarde internaționale de calitate ISO 9000:2000 (GOST R ISO 9000-2001) sau standardele aviatice DO-178B, AS9100, AS9006. Testarea software-ului care urmează să fie certificat are două obiective complementare: Primul obiectiv este acela de a demonstra că software-ul îndeplinește cerințele pentru acesta. Al doilea obiectiv este de a demonstra cu un nivel ridicat de încredere că erorile care pot duce la situații de defecțiune inacceptabile, așa cum sunt determinate de procesul de evaluare a siguranței sistemului, sunt identificate în timpul procesului de testare. De exemplu, în conformitate cu cerințele standardului DO-178B, pentru a satisface obiectivele testării software-ului, este necesar: Testele trebuie să se bazeze mai întâi pe cerințele software; Testele ar trebui să fie concepute pentru a verifica funcționarea corectă și pentru a crea condiții pentru identificarea erorilor potențiale. Examinarea completității testelor pe baza cerințelor software ar trebui să determine ce cerințe nu sunt testate. Analiza completității testelor pe baza structurii codului programului ar trebui să determine care structuri nu au fost executate în timpul testării. Acest standard vorbește și despre testarea bazată pe cerințe. Această strategie s-a dovedit a fi cea mai eficientă în detectarea erorilor. Orientările pentru selectarea cazurilor de testare pe baza cerințelor includ următoarele: Pentru a atinge obiectivele testării software-ului, trebuie efectuate două categorii de teste: teste pentru situații normale și teste pentru situații anormale (nenecesare, robuste). Ar trebui dezvoltate cazuri de testare specifice pentru cerințele software și sursele de erori inerente procesului de dezvoltare a software-ului. Scopul testelor pentru situații normale este de a demonstra capacitatea software-ului de a răspunde la intrări și condiții normale în conformitate cu cerințele. 24 Scopul testelor pentru situații anormale este de a demonstra capacitatea software-ului de a răspunde în mod adecvat la intrări și condiții anormale, cu alte cuvinte, nu ar trebui să provoace defectarea sistemului. Categoriile de situații de avarie pentru sistem se stabilesc prin determinarea pericolului situației de avarie pentru aeronavă și ocupanții acesteia. Orice eroare din software poate provoca o eroare care va contribui la situația de eșec. Astfel, nivelul de integritate software necesar pentru funcționarea în siguranță este legat de situațiile de defecțiune ale sistemului. Există 5 nivele de situații de eșec de la minor la critic. Conform acestor niveluri, este introdus conceptul de nivel de criticitate software. Nivelul de criticitate determină componența documentației transmise autorității de certificare și, prin urmare, profunzimea proceselor de dezvoltare și verificare a sistemului. De exemplu, numărul de tipuri de documente și cantitatea de muncă de dezvoltare a sistemului necesară pentru certificare pentru cel mai scăzut nivel de criticitate DO-178B poate diferi cu unul sau două ordine de mărime de numărul și volumele necesare pentru certificare pentru cel mai mult nivel inalt. Cerințele specifice sunt determinate de standardul conform căruia se preconizează efectuarea certificării. 25 TEMA 2. Testarea codului programului (prelegeri 2-5) 2.1. Sarcini și obiective ale testării codului programului Testarea codului programului este procesul de execuție a codului programului care vizează identificarea defectelor existente în acesta. Un defect aici este înțeles ca o secțiune a codului programului, a cărei execuție, în anumite condiții, duce la un comportament neașteptat al sistemului (adică, un comportament care nu îndeplinește cerințele). Comportamentul neașteptat al sistemului poate duce la defecțiuni în funcționarea acestuia și eșecuri, în acest caz se vorbește despre defecte semnificative în codul programului. Unele defecte provoacă probleme minore care nu perturbă funcționarea sistemului, dar fac oarecum dificilă lucrarea cu acesta. În acest caz, vorbim de defecte medii sau minore. Sarcina testării cu această abordare este de a determina condițiile în care apar defectele sistemului și de a înregistra aceste condiții. Sarcinile de testare nu includ de obicei identificarea anumitor secțiuni defecte ale codului programului și nu includ niciodată remedierea defectelor - aceasta este o sarcină de depanare care este efectuată pe baza rezultatelor testării sistemului. Scopul aplicării procedurii de testare a codului programului este de a minimiza numărul de defecte, mai ales semnificative, în produsul final. Testarea singură nu poate garanta absența completă a defectelor în codul de sistem. Cu toate acestea, în combinație cu procesele de verificare și validare, au ca scop eliminarea inconsecvențelor și a caracterului incomplet documentatia proiectului(în special, cerințele pentru sistem), testarea bine organizată asigură că sistemul îndeplinește cerințele și se comportă în conformitate cu acestea în toate situațiile avute în vedere. Atunci când se dezvoltă sisteme de fiabilitate sporită, de exemplu aviație, garanțiile de fiabilitate se obțin printr-o organizare clară a procesului de testare, determinând legătura acestuia cu alte procese ale ciclului de viață, introducând caracteristici cantitative care permit evaluarea succesului testării. În același timp, cu cât sunt mai mari cerințele pentru fiabilitatea sistemului (nivelul său de criticitate), cu atât cerințele sunt mai stricte. Astfel, în primul rând, luăm în considerare nu rezultatele specifice ale testării unui anumit sistem, ci organizare generală proces de testare, folosind abordarea „un proces bine organizat dă un rezultat de calitate”. Această abordare este comună multor standarde de calitate internaționale și din industrie, care vor fi discutate mai detaliat la sfârșitul acestui curs. Calitatea sistemului dezvoltat cu această abordare este rezultatul unui proces organizat de dezvoltare și testare, și nu un rezultat independent negestionat. Deoarece sistemele software moderne sunt foarte mari, metoda de descompunere funcțională este utilizată la testarea codului programului lor. Sistemul este împărțit în module separate (clase, spații de nume etc.) care au funcționalități și interfețe definite de cerințe. După aceea, fiecare modul este testat individual - se efectuează testarea unitară. Apoi, modulele individuale sunt asamblate în configurații mai mari - se efectuează testarea integrării și, în final, se testează sistemul în ansamblu - se efectuează testarea sistemului. Din punctul de vedere al codului programului, unitatea, integrarea și testarea sistemului au multe în comun, așa că acest subiect se va concentra pe testarea unitară, caracteristicile integrării și testării sistemului vor fi discutate mai târziu. 26 În timpul testării unitare, fiecare modul este testat atât pentru conformitatea cu cerințele, cât și pentru absența secțiunilor problematice ale codului programului care pot cauza defecțiuni și defecțiuni în sistem. De regulă, modulele nu funcționează în afara sistemului - primesc date de la alte module, le procesează și le transmit mai departe. Pentru a izola, pe de o parte, modulul de sistem și a elimina influența potențialelor erori de sistem, iar pe de altă parte, pentru a furniza modulului toate datele necesare, se utilizează un mediu de testare. Sarcina mediului de testare este de a crea un mediu de rulare pentru modul, pentru a emula toate interfețele externe pe care le accesează modulul. Despre caracteristicile organizării mediului de testare vor fi discutate în acest subiect. O procedură tipică de testare este pregătirea și executarea cazurilor de testare (denumite și simplu teste). Fiecare caz de testare verifică o „situație” în comportamentul modulului și constă dintr-o listă de valori transmise la intrarea modulului, o descriere a lansării și execuției procesării datelor - un scenariu de testare și o listă de valorile care sunt așteptate la ieșirea modulului în cazul comportării sale corecte. Scenariile de testare sunt compilate astfel încât să excludă accesul la datele interne ale modulului, toată interacțiunea ar trebui să aibă loc numai prin interfețele sale externe. Execuția unui caz de testare este susținută de un mediu de testare, care include o implementare programatică a scriptului de testare. Execuția începe prin trecerea intrării la modul și rularea scriptului. Ieșirea efectivă primită de la modul ca rezultat al execuției scriptului este stocată și comparată cu cele așteptate. Dacă se potrivesc, testul se consideră promovat, în caz contrar nu este promovat. Fiecare test eșuat indică fie un defect în unitatea testată, fie în mediul de testare, fie în descrierea testului. Setul de descrieri ale cazurilor de testare este un plan de testare - documentul principal care definește procedura de testare a unui modul de program. Planul de testare specifică nu numai cazurile de testare în sine, ci și ordinea în care urmează acestea, care poate fi de asemenea importantă. Structura și caracteristicile planurilor de testare vor fi discutate în acest subiect, probleme asociate cu ordinea cazurilor de testare - în subiectul „Testarea repetabilității”. La testare, este adesea necesar să se ia în considerare nu numai cerințele pentru sistem, ci și structura codului de program al modulului testat. În acest caz, testele sunt concepute astfel încât să detecteze greșeli tipice programatori cauzate de interpretarea greșită a cerințelor. Se aplică verificări ale condiției la limită, verificări ale clasei de echivalență. Absența în sistem a capabilităților care nu sunt specificate de cerințe garantează estimări diferite ale acoperirii codului de program prin teste, i.e. estimări ale procentului din anumite constructe de limbaj care sunt executate ca rezultat al executării tuturor cazurilor de testare. Toate acestea vor fi discutate la finalul acestui subiect. 2.2. Metode de încercare 2.2.1. Cutia neagră Ideea principală în testarea unui sistem ca o cutie neagră este că toate materialele care sunt disponibile pentru tester sunt cerințele pentru sistem care descriu comportamentul acestuia și sistemul în sine, cu care acesta poate lucra doar prin aplicarea unor influențe externe. la intrările sale și la ieșirile observând unele rezultate. Toate caracteristicile interne ale implementării sistemului sunt ascunse de tester, astfel, sistemul este o „cutie neagră”, al cărei comportament corect în raport cu cerințele trebuie verificat. 27 Din punctul de vedere al codului programului, o cutie neagră poate fi un set de clase (sau module) cu interfețe externe cunoscute, dar texte sursă inaccesibile. Sarcina principală a testerului pentru această metodă de testare este să verifice în mod constant dacă comportamentul sistemului îndeplinește cerințele. În plus, testerul trebuie să testeze sistemul în situații critice - ce se întâmplă dacă sunt date valori de intrare incorecte. Într-o situație ideală, toate variantele de situații critice ar trebui descrise în cerințele pentru sistem, iar testerul poate veni doar cu verificări specifice pentru aceste cerințe. Cu toate acestea, în realitate, în urma testării, sunt de obicei relevate două tipuri de probleme de sistem: 1. Incoerența comportamentului sistemului cu cerințele 2. Comportamentul inadecvat al sistemului în situații neprevăzute de cerințe. Rapoartele ambelor tipuri de probleme sunt documentate și partajate dezvoltatorilor. În același timp, problemele de primul tip provoacă de obicei o modificare a codului programului, mult mai rar - o schimbare a cerințelor. Modificarea cerințelor în acest caz poate fi necesară din cauza inconsecvenței acestora (mai multe cerințe diferite descriu modele diferite de comportament al sistemului în aceeași situație) sau incorecte (cerințele nu corespund realității). Problemele de al doilea tip necesită în mod clar modificări ale cerințelor din cauza caracterului incomplet al acestora - cerințele ratează în mod clar situația care duce la un comportament inadecvat al sistemului. În același timp, comportamentul inadecvat poate fi înțeles ca o prăbușire completă a sistemului sau, în general, orice comportament care nu este descris în cerințe. Testarea cutiei negre se mai numește și testarea cerințelor. aceasta este singura sursă de informații pentru construirea unui plan de testare. 2.2.2. Cutie de sticlă (albă) Când testează un sistem ca o cutie de sticlă, testerul are acces nu numai la cerințele pentru sistem, intrările și ieșirile sale, ci și la structura sa internă - vezi codul programului. Disponibilitatea codului programului extinde capacitățile testatorului prin faptul că acesta poate vedea conformitatea cerințelor cu secțiunile codului programului și, prin urmare, poate vedea dacă există cerințe pentru întregul cod de program. Codul programului pentru care nu există cerințe se numește cod fără cerințe. Un astfel de cod este o sursă potențială de comportament inadecvat al sistemului. În plus, transparența sistemului vă permite să aprofundați analiza zonelor sale care provoacă probleme - adesea o problemă o neutralizează pe alta și nu apar niciodată în același timp. 2.2.3. Testarea modelului Testarea modelului este oarecum îndepărtată de metodele clasice de verificare a software-ului. În primul rând, acest lucru se datorează faptului că obiectul testării nu este sistemul în sine, ci modelul său conceput prin mijloace formale. Dacă lăsăm deoparte problemele de verificare a corectitudinii și aplicabilității modelului în sine (se crede că corectitudinea și conformitatea acestuia cu sistemul original pot fi dovedite prin mijloace formale), atunci testerul are la dispoziție un instrument destul de puternic de analiză. integritatea generală a sistemului. Lucrând cu modelul, puteți crea situații care nu pot fi create într-un laborator de testare pentru un sistem real. Lucrând cu modelul codului de program al sistemului, este posibil să se analizeze proprietățile acestuia și parametrii sistemului cum ar fi optimitatea algoritmilor sau stabilitatea acestuia. 28 Cu toate acestea, testarea modelului nu a devenit larg răspândită tocmai din cauza dificultăților întâmpinate în elaborarea unei descrieri formale a comportamentului sistemului. Una dintre puținele excepții sunt sistemele de comunicație, al căror aparat algoritmic și matematic este destul de bine dezvoltat. 2.2.4. Analiza codului programului (inspecții) În multe situații, testarea comportamentului sistemului în ansamblu este imposibilă - secțiuni individuale ale codului programului nu pot fi executate niciodată, în timp ce acestea vor fi acoperite de cerințe. Managerii de excepții sunt un exemplu de astfel de secțiuni de cod. Dacă, de exemplu, două module își trimit valori numerice unul altuia, iar funcțiile de validare a valorii funcționează în ambele module, atunci funcția de verificare a modulului receptor nu va fi niciodată activată, deoarece toate valorile eronate vor fi tăiate în transmițător. În acest caz, se efectuează o analiză manuală a codului programului pentru corectitudine, numită și revizuiri de cod sau inspecții. Dacă, în urma inspecției, sunt identificate zone cu probleme, atunci informațiile despre acestea sunt transferate dezvoltatorilor pentru corectare împreună cu rezultatele testelor regulate. 2.3. Mediul de testare Cea mai mare parte a testării aproape oricărui sistem complex este de obicei efectuată în mod automat. În plus, sistemul testat este de obicei împărțit în module separate, fiecare dintre acestea fiind testat mai întâi separat de celelalte, apoi ca întreg. Aceasta înseamnă că, pentru a efectua testarea, este necesar să se creeze un mediu care să asigure lansarea și execuția modulului testat, să-i treacă datele de intrare, să colecteze date reale de ieșire obținute ca urmare a rulării sistemului pe date de intrare date. . După aceea, mediul ar trebui să compare datele reale de ieșire cu cele așteptate și, pe baza acestei comparații, să tragă o concluzie despre conformitatea comportamentului modulului cu cel specificat (Fig. 9). Driver de testare Date de ieșire așteptate în timpul procesării testului Datele de intrare Modulul Rezultate Stub-uri de date de ieșire reală 9 Schema generalizată a mediului de testare Mediul de testare poate fi folosit și pentru a înstrăina modulele individuale ale sistemului de întregul sistem. Separarea modulelor de sistem în primele etape ale testării vă permite să localizați mai precis problemele care apar în codul programului lor. Pentru a sprijini funcționarea unui modul izolat de sistem, mediul de testare ar trebui să modeleze comportamentul tuturor modulelor ale căror funcții sau date sunt accesate de modulul testat. 29
Trimiteți-vă munca bună în baza de cunoștințe este simplu. Utilizați formularul de mai jos
Studenții, studenții absolvenți, tinerii oameni de știință care folosesc baza de cunoștințe în studiile și munca lor vă vor fi foarte recunoscători.
Găzduit la http://www.allbest.ru/
abstract
Metode de verificare și testare software
Introducere
Oamenii au tendința de a face greșeli. Greșelile au fost întotdeauna și vor fi întotdeauna. Există o glumă în mediul IT că, dacă programul pornește prima dată și funcționează imediat, atunci trebuie să cauți o eroare.
Odata cu dezvoltarea informatică, odată cu pătrunderea sa în toate sferele vieții, crește și numărul erorilor din programe. Mai mult, creșterea erorilor este disproporționată cu creșterea numărului de programe. În fiecare an, rândurile programatorilor sunt completate cu bydlocoders (și numele lor este legion), care dezvoltă câmpul erorilor în mod exponențial.
Erorile nu sunt vizibile în fiecare zonă. De exemplu, nimănui nu îi pasă de bug-uri și vulnerabilități în browsere precum „amigo”. Da, iar pierderile din astfel de erori sunt nesemnificative: maximul pe care un utilizator obișnuit îl poate pierde sunt conturile în rețelele de socializare, o mie și jumătate de fotografii de vacanță mediocre și o colecție porno.
Există însă domenii în care erorile de programare pot duce la cele mai nefericite consecințe. Unul dintre primele cazuri pe care le-am putut găsi este nava spațială Mariner 1, care a fost distrusă pe 22 iulie 1962, la 293 de secunde după lansare, din cauza unei erori în programul computerului de bord. E bine că atunci nu au fost morți.
Și ce se va întâmpla dacă computerul de bord Boeing-747, cu patru sute de pasageri la bord, va face o excepție?
Pentru astfel de zone care pot fi numite „serioase” au fost inventate metodele de verificare și testare.
În unele literaturi străine, procesele de verificare și testare sunt identificate, iar în unele locuri testarea este considerată una dintre metodele de verificare. Voi efectua această lucrare după înțelesul meu, luând în considerare separat procesele de verificare și testare. De asemenea, în mod corect, voi atinge subiectul validării software-ului.
1. Definiții
Ciclu de viață software (LC). Acest termen se referă la intervalul de timp pornind de la ideea de a crea un software cu funcționalitatea necesară pentru a rezolva anumite probleme până la încetarea completă a utilizării ultima versiune acest program.
Artefacte ciclul de viață al software-ului (SW). Aceasta include o varietate de materiale informative legate de crearea de software. Aceștia sunt termeni de referință, descrierea arhitecturii, codul sursă, documentația utilizatorului și alte documente. Materialele care au fost folosite în timpul dezvoltării, dar care nu au fost înregistrate într-o formă accesibilă (de exemplu, comentarii în cod și abuzul dezvoltatorilor în chat) nu sunt artefacte.
2. Verificare
Verificarea verifică conformitatea unor artefacte create în cursul dezvoltării și întreținerii software cu altele create anterior sau utilizate ca date inițiale, precum și conformitatea acestor artefacte și procesele lor de dezvoltare cu regulile și standardele. În special, verificarea verifică corespondența dintre normele standardelor, descrierea cerințelor (termenii de referință) pentru software, soluții de proiectare, codul sursă, documentația utilizatorului și funcționarea software-ului în sine. În plus, se verifică dacă cerințele solutii de proiectare, documentația și codul sunt întocmite în conformitate cu normele și standardele adoptate într-o anumită țară, industrie și organizație la dezvoltarea software-ului și, de asemenea, că la crearea acestora, toate operațiunile specificate în standarde au fost efectuate în succesiunea cerută. Erorile și defectele detectate în timpul verificării sunt discrepanțe sau contradicții între câteva dintre documentele enumerate, între documente și funcționarea efectivă a programului, între normele standardelor și procesele propriu-zise de dezvoltare și întreținere a software-ului. În același timp, a decide ce document urmează să fie corectat (poate ambele) este o sarcină separată.
Cele de mai sus este definiția oficială a verificării. De fapt, totul este mult mai simplu: verificarea determină facem bine programul?.
Astfel, principalele metode de verificare sunt examinarea și inspecția.
verificarea expertizei programului
3. Validare
Procesul de validare verifică conformitatea oricăror artefacte create sau utilizate în timpul dezvoltării și întreținerii software-ului cu nevoile și cerințele utilizatorilor și clienților acestui software, ținând cont de legile. domeniul subiectuluiși limitările contextului în care software-ul este utilizat.
Și din nou, în spatele multor cuvinte, există un foarte sarcină simplă: în timpul procesului de validare se verifică dacă acești utilizatori/clienți au nevoie de o anumită funcționalitate a programului. Produsul software îndeplinește dorințele clienților și utilizatorilor finali.
4. Testare
Testarea este procesul de detectare a erorilor în software prin executarea codului unui sistem software pe datele de testare, colectarea caracteristicilor de performanță în dinamica execuției într-un mediu de operare specific, identificarea diferitelor erori, defecte, defecțiuni și defecte cauzate de situații neregulate și anormale. sau terminarea anormală a software-ului.
Din punct de vedere istoric, primul tip de testare a fost depanarea.
Depanarea este verificarea descrierii unui obiect de program într-un limbaj de programare pentru a detecta erorile din acesta și apoi a le elimina. Erorile sunt detectate de compilator în timpul controlului lor sintactic. După depanare, se efectuează verificarea pentru a verifica corectitudinea codului și validarea pentru a verifica dacă produsul îndeplinește cerințele specificate.
1. Metode de testare statică
Metodele statice sunt utilizate atunci când se efectuează inspecții și se revizuiesc specificațiile componentelor fără implementarea acestora. Tehnica analizei statice consta in revizuirea si analiza metodica a structurii programelor, precum si in demonstrarea corectitudinii acestora. Analiza statică vizează analiza documentelor elaborate în toate etapele ciclului de viață și constă în inspecția codului sursă și controlul end-to-end al programului.
Inspecția software este o verificare statică a conformității programului cu specificațiile date, realizată prin analiza diferitelor reprezentări ale rezultatelor proiectării (documentație, cerințe, specificații, diagrame sau cod sursă al programului) asupra proceselor ciclului de viață. Evaluările și inspecțiile rezultatelor proiectării și conformitatea acestora cu cerințele clienților oferă mai multe calitate superioară sisteme software create.
2. Metode de testare dinamică
Metoda cutiei negre. Atunci când se utilizează această metodă, se folosesc informații despre problema rezolvată, dar nu se știe nimic despre structura programului. Scopul testării conform acestui principiu este de a identifica numărul maxim de erori cu un singur test folosind un subset mic de date posibile de intrare.
Metodele de testare conform acestui principiu sunt folosite pentru a testa funcțiile implementate în program prin verificarea discrepanței dintre comportamentul real al funcțiilor și comportamentul așteptat, ținând cont de specificațiile cerințelor. În timpul pregătirii pentru această testare, sunt construite tabele de condiții, grafice cauza-efect 1 și zonele de defecțiune. În plus, sunt pregătite suite de testare care țin cont de parametrii și condițiile de mediu care afectează comportamentul funcțiilor.
Metoda cutiei albe.
Această metodă vă permite să explorați structura internă a programului, iar detectarea tuturor erorilor din program este un criteriu pentru testarea exhaustivă a rutelor fluxului de control, printre care sunt luate în considerare:
Criteriul de acoperire a operatorului - un set de teste în agregat trebuie să asigure că fiecare operator este trecut cel puțin o dată;
Criteriul de testare a ramurilor (aka acoperire de decizie sau acoperire de tranziție) - setul de teste în agregat trebuie să asigure că fiecare ramură sau ieșire este trecută cel puțin o dată.
3. Testare funcțională
Scopul testării funcționale este de a detecta neconcordanțe între comportamentul real al funcțiilor implementate și comportamentul așteptat conform specificației și cerințelor inițiale. Testele funcționale ar trebui să acopere toate funcțiile implementate, ținând cont de cele mai probabile tipuri de erori. Scenariile de testare care combină teste individuale sunt axate pe verificarea calității rezolvării problemelor funcționale.
Testele funcționale sunt create conform specificațiilor de funcții, informații de proiectare și text într-un limbaj de programare și sunt utilizate pentru a determina caracterul complet al implementării sarcinilor funcționale și conformitatea acestora cu cerințele inițiale.
Sarcinile de testare funcțională includ:
Identificarea unui set de cerințe funcționale;
Identificarea funcțiilor externe și construirea secvențelor de funcții în conformitate cu utilizarea acestora în sistemul software;
Identificarea setului de date de intrare ale fiecărei funcții și determinarea zonelor de modificare a acestora;
Construirea de suite de testare și scenarii pentru funcții de testare;
Identificarea și prezentarea tuturor cerințelor funcționale folosind cazuri de testare și erori de testare în program și în interacțiunea cu mediul.
Testele create din informațiile de proiectare sunt asociate cu structuri de date, algoritmi, interfețe între componente individuale și sunt utilizate pentru a testa componentele și interfețele acestora. Scopul principal este de a asigura integralitatea și consecvența funcțiilor implementate și a interfețelor dintre ele.
5. Tipuri de eroare ANSI/IEEE-7 29 -8 3
Eroare (eroare) - starea programului, în care se produc rezultate incorecte, a căror cauză sunt defecte (defecțiuni) în declarațiile programului sau în proces tehnologic dezvoltarea acestuia, ceea ce duce la interpretare greșită informații generale, ceea ce duce la o soluție greșită.
Defect (defecțiune) în program - o consecință a erorilor dezvoltatorului în orice stadiu de dezvoltare, care poate fi conținută în specificațiile originale sau de proiectare, textele codurilor de program, documentația operațională etc. În timpul execuției programului, poate fi detectat un defect sau o defecțiune.
Eșecul (eșecul) este o abatere a programului de la funcționare sau incapacitatea programului de a îndeplini funcțiile definite de cerințe și restricții, care este considerată ca un eveniment care contribuie la trecerea programului la o stare inoperabilă din cauza erorilor. , defecte latente în acesta sau defecțiuni în mediul de funcționare. Eșecul poate fi rezultatul următoarelor motive:
O specificație eronată sau o cerință omisă, ceea ce înseamnă că specificația nu reflectă cu exactitate ceea ce a intenționat utilizatorul;
Specificația poate conține o cerință care nu poate fi îndeplinită pentru hardware-ul și software-ul dat;
Designul programului poate conține erori (de exemplu, baza de date este proiectată fără mijloace de protecție împotriva accesului neautorizat al utilizatorilor, dar este necesară protecția);
Programul poate fi incorect, de ex. efectuează un algoritm neobișnuit sau nu este pe deplin implementat.
Concluzie
GOST-urile rusești legate de verificarea și testarea software-ului sunt traduceri ale standardelor „burgheze” precum ISO 12207, ANSI/IEEE-729-83 și altele (există multe). Problema este că aceste standarde internaționale tratează diferit problemele de testare și verificare. Ca să nu spun că se contrazic complet, dar pot provoca nedumerire.
Toate aceste standarde au fost formulate în anii 80 ai secolului trecut pentru industria spațială din SUA. În anii următori, acestea au fost corectate și republicate, dar au rămas dezacorduri și contradicții în documente.
Concluzie: structura metodelor de verificare, validare și testare trebuie percepută ca fiind condiționată.
Bibliografie
1. Enciclopedie gratuită wikipedia.org
2. Kulyamin V.V. Metode de verificare a software-ului M.: Institute for System Programming, 2008
3. Lavrishcheva E., Petrukhin V. Prelegere „Metode pentru verificarea și testarea programelor și sistemelor”: NOU „INTUIT” http://www.intuit.ru/studies/professional_retraining/944/courses/237/print_lecture/6130
Găzduit pe Allbest.ru
...Documente similare
Ciclul de viață al software-ului este un proces continuu care începe cu o decizie privind necesitatea creării software-ului și se termină cu retragerea completă a acestuia din funcționare. Abordarea lui Riley, Lehman și Boehm cu privire la definirea ciclului de viață al software-ului.
rezumat, adăugat la 01.11.2009
Conceptul de tehnologie de dezvoltare a programelor. Baza proiectării software-ului. Modele de ciclu de viață care au apărut istoric în timpul dezvoltării teoriei proiectării software. Modele spiralate (spirale), în cascadă și iterative.
prezentare, adaugat 05.11.2015
Istoricul dezvoltării și tipurile de testare software. Instalare, regresie, configurare, integrare, localizare, testare unitară. Metode de reducere a complexității testării unitare a aplicației dezvoltate.
lucrare de termen, adăugată 16.12.2015
Indecidibilitatea problemei de testare a software-ului. Tipuri și niveluri de testare. Strategii de testare în amonte și în aval. Metode de cutie „albă” și „neagră”. Testare automată și manuală. Dezvoltare prin testare.
lucrare de termen, adăugată 22.03.2015
Cerințe pentru tehnologia de proiectare software (SW). Alcătuirea și descrierea etapelor ciclului de viață complet al software-ului. Clasificarea modelelor ciclului de viață al software-ului, caracteristicile acestora. Metodologii de dezvoltare software, tehnici extreme de programare.
prezentare, adaugat 19.09.2016
Istoricul testării software-ului, principalele obiective și caracteristici ale implementării acestuia. Tipuri și tipuri de testare, niveluri de automatizare a acesteia. Utilizare și cercetare tehnologiile necesare. Ciclu complet rulează întregul sistem de monitorizare.
teză, adăugată 05.03.2018
Principalele standarde internaționale în domeniu tehnologia Informatiei. standard international ISO/IEC 9126 Calitate și ciclu de viață. Caracterizarea atributelor interne și externe ale calității. Analiza funcționalității software-ului.
raport, adaugat 13.06.2017
Scopurile și obiectivele ingineriei software. Conceptul de software. Șase principii utilizare eficientă software. Tipuri de software: la nivel de sistem, de rețea și aplicat. Principii de construire a software-ului.
lucrare de termen, adăugată 29.06.2010
Caracteristici generale ale principalelor modele de ciclu de viață: cascadă, incrementală, spirală. O etapă ca parte a procesului de dezvoltare software, limitată la un anumit interval de timp și care se termină cu lansarea unui anumit produs.
prezentare, adaugat 27.12.2013
Informatizarea Rusiei. Piaţă instrumente software. Principalele sarcini de standardizare, certificare si licentiere in domeniul informatizarii. Un set de metode și instrumente de inginerie pentru crearea de software. Ciclul de viață al software-ului.
Verificarea și validarea se referă la procesele de verificare și revizuire care verifică dacă software-ul respectă specificațiile și cerințele clientului. Verificarea și validarea acoperă întregul ciclu de viață al software-ului - ele încep în etapa de analiză a cerințelor și se termină cu verificarea codului programului în etapa de testare a sistemului software finit.
Verificarea și atestarea nu sunt același lucru, deși este ușor să le confundăm. Pe scurt, diferența dintre ele poate fi definită după cum urmează:
Verificarea răspunde la întrebarea dacă sistemul este proiectat corespunzător;
Certificarea răspunde la întrebarea dacă sistemul funcționează corect.
Conform acestor definiții, verificarea verifică dacă software-ul este conform cu specificațiile sistemului, în special cu cerințele funcționale și nefuncționale. Certificarea este un proces mai general. În timpul validării, trebuie să vă asigurați că produsul software corespunde așteptărilor clientului. Validarea se efectuează după verificare pentru a determina modul în care sistemul îndeplinește nu numai specificația, ci și așteptările clientului.
După cum sa menționat mai devreme, validarea cerințelor de sistem este foarte importantă în etapele incipiente ale dezvoltării software. Există adesea erori și omisiuni în cerințe; în astfel de cazuri, produsul final probabil nu va satisface așteptările clientului. Dar, desigur, validarea cerințelor nu poate dezvălui toate problemele din specificația cerințelor. Uneori, lacune și erori în cerințe sunt descoperite numai după finalizarea implementării sistemului.
Procesele de verificare și validare folosesc două tehnici principale pentru verificarea și analiza sistemelor.
1. Inspecție software. Analiza și verificarea diferitelor reprezentări ale sistemului, cum ar fi documentația cu specificațiile cerințelor, diagramele arhitecturale sau codul sursă al programului. Inspecția este efectuată în toate etapele procesului de dezvoltare a sistemului software. În paralel cu inspecția, se poate efectua analiza automată a codului sursă al programelor și documentelor aferente. Inspecția și analiza automatizată sunt metode statice de verificare și validare deoarece nu necesită un sistem executabil.
2. Testarea software-ului. Rularea codului executabil cu datele de testare și examinarea rezultatelor și performanței produsului software pentru a verifica dacă sistemul funcționează corect. Testarea este o metodă dinamică de verificare și validare deoarece este aplicată sistemului care rulează.
Pe fig. Figura 20.1 arată locul inspecției și testării în procesul de dezvoltare a software-ului. Săgețile indică etapele procesului de dezvoltare în care aceste metode pot fi aplicate. Conform acestei scheme, inspecția poate fi efectuată în toate etapele procesului de dezvoltare a sistemului și testarea - atunci când este creat un prototip sau un program executabil.
Metodele de inspecție includ: inspecția programului, analiza automată a codului sursă și verificarea formală. Dar metodele statice nu pot decât să verifice conformitatea programelor cu specificația; ele nu pot fi folosite pentru a verifica funcționarea corectă a sistemului. În plus, caracteristicile nefuncționale precum performanța și fiabilitatea nu pot fi testate cu metode statice. Prin urmare, pentru a evalua caracteristicile nefuncționale, se efectuează testarea sistemului.
Orez. 20.1. Verificare și atestare statică și dinamică
În ciuda utilizării pe scară largă a inspecției software, testarea este încă metoda predominantă de verificare și certificare. Testarea este o verificare a funcționării programelor cu date similare cu cele reale, care vor fi procesate în timpul funcționării sistemului. Prezența în program a defecte și inconsecvențe cu cerințele este detectată prin examinarea datelor de ieșire și identificarea celor anormale dintre acestea. Testarea este efectuată în timpul fazei de implementare a sistemului (pentru a verifica dacă sistemul corespunde așteptărilor dezvoltatorilor) și după finalizarea implementării acestuia.
Diferite tipuri de testare sunt utilizate în diferite etape ale procesului de dezvoltare software.
1. Testarea defectelor efectuate pentru a detecta neconcordanțe între program și specificațiile acestuia, care se datorează erorilor sau defectelor din programe. Astfel de teste sunt concepute pentru a detecta erori în sistem și nu pentru a simula funcționarea acestuia.
2. Testare statistică evaluează performanța și fiabilitatea programelor, precum și funcționarea sistemului în diferite moduri de operare. Testele sunt concepute pentru a imita funcționarea reală a sistemului cu date reale de intrare. Fiabilitatea sistemului este evaluată prin numărul de defecțiuni observate în activitatea programelor. Performanța este evaluată prin măsurarea timpului total de funcționare și a timpului de răspuns al sistemului la procesarea datelor de testare.
obiectivul principal Verificare și calificare - pentru a se asigura că sistemul este „potrivit scopului”. Adecvarea unui sistem software pentru scopul propus nu înseamnă că ar trebui să fie absolut lipsit de erori. Mai degrabă, sistemul ar trebui să fie rezonabil de bine adaptat scopurilor pentru care a fost destinat. Necesar validitatea conformității depinde de scopul sistemului, de așteptările utilizatorilor și de condițiile pieței pentru produsele software.
1. Scopul software-ului. Nivelul de fiabilitate a conformității depinde de cât de critic este software-ul dezvoltat în funcție de anumite criterii. De exemplu, nivelul de încredere pentru sistemele critice pentru siguranță ar trebui să fie semnificativ mai mare decât cel pentru sistemele software prototip dezvoltate pentru a demonstra o idee nouă.
2. Așteptările utilizatorilor. Trebuie remarcat cu tristețe că în prezent, majoritatea utilizatorilor au cerințe scăzute pentru software. Utilizatorii sunt atât de obișnuiți cu eșecurile care apar în timpul rulării programelor încât nu sunt surprinși de acest lucru. Sunt dispuși să tolereze defecțiunile sistemului dacă beneficiile utilizării acestuia depășesc dezavantajele. Cu toate acestea, de la începutul anilor 1990, toleranța utilizatorilor pentru defecțiunile sistemelor software a scăzut treptat. Recent, crearea de sisteme nefiabile a devenit aproape inacceptabilă, astfel încât companiile de dezvoltare de software trebuie să acorde din ce în ce mai multă atenție verificării și validării software-ului.
3. Condițiile pieței software. Atunci când evaluează un sistem software, vânzătorul trebuie să cunoască sistemele concurente, prețul pe care cumpărătorul este dispus să-l plătească pentru sistem și timpul așteptat de lansare pe piață pentru acel sistem. Dacă compania de dezvoltare are mai mulți concurenți, este necesar să se determine data intrării sistemului pe piață înainte de încheierea testării complete și a depanării, altfel concurenții pot fi primii care intra pe piață. Dacă clienții nu sunt dispuși să achiziționeze software la un preț ridicat, ei pot fi dispuși să tolereze mai multe defecțiuni ale sistemului. La determinarea costurilor procesului de verificare și calificare trebuie să se țină seama de toți acești factori.
De regulă, erorile sunt găsite în sistem în timpul verificării și atestării. Se fac modificări în sistem pentru a corecta erorile. Acest proces de depanare de obicei integrate cu alte procese de verificare și atestare. Cu toate acestea, testarea (sau mai general, verificarea și validarea) și depanarea sunt procese diferite care au scopuri diferite.
1. Verificarea și validarea este procesul de detectare a defectelor într-un sistem software.
2. Depanare - procesul de localizare a defectelor (erori) și remediere a acestora (Fig. 20.2).
Orez. 20.2. Procesul de depanare
Nu există metode simple de depanare a programelor. Depanatorii experimentați găsesc erori prin compararea tiparelor de ieșire de testare cu rezultatele sistemelor testate. Pentru a localiza o eroare este nevoie de cunoștințe despre tipurile de erori, modelele de ieșire, limbajul de programare și procesul de programare. Cunoașterea procesului de dezvoltare software este foarte importantă. Depanatorii sunt conștienți de cele mai frecvente erori de programare (cum ar fi creșterea unui contor). De asemenea, ia în considerare erorile care sunt tipice pentru anumite limbaje de programare, de exemplu, cele asociate cu utilizarea pointerilor în limbajul C.
Localizarea erorilor în codul programului nu este întotdeauna un proces simplu, deoarece eroarea nu este neapărat localizată în apropierea punctului din codul programului în care a avut loc accidentul. Pentru a izola erorile, depanatorul dezvoltă teste software suplimentare care ajută la identificarea sursei erorii în program. Poate fi necesar să urmăriți manual execuția programului.
Instrumentele interactive de depanare fac parte dintr-un set de instrumente de suport pentru limbaj care sunt integrate cu sistemul de compilare a codului. Acestea oferă un mediu special de execuție a programului prin care puteți accesa tabelul de identificatori, iar de acolo la valorile variabilelor. Utilizatorii controlează adesea execuția unui program într-o manieră pas cu pas, trecând de la instrucțiune la instrucțiune în secvență. După executarea fiecărei instrucțiuni, se verifică valorile variabilelor și se identifică eventualele erori.
Eroarea găsită în program este corectată, după care este necesar să verificați din nou programul. Pentru a face acest lucru, puteți reinspecta programul sau repeta testul anterior. Retestarea este folosită pentru a ne asigura că modificările aduse programului nu introduc noi erori în sistem, deoarece în practică un procent mare de „remedieri de erori” fie nu se completează complet, fie introduc noi erori în program.
În principiu, este necesar să rulați din nou toate testele în timpul retesării după fiecare remediere, dar în practică, această abordare este prea costisitoare. Prin urmare, la planificarea procesului de testare, dependențele dintre părțile sistemului sunt determinate și teste sunt atribuite pentru fiecare parte. Apoi este posibilă urmărirea elementelor programului utilizând cazuri de testare speciale (date de control) selectate pentru aceste elemente. Dacă rezultatele urmăririi sunt documentate, atunci numai un subset din setul total de date de testare poate fi utilizat pentru a testa elementul de program modificat și componentele sale dependente.
Planificare pentru verificare și atestare
Verificarea și validarea este un proces costisitor. Pentru sistemele mari, cum ar fi sistemele în timp real cu constrângeri complexe nefuncționale, jumătate din bugetul de dezvoltare a sistemului este cheltuit pentru procesul de verificare și validare. Prin urmare, necesitatea unei planificări atentă a acestui proces este evidentă.
Planificarea verificării și validării, ca parte a dezvoltării sistemelor software, ar trebui să înceapă cât mai devreme posibil. Pe fig. Figura 20.3 prezintă un model de dezvoltare software care ia în considerare procesul de planificare a testelor. Aici începe planificarea încă din fazele de specificare și proiectare a sistemului. Acest model este uneori denumit model V (pentru a vedea V, rotiți Figura 20.3 cu 90°). Această diagramă arată și împărțirea procesului de verificare și atestare în mai multe etape, cu testele corespunzătoare efectuate la fiecare etapă.
Orez. 20.3. Planificarea testelor în timpul dezvoltării și testării
În procesul de verificare și certificare a planificării, este necesar să se determine relația dintre metodele statice și dinamice de verificare a sistemului, să se determine standarde și proceduri pentru inspecția și testarea software-ului, să se aprobe harta tehnologica revizuiri software (vezi Secțiunea 19.2) și dezvoltați un plan de testare software. Dacă inspecția sau testarea este mai importantă depinde de tipul de sistem dezvoltat și de experiența organizației. Cu cât sistemul este mai critic, cu atât mai multă atenție trebuie acordată metodelor de verificare statică.
Planul de verificare și validare se concentrează pe standardele procesului de testare, mai degrabă decât pe descrierea unor teste specifice. Acest plan nu este doar orientativ, ci este destinat în principal profesioniștilor în dezvoltarea și testarea sistemelor. Planul permite personalului tehnic să obțină o imagine completă a testelor sistemului și să își planifice activitatea în acest context. În plus, planul oferă informații managerilor care sunt responsabili pentru a se asigura că echipa de testare are tot hardware-ul și software-ul necesar.
Planul de testare nu este un document fix. Ar trebui revizuit în mod regulat, deoarece testarea depinde de procesul de implementare a sistemului. De exemplu, dacă implementarea unei părți a sistemului nu este finalizată, atunci este imposibil să testați ansamblul sistemului. Prin urmare, planul trebuie revizuit periodic, astfel încât personalul de testare să poată fi folosit în alte locuri de muncă.
Cele două concepte de validare și verificare sunt adesea confundate. În plus, validarea cerințelor de sistem este adesea confundată cu validarea sistemului. Vă sugerez să analizați această problemă.
În articol, am luat în considerare două abordări ale modelării obiectelor: ca întreg și ca structură. În articolul actual, vom avea nevoie de această diviziune.
Să presupunem că avem un obiect funcțional proiectat. Fie ca acest obiect să fie considerat de noi ca o parte a construcției unui alt Obiect funcțional. Să existe o descriere a construcției Obiectului, astfel încât să conțină o descriere a obiectului. Într-o astfel de descriere, obiectul are o descriere ca un întreg, adică interfețele sale de interacțiune cu alte obiecte sunt descrise în cadrul construcției Obiectului. Să fie dată descrierea obiectului ca structură. Să existe un obiect informațional care să conțină cerințe pentru proiectarea descrierii obiectului ca structură. Să existe un corp de cunoștințe care conține reguli de inferență, pe baza cărora se obține o descriere a obiectului ca structură din descrierea obiectului ca întreg. Corpul de cunoștințe este ceea ce designerii sunt predați în institute - multe, multe cunoștințe. Ele permit, pe baza cunoștințelor despre obiect, proiectarea structurii acestuia.
Deci, puteți începe. Putem afirma că dacă obiectul în ansamblu este corect descris, dacă corpul de cunoștințe este corect și dacă regulile de inferență au fost respectate, atunci descrierea rezultată a construcției obiectului va fi corectă. Adică, pe baza acestei descrieri, un obiect funcțional corespunzător conditii reale Operațiune. Ce riscuri pot apărea:
1. Utilizarea cunoștințelor incorecte despre Obiect. Modelul Obiectului din mintea oamenilor poate să nu corespundă realității. Ei nu cunoșteau pericolul real al cutremurelor, de exemplu. În consecință, cerințele pentru obiect pot fi formulate incorect.
2. Înregistrare incompletă a cunoștințelor despre Obiect - ceva este omis, se fac greșeli. De exemplu, știau despre vânturi, dar au uitat să menționeze. Acest lucru poate duce la o descriere insuficient de completă a cerințelor pentru obiect.
3. Corp greșit de cunoștințe. Ni s-a învățat prioritatea masei față de alți parametri, dar s-a dovedit că trebuie să creștem viteza.
4. Aplicarea incorectă a regulilor de inferență la descrierea obiectului. Erori logice, ceva lipsește în cerințele pentru proiectarea obiectului, urma cerințelor este ruptă.
5. Înregistrare incompletă a concluziilor obținute despre proiectarea sistemului. Totul a fost luat în calcul, totul a fost calculat, dar au uitat să scrie.
6. Sistemul creat nu corespunde descrierii.
Este clar că toate artefactele proiectului apar, de regulă, în forma lor completată numai până la sfârșitul proiectului și chiar și atunci nu întotdeauna. Dar, dacă presupunem că dezvoltarea este în cascadă, atunci riscurile sunt așa cum am descris. Verificarea fiecărui risc este o operațiune specifică căreia i se poate da un nume. Dacă cineva este interesat, puteți încerca să veniți cu și să exprimați acești termeni.
Ce este verificarea? În rusă, verificarea este o verificare a conformității cu regulile. Regulile sunt sub forma unui document. Adică ar trebui să existe un document cu cerințe de documentare. Dacă documentația îndeplinește cerințele acestui document, atunci a trecut verificarea.
Ce este validarea? În limba rusă, validarea este verificarea corectitudinii concluziilor. Adică, ar trebui să existe un corp de cunoștințe care să descrie cum să obțineți o descriere a unui design bazat pe datele obiectului. Verificarea corectitudinii aplicării acestor concluzii este validare. Validarea înseamnă, printre altele, verificarea consecvenței, completitudinii și inteligibilității descrierii.
Validarea cerințelor este adesea confundată cu validarea unui produs construit pe acele cerințe. Nu merită să faci asta.
