Cerințe pentru criteriu ideal au fost propuse în lucrare:

Criteriile trebuie să fie suficiente, adică arată când un set finit de teste este suficient pentru a testa programul dat.

Criteriile trebuie să fie complete, adică în cazul unei erori, trebuie să existe un test din setul de teste care să îndeplinească criteriul care relevă eroarea.

Criteriul trebuie să fie de încredere, adică oricare două seturi de teste care o satisfac trebuie să dezvăluie sau să nu dezvăluie simultan erorile de program

Criteriul ar trebui să fie ușor de verificat, de exemplu, calculat pe teste

Pentru clase netriviale de programe în cazul general nu există un criteriu complet și de încredere, in functie de programe sau specificatii.De aceea, ne straduim spre un criteriu general ideal prin intermediul unor adevarate private.

Clase de criterii

Criterii structurale utilizați informații despre structura programului (așa-numitele criterii „cutie albă”)

Criterii funcționale sunt formulate în descrierea cerințelor pentru produsul software ( așa-numitele criterii „cutie neagră”.)

Criterii testarea stocastică sunt formulate prin prisma verificării prezenței proprietăților specificate în aplicația testată, prin testarea unor ipoteze statistice.

Criterii de mutație concentrat pe verificarea proprietăților unui produs software bazat pe abordarea Monte Carlo.

Criterii structurale (clasa I).

Criterii structurale utilizați un model de program cu casetă albă, care implică cunoașterea codului sursă al programului sau a specificației programului sub forma unui grafic de flux de control. Informațiile structurale sunt ușor de înțeles și accesibile dezvoltatorilor de subsisteme și module de aplicație, astfel încât această clasă de criterii este adesea folosită în etapele testării unitare și de integrare (testare unitară, testare de integrare). Criterii structurale se bazează pe elementele principale ale UGP, operatori, ramuri și căi.

Condiție de criteriu testarea în echipă(criteriul C0) - un set de teste în agregat trebuie să asigure că fiecare comandă este trecută cel puțin o dată. Acesta este un criteriu slab, de obicei este folosit în sistemele software mari unde nu pot fi aplicate alte criterii.

Condiție de criteriu testarea ramurilor(criteriul C1) - un set de teste în agregat trebuie să asigure că fiecare ramură este trecută cel puțin o dată. Acesta este un criteriu destul de puternic, dar economic, deoarece setul de ramuri din aplicația testată este finit și nu foarte mare. Acest criteriu este adesea folosit în sistemele de automatizare a testelor.

Condiție de criteriu testarea traseului(criteriul C2) - un set de teste în agregat trebuie să asigure că fiecare cale este trecută de cel puțin 1 dată. Dacă programul conține o buclă (în special una cu un număr implicit de iterații), atunci numărul de iterații este limitat la o constantă (adesea 2, sau numărul de clase de căi de ieșire).

Este prezentat un exemplu de program simplu. Luați în considerare condițiile pentru testarea acestuia în conformitate cu criterii structurale.

1 metoda public void (ref int x) ( 2 dacă (x>17) 3 x = 17-x; 4 dacă (x==-13) 5 x = 0; 6 ) Exemplul 3.1. Un exemplu de program simplu de testare pe baza criteriilor structurale

1 metoda void (int *x) ( 2 dacă (*x>17) 3 *x = 17-*x; 4 dacă (*x==-13) 5 *x = 0; 6 ) Exemplul 3.1.1. Un exemplu de program simplu de testare pe baza criteriilor structurale

Caz de testare unic, satisface criteriul de comandă (C0): (X,Y)=((x in =30, x out =0)) acoperă toate instrucțiunile de urmărire 1-2-3-4-5-6 Setul de teste de două teste, satisface criteriul de ramificare (C1):(X,Y)=((30,0), (17,17)) adaugă 1 test la set de teste pentru C0 și pista 1-2-4-6. Urma 1-2-3-4-5-6 parcurge toate ramurile accesibile în declarațiile if date true , iar traseul 1-2-4-6 parcurge toate ramurile accesibile în declarațiile if date false . O suită de teste de patru teste , satisface criteriul de cale (C2): (X,Y)=((30,0), (17,17), (-13,0), (21,-4)) Setul de condiții pentru doi dacă enunțurile etichetate 2 și 4 sunt date în

Tabelul 3.1. Condițiile declarațiilor if

	(30,0)	(17,17)	(-13,0)	(21,-4)
2 dacă (x>17)	>			>
4 dacă (x==-13)	=		=

Criteriul de ramură C2 verifică programul mai amănunțit decât criteriul C1, cu toate acestea, chiar dacă este satisfăcut, nu există niciun motiv pentru a afirma că programul este implementat în conformitate cu specificația (-177,-177). Într-adevăr, operatorii 3 și 4 din test (-177, -177) nu vor modifica valoarea x=-177 și rezultatul nu va îndeplini specificația. Criterii structurale nu verificați conformitatea cu specificația dacă nu se reflectă în structura programului. Prin urmare, în timpul testării cu succes a programului conform criteriului C2, este posibil să nu observăm o eroare asociată cu neîndeplinirea unor condiții din specificația cerințelor.

Criterii funcționale (Clasa II)

Criteriu funcțional- cel mai important criteriu de testare pentru industria software. Oferă, în primul rând, controlul gradului de îndeplinire a cerințelor clienților în produsul software. Deoarece cerințele sunt formulate pentru produs în ansamblu, ele reflectă interacțiunea aplicației testate cu mediul. În testarea funcțională se folosește predominant modelul „cutie neagră”. Problema testării funcționale este, în primul rând, laboriozitatea; Faptul este că documentele care stabilesc cerințele pentru un produs software (Specificația cerințelor software, Specificația funcțională etc.), de regulă, sunt destul de voluminoase, cu toate acestea, verificarea corespunzătoare ar trebui să fie cuprinzătoare. Mai jos sunt anumite tipuri criterii functionale.

Testarea articolului de specificație- un set de teste în agregat ar trebui să asigure că fiecare element de testat este verificat cel puțin o dată.

O specificație de cerințe poate conține sute și mii de cerințe pentru un produs software, iar fiecare dintre aceste cerințe în timpul testării trebuie verificată în conformitate cu criteriul prin cel puțin un test.

Testarea claselor de intrare- un set de teste în agregat ar trebui să asigure că un reprezentant al fiecărei clase de date de intrare este verificat cel puțin o dată.

La crearea testelor, clasele de date de intrare sunt mapate la modurile de utilizare ale componentei testate sau ale subsistemului aplicației, ceea ce reduce semnificativ opțiunile de iterație care sunt luate în considerare la dezvoltarea suitelor de testare. Trebuie remarcat faptul că atunci când sortăm valorile variabilelor de intrare în conformitate cu criteriul (de exemplu, diverse fișiere - surse de date de intrare), suntem forțați să folosim suite de testare puternice. Într-adevăr, împreună cu restricțiile privind valorile datelor de intrare, există restricții asupra valorilor datelor de intrare în toate combinațiile posibile, inclusiv verificarea răspunsurilor sistemului la apariția erorilor în valorile sau structurile datelor de intrare. Contabilizarea acestei diversități este un proces laborios, care creează dificultăți în aplicarea criteriului

Testarea regulilor- un set de teste în agregat trebuie să asigure verificarea fiecărei reguli, dacă valorile de intrare și de ieșire sunt descrise printr-un set de reguli, ceva gramatical.

Trebuie remarcat faptul că gramatica trebuie să fie suficient de simplă, astfel încât complexitatea dezvoltării setului corespunzător de teste să fie reală (se încadrează în termenele limită și personalul de specialiști alocat pentru implementarea fazei de testare)

Testarea claselor de ieșire- setul de teste în agregat trebuie să asigure verificarea unui reprezentant al fiecărei clase de ieșiri, cu condiția ca rezultatele de ieșire să fie preclasificate, iar clasele individuale de rezultate să țină seama, printre altele, de restricțiile de resurse sau de timp (timp). afară).

La crearea testelor, clasele de ieșire sunt mapate la modurile de utilizare ale componentei sau subsistemului testat, ceea ce reduce semnificativ opțiunile de iterație care sunt luate în considerare la dezvoltarea cazurilor de testare.

Testarea caracteristicilor- un set de teste în agregat ar trebui să asigure că fiecare acțiune implementată de unitatea testată este verificată cel puțin o dată.

Un criteriu foarte popular în practică, care, totuși, nu oferă acoperire a părții din funcționalitatea componentei testate asociată cu proprietăți structurale și comportamentale, a cărei descriere nu este concentrată în funcții individuale (adică descrierea este dispersată peste componenta).

Criteriul de testare a funcțiilor combină parțial caracteristicile structurale și criterii functionale. Se bazează pe modelul „cutie translucidă”, în care nu sunt specificate în mod explicit doar intrările și ieșirile componentei testate, ci și compoziția și structura metodelor (funcții, proceduri) și clasele utilizate.

Criterii combinate pentru programe și specificații- un set de teste în agregat ar trebui să asigure că toate combinațiile de condiții și specificații coerente ale programului sunt verificate cel puțin o dată.

În acest caz, toate combinațiile de condiții consistente trebuie confirmate, iar condițiile contradicțiilor trebuie descoperite și eliminate.

Un exemplu de aplicare a criteriilor de testare funcțională pentru a dezvolta o suită de teste bazată pe criteriul claselor de date de intrare

Să se elaboreze următorul fragment al specificației cerințelor pentru a rezolva problema testării sistemului „Sistem de control pentru complexul de depozitare automată a rulmenților” (a se vedea Anexa 1, FS):

Interogați starea depozitului (apelați funcția GetStoreStat). Adăugați intrarea „SISTEM: Stare DEPOZIT solicitată” în jurnalul de mesaje. În funcție de valoarea primită, efectuați următoarele acțiuni:

Interogați terminalul axei (apelați funcția de primire a unui mesaj de la terminal - GetAxlePar ). Mesajul „SISTEM: Parametrii axei solicitați” ar trebui adăugat în jurnalul de mesaje. În funcție de valoarea returnată de funcția GetAxlePar, trebuie efectuate următoarele acțiuni ():

Să definim clasele de date de intrare pentru parametrul - starea depozitului:

Stare depozit = 0 (corect).

Stare depozit = 4 (corect).

Stare depozit = 16 (corect).

Starea depozitului = 32 (corect).

Stare depozit = orice altă valoare (invalidă).

Acum luați în considerare cazurile de testare:

Cazul de testare 1 (acoperă clasa 4):

Starea depozitului - 32.

Sistemul solicită starea depozitului (apelând funcția GetStoreStat) și primește 32

Cazul de testare 2 (acoperă clasa 5):

Starea mediului (intrare - X ):

Starea depozitului - 12dfga.

Secvența așteptată de evenimente (ieșire - Y):

Sistemul solicită starea depozitului (apelând funcția GetStoreStat) și, conform articolului de specificație, dacă valoarea stării depozitului este incorectă, se adaugă în jurnal mesajul „DEPOZIT: EROARE: Stare nedefinită”.

Teste stocastice (clasa III)

Testarea stocastică este folosit la testarea sistemelor software complexe - când un set de teste deterministe (X, Y) are o putere enormă. În cazurile în care un astfel de set nu poate fi dezvoltat și executat în timpul fazei de testare, se poate aplica următoarea metodologie.

Elaborați programe - simulatoare de secvențe aleatorii de semnale de intrare (x).

Calculați în mod independent valorile (y) pentru semnalele de intrare corespunzătoare (x) și obțineți setul de test (X,Y).

Testați aplicația pe setul de testare (X,Y) folosind două moduri de a controla rezultatele:

Criterii testarea stocastică

Metode statistice sfârşitul testării - metode stocastice de luare a deciziilor despre coincidenţa ipotezelor despre distribuţia variabilelor aleatoare. Printre acestea se numără pe cele bine-cunoscute: metoda lui Student (St ), metoda chi-pătrat (χ 2 ), etc.

Metodă estimări ale ratei de detectare a erorilor- pe baza modelului ratei de detectare a erorilor, conform caruia testarea este oprita daca intervalul de timp estimat intre eroarea curenta si urmatoarea este prea mare pentru faza de testare a aplicatiei.

Orez. 3.1.

La formalizarea modelului ratei de detectare a erorilor (), au fost utilizate următoarele denumiri: N este numărul inițial de erori din pachetul software înainte de testare, C este constanta pentru reducerea ratei de detectare a erorilor prin găsirea următoarei erori, t 1 ,t 2 ,…t n este un tuplu de intervale de detecție a secvenței crescătoare din n erori, T este timpul de detectare a n erori Dacă presupunem că n erori sunt detectate în timpul T, atunci relația (1) este valabilă, afirmând că produsul a ratei de detectare a erorilor i și a timpului de detectare a erorilor i este 1 prin definiție:

(1) (N-i+1)*C*t i = 1

În această ipoteză, relația (2) este valabilă pentru n erori:

(2) N*C*t 1 +(N-1)*C*t 2 +…+(N-n+1)*C*t n =n N*C*(t 1 +t 2 +…+t n ) - C*Σ(i-1)t i = n NCT - C*Σ(i-1)t i = n

Dacă determinăm t i din (1) și însumăm de la 1 la n , atunci ajungem la relația (3) pentru timpul T de detectare a n erori

(3) Σ1/(N-i+1) = TC

Dacă exprimăm C din (2), ajungem la relația (4):

(4) C = n/(NT - Σ(i-1)t i)

În sfârșit, înlocuind C în (3), obținem relația finală (5), care este convenabilă pentru estimări:

(5) Σ1/(N-i+1) = n/(N - 1/T*Σ(i-1)t i)

Dacă estimăm valoarea lui N aproximativ, folosind metode cunoscute de estimare a numărului de erori din program, sau date privind densitatea erorilor pentru proiectele clasei luate în considerare din baza de date istorică a proiectelor și, în plus, utilizați datele actuale despre intervale de eroare t 1 ,t 2 …t n obținut în faza de testare, apoi prin înlocuirea acestor date în (5), putem obține o estimare a t n+1 - intervalul de timp necesar pentru a găsi și corecta următoarea eroare (eroare viitoare). Dacă t n+1 >Td - timpul permis pentru testarea proiectului, atunci terminăm testarea, în caz contrar continuăm căutarea erorilor.erori și rafinăm C în conformitate cu (4). Criteriul Moranda este foarte practic, deoarece se bazează pe informații. colectate în mod tradițional în timpul testării.

Criteriul mutației (clasa IV).

Se postulează că programatorii profesioniști scriu imediat programe aproape corecte care diferă de cele corecte prin erori mici sau erori de tip - schimbând valorile maxime ale indicilor în descrierea matricelor, erori în semnele operațiilor aritmetice, subestimarea sau supraestimarea limita buclei cu 1 etc. Se propune o abordare care permite, pe baza unor erori mici, estimarea numarului total de erori ramase in program.Abordarea se bazeaza pe urmatoarele concepte: Mutatiile sunt mici erori in program. Mutanții sunt programe care diferă unele de altele prin mutații. Metoda de testare a mutațiilor- se introduc mutatii in programul dezvoltat P, i.e. creați artificial programe mutante P1, P2... Apoi programul P și mutanții săi sunt testați pe același set de teste (X,Y).erori introduse în programele mutante, apoi setul de testare (X,Y) se potrivește criteriul mutației, iar programul testat este declarat corect.Dacă unii mutanți nu au dezvăluit toate mutațiile, atunci este necesar să extindeți setul de testare (X,Y) și să continuați testarea.

Un exemplu de aplicare a criteriului mutației

Programul testat P este prezentat în . Pentru aceasta sunt create două programe mutante P1 și P2. În P1, valoarea inițială a variabilei z este schimbată de la 1 la 2 (). În P2, valoarea inițială a variabilei i este modificată de la 1 la 0 și valoarea limită. al indicelui ciclului de la n la n-1 ().La efectuarea testelor (X,Y) = ((x=2,n=3,y=8),(x=999,n=1,y=999), (x=0,n=100,y=0 ) sunt detectate toate erorile din programele mutante și o eroare din programul principal, unde în condiția de buclă în loc de n există n-1 :

// Metoda calculează puterea nenegativă // n a numărului x static public double PowerNonNeg(double x, int n) ( double z=1; if (n>0) ( for (int i=1; n-1> Exemplul 3.2. Programul principal P

dublu PowerNonNeg(dublu x, int n) ( dublu z=1; int i; dacă (n>0) (pentru (i=1;n-1> Exemplul 3.2.1. Programul principal P

Valoarea inițială modificată a variabilei z în mutantul P1 este marcată cu un ton deschis:

// Metoda calculează puterea nenegativă // n a numărului x static public double PowerMutant1(double x, int n) ( double z=2; if (n>0) ( for (int i=1; n>=i;i++) ( z = z*x; ) ) else Console.WriteLine("Eroare! Puterea lui n trebuie să fie mai mare decât 0."); return z; ) Exemplul 3.3. Program mutant P1.

dublu PowerMutant1(dublu x, int n) ( dublu z=2; int i; if (n>0) (pentru (i=1;n>=i;i++) (z = z*x; ) ) else printf( „Eroare! Puterea lui n trebuie să fie mai mare decât 0.”); returnează z; ) Exemplul 3.3.1. Program mutant P1.

Valoarea inițială modificată a variabilei i și limita ciclului în mutantul P2 sunt marcate cu un ton ușor:

// Metoda calculează puterea nenegativă // n a numărului x static public double PowerMutant2(double x, int n) ( double z=1; if (n>0) ( for (int i=0; n-1>=i;i++ ) ( z = z*x; ) ) else Console.WriteLine("Eroare! Puterea lui n trebuie să fie mai mare decât 0"); return z; ) Exemplul 3.4. Program mutant P2.

dublu PowerMutant2(dublu x, int n) ( dublu z=1; int i; if (n>0) (pentru (i=0;n-1>=i;i++) (z = z*x; ) ) altfel printf("Eroare! Puterea lui n trebuie să fie mai mare decât 0. "); return z; ) Exemplul 3.4.1. Program mutant P2.

1. Criteriile trebuie să fie suficiente, adică arată când un set finit de teste este suficient pentru a testa programul dat.
2. Criteriile trebuie să fie complete, adică în cazul unei erori, trebuie să existe un test din setul de teste care să îndeplinească criteriul care relevă eroarea.
3. Criteriul trebuie să fie de încredere, adică oricare două seturi de teste care o satisfac trebuie să dezvăluie sau să nu dezvăluie simultan erorile de program
4. Criteriul ar trebui să fie ușor de verificat, de exemplu, calculat pe teste

Pentru clase netriviale de programe în cazul general nu există un criteriu complet și de încredereîn funcţie de programe sau specificaţii.

Prin urmare, ne străduim pentru un criteriu general ideal prin intermediul celor reale private.

Clase de criterii

1. Criterii structurale utilizați informații despre structura programului (așa-numitele criterii „cutie albă”)
2. Criterii funcționale sunt formulate în descrierea cerințelor pentru produsul software ( așa-numitele criterii „cutie neagră”.)
3. Criterii testarea stocastică sunt formulate prin prisma verificării prezenței proprietăților specificate în aplicația testată, prin testarea unor ipoteze statistice.
4. Criterii de mutație concentrat pe verificarea proprietăților unui produs software bazat pe abordarea Monte Carlo.

Criterii structurale (clasa I).

Criterii structurale utilizare model de program sub forma unei „casete albe”, ceea ce presupune cunoașterea codului sursă al programului sau specificațiile programului sub forma unui grafic de flux de control. Informațiile structurale sunt ușor de înțeles și accesibile dezvoltatorilor de subsisteme și module de aplicație, astfel încât această clasă de criterii este adesea folosită în etapele de modulare și testarea integrării( Testare unitară , Testare de integrare ).

Criterii structurale se bazează pe elementele principale ale UGP, operatori, ramuri și căi.

• Condiție de criteriu testarea în echipă(criteriul C0) - un set de teste în agregat trebuie să asigure că fiecare comandă este trecută cel puțin o dată. Acesta este un criteriu slab, de obicei este folosit în sistemele software mari unde nu pot fi aplicate alte criterii.
• Condiție de criteriu testarea ramurilor(criteriul C1) - un set de teste în agregat trebuie să asigure că fiecare ramură este trecută cel puțin o dată. Acesta este un criteriu destul de puternic, dar economic, deoarece setul de ramuri din aplicația testată este finit și nu foarte mare. Acest criteriu este adesea folosit în sisteme automatizare de testare.
• Condiție de criteriu testarea traseului(criteriul C2) - un set de teste în agregat trebuie să asigure că fiecare cale este trecută de cel puțin 1 dată. Dacă programul conține o buclă (în special una cu un număr implicit de iterații), atunci numărul de iterații este limitat la o constantă (adesea 2, sau numărul de clase de căi de ieșire).

Tabelul 3.1. Condițiile declarațiilor if

	(30,0)	(17,17)	(-13,0)	(21,-4)
2 dacă (x>17)	>			>
4 dacă (x==-13)			=

Criteriul de cale C2 verifică programul mai amănunțit decât criteriul - C1, dar chiar dacă este satisfăcut, nu există niciun motiv pentru a afirma că

Cerințe pentru un criteriu de testare ideal
Criteriul trebuie să fie suficient.
Criteriul trebuie să fie complet.
Criteriul trebuie să fie de încredere.
Criteriul ar trebui să fie ușor de verificat
Pentru clasele non-triviale de programe, în general, nu există un criteriu complet și de încredere care să depindă de programe sau specificații.
Prin urmare, ne străduim pentru un criteriu general ideal prin intermediul celor reale private.

Clase de criterii
Structural
Funcţional
Criteriile de testare stocastică sunt formulate în ceea ce privește testarea prezenței proprietăților specificate în aplicația testată, prin testarea unor ipoteze statistice.
Criteriile de mutație sunt axate pe verificarea proprietăților unui produs software bazat pe abordarea Monte Carlo.

Criterii structurale
- utilizați un model de program sub forma unei „casete albe”, ceea ce presupune cunoașterea codului sursă al programului sau specificația programului sub forma unui grafic de flux de control. Această clasă de criterii este adesea folosită în etapele testării unitare și de integrare (testare unitară, testare de integrare)

Criteriile structurale se bazează pe elementele principale ale UGP, operatori, ramuri și căi.
Condiția criteriului de testare a comenzii (criteriul C0) - setul de teste în agregat trebuie să asigure că fiecare comandă este trecută cel puțin o dată. Acesta este un criteriu slab, de obicei este folosit în sistemele software mari unde nu pot fi aplicate alte criterii.
Condiția criteriului de testare a ramurilor (criteriul C1) - setul de teste în agregat trebuie să asigure că fiecare ramură este trecută cel puțin o dată. Acesta este un criteriu destul de puternic, dar economic, deoarece setul de ramuri din aplicația testată este finit și nu foarte mare. Acest criteriu este adesea folosit în sistemele de automatizare a testelor.
Condiția criteriului de testare a căii (criteriul C2) - setul de teste în agregat trebuie să asigure că fiecare cale este trecută de cel puțin 1 dată. Dacă programul conține o buclă (în special una cu un număr implicit de iterații), atunci numărul de iterații este limitat la o constantă (adesea 2, sau numărul de clase de căi de ieșire).

Criterii funcționale
- cel mai important criteriu de testare pentru industria software. Oferă, în primul rând, controlul gradului de îndeplinire a cerințelor clienților în produsul software. Reflectați interacțiunea aplicației testate cu mediul. Se folosește un model cutie neagră. Problemă: intensitatea muncii; fapt este că documentele care stabilesc cerințele pentru un produs software (Specificație cerințelor software, Specificație funcțională etc.) sunt destul de voluminoase.

Elemente de specificație de testare - setul de teste în agregat ar trebui să asigure că fiecare element de testare este testat cel puțin o dată.
Testarea claselor de date de intrare - un set de teste în agregat ar trebui să asigure că un reprezentant al fiecărei clase de date de intrare este verificat cel puțin o dată. La crearea testelor, clasele de date de intrare sunt mapate la modurile de utilizare ale componentei testate sau ale subsistemului aplicației, ceea ce reduce semnificativ opțiunile de iterație care sunt luate în considerare la dezvoltarea suitelor de testare. Trebuie remarcat faptul că suntem forțați să folosim suite de testare puternice. Într-adevăr, împreună cu restricțiile privind valorile datelor de intrare, există restricții asupra valorilor datelor de intrare în toate combinațiile posibile, inclusiv verificarea reacțiilor sistemului la apariția erorilor în valorile sau structurile de intrare. date. Contabilizarea acestei diversități este un proces laborios, care creează dificultăți în aplicarea criteriului
Reguli de testare - un set de teste în agregat trebuie să asigure verificarea fiecărei reguli, dacă valorile de intrare și de ieșire sunt descrise printr-un set de reguli de gramatică.
Testarea claselor de ieșiri - setul de teste în agregat ar trebui să ofere un test pentru un reprezentant al fiecărei clase de ieșiri, cu condiția ca ieșirile să fie preclasificate, iar clasele de ieșiri individuale să ia în considerare, printre altele, restricțiile privind resursele sau timpul ( pauză). La crearea testelor, clasele de ieșire sunt mapate la modurile de utilizare ale componentei sau subsistemului testat, ceea ce reduce semnificativ opțiunile de iterație care sunt luate în considerare la dezvoltarea cazurilor de testare.
Testare funcțională - un set de teste în agregat ar trebui să asigure că fiecare acțiune implementată de unitatea testată este verificată cel puțin o dată. Nu acoperă o parte din funcționalitatea componentei testate legate de proprietățile structurale și comportamentale, a cărei descriere nu este concentrată în funcții individuale (adică, descrierea este dispersată în întreaga componentă). Criteriul de testare a funcțiilor combină parțial caracteristicile criteriilor structurale și funcționale. Se bazează pe modelul „cutie translucidă”, în care nu sunt specificate în mod explicit doar intrările și ieșirile componentei testate, ci și compoziția și structura metodelor (funcții, proceduri) și clasele utilizate.
Criterii combinate pentru programe și specificații - setul de teste în agregat trebuie să asigure că toate combinațiile de condiții și specificații consistente ale programului sunt verificate cel puțin o dată.

Criterii stocastice
- se foloseste la testarea sistemelor software complexe - cand un set de teste deterministe are o putere enorma. În cazurile în care un astfel de set nu poate fi dezvoltat și executat în timpul fazei de testare

Este necesar să se dezvolte programe - simulatoare de secvențe aleatorii de semnale de intrare (x). Calculați în mod independent valorile (y) pentru semnalele de intrare corespunzătoare (x) și obțineți setul de test (X,Y). Testați aplicația pe setul de testare (X,Y), folosind două metode pentru a controla rezultatele:
Control determinist - verificarea dacă valoarea calculată a lui y corespunde valorii lui y obținută ca urmare a executării testului pe setul (x) - o secvență aleatorie de semnale de intrare generate de simulator.
Controlul stocastic - verificarea corespondenței setului de valori (y), obținut ca urmare a efectuării testelor pe un set de valori de intrare (x), cu o distribuție a rezultatelor F(Y) cunoscută anterior.

În acest caz, mulțimea Y ​​este necunoscută (calculul ei este imposibil), dar legea de distribuție a acestei mulțimi este cunoscută.

Criterii de testare stocastică
Metode statistice de testare a completării - metode stocastice de luare a deciziilor despre coincidența ipotezelor despre distribuția variabilelor aleatoare. Le aparțin cele larg cunoscute: metoda Studentului, metoda Chi-pătrat.
Metoda de estimare a ratei de detectare a erorilor - bazată pe modelul ratei de detectare a erorilor, conform căruia testarea este oprită dacă intervalul de timp estimat dintre eroarea curentă și următoarea este prea mare pentru faza de testare a aplicației.

Criteriul mutației (clasa IV).
- Se postulează că programatorii profesioniști scriu imediat programe aproape corecte care diferă de cele corecte prin erori minore sau erori de tip - schimbând valorile maxime ale indicilor în descrierea matricelor, erori în semnele operațiilor aritmetice, subestimare sau supraestimare limita buclei cu 1 etc. Se propune o abordare care permite, pe baza unor erori mici, estimarea numărului total de erori rămase în program.

Mutațiile sunt mici erori dintr-un program.
Mutanții sunt programe care diferă unele de altele prin mutații.

Metoda de testare a mutațiilor - mutațiile sunt introduse în programul dezvoltat P, adică. creați artificial programe mutante P1, P2... Apoi programul P și mutanții săi sunt testați pe același set de teste (X,Y).
Dacă corectitudinea programului P este confirmată pe setul (X,Y) și, în plus, toate erorile introduse în programele mutante sunt detectate, atunci setul de teste (X,Y) îndeplinește criteriul de mutație, iar programul testat este declarat corect.

Testarea sistemelor informatice

1.2. Criterii de testare.

Cerințele pentru un criteriu ideal de testare pot fi distinse:

· Criteriul trebuie să fie suficient, adică. arată când un set finit de teste este suficient pentru a testa programul dat.

· Criteriul trebuie să fie complet, adică. în cazul unei erori, trebuie să existe un test din setul de teste care să îndeplinească criteriul care relevă eroarea.

· Criteriul trebuie să fie de încredere, i.e. oricare două seturi de teste care o satisfac trebuie să dezvăluie sau să nu dezvăluie simultan erorile de program.

· Criteriul ar trebui să fie ușor de verificat, de exemplu, calculat pe teste.

Pentru clasele non-triviale de programe, în general, nu există un criteriu complet și de încredere care să depindă de programe sau specificații. Prin urmare, de regulă, se tinde spre un criteriu general ideal prin intermediul unor criterii private reale.

Clase de criterii:

· Criteriile structurale folosesc informații despre structura programului (așa-numitele criterii „cutie albă”).

· Criteriile funcționale sunt formulate în descrierea cerințelor pentru produsul software (criteriile așa-numitei „cutie neagră”).

· Criteriile de testare stocastică sunt formulate în ceea ce privește testarea prezenței proprietăților specificate în aplicația testată, prin testarea unor teorii statistice.

· Criteriile de mutație sunt axate pe verificarea proprietăților unui produs software bazat pe abordarea Monte Carlo.

Criterii structurale (clasa I).

Criteriile structurale folosesc un model de program cu casetă albă, care implică cunoașterea codului sursă al programului sau a specificației programului sub forma unui grafic de flux de control. Informațiile structurale sunt ușor de înțeles și accesibile dezvoltatorilor de subsisteme și module de aplicație, astfel încât această clasă de criterii este adesea folosită în etapele testării unitare și de integrare.

Criteriile structurale se bazează pe elementele principale ale UGP, operatori, ramuri și căi.

· Condiția criteriului de testare a comenzii (criteriul C0) - setul de teste în agregat trebuie să asigure că fiecare comandă este trecută cel puțin o dată. Acesta este un criteriu slab, utilizat în sistemele software mari unde nu pot fi aplicate alte criterii.

· Condiția criteriului de testare a ramurilor (criteriul C1) - setul de teste în agregat trebuie să asigure că fiecare ramificare este trecută cel puțin o dată. Acesta este un criteriu destul de puternic și în același timp economic. Acest criteriu este adesea folosit în sistemele de automatizare a testelor.

· Condiția criteriului de testare a căii (criteriul C2) - un set de teste în agregat trebuie să asigure că fiecare cale este trecută cel puțin o dată. Dacă programul conține o buclă (în special una cu un număr implicit de iterații), atunci numărul de iterații este limitat la o constantă (adesea 2, sau numărul de clase de căi de ieșire).

Criteriile structurale nu testează conformitatea cu specificația dacă

nu se reflectă în structura programului.

Criterii funcționale (clasa II).

Criteriul funcțional este cel mai important criteriu de testare pentru industria software. Oferă, în primul rând, controlul gradului de îndeplinire a cerințelor clienților în produsul software. Deoarece cerințele sunt formulate pentru produs în ansamblu, ele reflectă interacțiunea aplicației testate cu mediul. În testarea funcțională se folosește predominant modelul „cutie neagră”. Problema testării funcționale este, în primul rând, laboriozitatea; Faptul este că documentele care stabilesc cerințele pentru un produs software (specificația cerințelor software, specificația funcțională etc.) sunt de obicei destul de voluminoase, totuși, verificarea corespunzătoare ar trebui să fie cuprinzătoare.

Mai jos sunt anumite tipuri de criterii funcționale.

· Testarea articolelor de specificație - un set de teste în agregat ar trebui să asigure că fiecare element de testare este testat cel puțin o dată. O specificație de cerințe poate conține sute și mii de cerințe pentru un produs software, iar fiecare dintre aceste cerințe în timpul testării trebuie verificată în conformitate cu criteriul prin cel puțin un test.

· Testarea claselor de date de intrare - un set de teste în agregat ar trebui să asigure că un reprezentant al fiecărei clase de date de intrare este verificat cel puțin o dată. la crearea testelor, clasele de date de intrare sunt comparate cu modurile de utilizare ale componentei sau subsistemului aplicației testate, ceea ce reduce semnificativ opțiunile de forță brută luate în considerare la dezvoltarea suitelor de testare. Trebuie remarcat faptul că, prin sortarea valorilor variabilelor de intrare în conformitate cu criteriul (de exemplu, diverse fișiere - surse de date de intrare), suntem forțați să folosim suite de testare puternice. Într-adevăr, împreună cu restricțiile privind valorile datelor de intrare, există restricții asupra valorilor datelor de intrare în toate combinațiile posibile, inclusiv verificarea reacțiilor sistemului la apariția erorilor în valorile sau structurile de intrare. date. Contabilizarea acestei diversități este un proces laborios, care creează dificultăți în aplicarea criteriului.

· Reguli de testare - un set de teste în agregat trebuie să asigure verificarea fiecărei reguli, dacă valorile de intrare și de ieșire sunt descrise printr-un set de reguli de gramatică. Trebuie remarcat faptul că gramatica trebuie să fie suficient de simplă, astfel încât complexitatea dezvoltării setului corespunzător de teste să fie reală (se încadrează în intervalul de timp și personalul de specialiști alocat pentru implementarea fazei de testare).

· Testarea claselor de ieșiri - setul de teste în agregat ar trebui să ofere un test al unui reprezentant al fiecărei clase de ieșiri, cu condiția ca ieșirile să fie pre-clasificate, indicând clasele de rezultate individuale, inclusiv resursele sau limitele de timp (time out).
La crearea testelor, clasele de ieșire sunt mapate la modurile de utilizare ale componentei sau subsistemului testat, ceea ce reduce semnificativ opțiunile de iterație care sunt luate în considerare la dezvoltarea cazurilor de testare.

· Funcții de testare - un set de teste în agregat ar trebui să asigure că fiecare acțiune implementată de unitatea testată este verificată cel puțin o dată. Un criteriu foarte popular în practică, care, totuși, nu oferă acoperire a părții din funcționalitatea componentei testate asociată cu proprietăți structurale și comportamentale, a cărei descriere nu este concentrată în funcții individuale (adică descrierea este dispersată peste componenta).

Criteriul de testare a funcțiilor combină parțial caracteristicile criteriilor structurale și funcționale. Se bazează pe modelul „cutie translucidă”, în care nu sunt indicate în mod explicit doar intrările și ieșirile componentei testate, ci și compoziția și structura metodelor (funcții, proceduri) și clasele utilizate.

· Criterii combinate pentru programe și specificații - setul de teste în agregat trebuie să asigure că toate combinațiile de condiții consistente ale programelor și specificațiilor sunt verificate cel puțin o dată. În acest caz, toate combinațiile de condiții consistente trebuie confirmate, iar condițiile contradicțiilor trebuie descoperite și eliminate.

Criterii stocastice (clasa III).

Testarea stocastică este utilizată atunci când se testează sisteme software complexe - când un set de teste deterministe (X, Y) are o putere enormă. În cazurile în care un astfel de set nu poate fi dezvoltat și executat în timpul fazei de testare, se poate aplica următoarea metodologie.

· Dezvoltați programe care simulează semnale de intrare secvențiale aleatorii (x).

· Calculați în mod independent valorile (y) pentru semnalele de intrare corespunzătoare (y) și obțineți un set de testare (X,Y).

· Testați aplicația pe setul de testare (X,Y), folosind două moduri de a controla rezultatele:

1. Control determinist - verificarea conformității valorii calculate cu valoarea y obținută în urma derulării testului pe setul (x) - o succesiune aleatorie de semnale de intrare generate de simulator.

2. Controlul stocastic - verificarea conformității setului (), obținut în urma efectuării testelor pe un set de valori (x), cu o distribuție cunoscută anterior a rezultatelor F(Y). În acest caz, mulțimea y este necunoscută (calculul ei este imposibil), dar legea de distribuție a acestei mulțimi este cunoscută.

Criterii pentru testarea stocastică:

· Metode statistice de finalizare a testării - metode stocastice de luare a deciziilor despre coincidența ipotezelor despre distribuția variabilelor aleatoare. Printre acestea se numără cele cunoscute: metoda Studentului (St), metoda Chi-pătrat (x 2) etc.

· Metodă de estimare a ratei de detectare a erorilor - pe baza modelului ratei de detectare a erorilor, conform căruia testarea este oprită dacă intervalul de timp estimat între eroarea curentă și următoarea este prea mare pentru faza de testare a aplicația.

Criteriul mutației (clasa IV).

Se postulează că programatorii profesioniști scriu imediat programe aproape corecte care diferă de cele corecte prin erori mici sau erori de tip - schimbând valorile maxime ale indicilor în descrierea matricelor, erori în semnele operațiilor aritmetice, subestimarea sau supraestimarea limita buclei cu 1 etc. Se propune o abordare care permite, pe baza unor erori mici, estimarea numărului total de erori rămase în program.

Abordarea se bazează pe următoarele concepte:

Mutațiile sunt mici erori dintr-un program.

Mutanții sunt programe care diferă unele de altele prin mutații.

Metoda de testare a mutațiilor - mutațiile sunt introduse în programul dezvoltat P, adică. programele mutante P1, P2 sunt create artificial... Apoi programul P și mutanții săi sunt testați pe același set de teste (X,Y).

Dacă corectitudinea programului P este confirmată pe setul (X,Y) și, în plus, toate erorile introduse în programele mutante sunt evidențiate, atunci setul de teste (X,Y) îndeplinește criteriul mutației, iar programul testat este declarat corect.

Dacă unii mutanți nu au dezvăluit toate mutațiile, atunci este necesar să extindeți setul de testare (X, Y) și să continuați testarea.

Sistem WEB automat pentru testarea studenților

Procesul de testare a acestui produs software a fost împărțit în 2 etape: · Testarea paginii utilizator este prezentată în Tabelul Nr. 11. Tabelul numărul 11...

Sistem automat de testare a studenților pe mai multe platforme

Procesul de testare a acestui produs software a fost împărțit în 2 etape: · testarea produsului utilizator este prezentată în Tabelul Nr. 11. Tabelul numărul 11...

Studiul algoritmilor de gestionare a resurselor pentru servere cu un singur procesor în timpul procesării online a sarcinilor (algoritmi SPT și RR)

Următoarele criterii sunt utilizate pentru a compara algoritmii de planificare pe termen scurt: 1. Utilizarea (utilizarea) CPU Utilizarea CPU. Utilizarea procesorului poate fi teoretic în intervalul de la 0 la 100%...

Clasificarea sistemelor automate de control

Clasificarea sistemelor de control automate depinde în mod semnificativ de criteriile de clasificare ...

Conceptul de construire a unei distribuții

După cum știți, până în prezent, omenirea a venit cu doar două moduri de a gestiona software-ul - asamblarea acestora direct din pachetele sursă și instalarea lor din pachetele binare recompilate. În concordanță...

Motivul pentru alegerea celei mai prestigioase universități din Perm

Să definim criteriile după care voi evalua alternativele propuse. Am identificat 7 criterii principale: 1. Opinia publică. Acesta este cel mai important criteriu pe care se bazează imaginea universității. 2. Recunoaștere. Reputația universității este, de asemenea, importantă...

Proiect de rețea locală la etajul doi al școlii nr.19

Principalul criteriu de acceptare este conformitatea proiectului finit cu cerințele clientului, precum și calitatea lucrărilor efectuate...

Dezvoltarea site-ului „Magazin de jucării pentru copii”

5. Subsistem de afișare a sistemului de ajutor pentru utilizator; 6. Subsistem pentru afișarea informațiilor despre program. 2...

Dezvoltarea unui manual electronic multimedia

Găzduit la http://www.allbest...

Elaborarea unui manual electronic multimedia la disciplina „Rețele de calculatoare”

Unul dintre criteriile de selecție a găzduirii este sistemul de operare utilizat, deoarece software-ul care va suporta funcționalitatea anumitor servicii depinde de acesta...

Testarea bateriei LAN

Pentru a descrie starea rețelei, a fost aleasă metoda valorii de prag, a cărei esență este compararea fiecărei valori măsurate cu o valoare recomandată de tabel ...

Foarte des trebuie să ne confruntăm cu întrebarea „Ce să automatizăm în primul rând?” Automatizarea nu se face de dragul automatizării: doriți să vedeți rezultatul procesului, care ar oferi un ROI pozitiv (puteți citi mai multe despre calcularea ROI).

De ce este important să folosiți automatizarea?

Se crede în mod obișnuit că automatizarea testelor acționează ca un instrument pentru a sprijini testarea manuală, dar de fapt este important să înțelegem că automatizarea este cea mai bună modalitate nu numai de a economisi timp, ci și de a crește eficiența, amploarea și acuratețea testării, deoarece sarcinile repetitive într-o abordare manuală sunt supuse riscului de eroare umană. Automatizarea nu depășește și nu înlocuiește testarea manuală, ci o completează. La fel ca managementul testelor, automatizarea trebuie, de asemenea, să fie strategică cu o planificare, monitorizare și control adecvate. Automatorii nu numai că învață noi modalități de automatizare, dar iau și multe decizii bine gândite. Automatizarea, atunci când este implementată corect, poate fi un beneficiu pentru o echipă, un proiect și o organizație.
Există multe avantaje ale automatizării, vom menționa următoarele:

• accelerează sarcinile comune, cum ar fi testele de fum și regresie;
• ajută la pregătirea datelor de testare;
• optimizează execuția cazurilor de testare asociate cu logica de afaceri complexă;
• facilitează cazurile de testare multiplatformă (de exemplu, la testarea diferitelor sisteme de operare, browsere etc.);
• excelent pentru executarea cazurilor de testare care sunt dificil sau chiar imposibil de executat manual;
• ajută bine în cazurile în care numărul de iterații în timpul execuției nu este cunoscut dinainte.

În același timp, nu trebuie uitat că automatizarea întregului proces de testare a software-ului este dificilă și ineficientă din punct de vedere al costurilor, atât din cauza costului ridicat al instrumentelor de testare, cât și din cauza probabilității naturii instabile a anumitor secțiuni ale aplicației. Situația de pe proiect influențează puternic alegerea zonei pentru automatizare (fie că este vorba despre automatizarea testului pentru regresie sau automatizarea care va arăta blocaje în construcțiile frecvente). Descriind toate opțiunile posibile, riscăm să obținem o carte întreagă și, prin urmare, vom lua în considerare doar cea mai comună situație: este necesar să automatizăm un set de regresii.

Deci, care sunt criteriile pentru selectarea cazurilor de testare pentru automatizare?

Una dintre cele mai frecvente greșeli pe care le fac testerii este alegerea greșită a testelor pentru automatizare. Este necesar să analizăm și să identificăm cu atenție candidații pentru automatizare, ținând cont de cel mai important factor și anume ROI; cu alte cuvinte, trebuie să găsiți modalități de a obține un ROI mai mare și mai pozitiv. Pentru a face acest lucru, va trebui să luați o serie de acțiuni:

• determinați cât de des este rulat cazul de testare (rulați-l pentru fiecare construcție nouă, sau o dată, dar cu o cantitate mare de intrare?);
• aflați dacă cazul de testare este critic pentru afaceri sau acoperă un scenariu complet de la capăt la capăt;
• asigurați-vă că analiza rezultatelor autotestului nu va depăși timpul alocat testării manuale (în caz contrar își va pierde relevanța pentru automatizare);
• luați în considerare probabilitatea de a detecta erori (introduceți teste care de cele mai multe ori arată erori și puncte slabe);
• înțelegeți dacă un test ar putea deveni un blocant pentru o caracteristică sau o funcționalitate importantă care este esențială pentru afacere.

Ce tipuri de teste ar trebui excluse de la testarea de automatizare?

Enumerăm cazurile în care testele trebuie filtrate din automatizare:

• teste de utilizare care necesită intervenție manuală pentru a verifica erorile sau abaterile de la comportamentul așteptat;
• cazuri de testare care includ setarea sau nu necesitatea reexecuției unei funcții (cu toate acestea, ar trebui să automatizați testele care necesită intrări mari);
• evitați automatizarea testelor care pot duce la rezultate imprevizibile (de exemplu, noi funcționalități, teste de sincronizare, verificări ale datei de expirare);
• Teste UX care includ verificări de redimensionare pentru obiecte de pe diferite dimensiuni de ecran.

Ce urmeaza?

Pe baza factorilor de selecție de mai sus, vom obține scenarii care vor participa la selecția pentru automatizare.
Următorul pas este împărțirea aplicației testate în module. Pentru fiecare modul, analizăm și identificăm cazuri de testare care vor fi executate cu un set diferit de date, pe medii diferite (OS/Browser) și cu o logică de business complexă, utilizăm o cantitate mare de date (inclusiv cele speciale) și sunt utilizate de către utilizatori diferiți.

Luați în considerare procesul cu un exemplu. Avem un modul cu crearea de aplicații în sistem, pentru care selectăm cazuri de testare care participă la procesul de creare a unei aplicații. După ce toate testele sunt scrise, notăm dacă cel puțin una dintre condițiile definite mai sus este îndeplinită (Fig. 1).

Făcând clic pe imagine, se va deschide versiunea completă.
Y - condiția este îndeplinită
N - Condiția nu este îndeplinită
Astfel, obținem 3 cazuri de testare care pot fi automatizate și 2 cazuri de testare care nu necesită automatizare. Am finalizat cea mai importantă sarcină și o jumătate bună din muncă: mizeria noului subiect se transformă într-un plan detaliat a ceea ce trebuie făcut.

Ieșire

Cel mai adesea, preferăm să automatizăm un set de regresie deoarece conține mai multe cazuri de testare, iar funcționalitatea sa este deja stabilă (adică nu se schimbă de la o versiune la alta). În acest caz, putem împărți seturile de regresie în module și putem decide să rulăm pachetul corespunzător conform cerințelor de lansare.
În loc să automatizăm întregul set, alegem automatizarea în faze. Cu alte cuvinte, urmărim un model prototip pentru dezvoltarea unui pachet de automatizare.

Așadar, creați o structură sau un cadru cu mai puține cazuri de testare de implementat, apoi îmbunătățiți-l adăugând tot mai multe exemple.

Iubește testerul din tine, nu pe tine însuți în testare!