Poglavlje 2: Proces i nivoi testiranja
Priča za početak. Dana 27. marta 2008. godine na londonskom aerodromu Heathrow otvoren je novi, ogroman Terminal 5, ponos britanske avijacije, napravljen za nekoliko milijardi funti. Srce terminala bio je automatski sistem za prtljag: kilometri traka i računari koji su trebali svaki kofer odvesti do pravog aviona. Prvog jutra sistem je počeo zastajati. Radnici nisu mogli ući na vrijeme jer nisu znali gdje je parking za osoblje, nekoliko traka je stalo, a softver nije znao šta da radi s koferima koji su stigli kad ih nije očekivao. Već prvog dana otkazani su deseci letova, a putnici su putovali bez prtljaga. Prema izvještajima iz tih dana, u prvih nekoliko dana otkazano je skoro 300 letova, a oko 15 000 kofera odvojeno je od vlasnika. Sistem je prije otvaranja testiran, ali uglavnom dio po dio. Ono što nije dovoljno testirano bilo je sve zajedno: hiljade stvarnih kofera, stvarni radnici koji prvi put rade u novoj zgradi, i sve situacije koje se dešavaju u pravom jutru na aerodromu. Jedan dio sistema radio je, drugi dio je radio, ali sistem nije radio.
U poglavlju 1 naučili smo šta su defekt i otkaz i zašto testiramo, i napravili prvu tabelu očekivanih rezultata. Ovo poglavlje odgovara na pitanje kako je testiranje organizovano. Prvo upoznajemo test proces: korake od planiranja do izvještaja. Zatim nivoe testiranja, od jedne funkcije do cijelog sistema u rukama korisnika, i kako se slažu u V-model i u agilni rad. Na kraju vrste testova i statičko testiranje: pronalaženje defekata čitanjem, bez pokretanja programa. Na praktičnoj nastavi radimo recenziju zahtjeva DeliveryApp i nalazimo nejasnoću koja je promakla svima, pa i programerima.
Literatura. Osnovna literatura predmeta:
- J. Popović: Priručnik za test inženjere, CET i Računarski fakultet, Beograd, 2023.
- Rakić-Skoković: Priručnik za testiranje softvera, Fakultet tehničkih nauka, Novi Sad, 2013.
- G. J. Myers: The Art of Software Testing, 2. izdanje, John Wiley & Sons, 2004.
- A. P. Mathur: Foundations of Software Testing, Addison-Wesley Professional, 2008.
Riječi ovog poglavlja.
- Test proces – dogovoren niz aktivnosti testiranja: planiranje, analiza, dizajn, implementacija, izvršavanje i završetak.
- Test baza – dokumenti iz kojih izvodimo testove (zahtjevi, pravila, modeli, kod).
- Test uslov – nešto što treba provjeriti (npr. „besplatna dostava na granici 30,00 €”).
- Test slučaj – konkretan ulaz, koraci i očekivani rezultat za jedan test uslov.
- Testni materijal (testware) – sve što testiranje proizvede: plan, test slučajevi, podaci, skripte, izvještaji.
- Nivo testiranja – grupa testova za jedan sloj sistema: komponentni, integracioni, sistemski, prihvatni.
- V-model – model u kojem svaka faza razvoja ima svoj par na strani testiranja.
- Funkcionalno i nefunkcionalno testiranje – provjera šta sistem radi, i kakav je dok to radi (brzina, sigurnost, upotrebljivost).
- Potvrdno testiranje – ponavljanje testa koji je pao, da se potvrdi da je defekt ispravljen.
- Regresiono testiranje – provjera da izmjena nije pokvarila nešto što je ranije radilo.
- Dim-test (smoke test) – kratak test najvažnijih funkcija, da se vidi da sistem uopšte „diše”.
- Statičko testiranje – pronalaženje defekata bez pokretanja programa: čitanjem i alatima koji analiziraju kod.
- Recenzija – pregled dokumenta ili koda od strane drugih ljudi, radi pronalaženja defekata.
Ciljevi poglavlja. Nakon poglavlja možete: nabrojati aktivnosti test procesa i za svaku reći šta nastaje; izvesti iz pravila test uslove i test slučajeve i povezati ih sljedivošću; razlikovati komponentno, integraciono, sistemsko i prihvatno testiranje po cilju, osnovi, okruženju i izvršiocu; objasniti V-model i testiranje u agilnom timu; razlikovati funkcionalno i nefunkcionalno, potvrdno i regresiono testiranje i dim-test; objasniti statičko testiranje i četiri vrste recenzija; provesti recenziju zahtjeva DeliveryApp i zapisati nejasnoće; pokazati da Python zaokružuje 214,5 centi na 214 i objasniti zašto je to defekt u zahtjevu, a ne nužno u kodu.
Plan poglavlja – Sedmica 2: tri časa teorije i tri časa praktične nastave
| Čas | Sadržaj | Na času |
|---|---|---|
| Teorija 1 | 2.1–2.3 Test proces; test uslov i test slučaj; sljedivost | Od PP-4 do četiri test slučaja |
| Teorija 2 | 2.4–2.6 Nivoi; V-model; testiranje u agilnom timu | Heathrow T5: dijelovi rade, sistem ne |
| Teorija 3 | 2.7–2.9 Vrste testova; statičko testiranje; recenzije | 21,45 € → popust 2,14 € ili 2,15 €? |
| Praksa 1–3 | Recenzija zahtjeva DeliveryApp; spisak nejasnoća; matrica sljedivosti | recenzija.md |
Dio 1 – Test proces
2.1 Šest aktivnosti testiranja
Testiranje nije jedna radnja („pokreni program i vidi”), nego niz aktivnosti. ISTQB ih opisuje ovako, a mi ih pratimo na pravilu PP-4 DeliveryApp (od 30,00 € dostava je besplatna):
| Aktivnost | Pitanje | Šta nastaje (PP-4) |
|---|---|---|
| Planiranje | Šta testiramo, kako, ko, do kada, kada smo gotovi? | plan: obračun cijene testira se prvi, jer je najrizičniji |
| Praćenje i kontrola | Idemo li po planu? Šta mijenjamo? | sedmični pregled: koliko testova napisano, koliko prolazi |
| Analiza | Šta treba provjeriti? | test uslovi: „besplatna dostava na granici”, „dostava ispod granice” |
| Dizajn | Kako to provjeriti? | test slučajevi: 30,00 € na 5 km → 0,00 €; 29,99 € → 3,00 € |
| Implementacija | Šta treba pripremiti? | podaci (jelovnik, adrese), okruženje, skripte testova |
| Izvršavanje | Pokrećemo i poredimo | rezultat: prolazi / pada; izvještaj o defektu za ono što pada |
| Završetak | Šta smo naučili? | izvještaj o testiranju, arhiviran testni materijal, pouke |
Aktivnosti se ne moraju raditi strogo jedna za drugom. U agilnom timu (2.6) one se ponavljaju u svakom sprintu, za svaku korisničku priču, a neke se preklapaju. Ali svaka se mora desiti. Najčešće se preskače analiza: tester odmah piše test slučajeve, i onda pokrije ono što mu prvo padne na pamet, a ne ono što je važno.
Sve što testiranje proizvede (plan, uslovi, slučajevi, podaci, skripte, izvještaji) zove se testni materijal (testware). Čuva se kao i kod: u Gitu, s verzijama.
Ukratko.
- Test proces ima aktivnosti: planiranje, praćenje i kontrola, analiza, dizajn, implementacija, izvršavanje i završetak.
- Analiza odgovara na pitanje šta provjeriti, a dizajn kako.
- U agilnom timu aktivnosti se ponavljaju za svaku priču, ali se nijedna ne preskače.
- Testni materijal se čuva kao kod, u Gitu.
2.2 Test baza, test uslov, test slučaj
Tri pojma vode od pravila do testa:
- Test baza je ono iz čega izvodimo testove: pravila PP-1 do PP-6, korisničke priče s kriterijima prihvatanja, modeli (dijagram stanja narudžbe), API ugovor, pa i sam kod.
- Test uslov je šta treba provjeriti, rečeno opšte. Iz PP-4: „dostava je besplatna za artikle od 30,00 € i više”; „dostava se plaća ispod 30,00 €”; „besplatna dostava gleda iznos prije popusta” (iz PP-5).
- Test slučaj je konkretan ulaz, preduslovi, koraci i očekivani rezultat za jedan uslov.
| Test uslov (iz PP-4 i PP-5) | Test slučaj | Ulaz | Očekivano |
|---|---|---|---|
| TU-4.1 besplatno od 30,00 € | TS-4.1a | artikli 30,00 €, 5 km | dostava 0,00 € |
| TU-4.1 | TS-4.1b | artikli 32,00 €, 2,5 km (N-1002) | dostava 0,00 €, ukupno 32,00 € |
| TU-4.2 plaća se ispod 30,00 € | TS-4.2a | artikli 29,99 €, 5 km | dostava 3,00 € |
| TU-4.3 besplatno gleda iznos prije popusta | TS-4.3a | artikli 32,00 €, 2,5 km, STUDENT10 | dostava 0,00 €; popust 3,20 €; ukupno 28,80 € |
Posljednji red je zanimljiv. Poslije popusta artikli koštaju 28,80 €, ispod 30,00 €. Da je pravilo glasilo „gleda iznos poslije popusta”, dostava bi se plaćala. PP-5 kaže „prije popusta”, pa je dostava besplatna. Bez ovog test uslova, takav detalj lako promakne i programeru i testeru.
Jedan test uslov obično ima više test slučajeva (granica i vrijednost daleko od granice), a jedan test slučaj ponekad pokriva više uslova.
Ukratko.
- Test baza su dokumenti iz kojih izvodimo testove; test uslov kaže šta provjeriti; test slučaj daje konkretan ulaz i očekivani rezultat.
- Iz PP-4 i PP-5 nastaju uslovi o besplatnoj dostavi, plaćenoj dostavi i iznosu prije popusta.
- N-1002 sa STUDENT10 ima besplatnu dostavu i ukupno 28,80 €, jer se gleda iznos prije popusta.
2.3 Sljedivost
Sljedivost znači da se za svaki test zna koje pravilo provjerava, i za svako pravilo koji ga testovi provjeravaju. Pravi se kao tabela, matrica sljedivosti:
| Pravilo | Test uslovi | Test slučajevi | Stanje |
|---|---|---|---|
| PP-1 | TU-1.1 odbija ispod 5,00 €; TU-1.2 prima od 5,00 € | TS-1.1a (4,99 €), TS-1.2a (5,00 €) | 2 / 2 prolaze |
| PP-2 | TU-2.1 do 3 km; TU-2.2 započeti km | TS-2.1a (3 km), TS-2.2a (3,1 km), TS-2.2b (4,2 km) | 3 / 3 |
| PP-4 | TU-4.1, TU-4.2, TU-4.3 | TS-4.1a, TS-4.1b, TS-4.2a, TS-4.3a | 4 / 4 |
| PP-6 | TU-6.1 otkazivanje dozvoljeno u NOVA i PRIHVAĆENA; TU-6.2 nije u U_PRIPREMI | … | … |
Sljedivost odgovara na tri pitanja koja tester stalno dobija:
- „Je li ovo pravilo testirano?” Red u matrici, i odgovor u sekundi.
- „Šta treba ponovo testirati ako se pravilo promijeni?” Ako udruženje promijeni PP-2 (dostava poskupi na 2,50 €), matrica pokazuje tačno tri test slučaja koja se mijenjaju.
- „Koliko smo gotovi?” Broj pravila s testovima koji prolaze, prema ukupnom broju pravila.
Ukratko.
- Sljedivost povezuje svako pravilo s testovima koji ga provjeravaju, i obrnuto.
- Matrica sljedivosti odgovara je li pravilo testirano, šta ponoviti kad se pravilo promijeni i koliko smo gotovi.
- Promjena PP-2 u matrici odmah pokazuje koja tri test slučaja treba izmijeniti.
Provjeri se.
- Koja aktivnost odgovara na pitanje „šta provjeriti”? – Analiza.
- Koliko je ukupno za N-1002 sa kodom STUDENT10? – 28,80 €: artikli 32,00 €, popust 3,20 €, dostava besplatna jer se gleda iznos prije popusta.
- Čemu služi matrica sljedivosti? – Da se za svako pravilo vidi koji ga testovi provjeravaju, i obrnuto.
Dio 2 – Nivoi testiranja
2.4 Četiri nivoa
Sistem se testira na više nivoa, od najmanjeg dijela do cijelog sistema u rukama korisnika. Svaki nivo ima svoj cilj, osnovu, okruženje i izvršioca:
| Nivo | Šta testiramo | Test baza | Ko obično | Primjer u DeliveryApp |
|---|---|---|---|---|
| Komponentno (jedinično) | jednu funkciju, klasu ili modul, izolovano | kod, dizajn | programer | cijena_dostave(4.2, 2150) == 300 |
| Integraciono | saradnju komponenti ili sistema | arhitektura, API ugovor | programer, tester | API prima narudžbu i upisuje je u bazu |
| Sistemsko | cijeli sistem, s kraja na kraj | zahtjevi, slučajevi korištenja, NZ | tester | kupac naruči kroz aplikaciju, restoran prihvati, dostavljač preda |
| Prihvatno | da li sistem odgovara korisniku i poslu | potrebe korisnika, ugovor, propisi | korisnici, naručilac | vlasnik Picerije R-1 jedan dan radi sa DeliveryApp |
Na integracionom nivou razlikuju se dvije vrste: integracija komponenti (dijelovi našeg sistema: API i baza) i integracija sistema (naš sistem i tuđi: DeliveryApp i sistem plaćanja, servis mapa).
Prihvatno testiranje ima nekoliko oblika: korisničko (UAT, user acceptance testing: rade li krajnji korisnici svoj posao?), operativno (mogu li ljudi koji održavaju sistem napraviti kopiju, vratiti je, pratiti sistem?), ugovorno i regulatorno (ispunjava li ugovor i zakon, npr. o zaštiti podataka) i alfa i beta testiranje (alfa: korisnici probaju u našem okruženju; beta: odabrani korisnici koriste sistem kod sebe prije zvaničnog početka).
Priča s Heathrowa je udžbenički primjer šta se desi kad su niži nivoi dobro pokriveni, a sistemsko i operativno prihvatno testiranje nisu urađeni u stvarnim uslovima: s pravim brojem kofera, s radnicima koji prvi put rade u zgradi, sa svim neočekivanim situacijama jednog jutra.
Slika iz života: gradnja automobila. Komponentno testiranje provjerava kočnicu na stolu. Integraciono provjerava kočnicu spojenu s papučicom i točkom. Sistemsko provjerava cijeli auto na poligonu. Prihvatno je kad kupac proba auto u svom gradu i kaže „to je to”.
Ukratko.
- Nivoi su komponentno, integraciono, sistemsko i prihvatno testiranje, od jedne funkcije do korisnika.
- Integracija može biti komponenti (naši dijelovi) ili sistema (naš i tuđi sistem).
- Prihvatno testiranje je korisničko, operativno, ugovorno i regulatorno, te alfa i beta.
- Heathrow 2008. pokazuje cijenu slabog sistemskog i operativnog testiranja u stvarnim uslovima.
2.5 V-model
V-model crta razvoj i testiranje kao slovo V. Lijeva strana se spušta od opšteg ka detaljnom (zahtjevi korisnika, zahtjevi sistema, arhitektura, detaljan dizajn, kod), a desna se penje od detaljnog ka opštem, s testovima koji provjeravaju svaku lijevu fazu:
| Lijevo (šta odlučujemo) | Desno (kako provjeravamo) |
|---|---|
| potrebe i zahtjevi korisnika | prihvatno testiranje |
| zahtjevi sistema | sistemsko testiranje |
| arhitektura | integraciono testiranje |
| detaljan dizajn i kod | komponentno testiranje |
Najvažnija ideja V-modela nije oblik slova, nego to da se test planira i dizajnira u istom trenutku kad nastaje ono što provjerava. Kad analitičar napiše PP-4, tester odmah piše TS-4.1a i TS-4.2a. Ako pri tome pita „a šta je s tačno 30,00 €?”, nejasnoća se ispravlja dok je to samo rečenica. Ovo je princip 3 iz poglavlja 1 (rano testiranje), nacrtan.
Ukratko.
- V-model povezuje svaku fazu razvoja s nivoom testiranja koji je provjerava.
- Zahtjevima korisnika odgovara prihvatno, zahtjevima sistema sistemsko, arhitekturi integraciono, a kodu komponentno testiranje.
- Test se dizajnira kad nastaje ono što provjerava, pa se nejasnoće otkriju rano.
2.6 Testiranje u agilnom timu
U agilnom timu (Scrum, poglavlje 2 udžbenika Projektovanje informacionih sistema) sistem se pravi u kratkim sprintovima od dvije sedmice, a svaki sprint mora dati inkrement koji radi. Testiranje se zato ne ostavlja „za kraj projekta”, nego se radi u svakom sprintu, za svaku priču:
- tester učestvuje u pisanju kriterija prihvatanja priče, prije programiranja (tri amigosa: vlasnik proizvoda, programer i tester zajedno pregledaju priču);
- programer piše jedinične testove uz kod;
- tester piše i automatizuje testove višeg nivoa i istražuje (poglavlje 3);
- priča nije gotova dok ne prođe testove iz Definicije gotovog;
- automatski testovi se pokreću pri svakoj izmjeni (CI, poglavlje 14), kao zaštita od regresije.
Ovaj pristup se zove i pomjeranje ulijevo (shift left): na vremenskoj liniji projekta testiranje se pomjera s kraja prema početku. Postoji i pomjeranje udesno (shift right): testiranje i praćenje sistema i poslije isporuke, u radu, kroz nadzor i postepenu isporuku (CrowdStrike, poglavlje 1).
Ni u agilnom timu nivoi ne nestaju. Komponentni, integracioni, sistemski i prihvatni testovi postoje i dalje, samo se rade u malim komadima, stalno.
Česta zabluda. „U agilnom timu nema testera, programeri sve testiraju sami.” Programeri pišu mnogo testova, ali pogled testera (šta bi moglo poći naopako, šta korisnik zaista radi) i dalje je potreban. Nekad ga nosi posebna osoba, nekad cijeli tim, ali ga ne smije nestati.
Ukratko.
- U agilnom timu testira se u svakom sprintu, za svaku priču, od kriterija prihvatanja do automatskih testova.
- Pomjeranje ulijevo znači testirati ranije, a pomjeranje udesno pratiti i testirati i poslije isporuke.
- Nivoi testiranja ostaju, samo se rade u malim komadima.
Provjeri se.
- Na kojem nivou je test „API upisuje narudžbu u bazu”? – Integraciono (integracija komponenti).
- Šta je beta testiranje? – Odabrani korisnici koriste sistem kod sebe prije zvaničnog početka.
- Šta znači pomjeranje ulijevo? – Testiranje počinje ranije, već pri pisanju zahtjeva.
Dio 3 – Vrste testova i statičko testiranje
2.7 Vrste testova
Nivo kaže gdje testiramo. Vrsta kaže šta testiramo:
| Vrsta | Pitanje | Primjer u DeliveryApp |
|---|---|---|
| funkcionalno | Radi li sistem ono što treba? | cijena dostave po PP-2 do PP-4 |
| nefunkcionalno | Kakav je dok to radi? | 95 % odgovora ≤ 2 s (NZ-1), kontrast (NZ-4), sigurnost (NZ-3) |
| bijela kutija | Je li prošao svaki dio koda? | svaki if u cijena_dostave izvršen u oba smjera (poglavlje 6) |
| crna kutija | Radi li po specifikaciji, bez gledanja koda? | granice 3 km, 10 km, 30,00 € (poglavlje 8) |
| potvrdno | Je li ispravljen defekt zaista ispravljen? | ponovo pokrenut test za 30,00 € poslije ispravke |
| regresiono | Je li izmjena pokvarila nešto drugo? | poslije ispravke popusta, ponovo svi testovi cijene |
| dim-test | „Diše” li sistem uopšte? | aplikacija se otvara, jelovnik se učitava, N-1001 košta 24,50 € |
Razlika između potvrdnog i regresionog testiranja važna je i često se brka. Potvrdno testiranje provjerava isto mjesto: test koji je pao sada prolazi. Regresiono provjerava sva ostala mjesta: da popravka česme nije poplavila kupatilo. Programer koji ispravi > u >= u PP-4 može slučajno promijeniti i nešto drugo; regresioni testovi to uhvate. Zato se regresioni testovi skoro uvijek automatizuju i pokreću pri svakoj izmjeni (poglavlje 4).
Dim-test (smoke test) je kratak skup od nekoliko testova najvažnijih funkcija, koji se pokrene odmah poslije isporuke nove verzije. Ime dolazi iz elektronike: kad se novi uređaj prvi put uključi, prvo se gleda da li se dimi. Da je Knight Capital imao dim-test koji provjerava da li svih osam servera radi istu verziju, priča iz poglavlja 1 bi bila kraća.
Ukratko.
- Vrste testova su funkcionalno i nefunkcionalno, bijela i crna kutija, potvrdno i regresiono testiranje i dim-test.
- Potvrdno testiranje provjerava da je defekt ispravljen, a regresiono da izmjena nije pokvarila ništa drugo.
- Dim-test brzo provjerava najvažnije funkcije odmah poslije isporuke.
2.8 Statičko testiranje
Do sada smo testirali pokretanjem programa: to je dinamičko testiranje. Ali mnogo defekata može se naći bez pokretanja, čitanjem dokumenata i koda ili alatima koji kod analiziraju. To je statičko testiranje, i ono je najjeftinije, jer nalazi defekte najranije, često prije nego što kod uopšte postoji.
Statičko testiranje nalazi stvari koje dinamičko teško nalazi:
- nejasnoće i protivrječnosti u zahtjevima (šta je s tačno 3 km? kako se zaokružuje popust?);
- nedostajuće zahtjeve (šta ako restoran ne odgovori?);
- odstupanja od standarda u kodu (nazivi, struktura);
- mrtav kod i nekorištene varijable (Knight Capital!);
- sigurnosne slabosti u kodu (lozinka zapisana u kodu, SQL zalijepljen iz unosa).
Primjer iz DeliveryApp pokazuje snagu statičkog testiranja. PP-5 kaže da STUDENT10 daje 10 % popusta. Recenzent pita: 10 % od 21,45 € je 2,145 €; da li je popust 2,14 € ili 2,15 €? U pravilu to ne piše. A kod DeliveryApp koristi Pythonovu funkciju round, koja zaokružuje „na parno” (banker’s rounding): broj tačno na pola zaokruži prema parnom broju. Zato je popust(2145, "STUDENT10") jednako 214 centi (2,14 €), a popust(2155, "STUDENT10") jednako 216 centi (2,16 €). Većina ljudi bi u školi naučila da se 214,5 zaokružuje na 215.
Je li to defekt u kodu? Ne nužno. To je defekt u zahtjevu: pravilo ne kaže kako se zaokružuje, pa programer nije imao po čemu da odluči. Kupac koji ručno izračuna 2,15 € i vidi 2,14 € mogao bi pomisliti da ga aplikacija vara za cent. Statičko testiranje je ovo našlo čitanjem, a ispravka je jedna rečenica u PP-5 („popust se zaokružuje na cijeli cent, pola centa naviše”) i jedan red koda.
Iz stvarnog svijeta. Pitanje zaokruživanja novca nije sitnica. Zakoni i pravila mnogih zemalja tačno propisuju kako se zaokružuju porezi i cijene, a banke i fiskalne kase moraju to raditi isto, jer cent na milion računa postaje deset hiljada eura.
Ukratko.
- Statičko testiranje nalazi defekte bez pokretanja programa: čitanjem dokumenata i koda i alatima za analizu.
- Nalazi nejasnoće u zahtjevima, nedostajuće zahtjeve, mrtav kod i sigurnosne slabosti.
- Python round zaokružuje na parno: popust na 21,45 € je 2,14 €, a na 21,55 € 2,16 €.
- To je defekt u zahtjevu PP-5, koji ne kaže kako se zaokružuje, pronađen čitanjem.
2.9 Recenzije
Recenzija je pregled dokumenta ili koda od strane drugih ljudi, radi pronalaženja defekata i poboljšanja. Recenzije se razlikuju po formalnosti:
| Vrsta | Kako izgleda | Kada |
|---|---|---|
| neformalna | kolega pogleda izmjenu i kaže šta misli | svakodnevno, npr. pull request |
| prolaz (walkthrough) | autor vodi grupu kroz dokument i objašnjava | da tim razumije i nađe pitanja |
| tehnička recenzija | stručnjaci pregledaju po listi i dogovore odluke | arhitektura, važni dizajn |
| inspekcija | najformalnija: uloge (moderator, čitač, zapisničar), lista, mjerenje broja nađenih defekata | sigurnosno kritičan softver |
Bez obzira na vrstu, dobra recenzija ima nekoliko pravila:
- Jasan cilj („nađi nejasnoće u PP-1 do PP-6”), a ne „pogledaj malo”.
- Lista za pregled: pitanja koja se postavljaju svakom pravilu (je li jasno, provjerljivo, potpuno, bez protivrječnosti; šta je na granicama; kako se zaokružuje; šta je s praznim i negativnim vrijednostima).
- Priprema: učesnici čitaju unaprijed, sami.
- Kritikuje se dokument, ne autor: „PP-5 ne kaže kako se zaokružuje”, a ne „ti nisi napisao kako se zaokružuje”.
- Zapis: svaki nalaz se zapiše s mjestom, opisom i ozbiljnošću, i prati se do ispravke.
Lista za pregled pravila DeliveryApp, koju koristimo na praktičnoj nastavi:
| Pitanje | Primjer nalaza |
|---|---|
| Šta je tačno na granici? | PP-2: tačno 3 km? (jasno: 2,00 €) PP-4: tačno 30,00 €? (jasno: „i više”) |
| Kako se zaokružuje? | PP-5: 10 % od 21,45 € nije rečeno |
| Šta s praznim, nultim, negativnim? | PP-3: 0 km je dozvoljeno; da li je adresa restorana u restoranu (0 km) moguća narudžba? |
| Ima li protivrječnosti? | PP-4 i PP-5: koji iznos gleda besplatna dostava (riješeno: prije popusta) |
| Šta nedostaje? | Šta ako restoran ne odgovori? Šta ako se jelo rasproda dok je u korpi? |
| Može li se testirati? | „Dostava mora biti brza” bi pala; PP-2 je provjerljiv |
Ukratko.
- Recenzija je pregled dokumenta ili koda od drugih ljudi; vrste su neformalna, prolaz, tehnička recenzija i inspekcija.
- Dobra recenzija ima jasan cilj, listu za pregled, pripremu, kritiku dokumenta a ne autora, i zapis nalaza.
- Lista za pravila DeliveryApp pita za granice, zaokruživanje, prazne i negativne vrijednosti, protivrječnosti, nedostatke i provjerljivost.
Provjeri se.
- Po čemu se statičko razlikuje od dinamičkog testiranja? – Statičko ne pokreće program, nego čita i analizira; dinamičko pokreće program.
- Koliki je popust na 21,45 € u kodu DeliveryApp? – 214 centi (2,14 €), jer round zaokružuje na parno.
- Koja je razlika između potvrdnog i regresionog testiranja? – Potvrdno provjerava da je defekt ispravljen, a regresiono da izmjena nije pokvarila ništa drugo.
Praktična nastava – recenzija zahtjeva DeliveryApp
Cilj je provesti pravu recenziju pravila DeliveryApp, zapisati nalaze, potvrditi jedan nalaz u kodu i napraviti matricu sljedivosti. Radi se u grupama od četiri studenta, a rezultati idu u repozitorij deliveryapp-testovi.
Korak 1 – Priprema (20 minuta, svako sam)
- Pročitajte pravila PP-1 do PP-6 i nefunkcionalne zahtjeve NZ-1 do NZ-5 iz
SADRZAJ.md(ili uvoda knjige). - Uz listu za pregled iz 2.9, svako za sebe zapiše najmanje pet pitanja ili nalaza. Ne razgovarajte još; cilj je da svako nađe svoje.
Korak 2 – Sastanak recenzije (40 minuta)
- Podijelite uloge: moderator (vodi i pazi na vrijeme), autor (brani pravila kao da ih je napisao, objašnjava namjeru), zapisničar i recenzent.
- Prođite pravila redom. Za svaki nalaz zapisničar upisuje u
recenzija.md:
| ID | Pravilo | Nalaz | Vrsta | Ozbiljnost | Prijedlog |
|---|---|---|---|---|---|
| R-01 | PP-5 | nije rečeno kako se zaokružuje 10 % (npr. 21,45 € → 2,145 €) | nejasnoća | srednja | „zaokružuje se na cijeli cent, pola naviše” |
Vrste: nejasnoća, nedostaje, protivrječnost, neprovjerljivo. Ozbiljnost: niska, srednja, visoka. 3. Na kraju moderator pročita sve nalaze i grupa za svaki odluči: prihvaćeno (pravilo treba izmijeniti), objašnjeno (pravilo je jasno, nalaz je pogrešno čitanje) ili otvoreno pitanje za naručioca.
Korak 3 – Potvrda nalaza u kodu (20 minuta)
Provjerite nalaz o zaokruživanju u Pythonu:
>>> from deliveryapp import popust
>>> popust(2145, "STUDENT10")
214
>>> popust(2155, "STUDENT10")
216
>>> round(214.5), round(215.5), round(2.5), round(3.5)
(214, 216, 2, 4)Zapišite u recenzija.md zašto je ovo defekt u zahtjevu i šta bi trebalo promijeniti i u pravilu i u kodu. (U Pythonu se zaokruživanje „pola naviše” za pozitivne cijele cente može napisati kao (iznos * procenat + 50) // 100; provjerite da za 2145 daje 215.)
Korak 4 – Test uslovi i matrica sljedivosti (40 minuta)
- Za svako od pravila PP-1 do PP-6 napišite bar dva test uslova i za svaki uslov bar jedan test slučaj s konkretnim ulazom i očekivanim rezultatom, u tabeli kao u 2.2.
- Napravite matricu sljedivosti kao u 2.3. Dodajte kolonu „Nivo” (komponentni, integracioni, sistemski, prihvatni) i za svaki test slučaj odlučite na kojem nivou bi se najprirodnije izvršio.
- Za NZ-1 i NZ-4 napišite po jedan test uslov i recite na kojem nivou i kojom vrstom testa (funkcionalno ili nefunkcionalno) se provjeravaju.
Korak 5 – Dim-test (15 minuta)
Napišite listu od pet koraka dim-testa koji bi se pokretao odmah poslije svake nove verzije DeliveryApp. Za svaki korak navedite očekivani rezultat (npr. „N-1001 u pregledu korpe pokazuje 24,50 €”).
Korak 6 – AI kao recenzent (opcionalno)
Dajte AI asistentu pravila PP-1 do PP-6 i zatražite: „Kao recenzent zahtjeva, nađi nejasnoće, nedostatke i protivrječnosti.” Uporedite s nalazima svoje grupe. Koji nalaz je našao AI, a grupa nije, i obrnuto? Provjerite svaki AI nalaz: je li zaista nejasnoća, ili AI nije pažljivo pročitao pravilo (npr. tvrdi da nije rečeno šta je s tačno 30,00 €, iako PP-4 kaže „i više”)?
Rezultat koji se predaje: recenzija.md s najmanje deset nalaza i odlukama, potvrdom nalaza o zaokruživanju, tabelom test uslova i slučajeva, matricom sljedivosti s nivoima i dim-testom od pet koraka.
Vježbe
Vježba za studenta 1 – aktivnosti procesa.
U kojoj aktivnosti test procesa nastaje: a) odluka da se obračun cijene testira prvi; b) tabela „30,00 € na 5 km → 0,00 €”; c) baza s izmišljenim jelovnikom za testove; d) izvještaj da je od 40 testova 38 prošlo; e) zaključak da treba više testova za popust jer je tamo nađeno najviše defekata.
Rješenje. a) planiranje; b) dizajn; c) implementacija; d) izvršavanje (i praćenje); e) završetak (pouke) ili kontrola.
Vježba za studenta 2 – nivo testiranja.
Na kojem nivou je test? a) popust(8000, "STUDENT10") == 500; b) DeliveryApp šalje iznos sistemu plaćanja i dobija potvrdu; c) kupac kroz aplikaciju naruči N-1001, restoran je prihvati, dostavljač preda; d) vlasnik R-2 tri dana koristi DeliveryApp u svom restoranu.
Rješenje. a) komponentno; b) integraciono (integracija sistema); c) sistemsko; d) prihvatno (korisničko, odnosno beta, ako je prije zvaničnog početka).
Vježba za studenta 3 – potvrdno ili regresiono.
Programer je ispravio defekt da kod student10 (mala slova) ne daje popust. Tester pokreće: a) test s student10; b) sve testove obračuna cijene; c) test N-1001 sa STUDENT10. Koji je potvrdni, a koji regresioni?
Rješenje. a) potvrdni (isto mjesto: provjerava ispravku). b) regresioni (sve ostalo). c) regresioni (provjerava da je raniji, ispravan slučaj i dalje ispravan).
Vježba za studenta 4 – test uslov za PP-5.
Napišite tri test uslova za PP-5 i za svaki jedan test slučaj s očekivanim rezultatom.
Rješenje. TU-5.1 važeći kod daje 10 %: artikli 21,50 € sa STUDENT10 → popust 2,15 €. TU-5.2 velika i mala slova i razmaci se zanemaruju: " student10 " na 21,50 € → 2,15 €. TU-5.3 gornja granica 5,00 €: artikli 80,00 € → popust 5,00 € (ne 8,00 €). (Prihvatljivi su i nepoznat kod → 0,00 € i popust ne dira dostavu.)
Vježba za studenta 5 – zaokruživanje.
Za iznose artikala 21,45 €, 21,55 € i 21,65 € izračunajte popust od 10 % „školski” (pola naviše) i kako ga računa Python round. U kojim slučajevima se razlikuju?
Rješenje. 10 % su 2,145, 2,155 i 2,165 €, odnosno 214,5, 215,5 i 216,5 centi. Školski: 215, 216, 217 centi. Python round (na parno): 214, 216, 216 centi. Razlikuju se za 21,45 € (214 umjesto 215) i 21,65 € (216 umjesto 217); za 21,55 € su isti (216).
Sažetak u pet rečenica
- Heathrow 2008. pokazuje da dijelovi mogu raditi, a sistem ne, ako se ne testira sve zajedno u stvarnim uslovima.
- Test proces ima planiranje, praćenje i kontrolu, analizu, dizajn, implementaciju, izvršavanje i završetak, a iz test baze nastaju test uslovi i test slučajevi povezani matricom sljedivosti.
- Nivoi testiranja su komponentni, integracioni, sistemski i prihvatni, a V-model svakoj fazi razvoja daje par na strani testiranja koji se dizajnira u isto vrijeme.
- Vrste testova su funkcionalni i nefunkcionalni, bijela i crna kutija, potvrdni i regresioni te dim-test, a u agilnom timu se testira u svakom sprintu.
- Statičko testiranje nalazi defekte čitanjem, kao nejasnoću u PP-5 o zaokruživanju (popust na 21,45 € u kodu je 2,14 €), a recenzije s listom za pregled kritikuju dokument, ne autora.