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

Troškovi proizvodnje se smanjuju sa ranim otkrivanjem I ispravkom grešaka. tehnikama i alatima. Ukupna ušteda prevazilazi pocetni trošak. Ukoliko su specifikacije u hijerarhijskim odnosima. Uz efektivan proces verifikacije redukuju se defekti instaliranih sistema. 2. Nedetektovane greške koje su izazvale milione poslovnih gubitaka uslovile su rast nezavisnog testiranja. pocevši od faze softverskih zahteva. Jedina kritika verifikacije je da povecava troškove razvoja softvera. Cilj je da se sprece defekti ili nedostaci i da se proizvod ucini merljivim pomocu parametara kvaliteta. 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. Verifikacija obuhvata sistematicne procedure pregleda. Kada se troškovi softvera posmatraju kroz citav životni vek proizvoda. specifikacije arhitekture (prikazuje arhitekturu programa. evidentni su različiti nivoi testiranja: 3 . rezultat su proizvodi visokog kvaliteta i smanjeni troškovi održavanja. Verifikacija takode omogucava interoperabilnost medu razlicitim sekcijama u softverskoj dokumentaciji i povezanim delovima zahteva. Testiranje softvera se posmatra kao validacioni proces. Inspekcioni troškovi sastoje se od merenja. a validacija zadovoljenje zahteva kupaca na kraju životnog ciklusa proizvoda.jer će prevideti sopstvene greške. Dobitna kombinacija je korišcenje verifikacije i validacije u procesu testiranja. Uz alate za automatsko testiranje. savremeni procesi testiranja se ne odvijaju samo nakon završetka programiranja. Na osnovu hijerarhije programa specifikacije. analize i testiranja ugradene u životni ciklus. verifikacija zapravo umanjuje troškove softvera. tj. Verifikacija ili validacija: Verifikacija omogucava da proizvod zadovolji zahtevekoji si specificirani tokom prethodnih aktivnosti i oblikovani kroz životni ciklus proizvoda. Kreiranje test proizvoda je bliže validaciji nego verifikaciji. Verifikacija obezbeduje kvalitet i održavanje softvera. Komparacija pravaca . 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. dugorocno gledano. program se može testirati u različitim fazama razvoja. a često i na koji način). Nakon završetka programiranja sistem se validira ili testira da bi se odredile funkcionalne ili operativne performanse. vec su utkane u sam proces razvoja softvera.- Ne dozvolit svojim programerima da testiraju sopstveni rad. Preventivni troškovi sastoje se od akcija koje se preduzimaju kako bi se sprecili defekti. Neke od mera kvaliteta su: struktuiranje razvojnog procesa uz pomoc standarda za razvoj softvera i podršku razvojnog procesa metodama. procene i provere proizvoda ili usluga i njihovog slaganja sa standardima i specifikacijama. nego za vreme dizajniranja. inspekcije. Ukupni trošak efektivnog upravljanja kvalitetom predstavlja sumu cetri komponente troškova: prevencije. jer ispravka grešaka može koštati 20 do 100 puta više za vreme operacija i održavanja sistema. Troškovi internih otkaza su oni koji podrazumevaju ispravku proizvoda sa greškama pre njihove isporuke. Naravno. internih i eksternih otkaza. Ovo se izbegava unakrsnim testiranjem tj. Troškovi eksternih otkaza sastoje se od grešaka otkrivenih nakon lansiranja proizvoda. komponente unutar programa i njihove odnose) i detalje specifikacije programa ( opisuje kako se primenjuje svaka komponenta programa ). Jednostavno je uočiti razliku između specifikacije programa (određuje šta program treba da radi. programeri raymenjuju kod i testiraju tuđi kod. do faze kodiranja. Prevencija ili detekcija: Kvalitet se ne može postici na vec gotovom proizvodu.ekonomski aspekti U literaturi se navode prednosti nekih od pravaca ili metoda u testiranju posmatrano sa aspekta troškova pre svega: 1.

pregled zbirnih rezultata.1. U procesu testiranja koriste se i razliciti alati koj pospešuju proces i daju bolji uvid u rezultate(npr. Slika1: Proces testiranja 4 .Rational. 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. Testprimera) 3. modela i drugih ulaza testiranja). Evaluacija testova (procena testova tj. gde se testiranje vrši. analiza izlaza. kada se vrši i ko izvršava testove) 2. Planiranje testiranja (odreduje se predmet. Test Complete i sl. uticaj promene zahteva i ulaza na plan testiranja) Svaka od ovih aktivnosti ima ulaze i izlaze. Izvršavanje testova (izvršavanje implementacije testa radi provere funkcionalnosti sistema) 5.). Implementacija testova (pravljenje višestruko upotrebljivih test scriptova koji realizuju test primere) 4. Testiranje jedinice (podrazumeva testiranje svake jedinice kao osnovne komponente u cilju određivanja korektnosti) 2. cilj i razlog testiranja( na osnovu zahteva. Dizajn testova (odreduje kako se sprovodi testiranje na osnovu artefakta tj. 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. validnosti izvršavanja testa.

Jedinicno testiranje (unit testing) – primenjuje se na pojedine klase. 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.Strategija testiranja predstavlja celokupan pristup testiranju. predloge. Programi mogu biti veoma jednostavni ili složeni. programski kod) i efikasne su metode za poboljšanje kvaliteta i razvojnog procesa proizvoda. . U testiranja višeg reda spadaju: . 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. Za ovaj process moraju se realizovati standardizovani propisi i procedure koje definišu nacin rada I aktivnosti test odeljenja. metode. izvršenje i evaluaciju. gde jedan od ucesnika ima ulogu vodeceg. kao i svih ucesnika u razvoju. module ili komponente programskog koda. 5 . . Ostali clanovi ucestvuju aktivno u raspravi. Ukoliko bi se radilo u idealnim uslovima.).Test materijal je podložan periodicnim aktivnostima kontrole kvaliteta Tipovi testiranja Inspekcije. tipove koji ce se primeniti. . a nakon jediničnog testiranja. raspored i zaduženja kod testiranja kroz plan testiranja. test primeri i dr.Odgovarajuci materijal (dokumenta.). strategija testiranja bila bi zajednička za celu organizaciju. da bi se lakše uocile greške i drugi problemi. recenzije i pregledi: Inspekcije. 2. Pregled vrše osobe koje nisu autori. . tehnike i alati. Integraciono testiranje – primenjuje se na softverski sitem kao celinu. Specifikacija predstavlja osnovnu komponentu svih definicija. kao i za sve programe unutar nje. 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. Sprovode se na sastancima. 3.Odgovornosti i zaduženja za planiranje testa.Ciljeve testa. Sve aktivnosti clanova tima koji ucestvuju u realizaciji procesa testiranja moraju biti dokumentovane i moraju pokriti sledece: . pri čemu se definišu nivoi testiranja.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. Tehnike testiranja 1. 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. Pregledi (walkthrough) – Tehnika pregleda u kojoj autor upoznaje ostale clanove tima sa elementima artefakta koji je izgradio. probleme i sl. a ostali uloge zapisicara(beleži pitanja. recenzije i pregledi su specificne tehnike fokusirane na ocenjivanje artefakata(pogodno za dokumentaciju. Ova tehnika deli se na tehnike bele i crne kutije. Ovo testiranje se dešava pre sistemskog. 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.

). .pregled tehnika testiranja Testiranje se posmatra kao posebna faza životnog ciklusa proizvoda koja prati kodiranje. 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).etalonski test . 4. konzistentna upotreba resursa i sl.. ili bazirano na korišćenju krajnjih korisnika/potrošača u odre₃enom vremenskom periodu. Tehnike se kombinuju i variraju. . . . Moderni model softverskog životnog ciklusa izbegava ovakvo gledanje na stvari i u prvi plan stavlja iterativno testiranje kroz razvoj životnog ciklusa. .uporedenje performansi novog sistema sa nekim. Kako su do sada objašnjeni samo neki od tipova i tehnika testiranja u tabeli je dat pregledsavremenih tehnika testiranja sa opisom.testiranje upotrebljivosti(usability testing) – estetski aspekti. ali se često odnosi na to da testeri dobro razumeju softver pre samog testiranja. prekid napajanja ili nedovoljno prostora na disku). Tehnika Acceptance testing – Testiranje prihvatljivosti Kratak opis Finalno testiranje bazirano na specifikacijma krajnjeg korisnika/potrošača. poznatim sistemom. Ad hoc testing – Ad hoc testiranje 6 . referentnim. konzistentnost korisnickog interfejsa.testiranje integriteta(integrity testing) – robusnost(otpornost na otkaze). .test zagušenja – provera da li sistem može da zadovolji višestruke zahteve razlicitih aktera za istim resursom. .test u stresnim uslovima(stress testing) – vrsta testa pouzdanosti sistema pod nenormalnim uslovima (velika opterecenja sistema. Testiranje omogucava ranu detekciju grešaka i ispravku istih i tehnicki uvid u pravu prirodu performansi sistema.test opterecenja – vrsta testa performansi kojim se procenjuju operativni limiti nepromenjivog sistema pod razlicitim opterecenjima ili razlicitih konfiguracija sistema pri istom opterecenju. Obicno se koristi nekoliko testnih metodologija da bi se obradili razliciti aspekti softverskog proizvoda.. . neraspoloživi servisi i sl. Slično istraživačkom testiranju.test konfiguracije (configuration testing) – testira ponašanje softvera u razlicitim hardversko/softverskim okruženjima. Najcešce se mere protok i vreme odziva (srednja i granicna vrednost).. korisnicka dokumentacija. nedovoljno memorije ili drugih resursa.test instalacije(installation testing) – testira instaliranje softvera na razlicitim sistemima i u razlicitim situacijama (npr.

Verifikacija da svaki uslov obuhvata sve moguće izlaze . Testiranje koliko dobro softver radi u odre₃enom hardversko/softverskom/OS/mrežnom okruženju. Integrisanje modula ili programa počevši od dna. a ne programeri i testeri. Verifikacija da svaka grana ima true ili false izlaze. Obično ga izvršavaju krajnji korisnici ili drugi. Označavanje višestrukih simultanih ulaza koji mogu uticati na uslove testa. Upore₃ivanje slabosti i dobrih strana softvera sa konkurentskim proizvodima. 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. Potvrda da svaki uslov obuhvata sve moguće izlaze. manje promene u dizajnu moguće su kao rezultat ovog testiranja. Identifikovanje testova na bazi tokova i putanja programa ili sistema. Pravljenje CRUD matrice i testiranje svih Basis path testing – Testiranje osnovnih tokova Beta testing – Beta testiranje Black-box testing – Black-box testiranje Bottom – up testing – Testiranje od dna ka vrhu Boundary value testing – Testiranje graničnih vrednosti Branch coverage testing – Branch(gransko) testiranje Branch/condition coverage – Grana/uslov testiranje Cause/effect graphing – Uzrok/posledica graf Comparison testing – Uporedno testiranje Compatibility testing – Testiranje kompatibilnosti Condition coverage testing – Testiranje pokrivenosti uslova CRUD testing – CRUD testiranje 7 . Testovi se generišu iz graničnih vrednosti odgovarajućih klasa.Alpha testing – Alfa testiranje Testiranje kada je razvoj pri kraju. Testovi se generišu na osnovu funkcionalnosti sistema. ne programeri ili testeri.

Korišćenje ad hoc ili brainstorming intuicije za definisanje test case-ova. Kombinacija Black-box i white-box testiranja. neformalno testiranje koje se ne bazira na formalnim test planovima ili test case-ovima. korišćenje mrežne komunikacije. Tabele koje pokazuju kriterijume odluke i respektivne akcije. interakcija sa bazom podataka. Slično sistemskom testiranju.kreacija objekata. Svaki ulazni uslov se deli na dve ili više grupa. Grafička reprezentacija izmerenih vrednosti organizovanih prema frekvenciji doga₃anja koja se koristi da naglasi „vruće“ tačke. uključuje test kompletnog okruženja aplikacije u situaciji kada se oponaša stvarni korisnički svet. ažuriranja i brisanja. Database testing – Testiranje baze podataka Decision tables – Tabele odluka Provera integriteta vrednosti u poljima baze podataka. npr. aplikacijama ili sistemima. Developer pregleda kod. Često označava kreativno. kako bi se izvukle najbolje strane oba ova tipa. Kontinualno testiranje aplikacije kada se Desk checking – Provera End-to-end testing – Sa kraja na kraj testiranje Equivalence partitioning – Ekvivalentno particionisanje Exception testing – Testiranje izuzetaka Exploratory testing – Istraživačko testiranje Free form testing – Slobodna forma testiranja Gray-box testing – Gray-box testiranje Histograms – Histogrami Incremental integration testing – 8 . Identifikovanje poruka o grešci i obrade izuzetaka i uslova koji ih okidaju. Testovi se generišu iz reprezentativnih validnih ili nevalidnih klasa. ili interakcija sa drugim hardverom. čitanja. testeri uče o softveru za vreme testiranja.

Ovaj tip testiranja je jako važan za klijent/server i distribuirane sisteme. Metod odre₃ivanja da li je skup testnih podataka ili testova koristan. Definisano je u zahtevima ili test planovima. Analiza paterna defekata radi identifikacije uzroka i posledica. Delovi mogu biti kodni moduli. Testiranje aplikacije pod opterećenjem. zahteva da različiti aspekti funkcionalnosti aplikacije budu dovoljno nezavisni da rade zasebno. Testiranje kombinovanih delova sistema radi utvr₃ivanja da li zajedno dobro funkcionišu. Testovi se kreiraju ili ponovo pokreću za svaki defekt koji se prona₃e u prethodnim Inspections – Inspekcije Integration testing – Integraciono testiranje JADs Load testing – Load testiranje Mutation testing – Mutaciono testiranje Orthogonal array testing – Ortogonalno testiranje niza Pareto analysis – Pareto analiza Performance testing – Testiranje performansi Positive and negative testing – Pozitivno i negativno testiranje Prior defect history testing – Testiranje prethodnih defekata 9 . Zahteva velike resurse. Izvršavaju ga testeri ili programeri. pre kompletiranja svih delova programa. ulazne i izlazne kriterijume. 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. Testiranje pozitivnih i negativnih vrednosti svih ulaza. Koristi se često sa stres i load testovima. individualne aplikacije ili klijent/server aplikacije na mreži. Tehnika koja spaja korisnike i developere pri dizajnu sistema. Formalni pregled koji koristi čekliste.Inkrementalno integraciono testiranje doda nova funkcionalnost. Matematička tehnika odre₃ivanja koje varijacije parametara treba da se testiraju.

kako bi se prešlo na veći stepen testiranja. Testiranje sistema sa manjim izmenama za vreme spiralnog razvoja. Grafički prikaz kako karakteristike kvaliteta variraju u vremenu. gde je svaka vrednost jednako važna. debagovanja. Meri stepen poslovnog rizika u sistemu kako bi se poboljšalo testiranje. Za svaki ulaz definiše se opseg za koji bi ponašanje sistema trebalo da bude isto. Nasumična selekcija iz skupa ulaznih vrednosti. neće biti potrebno testiranje u takvom stanju. Intergacija modula ili programa sa vrha i dna simultano. Tehnika u kojoj se prvo identifikuju stanja sistema. održavanja ili razvoja u novom release-u. Prototyping – Prototipovanje Pristup prikupljanja podataka od korisnika izgradnjom i demonstracijom nekog dela potencijalne aplikacije. Random testing – Nasumično testiranje Range testing – Testiranje opsega Recovery testing – Testiranje oporavka Regression testing – Regresiono testiranje Risk-based testing – Testiranje zasnovano na riziku Run charts – Grafici izvršavanja Sandwitch testing – Sendvič testiranje Sanity testing – Zdravorazumsko testiranje Security testing – Testiranje sigurnosti State transition testing – Testiranje prelaza stanja 10 . Inicijalni test napor kako bi se odredilo da li se novi softver dobro ponaša.testovima sistema. Testiranje koliko dobro sistem reaguje na neautorizovane napade. Npr. hardverskih otkaza ili drugih velikih problema ovog tipa. a potom se pišu test case-ovi kako bi se testirali okidači koji prouzrokuju prelaz iz jednog stanja u drugo. Ako novi softver obara sistem svakih 5 minuta. Testiranje koliko dobro se sistem oporavlja od padova.

Tehnika vo₃ena podacima i test kombinacijama ulazne sintakse. Mikro testiranje odre₃enih funkcija ili modula koda.Statement coverage testing – Testiranje izraza Statistical profile testing – Statističko profil testiranje Svaki izraz programa se izvršava bar jednom. pokriva sve kombinovane delove sistema. uslovi. Koriste se intervjui. sigurnosti i integriteta podataka tabela ulaza. Kombinovanje individualnih jedinica u okviru niti funkcionalnosti koje zajedno postižu neku funkciju ili skup funkcija. Test izgleda aplikacije za korisnika. Integracija modula ili programa počevši od vrha. Obično ih obavlja programer. Statističke tehnike se koriste da razviju korisnički profil sistema koji pomaže da se definišu prelazne putanje. Black-box tip testiranja koji se bazira na zahtevima. Testiranje funkcionalnosti sistema pod opterećenjem. Tehnika za upravljanje sastankom na kom učesnici projekta ispituju rad proizvoda. Subjektivno je i zavisi od ciljne grupe korisnika. Testovi se definišu ispitivanjem logičkih Stress testing – Stres testiranje Structured walkthroughs – Strukturni pregledi Syntax testing – Sintaksno testiranje System testing – Sistemsko testiranje Table testing – Tabelarno testiranje Thread testing – Testiranje niti Top-down testing – Testiraje od vrha ka dnu Unit testing – Jedinično testiranje Usability testing – Testiranje korisnosti White-box testing – White-box testiranje 11 . jer zahteva detaljno poznavanje internog dizajna i koda programa. ponavljanjem odre₃enih akcija ili ulaza. a ne tester. veliki ulazni brojevi ili kompleksni upiti nad bazom. Programeri i testeri ne odgovaraju za ovaj tip testiranja. video zapisi i druge tehnike. Testiranje pristupa. funkcije i tabele podataka.

kao i dizajna konkretnog softverskog proizvoda. Zavisnost petlji je prilično jednostavno testirati. manuelno i automatsko testiranje. logika i stilovi. osim ako postoji među petlja ili kod sadrži B/W petlju. white-box i gray-box testiranje. Praćenje se zasniva na svakom odabranom pojedinačnom delu koda. Metoda bele kutije –"White-box" Ovo testiranje proverava i analizira izvorni kod i zahteva dobro poznavanje programiranja. black-box. zavisnosti između višestrukih staza zapravo nisu testirane za ovaj pristup. deklariše ih ali ih ne koristi.Iako ove staze smatraju nezavisnim. mora se testirati ne samo svaki smer. na primer proverom da li se svaka linija koda izvršava barem jednom.Opis tehnika za testiranje Cesta je i podela testiranja na: 1. Korišćenjem White box testing metoda jedan tester može izvući probne slučajeve koji: 12 . Testovi se izvode na osnovu strukture programa.kao što su programski jezik. Specifičnim testovima može se proveravati postojanje beskonačnih petlji ili koda koji se nikada ne izvršava. Ovo testiranja su vrlo teška i dugotrajana. Tabela 1. staticko i dinamicko testiranje. već i sve moguće kombinacije uslova. proverom svih funkcija ili proverom svih mogućih kombinacija različitih programskih naredbi. Testiranje petlje – ove strategije se odnose na testiranju jedne petlje. š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. Ovaj pristup prikazuje skrivene bugove i koristi ih kao promenljive. Plan testiranja se određuje na osnovu elemenata implementacije softvera. odgovarajućeg programskog jezika. DFT (Data Flow Testing) teži da održava zavisnosti. Put testiranja – put testiranja definiše i pokriva sve moguće puteve kroz kod. 3. · · · · U White box testingu. 2. 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. grupnih petlji i ispletenih petlji.iskaza sistema. skup srednjih staza kroz kod definiše praćenje specifičnih promenljivih kroz svaki mogući proračun. Kod ove metode postoji mogućnost provere skoro celokupnog koda. ali to je uglavnom kroz manipulaciju sekvenci podataka. koristi se kontrola strukture proceduralnog dizajna za dobijanje test slučajeva.

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. Metoda crne kutije –"Black-box" Analizira se samo izvršavanje specificiranih funkcija i vrši se provera ulaznih i izlaznih podataka. 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. Pisanje test slučaja je prilično sporo i teško Šanse za posedovanje neidentifikovanih staza tokom testiranja 13 . Skoro 30% svih grešaka u kodu posledica su problema nepotpunih ili neodređenih specifikacija. funckionalnost. Tačnost izlaznih podataka proverava se na osnovu specifikacije zahteva za softver.● ● ● ● Garantuju da sve nezavisne staze u modulu budu istestirane barem jednom. Upotrebljava unutrašnje strukture podataka kako bi obezbedio njihovu valjanost. Sinonimi za black box uključuju: ponašanje. Problem funkcionalnog testiranja može da se pojavi u slučaju dvosmislenih zahteva i nemogućnosti opisivanja svih načina korišćenja softvera. U ovim testovima se ne vrši analiza izvornog koda.

strukture i sl.kao aplikacija koja verifikuje novu funkcionalnost a da ne onemogući prethodnu. Ekvivalentna vrednost može da se određuje na osnovu sledećeg: ● ● ● ● Ako je ulazni uslov (input conditions) specifičan niz. 14 . Idealan test slučaja otkriva klasu grešaka pre nego što je greška detektovana. jedna važeća i dve nevažeće ekvivalentne vrednosti su definisane Ako je ulazni uslov (input conditions) član specifičnog niza. ove skripte mogu koristiti u budućem razvoju softvera. 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. upravo na tome da je implementirano na racunaru. jedna važeća i jedna nevažeća ekvivalentna vrednost je definisana Ako je ulazni uslov (input conditions) Bulova. Ekvivalentnost particionisanja pokušava da identifikuje naznačenu klasu grešaka u test slučaju. jedna važeća i dve nevažeće ekvivalentne vrednosti su definisane Ako ulazni uslov (input conditions) zahteva specifičnu vrednost. Dizajn test slučaja za ekvivalentnost particionisanja je zasnovano na planiranju ekvivalentnih vrednosti unosa (inputa). 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. Dinamicke tehnike zavise od vremena i podrazumevaju izvršavanje specificnog niza instrukcija na papiru ili racunaru. provera sintakse. Jednom izvedene. osnove automatskog.Alati koji se koriste u Black box testingu Osnovni funkcionalni alati testiranja izvode rezultate testova crne kutije u obliku skripte. Staticko i dinamicko testiranje Staticko testiranje ne zavisi od vremena npr. Ekvivalentne vrednosti prikazuju skup važećih i nevažećih ulznih uslova (input conditions) u sistemu.

odnosno onda kada se i generišu. TS je integrisani deo SDLC. kriterijumа optimаlnosti i performаnsi dаte kompаnije i ekonomski model kvаlitetа softverа zа ocenu isplаtivosti predloženih аktivnosti SQA. Nedostaju resursi. Glavni cilj Testiranja softvera. Organizacije koje su ovladale TMM Nivo 2. mere zа poboljšаnje PRS-PTS(Proces Razvoja Softvera. greške (otkazi) softvera u ranim fazama propagiraju se do zadnjih faza SDLC tj. projektnih zahteva za softver pa do kraja najčešće V modela SDLC. je definisano nakon faze kodiranja zbog nezrelosti samog procesa Testiranja softvera. TMM levels TMM Nivo 1 Inicijalna faza: Testiranje softvera (TS) je haotičan proces. 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. je da se pokaže da je softver zadovoljio specifikaciju. Mnogi problemi vezani za kvalitet softvera na ovom TMM nivou posledica su planiranja TS kasno u ciklusu razvoja softvera (SDLC). integrisаnih u optimizovаn i kvаntitаtivno rukovođen proces rаzvojа. na ovom nivou zrelosti (TMM). Tabela 2 . testirаnjа i održаvаnjа softverа koji zadovoljava 3. Testiranje softvera na Nivou 2. Cilj testiranja softvera je da se pokaže da program radi. izborom аlternаtivnih plаnovа testirаnjа koji zаdovoljаvаju ogrаničenjа u pogledu slobodnih resursа. TMM Nivo 3 Faza Integrisanja: TS nije više faza koja sledi fazu kodiranja. Okruženje zа simulаciju scenаrijа rаzvojа kvаlitetnog softverа koje omogućаvа minimizаciju troškovа i rizikа. Softver se iznosi na tržište bez primene sistema obezbeđenja kvaliteta. loše je definisan i nije jasno razgraničen sa fazom otklanjanja grešaka (debugging). Mada je planirana kao aktivnost. na Nivou 3 aktivnost TS se odvija i planira od početka SDLC tj. Proces Testiranja Softvera) nа osnovu ekonomskih pаrаmetаrа.Nivoi zrelosti TS tzv. naprotiv. Testiranju se pristupa neplanirano i na kraju faze kodiranja programa. zrelosti softverske kompanije. Organizaciono je uspostavljena grupa za TS. To su pre svega ekspertski alati koji se integrisu na zahtev korisnika. Ovaj tip organizacije odgovara SEI CMM Level 1. TMM Nivo 2 Faza Definisana: Testiranje softvera je odvojena od faze otklanjanja grešaka (debugging) i definisano je kao odvojena faza nakon kodiranja. za razliku od TMM Nivoa 2. 4 i 5-ti nivo zrelosti kompanije u pogledu testiranja softvera (TMM). ne otkrivaju se blagovremeno. 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. Dalje. Primenjuju se osnovne tehnike i postupci. alati i adekvatno obučen kadar. a TS je profesionalni posao članova tima. Obuka kadra je 15 .PISA (Poslovno Inteligentna Simulaciona Arhitektura) Kratak opis projekta OptimalSQM predstavlja skup nаjboljih modelа i tehnikа iz prаkse.

se evidentiraju u bazi podataka o otkazima. efektivnost sada se na TMM Nivo 5 pristupa finom podešavanju i stalnom unapređenju kvaliteta TS. aktivnostima osiguranja kvaliteta softvera u cilju povećanja efikasnosti i efikasnosti otkrivanja i otkrivanja grešaka u toku razvoja softvera. Inspekcije i revizije se primenjuju planski u svim fazama SDLC kao obavezna aktivnost u TS i kontroli kvaliteta. alati za TS su u upotrebi. Uspostavljena je procedura za izbor i ocenu sredstava i alata za TS. Osnovna sredstva. alati za metriku. za koji se može reći da je TS definisan i kontrolisan. efektivnost. Nedostatak TS na ovom TMM nivou je i dalje primenjena preventivna aktivnost generisanja softverskih grešaka. “Testware”. TMM Nivo 5 Faza Optimizacije. Otkazi. efikasnost. ažuriranju baze podataka o otkazima. Proces TS je kontrolisan statističkim postupcima uzorkovanja i merenja nivoa poverenja metrika kvaliteta TS kao što su troškovi. slabo razvijena metrika kvaliteta TS kao i sredstva automatizacije TS. Ažurira se baza podataka o test-primerima sa svih projekata radi ponovne upotrebe pri regresionom (ponovljenom) testiranju. troškova. efikasnost. Iako organizacije na ovom TMM nivou znaju za značaj kontrole i obezbeđenja kvaliteta. algoritmi i odgovarajuće softverski alati za integralni i optimizirani proces testiranja i održavanja softvera. Razvoj softvera obuhvata:     Precizno planiranje(resursa. efektivnost) ocenjuje. obuke kadra i td. ova funkcija nije formalno primenjena u SDLC. odgovarajuće metode. U postizanju što boljeg kvaliteta softverskog proizvoda optimizacija se vrši uz navedena ograničenja u pogledu vremena i predviđenog budžeta. procenu i kontrolu rizika na softverskom projektu Utvrđivanje merenja kvaliteta softverskog proizvoda Kvantitativno upravljanje procesom testiranja tj. 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. efikasnost. ponovnom izvršavanju. greškama.fokusirana na oblast TS. upotrebljivost i pogodnost za održavanje. greškama i dodeljuje im se značaj (kritičnost).) Identifikaciju. Prevencije grešaka i Kontrola kvaliteta: Nakon uspešne izgradnje infrastrukture kroz sazrevanje TMM od Nivoa 1 do 4. trajanja. greške. praćenje generisanja i analizu uzroka istih kao i sredstva održavanja tzv. Program merenja kvaliteta TS kao i samog kvaliteta softvera kao proizvoda nije još uspostavljen. izvršavanju testova. 16 . preko metrika kao što su troškovi. TMM Nivo 4 Faza Merenja i Upravljanja: Proces TS se meri i kvalitet (cena. Automatska sredstva TS se koriste u svim fazama testiranja softvera dizajnu test primera. Softverski proizvod se testira radi ocene faktora kvaliteta kao što su pouzdanost.

OQT MAINT.za rešavanje kritičnih vektorskih (preko 100 promenljivih) u procesu upravljanja testiranjem. OQT MNGR komponenta se nalazi u srcu PISA-e. OQT OPST. 17 . MNGR je u srcu sistema.koja će biti prvi industriski jezik scenarija za testiranje softvera sa lako prilagodljivim unapred definisanim predložcima pravila . Takođe. 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. OQT BOX. konkretne kompanije i konkretnog projekta putm simlacije mogućih scenarija realizacije procesa testiranja u okviru planiranog budžeta. obezbeđuje integrisano i koherentno upravljanje multidisciplinarnim aspektima operacija testiranja.Slika 2. trajanja i atribta kvaliteta softvera koji se razvija. 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. MNGR sadrži SaaS-ove (Softwere as a Service) paradigme pravila . 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. Arhitektura OptimaISQM-a i Komponente softverske arhitekture OpimalSQM rešenja OptimalSQM sadrži (OQT MNGR. omogućavajući naprednu generaciju pravila testiranja.

jednostavan za korišćenje i podržan je jakom metodologijom.OQT SIM componenta simulira procese (scenarije) testiranje na osnovu uspostavljenih pravila i algoritama koji su bazirani na empirijskim rezultatima testiranja. koji onda mogu biti objavljeni putem OQT-MNGR u realnom vremenu ili kasnijem radnom okruženju. Simulacijoni tok je intuitivan. Potpuno integrisan sa svim drugim OQT-MNGR modelima. Zahvaljujući nadgledanjem planiranja. smanjenje naknadne dorade usled napravljenih grešaka u svim fazama razvoja softvera. što omogućava poređenje stvarne koristi baziranih na akumulaciji informacija u realnom svetu procesa testiranja za razne vrste softverskih proizvoda.). Svaka familija stimulacije je bogata sa pravilima koji su posebna meta poslovnih potreba. nivoa zrelosti softverskih kompanija. procesa testiranja u datoj kompaniji i sl. 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. nivoa CMM i TMM zrelosti konkretne kompanije kojoj pružamo servis. performansi razvojnog tima. procenu optimalnog scenarija za dati projekat na bazi rezultata simulacije mogućih scenarija testiranja spremljenog pre primene u realizaciji datog konkretnog softverskog projekta. kvalitet i pouzdanost. kvalifikacijom potencijalne koristi ovih pravila pre primene. kao što su smanjenje vremena testiranja. OQT-SIM takođe proverava poboljšanje kvaliteta i efikasnosti postojećih pravila postavljenih tokom vremena. OQT-SIM nudi tačno razumevanje stvarne koristi i ROI postavljenih pravila. 18 . SIM nudi simulaciju šablona koji sadrže algoritme iz različitih porodica softverskih proizvoda. OQT-SIM omogućava simulaciju pravila i postavljena pravila definisana u OQT-pravilima. napredna statistička kontrola procesa.

koje će biti spremljene za sve vrste softverskih proizvoda. „Bele kutije” i ”Sive kutije” u IT industriji. 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.OQT BOX komponenta će biti najbolja praksa i skup univerzalnih tehnika za testiranje softvera po metodi „Crne kutije”. procesnim i laboratorijskim kapacitetima. podržavajući sve nivoe i tipove testiranja softvera. Kao deo rešenja OptimalSQM-a. a prema uspostavljenim kriterijumima efikasnosti i efektivnosti za sve SDLC aktivnosti. BOX komponenta će biti potpuno nezavisna od modela procesa razvoja softvera i vrste softverskih proizvoda. 19 . izvršavaće se na zahtev OQT MNGR komponente. nivoa CMM i TMM zrelosti konkretne kompanije kojoj pružamo servis i kupljene softverske alate za testiranje.

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. adaptivno. profil greška itd. Osim toga. konačna stopa grešaka nakon 6 meseci upotrebe softvera.OQT MAINT komponenta razmišlja o svim rezultatima testiranja radi poboljšanja kontrole kvaliteta i upravljanja svim aspektima operacija testiranja u korektivnom. gustine grešaka na KSLOC ili FP metrici veličine softvera. 20 . adaptivnom i perfektivnom održavanju softvera kako u toku razvoja tako i nakon isporuke softverskog proizvoda na upotrebu. Na osnovu ovih podataka MAINT komponenta obezbeđuje kompletnu tehničku podršku nakon puštanja softverskih proizvoda u promet.za korektivno. za sve procene efikasnosti testiranja u otkrivanju i otklanjanju defekata (povećenje prinosa otkrivenih grešaka). perfektivno i preventivno održavanje na optimizovan način. MAINT komponenta vrši unakrsne procene kvaliteta svih flota testiranja. nudeći ekstremni integritet podataka. odnosno program za aktivnosti održavanje tj.

odredi adekvatne tehnike detekcije grešaka koje obezbeđuju zahtevani kvalitet tokom razvoja softverskog proizvoda u okvirima projektnih ograničenja tj. odredi aktivnosti i objekte testiranja u tačkama provere artifakata datog PTS (SDLC).OQT OPST komponenta (OPeratinonal Software Testing) treba timu za planiranje i sprovođenje testiranja konkretnog razvijanog softvera. performansi razvojnog tima. 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). zrelosti (TMM nivoa) procesa testiranja u datoj kompaniji i sl. 21 . sve parametre IOPTS. Dakle.. na osnovu sopstvene metrike ili usrednjene baze merenih karakteristika tipa softverskog proizvoda koji se razvija.

22 .

pruža dokaz koncepta za više scenarija. To rešenje predstavlja u ustvari zadatak simulacije mogućih scenarija realizuje procesa razvoja i testiranja konkretnog softverskog proizvoda date kompanije sa aspekta: zrelosti. ljudskih resursa u cilju pronalaženja optimalnog scenarija realizacije softverskog projekta. napredna statistička kontrola 23 . 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. SIM nudi simulaciju šablona koji sadrže algoritme iz različitih porodica softverskih proizvoda. uzimajući u obzir testiranje karakteristika kvaliteta softverskog proizvoda. OQT-Sim nudi tačno razumevanje stvarne koristi i ROI postavljenih pravila. kao i visok nivo pouzdanosti krajnjeg proizvoda. kao što su smanjenje vremena testiranja. Zahvaljujući nadgledanjem planiranja. Na kraju ovoga pogleda. što omogućava poređenje stvarne koristi baziranih na akumulaciji informacija u realnom svetu procesa testiranja za razne vrste softverskih proizvoda. potrebno je ponuditi rešenje koje može da precizno i lako kvalifikuje i kvantitativno utvrdi uticaj procesa testiranja softvera.Osvrt na OQT SIM komponentu Kako je testranje ključna aktivnost u procesu razvoja kvalitetnog softvera. nivoa zrelosti softverskih kompanija. 1. kvalifikacijom potencijalne koristi ovih pravila pre primene. Softverski alati. Današnje tehnike i metode nastoje da izbegnu višestruko testiranje. tehničkih kapaciteta. pravila testiranja nisu više samo pravila . pre njegovog uvođenja u proizvodnju tj. realno okruženje kod korisnika. nivoa CMM i TMM zrelosti konkretne kompanije kojoj pružamo servis. testiranje kvaliteta i pouzdanosti.to su poslovne odluke koje direktno utiču na troškove.1 Slika 3. OQT-SIM takođe proverava poboljšanje kvaliteta i efikasnosti postojećih pravila postavljenih tokom vremena.

Realizacijom servisno orijentisane arhitekture (PISA) sa integrisanim ekspertskim alatima (Profit eXpert. Svaka familija stimulacije je bogata sa pravilima koji su posebna meta poslovnih potreba. integrisanih u optimizovan i kvantitativno rukovođen proces testiranja i održavanja softvera. Potpuno integrisan sa svim drugim OQT-MNGR modelima. Risk Management eXpert. biće ponuđen kao proizvod: 1) Web portal . prvenstveno. Simulacijoni tok je intuitivan. dispozitiv i naknadna obrada. koje se sastoji od skupa softverskih servisa koji se integrišu na zahtev da bi se optimalno upravljalo procesom razvoja kvalitetnog softvera. Quality eXpert. kvalitet i pouzdanost. People Performance eXpert and Process Dynamics Control eXpert) biće ponuđeno OptimalSQM rešenje. izborom najboljih strategija i tehnika (zasnovane na simulaciji više scenarija) testiranja softvera (TS) na početku softverskog projekta. kada trenutni 24 . OQT-Sim omogućava simulaciju pravila i postavljena pravila definisana u OQT-pravilima. bolje i jeftinije od drugih rešenja) koje omogućava minimizaciju troškova i rizika. efektan i konzistentan način. jednostavan za korišćenje i podržan je jakom metodologijom.procesa.repozitorij najboljih modela i tehnika iz prakse. Malim i srednjim preduzećima koja razvijaju softver. 2) softversko okruženje za optimalan razvoj kvalitetnog softvera (brže. koji onda mogu biti objavljeni putem OQT-MNGR u realnom vremenu ili kasnijem radnom okruženju. izborom i prelaženjem na alternativne planove testiranja. OptimalSQM rešenje će biti izbalansirano i unificirano tako da nudi potpun repertoar servisa obezbeđenja i kontrole razvoja kvalitetnog softvera na efikasan. Planner eXpert. Maintenance eXpert.

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. Projektanata) • Ključna metrika i merenje kvaliteta softverskog proizvoda kao što su merenje veličine. OptimalSQM rešenje će ponuditi menadžmentu softverskog projekta čitav spektar servisa 4. posebno onih koji se bave razvojem i održavanjem softvera. Testware). na njihov zahtev. kao i mera za stalno poboljšanje PRSPTS na osnovu ekonomskih parametara (ROI. nivoa zrelosti PRS-PTS kompanije prema SEI CMM i TMM metodologiji. Predloženi projekt je u tom smislu u potpunosti usklađen sa osnovnom idejom finansiranja naučno-istraživačkog rada u Evropi. dovesti do povraćaja investicije tj. Prilagođen (datoj) kompaniji proces merenja – P3 (Proizvoda. koji će služiti kao podrška poslovanju malih i srednjih preduzeća. troškovima. Upravljanje konfiguracijom i sve izveštaje o performansama procesa TS (efiksanosti. procenu trajanja pojedinih poslova i zadataka na projektu i sl. 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.) 3. informatike i računarstva ostanu u regionu i nakon odbrane magistarskih i doktorskih disertacija. test slučajeve za svaku odabranu tehniku TS. • Ključna metrika i merenje napredovanja na projektu . Takođe. Kvantitatino će moći određivati upotrebu resursa u procesu TS koji daju najbonje rezultate). 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. Projektnih procesa. kao što su: 1. slobodni resursi (ljudi i oprema). koji treba da bude u funkciji podrške poslovanja i razvoja malih i srednjih preduzeća kao i podrške komercijalizaciji naučnih rezultata. izgraditi testno okruženje (oprema i softver tzv. na osnovu do sada obvjavljenih rezultata istraživanja u okviru projekta TR13018. potrebnim resursima. Kvantitativno upravljanje softverskim projektom (veličinom softvera.). upravljanje defektima i sl. Kvantitativna predikcija i ocenjivanje pouzdanosti softverskog proizvoda 5. izveštaje o uočenim problemima tokom TS i postignutim rezultatima u odnosu na plan TS. i 5. troškovima. OPEX i dr. Važan cilj projekta je i da se spreči odliv stručnih kadrova iz regiona. Menadžment servisi ostvarenog u odnosu na planiranu dobit softverskog projekta u toku PRS-PTS 2.izbor ne može da zadovolji ograničenja koja postavljaju zahtevi kvaliteta. strategiju i opis aktivnosti u implementaciji automatizovanog procesa TS. i • Ključna metrika i merenje performansi projektnog tima. rade na Univerzitetu u Novom Pazar. rizicima) i kvalitetu softverskog proizvoda koje menadžment zahteva. predloga izmena u dokumentima planiranog PRS-PTS tzv. ROI od 100:1. a pre svega omogući da eksperti iz oblasti matematike. BCR. 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. Procenjuje se. da će za tri godine primene predloženog softverskog okruženja sa integrisanim ekspertskim alatima. 25 . 4. kao i u centru. 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. CAPEX. prekrivenost projektnih zahteva.

kvantitativnih modela simulacije procesa detekcije i uklanjanja defekata. metoda. Takođe je prosečno 90% više potrošeno od planiranog. šablona smeštenih u bazi znanja. mogu postići značajne uštede u ovim privrednim granama (između $600 i $1. 9) izradi grafičkog korisničkog interfejsa za konkurentan. istraživanja u okviru ovog projekta će se fokusirati na dalju razradu i dogradnju PISA. USA Standish Group kompanije iz 2001. 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. rukovodiocu testiranja da omogući unapređenje PRS-PTS kroz ocenu efikasnosti i efektivnosti alternativnih planova SQA upotrebom naprednih. 7) razradi metodologije upravljanja rizikom PRS-PTS. 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. inspekcije i testiranje softvera (TS). preko 120% je duže trajao razvoj od planiranog kod završenih projekata. Osim toga. Takođe. bolji uvid u predviđanje kvaliteta izabranog dizajna. lošem kvalitetu ili njihovom kombinacijom. posebno koncept Poslovne Inteligentne Simulacione Arhitekture-PISA ulivaju poverenje u njegov uspeh. zasnovan na internet tehnologijama (Web-based GUI) radi izvođenja velikog 26 . Rules by wizards. procedurama i alatima koje obezbeđuju razvoj kvalitetnog softvera u okviru planiranog budžeta i trajanja razvoja (OptimalSQM). 5) implementaciji integrisanog procesa merenja kvaliteta softvera. broju projektanata. 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. ovaj projekat je logičan nastavak projekta TR13018. a u cilju postizanja stabilnog (predvidljivog i kontrolabilnog) procesa testiranja softvera sa najnižim rizikom.500 miliona dolara). kao aktivnosti osiguranja kvaliteta (SQA) su bitan preduslov za uspešan razvoj i implementaciju IKT. potrebnih resursa tokom PRS-PTS na sistematski i automatizovan način. ako se prouči poznati izveštaj – „Chaos Report“. 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. sa odgovarajućim softverskim komponentama koje omogućavaju dizajnerima softvera da postignu viši kvalitet dizajna. trajanja razvoja i testiranja. na bazi veoma opširnog uzorka analiziranih softverskih projekata u finansijskom sektoru i oblasti saobraćajne grane industrije. ali je upravljanje složenim procesom razvoja i testiranja (PRS-PTS) još teže bez adekvatnog softverskog okruženja sa integrisanim tehnikama.Strategijom naučnog i tehološkog razvoja predviđen je intenzivan razvoj IKT. Ova tvrdnja je evidentna. jednostavan rad većeg broja članova tima. čiji ostvareni rezultati istraživanja. 6) izradi ekonomičnog modela kvaliteta softvera i tehnika upravljanja troškovima realizacije PRS-PTS. Razvoj kvalitetnog softvera je jako složen i nepouzdan posao. Da bi se realizovalo softversko okruženje OptimalSQM. jer je Državni univerzitet u Novom Pazaru njegov nosilac. 2) automatizaciji procesa planiranja zasnovanog na modelima estimacije veličine softvera.000 pregledanih velikih projekata. 8) izradi balansirane metrike produktivnsti. na bazi 8. koji je ukazao da se izgradnjom pomenutnog adekvatnog softverskog okruženja sa infrastrukturom efikasnog i efektivnog PRS-PTS. cene. 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. po prihvatljivoj ceni i u prihvatljivom vremenu. u kome je konstatovano da 25% velikih projekata nikada nije završen usled znatnog prekoračenja u troškovima. čemu direktno doprinosi ovaj projekat. vremenu razvoja. Istraživanje rešenja PISA se sastoji u: 1) izradi kolekcije najboljih znanja — rešenja iz prakse. 4) izradi okruženja za komjutersko eksperimentisanje po principima planiranog eksperimenta (Design of Experiments) sa razrađenim pravilima preko čarobnjaka tzv. Pregledi. projekat je značajan i sa stanovišta tehnološkog razvoja regiona. 3) optimizaciji PRSPTS zasnovane na modelovanju i simulaciji kroz različite nivoe apstrakcije softvera koji testiramo. Takođe.

koji treba da identifikje observabilne i kontrolabilne promenjive konkretnog softverskog projekta. broju projektanata. broja potencijalnih grešaka u softveru. Testware). Dalo očekivane rezultate. proceni efekata. proceni i predikciji pouzdanosti softverskog rešenja tokom simulacije različitih scenarija dizajna i u toku realizacije PRS-PTS. Maintenance eXpert. 2) okruženje za simulaciju scenarija razvoja kvalitetnog softvera koje omogućava minimizaciju troškova i rizika. biće ponuđen: 1) Web portal-repozitorij najboljih modela i tehnika iz prakse. pruži neophodne podatke za simulaciju različitih scenarija PRS-PTS iz kojih se bira optimalni scenario realizacije projekta. Planner eXpert. neobhodno je: ocenjivanje i praćenje performansi projektnog tima. u osnovi. složenosti. Reliability eXpert. datog softverskog projekta. Planer eXpert treba na osnovu istraženih modela estimacije i predikcije veličine softvera. Quality eXpert. Realizacijom PISA sa integrisanim opisanim ekspertskim alatima. Quality eXpert treba da integriše specijalizovane ekspertske alate (Quality Metrics eXpert. koji treba da dovedu do donošenja odluke o završetku PRS-PTS i predaje softveskog proizvoda (IS) na upotrebu. adaptivnog. izgraditi testno okruženje (oprema i softver tzv. i 10) da omogući razmenu podataka i dokumenata sa standardnim radnim okruženjem članova tima jedne kompanije u obavljanju poslova planiranja. povećanje konkurentnosti. Kao što smo već istakli. integrisanih u optimizovan i kvantitativno rukovođen proces testiranja i održavanja softvera. izborom alternativnih planova testiranja koji zadovoljavaju ograničenja u pogledu slobodnih resursa. dinamičkim procesom razvoja i testiranja (sa preko 100 promenljivih) još teže bez adekvatnog softverskog alata Process Dynamics Control eXpert. strategiju i opis aktivnosti u implementaciji automatizovanog procesa 27 . OPEX i dr. podizanje nivoa zrelosti preduzeća na 4 i 5 nivo CMM i TMM zrelosti i zadovoljstva korisnika proizvoda i usluga. 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. cene.). perfektivnog i preventivog održavanja softvera. trajanja i cene njihove popravke tokom PRS-PTS. mere za poboljšanje PRS-PTS na osnovu ekonomskih parametara (ROI i dr. Product release eXpert) koji obezbeđuju servis menadžerima dizajna i testiranja softvera u: izradi metrike integrisanog procesa merenja kvaliteta softvera. Test Effort Estimation eXpert. BCR. 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. PISA treba.broja simulacija i deljenja rezultata obavljenih simulacija.). resursa kao što su: MS Office. prvenstveno. automatizaciji procesa planiranja zasnovanog na modelima estimacije veličine softvera. malim i srednjim preduzećima. da bude zasnovana na servisno orijentisanoj arhitekturi ( SOA) sa integrisanim ekspertskim alatima (Profit eXpert. Očekuju se. estimacije troškova. ali je upravljanje složenim. plana aktivnosti smanjenja i kontrole rizika na prihvatljivom nivou. nakon implementacije OptimalSQM rešenja u malim i srednjim preduzećima. Da bi ovako realizovano softversko okruženje za optimalan razvoj kvalitetnog softvera zaista obezbedilo uspeh na konkretnom softverskom projektu tj. trajanja razvoja i testiranja. Risk Management eXpert treba da u saradnji sa Profit eXpert sofverskim alatom pruži servis menadžerima dizajna i testiranja softvera u: identifikaciji. CAPEX. kriterijuma optimalnosti i performansi date kompanije i 3) ekonomski model kvaliteta softvera za ocenu isplativosti predloženih aktivnosti SQA. podizanje stručnog kapaciteta ljudi koji realizuju projekat korišćenjem softveskog alata People Performance eXpert. trajanja testiranja. velike uštede. People Performance eXpert and Process Dynamics Control eXpert) za sve modele PRS-PTS. Maintenance eXpert treba da obezbedi servis menadžerima dizajna i testiranja softvera u: izradi plana i proceni troškova korektivnog. MS Rroject i drugi specijalizovani softverski alati). da uspostavi kriterijume stabilnosti i optimalnosti u svakoj fazi PRS-PTS i za ceo proces. Risk Management eXpert. rasporeda poslova. trajanja razvoja. razvoj kvalitetnog softvera je jako složen i nepouzdan posao.

) 3. povećanje konkurentnosti. u odnosu na postejeću nfrastrukturu PRS-PTS softverske kompanije 1 i 2 nivoa CMM i TMM zrelosti. velike uštede. na osnovu do sada obavljenih istraživanja na projektu TR13018. 4. 28 . rizicima) i kvalitetu softverskog proizvoda koje menadžment zahteva. Projektanata) • Ključna metrika i merenje kvaliteta softverskog proizvoda kao što su merenje veličine. Upravljanje konfiguracijom i sve izveštaje o performansama procesa TS (efiksanosti. predloga izmena u dokumentima planiranog PRS-PTS tzv. • Ključna metrika i merenje napredovanja na projektu . potrebnim resursima. Predloženi projekt je u tom smislu u potpunosti usklađen sa osnovnom idejom finansiranja naučno-istraživačkog rada u Evropi. OptimalSQM rešenje će ponuditi menadžmentu softverskog projekta čitav spektar servisa 4. Takođe.ROI od 100:1. na njihov zahtev. informatike i računarstva ostanu u regionu i nakon odbrane magistarskih i doktorskih disertacija. dovesti do povraćaja investicije . a pre svega omogući da eksperti iz oblasti matematike. koji treba da bude u funkciji podrške poslovanja i razvoja malih i srednjih preduzeća kao i podrške komercijalizaciji naučnih rezultata. nakon implementacije OptimalSQM rešenja u malim i srednjim preduzećima. upravljanje defektima i sl. Projektnih procesa. 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. koji će služiti kao podrška poslovanju malih i srednjih preduzeća. test slučajeve za svaku odabranu tehniku TS. Očekuju se. troškovima. i • Ključna metrika i merenje performansi projektnog tima. rade na Univerzitetu u Novom Pazar. izveštaje o uočenim problemima tokom TS i postignutim rezultatima u odnosu na plan TS. nivoa zrelosti PRS-PTS kompanije prema SEI CMM i TMM metodologiji. posebno onih koji se bave razvojem i održavanjem softvera. kao i u centru. Prilagođen (datoj) kompaniji proces merenja – P3 (Proizvoda. Važan očekivani ključni rezultat projekta je i da se spreči odliv stručnih kadrova iz regiona. troškovima. kao što su: 1. i 5. procenu trajanja pojedinih poslova i zadataka na projektu i sl.TS. Kvantitatino će moći određivati upotrebu resursa u procesu TS koji daju najbonje rezultate). Procenjuje se. podizanje nivoa zrelosti preduzeća na 4 i 5 nivo CMM i TMM zrelosti i zadovoljstva korisnika proizvoda i usluga. da će za tri godine primene predloženog softverskog okruženja sa integrisanim ekspertskim alatima. Kvantitativno upravljanje softverskim projektom (veličinom softvera. 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. Menadžment servisi ostvarenog u odnosu na planiranu dobit softverskog projekta u toku PRS-PTS 2. prekrivenost projektnih zahteva. Kvantitativna predikcija i ocenjivanje pouzdanosti softverskog proizvoda 5.

Sign up to vote on this title
UsefulNot useful