Вы находитесь на странице: 1из 49

UNIVERZITET U SARAJEVU Fakultet za saobraaj i komunikacije Predmet: Informacioni sistemi u saobraaju i komunikacijama

- Design-driven testing (Dizajn voen testiranjem) - - -seminarski rad---

Sarajevo, novembar 2012.


1

SADRAJ Uvod............................................................................................................................................................. 3 1. Dizaj voen testiranjem u teoriji ...................................................................................................... 4


1.1. Razliite vrste testiranja ................................................................................................................ 5 1.2. Voenje test sluajeva iz dijagrama robusnosti ......................................................................... 9 1.3. Koritenje agilnog dodatka za ICONIX/EA ............................................................................. 11 1.4. Voenje test jedinica sa test sluajeva ....................................................................................... 13 1.5. Kratki uvod u JUnit ...................................................................................................................... 14 1.6. Pisanje efektivnih testova jedinica ............................................................................................. 17

2. Dizaj voen testiranjem u praksi ................................................................................................... 18


2.1. Testovi jedinica za Internet knjiaru .......................................................................................... 18 2.2. Testiranje Prikaz Poetne Stranice ............................................................................................. 20 2.3. Pokretanje testova iz test paketa ................................................................................................. 25 2.4. Testiranje Preuzmi Detalje Knjige Kontrolor ........................................................................... 26 2.5. Testiranje Prikai Detalje Knjige Kontrolor ............................................................................. 32 2.6. Testiranje Prikaz Stranica Knjiga Nije Pronaena Kontrolor ................................................ 40

3. Deset najveih greaka dizajna voenog testiranjem ............................................................... 45 Zakljuak ................................................................................................................................................ 46 Bibliografija
Popis slika i tabela

UVOD Lahko je pogledati u programski modul, i rei Eto, to je zavreno, ali osjeaj zavretka moe biti varljiv. Kako moemo znati sigurno da je kod zavrio sve use case (koritene sluajeve) scenarije, a ne samo osnovne kurseve, ve i alternativne takoe? DDT (design-driven testing) dizaj voen testiranjem prua neprobojnu metodu za proizvodnju test sluajeva, kako bi verifikovali da su svi naznaeni scenariji zavreni. Moemo takoe, koristiti ovaj proces da napiemo izvrne testove iz testnih sluajeva. Testiranje je proces koji bi trebao poeti mnogo prije kodiranja. Poinjanje testiranja proizvoda poslije nakon to je navodno zavren je marginalno bolji, ali bi testni proces trebao poeti mnogo prije nego to se uope pone kodirati. Priprema za testiranje poinje u toku faze analize, identifikovanjem testnih sluajeva uz koritenje robusnih dijagrama (robustness diagrams). Ranim testiranjem, mogue je eliminirati mnogo vie kvarova, prije nego to se uope pojave. Testiranje slijedi ubrzo nakon preliminarnog dizajna, a onda pisanje jedinica test kodova tokom implementacije. Moramo biti sigurni da su testovi povezani zajedno za zahtjevima. Ne iz razloga da svaki test bi trebao biti praen unazad ka zahtjevima, ali bi trebao bar postojati test da dokae da je svaki zahtjev proveden tano. Proces koji emo opisati u ovom poglavlju je jedna metoda za raenje upravo toga: pokretanje testova jedinica iz koritenih sluajeva.

1. Dizaj voen testiranjem u teoriji Poet emo ovo poglavlje osvrtanjem na pretpostavke i osnovne teorije DDT. Pokazat emo par primjera kroz rad, koje emo kasnije prenijeti u podpoglavlje Dizajn voen testiranjem u praksi, ali svakako potrebno je da se prvobitno osvrnemo na teoriju. Principi koje emo prodiskutovati u ovom poglavlju mogu biti sumirani u listu smjernica. Naa lista top 10 : 10. Usvojiti testiranje gdje se svaki pronalazak kvara prihvata kao pobjeda, a ne poraz. Ako pronaemo ( i popravimo) kvar u testiranju, korisnici ga nee ponai u konanom proizvodu. 9. Razumijevanje razliitih vrsta testiranja, kako i to kada se oni koriste. Upoznavanje sa razliitim vrstama testova koje emo opisati u ovom poglavlju i primjena svakog testa u pravo vrijeme, a isto tako vano, koritenje isporuka koje kreiramo na putu za pripremu svakog testa u unaprjeenju. 8. Kada testiranje jedinica kreira jedan ili vie testova za svaki kontroler na svakom robusnom dijagramu, takoer kreira jedan ili vie jedininih testova za svaku operaciju na svakoj klasi sa dizajnom. 7. Za realne sisteme, koristimo elemente dijagrama stanja kao osnovu za testove sluajeva. Na primjer, test odgovara razliitim elementima koji pokreu promjene stanja. Tokom ove vrste testiranja, pratimo promjene u osobinama objekata kako bi testirali interakcije izmeu objektnih metoda. Moemo koristiti elemente dijagrama stanja kao bazu za testove sluajeva. 6. Uraditi provjeru nivoa zahtjeva , provjeravajui svaki zahtjev koji smo identificirali. 5. Koristiti matricu slijedivosti kao pomo u provjeri zahtjeva. 4. Uraditi scenario nivoa pihvatljivosti za svaki koriteni sluaj. 3. Proiriti teme u testnim scenarijima za pokrivanje kompletnog puta, kroz odgovarajui dio osnovnog kursa i dodanog kursa u testiranju scenarija. 2. Koristiti okvir testiranja kao to je JUnit, za pohranjivanje i oganizovanje testova jedinica. 1. Odravanje testova jedinica dobro preciziranim.
4

1.1.Razliite vrste testiranja Treba li bi posmatrati testiranje kao skup interativnih i inkremantalnih razvojnih ciklusa, ne samo kao neto to se povremeno radi nakon to izdvojite hrpu kodova? Razlog za to je jednostavan: test dokazuje da proizvod odgovara specificiranoj namjeni. Testovi samo po sebi trebaju biti veoma vrsto povezani sa zahtjevima, na mikroskopskom nivou. Ako su testovi usko povezani sa zahtjevima, onda se prolaskom testa dokazuje da softver odgovara svojoj specificiranoj namjeni, a ako testovi nisu povezani sa zahtjevima onda prolazak testa, samim po sebi je beznaajan. Klju za testiranje je razumijevanje razliitih vrsta testova, i posebno kada u ciklusu ivota softvera, koja vrsta testa treba biti upotrijebljena. Slika 1. pokazuje koji testovi trebaju biti izvedeni za svaku fazu u ICONIX Process-u. Tako, za testove koji su preliminarno dizajnirani i provedeni zadovoljavavajue sa specifikacijama, provodimo integracione testove, pa nadalje. Pripreme za svaku vrstu testa mogu poeti dobro unaprijed. Na primjer, sve dok je poslovni ugovor (u sutini ugovor izmeu kompanije i kupca) nepotpisam, QA moe poeti pekulaciju izvedenih testova, baziranim na sadraju poslovnog sluaja. Slino, sve dok je koriteni sluaj napisan, softver testeri mogu poeti pisati testove za taj koriteni sluaj. Mnogi od testova vieg nivoa mogu biti napisani u obliku testova jedinica. Na primjer, kao to emo vidjeti kasnije u ovom radu, poeljno je da izvodimo testove jedinica i metode, direktno iz kontrola u preliminarnom dizajnu, koji su u suprotnom, izvoeni od koritenih sluajeva.

Slika 1. V model softverskog testiranja primjenjljivog u ICONIX Procces-u

Tabela 1. opisuje razliite vrste testova prikazane u slici 1.

Test Test jedinica Testiranje individualnih softverskih komponenti. Moe se koristiti za simulaciju inputa i outputa komponente, tako da moe raditi u samostalnom nainu Integracioni test Testiranje se vri da se otkriju greke u sueljima i u interakciji izmeu integrisanih komponenti. Za razliku od testova kompatibilnosti, klase su dio ukupnog sistema dizajna Test kompatibilnosti Testiranje da sistem sarauje dobro sa ostalim vanjskim sistemima, sa kojima se zahtjeva da komunicira. Test sistema Funkcionalni i behioralni dizaj test sluaja. Selekcija test sluaja koja je bazirana na analizi specifikacija komponenti bez upuivanja na unutarnje djelovanje. Funkcionalno testiranje sastoji se od mnogih koritenih sluajeva i poslovnih procesa ispitivanja, ali ukljuuje i testiranje funkcionalnih zahtjeva. Test prihvatljivosti Formalno testiranje provedeno od strane kupca, da se utvrdi da li sistem zadovoljava zahtjeve naznaene u ugovoru Beta testing Provodi se od strane krajnjeg korisnika koji nije drugaije ukljuen u razvoj. Test putanja Provjera da zavreni proizvod precizno odraava poslovni sluaj

Kada (i zato) bi trebali ih izvoditi Testiranje jedinica poinje prije integracije. Testiranje jedinica se izvrava na svakoj izgradnji softvera, kroz razvojne faze ( ukljuujui fazu popravka kvarova, nakon to je softver puten u testiranje sistema) Vri se nakon testiranja jedinica

Nije isti kao integracioni test, iako se oba rade u isto vrijeme

Vri se nakon integracionog testa. Test sistema, tei da bude fokusiran na razvoj. Njegova namjena je da dokae da sistem koji je naznaen je i dostavljen

Test prihvatljivosti provodi se u istoj liniji sa testom sistema ali je isticanje drugaije. Iznosi se da bi se utvrdilo da sistem isporuuje ono to je stvarno traeno. Provodi se prije testa prihvatljivosti, u okruenju to bliem proizvodnom okruenju. Radi se u taki u kojoj softver treba biti isporuen kupcu, da se osigura da je proizvod razvijen u skladu sa specifikacijama i da u potpunosti postie ciljeve.

Tabela 1. Razliite vrste testova i kada ih primjeniti

Kao dodatak navest emo neke vrste testova koje prolaze kroz razvojni proces ili nisu bazirane na specifinoj isporuci (Tabela 2.). Test Nefunkcionalni test zahtjeva funkcionalnost (izvoenje, korisnost,...) Test izvodljivosti Kada (i zato) bi trebali ih izvoditi Ovaj test treba se provoditi kroz ivotni ciklus

Testiranje onih zahtjeva koji nisu vezani za softvera, gdje je god mogue ( ak i na nivou testa jedinica). Ovaj test moe ( i treba) biti izveden u svakoj

Testiranja provedena za procjenu popustljivosti prilici ali se uglavnom izvrava nakon testa sistema ili komponenti sa specificiranim sistema. zahtjevima izvoenja. Test regresije Ovo testiranje se izvrava nakon to kod bude Retestiranje prethodno testiranog programa puten u test sistema. Test jedinica je forma slijedei modifikacije da osigura da neuspjesi regresijskog testa ako se izvede pravilno. nisu uvedeni ili neotkriveni kao rezultat napravljene promjene. Test otpornosti na stres Testiranja provedena za evaluaciju sistema ili komponente na granici ili izvan svojih granica, specificiranih zahtjevima. Test zapremine Ispitivanje gdje je sistem podvrgnut velikim koliinama podataka.
Tabela 2. Testovi koji prolaze kroz razvojni proces

Ovaj test se izvodi nakon testa izvodljivosti.

Izvodi se nakon testa sistema.

1.2.Voenje test sluajeva iz dijagrama robusnosti

Sa ICONIX Procces-om, ulaemo trud kako bi napisali koritene sluajeve, i identifikujemo objekte koji sudjeluju u koritenom sluaju kao i funkcije koje ti objekti obavljaju na dijagramu robusnosti (funkcije su prikazane kao kontroleri). Poto smo uloili trud u identifikaciju loginih softverskih funkcija, bilo bi dobro kada bismo dobili paket test sluajeva koji nas podsjeaju da testiramo sve funkcionalnosti koritenog sluaja. Slika 2. prikazuje pregled DDT, u kojoj test sluajevi su kreirani direktno od kontrolera na dijagramu robusnosti. Kako slika 2. prikazuje, moemo automatski transformisati dijagram robusnosti u sekvencijalni i dijagram test sluajeva koritei jednostavnu skriptu. Test kod moe biti naknadno generiran za test jedinica okvira kao to su JUnit or NUnit. Sada emo to detaljnije objasniti kroz korake na primjeru. Kada definiramo logine funkcije sa kontrolorima koritenih sluajeva, potrebno je te funkcije testirati. Radom sa dijagramom robusnosti, moemo kreirati dijagram test sluaja, koji prikazuje test sluaja za svakog kontrolora. To emo uraditi tako to emo kopirati sve kontrolore sa dijagrama robusnosti na novi dijagram, i onda povezati sa testom sluaja koritenjem <<realize>> konektora. To emo ubrzo prikazati i na primjeru.

Slika 2. Pregled DDT-a

Svaki test sluaja sadri vie scenarija. Da bi identifikovali test scenario za svaki kontrolor/test sluaj, trebamo slijediti slijedee korake: 1.Ponovo proitati tekst koritenog sluaja da se podsjetimo sadraja u kojem je kontroler koriten 2. Za svaki test sluaj, kreirati test scenario za svaki koriteni scenario (osnovni i alternativni kursevi)

10

3. Imenovati svaki test scenario nakon orginalnog koritenog scenarija. Na primjer, za kontroler Preuzeti detalje knjige( Retrieve Book Details), alternativni scenario nazvan Knjiga nije pronaena (Book Not Found), e dovesti do test scenarija Knjiga nije pronaena u test sluaju nazvanim Preuzeti detalji knjige. 1.3.Koritenje agilnog dodatka za ICONIX/EA

Trebamo naglasiti da ICONIX Process radi jednako dobro sa bilo kojim objektno-orjentiranim programskim jezikom, CASE alatom itd. Enterprise Arhitect (EA) ima poseban dodatak koji automatizira mnogo prijelaznog posla kada premjetamo izmeu dijagrama u ICONIX Process-u. Na primjer, dodatak e automatski kreirati set robusnih dijagrama za dijagram koritenog sluaja (slika 3. ), i dodatak e popuniti sekvencijalni dijagram koristei granice, entitet i kontroler objekte na robusnom dijagramu, to je veoma velika uteda na vremenu.

Slika 3. Koritenje Agilnog ICONIX/EA dodatka za generiranje dijagrama 11

Slika 4. Generacija test sluajeva u EA

Za potrebe testiranja, dodatak automatski kreira dijagram test sluaja od kontrolora na robusnom dijagramu (slika 4.). Onda je mogue napisati izvrni test jedinica za svaki test sluaj. Primjeujemo da je svaki test sluaja povezan sa kontrolorom. Drugim rijeima, postoji jedan test sluaj po kontroloru. Veza izmeu test sluaja i kontrolera je realizes (ostvaruje), ista veza koja je koritena da pokae klase implementacije/realizacije suelja. Desnim klikom na svaki test sluaj moete dodavati individualne scenarije.(slika 5.)

12

Slika 5. Dodavanje test scenarija u EA

1.4. Voenje test jedinica sa test sluajeva Da podsjetimo, moramo modelirati test sluaj na kontrolora iz svog robusnog dijagrama-da svaki kontroler dobija tano jedan test sluaj, i za svaki test sluaj, kreirati jedan ili vie test scenarija. Jednom kada kreiramo test sluaj i alociramo test scenarijo na svaki, vrijeme je da kreiramo kostur test jedinica.

13

Uputstva za voenje test jedinica iz test sluajeva: Za svaki test sluaj, kreiramo jednu klasu test jedinica. Na primjer, ako se test sluaja zove Test Preuzimanja Detalja Knjige, onda kreirate klasu JUnit testa nazvanu TestPreuzimanjaDetaljaKnjige. Za svaki test scenario, kreiramo jednu testnu metodu u klasi testova jedinica. Na primjer, ako je test sluaj nazvan Knjiga Nije Pronaena, kreiramo test metodu nazvanu testKnjigaNijePronaena(). Napisati test jedinica sa ugla posmatranja objekta, tj kontrolora. Ako otkrijemo nove alternativne teaje dok razmiljamo o scenariju test sluaja, to je mogue, ne treba oklijevati da ih dodamo u koriteni sluaj. Proi emo kroz neke primjere kreiranja testova jedinica iz testova sluajeva.

1.5.Kratki uvod u JUnit Za kodiranje primjera kasnije u ovom poglavlju koristit emo JUnit, popularnu Java-baziranu okvirnu test jedinicu. JUnit dio je xUnit porodice koja ukljuuje cppUnit za C++, n Unit za C#/.NET i DUnit za Borlan Delphi. Iako se izvorni kod moe razlikovati ovisno o jeziku/implementaciji, principi razmatrani u ovom poglavlju su u osnovi isti, bez obzira koji okvir test jedinica koristimo. Sa JUnit, piemo test sluaj gdje svaki test sluaj je pojedinana Java klasa. Unutar ove klase, pojedinane metode ispitivanja slijedite konvenciji imenovanja testa XYZ, gdje XYZ je ime naeg testa. Ova konvencija imenovanja dozvoljava JUnit da automatski otkrije i pokrene test metode, bez njihovog proglaavanja (npr. u vanjskom XML fajlu). Koritenje JUnit 4.0, test metode moe takoer biti identifikovano koritenjem Java 5 tvrdnji. Unutar test metode, moete napisati Java kod koji poziva metode u klasama da budu testirane i tvrdi da je rezultat upravo ono to se i oekivalo. Za dio tvrdnji , JUnit prua broj razliitih metoda tvrdnji(npr., tvrditi da je vrijednost istinita, ili da vrijednost nije-nula, ili da dvije vrijednosti su jednake). Test klasa moe sadravati bilo koji broj test metoda, iako je generalno dobra ideja drati broj ispod pet. Slino, dobro je ograniiti svaku test metodu na jednu tvrdnju.
14

Ovo uva test scenarij fokusiranim na testiranje jedne stvari. Ako imamo potrebu da dodamo vie od jedne tvrdnje, vjerovatno traimo vie od jednog test scenarija stisnute u jednu test metodu, tako da ne treba oklijevati da ih podijelimo.

Imamo primjer klase testa jedinica:


package test.com.iconixsw.bookstore.web; import junit.framework.*; public class AddToShoppingCartTest extends TestCase { public AddToShoppingCartTest (String testName) { super(testName); } public void testShoppingCartEmpty() throws Exception { ShoppingCart cart = new ShoppingCart(); assertEquals("Cart should be empty", 0, cart.getNumItems()); } public void testItemAdded() throws Exception { ShoppingCart cart = new ShoppingCart(); LineItem item = new LineItem(); cart.addItem(item); assertEquals("Cart should contain 1 item", 1, cart.getNumItems()); } }

Test sluaj DodajUKorpuKupovineTest sadri dvije test metode. Prva metoda je brza, razumna provjera da se uvjerimo da ako je nova KorpaKupovine kreirana, poinje prazna.

15

Druga test metoda provjerava da ako je jedan artikal dodan u korpu, onda korpa sadri tano jedan artikal. U oba sluaja koristimo asserEquals(), koji ima tri argumenta: Koristan opis koji se pojavi ako test ne izvri uslove Vijednost koja predstavlja kakva oekivana vrijednost treba biti Rezultat testiranog koda, koji bi naravno, rijeio samu vrijednost drugog argument.

Obje test metode postavljaju objekat KorpaKupovine. Zapravo, uzei u obzir da je test sluaj sve o dodavanju artikla u KorpaKupovine, imalo bi smisla za oba testa da koriste istu postavku koda. Sreom, JUnit omoguava a setUp() metodu samo za ovu namjenu. Da demonstriramo ovo, pokazat emo novu verziju DodajUKupovnuKorpuTest, koji koristi setup() da eliminie duple kodove. Novi kod je prikazan u crvenoj boji:
package test.com.iconixsw.bookstore.web; import junit.framework.*; public class AddToShoppingCartTest extends TestCase { private ShoppingCart cart; public AddToShoppingCartTest (String testName) { super(testName); } public void setUp() { cart = new ShoppingCart(); } public void testShoppingCartEmpty() throws Exception { assertEquals("Cart should be empty", 0, cart.getNumItems()); } public void testItemAdded() throws Exception { LineItem item = new LineItem(); cart.addItem(item); 16

assertEquals("Cart should contain 1 item", 1, cart.getNumItems()); } }

SetUp() metoda se pokree automatski, odmah prije poetka svake test metode. Vrijedno je istai taku da se ne pokree samo jednom za cijeli test sluaj. Umjesto toga, pokree se jednom za svaku posebnu test metodu, tako da za svaku test metodu, garantiramo, dobar, svje primjer KupovneKorpe. Postoji takoe teardown() metoda koja radi obrnuto od setup() i korisna je za zatvaranje vanjskih izvora kao to su veze baza podataka ili inpu/output tokovi. TearDown() se pokree odmah nakon svake pojedinane metode. Kroz vei dio ostatka ovog rada, proi emo kroz primjere da pokaemo kako pokretati testove jedinica direktno i test sluajeva, koji su pokretani od strane kontrolora sa robusnih dijagrama a koji su pokretani sa koritenih sluajeva. Na cilj je da pruimo detaljno razumijevanje kako da poveemo te testove zajedno sa zahtjevima na mikroskopskom nivou.

1.6.Pisanje efektivnih testova jedinica Prije nego ponemo na primjeru, vrijedno je istai neke najbolje prakse za pisanje dobrih testova jedinica. Cijela knjiga je posveena testovima jedinica, ali tehnike efektivnih testova jedinica sa perspective dizajnom-voenog testiranja mogu se saeti veoma jezgrovito: uvanje testova jedinica precizno. Generalno, trebamo pokriti jedan test sluaj jednom klasom testova jedinica i razliitom permutacijom ili tvrdnjom test sluaja u svakoj test metodi. Uvjeriti se da svaka test metoda testira tano jednu stvar. Povezati testove jedinica sa klasama i metodama koju testiramo. Povezati testove jedinica sa objektima u preliminarnom dizajnu. Podjednako tretiranje koda test jedinica sa istim potovanjem kao sa proizvodnim kodom.
17

Izbjegavanje duplikata u testu. Uvjeriti se da se testovi izvode 100% uspjeno. Koristiti mock objects(lane predmete), ali se ne oslanjati previe na njih.

U slijedeem poglavlju proi emo kroz primjer Internet knjiare, sve od dijagrama robusnosti, do JUnit testova. 2. Dizaj voen testiranjem u praksi U ovom dijelu, ilustrirat emo teoriju iz prvog dijela ovog poglavlja, koritenjem projekta Internet knjiare. Podsjetili smo se na detaljni dizaj iz 9 poglavlja i ovaj put, bez direktnog prelaska na kodiranje, prvo testiramo neke test sluajeve direktno is robusnih dijagrama, i spajamo ih sa detaljnim dizajnom. Onda koristimo test sluajeve da potvrdimo da: detaljni dizajn se poklapa sa koritenim sluajem kod se poklapa sa detaljnim dizajnom i ini ono za ta je namijenjen 2.1.Testovi jedinica za Internet knjiaru Da napiemo test jedinica za Internet knjiaru, uzet emo kontrolore sa robusnih dijagrama za koritene sluajeve Prikai Detalje Knjige (Show Book Details) i Napii korisniku recenziju (Write Customer Review), proizvesti test sluajeve za njih i onda napisati test jedinica baziran na test sluajevima. Ovaj korak bi trebali uraditi prioritetno za pisanje koda, tako da kada kodiramo, imamo dovoljan set testova jedinica da sastavimo i testiramo ponovo. Slika 6. prikazuje dijagram test sluaja. Ovaj dijagram je proizveden sa robusnog dijagrama za Prikai Detalje Knjige.

18

Slika 6. Generirani test sluaj za prikai detalje knjige koriteni sluaj

Prikai Stranicu Knjiga Nije Pronaena i test sluaj su prikazani crvenom bojom jer se radi o alternativnim kursevima. Da podsjetimo, svaki kontroler sa robusnog dijagrama dobija svoj test sluaj, i u svakom test sluaju smo kreirali jedan ili vie test scenarija. Za svaki test sluaj, kreiramo klasu testova jedinica i za svaki test scenario kreiramo metodu test jedinica. Proi emo kroz ovaj process jednom za svaki test sluaj (prikazan u slici 6.)

19

2.2.Testiranje Prikaz Poetne Stranice U ovom dijelu, kreirat emo test scenario za Kontrolora Prikaz Poetne Stranice, najjednostavnijeg u grupi, i onda emo napisati JUnit test klasu. Slijedi dio teksta koritenog sluaja koji je vezan za ovog kontrolora: Kupac upie u URL adresu za internet knjiaru poetnu stranicu. Sistem prikae listu knjiga iz kataloga na poetnoj stranici u obliku linkova koje moete otvoriti. Test sluaj za ovog kontrolora je jednostavan, zapravo, trebamo samo jedan test scenario za ovaj test sluaj zato to postoji malo toga to moe krenuti naopako. Da dodamo test scenario u EA, dvoklik na test sluaj i onda u prozoriu Postavke kliknemo Scenario tab.(slika 7.) Postoji samo jedan test scenario za ovaj test sluaj, tako da moemo oekivati da vidimo jednu test metodu u klasi testa jedinica.

Slika 7. Dodavanje test scenarija za test sluaj Prikaz poetne stranice 20

Slijedi kostur JUnit testa za ovaj test sluaj:


package test.com.iconixsw.bookstore.web; import junit.framework.*; public class DisplayHomePageTest extends TestCase { public DisplayHomePageTest(String testName) { super(testName); } public void testDisplayHomePage() throws Exception { }

} Test proiruje TestSluaj, klase JUnit. U JUnit, bilo koja metoda ije ime poinje sa test, je automatski prepoznata kao test metoda, tako da u ovom sluaju imamo samo jednu test metodu, testPrikazPoetneSTranice() koja je izvedena iz test scenarija prikazanog na slici 7. Ako test sluaj ima na primjer tri test scenarija, onda emo vidjeti tri test metode umjesto samo jedne. Slika 8 prikazuje izvedeni sekvencijalni dijagram PrikazDetaljaKnjige koji je vezan za ovaj test sluaj.

Slika 8. Izvod iz sekvencijalnog dijagrama Prikai poetnu stranicu

21

U ovom sluaju PoetnaKontroler se testira, i predmet poziva granini objekt, DispeerServlet. Test jedinica mora potvrditi da rezultati sa nosiocZahtjeva() je ono to oekujemo, s obzirom da se vrijednosti prenose. Metoda je:
public void testDisplayHomePage() throws Exception { HomeController homeController = new HomeController(); ModelAndView modelAndView = homeController.handleRequest(null, null);

assertEquals("Should be viewing home.jsp", "home", modelAndView.getViewName()); }

Sada kada imamo test, dobro je vjebati i pokuati uiniti ga neuspjenim, to e dokazati da e raditi kada nastupi i stvarni neuspjeh u budunosti. Moemo to uraditi pisajui praznu nosiocZahtjeva() metodu:

package com.iconixsw.bookstore.web; // import . . .

public class HomeController implements Controller {

public ModelAndView handleRequest( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException {

22

return new ModelAndView(""); } }

Ova verzija PoetnaKontroler, vraa prazno ime. Ako pokrenemo ponovo test jedinica dobit emo slijedee: ____________________________________________________________________________
.F Time: 0.015 There was 1 failure: 1) testDisplayHomePage (test.com.iconixsw.bookstore.web.DisplayHomePageTest)

junit.framework.ComparisonFailure: Should be viewing home.jsp. expected:<home> but was:<> at test.com.iconixsw.bookstore.web. DisplayHomePageTest.testDisplayHomePage (DisplayHomePageTest.java:17) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0 ______________________________________________________________________

23

To pokazuje da test mehanizam radi, pa moemo implementirati nosiocZahtjeva pravilno:

public ModelAndView handleRequest( HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { return new ModelAndView("home"); }

Pokretanjem testa trebali bi dobiti slijedee : _____________________________________________________________________________


. Time: 0.016 OK (1 test) ______________________________________________________________________

U test metodi loe kreiranje je stvaranje resursa koji bi trebali biti kreirani u setup() metodi koja se poziva prije svake test metode. Refaktorisani kod sada izgleda ovako:
package test.com.iconixsw.bookstore.web; // import statements omitted public class DisplayHomePageTest extends TestCase { private HomeController homeController; public DisplayHomePageTest(String testName) { super(testName); } public void setUp() throws Exception { 24

homeController = new HomeController(); } public void tearDown() throws Exception { homeController = null; } public void testDisplayHomePage() throws Exception { ModelAndView modelAndView = (null, null); assertEquals("Should be viewing home.jsp.", "home", modelAndView.getViewName()); } } homeController. handleRequest

Preokrenuli smo poetnaKontroler u privatnu varijablu i premjestili kod koji kreira u setUp() metodu. Takoe smo dodali teardown() metodu da podesimo poetnaKontrolor nazad na poetak. Ovo nije neophodno ali je dobro radi utede radne memorije u budunosti. Povratak na test pokazuje da ni jedna tvrdnja nije netana. Proi emo kroz isti process za ostale kontrolore prikazane u koritenom sluaju Prikai Detalje knjige.

2.3.Pokretanje testova iz test paketa Nismo jo uvijek pokazali kako da pokrenemo sve testove iz jednog pokuaja. To je jednostavno s JUnit-om. Mogue je grupirati sve klase testova jedinica zajedno u samo jedan test paket, i pokrenuti ga:
package test.com.iconixsw.bookstore; import test.com.iconixsw.bookstore.web.*; import junit.framework.*; 25

public class BookstoreTestSuite { public static Test suite() { TestSuite suite = new TestSuite(); suite.addTestSuite(DisplayHomePageTest.class); // add more tests here . . . return suite; } public static void main(String[] args) { junit.textui.TestRunner.run(suite()); } }

Ako pokrenemo InternetKnjiaraTestPaket iz komande, glavna metoda bit e nazvana paket(), koji e skupiti sve individualne test sluajeve zajedno, i vratiti ih zajedno u jedan predmet. Ovo e onda biti prebaeno u JUnit TestPokreta, koji proizvodi OK i Neuspjeh (failures) tekst rezultate koje emo vidjeti u primjeru. Kako piemo vie test klasa, dodajemo ih u test paket da bi se onda mogle pokrenuti zajedno. Ako se testovi izvode dovoljno brzo, to znai da moemo pokrenuti sve testove svaki put kada promijenimo neto ili dodamo neto novo.

2.4.Testiranje Preuzmi Detalje Knjige Kontroler (Retrieve Book Details Controller)

U ovom dijelu, kreiramo test scenario za Preuzmi Detalje Knjige Kontroler, i onda piemo i pokreemo njegovu JUnit test klasu. Ako spojimo Preuzmi Detalje Knjige Kontroler sa slijedeim tekstom: Kupac odabere link na poetnoj stranici i sistem preuzme detalje knjige od odabrane knjige

26

onda ovo sugerira da bi test trebao potvrditi da su knjige preuzete tano iz baze podataka. Da dodamo test sluaj u EA, dvoklikom otvorimo prozori Postavke i odaberemo Scenario tab. Onda moemo dodati osnovni i alternativni scenario u test sluaj. Slika 9 prikazuje dva test scenarija koja smo dodali za Preuzmi Detalje Knjige kontrolor/test sluaj.

Slika 9. Test scenario za Preuzmi detalje Knjige

Sada kada smo dodali test scenario potrebno je nadograivanje koritenog sluaja, robusni dijagram kako bi nacrtali sekvencijalni dijagram. Slijedea etapa je kreiranje kostura testa jedinica za ovaj test sluaj, koritenjem scenarija koji smo dodali. Sada emo pokazati kostur test
27

scenarija za Preuzmi Detalje Knjige kontroler/test sluaj. Stvarna test metoda (izvedena iz scenarija test sluaja) prikazana je crvenom bojom:

package test.com.iconixsw.bookstore.dao; import junit.framework.*; /** * Test case for the Retrieve Book Details controller. */ public class RetrieveBookDetailsTest extends TestCase { public RetrieveBookDetailsTest(String testName) { super(testName); } public void setUp() throws Exception { } public void tearDown() throws Exception { } public void testBookIdFound() { } public void testBookIdNotFound() { } }

Metode

testIdKnjigaPronaena()

(testBookIdFound())

testIdKnjigaNijePronaena()

(testBookIdNotFound()) su izvedene direktno iz dva scenarija prikazana na slici 9. Kao to smo ranije rekli, elimo da testiramo ID Knjiga pronaena (ili nije pronaena) direktno iz baze podataka. Zlatno pravilo za testove jedinica je to da oni trebaju imati mogunost brzog pokretanja. Ako testovi jedinica se ne pokreu brzo, onda se programeri nee uopte truditi da ih
28

pokreu tokom programiranja. Iz ovog razloga, dobra je praksa pokuati izbjei pisanje testova koji ostvaruju vezu sa vanjskim izvorima (npr. baza podataka). Povezivanje sa bazom podataka (ak i lokalnom) i pokretanje upita ili nadogradnji moe uiniti testove jedinica da se pokreu neproporcionalno sporo, posebno kada je ista postavka ili kod ponovljen vie od stotinu puta. Ali, ako ne moemo ukljuiti kod baze podataka u brzi test, kako da zapravo testiramo bilo ta? Jedan odgovor je da koristimo tzv. mock objekte (lane). Na primjer, moemo zamijeniti na JDBC specifine DAO klase sa lanom verzijom, ija je osnovna misija da osigura iste podatke test jedinica, iznova i iznova, ak veoma brzo. Dodat emo neke kodove u testnu klasu da preuzmemo ID Knjige i da potvrdimo da je primljen:
private BookDao bookDao; public void testBookIdFound() { Book book = bookDao.findById(1); assertNotNull("ID 1 should be found", book); }

Ako pokuamo da pokrenemo test jedinica sada, dobit emo NullPointerException, zbog toga to BookDao (knjiga osigurana) nije uitan:
public void setUp() throws Exception { bookDao = new MockBookDao(); }

Oito se ovo nee sastaviti iz razloga to ne postoji MockBookDao, i sada je dobro vrijeme da ga ubacimo:
package com.iconixsw.bookstore.dao.mock; // import statements omitted . . . public class MockBookDao implements BookDao { 29

private HashMap booksById; public MockBookDao() { initData(); }

public List findAll() throws DataAccessException { return (List) booksById.values(); } public Book findById(int bookId) throws DataAccessException { return (Book) booksById.get(new Integer(bookId)); } private void initData() { Book favWidgets = new Book(); favWidgets.setId(1); favWidgets.setTitle("My Favorite Widgets");

Book uncommon = new Book(); uncommon.setId(2); uncommon.setTitle("The Uncommon Event");

booksById = new HashMap(); booksById.put(new Integer(1), favWidgets); booksById.put(new Integer(2), uncommon); } }

30

BookDao ini najjedonostavniju moguu stvar, a to je kreiranje par objekata Knjiga i stavljanje tih objekata u HashMap, kljuem po ID knjige. Podaci se nikada ne spaavaju na vanjski disk ve u internoj memoriji. Sada kada imamo sastavljen test, trebali bi ga pokrenuti kroz JUnit, ali bi prvobitno trebali vidjeti neuspjeh testa kako bi potvrdili da test radi. Da bi to uradili samo emo kratko promijeniti initData() metodu na slijedei nain:
Book favWidgets = new Book(); favWidgets.setId(5); favWidgets.setTitle("My Favorite Widgets");

Jednostavno smo promjenili 1 u 5 tako da lani DAO ne vrati knjigu sa ID oznakom 1. Pokretanje testa sada e donijeti slijedee rezultate: _____________________________________________________________________________
.F Time: 0 There was 1 failure: 1) testBookIdFound (test.com.iconixsw.bookstore.dao.RetrieveBookDetailsTest) junit.framework.AssertionFailedError: ID 1 should be found at test.com.iconixsw.bookstore.dao. RetrieveBookDetailsTest. testBookIdFound(RetrieveBookDetailsTest.java:29) FAILURES!!! Tests run: 1, Failures: 1, Errors: 0 ____________________________________________________________________

31

Na ovaj nain moemo se uvjeriti da e test raditi ispravno kada doe do stvarnog neuspjeha testa. Sada kada vratimo vrijednost ponovo 1 i uradimo ponovo test dobit emo slijedee rezultate: ______________________________________________________________________________
. Time: 0 OK (1 test) ______________________________________________________________________

Trenutno testiramo samo jedan nain, odnosno Knjiga pronaena, trebamo to uraditi i za KnjigaNijePronaena:

public void testBookIdNotFound() { Book book = bookDao.findById(-1); assertNull("ID -1 should not be found", book); }

2.5.Testiranje Prikai Detalje Knjige Kontrolor Tekst u koritenom sluaju povezan za ovaj test sluaj je: sistem preuzima detalje knjige za izabranu knjigu i prikazuje ih na Pogledaj Detalje Knjige stranici. Slika 10 prikazuje test scenario koji je dodat u EA za ovaj test sluaj.

32

Slika 10. Test scenario za Prikai Detalje knjige kontrolor/test sluaj

Tu su tri scenarija: Stranica prikazana, Detalji knjige pronaeni i Detalji knjige nisu pronaeni Jedan od ovih scenarija nije u redu. Vraanjem u test sluaj prikazan u slici 6, uviamo da tamo ve postoji podjeljen alternativni test za test sluaj gdje detalji knjige nisu pronaeni. Tako za ovaj test sluaj, zapravo postoje dva test scenarija: Prikazana stanica i Detalji knjige pronaeni. Oba ova su osnovni test scenario, to ima smisla, zato to test sluaj sam po sebi, je za jednog kontrolora u osnovnom sluaju koritenog sluaja. Slika 11. prikazuje izvod iz sekvencijalnog dijagrama Prikai Detalje Knjige.

33

Slika 11. Izvod iz sekvencijalnog dijagrama Prikai Detalje Knjige Zapamtimo da trebamo pisati test sa take gledita objekta zvanog kontrolor. Pozivajui objekt je uglavnom granini objekt, iako moe takoe biti i drugi kontrolor. elimo da pozivi idu u kontrolor koji se testira. Kao to moemo vidjeti u slici 11, to znai testiranje dvije metode: rukovati() (handle()) i provjeriKnjigaPronaena() (checkBookFound()).

Slijedi kostur test klase za Prikai Detalje Knjige kontrolor/test sluaj (test metode su prikazane crvenom bojom):
package test.com.iconixsw.bookstore.web; import junit.framework.*; /** * Test case for the Display Book Details Page controller. */ public class DisplayBookDetailsPageTest extends TestCase { public DisplayBookDetailsPageTest(String testName) { 34

super(testName); } public void setUp() throws Exception { } public void tearDown() throws Exception { } public void testPageDisplayed()throws Exception { } public void testBookDetailsFound()throws Exception { } }

Provjeravanjem slike 11, eljet emo da kreiramo DetaljiKnjigeKontrolor objekat da poguramo i podstaknemo, i imalo bi smisla da to stavimo u setup() tako da isti osnovni kod bude podijeljen od strane obje test metode:
public void setUp() throws Exception { bookDetailsController = new BookDetailsController(); bookDetailsController.setBookDao(new MockBookDao()); } private BookDetailsController bookDetailsController;

U setUp(), sada kreiramo novi DetaljiKnjigeKontrolor:


public void setBookDao(BookDao bookDao) { this.bookDao = bookDao; } private BookDao bookDao;

35

Naredni kod pokazuje poetak prve metode:


testPageDisplayed(): public void testPageDisplayed() throws Exception { Book command = new Book(); command.setId(1); ModelAndView modelAndView = bookDetailsController.handle(null, null, command, null); // assert... }

Sada moemo dodati handle()-rukovati metodu u DetaljiKnjigeKontrolor:


protected ModelAndView handle( HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) throws Exception { return null; }

U poetku to nas vraa nuli, zato to elimo da budemo u mogunosti da prvo pokrenemo test i vidimo neuspjeh. Nazvat emo metodu test tako da kasnije znamo da je za test jedinica:
public ModelAndView testHandle(Book command) throws Exception { return handle(null, null, command, null); } 36

Jedini parametar koji je zapravo vaan je Knjiga. Sada moemo ponovo napisati test metodu za koritenje ove nove metode:

ModelAndView modelAndView = bookDetailsController.testHandle(command);

Provjerom

sekvencijalnog

dijagrama

slici

11.,

vidimo

da

druga

metoda

provjeraKnjigaPronaena(), je zapravo privatna metoda nazvana rukovati() (Handle()) tako da ne trebamo pisati specifinu metodu za to. Umjesto toga, izlaz iz provjeraKnjigaPronaena() e doprinijeti eventualnim izlazima iz rukovanje(), koji trebamo testirati. Sada moemo sastaviti ostatak, i oekivati neuspjeh. Slijedei korak je da napiemo stvarni kod za rukovanje() metodu, osim ako nismo dodali neku tvrdnju u dvije metode jo uvijek, tako da trenutno ne testiramo nita. To je veliki skup kodova sa mnogo duplikata, koje emo kasnije pretvoriti u neto kompaktnije.
public class DisplayBookDetailsPageTest extends TestCase { public DisplayBookDetailsPageTest(String testName) { super(testName); } public void setUp() throws Exception { bookDetailsController = new BookDetailsController(); bookDetailsController.setBookDao(new MockBookDao()); } private BookDetailsController bookDetailsController; public void tearDown() throws Exception { bookDetailsController = null; }

37

public void testPageDisplayed() throws Exception { Book command = new Book(); command.setId(1); ModelAndView modelAndView = BookDetailsController.testHandle(command); assertEquals("The bookdetails page should be displayed", "bookdetails", modelAndView.getViewName()); } public void testBookDetailsFound() throws Exception { BookDetailsCommand command = new BookDetailsCommand(); command.setId(1); ModelAndView modelAndView = bookDetailsController.testHandle(command); Map model = modelAndView.getModel(); Book book = (Book) model.get("book"); assertEquals("The book should have been found", 1, book.getId()); } }

Kao to moemo vidjeti, svaka test metoda radi manje ili vie iste stvari : postavlja komandni objekt Knjiga, dodjeljuje mu ID, koji onda prenosi u DetaljiKnjigeKontrolor i dobija ModelIPogled objekat nazad. Dvije metode testStranicaPrikazana() i testDetaljiKnjigePronaeni() dodjeljuju ID broj 1, postojei ID knjige iz razloga to su obje metode u osnovi iste. ini se da bi imalo smisla da prebacimo kod u setUp().
38

Stavljanjem koda u setUp(), dali bi do znanja da je ovo test postavka koda, a ne test kod, pa zbog toga, prebacujemo ga u odvojene metode. Evo rezultirajueg test koda (refaktorisani kod je prikazan crvenom bojom):
private Book command; public void setUp() throws Exception { command = new Book(); command.setId(1); } public void testPageDisplayed() throws Exception { ModelAndView modelAndView = callTestHandle(); assertEquals("The bookdetails page should be displayed.", "bookdetails", modelAndView.getViewName()); } public void testBookDetailsFound() throws Exception { ModelAndView modelAndView = callTestHandle(); Map model = modelAndView.getModel(); Book book = (Book) model.get("book"); assertEquals("The book should have been found.", 1, book.getId()); } private ModelAndView callTestHandle() { return bookDetailsController.testHandle(command); }

39

Pokretanjem ove klase testova, dobijamo crvene oznake svugdje zato to rukovanje() metoda jo uvijek vraa nulu, to moemo popraviti. Da zaokruimo ovaj test sluaj, moemo sad sigurno dodati realni kod u rukovanje() metodu u DetaljiKnjigeKontrolor:

protected ModelAndView handle( HttpServletRequest request, HttpServletResponse response, Object command, BindException errors) throws Exception { Book book = (Book) command; book.load(bookDao); return new ModelAndView("bookdetails", "book", book); }

Pokretanjem ovog koda kroz razliite testere jedinica dobijamo zeleno svjetlo, to znai da je test zadovoljio.

2.6.Testiranje Prikaz Stranica Knjiga Nije Pronaena Kontrolor (Display Book Not Found Page Controller) U zavrnom test sluaju, testiramo alternativne kurseve u kojima je ID knjige ne postoji. Tekst koritenog sluaja, koji povezuje sa ovim test sluajem je:

ALTERNATIVNI KURSEVI: Knjiga nije pronaena: Sistem prikazuje stranicu Detalji Knjige Nisu Pronaeni Slika 12. prikazuje test scenario koji je dodat u EA za ovaj test sluaj.

40

Tu su dva test scenarija: Stranica Knjiga Nije Pronaena Prikazana i Detalji Knjige Nisu Pronaeni . Oba ova scenarija su kategorizovana kao alternativni test scenariji, koji imaju smisla zato to je ovo test sluaj za kontrolora na alternativnom kursu u koritenom sluaju.

Slika 13. prikazuje izvod sekvencijalnog dijagrama koji pokriva dizajn za ovaj alternativni kurs.

Slika 12. Test scenarij za Knjiga Nije Pronaena kontrolor/test sluaj

41

Slika 13. Izvod iz sekvencijalnog dijagrama Prikai detalje knjige za alternativne kurseve

Pisanje kostura koda za klasu testa jedinica je jednostavna stvar prolaska kroz test scenarije za ovaj test sluaj i dodavanje test metode za svaki scenario. Test metode su prikazane crvenom bojom u slijedeem kodu:
public class DisplayBookNotFoundPageTest extends TestCase { public DisplayBookNotFoundPageTest(String testName) { super(testName); } public void setUp() throws Exception { } public void tearDown() throws Exception { } public void testBookNotFoundPageDisplayed() throws Exception {

42

} public void testBookDetailsNotFound() throws Exception { } }

Osnovni kod za ovu klasu e biti identian osnovnom kodu prethodnog test sluaja. Zapravo, kod koji ide u obje test metode je takoe veoma slian. Slika 14. prikazuje dvije klase koje bi trebale biti spojene. .

Slika 14. Dijagram klase za dva test sluaja Detalji Knjige (prvi pokuaj)

43

Problem sa ovim dizajnom je taj da kada pokrenemo StranicaPrikazKnjigaNijePronaenaTest, test iz roditeljske klase testova e se takoe pokrenuti. Moemo uzeti promodernistiki pristup i izbjei naslijedstvou korist agregacije. Drugim rijeima, moemo premjestiti zajedniki kod u odvojene pomone klase za oba test sluaja.(slika 15.)

Slika 15. Dijagram klase za dva Detalji knjige test sluaja

Zavrit emo ovo poglavlje sa 10 najveih greaka dizajnom voenog testiranja.

44

3. Deset najveih greaka dizajna voenog testiranjem Slijedi lista 10 najveih greaka koje ne bi trebali raditi: 10. Pretjerivati sa mock(lanim) objektima. 9. Duplicirati scenarije alternativnih kurseva u alternativne test scenarije za osnovne kurs kontrolore. 8. Zaboraviti da poveemo testove sa zahtjevima. 7. Ostaviti testiranje nakon to je napisan kod. 6. Zamijeniti testiranje sa dizajnom. 5. Ignorisati vrue take problema. 4. Koristiti nasilno testiranje umjesto identifikovanje, pa onda ciljanje vruih taki iz preliminarnog dizajna. 3. Koristiti pogrenu vrstu testiranja za pogrenu situaciju. 2. Zaboraviti uraditi testiranje uope. 1. Testirati toliko temeljito da nikada ne objavite proizvod.

45

Slika 16. Aktivnosti testiranja u toku faze implementacije

46

Zakljuak U ovom poglavlju pokrili smo razliite oblike koritenih sluajeva voenih testiranjem i opisali kada bi trebali koristiti svaki od njih. Dizaj voen testiranjem je metoda koja nam omoguava proizvodnju test sluajeva, kako bi se uvjerili da su svi naznaeni scenariji. Ovu metodu moemo takoe koristiti da napiemo izvrne testove testnih sluajeva. Naveli smo i definisali vrste testova koje se koriste i objasnili kako i kada se oni koriste. Takoe smo proli kroz primjer dizajna voenog testiranjem na primjeru Internet knjiare i napisali neke testove jedinica da pokrijemo Prikai Detalje Knjige koriteni sluaj.

Slika 16. pokazuje gdje smo trenutno. Aktivnosti koje su uraene u ovom poglavlju su prikazane crvenom bojom. Omoguili smo detaljan prikaz i diskusiju primjera uraenog u Agilnom dodataku ICONIX Procces-a u Enterprise Arhitect-u. Dodavanje osnovnih i alternativnih scenarija kao i postupak transformiranja robusnih dijagrama u sekvencijali ili dijagram test sluaja.

Jedna od kljunih taki u ovom poglavlju je da testovi ne dokazuju puno ako nisu uvezani na mikroskopskom nivou sa zahtjevima. Na kraju smo naveli 10 greki koje nikako ne bismo trebali initi u procesu testiranja. U slijedeem poglavlju govorit emo o zahtjevima i pokazat emo kako se oni uklapaju u ukupni proces.

47

Bibliografija

D. Rosenberg, M Stephens, Use case driven object modeling with UML: Theory and Practice, 2007.god.

48

Popis slika i tabela

Slike: Slika 1. V model softverskog testiranja primjenjljivog u ICONIX Procces-u Slika 2. Pregled DDT-a Slika 3. Koritenje Agilnog ICONIX/EA dodatka za generiranje dijagrama Slika 4. Generacija test sluajeva u EA Slika 5. Dodavanje test scenarija u EA Slika 6. Generirani test sluaj za prikai detalje knjige koriteni sluaj Slika 7. Dodavanje test scenarija za test sluaj Prikaz poetne stranice Slika 8. Izvod iz sekvencijalnog dijagrama Prikai poetnu stranicu Slika 9. Test scenario za Preuzmi detalje Knjige Slika 10. Test scenario za Prikai Detalje knjige kontrolor/test sluaj Slika 11. Izvod iz sekvencijalnog dijagrama Prikai Detalje Knjige Slika 12. Test scenarij za Knjiga Nije Pronaena kontrolor/test sluaj Slika 13. Izvod iz sekvencijalnog dijagrama Prikai detalje knjige za alternativne kurseve Slika 14. Dijagram klase za dva test sluaja Detalji Knjige (prvi pokuaj) Slika 15. Dijagram klase za dva Detalji knjige test sluaja Slika 16. Aktivnosti testiranja u toku faze implementacije

Tabele: Tabela 1. Razliite vrste testova i kada ih primjeniti Tabela 2. Testovi koji prolaze kroz razvojni proces

49

Вам также может понравиться