Klase kriterijuma
Strukturni kriterijumi (Klasa I).
Strukturni kriterijumi koristite programski model “bijele kutije”, koji pretpostavlja poznavanje izvornog koda programa ili specifikacije programa u obliku grafa kontrole toka. Strukturne informacije je razumljivo i dostupno programerima podsistema i aplikativnih modula, dakle ovu klasu kriterijumi se često koriste u fazama jediničnog i integracionog testiranja (Jedinstveno testiranje, Integraciono testiranje). Strukturni kriterijumi baziraju se na osnovnim elementima UGP-a, operatorima, granama i putanjama.1 javna void metoda (ref int x) ( 2 ako (x>17) 3 x = 17-x; 4 ako (x==-13) 5 x = 0; 6 ) Primjer 3.1. Primjer jednostavnog programa za testiranje prema strukturnim kriterijima
1 void Metoda (int *x) ( 2 ako (*x>17) 3 *x = 17-*x; 4 ako (*x==-13) 5 *x = 0; 6 ) Primjer 3.1.1. Primjer jednostavnog programa za testiranje prema strukturnim kriterijima
Komplet testova od jednog testa zadovoljava komandni kriterijum (C0): (X,Y)=((x ulaz =30, x izlaz =0)) pokriva sve operatore praćenja 1-2-3-4-5-6 Test set od dva testa, zadovoljava kriterij grananja (C1): (X,Y)=((30,0), (17,17)) dodaje 1 test na mnoge testove za C0 i rutu 1-2-4-6. Trag 1-2-3-4-5-6 prolazi kroz sve grane dostupne u if naredbama pod uslovom true , a trag 1-2-4-6 kroz sve grane dostupne u if naredbama pod uslovom false Test set od četiri testova , zadovoljava kriterij putanje (C2): (X,Y)=((30.0), (17.17), (-13.0), (21.-4)) Dat je skup uslova za dva if iskaza sa oznakama 2 i 4
| (30,0) | (17,17) | (-13,0) | (21,-4) | |
| 2 ako (x>17) | > | > | ||
| 4 ako (x==-13) | = | = |
Kriterij grane C2 temeljitije testira program od kriterija C1, ali čak i ako je zadovoljen, nema osnova za tvrdnju da je program implementiran u skladu sa specifikacijom.Na primjer, ako specifikacija specificira uslov da |x|100 , čija se nezadovoljivost može provjeriti testom (-177,-177) . Zaista, operatori 3 i 4 na testu (-177,-177) neće promijeniti vrijednost x=-177 i rezultat neće zadovoljiti specifikaciju. Strukturni kriterijumi ne provjeravajte usklađenost sa specifikacijom osim ako se to ne odražava u strukturi programa. Stoga, kada uspješno testiramo program prema kriteriju C2, možda nećemo primijetiti grešku povezanu s neispunjavanjem određenih uslova specifikacije zahtjeva.
Funkcionalni kriterijumi (klasa II)
Funkcionalni kriterijum- najvažniji kriterijum testiranja za softversku industriju. Omogućava, prije svega, kontrolu nad stepenom u kojem su zahtjevi kupaca zadovoljeni u softverskom proizvodu. Budući da su zahtjevi formulirani za proizvod u cjelini, oni odražavaju interakciju aplikacije koja se testira s okolinom. Funkcionalno testiranje uglavnom koristi model crne kutije. Problem funkcionalnog testiranja je, prije svega, radni intenzitet; Činjenica je da su dokumenti koji fiksiraju zahtjeve za softverski proizvod (specifikacija softverskih zahtjeva, funkcionalna specifikacija itd.) obično prilično obimni, međutim, odgovarajuća provjera mora biti sveobuhvatna. Ispod su određene vrste funkcionalni kriterijumi.Ispitivanje stavki specifikacije- ukupan skup testova mora osigurati da se svaka testirana stavka provjeri barem jednom.
Specifikacija zahteva može sadržati stotine i hiljade zahteva za softverski proizvod, a svaki od ovih zahteva tokom testiranja mora biti verifikovan u skladu sa kriterijumom najmanje jednim testom
Testiranje ulaznih klasa- skup testova zajedno mora osigurati da predstavnik svake klase ulaznih podataka bude testiran barem jednom.
Prilikom kreiranja testova, klase ulaznih podataka se upoređuju sa načinima korišćenja komponente ili podsistema aplikacije koji se testira, što značajno smanjuje brute force opcije koje se uzimaju u obzir pri razvoju test slučajeva. Treba napomenuti da prilikom sortiranja vrijednosti ulaznih varijabli u skladu s kriterijem (npr. razne fajlove- izvori ulaznih podataka), primorani smo koristiti moćne testne pakete. Zaista, uz ograničenja na vrijednosti ulaznih podataka, postoje ograničenja na vrijednosti ulaznih podataka u svim mogućim kombinacijama, uključujući provjeru reakcija sistema na pojavu grešaka u vrijednostima ili strukturama ulaznih podataka . Uzimanje u obzir ove raznolikosti je radno intenzivan proces, koji stvara poteškoće za primjenu kriterija
Testiranje pravila- skup testova ukupno treba da osigura provjeru svakog pravila, ako su ulazne i izlazne vrijednosti opisane skupom pravila, nekom gramatikom.
Treba napomenuti da bi gramatika trebala biti dovoljno jednostavna tako da je radni intenzitet razvoja odgovarajućeg skupa testova realan (uklapa se u vremenski okvir i osoblje stručnjaka raspoređeno za implementaciju faze testiranja)
Testiranje izlaznih klasa- ukupan skup testova treba da obezbedi verifikaciju predstavnika svake izlazne klase, pod uslovom da su izlazni rezultati unapred klasifikovani, i odvojene klase rezultati uzimaju u obzir, između ostalog, ograničenja resursa ili vremena ( vrijeme je isteklo).
Prilikom kreiranja testova, klase izlaznih podataka se upoređuju sa načinima korišćenja komponente ili podsistema koji se testira, što značajno smanjuje opcije grube sile koje se uzimaju u obzir pri razvoju test slučajeva.
Funkcionalno testiranje- skup testova zajedno mora osigurati da se svaka radnja implementirana od strane modula koji se testira bude provjerena barem jednom.
Vrlo popularan kriterij u praksi, koji, međutim, ne obezbjeđuje pokriće dijela funkcionalnosti komponente koja se testira u vezi sa strukturnim i bihevioralnim svojstvima, čiji opis nije koncentriran na pojedinačne funkcije (tj. opis je raspršen po cijeloj komponenta).
Kriterij funkcionalnog testiranja djelimično kombinuje karakteristike strukturnih i funkcionalni kriterijumi. Zasnovan je na modelu "prozirne kutije", gdje su eksplicitno naznačeni ne samo ulazi i izlazi komponente koja se testira, već i sastav i struktura korištenih metoda (funkcija, procedura) i klasa.
Kombinovani kriterijumi za programe i specifikacije- skup testova zajedno mora osigurati da se sve kombinacije konzistentnih programskih uslova i specifikacija provjere barem jednom.
U ovom slučaju, sve kombinacije konzistentnih uslova moraju biti potvrđene, a uslovi kontradiktornosti moraju biti otkriveni i eliminisani.
Primjer korištenja kriterija funkcionalnog testiranja za razvoj skupa testova na osnovu kriterija klasa ulaznih podataka
Pretpostavimo da je za rešavanje problema testiranja sistema „Upravljački sistem za automatizovani kompleks za skladištenje ležajeva“ (videti Dodatak 1, FS) razvijen sledeći fragment specifikacije zahteva:Test slučaj 1 (obuhvata klasu 4):
Status skladišta - 32.
Sistem traži status skladišta (pozovi funkciju GetStoreStat) i prima 32
Test slučaj 2 (obuhvata klasu 5):
Stanje okruženja (ulaz - X):
Status skladišta je 12dfga.
Očekivani slijed događaja (izlaz - Y):
Sistem traži status skladišta (pozovi funkciju GetStoreStat) i, prema klauzuli specifikacije, ako je vrijednost statusa skladišta netačna, u dnevnik se dodaje poruka “SKLADIŠTE: GREŠKA: Nedefiniran status”.
Stohastički kriterijumi (klasa III)
Stohastičko testiranje koristi se prilikom testiranja kompleksa softverski sistemi- kada skup determinističkih testova (X,Y) ima ogromnu snagu. U slučajevima kada se takav skup ne može razviti i izvršiti tokom faze testiranja, može se primijeniti sljedeća metodologija. 
Rice. 3.1.
Prilikom formalizacije modela stope detekcije grešaka (), korištene su sljedeće notacije: N - početni broj grešaka u softverskom paketu prije testiranja, C - konstanta za smanjenje stope detekcije greške zbog pronalaženja sljedeće greške, t 1, t 2,...t n - skup rastućih intervala detekcije sekvence od n grešaka, T je vrijeme za identifikaciju n grešaka. Ako pretpostavimo da je n grešaka identificirano tokom vremena T, tada je relacija (1) važeća, koja navodi da je proizvod brzine identifikacije greške i i vremena za identifikaciju greške i 1 po definiciji:
(1) (N-i+1)*C*t i = 1
Pod ovom pretpostavkom, relacija (2) vrijedi za n grešaka:
(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
Ako odredimo t i iz (1) i zbrojimo od 1 do n, dolazimo do relacije (3) za vrijeme T za otkrivanje n grešaka
(3) Σ1/(N-i+1) = TC
Ako izrazimo C iz (2), dolazimo do relacije (4):
(4) C = n/(NT - Σ(i-1)t i)
Konačno, zamjenom C u (3), dobijamo konačnu relaciju (5), pogodnu za procjene:
(5) Σ1/(N-i+1) = n/(N - 1/T*Σ(i-1)t i)
Ako vrijednost N procijenimo približno koristeći poznate metode za procjenu broja grešaka u programu, ili podatke o gustine grešaka za projekte dotične klase iz historijske baze podataka projekata, te, osim toga, koristiti trenutne podatke o intervali između grešaka t 1 ,t 2 …t n dobijeno tokom faze testiranja, tada zamjenom ovih podataka u (5) možete dobiti procjenu vremenskog intervala t n+1 potrebnog da se pronađe i ispravi sljedeća greška (buduća greška). t n+1 >Td je dozvoljeno vrijeme za testiranje projekta, zatim završavamo testiranje, u suprotnom nastavljamo sa traženjem grešaka Posmatrajući slijed intervala grešaka t 1 ,t 2 ...t n , i vrijeme utrošeno na identifikaciju n grešaka T=Σt i , možemo predvideti vremenski interval do sledećih grešaka i precizirati vrednost C u skladu sa (4) Moranda kriterijum je veoma praktičan, jer se oslanja na informacije koje se tradicionalno prikupljaju tokom procesa testiranja.
Kriterijum mutacije (klasa IV).
Pretpostavlja se da profesionalni programeri pišu gotovo odmah ispravne programe, koji se razlikuju od ispravnih zbog manjih grešaka ili grešaka u kucanju kao što je - storniranje maksimalne vrijednosti indeksi u opisima nizova, greške u znakovima aritmetičke operacije, potcjenjivanje ili precjenjivanje granice ciklusa za 1, itd. Predložen je pristup koji omogućava, na osnovu malih grešaka, procjenu ukupan broj preostale greške u programu Pristup se zasniva na sljedećim konceptima: Mutacije - manje greške u programu. Mutanti su programi koji se međusobno razlikuju po mutacijama. Metoda testiranja mutacija- u razvijeni program P unose se mutacije, tj. umjetno kreirati mutantne programe P1, P2... Tada se program P i njegovi mutanti testiraju na istom skupu testova (X,Y).Ako se na skupu (X,Y) potvrđuje ispravnost programa P i dodatno , onda sve greške unesene u mutantne programe test paket (X,Y) se podudara kriterijum mutacije, a program koji se testira je deklariran ispravan.Ako neki mutanti nisu identifikovali sve mutacije, potrebno je proširiti skup testova (X,Y) i nastaviti testiranje.Primjer primjene kriterija mutacije
Testirani program P prikazan je u . Za njega su kreirana dva mutantna programa P1 i P2.Promijenjeno u P1 početna vrijednost varijabla z od 1 do 2 (). U P2, početna vrijednost varijable i se mijenja sa 1 na 0, a granična vrijednost indeksa petlje se mijenja sa n na n-1 (). Prilikom pokretanja testova (X,Y) = ((x=2,n=3,y=8),(x=999,n=1,y=999), (x=0,n=100,y=0) Otkrivaju se sve greške u mutantnim programima i greška u glavnom programu, gdje je u stanju petlje n-1 umjesto n:// Metoda izračunava nenegativnu // snagu n broja x static public double PowerNonNeg(double x, int n) ( double z=1; if (n>0) ( for (int i=1; n-1> Primjer 3.2. Glavni program P
double PowerNonNeg(double x, int n) (dvostruki z=1; int i; ako (n>0) (za (i=1;n-1> Primjer 3.2.1. Glavni program P
Promijenjena početna vrijednost varijable z u P1 mutantu označena je svijetlim tonom:
// Metoda izračunava nenegativnu // snagu n broja 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("Greška! Snaga n mora biti veća od 0."); vrati z; ) Primjer 3.3. Mutantni program P1.
dupli PowerMutant1(double x, int n) ( duplo z=2; int i; if (n>0) (za (i=1;n>=i;i++) ( z = z*x; ) ) else printf( "Greška! Snaga n mora biti veća od 0."); vrati z; ) Primjer 3.3.1. Mutantni program P1.
Promijenjena početna vrijednost varijable i i granica petlje u P2 mutantu označena je svijetlim tonom:
// Metoda izračunava nenegativnu // snagu n broja 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("Greška! Snaga n mora biti veća od 0"); vrati z; ) Primjer 3.4. Mutantski program P2.
dupli PowerMutant2(double x, int n) (dvostruki z=1; int i; if (n>0) (za (i=0;n-1>=i;i++) ( z = z*x; ) ) drugo printf("Greška! Snaga n mora biti veća od 0."); return z; ) Primjer 3.4.1. Mutantski program P2.
- Kriterijum mora biti dovoljan, tj. pokazuju kada je neki konačan skup testova dovoljan za testiranje datog programa.
- Kriterijum mora biti potpun, tj. u slučaju greške, mora postojati test skupa testova koji zadovoljava kriterijum koji otkriva grešku.
- Kriterijum mora biti pouzdan, tj. bilo koja dva seta testova koji ga zadovoljavaju moraju istovremeno otkriti ili ne otkriti programske greške
- Kriterijum mora biti lako provjerljiv, na primjer, izračunato na testovima
Za netrivijalne klase programa u opštem slučaju ne postoji potpun i pouzdan kriterijum ovisno o programima ili specifikacijama.
Stoga težimo idealnom opštem kriterijumu kroz stvarne partikularne.
Klase kriterijuma
- Strukturni kriterijumi koristiti informacije o strukturi programa (tzv. kriterij "bijele kutije")
- Funkcionalni kriterijumi formulisani su u opisu zahteva za softverski proizvod ( takozvani kriterijumi "crne kutije".)
- Kriterijumi stohastičko testiranje su formulisani u smislu provjere prisustva specificiranih svojstava u aplikaciji koja se testira, putem testiranja određene statističke hipoteze.
- Kriteriji mutacije fokusirani su na provjeru svojstava softverskog proizvoda zasnovanog na Monte Carlo pristupu.
Strukturni kriterijumi (Klasa I).
Strukturni kriterijumi koristiti programski model u obliku "bijele kutije", koja pretpostavlja poznavanje izvornog koda programa ili specifikacije programa u obliku grafa kontrole protoka. Strukturne informacije su razumljive i dostupne programerima aplikativnih podsistema i modula, stoga se ova klasa kriterijuma često koristi u fazama modularnog i integracijsko testiranje(Testiranje jedinica, Integracijsko testiranje).
Strukturni kriterijumi baziraju se na osnovnim elementima UGP-a, operatorima, granama i putanjama.
- Uslov kriterijuma komande za testiranje(kriterijum C0) - ukupan skup testova mora osigurati da svaka komanda prođe barem jednom. Ovo je slab kriterijum i obično se koristi u velikim softverskim sistemima gde se drugi kriterijumi ne mogu primeniti.
- Uslov kriterijuma testne grane(kriterijum C1) - skup testova zajedno mora osigurati da se svaka grana položi barem jednom. Ovo je prilično jak i istovremeno ekonomičan kriterij, budući da je broj grana u aplikaciji koja se testira konačan i nije tako velik. Ovaj kriterijum se često koristi u sistemima automatizacija testiranja.
- Uslov kriterijuma testiranje puta(kriterijum C2) - skup testova ukupno mora osigurati da se svaki put prođe najmanje 1 put. Ako program sadrži petlju (posebno onu sa implicitnim brojem iteracija), tada je broj iteracija ograničen na konstantu (često 2, ili broj izlaznih klasa staza).
| (30,0) | (17,17) | (-13,0) | (21,-4) | |
| 2 ako (x>17) | > | > | ||
| 4 ako (x==-13) | = |
Kriterij putanje C2 temeljitije provjerava program od kriterija C1, ali čak i ako je zadovoljen, nema razloga tvrditi da
Zahtjevi za idealan testni kriterij
Kriterijum mora biti dovoljan.
Kriterijum mora biti potpun.
Kriterijum mora biti pouzdan.
Kriterijum mora biti lako provjerljiv
Za netrivijalne klase programa, generalno, ne postoji potpun i pouzdan kriterijum u zavisnosti od programa ili specifikacija.
Stoga težimo idealnom opštem kriterijumu kroz stvarne partikularne.
Klase kriterijuma
Strukturno
Funkcionalni
Kriterijumi za stohastičko testiranje su formulisani u smislu provjere prisustva specificiranih svojstava u aplikaciji koja se testira, putem testiranja određene statističke hipoteze.
Kriterijumi mutacije su fokusirani na provjeru svojstava softverskog proizvoda zasnovanog na Monte Carlo pristupu.
Strukturni kriterijumi
- koristiti programski model u obliku “bijele kutije”, koji pretpostavlja poznavanje izvornog teksta programa ili specifikacije programa u obliku grafa kontrole toka. Ova klasa kriterijuma se često koristi u fazama testiranja jedinica i integracije (Testiranje jedinica, Integraciono testiranje)
Strukturni kriterijumi su zasnovani na glavnim elementima UGP-a, operaterima, granama i putanjama.
Uvjet kriterija testiranja naredbe (kriterijum C0) - skup testova ukupan mora osigurati da se svaka naredba prođe barem jednom. Ovo je slab kriterijum i obično se koristi u velikim softverskim sistemima gde se drugi kriterijumi ne mogu primeniti.
Uslov kriterija testiranja grane (kriterijum C1) je da skup testova zajedno mora osigurati da se svaka grana prođe barem jednom. Ovo je prilično jak i istovremeno ekonomičan kriterij, budući da je broj grana u aplikaciji koja se testira konačan i nije tako velik. Ovaj kriterijum se često koristi u sistemima za automatizaciju testiranja.
Uvjet kriterija za testiranje staza (kriterijum C2) - skup testova ukupan mora osigurati da se svaki put prođe najmanje 1 put. Ako program sadrži petlju (posebno onu sa implicitnim brojem iteracija), tada je broj iteracija ograničen na konstantu (često 2, ili broj izlaznih klasa staza).
Funkcionalni kriterijumi
- najvažniji kriterijum testiranja za softversku industriju. Omogućava, prije svega, kontrolu nad stepenom u kojem su zahtjevi kupaca zadovoljeni u softverskom proizvodu. Odrazite interakciju aplikacije koja se testira sa okruženjem. Koristi se model "crne kutije". Problem: radno intenzivan; Činjenica je da su dokumenti koji fiksiraju zahtjeve za softverski proizvod (Specifikacija softverskih zahtjeva, Funkcionalna specifikacija itd.) prilično obimni.
Testiranje specifikacijskih stavki – skup testova zajedno mora osigurati da se svaki testirani predmet provjerava barem jednom.
Testiranje klasa ulaznih podataka - skup testova zajedno mora osigurati da se predstavnik svake klase ulaznih podataka testira barem jednom. Prilikom kreiranja testova, klase ulaznih podataka se upoređuju sa načinima korišćenja komponente ili podsistema aplikacije koji se testira, što značajno smanjuje brute force opcije koje se uzimaju u obzir pri razvoju test slučajeva. Treba napomenuti da smo primorani koristiti moćne testne pakete. Zaista, uz ograničenja na vrijednosti ulaznih podataka, postoje ograničenja na vrijednosti ulaznih podataka u svim mogućim kombinacijama, uključujući provjeru reakcija sistema na pojavu grešaka u vrijednostima ili strukturama ulaznih podataka . Uzimanje u obzir ove raznolikosti je radno intenzivan proces, koji stvara poteškoće za primjenu kriterija
Pravila testiranja - skup testova zajedno treba da osigura da je svako pravilo provjereno ako su ulazne i izlazne vrijednosti opisane skupom pravila neke gramatike.
Testiranje izlaznih klasa – skup testova zajedno treba da obezbedi verifikaciju predstavnika svake izlazne klase, pod uslovom da su izlazni rezultati unapred klasifikovani, a pojedinačne klase rezultata uzimaju u obzir, između ostalog, ograničenja resursa ili vremenskog ograničenja. Prilikom kreiranja testova, klase izlaznih podataka se upoređuju sa načinima korišćenja komponente ili podsistema koji se testira, što značajno smanjuje opcije grube sile koje se uzimaju u obzir pri razvoju test slučajeva.
Testiranje funkcije – skup testova zajedno mora osigurati da se svaka radnja implementirana od strane modula koji se testira bude provjerena barem jednom. Ne pruža pokriće dijela funkcionalnosti komponente koja se testira u vezi sa strukturnim i bihevioralnim svojstvima, čiji opis nije koncentrisan na pojedinačne funkcije (tj. opis je raspršen po cijeloj komponenti). Kriterij funkcionalnog testiranja djelimično kombinuje karakteristike strukturnih i funkcionalnih kriterijuma. Zasnovan je na modelu "prozirne kutije", gdje su eksplicitno naznačeni ne samo ulazi i izlazi komponente koja se testira, već i sastav i struktura korištenih metoda (funkcija, procedura) i klasa.
Kombinovani kriterijumi za programe i specifikacije – skup testova zajedno mora osigurati da se sve kombinacije konzistentnih programskih uslova i specifikacija testiraju barem jednom.
Stohastički kriterijumi
- koristi se pri testiranju složenih softverskih sistema - kada skup determinističkih testova ima ogromnu snagu. U slučajevima kada se takav set ne može razviti i izvršiti tokom faze testiranja
Potrebno je razviti programe koji simuliraju nasumične sekvence ulaznih signala (x). Nezavisno izračunajte vrijednosti (y) za odgovarajuće ulazne signale (x) i dobijte test skup (X,Y). Testirajte aplikaciju na test setu (X,Y), koristeći dva načina za kontrolu rezultata:
Deterministička kontrola - provjera korespondencije izračunate vrijednosti y sa vrijednošću y dobijenom kao rezultat izvođenja testa na skupu (x) - slučajni niz ulaznih signala generiranih od strane simulatora.
Stohastička kontrola - provjera usklađenosti skupa vrijednosti (y), dobijenih kao rezultat izvođenja testova na skupu ulaznih vrijednosti (x), sa prethodno poznatom distribucijom rezultata F(Y).
U ovom slučaju, skup Y je nepoznat (njegovo izračunavanje je nemoguće), ali je poznat zakon raspodjele ovog skupa.
Stohastički kriterijumi testiranja
Statističke metode za završetak testiranja - stohastičke metode za donošenje odluka o podudarnosti hipoteza o raspodjeli slučajnih varijabli. Tu spadaju dobro poznati: Studentova metoda, Hi-kvadrat metoda.
Metoda procjene stope detekcije greške - zasnovana na modelu stope detekcije greške, prema kojem se testiranje zaustavlja ako je procijenjeni vremenski interval između trenutne greške i sljedeće greške predugačak za fazu testiranja aplikacije.
Kriterijum mutacije (klasa IV).
- Pretpostavlja se da profesionalni programeri odmah napišu gotovo ispravne programe koji se razlikuju od ispravnih po manjim greškama ili greškama u kucanju - preokretanje maksimalnih vrijednosti indeksa u opisu nizova, greške u predznacima aritmetičkih operacija, podcjenjivanje ili precjenjivanje granica petlje za 1, itd. Predlaže se pristup koji omogućava, na osnovu malih grešaka, procjenu ukupnog broja grešaka preostalih u programu.
Mutacije su manje greške u programu.
Mutanti su programi koji se međusobno razlikuju po mutacijama.
Metoda testiranja mutacija - mutacije se uvode u razvijeni program P, tj. umjetno kreirati mutantne programe P1, P2... Zatim se program P i njegovi mutanti testiraju na istom skupu testova (X,Y).
Ako se na skupu (X,Y) potvrdi ispravnost programa P i pored toga se identifikuju sve greške unesene u mutantne programe, tada testni skup (X,Y) odgovara kriteriju mutacije, a testirani program je proglašen ispravnim.
Testiranje informacionih sistema
1.2. Kriterijumi testiranja.
Zahtjevi za idealan kriterij testiranja mogu se identificirati:
· Kriterijum mora biti dovoljan, tj. pokazuju kada je neki konačan skup testova dovoljan za testiranje datog programa.
· Kriterijum mora biti potpun, tj. u slučaju greške, mora postojati test skupa testova koji zadovoljava kriterijum koji otkriva grešku.
· Kriterijum mora biti pouzdan, tj. bilo koja dva seta testova koji ga zadovoljavaju moraju istovremeno otkriti ili ne otkriti programske greške.
· Kriterijum mora biti lako provjerljiv, na primjer, izračunat u testovima.
Za netrivijalne klase programa, generalno, ne postoji potpun i pouzdan kriterijum u zavisnosti od programa ili specifikacija. Stoga se po pravilu teži idealnom opštem kriterijumu preko stvarnih partikularnih.
Klase kriterijuma:
· Strukturni kriterijumi koriste informacije o strukturi programa (tzv. kriterijumi „bele kutije“).
· Funkcionalni kriterijumi su formulisani u opisu zahteva za softverski proizvod (tzv. kriterijumi „crne kutije“).
· Kriterijumi stohastičkog testiranja su formulisani u smislu provjere prisustva specificiranih svojstava u aplikaciji koja se testira, putem testiranja neke statističke teorije.
· Kriterijumi mutacije su fokusirani na provjeru svojstava softverskog proizvoda zasnovanog na Monte Carlo pristupu.
Strukturni kriterijumi (Klasa I).
Strukturni kriterijumi koriste model bele kutije programa, koji pretpostavlja poznavanje izvornog koda programa ili specifikacije programa u obliku grafa kontrole toka. Strukturne informacije su razumljive i dostupne programerima aplikativnih podsistema i modula, stoga se ova klasa kriterijuma često koristi u fazama testiranja jedinica i integracije.
Strukturni kriterijumi su zasnovani na glavnim elementima UGP-a, operaterima, granama i putanjama.
· Uslov kriterijuma testiranja komande (kriterijum C0) - skup testova ukupan mora da obezbedi da se svaka komanda prođe najmanje jednom. Ovo je slab kriterijum, koji se koristi u velikim softverskim sistemima gde se drugi kriterijumi ne mogu primeniti.
· Uslov kriterijuma za testiranje grana (kriterijum C1) - skup testova ukupan mora osigurati da se svaka grana položi barem jednom. Ovo je prilično jak i istovremeno ekonomičan kriterij. Ovaj kriterijum se često koristi u sistemima za automatizaciju testiranja.
· Uslov kriterijuma za testiranje staza (kriterijum C2) - skup testova u celini mora da obezbedi da se svaki put prođe barem jednom. Ako program sadrži petlju (posebno onu sa implicitnim brojem iteracija), tada je broj iteracija ograničen na konstantu (često 2, ili broj izlaznih klasa staza).
Strukturni kriteriji ne provjeravaju usklađenost sa specifikacijom ako
to se ne odražava u strukturi programa.
Funkcionalni kriterijumi (klasa II).
Funkcionalni kriterijum je najvažniji kriterijum testiranja za softversku industriju. Omogućava, prije svega, kontrolu nad stepenom u kojem su zahtjevi kupaca zadovoljeni u softverskom proizvodu. Budući da su zahtjevi formulirani za proizvod u cjelini, oni odražavaju interakciju aplikacije koja se testira s okolinom. Funkcionalno testiranje uglavnom koristi model crne kutije. Problem funkcionalnog testiranja je, prije svega, radni intenzitet; Činjenica je da su dokumenti koji fiksiraju zahtjeve za softverski proizvod (specifikacija softverskih zahtjeva, funkcionalna specifikacija itd.) obično prilično obimni, međutim, odgovarajuća provjera mora biti sveobuhvatna.
Ispod su specifične vrste funkcionalnih kriterijuma.
· Testiranje stavki specifikacije – skup testova u celini treba da obezbedi da se svaka testirana stavka verifikuje najmanje jednom. Specifikacija zahteva može sadržati stotine i hiljade zahteva za softverski proizvod, a svaki od ovih zahteva tokom testiranja mora biti verifikovan u skladu sa kriterijumom najmanje jednim testom.
· Testiranje klasa ulaznih podataka – skup testova zajedno mora osigurati da se predstavnik svake klase ulaznih podataka testira barem jednom. Prilikom kreiranja testova, klase ulaznih podataka se upoređuju sa načinima korišćenja komponente ili podsistema aplikacije koji se testira, što značajno smanjuje brute-force opcije koje se uzimaju u obzir pri razvoju test slučajeva. Treba napomenuti da smo, sortiranjem vrijednosti ulaznih varijabli u skladu s kriterijem (na primjer, razne datoteke - izvori ulaznih podataka), primorani koristiti moćne testne skupove. Zaista, uz ograničenja na vrijednosti ulaznih podataka, postoje ograničenja na vrijednosti ulaznih podataka u svim mogućim kombinacijama, uključujući provjeru reakcija sistema na pojavu grešaka u vrijednostima ili strukturama ulaznih podataka . Uzimanje ove raznolikosti u obzir je radno intenzivan proces, koji stvara poteškoće za primjenu kriterija.
· Testiranje pravila - skup testova zajedno treba da obezbedi verifikaciju svakog pravila ako su ulazne i izlazne vrednosti opisane skupom pravila neke gramatike. Treba napomenuti da gramatika treba da bude dovoljno jednostavna tako da je radni intenzitet razvoja odgovarajućeg skupa testova realan (uklapa se u vremenski okvir i osoblje stručnjaka dodeljeno za implementaciju faze testiranja).
· Testiranje izlaznih klasa – skup testova zajedno treba da obezbedi verifikaciju predstavnika svake izlazne klase, pod uslovom da su izlazni rezultati unapred klasifikovani, sa pojedinačnim klasama rezultata koji ukazuju, uključujući ograničenja resursa ili vremenskog ograničenja.
Prilikom kreiranja testova, klase izlaznih podataka se upoređuju sa načinima korišćenja komponente ili podsistema koji se testira, što značajno smanjuje opcije grube sile koje se uzimaju u obzir pri razvoju test slučajeva.
· Testiranje funkcije – skup testova zajedno mora osigurati da se svaka radnja implementirana od strane modula koji se testira bude provjerena barem jednom. Vrlo popularan kriterij u praksi, koji, međutim, ne obezbjeđuje pokriće dijela funkcionalnosti komponente koja se testira u vezi sa strukturnim i bihevioralnim svojstvima, čiji opis nije koncentriran na pojedinačne funkcije (tj. opis je raspršen po cijeloj komponenta).
Kriterij funkcionalnog testiranja djelimično kombinuje karakteristike strukturnih i funkcionalnih kriterijuma. Zasnovan je na modelu "prozirne kutije", gdje su eksplicitno naznačeni ne samo ulazi i izlazi komponente koja se testira, već i sastav i struktura korištenih metoda (funkcija, procedura) i klasa.
· Kombinovani kriterijumi za programe i specifikacije – skup testova zajedno mora osigurati da se sve kombinacije konzistentnih programskih uslova i specifikacija provjere barem jednom. U ovom slučaju, sve kombinacije konzistentnih uslova moraju biti potvrđene, a uslovi kontradiktornosti moraju biti otkriveni i eliminisani.
Stohastički kriterijumi (klasa III).
Stohastičko testiranje se koristi kada se testiraju složeni softverski sistemi - kada skup determinističkih testova (X, Y) ima ogromnu snagu. U slučajevima kada se takav skup ne može razviti i izvršiti tokom faze testiranja, može se primijeniti sljedeća metodologija.
· Razviti programe koji simuliraju nasumične sekvencijalne ulazne signale (x).
· Nezavisno izračunajte vrijednosti (y) za odgovarajuće ulazne signale (y) i dobijte test set (X,Y).
· Testirajte aplikaciju na test setu (X,Y), koristeći dva načina za kontrolu rezultata:
1. Deterministička kontrola - provjera usklađenosti izračunate vrijednosti sa vrijednošću y dobijenom kao rezultat izvođenja testa na skupu (x) - slučajni niz ulaznih signala generiranih od strane simulatora.
2. Stohastička kontrola - provjera usklađenosti skupa (), dobivenog kao rezultat izvođenja testova na skupu vrijednosti (x), sa prethodno poznatom distribucijom rezultata F(Y). U ovom slučaju, skup y je nepoznat (njegovo izračunavanje je nemoguće), ali je poznat zakon raspodjele ovog skupa.
Stohastički kriterijumi testiranja:
· Statističke metode za završetak testiranja - stohastičke metode za donošenje odluka o podudarnosti hipoteza o raspodjeli slučajnih varijabli. Tu spadaju dobro poznate: Studentova metoda (St), Hi-kvadrat metoda (x 2) itd.
· Metoda procjene stope detekcije greške - zasnovana na modelu stope detekcije greške, prema kojem se testiranje zaustavlja ako je procijenjeni vremenski interval između trenutne greške i sljedeće greške predugačak za fazu testiranja aplikacije.
Kriterijum mutacije (klasa IV).
Pretpostavlja se da profesionalni programeri odmah pišu gotovo ispravne programe koji se razlikuju od ispravnih po manjim greškama ili tipografskim greškama - preokretanjem maksimalnih vrijednosti indeksa u opisima nizova, greškama u predznacima aritmetičkih operacija, podcjenjivanjem ili precjenjivanjem petlje granica za 1 itd. Predlaže se pristup koji omogućava, na osnovu malih grešaka, procjenu ukupnog broja grešaka preostalih u programu.
Pristup se zasniva na sljedećim konceptima:
Mutacije su manje greške u programu.
Mutanti su programi koji se međusobno razlikuju po mutacijama.
Metoda testiranja mutacija - mutacije se uvode u razvijeni program P, tj. umjetno kreirati mutantne programe P1, P2... Zatim se program P i njegovi mutanti testiraju na istom skupu testova (X,Y).
Ako se na skupu (X,Y) potvrdi ispravnost programa P i pored toga se identifikuju sve greške unesene u mutantne programe, tada testni skup (X,Y) odgovara kriteriju mutacije, a program pod testom se proglašava ispravnim.
Ako neki mutanti nisu identificirali sve mutacije, tada se testni skup (X,Y) mora proširiti i testiranje nastaviti.
Automatizovani WEB sistem za testiranje studenata
Proces testiranja za ovo softverski proizvod je podijeljen u 2 faze: · testiranje korisničke stranice prikazano je u tabeli br. 11. Tabela br. 11...
Automatski sistem za testiranje studenata na više platformi
Proces testiranja ovog softverskog proizvoda podijeljen je u 2 faze: · testiranje korisničkog proizvoda prikazano je u tabeli br. 11. Tabela br. 11...
Proučavanje algoritama upravljanja resursima za jednoprocesorske servere tokom online obrade zadataka (SPT i RR algoritmi)
Sljedeći kriteriji se koriste za poređenje kratkoročnih algoritama planera: 1. Iskorišćenost (upotreba) CPU-a. Iskorišćenost CPU-a teoretski može biti u rasponu od 0 do 100%...
Klasifikacija automatizovani sistemi menadžment
Klasifikacija automatizovanih sistema upravljanja značajno zavisi od kriterijuma klasifikacije...
Koncept izgradnje distributivnog kompleta
Kao što znate, do današnjeg dana čovječanstvo je osmislilo samo dva načina upravljanja softverom - sastavljajući ih direktno iz paketa izvorni tekstovi i instalaciju iz ponovno kompajliranih binarnih paketa. U skladu...
Opravdanje za izbor najprestižnijeg univerziteta u Permu
Hajde da definišemo kriterijume po kojima ću vrednovati predložene alternative. Identifikovao sam 7 glavnih kriterijuma: 1. Javno mnjenje. Ovo je najviše važan kriterijum, na kojoj se zasniva imidž univerziteta. 2. Prepoznavanje. Bitna je i reputacija univerziteta...
Lokalni projekat računarsku mrežu drugi sprat škole br.19
Glavni kriterijum za prihvatanje je usklađenost gotovog projekta sa zahtevima naručioca, kao i kvalitet izvedenih radova...
Izrada web stranice za "Prodavnicu dječjih igračaka"
5. Podsistem izlaza ekrana sistem pomoći za korisnika; 6. Podsistem za prikaz informacija o programu na ekranu. 2...
Razvoj multimedije elektronski udžbenik
Objavljeno na http://www.allbest...
Izrada multimedijalnog elektronskog udžbenika iz discipline "Računarske mreže"
Jedan od kriterija za odabir hostinga je korišteni operativni sistem, pošto od toga zavisi softver koji će podržavati funkcionalnost određenih servisa...
Testiranje LAN baterija
Za opisivanje stanja mreže odabrana je metoda granične vrijednosti, čija je suština da se svaka izmjerena vrijednost uporedi sa tablicom preporučene vrijednosti...
Vrlo često nailazimo na pitanje „Šta prvo automatizirati?“ Automatizacija se ne radi radi automatizacije: želite da vidite rezultat procesa koji bi dao pozitivan ROI (možete pročitati više o izračunavanju ROI).
Zašto je važno koristiti automatizaciju?
Uobičajeno se vjeruje da automatizacija testiranja djeluje kao alat za podršku ručnom testiranju, ali u stvari je važno razumjeti da je automatizacija Najbolji način ne samo da štede vreme, već i povećavaju efikasnost, širinu obuhvata i tačnost testiranja, jer su zadaci koji se ponavljaju u ručnom pristupu izloženi riziku od ljudske greške. Automatizacija ne nadmašuje niti zamjenjuje ručno testiranje, ali ga nadopunjuje. Kao i upravljanje testiranjem, automatizacija takođe treba strategiju sa odgovarajućim planiranjem, praćenjem i kontrolom. Automatori ne samo da uče nove načine automatizacije, već i donose mnogo pametnih odluka. Automatizacija kod ispravna implementacija može biti prednost za tim, projekat i organizaciju.
Brojne su prednosti automatizacije, a mi ćemo spomenuti sljedeće:
- ubrzava uobičajene zadatke kao što su testovi dima i regresije;
- pomaže u pripremi testnih podataka;
- optimizira izvođenje test slučajeva povezanih sa složenom poslovnom logikom;
- olakšava višeplatformske testne slučajeve (na primjer, prilikom testiranja različitih OS-a, pretraživača, itd.);
- Odlično za izvršavanje test slučajeva koje je teško ili čak nemoguće završiti ručno;
- Dobro pomaže u slučajevima kada je broj iteracija tokom izvršenja unapred nepoznat.
U isto vrijeme, ne zaboravite automatizaciju cijelog procesa testiranja softver teško i isplativo, kako zbog visokih troškova alata za testiranje, tako i zbog potencijala nestabilne prirode određenih dijelova aplikacije. Projektne situacije uvelike utiču na izbor oblasti za automatizaciju (bilo da je u pitanju automatizacija testova za regresiju ili automatizacija koja će pokazati uska mjesta u čestim okupljanjima). Opisivanje svega moguće opcije, rizikujemo da dobijemo cijelu knjigu i stoga ćemo razmotriti samo najčešću situaciju: potrebno je automatizirati skup regresije.
Dakle, koji su kriteriji za odabir test slučajeva za automatizaciju?
Jedan od mnogih uobičajene greške Ono što testeri rade je da biraju pogrešne testove za automatizaciju. Potrebno je pažljivo analizirati i identifikovati kandidate za automatizaciju, uzimajući u obzir najviše važan faktor, odnosno ROI; drugim riječima, morate pronaći načine da dobijete veći i pozitivniji ROI. Da biste to učinili, morat ćete poduzeti niz radnji:
- odredite učestalost izvršavanja test slučaja (pokrenite ga za svaki novogradnja ili jednom, ali sa velikom količinom unosa?);
- saznati da li je testni slučaj poslovno kritičan ili pokriva kompletan scenarij od kraja do kraja;
- pobrinite se da analiza rezultata autotestiranja neće premašiti vrijeme provedeno tokom ručnog testiranja (inače će izgubiti relevantnost za automatizaciju);
- uzeti u obzir vjerovatnoću otkrivanja grešaka (uvesti testove koji najčešće pokazuju greške i slabosti);
- razumjeti da li test može postati blokirajući za važna funkcija ili funkcionalnost koja je kritična za poslovanje.
Koje vrste testova treba isključiti iz automatskog testiranja?
Navodimo slučajeve u kojima se testni slučajevi moraju filtrirati iz automatizacije:
- Testovi upotrebljivosti koji zahtijevaju ručnu intervenciju radi provjere grešaka ili odstupanja od očekivanog ponašanja;
- test slučajevi koji uključuju instalaciju ili ne moraju ponovo izvršavati funkcije (međutim, trebali biste automatizirati testove koji zahtijevaju velike ulazne podatke);
- Izbjegavajte automatizaciju testova koji mogu dovesti do nepredvidivih rezultata (na primjer, nove funkcionalnosti, vremenski testovi, provjera datuma isteka);
- UX testovi koji uključuju provjeru rekalibracije objekata različite veličine ekran.
Šta je sledeće?
Na osnovu gore navedenih faktora selekcije, dobićemo scenarije koji će učestvovati u selekciji za automatizaciju.
Sljedeći korak je podjela aplikacije koja se testira na module. Za svaki modul analiziramo i identifikujemo test slučajeve sa kojima će se izvršiti drugačiji set podaci, na različitim okruženjima (OS/Browser) i sa složenom poslovnom logikom, koriste veliku količinu podataka (uključujući i posebne) i koriste ih različiti korisnici.
Pogledajmo proces koristeći primjer. Imamo modul za kreiranje aplikacija u sistemu, za koji biramo test slučajeve uključene u proces kreiranja aplikacije. Nakon što su svi testovi napisani, konstatujemo da li je ispunjen bar jedan od uslova koje smo definisali (slika 1).
Klikom na sliku otvara se puna verzija.
Y – uslov je ispunjen
N – Uslov nije ispunjen
Tako dobijamo 3 test slučaja koji se mogu automatizovati i 2 test slučaja koji ne zahtevaju automatizaciju. Završili smo najvažniji zadatak i dobru polovinu posla: nered. nova tema pretvara u detaljan planšta treba uraditi.
Zaključak
Najčešće radije automatiziramo skup regresije jer sadrži velika količina testnih primjera, a njegova funkcionalnost je već stabilna (odnosno, ne mijenja se od izrade do verzije). U ovom slučaju, možemo podijeliti pakete regresije u module i odlučiti da pokrenemo odgovarajući paket u skladu sa zahtjevima izdanja.
Umjesto automatizacije cijelog skupa, biramo faznu automatizaciju. Drugim riječima, slijedimo model prototipa za razvoj paketa za automatizaciju.
Dakle, kreirajte strukturu ili okvir s manje implementiranih test slučajeva, a zatim ga poboljšajte dodavanjem sve više i više primjera.
Volite tester u sebi, a ne sebe u testiranju!
