UPI2 Flashcards
(28 cards)
Koje tehnike testiranja poznajete s obzirom na načine kako se definiraju testni slučajevi?
Tehnike testiranja možemo podijeliti prema načinu definiranja testnih slučajeva:
*Funkcionalno testiranje (crna kutija):
Testni slučajevi se temelje na zahtjevima i specifikaciji, bez poznavanja unutarnje strukture programa.
Npr. klasifikacijsko stablo, analiza graničnih vrijednosti.
*Strukturno testiranje (bijela kutija):
Testni slučajevi se temelje na programskom kodu.
Npr. statement coverage (C0), branch coverage (C1), path coverage (C4), MC/DC.
*Random testiranje:
Test podaci se biraju slučajnim odabirom – koristi se za nestrukturirano testiranje.
*Testiranje temeljeno na greškama:
Fokusirano na situacije u kojima se očekuju poznate greške.
Definirajte funkcionalno testiranje.
Funkcionalno testiranje je metoda testiranja u kojoj se testni slučajevi izvode prema funkcionalnim zahtjevima softvera, bez pregleda stvarnog koda. Cilj je provjeriti radi li softver točno ono što je navedeno u specifikaciji, bez obzira kako je to implementirano. Primjerice, ako aplikacija treba zbrajati dva broja, testni slučajevi će provjeriti ispravnost rezultata za različite kombinacije ulaza.
Na predavanjima smo obradili jednu metodu za odabir testnih slučajeva potrebnih za provedbu funkcionalnog testiranja. Objasnite tu metodu, koristite primjer. Navedite kako se određuje minimalan broj testnih slučajeva koje je potrebno koristiti (objasnite koristeći primjer).
Koraci:
1. Identificiraju se aspekti (npr. boja, oblik, veličina)
2. Svakom aspektu se dodjeljuju klase vrijednosti (npr. boja = crvena, zelena, plava)
3. Kombinacijom vrijednosti iz različitih aspekata dobivamo testne slučajeve
Primjer 1: Testiranje igračke
Boja: crvena, zelena
Oblik: krug, kvadrat
Veličina: mala, velika
Ukupno kombinacija: 2 × 2 × 2 = 8 (za potpunu pokrivenost)
Minimalni broj testnih slučajeva jednak je najvećem broju klasa u jednom aspektu.
U primjeru: svi aspekti imaju 2 klase, pa je minimalno 2 testna slučaja (ali za potpunu kombinaciju treba 8).
Primjer 2: Testiranje sustava za prepoznavanje građevnih blokova
Aspekti: Boja (crvena, zelena, plava), oblik (krug, trokut, pravokutnik), veličina (mala, velika).
Klase trokuta: jednakostranični, jednakokračni, ostali.
Stablo: Svaki aspekt se grana u svoje klase.
Testni slučajevi: Kombinacije klasa iz različitih aspekata (npr. mali crveni krug, veliki zeleni pravokutnik).
Minimalni broj testnih slučajeva: Određen najvećim brojem klasa unutar jednog aspekta. Ako trokut ima 3 klase, a ostali aspekti manje, minimalno je 3 testna slučaja.
Objasnite ulogu testnih podataka u funkcionalnom testiranju.
Testni podaci su ulazne vrijednosti koje se koriste za provjeru funkcionalnosti softvera. Oni se biraju tako da pokriju različite scenarije iz specifikacije, uključujući granične vrijednosti i izuzetke. Primjer: Za funkciju koja provjerava je li broj pozitivan, testni podaci bi bili: 5 (pozitivan), -3 (negativan), 0 (granična vrijednost). Za funkciju koja vraća je li broj paran, testni podaci bi mogli biti: 2 (očekivano: DA), 3 (NE), -4 (DA), 0 (DA), “tekst” (greška).
Detaljno objasnite kako teče proces testiranja softvera, navodeći njegove aktivnosti. Prisjetite se slike na kojoj je grafički prikazan tijek aktivnosti.
Proces testiranja uključuje sljedeće aktivnosti:
1. Određivanje testnih slučajeva: Definicija što će se testirati (iz specifikacije ili koda).
2. Odabir testnih podataka: Odabir konkretnih ulaznih vrijednosti.
3. Predviđanje očekivanih rezultata: Što bi softver trebao vratiti za dane ulaze.
4. Izvođenje testova: Pokretanje softvera s testnim podacima.
5. Evaluacija rezultata: Usporedba stvarnih i očekivanih rezultata.
6. Praćenje pokrivenosti: Mjerenje koliko je koda pokriveno testovima.
7. Dokumentacija: Bilježenje rezultata i grešaka.
Napomena: alati poput SOTA automatski mjere pokrivenost, a TESTONA pomaže pri odabiru testnih podataka.
Koji model testiranja mogu provoditi članovi tima koji ne znaju pisati programski kod i zašto?
Članovi tima koji ne znaju programirati mogu provoditi funkcionalno testiranje jer se ono temelji na specifikaciji zahtjeva, a ne na kodu. Testni slučajevi se izvode iz opisa funkcionalnosti, što ne zahtijeva poznavanje programiranja. Primjerice, tester može provjeriti je li korisničko sučelje intuitivno bez poznavanja koda iza njega ili tester može provjeriti radi li forma za prijavu ispravno, bez da zna kako se login validacija programira.
Objasnite svojim riječima zašto je testiranje zauzelo tako bitno mjesto u procesu razvoja softvera.
Testiranje je važno jer:
Otkriva greške prije nego dođu do korisnika -> manji troškovi popravaka
Povećava pouzdanost i kvalitetu softvera.
Smanjuje troškove kasnijih popravaka.
Osigurava da softver ispunjava zahtjeve korisnika.
Smanjuje rizik u kritičnim sustavima (npr. medicina, zrakoplovstvo)
Povećava povjerenje u sustav
Objasnite probleme kod primjene pristupa Potpuna pokrivenost naredbi prilikom strukturnog testiranja. Koristite primjer.
Primjer: Kratki if-statement if (x > 0) y = 1;.
Problem: Pokrivenost naredbi zahtijeva samo jedan testni slučaj (npr. x = 5), ali ne provjerava što se događa kada uvjet nije ispunjen (x = -3).
Rješenje: Potrebna je pokrivenost grana koja zahtijeva testiranje obje grane (istinito i lažno).
Nedostaci: Ne otkriva greške u neizvedenim dijelovima koda (npr. “mrtvi kod”).
Vrste dekompozicije?
*Funkcionalna: Sustav se dijeli na module prema procesima (npr. glavna funkcija → podfunkcije) i *Objektna: Sustav se dijeli na objekte/klase koji komuniciraju (npr. nasljeđivanje, agregacija).
Kvaliteta dizajna se ocjenjuje prema?
*Kohezija: Koliko su elementi unutar komponente povezani (cilj: visoka kohezija).
Primjer: Funkcionalna kohezija – svi dijelovi komponente doprinose jednoj funkciji.
*Sprega (Coupling): Koliko su komponente međusobno zavisne (cilj: niska sprega).
Najbolja: Podatkovna sprega (razmjena jednostavnih podataka).
Najgora: Sadržajna sprega (direktna manipulacija podacima između komponenti).
Arhitekturni modeli?
*Repozitorij: Centralna baza podataka koju koriste svi podsustavi (npr. bankarski sustavi).
*Klijent-poslužitelj: Distribuirani sustavi gdje klijenti traže usluge od poslužitelja (npr. web aplikacije).
*Virtualni stroj (slojevit model): Slojevi apstrakcije (npr. OSI model u mrežama).
Modeliranje kontrole?
*Centralizirano: Jedan kontrolor upravlja svim podsustavima.
*Događajima vođeno: Podsustavi reagiraju na vanjske događaje (npr. GUI aplikacije).
Dobri programerski stilovi?
*Komentari objašnjavaju svrhu modula, varijabli i složenih dijelova
*Opisna imena varijabli (npr. “UkupniIznos” bolje od “x”)
*Izbjegavanje GOTO naredbi; koristi se petlje i uvjeti
*Defanzivno programiranje – uvijek očekuj loš unos i greške, pa ih odmah provjeri
Metodologije u implementaciji?
*Stepwise refinement – od općeg prema konkretnom (npr. pseudokod pa kod)
*Pair programming – jedan programira, drugi provjerava
*Refaktoriranje – mijenjanje strukture koda bez promjene funkcije (npr. skraćivanje dužih funkcija)
Alati za prikaz algoritama:
Pseudokod, dijagram toka
Vrste održavanja:
*Korektivno: Ispravak grešaka (21% troškova).
*Adaptivno: Prilagodba novom okruženju (npr. novi OS, 25% troškova).
*Perfektivno: Poboljšanje performansi ili funkcionalnosti (50% troškova).
*Preventivno: Sprečavanje budućih grešaka (4% troškova).
Primjeri aktivnosti?
Refaktoriranje
Restrukturiranje
Migracija
Gašenje zastarjelih sustava
Podrška korisnicima
Tehnike održavanja:
*Reverzni inženjering: Analiza koda za rekonstrukciju dizajna (npr. generiranje UML dijagrama iz koda).
*Reinženjering: Restrukturiranje sustava za poboljšanje održivosti (npr. modularizacija).
*Migracija: Premještanje sustava na novu platformu.
Problemi u održavanju:
*Tehnički: Loša dokumentacija, nestrukturiran kod, poteškoće u razumijevanju legacy sustava.
*Upravljački: Niska motivacija tima (održavanje se smatra manje prestižnim od razvoja).
Metrike održavanja:
*Broj grešaka: Koliko grešaka se otkrije tijekom održavanja.
*Vrijeme popravka: Prosječno vrijeme potrebno za ispravak.
*Složenost koda: Kružna složenost (cyclomatic complexity) – veća složenost = teže održavanje.
Naslijeđeni sustavi:
Strategije:
1. Odbaci sustav ako nije kritičan/važan.
2. Ostaviti ako je stabilan
3. Reinženjering ako je kvaliteta loša, ali je poslovno vrijedan.
4. Zamijeni novim sustavom ako je tehnologija zastarjela.
Testiranje se može provoditi na različitim razinama:
jedinično testiranje, integracijsko testiranje, sistemsko testiranje i prihvatno testiranje.
Metode funkcionalnog testiranja:
*Klasifikacijsko stablo
Metoda za generiranje testnih slučajeva iz specifikacije.
Ulazni podaci se klasificiraju u aspekte i klase, a zatim se kombiniraju u testne slučajeve.
Minimalni broj testnih slučajeva određen je najvećom klasifikacijom (npr. ako najveća klasifikacija ima 5 klasa, potrebno je minimalno 5 testnih slučajeva).
*TESTONA/CTE
Alat za crtanje klasifikacijskog stabla
Strukturno testiranje – vrste pokrivenosti (iz CFG-a):
*Statement coverage (C0) – svaka naredba barem jednom
*Branch coverage (C1) – svaka grana (true/false) u if-ovima
*Path coverage (C4) – sve moguće putanje (teško primjenjivo zbog petlji)
*MC/DC – svaka komponenta uvjeta mora utjecati na ishod (koristi se u zrakoplovstvu)
*Boundary interior path – tijelo petlje mora biti testirano 0, 1 i 2 puta
