109.451.880 pregleda lekcija
26.973 pregleda lekcija danas
490.649 pokretanja testova
1.538.118 pregleda pdf dokumenata
109.451.880 pregleda lekcija
26.973 pregleda lekcija danas
490.649 pokretanja testova
1.538.118 pregleda pdf dokumenata
U ovoj lekciji će se obrađivati:
U ovoj lekciji će se razmatrati tehnike detekcije grešaka koje obezbeđuju smanjivanje broja grešaka u samom programskom kodu. Najčešće se svodi na ispitivanje tj. testiranje najniže softverske komponente, modula pa se u skladu sa tim i naziva jedinično testiranje.
Pre nego što kupcu predamo sistem za koji verujemo da ispravno funkcioniše, neophodno je obaviti više vrsta testiranja. Neki testovi zavise od onoga što se testira: komponente, grupe komponenti, podsistetmi ili ceo sistem. Drugi testovi zavise od onoga šta želimo da saznamo: Da li sistem radi u skladu sa projekto, zahtevima, očekivanjima kupca? Neka od ovih pitanja će biti razmotrena.
Kada se razvija veliki sistem, testiranje obično zahteva više faza. Prvo se zasebno testira svaka programska komponenta, nezavisno od ostalih delova sistema. Takvim testiranjem, koje se naziva testiranje modula ili jedinično testiranje proverava se da li pojedinačne komponente ispravno funkcionišu sa svim očekivanim tipovima ulaza, u skladu sa dizajnom komponente. Kad god je to moguće, jedinično testiranje se vrši u kontrolisanom okruženju tako da tim za testiranje može komponenti koja se testira da predaje unapred definisan skup podataka, i da posmatra izlazne akcije i rezultate. Osim toga, tim za testiranje proverava unutrašnju strukturu podataka, logiku i granične uslove za ulazne i izlazne podatke.
Kada se završi jedinično testiranje skupa komponenti, sledeći korak je proveravanje da li su interfejsi između komponenti pravilno definisani i realizovani putem aktivnosti testiranja softvera koje se u literaturi naziva integraciono testiranje. lntegraciono testiranje je postupak proveravanja da li sistemske komponente sarađuju kao što je opisano u specifikacijama dizajna sistema i programa.
Pošto se uverimo da se između komponenti informacije prenose u skladu sa dizajnom, testiramo sistem da bismo proverili ima li on željenu funkcionalnost. Funkcionalnim testiranjem se proverava da li integrisani sistem zaista izvršava funkcije opisane u specifikaciji zahteva. Kao rezultat dobija se sistem koji funkcioniše.
Treba imati u vidu da su zahtevi dokumentovani na dva načina: prvo u terminologiji kupca, a nakon toga u formi skupa softverskih i hardverskih zahteva namenjenih projektantima i programerima. Funkcionalni test predstavlja poređenje sistema koji se gradi sa funkcijama opisanim u specifikacijama zahteva kupca. Nakon toga se, u sklopu testiranja performansi, sistem se poredi sa ostatkom hardverskih i softverskih zahteva. Kada se to testiranje uspešno obavi u stvarnom radnom okruženju kupca, dobija se validiran sistem.
Po okončanju testiranja performansi, projektanti i programeri su uvereni da sistem funkcioniše u skladu sa njihovim shvatanjem opisa sistema. Sledeći korak je sastanak sa kupcem na kojem proveravamo da li sistem funkcioniše u skladu sa očekivanjima kupca. Zajedno sa kupcem obavlja se završni test prihvatanja, u kojem se proverava usklađenost sistema sa opisom zahteva kupca. Kada se obavi završni test, prihvaćeni sistem se instalira u okruženje u kome će se koristiti; konačni instalacioni test potvrduje da li sistem i dalje ispravno funkcioniše.
Na slici 1 ilustrovan je odnos između koraka testiranja. Bez obzira na veličinu sistema koji se testira, da bi se proverilo njegovo pravilno funkcionisanje, potrebne su sve opisane vrste testiranja.
Slika 1. Koraci testiranja
Programeri početnici nisu navikli da posmatraju testiranje kao proces otkrivanja grešaka u svim aktivnostima projektovanja softvera. U fazi studiranja pišu se programi prema speciflkacijama koje se dobijaju od nastavnika. Po završenom dizajniranju programa, piše se kod i prevodi se da bi se utvrdilo postoje li neke sintaktičke greške. Pri predaji programa na ocenjivanje, obično se nastavniku predaje listing programa, podaci koji su se koristili kao probni ulaz i eventualni izlaz u kojem se vidi kako je program obradio ulazne podatke. Kod, ulaz i izlaz, zajedno, predstavljaju dokaz da kod pravilno radi, a obično se biraju ulazni podaci koji će potvrditi predavaču da kod funkcioniše kao što je traženo u zadatku.
Programi koji se prave na samom početku programerske karijere verovatno se osmatraju samo kao rešenje jednog problema, a možda se neće uzeli u obzir i sam problem. Ako je to slučaj, podaci za testiranje se biraju tako da se potvrde rezultati u specijalnim slučajevima, a ne da bi se dokazalo odsustvo grešaka. Tako napisan program služi kao dokaz početne programerske veštine. Zbog toga se kritika programa psihološki doživljava kao kritika sposobnosti programera početnika. Testiranje kao dokaz ispravnosti programa služi da bi se nastavniku pokazalo stečeno znanje.
Međutim, kada se razvija sistem za potrebe kupaca, njih ne zanima da li sistem pravilno funkcioniše u nekim situacijama. Njih daleko više zanima mogu li da budu sigurni da će sistem pravilno funkcionisati u svim situacijama. Zato bi cilj svakog projektanta-programera trebalo da bude otkrivanje što više grešaka bez obzira na to gde se greške nalaze i bez obzira na to ko ih je napravio. Za povređena osećanja i sujetu nema mesta kada se u procesu razvoja otkriju greške. Zbog toga su mnogi softverski inženjeri pristalice bezličnog programiranja gde se programi posmatraju kao komponente većeg sistema, a ne kao vlasništvo onih koji su ih napisali. Kada se otkrije greška ili kada dođe do otkaza, depersonalizovani razvojni tim se bavi ispravljanjem greške, a ne prebacivanjem krivice na konkretnog izvršioca.
Čak i kada se sistem razvija bezličnim pristupom, ponekad je teško potisnuti lična osećanja iz procesa testiranja. Zato se za testiranje sistema često koristi nezavisan tim za testiranje. Na taj način se izbegava konflikt izmedu vlastitog osećanja odgovornosti za greške i potrebe da se pronađe što više grešaka.
Osim toga, postoje dodatni argumenti u prilog nezavisnog tima. Prvo, moguće je da se nenamerno unesu greške prilikom tumačenja dizajna, određivanja programske logike, pisanja dokumentacije ili implementiranja algoritama. Jasno je da se program ne bi dao na testiranje kad bi se mislilo mislili da on funkcioniše u skladu sa specifikacijama. Ali možda nam je kod previše blizak da bismo bili objektivni i prepoznali suptilnije greške.
Osim toga, nezavisni tim za testiranje može da učestvuje u pregledu komponente tokom celokupnog razvoja. Tim može da učestvuje u pregledima zahteva i dizajna, može pojedinačno da testira komponente koda, a takode i ceo sistem dok se on integriše i daje kupcima na prihvatanje. Na taj način, testiranje se može obavljati istovremeno sa kodiranjem; tim za testiranje može da testira i sklapa komponente čim se one završe, dok programeri za to vreme i dalje kodiraju preostale komponente.
Pre nego što se pažljivo razmotri jedinično testiranje, treba pomenuti filozofiju na koju se testiranje oslanja. Kako testirate komponente, grupu komponenti, podsisteme ili sistem, pogled na predmet testiranja (tj. komponentu, grupu, podsistem ili sistem) može da utiče na način izvođenja testa. Ako se predmet testiranja posmatra spolja kao zatvorenu kutiju, ili crnu kutiju (eng. Blackbox) sa nepoznatim sadržajem, prilikom testiranja se ubacuju podaci u zatvorenu kutiju i beleže se dobijeni rezultati. U tom slučaju cilj testiranja jeste da se potvrdi da su prosleđeni svi tipovi ulaznih podataka i pri tome dobijeni očekivani rezultati. Ova vrsta testiranja koja se u literaturi naziva testiranje po metodu crne kutije ima svoje prednosti i mane. Očigledna prednost je to što je zatvorena kutija oslobođena brige o ograničenjima koja nameće unutrašnja struktura i logika predmeta testiranja. Međutim, nije uvek moguće ceo test izvršiti na taj način. Na primer, ako se pretpostavi da jedna jednostavna komponenta prihvata kao ulaz tri broja a, b i c i kao rezultat daje dva rešenja jednačine:
ax2 + bx + c = 0
ili poruku „nema realnih rešenja". Komponentu nije moguće testirati tako da joj se podnesu sve moguće uređene trojke (a, b, c). U tom slučaju će tim za testiranje možda izabrati reprezentativne podatke za testiranje da bi pokazao da se sve moguće kombinacije pravilno obrađuju. Na primer, mogu se izabrati podaci tako da imamo sve kombinacije pozitivnih, negativnih vrednosti i nule za a, b i c. Ukupno dvadeset sedam mogućnosti. Ako se dovoljno poznaje rešavanje kvadratnih jednačina, mogu se birati vrednosti takve da diskriminanta b2 - 4ac u svakoj od tri klase bude: pozitivna, negativna ili jednaka nuli. (U tom slučaju, samo se prepostavlja kako je komponenta implementirana.) Medutim, čak i kada test za sve razmatrane klase ne otkrije nijednu grešku, ne postoji nikakva garancija da komponenta stvarno ne sadrži greške. Komponenta još uvek može u nekom konkretnom slučaju da da pogrešan rezultat, zbog finesa kao što su greške u zaokruživanju ili neusklađeni tipovi podataka.
Za neke predmete testiranja, testerski tim ne može da napravi skup reprezentativnih slučajeva koji dokazuju pravilno funkcionisanje u svim situacijama.
Za prevazilaženje ovog problema može se posmatrati predmet testiranja kao otvorenu kutiju (koja se ponekad naziva i belom kutijom (eng. whitebox). Tada možemo koristiti unutrašnju strukturu predmeta testiranja u cilju sprovođenja različitih testova. Na primer, mogu se osmisliti testovi tako da se izvrše sve naredbe ili svi tokovi kontrole unutar komponente, kako bi bilo potvrđeno da predmet testiranja ispravno radi. Međutim, ta vrsta pristupa, koja se u literaturi naziva testiranje po metodi bele kutije, može da bude nepraktična.
Na primer, komponenta sa mnogo grananja i petlji sadrži veliki broj putanji koje treba proveriti. Čak i sa relativno jednostavnom logičkom strukturom, teško je temeljno testirati komponentu sa značajnim brojem iteracija ili rekurzija. Na slici 2 se vidi da je logika komponente tako postavljena da se petlja izvršava nm puta.
Slika 2. Primer logičke strukture
Ako su i n i m svaki jednaki 100.000, primer koji se testira bi trebalo da se izvrši deset milijardi puta da bi prošao sve logičke putanje. Mogla bi se usvojiti strategija testiranja u kojoj se petlja izvršava samo nekoliko puta i pri tome proveriti manji broj relevantnih slučajeva, koji će biti reprezentativni za ceo skup mogućnosti. U ovom primeru se može izabrati jedna vrednost za I koja je manja od n, drugu vrednost koja je jednaka n i još jednu koja je veća od n. Slično tome, može se ispitati J koje je manje od m, jednako m i veće od m i njihove kombinacije sa kombinacijama vrednosti I. U opštem slučaju strategija može da se zasniva na podacima, strukturi, funkciji ili nekim drugim kriterijumima.
Prilikom donošenja odluke o načinu testiranja, ne mora se birati pristup otvorene ili zatvorene kutije. Testiranje po modelu zatvorene kutije može se posmatrati kao jedna, a testiranje po modelu otvorene kutije kao druga krajnost sveukupnog prostora testiranja. Sve filozofije testiranja padaju negde izmedu te dve krajnosti. U svakom slučaju, vidi se kako se u nekim pristupima, kao što je pristup sa strukturom kutije, kombinuje više tačaka iz kontinuuma da bi se komponenta obradila iz više uglova. Uglavnom, izbor filozofije testiranja zavisi od više faktora, uključujući i:
Kako treba da početi ako sekao cilj postavi pronalaženje grešaka u komponentama? Postupak je sličan onome koji se koristili kada se na predavanjima testiraju programi. Prvo se isoita kod tako što se pročita uz traženje grešaka u algoritmu, podacima i sintaksi. Može se čak uporediti kod sa specifikacijama i dizajnom da bi se uzeli u obzir svi relevantni slučajevi. Zatim se kod prevodi i uklanjaju se preostale sintaktičke greške. Na kraju, prave se slučajeve za testiranje da li se ulaz pravilno konvertuje u željeni izlaz. Jedinično testiranje ide tačno ovim putem.
Copyright © LINK group. Sva prava zadržana.
office@link.co.rs, +381.11.7856 140, +381.11.7856 100
Cara Dušana 34, 11080 Zemun, Beograd, Srbija
Powered by LINK CMS.