P. 1
testiranje softvera

testiranje softvera

|Views: 426|Likes:
Published by Siniša Ševo

More info:

Published by: Siniša Ševo on Jun 08, 2012
Copyright:Attribution Non-commercial

Availability:

Read on Scribd mobile: iPhone, iPad and Android.
download as PDF, TXT or read online from Scribd
See more
See less

11/21/2014

pdf

text

original

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

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

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

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

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. Kako su do sada objašnjeni samo neki od tipova i tehnika testiranja u tabeli je dat pregledsavremenih tehnika testiranja sa opisom. konzistentnost korisnickog interfejsa. Obicno se koristi nekoliko testnih metodologija da bi se obradili razliciti aspekti softverskog proizvoda. neraspoloživi servisi i sl. prekid napajanja ili nedovoljno prostora na disku). Moderni model softverskog životnog ciklusa izbegava ovakvo gledanje na stvari i u prvi plan stavlja iterativno testiranje kroz razvoj životnog ciklusa. Tehnike se kombinuju i variraju. 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).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. Tehnika Acceptance testing – Testiranje prihvatljivosti Kratak opis Finalno testiranje bazirano na specifikacijma krajnjeg korisnika/potrošača.etalonski test .uporedenje performansi novog sistema sa nekim. korisnicka dokumentacija. . poznatim sistemom..testiranje upotrebljivosti(usability testing) – estetski aspekti. .pregled tehnika testiranja Testiranje se posmatra kao posebna faza životnog ciklusa proizvoda koja prati kodiranje. . Slično istraživačkom testiranju. referentnim. .testiranje integriteta(integrity testing) – robusnost(otpornost na otkaze). nedovoljno memorije ili drugih resursa..)..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. . ili bazirano na korišćenju krajnjih korisnika/potrošača u odre₃enom vremenskom periodu. . ali se često odnosi na to da testeri dobro razumeju softver pre samog testiranja. Ad hoc testing – Ad hoc testiranje 6 . Najcešce se mere protok i vreme odziva (srednja i granicna vrednost). konzistentna upotreba resursa i sl.

Obično ga izvršavaju krajnji korisnici ili drugi. Testovi se generišu na osnovu funkcionalnosti sistema.Alpha testing – Alfa testiranje Testiranje kada je razvoj pri kraju. manje promene u dizajnu moguće su kao rezultat ovog testiranja. Verifikacija da svaka grana ima true ili false izlaze. Identifikovanje testova na bazi tokova i putanja programa ili sistema. Testovi se generišu iz graničnih vrednosti odgovarajućih klasa. Integrisanje modula ili programa počevši od dna. Označavanje višestrukih simultanih ulaza koji mogu uticati na uslove testa. Testiranje koliko dobro softver radi u odre₃enom hardversko/softverskom/OS/mrežnom okruženju. ne programeri ili testeri. 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. Upore₃ivanje slabosti i dobrih strana softvera sa konkurentskim proizvodima. a ne programeri i testeri. Potvrda da svaki uslov obuhvata sve moguće izlaze. Obavljaju ga krajnji korisnici ili drugi. 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 . Verifikacija da svaki uslov obuhvata sve moguće izlaze .

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

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. Tehnika koja spaja korisnike i developere pri dizajnu sistema. Matematička tehnika odre₃ivanja koje varijacije parametara treba da se testiraju. Delovi mogu biti kodni moduli. Testiranje pozitivnih i negativnih vrednosti svih ulaza. Metod odre₃ivanja da li je skup testnih podataka ili testova koristan. individualne aplikacije ili klijent/server aplikacije na mreži. Izvršavaju ga testeri ili programeri. Ovaj tip testiranja je jako važan za klijent/server i distribuirane sisteme. Testiranje kombinovanih delova sistema radi utvr₃ivanja da li zajedno dobro funkcionišu. pre kompletiranja svih delova programa. Zahteva velike resurse. 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 . Definisano je u zahtevima ili test planovima. Formalni pregled koji koristi čekliste. zahteva da različiti aspekti funkcionalnosti aplikacije budu dovoljno nezavisni da rade zasebno. Analiza paterna defekata radi identifikacije uzroka i posledica. ulazne i izlazne kriterijume. Testiranje aplikacije pod opterećenjem. Koristi se često sa stres i load testovima.Inkrementalno integraciono testiranje doda nova funkcionalnost.

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

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

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

U ovim testovima se ne vrši analiza izvornog koda.● ● ● ● Garantuju da sve nezavisne staze u modulu budu istestirane barem jednom. Skoro 30% svih grešaka u kodu posledica su problema nepotpunih ili neodređenih specifikacija. funckionalnost. 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. Sinonimi za black box uključuju: ponašanje. 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 . Problem funkcionalnog testiranja može da se pojavi u slučaju dvosmislenih zahteva i nemogućnosti opisivanja svih načina korišćenja softvera. 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. Tačnost izlaznih podataka proverava se na osnovu specifikacije zahteva za softver.

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

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

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

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

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

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

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

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

22 .

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

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

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

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

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

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

You're Reading a Free Preview

Download
scribd
/*********** DO NOT ALTER ANYTHING BELOW THIS LINE ! ************/ var s_code=s.t();if(s_code)document.write(s_code)//-->