Documenti di Didattica
Documenti di Professioni
Documenti di Cultura
Testiranje - Softvera Skripta
Testiranje - Softvera Skripta
Testiranje - Softvera Skripta
Senad Ibraimoski
mi08247@alas.matf.bg.ac.rs
Testiranje .............................................................................................................................................. 3
2.1
2.2
Dizajn testova................................................................................................................................ 6
2.3
Izvravanje testova........................................................................................................................ 6
2.4
Akteri ..................................................................................................................................................... 7
3.1
Tester ............................................................................................................................................ 8
3.2
3.3
3.4
primer.......................................................................................................................................... 12
Zakljuak ..................................................................................................................................................... 14
7
Reference ............................................................................................................................................ 15
Abstrakt
Testiranje je veoma vana aktivnost u razvoju softvera koja je posebno dobila na znaaju kada je vrednost
softvera poela da raste. Greke u softveru koji je vredan nekoliko miliona dolara mogu prouzrokovati
ogromne novane tete, tako da se moraju otkloniti to je mogue ranije. Zbog toga se u poslednje vreme ne
tedi na aktivnostima testiranja. Postepeno testiranje postaje aktivnost koja je vana kao i sam razvoj softvera
tako da je potrebno ozbiljno prii ovoj temi. Meutim, softverski timovi esto ne shvataju proces testiranja i
sloenost uloga koje postoje u procesu testiranja. esto se smatra da su testeri manje-vie sporedno osoblje
koje eka da se softverski sistem napravi, dobije sistem i onda rade sa njim ta god im je volja kako bi pronali
sve probleme. Meutim, proces testiranja je znatno sloeniji, sa ozbiljnim planovima, strukturom test tima i
metodologijom rada. Ovaj rad Vas uvodi u pojam testiranja I daje najbitnije razlike izmedju manuelnog i
automatskog testiranja softvera.
1 TESTIRANJE
Konkretno, u izradi softvera testiranje predstavlja pokuaj da se pronau greke u softveru koji je napravljen.
Softver je implementiran prema korisnikim zahtevima kojima se reava neki realni problem ili se kreira neka
korisna funkcionalnost koja predstavlja neto to je potrebno krajnjim korisnicima. Kada se implementira,
softver moe u veoj ili manjoj meri da odgovara originalnim zahtevima prema kojima je i napravljen.
Svako ponaanje softvera koje se ne slae sa originalnim zahtevima predstavlja greku koju je potrebno
identifikovati i otkloniti. U uem smislu, testiranje predstavlja upravo proveru da li je odreeni softver u
potpunosti implementiran prema originalnim korisnikim zahtevima. U irem smislu testiranje predstavlja
sistem kontrole kvaliteta (QA Quality Assurance) kojim se ne proverava samo softver ve i sve njegove
pratee komponente I karakteristike.
Kvalitet softvera se moe definisati na razliite naine kao na primer:
1. Usaglaenost sa zahtevima i potrebama korisnika jedan od najbitnijih uslova da bi se softver ocenio
kao kvalitetan je da pomae krajnjim korisnicima u radu.
2. Dobri atributi proizvoda kao to su brzina rada, malo zauzee memorije i prostora na disku, brzina
pokretanja.
3. Lakoa odravanja i promena u softveru, kao i prenoenja na druge platforme. Kvalitet
dokumentacije, zahteva, dizajna, uputstava za upotrebu i bilo kojih drugih prateih dokumenata
kojima se opisuje softver.
4. Usaglaenost sa standardima to podrazumeva usaglaenost sa organizacionim standardnima pisanja
programskog koda, potovanje optih standarda (ISO), usaglaenost sa zakonima i slino.
5. Rad u ekstremnim uslovima sa ogromnim koliinama podataka, slabim vezama, ogranienim
resursima koji su na raspolaganju i slino.
Bez obzira na to kako se definie kvalitet, svaka definicija predstavlja skup nefunkcionalnih zahteva kojima se
opisuje ta se oekuje od softvera. Cilj testiranja kao kontrole kvaliteta je upravo provera da li su ovi zahtevi
ispunjeni. Primer provere kvaliteta softvera danas ukljuuje i proveru smislenosti originalnih zahteva, jasnoe
specifikacije i usaglaenosti sa originalnim zahtevima, lakoe korienja softvera i slino.
Danas se sve manje govori o testiranju softvera kao izolovanoj aktivnosti provere funkcionalnosti i tei se
optoj kontroli kvaliteta svih softverskih komponenti. Za ljude koji rade ovakve poslove esto se umesto
naziva tester vie koristi termin kontrolor kvaliteta (QA).
U istoriji tehnike je poznato mnogo greaka koje su uzrokovane softverskim problemima. Ovi problemi su
esto uzrokovali viemilionske tete.
Primeri takvih greaka su:
1998. Pad Marsovog orbitera. Orbiter je priao Marsu pod pogrenim uglom I umesto u orbiti zavrio
je na povrini planete. Uzrok je nekompatibilnost podataka koje su moduli slali jedan drugom, ime
je uniten projekat vredan 327 miliona dolara.
2002. Studija Nacionalnog instituta za standarde i tehnologiju (NIST) je pokazala da softverske greke
kotaju ameriku ekonomiju 59,5 milijardi dolara godinje. Studija govori da bi se 22,2 milijarde
dolara mogle utedeti boljim testiranjem.
2007. Blokiranje aerodroma u Los Anelesu. Usled greke u softveru, pogrene informacije su bile
poslate u mreu carine Sjedinjenih Amerikih Drava, to je uslovilo da 17.000 aviona budu osam sati
zarobljeni na aerodromu.
2010. Usled greke u softveru kojim su se unosile informacije o organima koji mogu biti izvaeni iz
donatora, pogreni organi izvaeni iz 25 donatora u Velikoj Britaniji. Softver za prikupljanje podataka
se koristio od 1999. godine I pronaeno je jo 400.000 greaka.
2011. Investicioni fond AXA je morao da plati preko 200 miliona dolara zbog tete koju je nanela
greka u softveru zbog koje su investitori izgubili investicije. Fond je znao za greku, ali je tvrdio da je
problem u tritu i drugim faktorima.
Kao to se moe videti u sluaju da se radi o velikim i skupim projektima nikada nije dovoljno testiranja poto
i najmanji problem moe da uniti ogroman napor koji je uloen na projektu. Dananji softverski projekti
postaju sve skuplji tako da je danas sve vei fokus na testiranju i proverama softvera kako bi se izbegli
problemi koji u poslednjem trenutku mogu da unite ceo projekat.
S obzirom da se greke ne mogu izbei, potrebno ih je to je mogue ranije otkriti kako bi njihovo otklanjanje
bilo bre i jeftinije.
Slika 1.1.
2 PROCES TESTIRANJA
Testiranje je proces koji obuhvata veliki broj aktivnosti i usko je vezan sa procesom razvoja softvera. Ovde e
biti kratko opisan uobiajeni proces testiranja koji se moe prilagoavati konkretnim potrebama.
Primer aktivnosti testiranja koje se primenjuju tokom faza razvoja projekta je prikazan na slici 1.2.
U ranijim fazama projekta koje predstavljaju upoznavanje sa konkretnim projektom i problemima koje je
potrebno reiti, planira se ta e se testirati i ta je sve potrebno test timu, to predstavlja osnovu za dalji rad.
Planiranje se ne zavrava na poetku projekta zavisno od potreba i zahteva na projektu planiranje se
nastavlja do kraja.
Slika 1.2
Praenje statusa problema ovo je aktivnost koja se esto izvrava paralelno sa fazom izvravanja
testova i obuhvata praenje ivotnog ciklusa prijavljenih problema to ukljuuje reavanje problema
od strane programera, potvrivanje da je problem reen od strane testera ili reaktiviranje problema i
vraanje programerima ako nije korektno reen.
3 AKTERI
U sluaju da je implementiran potpun proces testiranja potrebno je okupiti vei broj ljudi sa razliitim
ulogama, znanjima i sposobnostima koji e zajedno uspeno testirati softver. U procesu testiranja se mogu
ukljuiti lanovi test tima sa razliitim ulogama zavisno od njihovog znanja.
Svaka softverska organizacija ima svoju klasifikaciju pozicija u test timu:
Tester je svako ko ima dovoljno znanja u korienju softvera ili znanja u odreenoj oblasti primene
softvera i ko moe da koristi softver i ispituje da li se ponaa kao to je oekivano.
Test inenjer je neko ko ima vie tehnikog iskustva i znanja koja mu omoguavaju da koristi test
alate, prilagoava okruenje potrebama testa, i vie se bavi tehnikim delovima testa.
Test analitiar je neko ko je u stanju da analizira originalne zahteve i definie test sluajeve koje je
potrebno izvriti kako bi se proverilo da li su zahtevi ispravno implementirani.
Test menader ili voa test tima je osoba sa dosta iskustva u testiranju, onaj ko moe da sagleda
kompletan proces testiranja, menja ga u skladu sa potrebama projekta i vodi ceo test tim tokom
provere softvera.
3.1 TESTER
Tester je bilo koji lan tima koji proverava validnost sistema ili njegovih komponenti. U praksi tester ne mora
da ima neko tehniko predznanje o aplikaciji ili platformi koja se testira poto mu je fokus na poslovnom
procesu i korisnikom pogledu na sistem.
esto su testeri aplikacija ljudi koji imaju neko znanje o problemu koji reava aplikacija i mogu da prou kroz
funkcionalnosti kako bi proverili da li su one ispravno implementirane. Na primer, u sluaju da se
implementira neka finansijska aplikacija, esto testiranje vri neki ekonomista koji dovoljno dobro poznaje
problematiku i koji moe da korienjem aplikacije proveri da li su sva poslovna pravila ispravno
implementirana. Kod testera najvanija osobina je snalaljivost, brzo shvatanje rada kako softvera tako i
korisnika.
Jedina stvar koja je bitna za testera jeste da je upoznat sa aplikacijom koju testira i da je ispravno testira i
prijavljuje probleme. Osnovne aktivnosti koje tester radi su:
1. Izvravanje testova testeri ili prate pripremljene scenarije za testiranje ili vre ad-hoc testove kako
bi pronali greke koje ne pokrivaju planirani scenariji testiranja.
2. Analiza pronaenih problema svaki problem koji je pronaen se analizira kako bi se prikupilo to je
mogue vie informacija o tome zato je problem nastao i pod kojim uslovima se moe
reprodukovati.
3. Izvetavanje o pronaenim problemima poto su pronaeni problemi analizirani i potpuno opisani
oni se prijavljuju u sistem za prijavljivanje greaka gde se dodeljuju razvojnom timu kako bi bili
reeni.
4. Uestvovanje u analizi i dizajnu testova testeri zajedno sa ostalim lanovima test tima identifikuju
ta e biti testirano i na koji nain. Iako njihova primarna aktivnost nije identifikacija i specifikacija
test sluajeva koji e se koristiti, oni zajedno sa analitiarima uestvuju u definisanju naina na koji e
testiranje biti sprovedeno.
5. Pregled i evaluacija kvaliteta i smislenosti zahteva i specifikacije softvera.
10
4 MANUELNO TESTIRANJE
Pod pojmom manuelnog testiranja podrazumevamo runo izvravanje test sluajeva. U najveem broju
sluaja tester prati odreeni niz koraka da bi verifikao odreeni segment aplikacije ili kod koji je pod
tesitranjem.
Test sluaj se oznaava kao uspean ako njegovo izvravanje nad sistemom pod testom dovodi do rezlutata
koji je ekvivalentan sa oekivanim. Naravno ovo je u kontradikciji sa sve vie popularnom metodologijom
destruktivnog testiranja gde se test sluaj oznaava uspenim akko njegovo izvravanje nad sistemom pod
testom se ne slae sa oekivanim rezultatom, odnosno test sluaj je uspean ako otkrije postojanje greaka u
softveru.
11
Postoje razliiti tipovi testiranja i na svaki od njih se moe primenti metode kako manuelnog tako i
automatskog tesitranja. Pregled razliitih tipova testiranja moete videti na slici 1.3.
Slika 1.3
Black Box: Posmatranje softvera kao zatvorene kutije gde se na osnovu predefinisanih koraka
podacima hrani sistem i posmatra se da li se njegove izlazne vrednosti slau sa oekivanim.
White Box: Posmatanje softvera kao otvorene kutije gde se stavlja focus na kod.
Unit Test: Za svaku atomsku jedinicu koda, to u zavisnosti od programske paradigme koja se koristi
za implementaciju softvera moe biti funkcija, procedura, metod i sl. kodira se test koji testira tu istu
jedinicu.
System Test: Testiranje kompletnog sistema (hardver, softver) u cilju provere slaganja sa korisnikim
zahtevima kao i funkcionalnih i nefunkcionalnih zahteva.
Integration Test: S obzirom na porast agilnih metodologija razvoja, veina softverskih sistema se
implementira u fazama gde je izlaz iz svake faze inkrement. Inkrementi su meusobno povezani tako
da se mora proveriti da li se on slae sa ve gotovim sistemom u koji se on integrie.
Acceptance Test: Testiranje da li se softver slae sa zahtevima korisnika.
Ovde su ukratko navedene definicije, predlaemo itaocu da istrai dalje o svakoj pojedinano s obzirom da
zasebno za svaki od vidova testiranja postoji ogromna koliina dostupne literature.
12
5 AUTOMATSKO TESTIRANJE
Suprotno manuelnom testiranju automatsko testiranje zahteva postojanje odreenog koda koji je pisan da bi
se automatizovali koraci pri izvravanju odreenog test sluaja. Popularno se datoteke koje sadre
automatizacionu logiku nazivaju test skripte I mogu biti pisane svim danas popularnim programskim jezicima
nezavisno od programske paradigme.
Automatsko testiranje se esto koristi da bi se test sluajevi u okviru odreenog test paketa koji su izvreni
manuleno mogu brzo izvravati automatski. To je jako bitno kod regresionog testiranja s obzirom da
regresiono testiranje sadri sve test sluajeve koji su prethodno bili izvreni nad sistemom ali I najnovije koji
testiraju dodatu funkcionalnost.
Regression test esto moe ukljuivati I vie hiljada test sluajeva tako da potreba za automatizacijom jasna.
Motivi naravno su uteda vremena a samim tim I novca.
5.1
PRIMER
Recimo da elimo da testiramo pretragu na www.google.com sajtu. U sutini bitno nam je da dobijemo http
response od servera, da pronaemo polje za unos klua pretrage kao i da vidimo da li je pretraga izvrena.
Kod ovog primera bie nam dovoljno da samo proverimo da li ste title web stranice promenio. Sledei kod
testira isti primer koristei podrku selenium automation biblioteka, I google webdriver-a.
13
import
import
import
import
org.openqa.selenium.By;
org.openqa.selenium.WebDriver;
org.openqa.selenium.WebElement;
org.openqa.selenium.htmlunit.HtmlUnitDriver;
Manje pouzdani: manuelno testiranje nije pouzdano, jer ne postoji strogo merilo na raspolaganju, tj.
da li su aktuelni i oekivani rezultati su u korektnom odnosu. Upravo se tu oslanjamo na miljenje
testera.
Visok rizik: manuelni proces testiranja podlee visokim rizicima propusta i greaka. Ljudi se umore,
mogu biti privremeno nepaljivi, mogu da imaju mnogo zadataka koje je potrebno zavriti, mogu biti
nedovoljno obueni i tako dalje. Dakle, nenamerno se greke deavaju kod unosa podataka, u
podeavanju parametara, izvrenju testa i u poreenjima rezultata.
Nepotpuna pokrivenost: Testiranje je veoma sloen proces kada imamo kombinaciju vie platformi,
operativnih sistema, servera, klijenata, protokola, poslovnih procesa itd. U ovakvim sluajevima
manuelna regresija je praktino nemogua.
Rokovi: Ogranieni resursi u toku test procesa onesposobljavaju efikasno I blagovremeno manuelno
testiranje. Prema aktuelnim studijama, 90% svih IT projekata probija rokove zbog runog testiranja.
14
Automatizovani razvoj testova je obino 3-5 puta skuplji proces od kompletnog ciklusa manuelnog
testiranja.
Automatizacija je previe glomazna problematika. Ko automatizuje? Ko odrava? Ova pitanja
komplikuju samu ideju automatizacije.
Automatizacija e zahtevati dodatno obueno osoblje.
ZAKLJUAK:
Test automatizacija je delimino a ne kompletno reenje. Trenutno ne postoji dovoljno pouzdan proces
kao ni alati pomou kojih bismo mogli zanemariti sve aktere koji uestvuju u test procesu. Manuelno I
Automatsko testiranje se dopunjuju.
15
7 REFERENCE