U ovoj lekciji će se obrađivati aktivnost planiranog procesa testiranja softvera na nivou integracije strukture softverskog proizvoda kroz:

• Strategije integracionog testiranja
• Integracije odozdo nagore
• Integracije odozgo nadole
• Integrisanje po principu „velikog praska"
• Sendvič integracije
• Poređenje različitih integracionih strategija

Integraciono testiranje

Kada se uverimo da pojedinačne komponente pravilno rade i zadovoljavaju naše ciljeve, ugradjujemo ih u sistem koji radi. Integracija se planira i koordinira na način da kada dođe do nepravilnosti unapred postoji orijentir u vezi sa uzrokom. Osim toga, redosled kojim se komponente testiraju utiče na izbor slučajeva i alata. Kod većih sistema su neke komponente možda još u fazi kodiranja, druge u fazi jediničnog testiranja, a neke grupe komponente se testiraju zajedno. Strategija utiče ne samo na vremenski raspored integracije i redosled kodiranja, već, takodje, i na troškove i sveobuhvatnost testiranja.

Sistem se ponovo posmatra kao hijerarhija komponenti, gde svaka komponenta pripada nekom sloju dizajna. Moguće je početi od vrha i napredovati nadole tokom testiranja, moguće je ići odozdo nagore ili kombinovati oba pristupa.

Integracija odozdo nagore

Jedan popularan pristup za spajanje komponenti za testiranje većeg sistema naziva se testiranje odozdo nagore. Kada se koristi ovaj metod, prvo se jedinično testira svaka komponenta na najnižem nivou hijerarhije sistema. Zatim se testiraju komponente koje pozivaju prethodno testirane komponente. Taj postupak se ponavlja sve dok testiranjem ne budu obuhvaćene sve komponente. Metod odozdo nagore je koristan kada većina komponenti na najnižem nivou predstavlja pomoćne rutine opšte namene koje se pozivaju iz drugih komponenti, kod objektno orijentisanog dizajna ili kada sistem integriše veći broj nezavisnih ponovno iskoristivih komponenti.

Na primer, ako se uzmu komponente i hijerarhija na slici 1. Za testiranje ovog sistema odozdo nagore, prvo testiramo najniži nivo: E, F i G. Pošto komponente koje pozivaju programe najnižeg nivoa nisu spremne, piše se poseban kod kao pomoć za integraciju. Rukovalac komponentom je rutina koja poziva određenu komponentu i saopštava joj slučaj. Rukovalac se lako kodira, pošto retko zahteva složenu obradu. Medjutim, potrebno je paziti da se pravilno definiše interfejs rukovaoca i komponente koja se testira. Ponekad se podaci za testiranje mogu automatski predati na jeziku specijalne namene koji olakšava definisanje podataka.

Slika 1. Primer hijerarhije komponenti

U našem primeru, potrebni su nam rukovaoci komponenti za E, F i G. Kada se uverimo da te tri komponente ispravno rade, prelazimo na sledeći viši nivo. Za razliku od komponenti najnižeg nivoa, komponente sledećeg nivoa se ne testiraju pojedinačno. One se kombinuju sa komponentama koje pozivaju (a koje su već testirane). U ovom slučaju, zajedno testiramo B, E i F. Ako se pojavi problem, znamo da je uzrok u B, ili u interfejsu između B i E, ili između B i F, pošto E i F pojedinačno ispravno rade. Da smo zajedno testirali B, E i F bez prethodnog jediničnog testiranja E i F, možda ne bismo mogli tako lako da otkrijemo uzrok problema.

Na sličan način testiramo D sa G. Pošto C ne poziva ni jednu drugu komponentu, testiramo je izolovano. Na kraju testiramo sve komponente zajedno. Na slici 2 prikazan je redosled testiranja i njihove međuzavisnosti.

Slika 2.  Testiranje odozdo nagore

Testiranje odozdo nagore se često kritikuje kod funkcionalno dekomponovanih sistema, jer se komponente najvišeg nivoa, koje su obično najvažnije, poslednje testiraju. Najviši nivo upravlja glavnim aktivnostima u sistemu, dok niži nivoi često obavljaju prizemnije poslove, kao što su ulazne i izlazne funkcije ili izračunavanja koja se ponavljaju. Zato neki projektanti smatraju da se time otkrivanje značajnijih grešaka odlaže do završetka testiranja, budući da se prvo testiraju niži nivoi. Štaviše, ponekad greške na visokom nivou ukazuju na greške u dizajnu; očigledno bi te greške trebalo ispraviti u što je moguće ranijim fazama razvoja, a ne čekati do samog kraja. Na kraju, komponente najvišeg nivoa često kontrolišu vreme i na njega utiču. Teško je testirati sistem odozdo nagore ako u velikom delu obrade u sistemu postoji vremenska zavisnost.

S druge strane, testiranje odozdo nagore je često najprimerenije za objektno orijentisane programe. Objekti se kombinuju jedan po jedan sa objektima ili kolekcijama prethodno testiranih objekata. Poruke se razmenjuju i testiranje obezbeđuje da objekti pravilno reaguju.

Integracija odozgo nadole

Mnogi projektanti više vole pristup odozgo nadole koji je na razne načine suprotan pristupu odozdo nagore. Na najvišem nivou obično imamo jednu kontrolnu komponentu i nju izolovano testiramo. Zatim se komponente koje ona poziva kombinuju i testiraju kao veća celina. Isto se ponavlja dok se ne uključe sve komponente.

Komponenta koja se testira možda poziva drugu koja još nije testirana i zato pišemo lažnu rutinu (stab), program specijalne namene koji simulira aktivnost komponente koja nedostaje. Lažna rutina odgovara na poziv i vraća izlazne podatke tako da postupak testiranja može da se nastavi. Na primer, ako se poziva komponenta koja izračunava sledeću slobodnu adresu, ali ta komponenta još nije testirana, tada lažna rutina može da vraća jednu fiksnu adresu samo da bi testiranje moglo da se nastavi. Kao što važi i za rukovaoca, lažne rutine ne moraju da budu složene niti logički potpune.

Na slici 3 prikazano je kako bi se naš primer sistema testirao odozgo nadole. Najviša komponenta A je jedina koja se testira izolovano, dok su za B, C i D potrebne lažne rutine. Pošto se ona istestira, kombinuje se sa sledećim nivoom pa se zajedno testiraju A, B, C i D. U ovoj fazi testiranja biće potrebne lažne rutine za E, F ili G. Na kraju se testira ceo sistem.

Ako komponente najnižeg nivoa vrše samo ulaz i izlaz, lažne rutine za njih bile bi skoro identične komponentama koje zamenjuju. U tom slučaju se može promeniti redosled integracije tako da se komponente ulaza i izlaza ugrade ranije.
Mnoge prednosti projektovanja i programiranja sistema odozgo nadole važe i za testiranje odozgo nadole. Kada se, primenom dizajna odozgo nadole, funkcije konkretnih komponenti lokalizuju, testiranje odozgo nadole omogućava da se isproba jedna po jedna funkcija, počevši od najvišeg nivoa kontrole, kroz odgovarajuće komponente, do dna. Tako se slučajevi mogu definisati prema funkcijama koje se ispituju. Uz to, bilo koja greška u dizajnu ili pitanje od značaja za fleksibilnost funkcija može da se postavi na početku, a ne na kraju procesa testiranja.

Slika 3.  Testiranje odozgo nadole

Takođe, za testiranje odozgo nadole nisu potrebni programi rukovaoci. S druge strane, pisanje lažnih rutina može da bude teško, pošto one moraju da podrže testiranje svih mogućih uslova. Na primer, ako se pretpostavi da komponenta Z u sistemu za crtanje mapa obavlja izračunavanje na osnovu geografske širine i dužine koje dobija iz komponente Y, specifikacija dizajna određuje da je izlaz iz Y uvek u severnoj hemisferi. Pošto Z poziva Y, u trenutku kada se Z uključuje u testiranje odozgo nadole, Y možda još nije kodiran. Ako napišemo lažnu rutinu koja će davati jedan broj između 0 i 180 da bi se omogućilo testiranje komponente Z, lažna rutina će morati da se promeni, ako se u dizajn uključi i južna hemisfera. To znači da je lažna rutina važan deo testiranja i da njena ispravnost može da ima uticaja na validnost celog testa.

Nedostatak testiranja odozgo nadole jeste potencijalna potreba za velikim brojem lažnih rutina. To se može dogoditi ako najniži nivo sistema sadrži veliki broj rutina opšte namene. Jedan od načina da se taj problem izbegne je mala promena strategije. Umesto da se istovremeno uključuje jedan nivo u celosti, u modifikovanom pristupu odozgo nadole se pre objedinjavanja jedinično testiraju komponente svakog nivoa. Primer sistema koji je naveden ovde može se testirati po modifikovanom pristupu tako što se prvo testira A, zatim B, C i D, i tek tada se te četiri komponente integrišu radi testiranja prvog i drugog nivoa. Zatim se E, F i G testiraju pojedinačno. Na kraju se ceo sistem spaja za testiranje kao na slici 4.

Jedinično testiranje komponenti svakog nivoa uvodi još jednu poteškoću. Za svaku komponentu su potrebne i lažne rutine i programi rukovaoci, što rezultira sa više kodiranja, a time i više potencijalnih problema.

Slika 4.   Modifikovano testiranje odozgo nadole

Integrisanje po principu „velikog praska"

Kada su sve komponente jedinično testirane, mogu se sve sastaviti u konačni sistem i isprobati da li će sve odmah raditi. Myers (1979) to naziva testiranjem „po principu velikog praska", a na slici 5 prikazana je njegova primena na prethodno pomenut primer sistema. Mnogi programeri koriste ovaj pristup kod malih sistema, dok njegova primena na velike sisteme nije praktična. U stvari, pošto testiranje ,,po principu velikog praska" ima niz nedostataka, ono se ne preporučuje ni za jedan sistem. Prvo, za testiranje pojedinačnih komponenti potrebne su i lažne rutine i programi rukovaoci. Drugo, pošto se sve komponente integrišu odjednom, teško je pronaći uzrok bilo koje nepravilnosti. Na kraju, greške u interfejsima je teško razlučiti od ostalih vrsta grešaka.

Slika 5. Testiranje „po principu velikog praska"

Sendvič integracija

Myers 1979. godine kombinuje strategiju odozgo nadole sa strategijom odozdo nagore i tako obrazuje tzv. sendvič testiranje. Sistem se posmatra u tri sloja, kao sendvič: ciljni sloj u sredini, sloj neposredno iznad i sloj neposredno ispod ciljnog. Za gornji sloj se koristi pristup odozgo nadole, a za donji sloj pristup odozdo nagore. Testiranje konvergira prema ciljnom sloju koji se bira na osnovu karakteristika sistema i strukturne hijerarhije komponenti. Na primer, ako sloj na dnu sadrži veliki broj pomoćnih programa opšte namene, ciljni sloj može da bude sloj iznad njega u kojem se nalaze komponente koje koriste pomoćne programe. Na ovaj način se na početku testiranja proverava ispravnost pomoćnih programa testiranjem odozdo nagore. Lažne rutine za pomoćne programe nisu potrebne, pošto se za to mogu upotrebiti sami pomoćni programi. Na slici 6 prikazan je jedan od mogućih redosleda za sendvič integraciju našeg primera hijerarhije komponenti, gde je ciljni sloj u sredini, tj. komponente B, C i D.

Slika 6. Sendvič testiranje

Sendvič testiranje omogućava da se integraciono testiranje obavi u ranim fazama. Ono takođe objedinjava prednosti pristupa odozgo nadole i pristupa odozdo nagore tako što se na početku testiraju kontrolne komponente i pomoćni programi. Medutim, ne vrši se sveobuhvatno testiranje pojedinačnih komponenti pre integracije. Jedna varijacija, modifikovano sendvič testiranje, predviđa testiranje komponenti višeg nivoa pre njihovog spajanja sa ostalima, kao što se vidi na slici 7.

Slika 7. Modifikovano sendvič testiranje

Poređenje različitih integracionih strategija

Izbor integracione strategije ne zavisi samo od karakteristika sistema, već i od očekivanja kupca. Na primer, kupac možda želi što pre da vidi radnu verziju, pa se može prihvatiti strategiju kojom se sistem koji funkcioniše gradi u ranim fazama procesa testiranja. Na taj način, neki programeri još kodiraju dok drugi testiraju, pa se faze testiranja i kodiranja preklapaju. Myers (1979) je sastavio matricu prikazanu u tabeli 1 u kojoj se porede različite strategije testiranja na osnovu nekoliko atributa sistema i potreba kupaca.

Microsoft-ovu integracionu strategiju pokreće tržište, na osnovu potrebe da proizvod bude u funkciji što je moguće pre. Microsoft koristi više malih timova (od po tri do osam učesnika) koji rade paralelno i implementiraju tzv. pristup „sinhronizovati i stabilizovati". U postupku. se naizmenično dizajniraju, grade i testiraju komponente, a kupci se uključuju u postupak testiranja. Svi delovi proizvoda često se integrišu da bi se utvrdilo šta radi ispravno, a šta ne.

Microsoft-ov pristup omogućava timu da menja specifikacije osobina kako se projektanti postepeno sve bolje upoznaju sa mogućnostima i potrebama proizvoda. Ponekad se skup osobina promeni i do 30%. Proizvod i projekat se podele na delove na nivou osobina, a za njihovu realizaciju se zadužuju različiti timovi. Zatim se definišu kontrolne tačke, na osnovu klasifikacije osobina na esencijaine, poželjne i manje bitne. Timovi sinhronizuju rad tako što svakodnevno grade proizvod i pronalaze i ispravljaju greške, kao šta je prikazano na slici 8. Tako se esencijalna svojstva prva razvijaju i integrišu, a svaka kontrolna tačka ima i „rezervno vreme" za prevazilaženje neočekivanih komplikacija i kašnjenja. Ako vreme isporuke mora da se skrati, manje bitna svojstva se isključuju iz projekta.

Bez obzira na izabranu strategiju, svaka komponenta se u cilju testiranja samo jednom ugrađuje. Osim toga, komponenta ne bi nikada smela da se menja radi olakšavanja procesa testiranja. Lažne rutine i programi rukovaoci su zasebni novi programi, a ne privremene izmene postojećih programa.

Slika 8. Microsoftov pristup sinhronizovanja i stabilizovanja

Dodaj komentar Sviđa mi se - (0) Ne sviđa mi se - (0)    

Ime Nick Email Title Sigurnosni kod

CommentText

• Testiranje u fazi integracije 1

• Testiranje u fazi integracije 2

• Testiranje u fazi integracije 3