STRATEGIJE SOFTVERSKOG TESTIRANJA

Strategija za testiranje softvera integrise slucaj softverskog testa modeliranja dizajna u dobro isplaniranu seriju koraka koji rezultariju u uspesnu konstrukciju softvera. Strategija obezbedjuje autokartu koja opisuje korake da se sprovedu kao deo testiranja, kada su ovi koraci isplanirani i preduzeti, i koliko puno napora, vremena, i sredstava ce biti obavezno. Stoga, bilo koja strategija testiranja mora da ukljuci planiranje testa, slucaj dizajniranja testa, izvrsenje testa, rezultanta prikupljanja podataka i procena.

Strategija testiranja softvera trebalo bi da bude dovoljno fleksibilna da promovise prilagodjeni pristup testiranja. U isto vreme, mora da je dosta kruto da se promovise razumno planiranje i pracenje upravljanja kako projekat napreduje.

Shuman razmatra ove probleme:Na mnogo nacina, testiranje je individualisticki proces, i broj razlicitih tipova

testova varira toliko koliko i razliciti razvojni pristupi. Dugi niz godina, nasa jedina odbrana protiv gresaka programiranja je bilo oprezno dizajniranje i prirodna inteligencija programera. Sada mi smo u dobu gde moderne dizajnerske tehnike [i formalni tehnicki komentari] nam pomazu da smanjimo broj pocetnih greski koje su nerazdvojive u kodu. Isto, razlicite metode testa pocinju da skupljaju sebe u nekoliko razlicitih pristupa i filozofija.

Sta je to? Slucajevi modeliranja dizajna softverskog testa [Glava 17] je vazno ali isto tako i strategija koju koristimo da ih pogubimo. Da li treba da razvijete formalan plan za vase testove? Da li trebate da testirate ceo program kao celinu ili dapokrenete testove na samo mali deo toga? Da li trebate da opet pokrenete testove koje ste vec sproveli kada dodate nove komponente na veliki sistem? Kada trebate da ukljucite kupca? Ova i mnoga druga pitanja su odgovorena kada razvijete strategiju za testiranje softvera. Ko to radi? Strategija za softversko testiranje je proizvedena od rukovodioca projekta, softverskih inzenjera, i strucnjaka za testiranje. Zasto je to bitno? Testiranje uracuna vise napora za projekat nego bilo koja aktivnost inzenjiranja softvera. Ako je sprovedeno slucajno, vreme je izgubljeno, nepotreban trud je potrosen, greske se jave neprimecene. Stoga bi bilo razumno da se uspostavi sistematicna strategija za testiranje softvera. Koji su koraci? Testiranje pocinje „u malom“ i napreduje „uveliko“. Ovim mi podrazumevamo da ranija testiranja se fokusiraju na jednu komponentu i primenjuje test bele-i-crne kutije da otkrije logicke i funkcionalne greske u programu. Nakon sto su individualne komponente testirane one moraju biti integrisane. Testiranje se nastavlja kako se softver konstruise. Konacno, serije testova visokog reda se izvrsavaju onda kada je ceo program operativan.

Ovi testovi su dizajnirani da otkriju greske u trazenjima. Sta je to proizvodno delo? Specifikacija testa dokumentuje pristup softverskog tima testiranju definisuci plan koji opisuje ukupnu strategiju i proceduru koja definise specificne korake tetsiranja i testovi ce biti sprovedeni.

Kako da se uverim da sam to tacno uradio? Pregledajuci specifikacije testiranja pre testiranja, mozes proceniti potpunost slucajeva testiranja i zadataka testiranja. Efektivni plan testa i procedure ce voditi do uredne konstrukcije softvera i otkrivanju gresaka na svakoj etapi u procesu konstruisanja.

Strategijski pristup testiranju softvera

Testiranje je set aktivnosti koje mogu biti planirane unapred i sprovedene sistematicno. Iz ovog razloga, sablon za testiranje softvera-set koraka u kojima mozemo da smestimo specifican slucaj dizajniranja tehnika testa i metode testiranja-trebalo bi da su definisiane za softverski proces.

Broj strategija za softversko testiranje je predlozeno u literaturi. Sve obezbedjuju razvoj softvera sa sablonom za testiranje i sve imaju sledece osnovne karakteristike:

*testiranje pocinje na komponenti nivo2 i radi „spolja“ prema integraciji celog kompjuterski baziranog sistema

*razlicite tehnike testiranja su odgovarajuce u razlicitim trenucima vremena*testiranje je sprovedeno od razvijaca softvera i [za velike projekte]

nezavisna test-grupa.*testiranje i otklanjanje gresaka su razlicite aktivnosti, ali otklanjanje

gresaka mora biti smesteno u bilo kojoj strategiji testiranjaStrategija za testiranje softvera je prilagodjena testovima nizeg nivoa koji su

neophodni da verifikuju taj mali segment izvornog koda je korektno sprovedena kao i testovi visokog nivoa koji overavaju funkcije glavnog sistema nasuprot zahtevima musterije. Strategija mora da obezbedi rukovanje za onog koji obavlja strucan posao i set prekretnica za rukovodioca. Zato sto se koraci strategije testa dese u trenutku kada je rok stegnuo sto je ranije moguce.

Testiranje softvera je je jedan element siroke teme koja se cesto odnosi na proveru i potvrdjivanje (P&P). Provera upucuje na set aktivnosti koje obezbedjuju da softver ispravno ispunjava specificnu funkciju.

Potvrdjivanje se odnosi na set aktivnosti koje obezbedjuju da softver koji je napravljen je shodan zahtevima musterije. Boehm [BOE81] iznosi ovo na drugi nacin:

Provera: „Da li gradimo ovaj projekat tacno?“Potvrdjivanje: „Da li gradimo pravi projekat?“Definicija P&P obuhvata mnoge aktivnosti koje mi upucujemo ka softveru

osiguranog kvaliteta (S&A)provera i potvrdjivanje obuhvataju sirok niz aktivnosti S&A koje ukljucuju

formalne tehnicke komentare, kvalitet i konfiguracijske provere, pracenje

performanse, simulaciju, studiju izvodljivosti, pregled databaze, algoritamsku analizu, testiranje razvoja, kvalitet testiranja, i instalacija testiranja [WAL89].

Iako testiranje igra vaznu ulogu u P&P, mnoge druge aktivnosti su takodje bitne. Testiranje dakako snabdeva poslednji bedem od kog kvalitet moze biti ocenjen i vise pragmaticno, greske mogu biti otkrivene. Ali testiranje ne bi trebalo posmatrati kao bezbednu mrezu. Kao sto kazu, „ne mozes da testiras u kvalitetu. ako to nije tu pre nego sto pocnes da testiras, to nece biti tu kad zavrsis testiranje.“ Kvalitet je prikljucen unutar softvera tokom procesa inzenjiranja softvera. pravilna primena metoda i alata, efektivni pregledi formalnih tehnika, i cvrsto upravljanje i merenje sve to vodi kvalitetu koje je potvrdjeno tokom testiranja.

Miler [MIL77] dovodi u vezu testiranje softvera ka ka uverenosti kvaliteta navodeci da „osnovna motivacija programa za testiranje je da afirmise kvalitet softvera sa metodama koje se mogu ekonomicno i efikasno primeniti i na veliki i mali sistem.“

Verifikacija i validacija

Testiranje softvera je jedan od elemenata šireg tema koja se često naziva verifikacijui validacija (V i V). Verifikacija se odnosi na skup aktivnosti kojima se obezbeđuje da softver pravilno sprovodi određene funkcije. Validacija se odnosi na drugi skup aktivnosti kojima se obezbeđuje da softver koji je izgrađen je pratiti po zahtevu korisnika zahtevima. Boehm [BOE81] Države ovaj drugi način:

Verifikacija: "Da li smo zgradu proizvod zar ne?"Validacija: "Da li smo zgradu pravi proizvod?"Definicija V i V obuhvata mnoge aktivnosti koje su se pozvali nakao garancija kvaliteta softvera (SQA).Verifikacija i validacija obuhvata širok spektar aktivnosti koje obuhvataju

SQA formalno tehnički pregledi, kvalitet i konfiguraciju revizije, praćenje rezultata, simulacija, studiju izvodljivosti, dokumentacija pregled, baze podataka pregled, algoritam analize, Razvoj testiranje, testiranje kvalifikacija, testiranje i instalacija [VAL89].

Iako testiranje igra izuzetno važnu ulogu u V & V, mnoge druge aktivnosti takođe je potrebno. Testiranje da li obezbeđuju poslednji bastion iz koga mogu da se oceni kvalitet i, još pragmatično, greške mogu biti otkriveni. Međutim, testiranje ne bi trebalo posmatrati kao bezbednost neto. Kako kažu, "Ne mogu testirati u kvalitetu Ako to nije tamo pre nego što počnete testiranja, to. neće biti tu kada završite testiranje "Kvalitet je. inkorporirana u softver tokom procesa softverskog inženjerstva. Pravilna primena metoda i alata, efektivna formalno tehnički pregledi, kao i upravljanje čvrstim i merenje sve dovesti do kvaliteta koji je potvrđen tokom testiranja. Miler [MIL77] se odnosi na softver za testiranje kvaliteta tvrdnjom da " osnovna motivacija programa testiranja je da se afirmišu kvalitet softvera sa metodama koji se mogu ekonomski i efikasno primenjuju na obe velike i male sistema. "

Organizovanje za testiranje softvera

Za svaki softverski projekat, postoji inherentni konflikt interesa koji se javlja kao testiranje počinje. Ljudi koji su izgradili softver se sada traži da testiraju softver.

Ovo izgleda bezazleno u sebi, posle svega, ko zna bolje od svojih programa Developers? Nažalost, te iste programeri imaju interes u demonstriranju koji program greške, da radi u skladu sa zahtevima korisnika, i da će biti završen na vreme iu okviru budžeta. Svaki od ovih interesa ublažavanje protiv temeljno testiranje.

Sa psihološke tačke gledišta, analiza i dizajn softvera (uz kodiranje) su konstruktivni zadaci. Softverski inženjer kreira računarski program, svoju dokumentaciju, i srodnih struktura podataka. Kao i svaki graditelj, softverski inženjer je ponosan na objekat koji je izgrađen i gleda popreko svako ko pokušada suza ga dole. Kada se testiranje počinje, tu je suptilna, ali definitivno, pokušaj da se "Break" ono što je softver inženjer je izgradio. Sa tačke gledišta Builder, testiranje se može smatrati (psihološki) destruktivna. Dakle, graditelj gazišta lagano, projektovanje i izvršavanje testova koji će pokazati da je program radovi, nego otkrivanje grešaka. Nažalost, greške će biti prisutni. I, ako softverski inženjer ih ne pronađete, korisnik će!

Često Postoji nekoliko zabluda koje se mogu pogrešno zaključiti na osnovu prethodne diskusije: (1) da programer softvera treba da uradi bez testiranja na svi, (2) da softver treba da bude "bacila preko zida" strancima, koji će testirati ga nemilosrdno, (3) da testera se uključe u projekat tek kada ispitivanje koraka uskoro će početi. Svaka od ovih izjava je netačna. Softversko inzenjrestvo je uvek odgovoran za testiranje pojedinih jedinica (komponente) programa, obezbeđujući da svaka obavlja funkciju za koju je dizajniran. U mnogim slučajevima, programer takođe obavlja integraciju testiranje-testiranje korak koji vodi ka izgradnji (i testiranje) od kompletne programske strukture.

Samo posle arhitektura softvera je potpuno ne nezavisna Test Group postala uključeni.

Uloga nezavisnog Test Group (ITG) je da se otklone probleme inherentne u vezi sa pokazivanjem graditelj testa stvar koja je izgrađena. Nezavisno testiranje otklanja sukob interesa koji inače mogu biti prisutni. Uostalom, osoblje u nezavisna grupa tima su plaćeni da pronađete greške.

Međutim, softverski inženjer ne okreće oko programa za ITG i hoda u gostima. Developer i ITG usko sarađuje tokom softverski projekat kako bi se osiguralo da temeljna testovi će biti sprovedena. Iako testiranje se sprovodi, projektant mora da biti na raspolaganju da ispravi greške koje su otkriveni. ITG je deo softvera tima razvojni projekat u smislu da učestvuje u specifikaciji aktivnosti i ostaje uključen (planiranje i specifikaciju test proceduri) tokom velikog projekta. Međutim, u mnogim slučajevima ITG izveštaje kvaliteta softvera organizacija

osiguranja, čime postizanje stepena nezavisnosti koje ne bi bilo moguće da je deo softverskog inženjerstva organizacije.

Softver za testiranje strategija

Softverskog inženjeringa proces može se posmatrati kao spirala je ilustrovano na slici. U početku, sistem inženjeringa i definiše ulogu softvera i dovodi do softvera zahteva analizu, gde informacije o domenu, funkcija, ponašanje, performanse, ograničenja, kao i kriterijumi za proveru softvera je uspostavljena. Premeštanje

duž unutrašnje spiralno, dolazimo do dizajna i konačno do kodiranja. Za razvijanje računaru softver, mi smo zajedno unutra spiralno pojednostavljuje da smanjenje nivoa apstrakcije na svakom potezu.

Strategija za testiranje softvera može se posmatrati u kontekstu spirale (Slika18.1). Jedinica za testiranje počinje u vrtlog spirale i koncentriše se na svaku jedinicu (Tj. komponenta) od softvera kao što je implementiran u izvornom kodu. Testiranje napreduje pomeranjem spolja duž spirala integracije testiranje, gde je fokus na dizajn i izgradnja softverske arhitekture.

Uzimajući drugom okrenuti ka spolja na spirala, nailazimo na testiranje valjanosti, gde je zahteve koji su utvrđeni kao deo zahtevi softvera analize su validirane protiv softvera koji je konstruisan. Konačno, stižemo na testiranje sistema, gde je softver i drugi sistem elementi su testirani u celini. Da biste testirali softver računara, mi se spiralno duž pojednostavljuje da proširi obim testiranja sa svakim zaokretom.

Imajući u vidu proces od proceduralne tačke gledišta, testiranje u kontekstu softverskog inženjerstva je zapravo niz od četiri koraka koji se sprovode redom.

Koraci su prikazani na slici 18,2. U početku, testovi fokus na svaku komponentu pojedinačno, osiguravajući da funkcioniše ispravno kao celina. Dakle, ime jedinica za testiranje. Jedinica za testiranje čini teškim upotrebom bele kutije za testiranje tehnike, vežbanje specifične staze u kontrolnu strukturu modula da obezbedi potpunu pokrivenost i maksimalna greška otkrivanje. Sledeće, komponente moraju biti sastavljeni ili integrisana u obliku kompletan softverski paket. Integracija testiranje se bavi pitanjima u vezi sa dva problema verifikacije i programa izgradnje. Crne kutije test dizajn tehnike su najčešći tokom integracije, iako je ograničena iznosu od bele kutije za testiranje mogu da se koriste kako bi se obezbedilo pokrivanje velikih kontrole staze. Pošto softver je integrisan (izgrađena), skup visokog reda testovi sprovode. Validacija kriterijumima (osnovana u toku analize zahteva) moraju biti testiran. Validacija testiranje predviđa konačnu garanciju da softver zadovoljava sve funkcionalne, ponašanja, i performansi. Crne kutije testiranja tehnike se koriste isključivo tokom validacije.

Poslednji visoki reda testiranje korak je izvan granica softverskog inženjerstva i u širem kontekstu inženjering računarskih sistema. Softver, jednom potvrđena, mora se kombinovati sa drugim elementima sistema (na primer, hardver, ljudi, baze podataka). Testiranje sistema potvrđuje da su svi elementi mreže ispravno i da je ukupna funkcija sistema i performansi je postignuto.

Kriterijumi za završetak testiranja

Classic Postavlja se pitanje svaki put testiranje softvera je razmatrano: "Kada smo uradili testiranje-Kako znamo da smo dovoljno provereno "Nažalost?, ne postoji konačan odgovor na ovo pitanje, ali postoji nekoliko odgovora pragmatični i ranim pokušajima u empirijskim smernice.

Jedan odgovor na pitanje je: "Nikada ne završite testiranje, jednostavno teret smene od vas (softverski inženjer "), da kupac" Svaki put kupca. / korisnik izvršava računarski program, program je u fazi testiranja. To otrežnjenje Činjenica podvlači značaj drugog softvera aktivnosti obezbeđenja kvaliteta. Još jedan odgovor (donekle cinično, ali ipak tačna) je: "Vi ste uradili testiranje kada vam ponestane vremena, ili vam ponestane novca. " Iako je malo prakse bih sa ovim odgovorima, inženjer softvera je potrebno više rigorozne kriterijume za određivanje kada je dovoljno za testiranje sprovedena. Musa i Akerman [MUS89] sugerišu odgovor koji je zasnovan na statističkoj kriterijuma: "Ne, mi ne možemo biti apsolutno sigurni da softver nikada neće uspeti, ali u odnosu na teorijski i eksperimentalno potvrđena zvuk statističkog modela, Uradili smo dovoljno testiranje reći sa 95 odsto poverenja da je verovatnoća od 1000 procesora sati rad bez neuspeha u probabilisticalli definisano okruženje je najmanje 0.995. "

Korišćenje statističko modelovanje i softvera pouzdanost teorije, modeli softverskih kvarova (Otkrili prilikom testiranja) kao funkciju vremena izvršenja može da se razvije [MUS89]. Verzija neuspeha modela, koji se zove logaritamske Puassona izvršenja vreme modela, ima oblik

f (t) = (1 / P) ln [l 0 + 1 pt]

gde je f (t) = kumulativni broj propusta od kojih se očekuje da se pojavljuju kada Softver je bio testiran na određeno vreme izvršenja, T,

L0 = inicijalnog softvera neuspeh intenziteta (neuspehe po jedinici vremena) na početku testiranja,

P = eksponencijalni smanjenje intenziteta kao neuspeh su greške otkrivenei popravke su napravljeni.

Trenutna insuficijencija intenziteta, L (t) se može izvesti tako što izvod f (t)L (t) = l 0 / (L0 pt + 1)

Korišćenje odnos je navedeno u jednačini (18-2), testeri mogu da predvidim pad-off grešaka i testiranje napreduje. Sunce greška intenzitet se može prikazati u odnosu na predviđeni kriva (slika 18.3). Ako stvarnih podataka prikupljenih tokom testiranja i logaritamska Puassona vreme izvršenja modela su prilično blizu jedan drugog preko broj tačaka podataka, model se može koristiti za predviđanje ukupno vreme potrebno za testiranje da se postigne prihvatljivo niskog intenziteta neuspeh.

Prikupljanjem merenja tokom testiranja softvera i korišćenje postojećeg softvera pouzdanost modela, moguće je razviti smislen smernice za odgovaranje Pitanje: "Kada smo mi uradili testiranje?" Malo je rasprava koja je dalji rad i dalje da se uradi pre nego kvantitativni pravila za testiranje mogu se osnivati, ali empirijski pristupe koji trenutno postoje su znatno bolji nego sirova intuicija.

Strateška pitanja

Kasnije u ovom poglavlju, mi smo istražiti sistematski strategije za testiranje softvera. Ali, čak i najbolja strategija neće uspeti ako niz prevashodni pitanja nisu obratili. Tom Gilb [GIL95] tvrdi da mora da sledeća pitanja mogu rešiti ako se uspešno softvera testiranje strategija će se realizovati:

Navedite proizvod zahteve u kvantitativne način mnogo pre nego štoi spitivanje počinje. Iako je prevashodni cilj ispitivanja je da se pronađe greške, dobar za testiranje strategija i procenjuje druge kvalitetne karakteristike su kao i prenosivost, održavanja, i upotrebljivost (Glava 19). One treba da budu navedene u način koji je merljiv, tako da rezultati ispitivanja su nedvosmisleni.

Državni testiranje ciljeva eksplicitno. Specifični ciljevi ispitivanja treba navesti u merljivim terminima. Na primer, efikasnost testa, testa pokrivenost, srednje vreme na neuspeh, troškovi pronašli i rešili nedostataka, preostali defekt gustina ili učestalost pojavljivanja, i test-sati rada po regresije testirati sve treba navesti u okviru testa plana [GIL95].

Razumeti korisnici softvera i razvoj profil za svaki korisnik kategoriju. Slučajevi korišćenja koji opisuju interakciju scenario za svaku klasu korisnik može da smanji ukupan napor testiranja fokusirajući se na testiranje stvarna upotreba product Develop plana testiranja koja naglašava Gilb "Rapid ciklus testiranja." [GIL95] preporučuje da softverski inženjering tima "Naučite za

testiranje u Rapid ciklusa (2 odsto projekta napora) od kupaca-koristan, bar polje 'trialable' koracima funkcionalnosti i / ili poboljšanja kvaliteta. "povratne informacije generisane iz ove brze ciklusa testova može da se koristi za kontrolu nivoa kvaliteta i odgovarajućih testova strategija.

Napravite "robustan", softver koji je dizajniran da se testirate. Softvare treba da budu dizajnirani na način koji koristi antibugging (Odeljak 18.3.1) tehnika. To je, softver bi trebalo da bude u stanju da određene dijagnoze klase grešaka. Pored toga, dizajn bi trebalo da primi automatsku testiranje i regresija testiranja. Koristite efikasan formalno tehnička gostiju kao filter pre testiranja. Formalan tehnički kritike (Glava 8) mogu biti efikasni kao testiranje u otkrivanju grešaka. Iz tog razloga, pregledi mogu da smanje količinu testiranja napora koji je potrebne za proizvodnju visoko-kvalitetan softver.

Ponašanja formalno tehnička pregledi za procenu strategije testa i testa slučajevima sami. Formalni tehnički pregledi mogu da otkriju nedoslednosti, propusta, i potpuno greške u pristupu testiranja. To štedi vreme i takođe poboljšava proizvod kualiti.Develop kontinuirano poboljšanje pristupa za testiranje proces. Test Strategija treba da se meri. Metrika prikupljeni tokom testiranje treba da se koristi kao deo statistički pristup kontroli procesa za softver za testiranje.

Testiranje jedinica

Jedinica za testiranje se fokusira na verifikaciju napore najmanja jedinica softvera dizajna softverska komponenta ili modul. Koristeći komponente nivou Opis dizajna kao uputstvo za upotrebu, važni za kontrolu putanje su testirani da otkrije greške u okviru granica modula. Relativna kompleksnost testove i otkrili greške je ograničena ograničen prostor za uspostavio jedinicu testiranje. Jedinica test je belo-boks orijentisan, i korak može biti sprovedena paralelno na više komponenti.

Jedinica test Razmatranja

Testovi koje se javljaju kao deo jedinice testova su šematski prikazano na slici 18,4.

Modul interfejs je testirana da osigura da informacije pravilno teče u i van programa jedinica pod testa. Lokalnih struktura podataka se ispituje da obezbedi da podatke koji se nalaze privremeno održava svoj integritet u svim koracima u realizaciji algoritma. Granični uslovi su testirani kako bi se osiguralo da modul radi pravilno u granicama osnovana sa ciljem da ograniči ili ograničiti prerade. Sve nezavisne putanje (osnova staze) kroz kontrolna struktura se vrši kako bi se osiguralo da su sve izjave modul je pogubljeno najmanje jednom. I na kraju, svi putevi su grešaka testiran.

Testovi toka podataka preko modula interfejsa su potrebna pre nego što bilo koji drugi test započet. Ako se podaci ne uđe i izađe na pravi način, svi ostali testovi su sporna. Pored toga, lokalne strukture podataka treba da se ostvaruje i lokalni uticaj na globalno podaci bi trebalo da da se sazna (ako je moguće) za vreme testiranja jedinice. Selektivno ispitivanje izvršenja staza je osnovni zadatak tokom jedinice testa. Test slučajevima treba da bude dizajniran tako da otkrije greške usled pogrešne proračune, netačan poređenja, ili nepravilnog kontrolu protoka. Osnove putanju i petlje za testiranje su efikasni tehnike za otkrivanje širok spektar puta grešaka.

Među više uobičajene greške u obračun su (1) pogrešno ili netačno aritmetičke prednost, (2) mešoviti režim rada, (3) neispravan inicijalizaciju, (4) preciznost netačnost, (5) netačno simbolično predstavljanje izraza. Poređenje i kontrola protoka su tesno zajedno jedan drugom (tj. promeni protoka često dolazi posle poređenje). Test slučajevima trebalo bi da otkrije greške, kao što su (1) poređenje različitih tipova podataka, (2) netačna logičke operatore ili prednost, (3) očekivanje jednakosti Kada se preciznost o grešci čini malo verovatno jednakost, (4) netačno poređenje varijabli, (5) nepravilno ili nepostojeće petlje prestanka, (6) neuspeh da izađete kada divergentnih iteracija je naišao, i (7) nepropisno put izmenjena u petlji promenljive.Dobar dizajn diktira da se greška uslove predviđene i bez greške rukovanje staze podesiti da preusmerava ili čisto okonča u fazi obrade kada ipak dođe do greške. Iourdon [IOU75] zove ovaj pristup antibugging. Nažalost, postoji tendencija da se uključe grešaka u softver, a zatim ga nikada nije testa. Istinita priča može poslužiti kao ilustruju:

Veliki interaktivnog dizajna razvijen je sistem pod ugovorom. U jednom obradu transakcija modula, praktičnog Joker nalazi se sledeća greška rukovanje poruku nakon serije uslovnih testova koji pozivaju razne kontrole toka grane:

ERROR! NEMA NAČIN možete dobiti ovde. Ovaj "poruku o grešci" je otkrivena od strane kupca u toku korisnika

obuka! Među potencijalne greške koje bi trebalo da bude testiran grešaka se ocenjuje su

1. Opis greške je nerazumljiv.2. Greška primetio ne odgovara Došlo je do greške.3. Greška stanje dovodi do sistema intervencije pre grešaka.4. Izuzetak-uslov za preradu je netačna.5. Greška opis ne pruža dovoljno informacija da pomognu u mestuna uzrok greške.

Granični ispitivanja je poslednji (i verovatno najvažniji) zadatak jedinice testa korak. Softver često ne na njene granice. To jest, greške se često javljaju kada se n-ti element N-dimenzionalni niz obrade, kada ITH ponavljanje petlje sa I prolazi se poziva, kada maksimalna ili minimalna dozvoljena vrednost je naišao. Test slučajevima koji vežba strukturu podataka, kontrolu toka, i vrednosti podataka odmah ispod, u, i malo iznad minimuma i maksimuma su veoma verovatno da otkrije greške.

Jedinica za test procedurama

Jedinica za testiranje se obično smatra kao dodatak kodiranje korak. Nakon izvor nivou Kod je razvijen, pregledani i verifikovani za prepisku na componentlevel dizajn, dizajn jedinica test počinje. Pregled dizajna informacije pružaju smernice za uspostavljanje testiranja predmeta koji će verovatno da otkrije greške u svakoj od kategorije razgovarali ranije. Svaki test bi trebalo da bude u kombinaciji sa skupa očekuje rezultate.

Pošto komponenta nije samostalan program, vozač i / ili klica softvera moraju biti razvijeni za svaku jedinicu testa. Jedinica test okruženju je ilustrovano na slici 18,5. U većini aplikacija vozač nije ništa više nego "glavni program" koji prihvata test podacima, prolazi takve podatke da se komponenta (da se testira), i štampa relevantne rezultate. Klice služe da zameni module koji su podređeni (nazivaju) komponenta se testira. Klica ili "potprograma lutke" koristi podređenih modula interfejs, mogu da urade minimalne manipulacije podacima, štampa proveru ulaska, i vraća kontrolu modula u procesu testiranja.

Vozači i klice predstavljaju iznad glave. To jest, oba su softver koji mora biti napisan (Formalna dizajn nije često primenjuje), ali to se ne isporučuje uz završni softverski proizvod. Ako vozača i klice se čuvaju jednostavna, Sunce iznad glave je relativno nizak. Nažalost, mnoge komponente ne mogu biti adekvatno jedinica testiran sa "jednostavnim"

iznad glave softvera. U takvim slučajevima, kompletna testiranja može da se odloži Unti

• Uređaj za testiranje je pojednostavljeno kada komponenta sa visokim kohezija je dizajniran. Kada samo jednu funkciju se obratili komponente, broj testiranja se smanjuje

i greške mogu biti lakše predvideti i otkriven.

INTEGRACIJA TESTING

Početnik u svetu softvera pitati naizgled legitimno pitanje kada sve moduli su testirani jedinica: "Ako svi oni pojedinačno rade, zašto sumnje da oni će raditi kada smo ih zajedno "Problem, naravno, jeste"? stavljajući ih . Zajedno "-povezivanje podataka može da se izgubi kroz interfejs, jedan modul može imati nenamerno, nepovoljne utiče na drugom, subfunctions, u kombinaciji, ne može da proizvede željeni smer funkciju, individualno prihvatljivo nepreciznosti mogu biti uvećane do neprihvatljivih nivoa; globalne strukture podataka mogu da predstavljaju problem. Nažalost, lista ide dalje i dalje.

Integracija testiranje je sistematski tehnika za izgradnju strukturu programa dok u isto vreme sprovodi testove da otkrije greške u vezi sa interfejs. Cilj je da se jedinica testira komponente i izgradi strukturu programa koji je diktiran po svom dizajnu. Često postoji tendencija da se pokuša nonincremental integracije, to je da izgradi program koristeći "Big Bang" pristup. Sve komponente su kombinovani u unapred. Čitav program je testiran u celini. I haos obično rezultate! Skup grešaka je naišao. Ispravka je teško, jer izolacija uzročnika je komplikovano od ogromno prostranstvo celog programa. Nakon ove greške su ispravljene, nove se pojavljuju i proces se nastavlja u naizgled beskrajne petlje. Inkrementalno integracija je antiteza velikog praska pristup. Program je izgrađen i testiran u malim koracima, gde se greške lakše da izoluju i ispravna, interfejsi su više verovatno da će biti u potpunosti testirani i sistematsko testiranje pristup može se primeniti. U odeljcima koji slede, broj različitih dodatnih Integracija strategija se diskutuje.

Odozgo na dole integracije

Odozgo na dole integracije testiranje je inkrementalni pristup izgradnji programastrukture. Moduli su integrisani pomeranjem na dole preko kontrole hijerarhije, počevši od osnovni kontrolni modul (glavni program). Moduli podređeni (I na kraju podređeni) da glavni modul za kontrolu su uključeni u struktura u bilo dubine ili širine prvi-prvi način. Pozivajući se na slici 18,6, dubina-prvi integracije će objediniti sve komponente na glavni kontrolni put strukture. Izbor glavnih put donekle proizvoljan i zavisi od aplikacije specifičnim karakteristikama. Na primer, izbor levoj put, komponente M1, M2, M5 bi se integrišu na prvom mestu. Dalje, M8 ili (ako je neophodno za pravilno funkcionisanje M2) M6 biti integrisani. Zatim, centralni i righthand Kontrola putanje se grade. Širina-prva integracije

obuhvata sve komponente direktno podređen na svakom nivou, krećući se po strukturi horizontalno. Od figura, komponente M2, M3, i M4 (zamena za stub S4) će biti integrisana na prvom mestu. Sledeći nivo kontrole, M5, M6, i tako dalje, sledi.

Integracija obavlja se u seriji od pet koraka:1. Glavni kontrolni modul se koristi kao test vozač i klice se

zamenjuju za sve komponente direktno podređeni glavni modul kontrole.2. U zavisnosti od izabranog pristupa integracija (tj. dubina ili

širina prvi), podređeni Klice se zamenjuju jedan po jedan sa stvarnim komponentama.

3. Testovi se obavljaju kao i svaka komponenta je integrisan.4. Po završetku svakog seta testova, drugi stub je zamenjen sa

realnom komponentu.5. Regresiona ispitivanja (član 18.4.3) može se sprovesti kako

bi se obezbedilo da nove greške nisu uvedene.

Proces se nastavlja korak 2 sve dok ceo program struktura izgrađena. Top-dovn Strategija za integraciju proverava kontrola glavnih ili odluke poena početkom na testu procesu. U dobro faktor programsku strukturu, donošenje odluka se javlja na višim nivoima u hijerarhiji i zbog toga je naišao na prvom mestu. Ako se glavni problemi kontrole postoje, rano prepoznavanje je od suštinskog značaja. Ako je dubina integracije-prva je izabran, potpuna funkcija softvera može biti implementiran i pokazali. Na primer, smatraju Classic strukturu transakcija (poglavlje 14) u kojoj složenog niza interaktivne ulaza se traži, kupio i provera preko dolazni put. Test korak integracije (gde su vozači ili klice takođe se koristi).

Dolazni putanja može biti integrisan u top-dovn način. Svi unosa obradu (za naredne transakcije dispečerskog) može da se demonstrira pred drugim elementima strukture su integrisani. Rano ispoljavanje funkcionalnih sposobnosti poverenje Builder i za programera i korisnika.

Top-dovn strategije zvuči relativno jednostavno, ali u praksi, logističke probleme mogu nastati. Najčešći od ovih problema se javlja prilikom obrade na niskim nivoa u hijerarhiji je dužan da adekvatno testiranje višim nivoima. Klice zameniti lovlevel modula na početku testiranja odozgo-nadole, dakle, nema značajne podaci mogu protok nagore u programskoj strukturi. Tester je napustio sa tri izbora: (1) kašnjenje mnogi testovi dok se klice su zamenjeni sa stvarnim modula (2) razvijaju klice koje obavljaju ograničene funkcije koje simuliraju stvarne modula, ili (3) integriše softver naviše iz dna hijerarhije.

Prvi pristup (kašnjenje do klice testovi zamenjuju stvarnim moduli) izaziva nam da izgubi kontrolu nad nekim povezanost između specifičnih testova i inkorporacije specifičnih modula. To može dovesti do teškoća u određivanju uzroka grešaka i teži da prekrši veoma ograničen priroda top-dovn pristup.

Drugi pristup je izvodljiv, ali može da dovede do značajnih iznad glave, kao i klice se sve više i složenije. Treći pristup, nazvan odozdo testiranja, raspravlja u narednom odeljku.

Od dna prema vrhu integracija testiranja, kao sto i ime ukazuje, pocinje izgradnju i testiranje sa atomskim modulima ( tj komponente kod najnizih nivoa u programu struktura).

Posto su delovi integrisani od dna prema vrhu, obrada zahteva za komponente je podredjen datim nivoom koji je uvek dostupan i eliminise klice.

Od dna prema vrhu strategije integracije se mogu primenjivati sa sledecim koracima:

1. Nizak nivo komponenti se kombinuje u klastere koj vrsi odredjena softerska podfunkcija

2. Upravljacki program ( kontrolni program za testiranje) je napisan da koordinira predmet testiranja ulazne proizvodnje

3. Klaster nije testiran.4. Upravljacki programi su uklonjeni i klasterima se kombinuju

navise pokretni u programu strukture.

Integracija prati model prikazan na slici 18.7. Komponente su u kombinaciji da formiraju grupe 1, 2 i 3. Upravljacki program nije ispitivao svaku grupu( prikazuje kao isprekidan blok). Komponente u grupama 1 i 2 su podredjeni Ma. Upravljacki programi D1 i D2 su uklonjeni i interfejs je direknto na Ma. Slicno tome, upravljacki program D3 grupe 3 nije uklonjen iz integracije sa modulom Mb. I Ma i Mb ce na kraju biti integrisani sa komponentom Mc i tako dalje.

Kako se integracija krece na gore, potreba testiranja za korisnike se smanjuje.

U stvari, ako su prva dva nivoa programske strukture integrisani od vrha prema dnu, broj za korisnike se moze znatno smanjiti i integracija grupe nije u veilikoj meri pojednostavljen.

Regresija Testiranja

Svaki put novi model nije dodat kao deo itegracionih testiranja, vec je potrebno upustvo za upotrebu promena. Novi protok podataka staze je uspostavljanje, nove I/O ,koji mogu da javljaju iz novog kontrolnog centra. Ove promene mogu izazvati probleme funkcijama koje su prethodno radile besprekorno. U kontekstu stategije integracije u testu, regresija testiranja nekih tekstova koji su vec sprovedeni kako bi se osiguralo da se promene nisu i da se nisu ostvarila nezeljena dejstva.

U sirem kontekstu, uspesni tekstovi ( bilo koje vrste) , rezultati su u otkrivanju gresaka i greske moraju biti ispravljene. Uvek kada upustvo za upotrebu nije ispravljeno, neki aspekti se ne menjaju. Regresija testiranja nije aktivnost koja pomaze da se osigura da promene( usled testriranja iloi iz drugih razloga) ne uvedu nezeljeno funkcionisanje ili dodatne greske.

Regresiona testiranja mogu da se rucno sprovode, ponovno izvrsenje je podskup svih testiranja i slucajeva koji su koriscenjem automatizovanih sminanja/reprodukcija alata.

Slikaj/ reprodukuj alati, omogucavaju upustvo za upotrebu inzenjera da zauzme predmet testiranja i rezultate za kasniju reprodukciju i poredjenje.

Regresija testiranja paketa( podskup tekstova da se izvrsi) sadrzi tri razlicite klase predmeta testiranja:

Reprezentativnom uzorku od testova koji ce vrsiti sve funkcije i upustvo za upotrebu

Dodatni testovi koji se fokusiraju na softverske funksije koje je verovatno da ce biti pogodjeni promenama

Testovi koji se odnose na upustvo za upotrebu komponenata koji su izmenjeni. Kako prihod integracije testiranja moze narasti, broj regresije testova moze da bude prilicno velika.

Dakle, regresija testiranja paketa, treba da bude dizajnirana da obuhvati samo one testove koji se odnose na jedni ili vise grupa gresaka u svakoj od glavnih programa funkcije. On nije nepraktican i neefikasan da ponov izvrsi testitanje za svaki program ponaosob kada nastanu promene.

Testiranje Dima

Testiranje dima nije testiranje integracije, vec pristup koji se obicno koristi kao upustvo za razvijene proizvode. Dizajniran je kao ritam mehanizam za vremenski kriticne projekte, omogucavajuci softverski tim da proceni svoj projekat na cestim osnovama. U sustini, testiranje dima je pristup koji obuhvata sledece aktivnosti:

1. Komponente softvera koje su prevedene na broj su integrisane. Izgrada obuhvata sve datoteke sa podacima, biblioteke, visekratnu upotrebu modula i projektovane komponente koje je potrebno da sprovedu jednu ili vise proizvoda funkcija.

2. Serija testova nije dizajnirana da izlozi greske koje ce se i dalje zadrzati, vec da izgradi i ispravno obavlja svoju funkciju. Nameda bi trebalo da otkrije greske koje su najveca verovatnoca za bacanje zbog cega softverski projekat kasni.

3. Build nije integrisan sa ostalim proizvodima i ne oslanja se na svakodnevno testiranje dima. Pristup integracija moze da bude odozgo prema dole ili obrnuto.

Dvena frekvencija ispitivanja celog proizvoda moze iznenaditi citaoce. Medjutim, cesto daju testove na ispitivanja menadzerima i citaocima, kako bi uvideli realnu situaciju i da li postoji napredak u testiranju. McConnell[MCO96] opisuje dim set na sledeci nacin:

Dim test treba da prodje ceo sistem skraja na kraj. To ne mora da bude konacna, ali bi trebalo da bude sposobna za izlaganje glavnih problema.

Dim test treba da bude temljno dovoljan da, ako se izgradi prolaz, mozete pretpostaviti da nije dovoljno stabilan da se testira detaljnije.

Dim testiranje pruza brojne prednosti, kada se primenjuje u slozenim softvreskim projektima:

Rizik integracije nije sveden na minimum, jer dim testiranje sprovode svakodnevno, nekopmaktibilno i drugi prikazuju greske koje se

odma otkriju, cime se smanjuje mogucnost ozbiljnih uticaja kada se otrkije greska.

Kvalitet krajnjeg proizvoda nije poboljsan, posto je izgradnja pristupu orijentisana, testiranje dima nije verovatno d ace otrkiti i funkcionalne greske i arhitektonske komponente na nivou dizajna defekata. Ako se ti nedostaci rano isprave, rezultat ce biti bolji kvalitet proizvoda.

Greske dijagnoze i korekcije su pojednostavljene. Kai is vi pristup testiranju integracija,, otrkiva greske u toku dim testiranja i verovatno ce biti povezan sa nvomi upustvo za upotrebu koracima, tj, upustvi za upotrebu koji je upravo dodao da se izgradi , a nije verovatno uzrok novootkrivene greske.

Napredak nije lako proceniti. Sa svakim danom, vise softvera je integrisano i vise se pokazuje da se radi. To poboljsava moral timu i daje menadzerima dobar znak da je napredak ostvaren.

Komentari na integraciju testiranja

Bilo je mnogo diskusija (npr [bei84]) na relativne nedostatke i prednosti bottom-up integracije testiranja. U principu, prednosti jedne strategije imaju tendenciju da dovedu nedostatke sa druge strategije. Mana top-down pristupa je za grupe i polaznike testiranja teska ako bude povezana sa njima. Problem u vezi klice mogu biti nadoknadjena ranim testiranjem glavne kontrolne funkcije. Glavni nedostatak bottom-up integracije je da program kao entite ne postoji sve dok nije dodat posledni moduo:”[MYE79]. Ova mana nije ublazila lakse testiranje i nedostatak klice.

Izbor strategije zavisi od integracije, upustva za upotrebu i karakteristika, ponekad i raspored projekta. U proncipu, u kombinaciji da koristi top-down testovi za gornje nivoe programske structure zajedno sa bottom-up testovi za podredjenih nivoa mogu da budu najbolji kompromis.

Kako se obavlja testiranje integracija, ispitivac treba da identifikuje kriticne module. Kriticni modul ima jedan ili vise od sledecih karakteristika:

1. Adrese nekoliko softverskih zahteva2. Ima visok nivo kontrole3. Nije kompleksan ili sklon greskama4. Ima odredjene zahteve performansi. Kriticni modulima treba

da se testiraju sto je ranije moguce. Pored toga, regresija testova treba da se usredsredi na kriticne modul funkcije.

Integracioni test dokumentacija

Opsti plan za integraciju i upustvo za upotrebu i opis sprecificnih testova je dokumentovan u specifikaciju ispitivanja. Ovaj document sadrzi plan testa i postupke ispitivanja, nije delo proizvoda za upotrebu procesa, i postaje deo za upustvo i upotrebu konfiguracija. Plan testiranje opisuje opste strategije za integraciju. Testiranje je podeljen u faze i osljanja se pitanjima koje se bave specificnim finkcionalnim i bihejvioralnim karakteristikama za upotrebu. Na primer, integracija testiranja za CAD sistem moze biti podeljen u sledece test faze:

Interakcija korisnika ( komanda izbor, crtanje staranje, zastupanje ekrana, obrade greske i predstavljanja)

Podaci manipulacije i analize( symbol stvaranja, dimenzionisanje, rotacije, izracunavanje fiziskih osobina)

Ekran za obradu i generisanje( dvodimenizonalni displeji, trodimenzionala, grafikoni)

Upravljanje bazama podataka( pristu, azuriranjem integritet, performance).

Svaka od ovih faza oznacava(ocrtava) siroka funkcionalna kategorija koje u okviru upustva za upotrebu mogu generalno da se odnose na specificne domen programske structure. Zbog toga, program je predvidjen i kreiran da odgovara svakoj fazi. Sledeci kriterijumi i odgovarajuci testovi se primenjuju za sve faze testiranja:

Interfejs integriteta. Interni i externi interfejsi su testirani kao i svaki modul koji je ugradjen u strukturu

Funkcionalna ispravnos. Testovi dizajnirani da otkriju funkcionalne greske koje se sprovode

Informacije sadrzaja. Testovi dizajnirani da otkriju greske koje se sprovode u lokalnim i globalnim strukturama

Performance. Testovi za proveru performansi koje se sprovode u softverski dizajn

Raspored za integraciju, razvoj softvera pre svega, u vezi je teme o kome se razgovara kao testiranje plana. Pocetni i zavrsni datumi za svaku fazu se osnivaju “dostupnost windows” gde su moduli testiranja definisani.

Kratak opis softvera koncetrise se na karakteristike koje bi mogle zahtevati posebne napore. Konacno, testiranje zivotne sredine i resursi su opisani.

Neobicne hardverske konfiguracije, egzoticni simulatori, kao i specilajni test alati i tehnike, su neke od mnogih tema koje mogu biti razmatrane. Detaljne procedure testiranja koja su potrebna da se ostvare, je u nastavku opisan. Redosled integracije i odgovarajucih testova na svakoj integraciji su u koracima opisani. Spisak svih testiranja( sa komentarima za kasniju referencu) i ocekivani rezultati su takodje ukljuceni.

Istorija stvarnih rezultata testiranja, problema, ili osobenosti je zabelezen u tes specifikacija. Informacije sadrzane u ovom odeljku mogu biti od bitnog znacaja za vreme odrzavanja softvera.

Odgovarajuci prilozi i reference su takodje prikazani. Kao i svi drugi elementi konfiguracije softvera, testiranje specifikacije formata moze biti prilagodjen lokalnim potrebama organizacije softverskog inzenjerstva. Vazno je napomenuti da je ona, medjutim, strategija za integraciju i ispitivanja detalja, da se neophodni sastojci moraju nabaviti.

Nostrifikacija ispitivanja

Kulminacija integracije testiranja, softver je u potpunosti sastavljen kao paket, greske na intefrejsu su otkrivene i ispravljene i finalna serija testiranja softvera moze da pocne. Validacija se moze definisati na mnogo nacina, ali jednostavno, definicija je da validacija uspe kada softver finkcionise na nacin na koji je moze razumeti kupac. U ovom trenutku programmer moze da protestuje:”ko ili sta je arbitar razumnog ocekivanja?”

Razumna ocekivanja su definisana u zahtevima softverske specifikacije-dokumenta( poglavlje 11) koje opisuje sve korisnicke attribute softvera koji su vidljivi. Specifikacija sadrzi odeljak za proveru valjanosti kriterijuma. Informacija sadrzana u taj deo predstavlja osnovu za pristup validacije testiranja.

Ispitivanje kriterijuma validacije

Softver validacije se postize kroz niz black-box testova, koji pokazuju usaglasenost sa zahtevima. Test plan obrise klase testova da bi se sproveo postupak ispitivanja i definisao specificni test predmeta, koji ce se koristiti sa zahtevima da bi pokazao usaglasenost. I plan i postupak su dizajnirani da obezbede sve funkcionalne zahteve sa kojim su zadovoljni, sve karakteristike ponasanja koje su postignute, svi zahtevi performansi, ispravan document, a drugi uslovi su ispunjeni( npr.kompatibilnost, greska oporavka, odrzavanje).

Posle svake provere valjanosti koji se sprovodi, moguce je da se pojave dva stanja: (1) funkcije ili karakteristike u skladu sa prihvacenom specifikacijom ili (2) kreiranje lista nedostataka i otkrivanje odstupanja specifikacije. Odsupanje ili greske otkrivene u ovoj fazi projekta, se retko ispravljaju pre zakazane isporuke. Cesto je neophodno da pregovara sa klijentima i da se uspostave metode za resavanje nedostataka.

Razmatranje konfiguracije

Process provere valjanosti je vazan element za pregled konfiguracije. Namera revizije je da se osigura da su svi elementi konfiguracije softvera pravilno razvijeni, obradjeni su, i imaju potrebne detalje za jacanje podrske u fazi zivotnog ciklusa softvera. Razmatranje konfiguracije ponekad se naziva revizija, a o tome ima vise reci u poglavlju 9.

Alfa i Beta testiranje

U praksi je nemoguce da programmer predvidi kako ce kupac koristiti program. Upustvo za upotrebu se moze pogresno protumaciti, cudna kombinacija podataka moze se redovno koristiti, izlaz koji izgleda jasno definisan moze biti nerazumljiv za korisnike na terenu.

Softver je prilagodjen da sluzi jednog korisnika, da ispuni sve zahteve koja se sprovodu prilikom testiranja. Prihvatanje testa moze da varira od neforlmalne “test drive” i da vrsi niz sistemskih testiranja. U stvari, prihvatanje testiranja moze da se sprovodi u period od nekoliko nedelja ili meseci, cime otrkivanja kumulativne greske, degradiraju sistem tokom vremena.

Alfa test se sprovodi na sajtu od strane kupca. Softver je napravljen da se koristi u prirodnom okruzenju gde ce hvatati koriscene problem i snimati greske. Alfa testovi se sprovode u kontrolisanim zivotnim sredinama.

Beta testiranje se vrsi u jednoj ili vise kupaca na lokacijama krajnjeg korisnia softvera. Za razliku od alfa testiranja, programmer generalno nije prisutan.

Zbog toga beta test je “uzivo” primena softvera u okruzenju koji se ne moze kontrolisati od strane programera. Korisnicka evidencija svih problema(stvarne ili zamisljene) koji se pojavljuju u toku beta testiranja u redovnim intervalima. Kao rezultat problema prijavljenih tokom testova beta, softver inzenjeri modifikuju a zatim pripreme softverski proizvod za bazu kupca.

Testiranje sistema

Na pocetku ove knjige, mi smo istakli cinjenicu da je softver samo jedan od vecih elemenata baziran na kompijuterskom sistemu. Konacno, softver je inkorporiran sa drugim elementima sistema ( npr, hardver, ljudi, informacija) i niz sistemskih integracija i validacija koji testiranje sprovode. Ovi testovi ne spadaju u krug procesa softvera i ne vode ga samo softverski inzenjeri. Medjutim, koraci predizeti u toku dizajniranja i testiranja moze uveliko poboljsati verovatnocu uspesnosti softvera za integraciju u veci sistem.

Problem klasicnog testiranja sistema je lako pokazujuci. Ovo se desava kada se greska otkrije i svaki element sistema krivi druge za nastali problem. Kada se dese takve gluposti, softverski inzenjer treba da predvidi potencijalni

problem interfejsa (1) staza greske koji testira sve informacije koji dolaze iz drugih elemenata sistema, (2) ponasanje serijala testiranja koji simulira lose podatke ili druge potencijalne greske na softverski interfej, (3) zapis rezultata testiranja da se koristi kao dokaz ako pokazujuci ne dodje, i (4) ucestvuju u planiranju i projektovanju sistema testova kako bi se osiguralo da je softver testiran adekvatno.

Testiranje sistema je zapravo niz razlicitih testova cija je osnovna svrha da u potpunosti ostvaruje kompijuterski baziran sistem. Iako svaki test ima drugaciju namenu, sav posao je da se proveri da li su elementi sistema pravilno integrisani. U odeljcima koji slede, mi smo tumacili vrste sistema testova [bei84] koijk su zasnovani na softverski sistem.

Testiranje bezbednosti

Bilo koji racunar ciji je sistem zasnovan da upravlja osetljivim informacijama je uzrok akcije da nepropisno koristi pojedinca, je meta nepravilnog ili nezakonitog prodora. Prodor obuhvata sirok spektar aktivnosti: hakera koji pokusava da prodre u sistem; nezadovoljni radnici koji pokusavaju da se osvete; neposteni pojedinci koji pokusavaju da prodru u nezakonite podatke i ostvare neku dobit.

Bezbednost testiranja je zasnovan na tome da proverite da li mehanizmi zastite koji su ugradjeni u sistem zaista stite od nepravilnih prodora. Da citiram Beizer[BEI84]: “Bezbednost sistema mora, naravno, da se testira nepredvidivo ali takodje mora da se testria sa boka i od pozadi napada.

Tokom testiranja bezbednosti, ispitivac igra ulogu(e) pojedinca koji zeli da prodre u sistem. Sve ide. Ispitivac moze pokusati da otkrije lozinke na neki spoljni nacin; moze da napada sistem sa prilagodjenim softverskim dizajnom do poremecaja svih odbrambenih sistema koji su izgradjeni, mogu da nadvladaju sistem, a time uskracuju usluge drugima, mozda namerno izazove sistemske greske, u nadi da prodre tokom oporavka sistema, moze pretrazivati kroz nesigurne podatke, s’nadom da ce pronaci kljuc za unos u sistem.

S’ obzirom na dovoljno vremena i resursa, dobro bezbedonostno testiranje ce konacno prodreti u sistem. Uloga sistema dizajnera je da kosta vise od prodora i vrednosti informacija koje ce dobiti.

Stresno testiranje

Tokom prethodnih poglavlja testiranja softvera, crno-bela kutija i kutija tehnike daju rezultat i detaljne procene normalne funkcije i performance programa. Stres testovi su dizajnirani da se suoce sa programima i nenormalnim situacijama. U sustini, ispitivac koji obavlja stresno testiranje, pita:”koliko mozemo uraditi sto pre ovih?”

Stresno testiranje sistema se izvrsava na nacin koji zahteva resurse u abnormalne kolicine, ucestalos, ili zapreminu. Na primer, (1) posebni testovi

mogu biti dizajnirani da generisanje prekida traje deset sekundi, kada se jedan ili dva prosecna stopa, (2) ulaz brzine prenosa moze biti povecan za red velicine da bi se lakse odredilo kako funkcionise unos, (3) test slucajeva koji zahtevaju maksimalne memorije ili druge resurse se izvrsavaju, (4) u probnim slucajevima koji mogu izazvati mlacenje u virtuelnom operativnom sistemu su dizajnirani, (5) probni slucajevi koji mogu izazvati preterano lova za disk podatke koji su napravili. U sustini, ispitivac pokusava da probije program.

Varijacija strestnog testiranja je tehnika koja se zove osetljivost testiranja. U nekim situacijama je veoma mali opseg podataka sadrzanih u okvirima vazecih podataka za program koji moze izazvati ektremne cak i pogresne, ali i duboke obrade degradacije. Testiranje osetljivosti pokusava da otkrije kombinacije podataka u okviru vazecih unosa klase, koje mogu izazvati nestabilnost ili nepravilne prerade.

Testiranje

U realnom vremenu ugradjenih sistema, softvera koji obezbedjuju potrebne funkcije, a koji nisu u skladu sa zahtevima performanis je neprihvatiljivo. Testiranje performansi je dizajniran za testiranje performansi izvrsavanja softvera u kontekstu integrisanog sistema. Testiranje se javlja u svim koracima u testiranju procesa. Cak in a nivou jedinica, performanse pojedinacnih modula mogu biti kao testovi koji se sprovode. Medjutim, to nije sve dok se svi elementi sistema u potpunosti ne integrisu i dok se prave performanse sistema ne utvrde.

Testovi performansi su cesto u kombinaciji sa testiranjem stresa i obicno zahtevaju obe instrumentacije i hardver i softver. To je cesto potrebo da se izmeri koriscenjem resursa(npr processor ciklusa) na strog nacin. Spoljna instrumentacija moze da pravi izvrsenje po intervalima, registrovane dogadjaje(npr. Prekid) kada do njih dodje, i drzavni uzorak na redovnoj osnovi.

Po instumentalnim sistemima, ispitivanje moze otkriti situacije koje dovode do degradacije i ogucih otkazivanja sistema.

Umetnost otklanjanja gresaka

Testiranje softvera je process koji moze da se sistematski planira. Test u slucaju dizajna moze biti sproveden, strategija moze biti definisana, a rezultati se mogu vrednovati protiv propisanih ocekivanja.

Otklanjanje gresaka javlja se kao posledica uspesnog testiranja. To jest, kada se testiranjem otkriju greske, uklanjanje gresaka je process koji daje rezultate u uklanjanju gresaka. I ako otkalnjanje gresaka moze i treba da bude uredan process, i dalje je vecim delom umetnos. Softverski inzenjer u ocenjivanju rezultata testa, se cesto suocava sa simptomaticnim pokazateljom softverskih problema. To su uzroci spoljasnje manifestacije greske i unutrasnje koji mozda nemaju ociglednu vezu jednu prema drugom. Za otklanjanje gresaka lose se razume mentalni process koji se spaja sa simptomom.

Proces otklanjanja gresaka

Otklanjanje gresaka nije testiranje, vec se uvek javlja kao posledica testiranja. Pozivajuci na slici 18.8 proces otklanjanja gresaka pocinje izvodjenjem testiranja. Rezultat se procenjuje i nedostatak prepiske izmedju ocekivanog i svatnog ucinka je izasao. U mnogim slucajevima, podaci ne odgovaraju simptomu osnovnom ciji je uzrok jos skriven. Process otklanjanja gresaka pokusava da se podudara sa simptomom sto ga izaziva, i time dovodi do ispravljanje greske. Process otklanjanja gresaka ce uvek imati jedan od dva ishoda: (1) izazivace se i ispraviti, ili (2) izazova nece biti. U drugom slucaju, lice obavljanje otklanjanje gresaka moze da izazove osumnjiceni, dizajner u tom slucaju testira za proveru u svakom slucaju da bi pomogao u otklanjanju sumnje, i radce na ispravku greske na iterativni nacin.

Zasto je tako tesko otkloniti greske? U verovatnoci, ljudska psihologija ima vise veze sa odgovorom od softverske tehnologije. Medjutim, nekoliko karakteristika gresaka, daju nekakve dokaze:

1. Simptom i razlog mogu biti geografski udaljeni. To jest, symptom se moze pojaviti u jednom delu programa, a uzrok se moze nalaziti u drugoj lokaciji. Visoko u sprezi struktura programa (Poglavlje 13) pogorsava situaciju.

2. Kada se druga greska ispravi, symptom moze da nestane( privremeno)

3. Symptom moze zapravo biti uzrokovan bez greske.4. Simptom moze biti izazvan ljudskom greskom kojoj nije lako

uci u trag

5. Simptom moze biti i posledica ogranicenja problema, a ne obrada problema

6. To moze biti tesko da se precizno reprodukuje u uslovima unosa ( na primer, u realnom vremenu u kojoj je ulaz narucivanja neodredjen)

7. Simptom moze biti isprekidan. Ovo je narocito uobicajeno u ugradjenim sistemima koji cine par hardvera i softvera povezanih.

8. Simptom moze biti uzrok da se preko nekog broja distribuira, a tada zadaci rade na razlicitim procesorima[CHE90].

U toku otklanjanja gresaka, nailazimo na greske koje se krecu od blagih ali dosadnih pa sve do katastrofalnih, koje nanose tesko ekonomskih ili fizickih ostecenja. Kao posledica gresaka povecanja iznosa, ulaze se da se pronadje uzrok tog povecanja. Cesto, ponekad pritisak snage softvera trazi da programer popravi jos jednu gresku, a u isto vreme presdtavi jod dve.

Psiholoska razmatranja

Nazalost, cini se da postije neki dokazi da je otkrivanje gresaka urodjena osobina ljudi koja ih cini junacima. Neki ljudi su dobri u tome a neki nisu. Iako je experimentalni dokaz za otkrivanje greske otvoren za mnoge interpretacije, velika neslaganja za otklanjanje gresaka su prijavljana programerima sa istim obrazovanjem i iskustvom.

Kometnarisuci ljudskim aspektima otkrivanje gresaka, Shneiderman[SHN80]:

Otklanjanje gresaka je jedna od vise frustrirajucih delova programa. Ona ima elemente resavanja za prebleme, mozgalice, zajedno sa dosadnim priznanjima da ste najverovatnije napravili gresku. Povecanje anksioznosti i nespremnost da se prihvati mogucnost greske, zadaje poteskoce. Srecom, postoji veliki olaksanja i smanjenja napetosti, kada je greska na kraju ispravljena.

Iako je mozda tesko “nauciti” otklanjati greske, brojevi pristupa problemu mogu biti predlozeni. Trebamo ispitati ove u sledecm odeljku.

Proces otklanjanja greske

Bez obzira na pristup koji je uzet, za otklanjanje greske ima se jedan motiv: da se pronadje i tacno uzrokuje softverska greska. Cilj se ostvaruje kombinacijom sistema evolucije, intuicije, i srece. Bradley pBRa85] opisuje pristuo za otklanjanje greske na sledeci nacin:

Otklanjanje greske je jednostavnja primena naucnih metoda koja je razvijena pre 2500 godina. Osnova za otklanjanje gresaka je da pronadjete izvor problema(uzrok) kroz rad hipoteze koji predvidja nove vrednosti da se ispita.

Uzmi jednostavno primer obicni, ne softverski: lampa u mojoj kuci ne radi. Ako nista u kuci ne radi, razlog mora biti u glavnim prekidacima ili van njega, pogledati da li i komsije imaju istih problema, da li nemaju struje. Uzmemo i prikljucimo osumnjiceni deo lampe u uticnicu i ako radi, onda je aparat osumnjicen, dakle, ide smenjivanje hipoteze i testa.

U principu, tri kategorije za otklanjanje gresaka mogu biti predlozene [MYE79]:

(1) Brutalnu silu, (2) vracanje unazad, i (3) uzrok eliminacije.Grubom silom kategorija za otklanjanje gresaka je verovatno najcesci i

najmanje efikasan medot za izolovanje softverske greske. U kranjem slucaju, metod grube sile za otklanjanje greske se primenjuje kada sve ostalo zakaze. Koriscenje “neka racunar pronadje gresku” filozofije, bacene memorije su preduzete, otvoreni tragovi se pozivaju, a program se ucitava sa funkcijom zapisivanja izjavama. Nadamo se da negde u bari informacija koje je proizvela gresku, mozemo naci trag do uzroka greske. Iako nam masa informacija proizvedenih na kraju, moze pomoci da dodjemo do uspeha, ona cesce uzima nas sav trud i gubimo vreme. Pre svega najpre se mora promisliti za sve.

Povratak na staro, je prilicno uobicajena metoda za uklanjanje gresaka koja moze uspesno biti obavljena u malim programima. Pocetak na mestu gde je simptom otkriven, moze nas uputiti na kraju gde je uzrok greske otrkiven. Nazalost, broj mogucnosti se povecava, broj uzroka moze da bude zaista veliki. Treci pristup za otklanjanje greske –uzrok eliminacije- se manifestuje indukcijom ili odbitak uvodi u koncept binarne podele. Podaci vezani za greske, pojave se da organizirano izoluju potenciajne uzroke. “Uzrok hipoteza” je osmisljenj i navedeni podaci se koriste da dokazu ili opovrgnu hipotezu.

Alternativno, spisak svih mogucih uzroka je razvijen i testovi se sprovode za otklanjanje svake greske. Ako pocetni testovi ukazuju na to da odredjeni uzrok hipoteza ukazuje na nadu da ce se skloniti greske, podaci su rafinirani u pokusaju da se izoluju greske.

Svaki od ovih pristupa za otklanjanje greske, moze biti alatkom za otklanjanje greske. Mi mozemo primeniti sirok spektar za otklanjanje greske kompajlera, i dinamicno otklanjati greske pomagala(“markeri”), automatski test generatora, memorije deponije, i unakrsne fererence karte.

Medjutim, alatke nisu zamena za pazljivu procenu na osnovu kompletnog softvera i nisu dizajnirane da se dokument jasno vidi iz izvornog koda.

Svaka diskusija o nacinu pristupa otklanjanju gresaka je nepotpuna i treba napomenuti da se nista ne treba preduzimati od dobrih saveznika. Svako od nas moze se zbuniti u roku od nekoliko sati ili dana, ako trazi uporno gresku. Pomoc kolege u tom trenutku je najpotrebnija, zato sto moze biti od velike pomoci. Trenutno greska je otkrivena. Smesno zadovoljstvo, nas kolega otvori odredjene teme, znajuci da smo frustrirani radom dugim, i samim tim moze da doprinese

puno. Konacno maximum za otklanjanje greske moze biti:”Kada sve ostalo ne uspe, traziti pomoc!”

Kada se greska nadje, ona mora biti ispravljena. Ali kao sto smo vec primetili, korekcija otkrivene greske moze nas uvesti u druge ne otkrivene greske i tako bi naneli vise stete nego koristi samom sebi. Van Vleck[VAN89] ukazuje na tri jednostavna pitanja koja svaki softverski inzenjer treba pitati pre nego sto pocne uklanjati gresku:

(1) Da li se uzrok greske reprodukuje u drugom delu programa?U mnogim situacijama, program je izazvan pogresno, zato sto defekt ne

sme izazvati da se reprodukuje na nekom drugom mestu. Eksplicitno razmatranje logickih obrazaca moze dovesti do otkrica drugih gresaka

(2) Ono sto “sledeca greska” moze izazvati, treba popraviti samo to?

Pre nego sto je napravljena korekcija, izvorni kod treba da se proceni i da se proceni struktura podataka. Ako se krene ispraviti greska, treba preduzeti i videti dali je bilo kakva promena zadesila ostale delove programa.

(3) Sta je to sto smo mogli preduzeti da sprecimo gresku odmah u startu?

Ovo pitanje je prvi korak ka uspostavljanju statickih kvaliteta softvera pristupu osigranja(poglalje 8). Ako se tacan proces, kao i proizvod greske otkrije, greska ce biti otklonjena iz tekuceg programa i moze se eliminisati iz svih buducih programa.

Rezime

Najveci procenat u testiranju oduzima proces testiranja softverskih racuna. Ipak, mi smo tek poceli da razumemo suptilnost sistematskog plraniranja testiranja i kontrole izvrsenja.

Cilj testiranja softvera je da otkrije greske. Da bi se ispunio ovaj cilj, potrebno je ostvariti nekoliko koraka tetriranja jedinice, integracija, validacua i sistem testovi koji se planiraju izvrsiti. Jedinica i integracija testiranja, koncentrisani su na funkciolanim komponentama verifikovani u programsku strukturu. Validacija testiranja pokazuje pracenje softverskih zahteva i potvrdjuje testiranje sistema softvera nakon sto je ukljucen u veci sistem.

Svaki korak testiranja postize se kroz niz sistematskih tehnickih testiranja koje trebaju pomoci u dizajniranju slucajeva testiranja. Uz svaki korak testiranja, nivo apstrakcije za softver se smatra prosirenim.

Za razliku od testiranja( sistematski, aktivno planiranje) otklanjanje gresaka se mora posmatrati kao vestina. Pocevsi sa simptomima indikacije problema, za otklanjanje gresaka potrebno je pronaci uzrok greske. Od mnogo resursa na raspolaganju u toku otklanjanje gresaka, najvise vredi savet drugih clanova osoblja softverskog inzenjerstva.

Uslov za bolji kvalitet softvera zahteva sistematski pristup testiranja. Da citiram Dunn and Ullman[DUN82], ono sto je potrebno je opsta strategija, koja

obuhvata prostor strateskog testiranja, sasvim namerno, kao u svojoj metodologiji na kojoj su zasnovani sistematski razvoji i projektovanje.

U ovom poglavlju smo ispitivali prostor strateskog testiranja, s’obzirom na korake koji imaju veliku verovatnocu da prevazidje cilj testiranja: da pronadje i ukloni greske na pravilan i efikasan nacin.

REFERENCE

[BEI84] Beizer, B., Software System Testing and Quality Assurance, Van Nostrand-

Reinhold, 1984.[BOE81] Boehm, B., Software Engineering Economics, Prentice-Hall,

1981, p. 37.[BRA85] Bradley, J.H., "The Science and Art of Debugging,"

Computerworld, August19, 1985, pp. 35–38.[CHE90] Cheung, W.H., J.P. Black, and E. Manning, "A Framework for

DistributedDebugging," IEEE Software, January 1990, pp. 106–115.[DUN82] Dunn, R. and R. Ullman, Quality Assurance for Computer

Software, McGraw-Hill, 1982, p. 158.[GIL95] Gilb, T., “What We Fail to Do in Our Current Testing Culture,”

TestingTechniques Newsletter, (on-line edition, ttn@soft.com), Software

Research, January1995.[MCO96] McConnell, S., “Best Practices: Daily Build and Smoke Test”,

IEEE Software,vol. 13, no. 4, July 1996, 143–144.[MIL77] Miller, E., "The Philosophy of Testing," in Program Testing

Techniques, IEEEComputer Society Press, 1977, pp. 1–3.[MUS89] Musa, J.D. and Ackerman, A.F., "Quantifying Software

Validation: When toStop Tes ting?" IEEE Software, May 1989, pp. 19–27.[MYE79] Myers, G., The Art of Software Testing, Wiley, 1979.[SHO83] Shooman, M.L., Software Engineering, McGraw-Hill, 1983.[SHN80] Shneiderman, B., Software Psychology, Winthrop Publishers,

1980, p. 28.

[VAN89] Van Vleck, T., "Three Questions About Each Bug You Find," ACM Software

Engineering Notes, vol. 14, no. 5, July 1989, pp. 62–63.[WAL89] Wallace, D.R. and R.U. Fujii, "Software Verification and

Validation: AnOverview," IEEE Software, May 1989, pp. 10–17.[YOU75] Yourdon, E., Techniques of Program Structure and Design,

Prentice-Hall, 1975.

Razmisljati i ukazati na probleme

1. Svojim recima opisati razliku izmedju verifikacije i validacije. Da li obe metode koriste slucaj ispitivanja, projektovanja i testiranja strategije?

2. Liste problema koje mogu biti nezavnisne u vezi sa stvaranjem grupe testiranja. Da li su ITG i SQA grupe sacinjene od isto naroda?

3. Da li je uvek moguce da se razvije strategija za testiranje softvera koji koristi redosled testiranja opisane u clanu 18.1.3? Kakve komplikacije mogu nastat iz ugradjenog sistema?

4. Ako mozete da izaberete samo tri metode testiranja dizajna kucista, koje bi to metode bile i zasto?

5. Zasto je veoma tesko da se sjedine moduli jedinica testiranja?

6. Koncept za borbu protiv otkrivanja gresaka je izuzetno efikasan nacin da se obezbedi pomoc kada se greska otkrije i da se ukloni:

7. Razviti skup smernica za borbu protiv otkrivanja greske8. Diskutovati o presdnosti koriscenja tehnike9. Razmatrati nedostatke