Testiranje softvera
Šta je testiranje softvera?
Testiranje softvera je proces koji se koristi da bi se utvrdila ispravnost, potpunost i kvalitet
razvijenog softvera. Imajući to u vidu, testiranje nikada ne može u potpunosti da utvrdi ispravnost
računarskog softvera. Samo proces formalne verifikacije može da pokaže da u softveru nema
grešaka.
Testiranje softvera je način da se obezbedi manji broj grešaka, manji trošak održavanja i
sveukupne cene softvera. U ovom projektu se usredsređujemo na proces testiranja i merenja
softvera koja omogućavaju kvantitativnu procenu ovog kritičnog dela procesa razvoja softvera.
Testiranje softvera uključuje proces otkrivanja neusaglašenosti softvera kako bi one bile ispravljene
pre nego budu instalirane u živo okruženje koje je podrška za svakodnevni rad poslovnih jedinica
kompanije. Testiranje je aktivnost koja se sprovodi radi evaluacije kvaliteta proizvodnje softvera i
njegovog poboljšanja. Ono nije aktivnost koja počinje samo nakon kompletiranja faze kodiranja.
Softversko testiranje se danas vidi kao aktivnost koja obuhvata ceo proces razvoja i održavanja, i
predstavlja važan deo kompletne konstrukcije softvera. Planiranje testiranja treba da počne sa
ranom fazom izrade zahteva za kvalitet softverskog proizvoda i procesa njegovog projektovanja, i
test planovi i procedure moraju biti sistematski i kontinualno razvijani i po potrebi redifinisani.
Pravi stav prema kvalitetu je prevencija, mnogo je bolje izbeći probleme nego ih ispravljati, kao i za
sve ostale životne situacije fraza je neizbežna da je bolje sprečiti, nego lečiti. Ima neminovnih
grešaka, naše je da ih svedemo na minimum ili potpuno uklonimo. Da stvorimo harmoniju i balans.
U bilo kom upotrebljivom softveru u praksi postoji beskonačan broj mogućih testova koje
je praktično nemoguće sve izvesti, te je nemoguće u određenom vremenskom periodu, sa
ograničenim resursima (ljudi, oprema i alati) izvršiti totalno testiranje koje bi otkrilo sve greške u
sofveru.
Postoji mnogo pristupa u testiranju softvera, ali je efikasno testiranje složenog proizvoda pre
rezultat procesa istraživanja, a ne samo pitanje izrade i slepog praćenja procedure. Jedna definicija
testiranja softvera je: proces ispitivanja proizvoda u cilju njegove procene, gde se ’’ispitivanje’’
odnosi na to šta se testiranjem proizvoda želi postići, a’’proizvod’’ daje odgovor kroz reakciju na
probno testiranje.
Zašto testiranje softvera?
Testiranje softvera je značajno zato što softver može, ukoliko ne radi adekvtano, izazvati neuspeh
misije, uticati na operativnu efikasnost i pouzdanost. Efikasno testiranje softvera doprinosi isporuci
kvalitetnog softverskog proizvoda koji zadovoljava potrebe, očekivanja i zahteve korisnika.
Ukoliko radi loše, to vodi visokim troškovima održavanja i nezadovoljstvu korisnika.
20 zajedničkih sotverskih problema:
Netačna kalkulacija, netačno uređeni podaci, neefikasno uređeni podaci, netačno kodiranje/primena
poslovnih pravila, neadekvatan rezultat softvera, zbunjujući ili podaci koji mogu dovesti u zabludu,
softver koji je teško koristiti, zastareo softver, neodslednost u obradi, teškoće u održavanju i
razumevanju, nepouzdani rezultati, neadekvtana podrška poslovnim potrebama i ciljevima, slaba
podrška od strane prodavca, netačna ili neadekvatna povezanost sa drugim sistemima, netačno
povezivanje podataka, istraživanje podataka koje donosi netačne rezultate, neadekvatna obrada
povezanosti podataka, netačno rukovanje fajlovima i podacima, neadekvatna kontrola, nemogućnost
rukovanja kapacitetima proizvodnje podataka.
1
5 ključnih stvari u testiranju softvera su:
1. Strategija testiranja- koja pokazuje način, tj.metod testiranja-koje tipove i koju količinu
testova treba upotrebiti da bi se na najbolji način otkrile greške koje su skrivene u softveru.
2. Plan testiranja- koji sadrži konkretne zadatke koji će omogućiti ostvarenje strategije
testiranja.
3. Slučajevi tesiranja - koji su pripremljeni u formi detaljnih primera i koji se koriste da bi se
proverilo da li softver odgovara zahtevima.
4. Podaci za testiranje- koji se sastoji i od ulaznih podataka i baze podataka, koji se koriste
dok se izvršavaju test slučajevi,
5. Okruženje testiranja- softversko i hardversko okruyenje (operativni sistem i druga
softverska rešenja)u kome se celo testiranje obavlja.
Životni ciklus testiranja: započinje planom testiranja, izradom slučajeva, sprovođenjem testiranja,
praćenjem grešaka, i završava se izveštajem procesa testiranja.
Šta je kvalitet softvera?
Kvalitet predstavlja sposobnost da se proizvede softver koji zadovoljava ili nadmašuje
postavljene zahteve (prema definisanim merljivim kriterijumima) i koji je proizveden definisanim
procesom. Ovaj proces ne svodi se samo na zadovoljenje definisanih zahteva, vec se u okviru njega
moraju definisati mere i kriterijumi koji usmeravaju process postizanja kvaliteta. Potrebno je
usvojiti pravila za jedan ponovljiv i upravljiv proces ciji proizvodi ce dostizati odredeni nivo
kaliteta.
Jedna od definicija koja se pominje u softverskoj literaturi je i definicija sa stanovišta potrošaca.
Potrošac definiše kvalitet kao meru zadovoljavanja potreba kupca od strane proizvoda ili usluge.
Drugom recju, upotrebnim kvalitetom.
Najčešće zablude o kvalitetu:
1. Kvalitet može biti naknadno dodat i“utestiran“ –što ne stoji već kvalitet mora biti opisan i
ugrađen u proces stvaranja proizvoda.
2. Kvalitet dolazi sam od sebe – što ne stoji već kalitet ne nastaje tek tako. Proces razvoja mora se
definisati, sprovoditi i kontrolisati kako bi se dostigao odredeni nivo kvaliteta.
3. Kvalitet je jednodimenzionalna karakteristika i svakom znaci isto- što ne stoji već kvalitet ima
više dimenzija od kojih su najvažnije: funkcionalnost, pouzdanost, upotrebljivost, efikasnost, stepen
podrške. Svaku od dimenzija prati odgovarajući tip testiranja softvera.
10 pravila testiranja:
-
Testiranje treba da započne još u ranoj fazi i da se obavlja često
Treba integrisati razvoj aplikacije i životni ciklus testiranja. Dobiće se bolji rezultati bez
neophodnosti posredovanja između dva ’’zaraćena tabora’’ u procesu testiranja softvera
Treba formalizovati metodologiju testiranja- a to znači treba sve testitati na identičan način
i dobiće se uniformisani rezultati
Razviti obim plan testiranja- koji predstavlja osnovu za metodologiju testiranja
Treba koristiti i statičke i dinamičke testove
Definisati očekivane rezultate (problem Test Oracle)
Razumeti poslovne potrebe koje stoje iza razvijene aplikacije-na taj način će se razviti i
bolja aplikacija i bolje testiranje
Koristiti različite nivoe i tipove testiranja (regresiju, sistemsko testiranje, integraciju)
Pregledati i proveravati rad, što će smanjiti troškove
2
-
Ne dozvolit svojim programerima da testiraju sopstveni rad- jer će prevideti sopstvene
greške. Ovo se izbegava unakrsnim testiranjem tj. programeri raymenjuju kod i testiraju
tuđi kod.
Komparacija pravaca - ekonomski aspekti
U literaturi se navode prednosti nekih od pravaca ili metoda u testiranju posmatrano sa
aspekta troškova pre svega:
1. Prevencija ili detekcija: Kvalitet se ne može postici na vec gotovom proizvodu. Cilj je da
se sprece defekti ili nedostaci i da se proizvod ucini merljivim pomocu parametara kvaliteta. Neke
od mera kvaliteta su: struktuiranje razvojnog procesa uz pomoc standarda za razvoj softvera i
podršku razvojnog procesa metodama, tehnikama i alatima. Nedetektovane greške koje su izazvale
milione poslovnih gubitaka uslovile su rast nezavisnog testiranja. Troškovi proizvodnje se smanjuju
sa ranim otkrivanjem I ispravkom grešaka. Uz alate za automatsko testiranje, dugorocno gledano,
rezultat su proizvodi visokog kvaliteta i smanjeni troškovi održavanja. Ukupni trošak efektivnog
upravljanja kvalitetom predstavlja sumu cetri komponente troškova: prevencije, inspekcije, internih
i eksternih otkaza.
Preventivni troškovi sastoje se od akcija koje se preduzimaju kako bi se sprecili defekti. Inspekcioni
troškovi sastoje se od merenja, procene i provere proizvoda ili usluga i njihovog slaganja sa
standardima i specifikacijama. Troškovi internih otkaza su oni koji podrazumevaju ispravku
proizvoda sa greškama pre njihove isporuke. Troškovi eksternih otkaza sastoje se od grešaka
otkrivenih nakon lansiranja proizvoda. Prevencija se najviše isplati jer povecavanje preventivnih
troškova smanjuje broj defekata koji idu kupcu neotkriveni i tako se unapreduje kvalitet proizvoda i
smanjuju troškovi proizvodnje i održavanja.
2. Verifikacija ili validacija: Verifikacija omogucava da proizvod zadovolji zahtevekoji si
specificirani tokom prethodnih aktivnosti i oblikovani kroz životni ciklus proizvoda, a validacija
zadovoljenje zahteva kupaca na kraju životnog ciklusa proizvoda. Kreiranje test proizvoda je bliže
validaciji nego verifikaciji. Testiranje softvera se posmatra kao validacioni proces. Nakon završetka
programiranja sistem se validira ili testira da bi se odredile funkcionalne ili operativne performanse.
Naravno, savremeni procesi testiranja se ne odvijaju samo nakon završetka programiranja, vec su
utkane u sam proces razvoja softvera. Dobitna kombinacija je korišcenje verifikacije i validacije u
procesu testiranja. Verifikacija obuhvata sistematicne procedure pregleda, analize i testiranja
ugradene u životni ciklus, pocevši od faze softverskih zahteva, do faze kodiranja. Verifikacija
obezbeduje kvalitet i održavanje softvera. Koncept verifikacije ukljucuje dva kriterijuma: softver
mora adekvatno i korektno izvršavati sve funkcije i ne sme izvršavati one funkcije koje sam po sebi
ili u kombinaciji sa ostalim funkcijama mogu degradirati performanse citavog sistema. Verifikacija
takode omogucava interoperabilnost medu razlicitim sekcijama u softverskoj dokumentaciji i
povezanim delovima zahteva. Jedina kritika verifikacije je da povecava troškove razvoja softvera.
Kada se troškovi softvera posmatraju kroz citav životni vek proizvoda, verifikacija zapravo
umanjuje troškove softvera. Uz efektivan proces verifikacije redukuju se defekti instaliranih
sistema. Ukupna ušteda prevazilazi pocetni trošak, jer ispravka grešaka može koštati 20 do 100 puta
više za vreme operacija i održavanja sistema, nego za vreme dizajniranja.
Jednostavno je uočiti razliku između specifikacije programa (određuje šta program treba da radi, a
često i na koji način), specifikacije arhitekture (prikazuje arhitekturu programa, tj. komponente
unutar programa i njihove odnose) i detalje specifikacije programa ( opisuje kako se primenjuje
svaka komponenta programa ). Ukoliko su specifikacije u hijerarhijskim odnosima, program se
može testirati u različitim fazama razvoja. Na osnovu hijerarhije programa specifikacije, evidentni
su različiti nivoi testiranja:
3
1. Testiranje jedinice (podrazumeva testiranje svake jedinice kao osnovne komponente u cilju
određivanja korektnosti)
2. Testiranje integracije programa korak po korak ( sa sve većim i većim komponenata
programa koje se integrišu ali i testiranjem sve do onog momenta kada funkcionišu kao
celina)
3. Sistemsko testiranje ( program se integriše u proizvod koji se može nazvati ”konačan
proizvod” i potom se vrši testiranje da se utvrdi da i su ispunjeni svi zahtevi)
4. Testiranje prihvatanja (vrši se prihvatanje gotovog programa i često se koristi podskup
sistemskih testova)
Proces testiranja
Testiranje se sastoji od sledecih aktivnosti:
1. Planiranje testiranja (odreduje se predmet, cilj i razlog testiranja( na osnovu zahteva,
modela i drugih ulaza testiranja), gde se testiranje vrši, kada se vrši i ko izvršava testove)
2. Dizajn testova (odreduje kako se sprovodi testiranje na osnovu artefakta tj. Testprimera)
3. Implementacija testova (pravljenje višestruko upotrebljivih test scriptova koji realizuju
test primere)
4. Izvršavanje testova (izvršavanje implementacije testa radi provere
funkcionalnosti sistema)
5. Evaluacija testova (procena testova tj. validnosti izvršavanja testa, analiza izlaza, pregled
zbirnih rezultata, uticaj promene zahteva i ulaza na plan testiranja) Svaka od ovih aktivnosti ima
ulaze i izlaze. U procesu testiranja koriste se i razliciti alati koj pospešuju proces i daju bolji uvid u
rezultate(npr.Rational, Test Complete i sl.).
Slika1: Proces testiranja
4
Strategija testiranja predstavlja celokupan pristup testiranju, pri čemu se definišu nivoi testiranja,
metode, tehnike i alati. Ukoliko bi se radilo u idealnim uslovima, strategija testiranja bila bi
zajednička za celu organizaciju, kao i za sve programe unutar nje. Primena i razvoj strategije vrlo su
bitni za postizanje određenog kvaliteta programa a samim tim i realizaciju projekta. Prvi korak pri
izboru strategije testiranja programa jeste specifikacija.
Specifikacija predstavlja osnovnu komponentu svih definicija. Programi mogu biti veoma
jednostavni ili složeni, dok specifikacija (zavisno od veličine i primenjenih programerskih metoda)
može da bude u obliku jednog dokumenta ili da predstavlja složenu hijerarhiju dokumenata.
Ukoliko se posmatraju različite hijerarhije programa specifikacija može se zaključiti da se one
sastoje od tri ili više nivoa dokumenata
Organizacija procesa testiranja
Proces testiranja mora se odvijati tokom svih faza životnog ciklusa. Za ovaj process moraju
se realizovati standardizovani propisi i procedure koje definišu nacin rada I aktivnosti test odeljenja,
kao i svih ucesnika u razvoju. Sve aktivnosti clanova tima koji ucestvuju u realizaciji procesa
testiranja moraju biti dokumentovane i moraju pokriti
sledece:
- Odgovornosti i zaduženja za planiranje testa, izvršenje i evaluaciju.
- Ciljeve testa, tipove koji ce se primeniti, raspored i zaduženja kod testiranja kroz
plan testiranja.
- Odgovarajuci materijal (dokumenta, test primeri i dr.).
- Test materijal je podložan periodicnim aktivnostima kontrole kvaliteta
Tipovi testiranja
Inspekcije, recenzije i pregledi:
Inspekcije, recenzije i pregledi su specificne tehnike fokusirane na ocenjivanje
artefakata(pogodno za dokumentaciju, programski kod) i efikasne su metode za poboljšanje
kvaliteta i razvojnog procesa proizvoda. Sprovode se na sastancima, gde jedan od ucesnika ima
ulogu vodeceg, a ostali uloge zapisicara(beleži pitanja, predloge, probleme i sl.). Ove tehnike
opisuju se u okviru IEEE standarda na sledeci nacin:
Recenzija (review) – formalni stastanak na kome se artefakt ili skup artefakata predstavlja
korisniku ili drugim stranama koje ucestvuju u procesu odobravanja ili komentarisanja.
Inspekcija (inspection) – fomalna tehnika procene u kojoj se artefakti detaljno pregledaju.
Pregled vrše osobe koje nisu autori, da bi se lakše uocile greške i drugi problemi.
Pregledi (walkthrough) – Tehnika pregleda u kojoj autor upoznaje ostale clanove tima sa
elementima artefakta koji je izgradio. Ostali clanovi ucestvuju aktivno u raspravi.
Tehnike testiranja
1. Jedinicno testiranje (unit testing) – primenjuje se na pojedine klase, module ili komponente
programskog koda. Ova tehnika deli se na tehnike bele i crne kutije.
2. Integraciono testiranje – primenjuje se na softverski sitem kao celinu. Integraciono testiranje je
faza u testiranju softvera u kojoj se pojedinačni moduli softverskog sistema kombinuju i testiraju
kao grupa i tako se otkrivaju greške. Ovo testiranje se dešava pre sistemskog, a nakon jediničnog
testiranja.
3. U testiranja višeg reda spadaju:
- testiranje sigurnosti (security testing): da li su funkcije dostupne onim i samo onim korisnicima
kojima su i namenjene.
- testiranje kolicine podataka – verifikovanje da li softver može obraditi veliku kolicinu podataka.
5
- testiranje upotrebljivosti(usability testing) – estetski aspekti, konzistentnost korisnickog
interfejsa, korisnicka dokumentacija.
- testiranje integriteta(integrity testing) – robusnost(otpornost na otkaze), konzistentna upotreba
resursa i sl.
- test u stresnim uslovima(stress testing) – vrsta testa pouzdanosti sistema pod nenormalnim
uslovima (velika opterecenja sistema, nedovoljno memorije ili drugih resursa, neraspoloživi servisi
i sl.).
- etalonski test - uporedenje performansi novog sistema sa nekim, referentnim, poznatim sistemom.
- test zagušenja – provera da li sistem može da zadovolji višestruke zahteve razlicitih aktera za
istim resursom.
- test opterecenja – vrsta testa performansi kojim se procenjuju operativni limiti nepromenjivog
sistema pod razlicitim opterecenjima ili razlicitih konfiguracija sistema pri istom opterecenju.
Najcešce se mere protok i vreme odziva (srednja i granicna vrednost).
- test konfiguracije (configuration testing) – testira ponašanje softvera u razlicitim
hardversko/softverskim okruženjima.
- test instalacije(installation testing) – testira instaliranje softvera na razlicitim sistemima i u
razlicitim situacijama (npr. prekid napajanja ili nedovoljno prostora na disku).
4. Regresiono testiranje – na osnovu jednom razvijenog testa više puta se sprovodi testiranje
softvera (tipicno nakon neke izmene u softveru da bi se utvrdilo da nisu pokvarene funkcionalnosti
softvera).
...pregled tehnika testiranja
Testiranje se posmatra kao posebna faza životnog ciklusa proizvoda koja prati kodiranje. Moderni
model softverskog životnog ciklusa izbegava ovakvo gledanje na stvari i u prvi plan stavlja
iterativno testiranje kroz razvoj životnog ciklusa.
Testiranje omogucava ranu detekciju grešaka i ispravku istih i tehnicki uvid u pravu
prirodu performansi sistema. Obicno se koristi nekoliko testnih metodologija da bi se obradili
razliciti aspekti softverskog proizvoda.
Kako su do sada objašnjeni samo neki od tipova i tehnika testiranja u tabeli je dat
pregledsavremenih tehnika testiranja sa opisom. Tehnike se kombinuju i variraju.
Tehnika
Acceptance testing – Testiranje
prihvatljivosti
Kratak opis
Finalno testiranje bazirano na
specifikacijma krajnjeg
korisnika/potrošača, ili bazirano na
korišćenju krajnjih korisnika/potrošača u
odre₃enom vremenskom periodu.
Ad hoc testing – Ad hoc testiranje
Slično istraživačkom testiranju, ali se često
odnosi na to da testeri dobro razumeju
softver pre samog testiranja.
6
Alpha testing – Alfa testiranje
Testiranje kada je razvoj pri kraju; manje
promene u dizajnu moguće su kao rezultat
ovog testiranja. Obično ga izvršavaju
krajnji korisnici ili drugi, a ne programeri i
testeri.
Basis path testing – Testiranje osnovnih
tokova
Identifikovanje testova na bazi tokova i
putanja programa ili sistema.
Beta testing – Beta testiranje
Kada su razvoj i testiranje u suštini
završeni i potrebno je pronaći konačne
greške i probleme pre samog lansiranja
proizvoda. Obavljaju ga krajnji korisnici ili
drugi, ne programeri ili testeri.
Black-box testing – Black-box testiranje
Testovi se generišu na osnovu
funkcionalnosti sistema.
Bottom – up testing – Testiranje od dna ka
vrhu
Integrisanje modula ili programa počevši
od dna.
Boundary value testing – Testiranje
graničnih vrednosti
Testovi se generišu iz graničnih vrednosti
odgovarajućih klasa.
Branch coverage testing –
Branch(gransko) testiranje
Verifikacija da svaka grana ima true ili
false izlaze.
Branch/condition coverage – Grana/uslov
testiranje
Verifikacija da svaki uslov obuhvata sve
moguće izlaze .
Cause/effect graphing – Uzrok/posledica
graf
Označavanje višestrukih simultanih ulaza
koji mogu uticati na uslove testa.
Comparison testing – Uporedno testiranje
Upore₃ivanje slabosti i dobrih strana
softvera sa konkurentskim proizvodima.
Compatibility testing – Testiranje
kompatibilnosti
Testiranje koliko dobro softver radi u
odre₃enom
hardversko/softverskom/OS/mrežnom
okruženju.
Condition coverage testing – Testiranje
pokrivenosti uslova
Potvrda da svaki uslov obuhvata sve
moguće izlaze.
CRUD testing – CRUD testiranje
Pravljenje CRUD matrice i testiranje svih
7
kreacija objekata, čitanja, ažuriranja i
brisanja.
Database testing – Testiranje baze
podataka
Provera integriteta vrednosti u poljima baze
podataka.
Decision tables – Tabele odluka
Tabele koje pokazuju kriterijume odluke i
respektivne akcije.
Desk checking – Provera
Developer pregleda kod.
End-to-end testing –
Sa kraja na kraj testiranje
Slično sistemskom testiranju, uključuje test
kompletnog okruženja aplikacije u situaciji
kada se oponaša stvarni korisnički svet,
npr. interakcija sa bazom podataka,
korišćenje mrežne komunikacije, ili
interakcija sa drugim hardverom,
aplikacijama ili sistemima.
Equivalence partitioning – Ekvivalentno
particionisanje
Svaki ulazni uslov se deli na dve ili više
grupa. Testovi se generišu iz
reprezentativnih validnih ili nevalidnih
klasa.
Exception testing – Testiranje izuzetaka
Identifikovanje poruka o grešci i obrade
izuzetaka i uslova koji ih okidaju.
Exploratory testing – Istraživačko
testiranje
Često označava kreativno, neformalno
testiranje koje se ne bazira na formalnim
test planovima ili test case-ovima; testeri
uče o softveru za vreme testiranja.
Free form testing – Slobodna forma
testiranja
Korišćenje ad hoc ili brainstorming
intuicije za definisanje test case-ova.
Gray-box testing – Gray-box testiranje
Kombinacija Black-box i white-box
testiranja, kako bi se izvukle najbolje strane
oba ova tipa.
Histograms – Histogrami
Grafička reprezentacija izmerenih
vrednosti organizovanih prema frekvenciji
doga₃anja koja se koristi da naglasi
„vruće“ tačke.
Incremental integration testing –
Kontinualno testiranje aplikacije kada se
8
Inkrementalno integraciono testiranje
doda nova funkcionalnost, zahteva da
različiti aspekti funkcionalnosti aplikacije
budu dovoljno nezavisni da rade zasebno,
pre kompletiranja svih delova programa.
Izvršavaju ga testeri ili programeri.
Inspections – Inspekcije
Formalni pregled koji koristi čekliste,
ulazne i izlazne kriterijume.
Integration testing – Integraciono
testiranje
Testiranje kombinovanih delova sistema
radi utvr₃ivanja da li zajedno dobro
funkcionišu. Delovi mogu biti kodni
moduli, individualne aplikacije ili
klijent/server aplikacije na mreži. Ovaj tip
testiranja je jako važan za klijent/server i
distribuirane sisteme.
JADs
Tehnika koja spaja korisnike i developere
pri dizajnu sistema.
Load testing – Load testiranje
Testiranje aplikacije pod opterećenjem.
Mutation testing – Mutaciono testiranje
Metod odre₃ivanja da li je skup testnih
podataka ili testova koristan, namernim
uvo₃enjem raznih promena u kodu(„bugs“)
i retestiranje sa originalnim test
podacima/slučajevima kako bi se odredilo
da li su otkrivene greške. Zahteva velike
resurse.
Orthogonal array testing – Ortogonalno
testiranje niza
Matematička tehnika odre₃ivanja koje
varijacije parametara treba da se testiraju.
Pareto analysis – Pareto analiza
Analiza paterna defekata radi identifikacije
uzroka i posledica.
Performance testing – Testiranje
performansi
Koristi se često sa stres i load testovima.
Definisano je u zahtevima ili test
planovima.
Positive and negative testing – Pozitivno i
negativno testiranje
Testiranje pozitivnih i negativnih vrednosti
svih ulaza.
Prior defect history testing – Testiranje
prethodnih defekata
Testovi se kreiraju ili ponovo pokreću za
svaki defekt koji se prona₃e u prethodnim
9
testovima sistema.
Prototyping – Prototipovanje
Pristup prikupljanja podataka od korisnika
izgradnjom i demonstracijom nekog dela
potencijalne aplikacije.
Random testing – Nasumično testiranje
Nasumična selekcija iz skupa ulaznih
vrednosti, gde je svaka vrednost jednako
važna.
Range testing – Testiranje opsega
Za svaki ulaz definiše se opseg za koji bi
ponašanje sistema trebalo da bude isto.
Recovery testing – Testiranje oporavka
Testiranje koliko dobro se sistem oporavlja
od padova, hardverskih otkaza ili drugih
velikih problema ovog tipa.
Regression testing – Regresiono testiranje
Testiranje sistema sa manjim izmenama za
vreme spiralnog razvoja, debagovanja,
održavanja ili razvoja u novom release-u.
Risk-based testing – Testiranje zasnovano
na riziku
Meri stepen poslovnog rizika u sistemu
kako bi se poboljšalo testiranje.
Run charts – Grafici izvršavanja
Grafički prikaz kako karakteristike
kvaliteta variraju u vremenu.
Sandwitch testing – Sendvič testiranje
Intergacija modula ili programa sa vrha i
dna simultano.
Sanity testing – Zdravorazumsko
testiranje
Inicijalni test napor kako bi se odredilo da
li se novi softver dobro ponaša, kako bi se
prešlo na veći stepen testiranja. Npr. Ako
novi softver obara sistem svakih 5 minuta,
neće biti potrebno testiranje u takvom
stanju.
Security testing – Testiranje sigurnosti
Testiranje koliko dobro sistem reaguje na
neautorizovane napade.
State transition testing – Testiranje
prelaza stanja
Tehnika u kojoj se prvo identifikuju stanja
sistema, a potom se pišu test case-ovi kako
bi se testirali okidači koji prouzrokuju
prelaz iz jednog stanja u drugo.
10
Statement coverage testing – Testiranje
izraza
Svaki izraz programa se izvršava bar
jednom.
Statistical profile testing – Statističko
profil testiranje
Statističke tehnike se koriste da razviju
korisnički profil sistema koji pomaže da se
definišu prelazne putanje, uslovi, funkcije i
tabele podataka.
Stress testing – Stres testiranje
Testiranje funkcionalnosti sistema pod
opterećenjem, ponavljanjem odre₃enih
akcija ili ulaza, veliki ulazni brojevi ili
kompleksni upiti nad bazom.
Structured walkthroughs – Strukturni
pregledi
Tehnika za upravljanje sastankom na kom
učesnici projekta ispituju rad proizvoda.
Syntax testing – Sintaksno testiranje
Tehnika vo₃ena podacima i test
kombinacijama ulazne sintakse.
System testing – Sistemsko testiranje
Black-box tip testiranja koji se bazira na
zahtevima; pokriva sve kombinovane
delove sistema.
Table testing – Tabelarno testiranje
Testiranje pristupa, sigurnosti i integriteta
podataka tabela ulaza.
Thread testing – Testiranje niti
Kombinovanje individualnih jedinica u
okviru niti funkcionalnosti koje zajedno
postižu neku funkciju ili skup funkcija.
Top-down testing – Testiraje od vrha ka
dnu
Integracija modula ili programa počevši od
vrha.
Unit testing – Jedinično testiranje
Mikro testiranje odre₃enih funkcija ili
modula koda. Obično ih obavlja programer,
a ne tester, jer zahteva detaljno poznavanje
internog dizajna i koda programa.
Usability testing – Testiranje korisnosti
Test izgleda aplikacije za korisnika.
Subjektivno je i zavisi od ciljne grupe
korisnika. Koriste se intervjui, video zapisi
i druge tehnike. Programeri i testeri ne
odgovaraju za ovaj tip testiranja.
White-box testing – White-box testiranje
Testovi se definišu ispitivanjem logičkih
11
iskaza sistema.
Tabela 1.Opis tehnika za testiranje
Cesta je i podela testiranja na:
1. black-box, white-box i gray-box testiranje,
2. manuelno i automatsko testiranje,
3. staticko i dinamicko testiranje.
Metoda bele kutije –"White-box"
Ovo testiranje proverava i analizira izvorni kod i zahteva dobro poznavanje programiranja, odgovarajućeg
programskog jezika, kao i dizajna konkretnog softverskog proizvoda. Plan testiranja se određuje na
osnovu elemenata implementacije softvera,kao što su programski jezik, logika i stilovi. Testovi se izvode
na osnovu strukture programa. Kod ove metode postoji mogućnost provere skoro celokupnog koda, na
primer proverom da li se svaka linija koda izvršava barem jednom, proverom svih funkcija ili proverom
svih mogućih kombinacija različitih programskih naredbi. Specifičnim testovima može se proveravati
postojanje beskonačnih petlji ili koda koji se nikada ne izvršava.
Kodna pokrivenost je navedena u 6 sledećih koraka:
·
·
·
·
·
·
·
Segment pokrivenost – svaki segment koda u B/W kontroli strukture se izvršava makar
jednom
Područna rasprostanjenost ili čvorno testiranje – svaki ogranak u kodu se koristi u jednom
mogućem smeru barem jednom
Složeno stanje rasprostranjenosti – kada postoji više uslova, mora se testirati ne samo svaki
smer, već i sve moguće kombinacije uslova, što se obično obavlja pomoću kombinacijske tabele
(Truth Table)
Osnovni put testiranja – svaka nezavisna staza kroz kod koristi prethodno definisan niz
Testiranje toka podataka – u ovom pristupu, skup srednjih staza kroz kod definiše praćenje
specifičnih promenljivih kroz svaki mogući proračun. Praćenje se zasniva na svakom odabranom
pojedinačnom delu koda.Iako ove staze smatraju nezavisnim, zavisnosti između višestrukih staza
zapravo nisu testirane za ovaj pristup. DFT (Data Flow Testing) teži da održava zavisnosti, ali to
je uglavnom kroz manipulaciju sekvenci podataka. Ovaj pristup prikazuje skrivene bugove i
koristi ih kao promenljive, deklariše ih ali ih ne koristi.
Put testiranja – put testiranja definiše i pokriva sve moguće puteve kroz kod. Ovo testiranja
su vrlo teška i dugotrajana.
Testiranje petlje – ove strategije se odnose na testiranju jedne petlje, grupnih petlji i
ispletenih petlji. Zavisnost petlji je prilično jednostavno testirati, osim ako postoji među petlja ili
kod sadrži B/W petlju.
U White box testingu, koristi se kontrola strukture proceduralnog dizajna za dobijanje test slučajeva.
Korišćenjem White box testing metoda jedan tester može izvući probne slučajeve koji:
12
●
●
●
●
Garantuju da sve nezavisne staze u modulu budu istestirane barem jednom.
Izvršavaju sve logičke odluke o njihovoj istinitosti ili lažnoj vrednosti
Izvlače sve petlje na sopstvenim granicama i unutar svojih dozvoljenih operativnih granica.
Upotrebljava unutrašnje strukture podataka kako bi obezbedio njihovu valjanost.
Metoda crne kutije –"Black-box"
Analizira se samo izvršavanje specificiranih funkcija i vrši se provera ulaznih i izlaznih podataka. Tačnost
izlaznih podataka proverava se na osnovu specifikacije zahteva za softver. U ovim testovima se ne vrši
analiza izvornog koda. Problem funkcionalnog testiranja može da se pojavi u slučaju dvosmislenih
zahteva i nemogućnosti opisivanja svih načina korišćenja softvera. Skoro 30% svih grešaka u kodu
posledica su problema nepotpunih ili neodređenih specifikacija. Sinonimi za black box uključuju:
ponašanje, funckionalnost, neprozinost i zatvorenost
Testiranjem se pokušavaju pronaći greške u sledećim kategorijama:
●
●
●
●
●
Neispravna ili nepotpuna funkcija
Greška interfejsa
Greška u strukturi podataka ili u pristupu spoljnoj bazi podataka
Greška performanse
Greška inicijalizacije i greška izvršavanja
Primenom metode crne kutije izrađuje se skup test slučajeva koji ispunjavaju zahteve:
●
●
Test slučaja koji smanjuju broj test slučaja na mogućnost razumnog testiranja
Test slučaja koji će nam prikazati prisutnost ili odsutnost klase grešaka
Prednosti Black box testinga
·
·
·
·
Testiranje može biti ne – tehničko
Ovo testiranje će najverovatnije pronaći one bugove koje je korisnik pronašao
Testiranje pomaže u identifikovanju nejasnoća i protivrečnosti funkcionalnih specifikacija
Test slučajevi mogu biti izrađeni po završetku funkcionalnih specifikacija
Nedostatci Black box testinga
●
●
●
●
Šanse za ponavljanje testova koje je već odradio proramer
Test inputa zauzima veliki deo prostora
Teško je utvrditi sva moguća testiranja ulaza u ograničenom vremenu. Pisanje test slučaja je
prilično sporo i teško
Šanse za posedovanje neidentifikovanih staza tokom testiranja
13
Alati koji se koriste u Black box testingu
Osnovni funkcionalni alati testiranja izvode rezultate testova crne kutije u obliku skripte. Jednom
izvedene, ove skripte mogu koristiti u budućem razvoju softvera,kao aplikacija koja verifikuje novu
funkcionalnost a da ne onemogući prethodnu.
Ekvivalentno particionisanje
Ekvivalentno particionisanje je metoda testiranja crne kutije koja deli ulazni softverski domen u klasu
podataka od kojih se izrađuju u test slučajevi. Idealan test slučaja otkriva klasu grešaka pre nego što je
greška detektovana. Ekvivalentnost particionisanja pokušava da identifikuje naznačenu klasu grešaka u
test slučaju. Dizajn test slučaja za ekvivalentnost particionisanja je zasnovano na planiranju ekvivalentnih
vrednosti unosa (inputa). Ekvivalentne vrednosti prikazuju skup važećih i nevažećih ulznih uslova (input
conditions) u sistemu.
Ekvivalentna vrednost može da se određuje na osnovu sledećeg:
●
●
●
●
Ako je ulazni uslov (input conditions) specifičan niz, jedna važeća i dve nevažeće ekvivalentne
vrednosti su definisane
Ako ulazni uslov (input conditions) zahteva specifičnu vrednost, jedna važeća i dve nevažeće
ekvivalentne vrednosti su definisane
Ako je ulazni uslov (input conditions) član specifičnog niza, jedna važeća i jedna nevažeća
ekvivalentna vrednost je definisana
Ako je ulazni uslov (input conditions) Bulova, jedna važeća i jedna nevažeća ekvivalentna
vrednost je definisana
Manuelno i automatsko testiranje
Osnove manuelnog testiranja pocivaju na tome da su njegovi nosioci ljudi i da nije implementirano na
racunaru; osnove automatskog, upravo na tome da je implementirano na racunaru.
Staticko i dinamicko testiranje
Staticko testiranje ne zavisi od vremena npr. provera sintakse, strukture i sl.
Dinamicke tehnike zavise od vremena i podrazumevaju izvršavanje specificnog niza instrukcija na papiru
ili racunaru.
14
PISA (Poslovno Inteligentna Simulaciona Arhitektura)
Kratak opis projekta
OptimalSQM predstavlja skup nаjboljih modelа i tehnikа iz prаkse, integrisаnih u optimizovаn i
kvаntitаtivno rukovođen proces rаzvojа, testirаnjа i održаvаnjа softverа koji zadovoljava 3, 4 i 5-ti nivo
zrelosti kompanije u pogledu testiranja softvera (TMM). To su pre svega ekspertski alati koji se integrisu
na zahtev korisnika. Okruženje zа simulаciju scenаrijа rаzvojа kvаlitetnog softverа koje omogućаvа
minimizаciju troškovа i rizikа, izborom аlternаtivnih plаnovа testirаnjа koji zаdovoljаvаju ogrаničenjа u
pogledu slobodnih resursа, kriterijumа optimаlnosti i performаnsi dаte kompаnije i ekonomski model
kvаlitetа softverа zа ocenu isplаtivosti predloženih аktivnosti SQA, mere zа poboljšаnje PRS-PTS(Proces
Razvoja Softvera, Proces Testiranja Softvera) nа osnovu ekonomskih pаrаmetаrа. Razvoj softvera troši
više od polovine svog budžeta na aktivnosti povezane sa testiranjem u toku projektovanja softvera i na
održavanju softvera nakon njegove predaje na upotrebu.
Tabela 2 - Nivoi zrelosti TS tzv. TMM levels
TMM Nivo 1
Inicijalna faza: Testiranje softvera (TS) je haotičan proces; loše je
definisan i nije jasno razgraničen sa fazom otklanjanja grešaka
(debugging). Testiranju se pristupa neplanirano i na kraju faze kodiranja
programa. Cilj testiranja softvera je da se pokaže da program radi. Softver
se iznosi na tržište bez primene sistema obezbeđenja kvaliteta. Nedostaju
resursi, alati i adekvatno obučen kadar. Ovaj tip organizacije odgovara
SEI CMM Level 1, zrelosti softverske kompanije.
TMM Nivo 2
Faza Definisana: Testiranje softvera je odvojena od faze otklanjanja
grešaka (debugging) i definisano je kao odvojena faza nakon kodiranja.
Mada je planirana kao aktivnost, Testiranje softvera na Nivou 2, je
definisano nakon faze kodiranja zbog nezrelosti samog procesa Testiranja
softvera. Glavni cilj Testiranja softvera, na ovom nivou zrelosti (TMM), je
da se pokaže da je softver zadovoljio specifikaciju. Primenjuju se osnovne
tehnike i postupci. Mnogi problemi vezani za kvalitet softvera na ovom
TMM nivou posledica su planiranja TS kasno u ciklusu razvoja softvera
(SDLC). Dalje, greške (otkazi) softvera u ranim fazama propagiraju se do
zadnjih faza SDLC tj. ne otkrivaju se blagovremeno, odnosno onda kada
se i generišu.
TMM Nivo 3
Faza Integrisanja: TS nije više faza koja sledi fazu kodiranja, naprotiv,
TS je integrisani deo SDLC. Organizacije koje su ovladale TMM Nivo 2,
za razliku od TMM Nivoa 2, na Nivou 3 aktivnost TS se odvija i planira
od početka SDLC tj. projektnih zahteva za softver pa do kraja najčešće V
modela SDLC. Ciljevi i zadaci TS su utvrđeni na bazi zahteva klijenata i
mogućih kupaca softvera i koriste se u fazi dizajna test primera i
kriterijuma uspešnog odziva testa. Organizaciono je uspostavljena grupa
za TS, a TS je profesionalni posao članova tima. Obuka kadra je
15
fokusirana na oblast TS. Osnovna sredstva, alati za TS su u upotrebi. Iako
organizacije na ovom TMM nivou znaju za značaj kontrole i obezbeđenja
kvaliteta, ova funkcija nije formalno primenjena u SDLC. Program
merenja kvaliteta TS kao i samog kvaliteta softvera kao proizvoda nije još
uspostavljen.
TMM Nivo 4
Faza Merenja i Upravljanja: Proces TS se meri i kvalitet (cena,
efikasnost, efektivnost) ocenjuje. Inspekcije i revizije se primenjuju
planski u svim fazama SDLC kao obavezna aktivnost u TS i kontroli
kvaliteta. Softverski proizvod se testira radi ocene faktora kvaliteta kao što
su pouzdanost, upotrebljivost i pogodnost za održavanje. Ažurira se baza
podataka o test-primerima sa svih projekata radi ponovne upotrebe pri
regresionom (ponovljenom) testiranju. Otkazi, greške, se evidentiraju u
bazi podataka o otkazima, greškama i dodeljuje im se značaj (kritičnost).
Nedostatak TS na ovom TMM nivou je i dalje primenjena preventivna
aktivnost generisanja softverskih grešaka, slabo razvijena metrika
kvaliteta TS kao i sredstva automatizacije TS.
TMM Nivo 5
Faza Optimizacije, Prevencije grešaka i Kontrola kvaliteta: Nakon
uspešne izgradnje infrastrukture kroz sazrevanje TMM od Nivoa 1 do 4,
za koji se može reći da je TS definisan i kontrolisan, preko metrika kao što
su troškovi, efikasnost, efektivnost sada se na TMM Nivo 5 pristupa
finom podešavanju i stalnom unapređenju kvaliteta TS. Proces TS je
kontrolisan statističkim postupcima uzorkovanja i merenja nivoa
poverenja metrika kvaliteta TS kao što su troškovi, efikasnost, efektivnost.
Uspostavljena je procedura za izbor i ocenu sredstava i alata za TS.
Automatska sredstva TS se koriste u svim fazama testiranja softvera
dizajnu test primera, izvršavanju testova, ponovnom izvršavanju,
ažuriranju baze podataka o otkazima, greškama, alati za metriku, praćenje
generisanja i analizu uzroka istih kao i sredstva održavanja tzv.
“Testware”.
Razvoj softvera obuhvata:




Precizno planiranje(resursa, troškova, trajanja, obuke kadra i td.)
Identifikaciju, procenu i kontrolu rizika na softverskom projektu
Utvrđivanje merenja kvaliteta softverskog proizvoda
Kvantitativno upravljanje procesom testiranja tj. aktivnostima osiguranja kvaliteta softvera u cilju
povećanja efikasnosti i efikasnosti otkrivanja i otkrivanja grešaka u toku razvoja softvera.
Pošto je nemoguće izvršiti testiranje i dokazati da je softver bez greške kako u fazi razvoja tako i u
fazi održavanja softvera cilj ovog projekta bi bio da se predloži model razvoja, odgovarajuće metode,
algoritmi i odgovarajuće softverski alati za integralni i optimizirani proces testiranja i održavanja softvera.
U postizanju što boljeg kvaliteta softverskog proizvoda optimizacija se vrši uz navedena ograničenja u
pogledu vremena i predviđenog budžeta.
16
Slika 2. Arhitektura OptimaISQM-a i Komponente softverske arhitekture OpimalSQM rešenja
OptimalSQM sadrži (OQT MNGR, OQT BOX, OQT MAINT, OQT OPST, OQT SIM) i
dostupan je kao sveobuhvatni paket rešenja za upravljanje testiranjem i simulacijom mogućih scenarija
procesa testiranja konkretne kompanije i konkretnog projekta. MNGR je u srcu sistema, pruža integrisano
i koherentno upravljanje multidisciplinarnim aspektima ispitivanja softvera i omogućava testiranje pravila
u upravljanju procesom testiranja određenog tipa softvera na optimalan način, konkretne kompanije i
konkretnog projekta putm simlacije mogućih scenarija realizacije procesa testiranja u okviru planiranog
budžeta, trajanja i atribta kvaliteta softvera koji se razvija.
OQT MNGR komponenta se nalazi u srcu PISA-e, obezbeđuje integrisano i
koherentno upravljanje multidisciplinarnim aspektima operacija testiranja, omogućavajući naprednu
generaciju pravila testiranja. MNGR sadrži SaaS-ove (Softwere as a Service) paradigme pravila - koja će
biti prvi industriski jezik scenarija za testiranje softvera sa lako prilagodljivim unapred definisanim
predložcima pravila - za rešavanje kritičnih vektorskih (preko 100 promenljivih) u procesu upravljanja
testiranjem. Takođe, važna funkcija MNGR komponente je da pruži sve upitnike na projektu: aktivnosti
razvoja procesa i bitne stavke produktivnosti procesa radi izračunavanja ograničenja procene rizika i radi
postizanja održive procene određenih preduzeća i projekata.
17
OQT SIM componenta simulira procese (scenarije) testiranje na osnovu
uspostavljenih pravila i algoritama koji su bazirani na empirijskim rezultatima testiranja, kvalifikacijom
potencijalne koristi ovih pravila pre primene. Zahvaljujući nadgledanjem planiranja, OQT-SIM takođe
proverava poboljšanje kvaliteta i efikasnosti postojećih pravila postavljenih tokom vremena, što
omogućava poređenje stvarne koristi baziranih na akumulaciji informacija u realnom svetu procesa
testiranja za razne vrste softverskih proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj
pružamo servis. OQT-SIM nudi tačno razumevanje stvarne koristi i ROI postavljenih pravila, pruža dokaz
koncepta za više scenarija stvarnih performansi konkretne kompanije i konkretnog projekta te kompanije
(iz sopstvene metrike ili usrednjene baze merenih karakteristika tipa softverskog proizvoda koji se razvija,
performansi razvojnog tima, procesa testiranja u datoj kompaniji i sl.), procenu optimalnog scenarija za
dati projekat na bazi rezultata simulacije mogućih scenarija testiranja spremljenog pre primene u
realizaciji datog konkretnog softverskog projekta. SIM nudi simulaciju šablona koji sadrže algoritme iz
različitih porodica softverskih proizvoda, nivoa zrelosti softverskih kompanija, kao što su smanjenje
vremena testiranja, napredna statistička kontrola procesa, kvalitet i pouzdanost, smanjenje naknadne
dorade usled napravljenih grešaka u svim fazama razvoja softvera. Svaka familija stimulacije je bogata sa
pravilima koji su posebna meta poslovnih potreba. Potpuno integrisan sa svim drugim OQT-MNGR
modelima, OQT-SIM omogućava simulaciju pravila i postavljena pravila definisana u OQT-pravilima,
koji onda mogu biti objavljeni putem OQT-MNGR u realnom vremenu ili kasnijem radnom okruženju.
Simulacijoni tok je intuitivan, jednostavan za korišćenje i podržan je jakom metodologijom.
18
OQT BOX komponenta će biti najbolja praksa i skup univerzalnih tehnika za
testiranje softvera po metodi „Crne kutije”, „Bele kutije” i ”Sive kutije” u IT industriji, koje će biti
spremljene za sve vrste softverskih proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj
pružamo servis i kupljene softverske alate za testiranje. BOX komponenta će biti potpuno nezavisna od
modela procesa razvoja softvera i vrste softverskih proizvoda, podržavajući sve nivoe i tipove testiranja
softvera. Kao deo rešenja OptimalSQM-a, izvršavaće se na zahtev OQT MNGR komponente, a na osnovu
proverenih pravila koja su kreirana i proverena simulacijom mogućih scenarija testiranje softvera pre
njihove primene u tesetiranju konkretnog softvera koji razvija i testira konkretna kompanija sa svojim
ljudskim, procesnim i laboratorijskim kapacitetima, a prema uspostavljenim kriterijumima efikasnosti i
efektivnosti za sve SDLC aktivnosti.
19
OQT MAINT komponenta razmišlja o svim rezultatima testiranja radi poboljšanja
kontrole kvaliteta i upravljanja svim aspektima operacija testiranja u korektivnom, adaptivnom i
perfektivnom održavanju softvera kako u toku razvoja tako i nakon isporuke softverskog proizvoda na
upotrebu. MAINT komponenta vrši unakrsne procene kvaliteta svih flota testiranja, za sve procene
efikasnosti testiranja u otkrivanju i otklanjanju defekata (povećenje prinosa otkrivenih grešaka), nudeći
ekstremni integritet podataka. Osim toga, MAINT komponenta poboljšava pouzdanost softvera kroz SRE
(Software Reliability Engineering) metodologiju metrike pouzdanosti softverskog proizvoda u
predviđanju i proceni kritičnih faktora kao što su: stopa grešaka po fazama razvoja softvera, konačna
stopa grešaka nakon 6 meseci upotrebe softvera, gustine grešaka na KSLOC ili FP metrici veličine
softvera, profil greška itd. Na osnovu ovih podataka MAINT komponenta obezbeđuje kompletnu tehničku
podršku nakon puštanja softverskih proizvoda u promet, odnosno program za aktivnosti održavanje tj.za
korektivno, adaptivno, perfektivno i preventivno održavanje na optimizovan način.
20
OQT OPST komponenta (OPeratinonal Software Testing) treba timu za planiranje i
sprovođenje testiranja konkretnog razvijanog softvera, konkretne kompanije (Project Specific Software
Testing) omogući da na osnovu stvarnih performansi konkretne kompanije i konkretnog projekta te
kompanije i pronađenog optimalnog scenarija za dati projekat na bazi REZULTATA izvršenih simulacija
(OQT SIM komponente) mogućih scenarija testiranja pre primene u realizaciji datog konkretnog
softverskog projekta odredi karakteristike integralnog i optimalnog PTS (IOPTS). Dakle, na osnovu
sopstvene metrike ili usrednjene baze merenih karakteristika tipa softverskog proizvoda koji se razvija,
performansi razvojnog tima, zrelosti (TMM nivoa) procesa testiranja u datoj kompaniji i sl., odredi
aktivnosti i objekte testiranja u tačkama provere artifakata datog PTS (SDLC), odredi adekvatne tehnike
detekcije grešaka koje obezbeđuju zahtevani kvalitet tokom razvoja softverskog proizvoda u okvirima
projektnih ograničenja tj. sve parametre IOPTS.
21
22
1.1
Osvrt na OQT SIM komponentu
Kako je testranje ključna aktivnost u procesu razvoja kvalitetnog softvera, pravila testiranja nisu
više samo pravila - to su poslovne odluke koje direktno utiču na troškove, testiranje kvaliteta i
pouzdanosti. Današnje tehnike i metode nastoje da izbegnu višestruko testiranje, uzimajući u obzir
testiranje karakteristika kvaliteta softverskog proizvoda, kao i visok nivo pouzdanosti krajnjeg proizvoda.
Na kraju ovoga pogleda, potrebno je ponuditi rešenje koje može da precizno i lako kvalifikuje i
kvantitativno utvrdi uticaj procesa testiranja softvera, pre njegovog uvođenja u proizvodnju tj. realno
okruženje kod korisnika. To rešenje predstavlja u ustvari zadatak simulacije mogućih scenarija realizuje
procesa razvoja i testiranja konkretnog softverskog proizvoda date kompanije sa aspekta: zrelosti,
tehničkih kapaciteta, ljudskih resursa u cilju pronalaženja optimalnog scenarija realizacije softverskog
projekta.
Slika 3. Softverski alati, tehnike i modeli koje nudi naše OptimalSQM rešenje
OQT SIM komponenta simulira procese (scenarije) testiranje na osnovu uspostavljenih pravila i
algoritama koji su bazirani na empirijskim rezultatima testiranja, kvalifikacijom potencijalne koristi ovih
pravila pre primene. Zahvaljujući nadgledanjem planiranja, OQT-SIM takođe proverava poboljšanje
kvaliteta i efikasnosti postojećih pravila postavljenih tokom vremena, što omogućava poređenje stvarne
koristi baziranih na akumulaciji informacija u realnom svetu procesa testiranja za razne vrste softverskih
proizvoda, nivoa CMM i TMM zrelosti konkretne kompanije kojoj pružamo servis.
OQT-Sim nudi tačno razumevanje stvarne koristi i ROI postavljenih pravila, pruža dokaz koncepta
za više scenarija.
SIM nudi simulaciju šablona koji sadrže algoritme iz različitih porodica softverskih proizvoda, nivoa
zrelosti softverskih kompanija, kao što su smanjenje vremena testiranja, napredna statistička kontrola
23
procesa, kvalitet i pouzdanost, dispozitiv i naknadna obrada. Svaka familija stimulacije je bogata sa
pravilima koji su posebna meta poslovnih potreba. Potpuno integrisan sa svim drugim OQT-MNGR
modelima, OQT-Sim omogućava simulaciju pravila i postavljena pravila definisana u OQT-pravilima,
koji onda mogu biti objavljeni putem OQT-MNGR u realnom vremenu ili kasnijem radnom okruženju.
Simulacijoni tok je intuitivan, jednostavan za korišćenje i podržan je jakom metodologijom.
Realizacijom servisno orijentisane arhitekture (PISA) sa integrisanim ekspertskim alatima (Profit eXpert,
Planner eXpert, Risk Management eXpert, Quality eXpert, Maintenance eXpert, People Performance
eXpert and Process Dynamics Control eXpert) biće ponuđeno OptimalSQM rešenje, koje se sastoji od
skupa softverskih servisa koji se integrišu na zahtev da bi se optimalno upravljalo procesom razvoja
kvalitetnog softvera. OptimalSQM rešenje će biti izbalansirano i unificirano tako da nudi potpun repertoar
servisa obezbeđenja i kontrole razvoja kvalitetnog softvera na efikasan, efektan i konzistentan način,
izborom najboljih strategija i tehnika (zasnovane na simulaciji više scenarija) testiranja softvera (TS) na
početku softverskog projekta. Malim i srednjim preduzećima koja razvijaju softver, prvenstveno, biće
ponuđen kao proizvod: 1) Web portal - repozitorij najboljih modela i tehnika iz prakse, integrisanih u
optimizovan i kvantitativno rukovođen proces testiranja i održavanja softvera; 2) softversko okruženje za
optimalan razvoj kvalitetnog softvera (brže, bolje i jeftinije od drugih rešenja) koje omogućava
minimizaciju troškova i rizika, izborom i prelaženjem na alternativne planove testiranja, kada trenutni
24
izbor ne može da zadovolji ograničenja koja postavljaju zahtevi kvaliteta, slobodni resursi (ljudi i
oprema), kvantitativni kriterijumi optimalnosti i stabilnosti koji se uspostavljaju na bazi raspoloživih
resursa i performansi date kompanije i 3) na bazi izrađenog ekonomskog modela kvaliteta softvera oceni
isplativost predloženih aktivnosti obezbeđenja i kontrole kvaliteta, kao i mera za stalno poboljšanje PRSPTS na osnovu ekonomskih parametara (ROI, BCR, CAPEX, OPEX i dr.).
Menadžment (odgovoran za projektovanje i testiranje) softverskog projekta će na brz i jednostavan način
izrađivati: glavni plan testiranja na bazi utvrđene metrike kvaliteta softvera, izgraditi testno okruženje
(oprema i softver tzv. Testware), strategiju i opis aktivnosti u implementaciji automatizovanog procesa
TS, test slučajeve za svaku odabranu tehniku TS, izveštaje o uočenim problemima tokom TS i
postignutim rezultatima u odnosu na plan TS, predloga izmena u dokumentima planiranog PRS-PTS tzv.
Upravljanje konfiguracijom i sve izveštaje o performansama procesa TS (efiksanosti, troškovima,
rizicima) i kvalitetu softverskog proizvoda koje menadžment zahteva.
Takođe, OptimalSQM rešenje će ponuditi menadžmentu softverskog projekta čitav spektar servisa 4. i 5.
nivoa zrelosti PRS-PTS kompanije prema SEI CMM i TMM metodologiji, na njihov zahtev, kao što su:
1. Menadžment servisi ostvarenog u odnosu na planiranu dobit softverskog projekta u toku PRS-PTS
2. Kvantitativno upravljanje softverskim projektom (veličinom softvera, troškovima, potrebnim
resursima,
procenu
trajanja
pojedinih
poslova
i
zadataka
na
projektu
i
sl.)
3. Kvantitativno upravljanje rizicima (Ocenjivanje rizika preko identifikacije kritičnih rizika na projektu i
preporuke kako se ti rizici mogu smanjiti i držati pod kontrolom na prihvatljivom nivou. Kvantitatino će
moći određivati upotrebu resursa u procesu TS koji daju najbonje rezultate).
4.
Kvantitativna
predikcija
i
ocenjivanje
pouzdanosti
softverskog
proizvoda
5. Prilagođen (datoj) kompaniji proces merenja – P3 (Proizvoda, Projektnih procesa, Projektanata)
• Ključna metrika i merenje kvaliteta softverskog proizvoda kao što su merenje veličine, prekrivenost
projektnih zahteva, upravljanje defektima i sl.
• Ključna metrika i merenje napredovanja na projektu , i
• Ključna metrika i merenje performansi projektnog tima, koji skupa pružaju mogućnost da menadžmnjnt
projekta može kvantitativno ocenjivati efikasnost i efektivnost realizacije projekta i da identifikuje rizike
na softverskom projektu.
Procenjuje se, na osnovu do sada obvjavljenih rezultata istraživanja u okviru projekta TR13018, da će za
tri godine primene predloženog softverskog okruženja sa integrisanim ekspertskim alatima, dovesti do
povraćaja investicije tj. ROI od 100:1, odnosno za svaku investiranu monetarnu jedinicu dobiće se 100
novčanih jedinica u odnosu na postejeće modele i infrastrukturu PRS-PTS softverske kompanije 1 i 2
nivoa CMM i TMM zrelosti. Važan cilj projekta je i da se spreči odliv stručnih kadrova iz regiona, a pre
svega omogući da eksperti iz oblasti matematike, informatike i računarstva ostanu u regionu i nakon
odbrane magistarskih i doktorskih disertacija, rade na Univerzitetu u Novom Pazar, kao i u centru, koji će
služiti kao podrška poslovanju malih i srednjih preduzeća, posebno onih koji se bave razvojem i
održavanjem softvera. Predloženi projekt je u tom smislu u potpunosti usklađen sa osnovnom idejom
finansiranja naučno-istraživačkog rada u Evropi, koji treba da bude u funkciji podrške poslovanja i
razvoja malih i srednjih preduzeća kao i podrške komercijalizaciji naučnih rezultata.
25
Strategijom naučnog i tehološkog razvoja predviđen je intenzivan razvoj IKT, čemu direktno doprinosi
ovaj projekat. Osim toga, projekat je značajan i sa stanovišta tehnološkog razvoja regiona, jer je Državni
univerzitet u Novom Pazaru njegov nosilac. Takođe, ovaj projekat je logičan nastavak projekta TR13018,
čiji ostvareni rezultati istraživanja, posebno koncept Poslovne Inteligentne Simulacione Arhitekture-PISA
ulivaju poverenje u njegov uspeh. Pregledi, inspekcije i testiranje softvera (TS), kao aktivnosti osiguranja
kvaliteta (SQA) su bitan preduslov za uspešan razvoj i implementaciju IKT. Industrija razvoja softvera
troši više od polovine svog budžeta na aktivnosti povezane sa testiranjem u toku projektovanja softvera i
na održavanje softvera nakon njegove predaje na upotrebu. Razvoj kvalitetnog softvera je jako složen i
nepouzdan posao, ali je upravljanje složenim procesom razvoja i testiranja (PRS-PTS) još teže bez
adekvatnog softverskog okruženja sa integrisanim tehnikama, procedurama i alatima koje obezbeđuju
razvoj kvalitetnog softvera u okviru planiranog budžeta i trajanja razvoja (OptimalSQM). Ova tvrdnja je
evidentna, ako se prouči poznati izveštaj – „Chaos Report“, USA Standish Group kompanije iz 2001, na
bazi 8,000 pregledanih velikih projekata, u kome je konstatovano da 25% velikih projekata nikada nije
završen usled znatnog prekoračenja u troškovima, vremenu razvoja, lošem kvalitetu ili njihovom
kombinacijom. Takođe je prosečno 90% više potrošeno od planiranog, preko 120% je duže trajao razvoj
od planiranog kod završenih projekata. Takođe, veliku podršku ovom istraživanju i pristupu PRS-PTS
dao je i izveštaj Američkog Instituta za standarde i tehnologije (NIST) iz 2002, koji je ukazao da se
izgradnjom pomenutnog adekvatnog softverskog okruženja sa infrastrukturom efikasnog i efektivnog
PRS-PTS, na bazi veoma opširnog uzorka analiziranih softverskih projekata u finansijskom sektoru i
oblasti saobraćajne grane industrije, mogu postići značajne uštede u ovim privrednim granama (između
$600 i $1.500 miliona dolara). Da bi se realizovalo softversko okruženje OptimalSQM, istraživanja u
okviru ovog projekta će se fokusirati na dalju razradu i dogradnju PISA, sa odgovarajućim softverskim
komponentama koje omogućavaju dizajnerima softvera da postignu viši kvalitet dizajna, bolji uvid u
predviđanje kvaliteta izabranog dizajna, rukovodiocu testiranja da omogući unapređenje PRS-PTS kroz
ocenu efikasnosti i efektivnosti alternativnih planova SQA upotrebom naprednih, kvantitativnih modela
simulacije procesa detekcije i uklanjanja defekata, potrebnih resursa tokom PRS-PTS na sistematski i
automatizovan način. PISA treba da obezbedi potpun spektar servisa koji zadovoljavaju najviše nivoe (4 i
5 nivo zrelosti PRS-PTS po SEI CMM i TMM metodologiji) za razvoj kvalitetnog softvera na optimalan
način. Istraživanje rešenja PISA se sastoji u: 1) izradi kolekcije najboljih znanja — rešenja iz prakse,
metoda, šablona smeštenih u bazi znanja; 2) automatizaciji procesa planiranja zasnovanog na modelima
estimacije veličine softvera, cene, broju projektanata, trajanja razvoja i testiranja; 3) optimizaciji PRSPTS zasnovane na modelovanju i simulaciji kroz različite nivoe apstrakcije softvera koji testiramo, a u
cilju postizanja stabilnog (predvidljivog i kontrolabilnog) procesa testiranja softvera sa najnižim rizikom,
po prihvatljivoj ceni i u prihvatljivom vremenu. Optimalno rešenje se određuje na bazi scenarija
angažovanja resursa na početku projekta (na osnovu sopstvenih ili iskustvenih podataka iz prakse drugih
kompanija) kao i u toku same realizacije PRS-PTS; 4) izradi okruženja za komjutersko eksperimentisanje
po principima planiranog eksperimenta (Design of Experiments) sa razrađenim pravilima preko
čarobnjaka tzv. Rules by wizards; 5) implementaciji integrisanog procesa merenja kvaliteta softvera; 6)
izradi ekonomičnog modela kvaliteta softvera i tehnika upravljanja troškovima realizacije PRS-PTS; 7)
razradi metodologije upravljanja rizikom PRS-PTS; 8) izradi balansirane metrike produktivnsti,
usaglešene sa strategijom balansirane tabele željenih i postignutih rezultata (Balanced Scorecard) na putu
dostizanja 4 i 5 nivoa zrelosti PRS-PTS (po SEI CMM i TMM metodologiji) i Šest sigma strategiji
stalnog poboljšanja PRS-PTS; 9) izradi grafičkog korisničkog interfejsa za konkurentan, jednostavan rad
većeg broja članova tima, zasnovan na internet tehnologijama (Web-based GUI) radi izvođenja velikog
26
broja simulacija i deljenja rezultata obavljenih simulacija, i 10) da omogući razmenu podataka i
dokumenata sa standardnim radnim okruženjem članova tima jedne kompanije u obavljanju poslova
planiranja, rasporeda poslova, estimacije troškova, resursa kao što su: MS Office, MS Rroject i drugi
specijalizovani softverski alati). PISA treba, u osnovi, da bude zasnovana na servisno orijentisanoj
arhitekturi ( SOA) sa integrisanim ekspertskim alatima (Profit eXpert, Planner eXpert, Risk Management
eXpert, Quality eXpert, Maintenance eXpert, People Performance eXpert and Process Dynamics Control
eXpert) za sve modele PRS-PTS. Zadatak Profit eXpert softverske komponente će biti da na bazi
izrađenog ekonomskog modela kvaliteta softvera oceni isplativost predloženih aktivnosti obezbeđenja i
kontrole kvaliteta PRS-PTS na osnovu ekonomskih parametara (ROI, BCR, CAPEX, OPEX i dr.). Planer
eXpert treba na osnovu istraženih modela estimacije i predikcije veličine softvera, složenosti, trajanja
razvoja, trajanja testiranja, broja potencijalnih grešaka u softveru, trajanja i cene njihove popravke tokom
PRS-PTS, pruži neophodne podatke za simulaciju različitih scenarija PRS-PTS iz kojih se bira optimalni
scenario realizacije projekta. Risk Management eXpert treba da u saradnji sa Profit eXpert sofverskim
alatom pruži servis menadžerima dizajna i testiranja softvera u: identifikaciji, proceni efekata, plana
aktivnosti smanjenja i kontrole rizika na prihvatljivom nivou, datog softverskog projekta. Quality eXpert
treba da integriše specijalizovane ekspertske alate (Quality Metrics eXpert, Test Effort Estimation eXpert,
Reliability eXpert, Product release eXpert) koji obezbeđuju servis menadžerima dizajna i testiranja
softvera u: izradi metrike integrisanog procesa merenja kvaliteta softvera, automatizaciji procesa
planiranja zasnovanog na modelima estimacije veličine softvera, cene, broju projektanata, trajanja razvoja
i testiranja, proceni i predikciji pouzdanosti softverskog rešenja tokom simulacije različitih scenarija
dizajna i u toku realizacije PRS-PTS, koji treba da dovedu do donošenja odluke o završetku PRS-PTS i
predaje softveskog proizvoda (IS) na upotrebu. Maintenance eXpert treba da obezbedi servis
menadžerima dizajna i testiranja softvera u: izradi plana i proceni troškova korektivnog, adaptivnog,
perfektivnog i preventivog održavanja softvera. Kao što smo već istakli, razvoj kvalitetnog softvera je
jako složen i nepouzdan posao, ali je upravljanje složenim, dinamičkim procesom razvoja i testiranja (sa
preko 100 promenljivih) još teže bez adekvatnog softverskog alata Process Dynamics Control eXpert, koji
treba da identifikje observabilne i kontrolabilne promenjive konkretnog softverskog projekta, da uspostavi
kriterijume stabilnosti i optimalnosti u svakoj fazi PRS-PTS i za ceo proces. Da bi ovako realizovano
softversko okruženje za optimalan razvoj kvalitetnog softvera zaista obezbedilo uspeh na konkretnom
softverskom projektu tj. Dalo očekivane rezultate, neobhodno je: ocenjivanje i praćenje performansi
projektnog tima, podizanje stručnog kapaciteta ljudi koji realizuju projekat korišćenjem softveskog alata
People Performance eXpert. Očekuju se, nakon implementacije OptimalSQM rešenja u malim i srednjim
preduzećima, velike uštede, povećanje konkurentnosti, podizanje nivoa zrelosti preduzeća na 4 i 5 nivo
CMM
i
TMM
zrelosti
i
zadovoljstva
korisnika
proizvoda
i
usluga.
Realizacijom PISA sa integrisanim opisanim ekspertskim alatima, malim i srednjim preduzećima,
prvenstveno, biće ponuđen: 1) Web portal-repozitorij najboljih modela i tehnika iz prakse, integrisanih u
optimizovan i kvantitativno rukovođen proces testiranja i održavanja softvera; 2) okruženje za simulaciju
scenarija razvoja kvalitetnog softvera koje omogućava minimizaciju troškova i rizika, izborom
alternativnih planova testiranja koji zadovoljavaju ograničenja u pogledu slobodnih resursa, kriterijuma
optimalnosti i performansi date kompanije i 3) ekonomski model kvaliteta softvera za ocenu isplativosti
predloženih aktivnosti SQA, mere za poboljšanje PRS-PTS na osnovu ekonomskih parametara (ROI i
dr.). Menadžment (odgovoran za projektovanje i testiranje) projekta će na brz i jednostavan način
izrađivati: glavni plan testiranja na bazi utvrđene metrike kvaliteta softvera, izgraditi testno okruženje
(oprema i softver tzv. Testware), strategiju i opis aktivnosti u implementaciji automatizovanog procesa
27
TS, test slučajeve za svaku odabranu tehniku TS, izveštaje o uočenim problemima tokom TS i
postignutim rezultatima u odnosu na plan TS, predloga izmena u dokumentima planiranog PRS-PTS tzv.
Upravljanje konfiguracijom i sve izveštaje o performansama procesa TS (efiksanosti, troškovima,
rizicima) i kvalitetu softverskog proizvoda koje menadžment zahteva. Očekuju se, nakon implementacije
OptimalSQM rešenja u malim i srednjim preduzećima, velike uštede, povećanje konkurentnosti,
podizanje nivoa zrelosti preduzeća na 4 i 5 nivo CMM i TMM zrelosti i zadovoljstva korisnika proizvoda
i usluga. Procenjuje se, na osnovu do sada obavljenih istraživanja na projektu TR13018, da će za tri
godine primene predloženog softverskog okruženja sa integrisanim ekspertskim alatima, dovesti do
povraćaja investicije - ROI od 100:1, u odnosu na postejeću nfrastrukturu PRS-PTS softverske kompanije
1 i 2 nivoa CMM i TMM zrelosti. Takođe, OptimalSQM rešenje će ponuditi menadžmentu softverskog
projekta čitav spektar servisa 4. i 5. nivoa zrelosti PRS-PTS kompanije prema SEI CMM i TMM
metodologiji, na njihov zahtev, kao što su: 1. Menadžment servisi ostvarenog u odnosu na planiranu dobit
softverskog projekta u toku PRS-PTS 2. Kvantitativno upravljanje softverskim projektom (veličinom
softvera, troškovima, potrebnim resursima, procenu trajanja pojedinih poslova i zadataka na projektu i sl.)
3. Kvantitativno upravljanje rizicima (Ocenjivanje rizika preko identifikacije kritičnih rizika na projektu i
preporuke kako se ti rizici mogu smanjiti i držati pod kontrolom na prihvatljivom nivou. Kvantitatino će
moći određivati upotrebu resursa u procesu TS koji daju najbonje rezultate). 4. Kvantitativna predikcija i
ocenjivanje pouzdanosti softverskog proizvoda 5. Prilagođen (datoj) kompaniji proces merenja – P3
(Proizvoda, Projektnih procesa, Projektanata) • Ključna metrika i merenje kvaliteta softverskog proizvoda
kao što su merenje veličine, prekrivenost projektnih zahteva, upravljanje defektima i sl. • Ključna metrika
i merenje napredovanja na projektu , i • Ključna metrika i merenje performansi projektnog tima, koji
skupa pružaju mogućnost da menadžmnjnt projekta može kvantitativno ocenjivati efikasnost i efektivnost
realizacije projekta i da identifikuje rizike na softverskom projektu. Važan očekivani ključni rezultat
projekta je i da se spreči odliv stručnih kadrova iz regiona, a pre svega omogući da eksperti iz oblasti
matematike, informatike i računarstva ostanu u regionu i nakon odbrane magistarskih i doktorskih
disertacija, rade na Univerzitetu u Novom Pazar, kao i u centru, koji će služiti kao podrška poslovanju
malih i srednjih preduzeća, posebno onih koji se bave razvojem i održavanjem softvera. Predloženi
projekt je u tom smislu u potpunosti usklađen sa osnovnom idejom finansiranja naučno-istraživačkog rada
u Evropi, koji treba da bude u funkciji podrške poslovanja i razvoja malih i srednjih preduzeća kao i
podrške komercijalizaciji naučnih rezultata.
28
Download

Ovde - Upravljanje procesom testiranja softvera