Testiranje softvera
Uvod
Testiranje Testiranje je aktivnost koja se izvodi identifikaci identifikacijom jom defekata defekata i problema problema radi procene kvaliteta proizvoda, kao i za njegovo unapređenje. Testiranje soft softve vera ra se sast sastoj ojii iz dinamičke verifi verifikaci kacije je ponašan ponašanja ja progra programa ma na skupu u test testir iran anja ja,, pogo pogodn dno o selektovanog iz uglav glavno nom m konačnom skup beskonačnih područja izvršavanja, u odnosu na očekivano ponašanje. U gore gore nave navede deno nojj defi defini nici ciji ji,, reči reči napi napisa sane ne ukos ukoso o odgo odgova vara raju ju klju ključn čnim im prob roblem lemima ima iden dentifi tifika kaci cije je obla oblast stii zna znanja nja soft softve vers rsko kog g test testir iraanja nja. Pojedinačno: Dinamičko: Ovaj termin znači da testiranje uvek podrazumeva izvršavanje
programa na (validnim) ulazima. Preciznije, sama vrednost ulaza nije uvek dovoljna za određivanje testa, jer kompleksan, nedeterministički sistem može da reaguje na isti ulaz različitim ponašanjem, u zavisnosti od stanja sist sistem ema. a. U ovoj ovoj obla oblast stii znan znanja ja,, ipak ipak,, održ održać aćee se term termin in „ula „ulaz“ z“,, uz podrazumevanje da njegovo značenje uključuje i posebno stanje ulaza, u onim slučajevima u kojima je potrebno. Različite od testiranja i njemu komplementarne su statističke tehnike. Konačno: Čak i u jednostavnijim programima, veliki broj skupova testiranja
je moguć moguć pa bi se iscrpni testovi testovi izvršavali izvršavali mesecima mesecima ili godinama godinama do zavr završe šetk tkaa. Zbo Zbog toga toga se gener eneral alno no čita čitavv sku skup za test estira iranje nje može ože posmatrati kao konačan. Testiranje uvek podrazumeva kompromis između ogra ograni niče čeni nih h resu resurs rsaa i vrem vremen ensk skog og rasp raspor ored edaa u odno odnosu su na sušt suštin insk skii neograničene zahteve testa. Razlikuje je se veliki veliki broj broj ponuđe ponuđenih nih tehnik tehnikaa testira testiranja nja,, pre Selektovano: Razliku svega u tome kako se vrši selekcija skupa za testiranje. Softverski inženjeri mora moraju ju biti biti svesni svesni da razli različit čitii krit kriteri eriju jumi mi sele selekci kcije je mogu mogu da proi proizv zved edu u veoma različite stepene efikasnosi. Kako izabrati najpogodniji kriterijum selekcije u odnosu na date uslove predstavlja veoma kompleksan problem; u praks raksi, i, moraj oraju u se prime rimeni niti ti tehn tehnik ikee anal analiz izee rizi rizika ka ka kao o i stru stručn čnos ostt inženjera. iti moguć oguće, e, iako iako nije nije uvek uvek lako lako,, odlu odluči čiti ti da li su Očekivano: Mora biti posm posmat atra rani ni isho ishodi di izvr izvršen šenog og prog progra rama ma prih prihva vatlj tljivi ivi ili ne, ne, u supr suprot otno nom m testira testiranje nje bi bilo beskori beskorisno sno.. Posma Posmatra trano no ponaša ponašanje nje se može može ispitat ispitatii u odnosu na očekivanja korisnika (što se obično naziva testiranje validacije), 1
u odnosi na specifikaciju (testiranje verifikacije), ili, na kraju, u odnosu na očekivano ponašanje iz implicitnih zahteva ili razumnih očekivanja. Pogled testiranja testiranja softvera softvera evoluirao evoluirao je ka više konstruktiv konstruktivnom nom.. Testiranje Testiranje se više ne vidi kao aktivnost koja počinje samo kada je završena faza kodi kodira ranj nja, a, sa ogra ograni niče čeno nom m svrh svrhom om otkr otkriv ivan anja ja greš grešak aka. a. Sada Sada se na testiranje softvera gleda kao na aktivnost koja bi trebalo da prati čitav proces razvoja i održavanja, i kao takva je zanačajan deo konstrukcije proizvoda. Zaista, planiranje testiranja bi trebalo početi u ranim fazama procesa ispitivanja, planovi testiranja i procedure moraju se sistematski i u kontin kontinuit uitetu etu razvija razvijati, ti, i prerađi prerađivat vati, i, kako kako razvoj razvoj odmiče. odmiče. Ove Ove akt aktivn ivnosti osti planir planiranj anjaa i dizajn dizajnira iranja nja same same predsta predstavlja vljaju ju koristan koristan ulaz ulaz za dizajn dizajnere ere isti istica canj njem em pote potenc ncij ijal alni nih h slab slabos osti ti (kao (kao što što su propu ropust stii u diza dizajn jnu u ili ili kontradiktornosti, kao i propusti i dvosmislenosti u dokumentaciji). Sada se smatra da je pravi stav ka kvalitetu jedna od prevencija: Očigledno je mnogo bolje izbeći izbeći probleme nego ih ispravljati ispravljati.. Tada se testiranje mora videti kao primarno sredstvo za proveru ne samo efektivnosti prevencije, već i za identifikovanje grešaka u onim slučajevima gde, iz nekog razloga, nije bilo efektivno. Možda je očigledno, ali vredno napomene, da čak i posle uspe uspešno šnog g zavr završet šetka ka obim obimno nog g testi testira ranj nja, a, softv softver er i dalje dalje može može sadr sadrža žati ti greš greške ke.. Lek Lek za soft softve vers rske ke greš greške ke nako nakon n ispo isporu ruke ke je obez obezbe beđi điva vanj njee korektivnih akcija održavanja. U soft softve vers rsko kom m kv kval alit itet etu u (Softw Software are Qualit Quality y Manag Managem emen entt Techni Technique ques s), tehnik tehnikee uprav upravljan ljanja ja softve softverski rskim m kvalite kvalitetom tom kat katego egorisa risane ne su u statičk statičkee tehnike (bez izvršavanja koda) i dinamičke tehnike (izvršavanje koda). Obe kategorije su korisne. Ova oblast znanja se fokusira na dinamičke tehnike. Test Testir iraanje nje soft softve vera ra je pove poveza zano no i sa soft softve vers rsko kom m kons konsttrukc rukcij ijom om (Construction Testing). Testiranje jedinice i integracije u bliskoj su vezi sa konstrukcijom softvera, ili čak deo njega.
Podela tema
Podela tema za oblast znanja testiranja softvera je prikazana na Figuri 1. Prva podoblast opisuje Osnove Osnove softversk softverskog og testiranj testiranja a (Softwar (Software e Testing Testing Fundamentals). Ona pokriva osnovne definicije u oblasti testiranja softvera, osno osnovn vnu u term termin inolo ologij giju u i klju ključna čna pitan pitanja ja,, ka kao o i njenu njenu vezu vezu sa drugim drugim aktivnostima. Druga podoblast, Nivoi testiranja (Test Levels) , sačinjena je iz dve (ortogonalne) teme: 2.1 prikazuje nivoe u kojima je testiranje velikih softver softveraa tradici tradiciona onalno lno podelje podeljeno; no; i 2.2 razma razmatra tra testira testiranje nje za poseb posebne ne 2
u odnosi na specifikaciju (testiranje verifikacije), ili, na kraju, u odnosu na očekivano ponašanje iz implicitnih zahteva ili razumnih očekivanja. Pogled testiranja testiranja softvera softvera evoluirao evoluirao je ka više konstruktiv konstruktivnom nom.. Testiranje Testiranje se više ne vidi kao aktivnost koja počinje samo kada je završena faza kodi kodira ranj nja, a, sa ogra ograni niče čeno nom m svrh svrhom om otkr otkriv ivan anja ja greš grešak aka. a. Sada Sada se na testiranje softvera gleda kao na aktivnost koja bi trebalo da prati čitav proces razvoja i održavanja, i kao takva je zanačajan deo konstrukcije proizvoda. Zaista, planiranje testiranja bi trebalo početi u ranim fazama procesa ispitivanja, planovi testiranja i procedure moraju se sistematski i u kontin kontinuit uitetu etu razvija razvijati, ti, i prerađi prerađivat vati, i, kako kako razvoj razvoj odmiče. odmiče. Ove Ove akt aktivn ivnosti osti planir planiranj anjaa i dizajn dizajnira iranja nja same same predsta predstavlja vljaju ju koristan koristan ulaz ulaz za dizajn dizajnere ere isti istica canj njem em pote potenc ncij ijal alni nih h slab slabos osti ti (kao (kao što što su propu ropust stii u diza dizajn jnu u ili ili kontradiktornosti, kao i propusti i dvosmislenosti u dokumentaciji). Sada se smatra da je pravi stav ka kvalitetu jedna od prevencija: Očigledno je mnogo bolje izbeći izbeći probleme nego ih ispravljati ispravljati.. Tada se testiranje mora videti kao primarno sredstvo za proveru ne samo efektivnosti prevencije, već i za identifikovanje grešaka u onim slučajevima gde, iz nekog razloga, nije bilo efektivno. Možda je očigledno, ali vredno napomene, da čak i posle uspe uspešno šnog g zavr završet šetka ka obim obimno nog g testi testira ranj nja, a, softv softver er i dalje dalje može može sadr sadrža žati ti greš greške ke.. Lek Lek za soft softve vers rske ke greš greške ke nako nakon n ispo isporu ruke ke je obez obezbe beđi điva vanj njee korektivnih akcija održavanja. U soft softve vers rsko kom m kv kval alit itet etu u (Softw Software are Qualit Quality y Manag Managem emen entt Techni Technique ques s), tehnik tehnikee uprav upravljan ljanja ja softve softverski rskim m kvalite kvalitetom tom kat katego egorisa risane ne su u statičk statičkee tehnike (bez izvršavanja koda) i dinamičke tehnike (izvršavanje koda). Obe kategorije su korisne. Ova oblast znanja se fokusira na dinamičke tehnike. Test Testir iraanje nje soft softve vera ra je pove poveza zano no i sa soft softve vers rsko kom m kons konsttrukc rukcij ijom om (Construction Testing). Testiranje jedinice i integracije u bliskoj su vezi sa konstrukcijom softvera, ili čak deo njega.
Podela tema
Podela tema za oblast znanja testiranja softvera je prikazana na Figuri 1. Prva podoblast opisuje Osnove Osnove softversk softverskog og testiranj testiranja a (Softwar (Software e Testing Testing Fundamentals). Ona pokriva osnovne definicije u oblasti testiranja softvera, osno osnovn vnu u term termin inolo ologij giju u i klju ključna čna pitan pitanja ja,, ka kao o i njenu njenu vezu vezu sa drugim drugim aktivnostima. Druga podoblast, Nivoi testiranja (Test Levels) , sačinjena je iz dve (ortogonalne) teme: 2.1 prikazuje nivoe u kojima je testiranje velikih softver softveraa tradici tradiciona onalno lno podelje podeljeno; no; i 2.2 razma razmatra tra testira testiranje nje za poseb posebne ne 2
uslove osobina i naziva se ciljevi testiranja ( objectives of testing). Ne mogu se svi tipovi testiranja primeniti na svaki softverski proizvod, niti je svaki mogući tip naveden. Cilj testiranja i objekat testiranja zajedno utvrđuju kako se identifikuje skup testiranja, obazirući se na konzistenciju – koliko testiranja je dovoljno za postizanje željenog cilja – i svoju kompoziciju – koje slučaje slučajeve ve testa testa bi trebalo trebalo selekto selektovat vatii za postiz postizanj anjee željeno željenog g cilja. cilja. Kriterijumi za prvo pitanje se nazivaju kriterijumi adekvatnosti testa, dok se oni koji se odnose na drugo pitanje nazivaju kriterijumi selekcije testa. Više tehnika za testiranje (test techniques) je razvijeno proteklih nekoliko decenija, i dalje se predlažu nove. Opšte prihvaćene tehnike su pokrivene u podoblasti 3. Mere u vezi sa testom (Test-related Measures Measures) su razmotrene u podo podobl blas asti ti 4. Na kraj kraju, u, probl roblem emii sa proce roceso som m test testaa (Test Test Process Process) pokriveni su u podoblasti 5.
Slika 1- Podela tema za oblast znanja testiranja softvera
1. Osnove testiranja softvera (Software Testing Fundamentals) 3
1.1.
Terminologij Termino logijaa vezana za testiranje testir anje (Testing-related terminology )
1.1.1.
Definicije testiranja i povezana terminologija1
Sveo Sveobu buhv hvat atan an uvod uvod u obla oblast st znan znanja ja soft softve versk rskog og test testira iranja nja data data je u preporučenim referencama. 1.1.2.
Greške nasuprot neuspehu
Mnog Mnogo o term termina ina u liter literat atur urii softv softver ersko skog g inže inženje njerin ringa ga se koris koristi ti da bi se opisala greška u radu, kao što su termini defekt ( fault ), ), otkaz (failure), grešk greškaa (error ) i drug drugi. i. Ova Ova term termin inol olog ogij ijaa se prec preciz izno no defi defini niše še u IEEE IEEE Standardu Standardu 610.12-199 610.12-1990, 0, standardno standardnom m rečniku terminologije terminologije softverskog softverskog inžen inženjer jerin inga ga (IEEE (IEEE61 6100-90 90), ), i tako takođe đe je razm razmat atra rana na u obla oblasti sti znan znanja ja softv softver ersko skog g kv kvali alite teta ta.. Bitn Bitno o je napr naprav avit itii jasn jasnu u razl razliku iku izme između đu uzro uzroka ka greške, za koji će se ovde koristiti termin nedostatak ili defekat (defect ), ), i neželjenog efekta posmatranog u sistemu isporuke, koji će se nazivati otkaz. Testiranje može otkriti otkaze, ali defekti su ti koji se mogu i moraju ukloniti. Ipak, trebalo bi prihvatiti da uzrok otkaza ne može uvek biti nedvosmisleno utvrđen. Ne postoje teoretski kriterijumi kojima bi se definitivno odredilo koji je nedostatak izazvao posmatrani neuspeh. Može se reći da je to defekt koji se mora modifikovati kako bi se uklonio problem, ali druge modifikacije bi isto tako mogle da rade. Kako bi se izbegla dvosmislenost, neki autori pref prefer erira iraju ju da govo govore re o ulazim ulazimaa koji koji izaz izaziv ivaj aju u otka otkaze ze (failure-causing inputs), a ne o manama – odnosno o onom skupu ulaza koji utiče na pojavu otkaza.
1.2.
Ključna Ključ na pitanja pita nja (Key issues) issue s) 2
1
B. Beizer, Software Testing Techniques, Techniques, (International Thomson Press, 1990), Chaps. 1. P. C. Jorgensen, Software Testing: A Craftsman's Approach, Approach, (second edition, CRC Press, 2004), Chap. 2. M.R. Lyu, Handbook of Software Reliability Engineering , (Mc-Graw-Hill/IEEE, 1996), Chap. 2. W. Perry, Effective Perry, Effective Methods for Software Testing , (John Wiley & Sons, 1995), Chap. 1. S. L. Pfleeger, Software Engineering: Theory and Practice, Practice, (second ed., Prentice Hall, 2001), Chap. 8. 2
B. Beizer, Software Testing Techniques, Techniques, (International Thomson Press, 1990), Chaps. 3, 13.
4
1.2.1.
Kriterijum selekcije testa/Kriterijum adekvatnosti testa (ili pravila zaustavljanja)
Kriterijum selekcije testa (Test selection criterion) je sredstvo za odlučivanje koji je prikladan skup testova. Kriterijum selekcije se može koristiti za izbor test slučajeva ili za proveru da li je odabran paket testa adekvatan – odnosno, za odlučivanje da li se testiranje može zaustaviti. 1.2.2.
Efektivnost testiranja (Testing effectiveness) /Ciljevi testiranja
Testiranje je opservacija uzorka programskih izvršavanja. Selekcija uzorka može biti vođena različitim ciljevima: da li se efektivnost testa može proceniti zavisi od cilja koji se sledi. 1.2.3.
Testiranje radi identifikacije identification)
defekata (Testing
for
defect
U testiranju radi identifikacije defekta, uspešan test je onaj koji izaziva neuspešan rad sistema. Ovo je različito u odnosu na testiranje radi demonstracije da softver ispunjava specifikacije ili druge željene karakteristike, u čijem slučaju je testiranje uspešno ukoliko se ne zabeleže (značajni) neuspesi. 1.2.4.
Problem predskazivanja (The oracle problem)
Predskazivač je bilo koji (ljudski ili mehanički) izvršilac koji odlučuje da li se program ponašao u skladu sa testom, i prema tome stvara presudu o „prolasku“ ili „neuspehu“. Postoji veliki broj različitih vrsta predskazivača, i automatizacija može biti jako teška i skupa. 1.2.5.
Teoretska i praktična ograničenja testiranja
Teoretsko testiranje nas upozorava na nejednak nivo poverenja serija testova. Na žalost, većina utvrđenih rezultata teoretskog testiranja su negativni, u kojima se opisuje šta testovi ne mogu da postignu nasuprot onome što je zaista postignuto. Najpoznatiji citat u vezi sa tim je Dijkstra aforizam „Testiranje programa može biti upotrebljeno da pokaže prisustvo bagova, ali nikada da pokaže njihovo nepostojanje". Zbog toga, testiranje S. L. Pfleeger, Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001), Chap. 8. P.A.V. Hall and J.H.R. May, Software Unit Test Coverage and Adequacy,( ACM Computing Surveys, vol. 29, 1997), Section 1. Perry, Effective Methods for Software Testing , (John Wiley & Sons, 1995), Chap. 21. J. Falk, and H.Q. Nguyen, Testing Computer Software, (second ed., John Wiley & Sons, 1999), Chaps. 1-2.
5
H. Zhu, W. C. Kaner,
mora biti sprovedeno zasnovano na rizicima i može biti posmatrano kao strategija menadžmenta rizika. 1.2.6.
Problem nedostižnih putanja (Theoretical and practical limitations of testing)
Neizvršive putanje, putanje kontrolnog toka koje ne mogu biti proverene bilo kojim ulaznim podacima, su veliki problem u testiranju orijentisanom na putanjama, i posebno u automatskom izvođenju ulaza testa za tehnike testiranja bazirane na kodu. 1.2.7.
Mogućnost testiranja (Testability )
Termin „software testability“ ima dva vezana, ali različita značenja: u jednom slučaju, odnosi se na stepen do kojeg je softveru lako da ispuni dati kriterijum pokrivenosti testa kao u (Bac90), u drugom slučaju, definisan je kao mogućnost i verovatnoća merena statistički, da će softver otkriti otkaze pod testiranjem, ukoliko su zaista defekti, kao u (Voa95, Ber96a). Oba značenja su važna. 1.3.
Veze testiranja sa drugim aktivnostima (Relationships of testing to other activities)
Testiranje softvera je povezano, ali ujedno i različito od statičnih tehnika menadžmenta softverskog kvaliteta ( software quality management techniques), dokaza korektnosti ( proofs of correctness), debugging-a i samog programiranja. Ipak, informativno je razmatrati testiranje sa tačke gledišta analize kvaliteta softvera i sertifikata.
2. Nivoi testiranja (Test levels)3 2.1.
Cilj testa (The target of the test)
3
B. Beizer, Software Testing Techniques, (International Thomson Press, 1990), Chap. 1. Effective Methods for Software Testing , (John Wiley & Sons, 1995), Chap. 8-10, 17. Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001), Chaps. 8-9 .
W. Perry, S. L. Pfleeger,
C. Jorgensen, Software Testing: A Craftsman's Approach, (second edition, CRC Press, 2004), Chaps. 13-15. C. Kaner, J. Falk, and H.Q. Nguyen, Testing Computer Software, (second ed., John Wiley & Sons, 1999), Chap. 7. K. Beck, Test-Driven Development by Example, (Addison-Wesley, 2002). M.R. Lyu, Handbook of Software Reliability Engineering , (Mc-Graw-Hill/IEEE, 1996), Chap. 7.
6
Testiranje softvera se obično izvršava na različitim nivoima tokom razvoja i održavanja procesa. Odnosno, cilj testiranja može da varira: jedan modul, grupa takvih modula (povezanih svrhom, upotrebom, ponašanjem ili strukturom), ili čitav sistem. Mogu se razlikovati tri velike faze testa, nazvane Jedinica (Unit ), Integracija (Integration) i Sistem (System). Ne podrazumeva se nijedan model procesa, niti se pretpostavlja da bilo koja od ove tri faze ima veći značaj od preostale dve. 2.1.1.
Testiranje jedinice (Unit testing)
Testiranje jedinice verifikuje funkcionisanje delova softvera u izolaciji koji se posebno mogu testirati. U zavisnosti od konteksta, to mogu biti individualni podprogrami ili veće komponente napravljene od usko vezanih jedinica. Test jedinica je preciznije definisana u IEEE Standard for Software Unit Testing (IEEE1008-87), koji takođe opisuje integrisani pristup sistematskog i dokumentovanog testiranja jedinice. Obično, testiranje jedinice nastaje sa pristupom kodu koji se testira i uz pomoć debugging alata, i može da uključuje programere koji su napisali kod. 2.1.2.
Testiranje integracije (Integration tetsing)
Testiranje integracije je proces verifikacije interakcije između komponenti softvera. Klasične strategije testiranja integracije, kao što su top-down ili bottom-up (odozgo na dole, i odozdo na gore), koriste se sa tradicionalnim sotverom sa hijerarhijskom strukturom. Moderne sistematske strategije integracije pre su vođene arhitekturom, što navodi na integraciju komponenti softvera ili podsistema baziranih na identifikovanim funkcionalnim temama. Testiranje integracije je kontinualna aktivnost, na svakoj fazi softverski inženjeri moraju izdvojiti perspektive nižih nivoa i koncentrisati se na perspektive nivoa koji integrišu. Osim za male, jednostavne softvere, sistematske, inkrementalne integracione strategije testiranja se obično preferiraju stavljanjem svih komponenti zajedno, što se slikovito zove „big bang“ testiranje. 2.1.3.
Testiranje sistema (System testing)
Testiranje sistema se razmatra uz ponašanje čitavog sistema. Većina funkcionalnih grešaka već bi trebalo da su identifikovane tokom testiranja jedinice i integracije. Testiranje sistema se obično smatra prikladnim za poređenje sistema i ne-funkcionalnih sistemskih zahteva, kao što su bezbednost, brzina, tačnost, i pouzdanost. Eksterni interfejsi prema drugim aplikacijama, uslužnim programima, hardverskim uređajima ili operativnom okruženju, takođe su procenjeni na ovom nivou. 7
2.2.
Ciljevi testiranja (Objectives of Testing)
Testiranje se izvršava pri određenim ciljevima, koji su manje ili više eksplicitno izraženi, i sa varirajućim stepenima preciznosti. Postavljanje ciljeva precizno, kvantitativnim terminima, omogućava da kontrola bude ustanovljena tokom procesa testiranja. Testiranje može biti namenjeno za verifikaciju različitih osobina. Slučajevi testa se mogu osmisliti kako bi proverili da li su funkcionalne specifikacije tačno implementirane, što se u raznim slučajevima u literaturi naziva testiranje usaglašenosti (conformance testing), korektnosti (correctness), ili funkcionalno (functional ) testiranje. Ipak, nekoliko drugih nefunkcionalnih osobina se
mogu testirati, uključujući performanse, pouzdanost, i korisnost, pored ostalih. Drugi značajni ciljevi za testiranje uključuju (ali nisu ograničeni na) merenje pouzdanosti, procenu korisnosti i prihvatanja, za koje bi trebalo primeniti različite pristupe. Može se zapaziti da objekat testa varira sa ciljem testa; uopšteno, različite svrhe se ispunjavaju različitim nivoom testiranja. Neke vrste testiranja su prikladnije za softverske pakete pravljene po meri, testiranje instalacija (installation), na primer; i druge generičke proizvode, kao beta (beta) testiranje. 2.2.1.
Testiranje prihvatanja/kvalifikacije ( Acceptance/qualification testing)
Testiranje prihvatanja proverava ponašanje sistema u osnosu na zahteve kupaca, bez obzira na to kako su izraženi; kupci preduzimaju ili određuju tipične zadatke kako bi proverili da su njihovi zahtevi zadovoljeni ili da je organizacija identifikovala njih za ciljno tržište softvera. Ova aktivnost testiranja može ali ne mora uključivati one koji razvijaju sistem.
2.2.2.
Testiranje instalacije (Installation testing)
Nakon kompletiranja testiranja softvera i prihvatljivosti softver se može verifikovati u odnosu na instalaciju u ciljnoj sredini. Testiranje instalacije može se posmatrati kao sistemsko testiranje izvođeno još jednom prema zahtevima hardverske konfiguracije. Procedure instalacije mogu, takođe, biti verifikovane. 2.2.3.
Alfa i beta testiranje ( Alpha and beta testing) 8
Pre izbacivanja softvera, ponekad se daje malom, reprezentativnom skupu potencijalnih korisnika na probu, ili unutar (alfa testiranje) ili eksterno (beta testiranje). Ovi korisnici izveštavaju o problemima sa proizvodom. Alfa i beta upotreba su često nekorelisane i često se na njih ne upućuje u planu testa. Testiranje usaglašenosti/Funkcionalno testiranje/Testiranje tačnosti (Conformance testing/Functional testing/Correctness testing ) 2.2.4.
Testiranje usaglašenosti usmereno je na validaciju bez obzira da li posmatrano ponašanje testiranog softvera odgovara svojim specifikacijama. 2.2.5.
Postizanje pouzdanosti i procena (Reliability achievement and evaluation)
Kako bi se pomogla identifikacija grešaka, testiranje bi trebalo da poboljša pouzdanost. Nasuprot tome, statističke mere pouzdanosti se mogu izvesti slučajnim generisanjem slučajeva testa prema operativnom profilu. Korišćenjem modela rasta, oba cilja se mogu zajedno sprovesti. 2.2.6.
Regresiono testiranje (Regression testing)
Prema (IEEE610.12-90), regresiono testiranje je „selektivno retestiranje sistema ili komponenti kako bi se verifikovalo da modifikacije nisu proizvele neželjene efekte...“ U praksi, ideja je da se pokaže da softver koji je prethodno prošao testove i dalje to može. Beizer to definiše kao bilo koje ponavljanje testova sa namerom da se pokaže da je ponašanje softvera nepromenjeno, osim ukoliko se to ne zahteva. Očigledno je da se mora izvršiti kompromis između osiguranja datog regresionim testiranjem svakog puta kada se izvrši promena i resursa potrebnih za to.
2.2.7.
Testiranje performansi (Performance testing)
Posebno je namenjeno verifikaciji da softver zadovoljava posebne zahteve performansi, na primer, kapaciteta i vremena odgovora. Posebna vrsta testiranja performansi je testiranje diska (volume testing), u kome se ispituju interni programi ili limiti sistema. 2.2.8.
Testiranje stresa (Stress testing)
Stres testiranje vežba softver na maksimumu opterećenja, kao i preko toga. 9
2.2.9. Back-to-back testiranje
Jedan test se izvršava na dve implementirane verzije softverskog proizvoda i rezultati se porede. 2.2.10.
Testiranje oporavka (Recovery testing)
Testiranje oporavka namenjeno je verifikaciji sposobnosti restartovanja softvera nakon „sloma“.
2.2.11.
Testiranje konfiguracije (Configuration testing)
U slučajevima kada je softver izgrađen kako bi služio različitim korisnicima, testiranje konfiguracije analizira softver pod različito određenim konfiguracijama. 2.2.12.
Testiranje upotrebljivosti (Usability testing)
Ovaj proces procenjuje koliko je lako krajnjim korisnicima da nauče da rade sa softverom, uključujući dokumentaciju; koliko efektivno funkcije softvera podržavaju zadatke korisnika; i, na kraju, sposobnost oporavka nakon grešaka korisnika. 2.2.13.
Razvoj vođen testom (Test-driven development )
Ovaj razvoj nije na prvi pogled tehnika, zalažući se za upotrebu testova kao surogata dokumentomovane specifikacije potreba pre nezavisne provere da softver ima pravilno implementirane zahteve.
3. Tehnike testa (Test techniques)
Jedan od ciljeva testiranja je otkrivanje koliki je potencijal grešaka moguć, i mnoge tehnike su razvijene na osnovu ovoga, tehnike koje pokušavaju da „slome“ program, izvršavanjem jednog ili više testova izvedenog iz identifikovanih klasa ekvivalenta egzekucija. Vodeći princip ovih tehnika je da budu što sistematičnije u identifikaciji reprezentativnog skupa programskog ponašanja; na primer, posmatranje podklasa oblasti ulaza, scenario, stanja i toka podataka. Teško je naći homogenu bazu za klasifikaciju svih tehnika, i ona koja je ovde data mora se smatrati za kompromisnu. Klasifikacija je bazirana na tome kako su testovi generisani iz intuicije i iskustva softverskih inženjera, kao i specifikacije, strukture koda, (realne ili veštačke) greške koje bi trebalo naći, prirode aplikacije. 10
Ponekad su ove tehnike klasifikovane kao bele-kutije (white-box , ili glassbox), ako se test oslanja na informacije kako je softver dizajniran ili kakvi su kodovi, ili crne-kutije ( black-box) ukoliko se slučajevi testiranja oslanjaju samo na ulaz/izlaz ponašanje. Poslednja kategorija odnosi se na kombinovanu upotrebu dve ili više tehnika. Očigledno, ove tehnike se ne koriste podjednako često. Uključene su u listu one koje bi inženjer trebalo da zna. 3.1 Bazirane na intuiciji i iskustvu softverskih inženjera4
3.1.1 Ad hoc testiranje Verovatno najrasprostranjenija tehnika ostaje ad hoc testiranje: testovi se izvode oslanjajući se na inženjersko umeće, intuiciju, i iskustvo sa sličnim programima. Ad hoc testiranje može biti korisno za identifikaciju specijalnih testova, onih koje nije lako zabeležiti formalizovanim tehnikama. 3.1.2 Istraživačko testiranje (Explorarity testing) Ovo testiranje je definisano kao simultano učenje, dizajn testa i izvršavanje testa; odnosno, testovi nisu određeni unapred u okviru utvrđenog plana testa, već su dinamički dizajnirani, izvršeni i modifikovani. Efektivnost ovih testova oslanja se na znanje inženjera, koje se može izvesti iz mnogo izvora: posmatranog ponašanja proizvoda tokom testiranja, upoznatosti sa aplikacijom, platformom, procesom neuspeha, tipom mogućih grešaka i mana, rizika povezanog sa posebnim proizvodom i slično. 3.2 Tehnike bazirane na specifikaciji
3.2.1 Ekvivalentno deljenje (Equivalence partitioning) Domen ulaza je podeljen na kolekciju podskupova, ili ekvivalentnih klasa, koje se smatraju ekvivalentima prema određenim relacijama, i reprezentativan skup testova (ponekad samo jedan) je uzet iz svake klase. 4
C. Kaner, J. Falk, and H.Q. Nguyen, Testing Computer Software, (second ed., John Wiley & Sons, 1999), Chaps. 1, 7.
P. C. Jorgensen, Software Testing: A Craftsman's Approach, (second edition, CRC Press, 2004), Chaps. 2, 5-7, 9-10, 12, 15. B. Beizer, Software Testing Techniques, (International Thomson Press, 1990), Chaps. 1, 3, 5, 10-11, 13. L. Pfleeger, Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001), Chap. 9. H. Zhu, P.A.V. Hall and J.H.R. May, Software Unit Test Coverage and Adequacy,( ACM Computing Surveys, vol. 29, 1997). W. Perry, Effective Methods for Software Testing , (John Wiley & Sons, 1995), Chaps. 8, 17. M.R. Lyu, Handbook of Software Reliability Engineering , (Mc-Graw-Hill/IEEE, 1996), Chap. 5-6.
11
S.
3.2.2 Analize vrednosti granica (Boundary-value analysis) Slučajevi testa izabrani su na ili blizu granica oblasti ulaza promenljivih, sa obrazloženjem kao osnovom da mnoge greške imaju tendenciju da se koncentrišu blizu ekstremnih vrednosti ulaza. Proširenje ove tehnike su testiranja robustnosti , gde su slučajevi testa takođe izabrani izvan ulazne oblasti promenljivih, kako bi se testirala robustnost programa prema neočekivanim ili pogrešnim ulazima. 3.2.3 Tabela odluka (Decision table) Tabele odluka predstavljaju logičke veze između uslova (grubo rečeno, ulaza) i akcija (grubo, izlaza). Slučajevi testa su sistematično dobijeni razmatranjem svake moguće kombinacije uslova i akcija. Tehnika povezana sa ovom je grafičko predstavljanje uzrok-efekat. 3.2.4 Konačnog stanja bazirane na mašini ( Finite-state machine-based ) Modeliranjem programa kao mašine konačnih stanja, testovi se mogu odabrati sa ciljem da se pokriju stanja i tranzicije na njima. 3.2.5 Testiranje specifications)
iz
formalnih
specifikacija
(Testing
from
formal
Davanje specifikacije u formalnom jeziku omogućava automatsku derivaciju funkcionalnih slučajeva testa i istovremeno, obezbeđuje referentni izlaz, oracle, za proveru rezultata testa. Metode postoje i za dobijanje slučajeva testa iz onih baziranih na modelu ili algebarskih specifikacija. 3.2.6 Slučajno testiranje (Random testing) Testovi su generisani samo slučajno, ali ih ne bi trebalo mešati sa statističkim testovima iz operacionog profila kao što je opisano u podtemi 3.5.1 Operativni profil . Ovaj vid testiranja pada pod naslov ulaza zasnovanih na specifikaciji jer bar oblast ulaza mora biti poznata kako bismo mogli da uzimamo slučajne tačke unutar nje.
3.3 Tehnike bazirane na kodu (Code-based)
3.3.1 Kriterijum baziran na kontrolnom protoku (Control-flow-based criteria) Ovi kriterijumi su usmereni za pokrivanje svih naredbi ili blokova naredbi u programu, ili njihovih posebnih kombinacija. Nekoliko kriterijuma je 12
predloženo kao pokrivanje uslov/odluka. Najjači od kriterijuma baziranih na kontrolnom toku je testiranje puta (path testing), koje ima za cilj izvršavanje svih od-ulaska-do-izlaska putanja kontrolnog toka u grafikonu toka. Zato što testiranje putanje generalno nije izvodljivo zbog petlji, drugi manje strogi kriterijumi koriste se u praksi, kao što je testiranje izjava, testiranje grana, i testiranje uslov/odluka. Adekvatnost takvih testova meri se procentima; na primer, kada su sve grane izvršene makar jednom u testu, 100% pokrivenosti grana se kaže da je postignuto. 3.3.2 Kriterijum baziran na toku podataka ( Data flow-based criteria) U ovakvom testiranju, kontrolni grafik toka beleži se sa informacijama o tome kako su promenljive u programu definisane, korišćene, i ubijene (nedefinisane). Najjači kriterijum, sve definicije – koriste puteve, zahteva da se za svaku promenljivu, svaki segment putanje kontrolnog toka iz definicije te promenljive koristi dok se izvršava. Kako bi se smanjio broj potrebnih putanja, slabije strategije kao svih definicija ( all-definitions) i svih upotreba (all-uses) se koriste. 3.3.3 Referentni modeli za testiranje bazirano na kodu ( flowgraph, call graph) Iako sama po sebi nije tehnika, kontrolna struktura programa grafički se prikazuje korišćenjem grafa tokova u tehnikama testiranja baziranim na kodu. Graf tokova je usmereni graf od kojeg čvorovi i lukovi odgovaraju programskim elementima. Na primer, čvorovi mogu predstavljati naredbe ili neometane sekvence naredbi, i lukovi transfer kontrole između čvorova. 3.4 Tehnike bazirane na defektima (Fault-based techniques) Sa različitim nivoima formalizacije, ove tehnike testiranja smišljaju slučajeve za testiranja posebno namenjene za otkrivanje kategorija verovatno ili unapred definisanih defekata.
3.4.1 Pogađanje grešaka (Error guessing) U pogađanju grešaka, slučajevi za testiranje su posebno dizajnirani od strane softverskih inženjera koji su pokušavali da otkriju najprihvatljivije greške datog programa. Dobar izvor informacija je istorija grešaka otkrivenih u ranijim projektima, kao i inženjerska ekspertiza. 3.4.2 Testiranje mutacija (Mutation tetsing) 13
Ovo je blago izmenjena verzija programa pod testom, razlikujući se malom, sintaksičkom promenom. Ukoliko je slučaj testiranja uspešan u utvrđivanju razlike između programa i mutanta, drugi se „ubija“. Originalno je osnovana kao tehnika evaluacije skupa testiranja. Mutaciono testiranje je samo po sebi kriterijum testiranja: ili su testovi slučajno generisani dok se dovoljan broj mutacija ne ubije, ili su testovi posebno dizajnirani da ubiju preživele mutacije. U drugom slučaju testiranje mutacija može se kategorisati kao tehnika bazirana na kodu. Osnovna pretpostavka testiranja mutacija, efekat združivanja, je ta da se traženjem jednostavnih sintaksičkih grešaka nalaze kompleksnije ali realni defekti. Kako bi tehnika bila efektivna, na sistematičan način se mora automatski proizvesti veliki broj mutanta.
3.5 Tehnike bazirane na upotrebi (Usage-based) 3.5.1 Operativni profil (Operational profile) U testiranju procene pouzdanosti okruženje testa mora reprodukovati operativno okruženje softvera što je bliže moguće. Ideja je da se iz posmatranih rezultata testa zaključuje buduća pouzdanost softvera kada je u pravoj upotrebi. Kako bi se to uradilo, ulazima se dodeljuje raspodela verovatnoće, ili profil, prema njihovom pojavljivanju u stvarnim operacijama. 3.5.2 Testiranje projektovano na pouzdanosti softvera ( Software Reliability Engineered Testing) Testiranje projektovano na pouzdanosti softvera (SRET) je metoda testiranja koja obuhvata čitav proces razvoja, gde je testiranje „dizajnirano i vođeno ciljevima pouzdanosti i očekivanim relativnim korišćenjem i kritičnostima različitih funkcija u oblasti“. 3.6 Tehnike bazirane na prirodi aplikacije
Ove tehnike se odnose na sve tipove softvera. Ipak, za neke vrste aplikacija, potreban je dodatni know-how za izvođenje testa. Lista nekoliko specijalizovanih oblasti testiranja data ovde, bazirana na prirodi aplikacije : •
Testiranje bazirano na objektu (Object-oriented testing) Testiranje bazirano na komponentama (Component-based testing)
•
Web-bazirano testiranje (Web-based testing)
•
GUI testiranje 14
•
Testiranje konkurentnih programa
•
Testiranje usaglašenosti protokola
•
Testiranje sistema realnog vremena
•
Testiranje bezbednosno-kritičnih sistema (IEEE1228-94)
3.7 Selekcija i kombinovanje tehnika
3.7.1 Funkcionalne i strukturne Tehnike testiranja bazirane na specifikaciji i kodu često su kontrastne kao funkcionalno nasuprot strukturnom testiranju. Ova dva pristupa odabiru testa ne treba posmatrati kao alternativne već komplementarne; zapravo, one koriste različite izvore informacija i dokazano je da daju akcenat na različite vrste problema. Mogu se koristiti u kombinaciji, u zavisnosti od budžeta. 3.7.2 Determinističke nasuprot slučajnim Slučajevi testa se mogu izabrati na deterministički način, prema raznim tehnikama koje su nabrojene, ili slučajno iz nekih raspodela ulaza, kao što se obično radi u testiranju pouzdanosti. Nekoliko analitičkih i empirijskih poređenja je sprovedeno kako bi se analizirali uslovi koji čine da je jedan pristup efektivniji od drugog.
15
4. Merenja vezana za test5
Ponekad, tehnike testa se mešaju sa ciljevima testa. Tehnike testa treba gledati kao sredstva koja pomažu da se postignu ciljeva testa. Na primer, pokrivenost grane je popularna tehnika testa. Dostizanje određenih mera pokrivenosti grane ne bi trebalo posmatrati kao cilj testiranja samo po sebi: to je sredstvo kako bi se poboljšale šanse nalaženja kvarova sistematskim vežbama svake grane programa iz tačke odluke. Kako bi izbegli takve nesporazume, mora se napraviti jasna razlika između mera povezanih sa testom, koje obezbeđuju evaluaciju programa pri testu baziranom na posmatranim izlazima testa, i onih koje procenjuju temeljnost skupa testa. Mere se obično smatraju za instrument analize kvaliteta. Mere se mogu koristiti za optimizaciju planiranja i izvršavanja testova. Menadžment može koristiti nekoliko mera procesa kako bi nadgledali napredak. 4.1 Procena testiranog programa (IEEE982.1-98)
4.1.1 Merenja programa koja pomažu planiranju i dizajniranju testa Mere bazirane na veličini programa (na primer, izvorne linije koda ili funkcionalne tačke) ili strukture programa (kao što je kompleksnost) koriste se za vođenje programa. Strukturne mere, takođe, mogu uključivati merenja među modulima programa u pogledu učestalosti kojom se moduli pozivaju međusobno. 4.1.2 Tipovi defekata, klasifikacija i statistike U literaturi se može naći dosta klasifikacija i taksonomija defekata. Kako bi testiranje bilo efektivnije, bitno je znati koji tip nedostatka se može naći u softveru prilikom testiranja, i njegova učestalost sa kojom su se ovakvi nedostaci pojavljivali u prošlosti. Ova informacija može biti veoma korisna prilikom predviđanja kvaliteta, kao i za unapređenje procesa. 4.1.3 Gustina defekata ( Fault density ) Program pod testom se može oceniti brojanjem i klasifikacijom otkrivenih defekata po njihovim tipovima. Za svaku klasu defekata meri se gustina defekata kao odnos između broja defekata nađenih i veličine programa. 5
P. C. Jorgensen, Software Testing: A Craftsman's Approach, (second edition, CRC Press, 2004), S. L. Pfleeger, Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001), Chaps. 2, 9. B. Beizer, Software Testing Techniques, (International Thomson Press, 1990), Chaps. 2, 7.
Chaps. 8-9. W. Perry, Effective Methods for Software Testing , (John Wiley & Sons, 1995), Chaps. 17, 20. M.R. Lyu, Handbook of Software Reliability Engineering , (Mc-Graw-Hill/IEEE, 1996), Chap. 7. H. Zhu, P.A.V. Hall and J.H.R. May, Software Unit Test Coverage and Adequacy,( ACM Computing Surveys, vol. 29, 1997). Sections 3, 5
16
4.1.4 Test trajanja, procena pouzdanosti Statistička procena pouzdanosti softvera, koja se može dobiti dostizanjem pouzdanosti i evaluacijom, može se koristiti za procenu proizvoda i na osnovu toga doneti odluka da li se testiranje može ili ne može zaustaviti. 4.1.5 Modeli rasta pouzdanosti Ovi modeli obezbeđuju predviđanje pouzdanosti na osnovu posmatranih defekata pod dostignutom pouzdanošću i evaluacijom. Oni pretpostavljaju, u opštem slučaju, da su defekti koji su izazvali posmatrane neuspešnosti popravljeni (iako neki modeli prihvataju nesavršenosti), i prema tome, u proseku, pouzdanost proizvoda prikazuje trend rasta. Sada postoji više modela. Mnogi su zasnovani na opštim pretpostavkama, dok se drugi razlikuju. Zapažamo, da su ovi modeli podeljeni u modele koji broje defekte i one koji uzimaju vreme između defekata.
4.2 Evaluacija izvršenih testova 4.2.1 Mere pokrivenosti/temeljnosti (Coverage/thoroughness measures ) Neki kriterijumi adekvatnosti testa zahtevaju da slučajevi testiranja sistematski ispituju skup elemenata identifikovanih u programu ili specifikaciji. Kako bi procenili temeljnost izvršenog testa, testeri mogu da nadgledaju pokrivene elemente, tako da dinamički mogu meriti odnos između pokrivenih elemenata i njihovog ukupnog broja. Na primer, moguće je meriti procenat pokrivenih grana u grafu toka programa, ili procenat funkcionalnih zahteva ostvarenih među onima koji su navedeni u listi dokumenta specifikacije. Kriterijum adekvatnosti baziran na kodu zahteva prikladanu instrumentaciju programa pod testom. 4.2.2 „Uvođenje“ defekata ( Fault seeding) Neki defekti se veštačkim putem uvode u program pre testiranja. Kada se testovi izvršavaju, neki od ovih postavljenih defekata biće otkriveni, kao verovano još neki koji su već postojali. U teoriji, u zavisnosti od toga koji su veštački defekti otkriveni i koliko, može se proceniti efektivnost testiranja i može se proceniti broj preostalih pravih grešaka. U praksi, statističari sumnjaju u raspodelu i reprezentativnost uvedenih defekata u odnosu na prave defekte i male veličine na kojoj se bazira ekstrapolacija. 17
Neki navode da bi ovu tehniku trebalo koristiti sa velikom pažnjom, jer uvođenje defekata u softver uključuje očigledan rizik toga da oni tu ostanu. 4.2.3 Rezultat mutacija (Mutation score) U testiranju mutacija, odnos ubijenih mutacija u odnosu na ukupan broj generisanih može biti mera efektivnosti izvršenog testa. 4.2.4 Poređenje i relativna efektivnost različitih tehnika Sprovedeno je nekoliko studija kako bi se poredila relativna efektivnost sa različitim tehnikama testa. Bitna je preciznost karakteristika u odnosu na koje se tehnike procenjuju; šta je, na primer, tačno značenje termina „efektivnost“? Moguća tumačenja su: broj potrebnih testova kako bi se pronašao prvi defekt, odnos broja defekata nađenih tokom testiranja u odnosu na sve greške nađene tokom i nakon testiranja, ili u kojoj meri je pouzdanost unapređena. Analitička i empirijska poređenja različitih tehnika sprovedena su prema svakom pojmu efektivnosti određenom iznad.
5. Proces testa (Test process)
Koncepti testa, strategije, tehnike i mere potrebno je da budu integrisani u određen i kontrolisan proces koji vode ljudi. Proces testiranja podržava aktivnosti testiranja i omogućava vođenje timovima testiranja, od planiranja testa do procene izlaza testa, kao što obezbeđuje opravdano osiguranje da će ciljevi testiranja biti efikasno ispunjeni. 5.1 Praktična razmatranja6 5.1.1 Programiranje bez stavova/bezlično programiranje ( Attitudes/Egoless programming) Veoma bitna komponenta uspešnog testiranja je stav saradnje za testiranje i kvalitetne aktivnosti uverenja. Menadžeri imaju ključnu ulogu u usvajanju opšteg pozitivnog prihvatanja otkrivanja defekata tokom razvoja i održavanja; na primer, prevencijom razmišljanja o vlasništvu koda među 6
B. Beizer, Software Testing Techniques, (International Thomson Press, 1990), Chap. 13. Pfleeger, Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001), Chaps. 8-9. J. Bach, and B. Pettichord, Lessons Learned in Software Testing , (Wiley Computer Publishing, 2001). Beck, Test-Driven Development by Example, (Addison-Wesley, 2002). W. Perry, Effective Methods for Software Testing , (John Wiley & Sons, 1995), Chaps. 1-4, 19, 21. Kaner, J. Falk, and H.Q. Nguyen, Testing Computer Software, (second ed., John Wiley & Sons, 1999), Chaps. 12, 15.
18
S. L. C. Kaner, K. C.
programerima, tako da se ne osećaju odgovornim za defekte koji su otkriveni njihovim kodom.
5.1.2 Vođenje testova (Test guides) Faza testiranja može biti vođena raznim ciljevima, na primer: u testiranju baziranom na riziku, koje koristi rizik proizvoda radi utvrđivanja prioriteta i fokusiranja na strategiju testa; ili u testiranju baziranom na scenariju, u kojem su slučajevi testa bazirani na utvrđenom scenariju softvera. 5.1.3 Menadžment procesa testa Aktivnosti testa sprovedene na različitim nivoima moraju biti organizovane, zajedno sa ljudima, alatima, politikama, i merama, u dobro definisan proces koji je integralni deo životnog ciklusa. U IEEE/EIA Standardu 12207.0, testiranje se ne opisuje kao samostalan proces, već su principi aktivnosti testiranja uključeni u pet primarnih pocesa životnog ciklusa kao i u procese podrške. U IEEE Std 1074, testiranje je grupisano sa drugim aktivnostima evaluacije, kao značajno za čitav životni ciklus. 5.1.4 Dokumentacija testa i proizvodi rada Dokumentacija je integralni deo formalizacije procesa testa. IEEE Standard for Software Test Documentation (IEEE829-98) obezbeđuje dobar opis dokumentacije testa i njihove međusobne veze i veze sa procesom testiranja. Dokumentacija testa može uključivati, između ostalog, plan testa, specifikaciju dizajna testa, specifikaciju procedure testa, specifikaciju slučajeva testa, log testa, i incidente testa ili izveštaj o problemima. Softver pod testom se dokumentuje kao predmet testiranja. Dokumentacija testa bi trebalo da bude oformljena i kontinualno ažurirana, do istog nivoa kvaliteta kao i drugi tipovi dokumentacije u softverskom inženjeringu. 5.1.5 Interni vs. Nezavisni tim (Internal vs. independent test team) Formalizacija procesa testiranja može uključivati formalizaciju i organizacije tima koji vrši testiranje. Ovaj tim mogu sačinjavati interni članovi (odnosno, projektni tim, uključen ili ne u konstrukciju softvera), ili eksterni članovi, sa ciljem da se dobiju objektivne, nezavisne perspektive, ili, na kraju, da bude sačinjen i od internih i od eksternih članova. Razmatranja troškova, vremena, zrelosti nivoa uključene organizacije, i kritičnost aplikacije mogu presuditi u odlučivanju.
19
5.1.6 Procena troškova/napora i druge mere procesa (Cost/effort estimation and other process measures) Nekoliko mera povezanih sa resursima potrošenim za testiranje, kao i u vezi sa relativnom efektivnošću pronalaženja defekata na različitim fazama testa, koriste menadžeri kako bi kontrolisali i unapredili proces testa. Ove mere testa mogu pokrivati aspekte kao što su broj određenih slučajeva testa, broj izvršenih slučajeva testa, broj slučajeva koji su prošli, broj slučajeva koji su bili neuspešni, između ostalih. Evaluacija faza testa može se kombinovati sa analizom korenih uzroka (root cause) kako bi se procenila efektivnost procesa testa u nalaženju defekata što je ranije moguće. Takva procena se može povezati sa analizom rizika. Povrh toga, resursi potrošeni za testiranje trebalo bi da budu propocionalni sa upotrebom/kritičnošću primene: različite tehnike imaju različite troškove i daju različite nivoe poverenja pouzdanosti proizvoda. 5.1.7 Završetak (Termination) Potrebno je doneti odluku koliko je testiranja dovoljno i kada se može završiti faza testiranja. Temeljne mere, kao što je dostignuta pokrivenost koda ili funkcionalna kompletnost, kao i procene gustine defekata ili operativne pouzdanosti, omogućuju korisnu podršku, ali same nisu dovoljne. Odluka takođe uključuje razmatranja o troškovima i rizicima nastalim iz potencijalnih preostalih defekata, nasuprot troškovima koji bi podrazumevali nastavak testa.
5.1.8 Ponovna upotreba testa i obrasci testa Kako bi se testiranje ili održavanje sprovelo na organizovan i troškovnoefikasan način, sredstva korišćena za testiranje svakog dela softvera trebalo bi se sistematski ponovo koristiti. Ovo skladište materijala za testiranje mora biti pod kontrolom menadžmenta za softversku konfiguraciju, tako da se promene zahteva softvera ili dizajna odražavaju u promenama prostora sprovedenog testa. Rešenja testa prihvaćena za testiranje nekih tipova aplikacija pod određenim okolnostima, sa motivacijom iza sprovedene odluke, formiraju obrazac testa koji se može dokumentovati za kasnije ponovne upotrebe u sličnim projektima. 5.2 Aktivnosti testa (Test activities)7 7
C. Kaner, J. Falk, and H.Q. Nguyen, Testing Computer Software, (second ed., John Wiley & Sons, 1999), Chaps. 5-7, 11-12 W. Perry, Effective Methods for Software Testing , (John Wiley & Sons, 1995), Chaps. 19-21. L. Pfleeger, Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001), Chap. 8.
20
S. B. Beizer,
Pod ovom temom dat je kratak pregled aktivnosti testa; kao što se često podrazumeva narednim opisom, uspešno upravljanje aktivnostima testa u velikoj meri zavisi od procesa menadžmenta softverske konfiguracije. 5.2.1 Planiranje (Planning) Kao i bilo koji drugi aspekt projektnog menadžmenta, i aktivnosti testiranja mogu biti planirane. Ključni aspekti planiranja testa uključuju koordinaciju zaposlenih, upravljenje dostupnih objekata za testove i opreme (koja može da uključuje magnetske medije, planove i procedure testova), i planiranje mogućih neželjenih ishoda. Ukoliko se održava više od jedne osnovne linije softvera, tada se kao glavno razmatra vreme i napor potreban za obezbeđivanje da je okruženje za test postavljeno na odgovarajućoj konfiguraciji. 5.2.2 Generisanje test-slučajeva (Test-case generation) Generisanje test-slučajeva je bazirano na nivou testiranja koji treba izvršiti i u odnosu na posebne tehnike testiranja. Test-slučajevi bi trebalo da budu pod kontrolom menadžmenta softverske konfiguracije i uključuju očekivane rezultate za svaki test. 5.2.3 Razvoj okruženja testa (Test environment development ) Okruženje korišćeno za testiranje trebalo bi da je kompatibilno sa alatima softverskog inženjeringa. Trebalo bi da olakša razvoj i kontrolu testslučajeva, kao i povraćaj očekivanih rezultata, skripti, i drugih materijala za testiranje. 5.2.4 Izvršavanje (Execution) Izvršavanje testa bi trebalo da otelotvori osnovni princip naučnog eksperimentisanja: sve što je urađeno tokom testa trebalo bi da je izvršeno i dokumentovano dovoljno jasno da bi druga osoba mogla da ponovi rezultate. Stoga, testiranje bi trebalo izvršavati u skladu sa dokumentovanim procedurama, upotrebom jasno definisane verzije softvera u testu. 5.2.5 Procena rezultata testa (Test results evaluation) Rezultati testa se moraju oceniti kako bi se utvrdilo da li je test bio uspešan. U većini slučajeva, „uspešan“ znači da je softver dao očekivane rezultate i nije imao većih problema sa neočekivanim izlazima. Nisu svi neočekivani izlazi obavezno defekti. Pre nego što se defekt može ukloniti, potrebna je analiza i napor kako bi se izolovao, identifikovao i opisao Software Testing Techniques, (International Thomson Press, 1990), Chaps. 13.
21
problem. Kada su rezultati testa posebno značajni, može se sazvati formalni sastanak za pregled kako bi to procenio. 5.2.6 Izveštavanje problema (Problem reporting)/Test log Aktivnosti testiranja mogu se uneti u log testa kako bi se identifikovalo kada je test izvršen, ko je izvršio test, koja je softverska konfiguracija bila osnova za testiranje, i druge relevantne informacije. Neočekivani ili netačni rezultati testa mogu se zabeležiti u sistemu izveštavanja problema, podaci od kojih se formira baza za kasnije popravljanje grešaka koji su bili zapaženi kao defekti tokom testiranja. Takođe, anomalije koje nisu klasifikovane kao defekti mogu se dokumentovati za slučaj da se kasnije ispostavi da su važnije od onoga što se prvo smatralo. Izveštaji testa su takođe ulaz za promenu procesa upravljanja. 5.2.7 Praćenje kvarova (Defect tracking) Neuspesi posmatrani tokom testiranja najčešće nastaju zbog defekata ili kvarova softvera. Takvi kvarovi se mogu analizirati kako bi se utvrdilo kada su uvedeni u softver, kakve greške su dovele do njihovog nastanka (loše definisane potrebe, netačne deklaracije promenljivih, curenje memorije, greška programske sintakse) i kada su prvi put mogle biti primećene u softveru. Informacije o praćenju kvarova koriste se za utvrđivanje koje aspekte softverskog inženjeringa bi trebalo unaprediti i koliko su bile uspešne prethodne analize i testiranja.
Kvalitet softvera CMMI-Capability Maturity Model Integrated, COTS-Commercial Off-theShelf Software, PDCA-Plan, Do, Check, Act, SQA-Software Quality Assurance, SQM-Software Quality Management, TQM-Total Quality Management, V&V-Verification and Validation
Tokom godina, autori i organizacije na različite načine su definisali termin „kvalitet“. Za Phil Crosby-a, to je bila „potvrda zahteva korisnika“. Watts Humphrey ga naziva „postizanje odličnih nivoa prikladnosti za upotrebu“, dok je IBM dao frazu „kvalitet vođen tržištem“ (“market-driven quality“), koji je baziran na dostizanju potpunog zadovoljstva kupaca. Kriterijum Baldrige-a za organizacijski kvalitet (NIST03) ima sličnu frazu, „kvalitet vođen kupcem“ (“customer-driven quality”), i uključuje zadovoljstvo kupaca kao glavno razmatranje. Skorije, kvalitet je definisan u (ISO900100) kao „stepen do kog skup inherentnih karakteristika ispunjava zahteve.“
22
Slika 2 - Podela tema o kvalitetu softvera
Podela tema o kvalitetu softvera 1. Osnove kvaliteta softvera (Software Quality Fundamentals)
Usaglašavanje o zahtevima kvaliteta, kao i jasna komunikacija sa softverskim inženjerom o tome šta predstavlja kvalitet, zahteva da mnogi aspekti kvaliteta budu formalno definisani i razmatrani. Softverski inženjer bi trebalo da razume osnovna značenja koncepta kvaliteta i karakteristika kao i njihovih vrednosti za softver prilikom razvoja ili do održavanja. Značajan koncept je taj da softverski zahtevi definišu potrebne 23
karakteristike kvaliteta softvera i uticaj metoda merenja i kriterijuma prihvatanja za procenu ovih karakteristika. 1.1 Kultura i etika softverskog inženjerstva ( Software Engineering Culture and Ethics )
Očekuje se da softverski inženjeri dele posvećenost za softverskim kvalitetom kao deo njihove kulture. Zdrava kultura softverskog inženjerstva opisana je u [Wie96]. Etika može imati značajnu ulogu u softverskom kvalitetu, kulturi, i stavovima softver inženjera. IEEE Computer Society i ACM [IEEE99] razvili su etički kodeks i profesionalnu praksu na osnovu osam principa kako bi pomogli softverskim inženjerima da ojačaju stavove u vezi sa kvalitetom i nezavisnošću svog posla. 1.2 Vrednost i troškovi kvaliteta (Value and Costs of Quality)8
Pojam „kvaliteta“ nije tako jednostavan kao što može da izgleda. Za bilo koji projektovani proizvod postoji više željenih kvaliteta koji su relevantni za posebnu perspektivu proizvoda koji se moraju razmatrati i utvrditi za vreme za koje se definišu zahtevi proizvoda. Karakteristike kvaliteta mogu biti obavezne ili ne, ili mogu biti tražene do višeg ili nižeg nivoa, i među njima se mogu izvršiti kompromisi. Troškovi kvaliteta mogu biti podeljeni na troškove prevencije, troškove procene, unutrašnje troškove otkaza i spoljašnje troškove otkaza. Motivacija iza softverskog projekta je želja za stvaranjem softvera koji ima vrednost, a ta vrednost može biti, ili ne, označena kao trošak. Korisnik će imati neke maksimalne cene u vidu u zamenu za koju se očekuje da će osnovna svrha softvera biti ispunjena. Korisnik će imati i neka očekivanja u pogledu kvaliteta softvera. Ponekad klijenti ne razmišljaju o pitanjima kvaliteta ili vezanim troškovima. Da li je ta karakteristika samo dekorativna, ili je od ključnog značaja za softver? Ako se odgovor nalazi između, kao što je gotovo uvek slučaj, onda je pitanje uključivanja klijenta delom u proces odluke, i potpuno obaveštenje i o troškovima i o koristima. U idealnom slučaju, većina tih odluka će se doneti u toku procesa uzimanja zahteva, ali ova pitanja mogu se javiti i tokom životnog ciklusa softvera. Ne 8
B.W. Boehm et al., “Characteristics of Software Quality,” TRW Series on Software Technologies, (vol. 1, 1978). National Institute of Standards and Technology, “Baldrige National Quality Program,” http://www.quality.nist.gov (accessed January 14, 2012). R.S. Pressman, Software Engineering: A Practitioner’s Approach, (sixth ed., McGraw-Hill, 2004). K. Wiegers, Creating a Software Engineering Culture, (Dorset House, 1996), Chap. 11. S.L. Pfleeger,Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001). C. Jones and J. Capers, Applied Software Measurement: Assuring Productivity and Quality, (second ed., McGraw-Hill, 1996), Chap. 5. D. Houston, “Software Quality Professional,” ( ASQC , vol. 1, iss. 2, 1999).
24
postoji određeno pravilo o tome kako bi ova odluka trebalo da bude donešena, ali softverski inženjer bi trebalo da bude u stanju da predstavi alternative kvaliteta i njihovih trošova.
1.3
Modeli i karakteristike kvaliteta (Models and Quality Characteristics)9
Terminologija za karakteristike softverskog kvaliteta razlikuje se od jedne do druge taksonomije (ili modela kvaliteta softvera), gde svaki model ima različite hijerarhijske nivoe i različit ukupan broj karakteristika. Razni autori su proizveli modele karakteristika softverskog kvaliteta ili atributa koji mogu biti korisni za diskusiju, planiranje i ocenu kvaliteta proizvoda softvera ISO/IEC je definisao tri povezana modela kvaliteta softverskog proizvoda (interni kvalitet, eksterni kvalitet, i kvalitet u upotrebi) (ISO9126-01) kao i skup povezanih delova (ISO14598-98). 1.3.1 Kvalitet procesa softverskog inženjerstva Upravljanje kvalitetom softvera i kvalitet procesa softverskog inženjerstva imaju direktan uticaj na kvalitet softverskog proizvoda. Modeli i kriterijumi koji procenjuju sposobnosti softverske organizacije prvenstveno su projektne organizacije i pitanja menadžmenta, i kao takvi prikazani u okviru oblasti znanja upravljanja softverskog inženjerstva ( Software Engineering Management ) i procesa softverskog inženjerstva (Software Engineering Process). Naravno, nije moguće u potpunosti razlikovati kvalitet procesa od kvaliteta proizvoda. Kvalitet procesa, razmatran u oblasti znanja procesa softverskog inženjeringa u okviru ovog Vodiča, utiče na karakteristike kvaliteta softverskih proizvoda, što zauzvrat utiče na kvalitet u upotrebi viđen od strane kupaca. Dva važna standarda kvaliteta su TickIT i jedan koji ima uticaj na kvalitet softvera, ISO9001-00 standard, zajedno sa svojim smernicama za aplikaciju na softveru [ISO90003-04]. Još jedan industrijski standard softverskog kvaliteta je CMMI ( Capability Maturity Model Integrated ), o kome se takođe, razmatra u oblasti znanja 9
G. Dache, “ IT Companies will gain competitive advantage by integrating CMM with ISO9001”, (vol. 11, iss. 11, November 2001). D. Kiang, “ Harmonization of International Software Standards on Integrity and Dependability,” (IEEE Computer Society Press, 1995). J.C. Laprie, Dependability: Basic Concepts and Terminology in English, French, German, Italian and Japanese, (IFIP WG 10.4, Springer-Verlag, 1991). R.O. Lewis, Independent Verification and Validation: A Life Cycle Engineering Process for Quality Software, (John Wiley & Sons, 1992). J. Musa, Software Reliability Engineering: More Reliable S oftware, Faster Development and Testing: McGraw Hill, (1999). National Institute of Standards and Technology, “Baldrige National Quality Program,” http://www.quality.nist.gov (accessed January 14, 2012). S.R. Rakitin, Software Verification and Validation: A Practitioner’s Guide, (Artech House, 1997). “Capability Maturity Model Integration for Software Engineering (CMMI)”, (Carnegie Mellon University, 2002).
25
procesa softverskog inženjeringa. CMMI ima nameru da obezbedi smernice za poboljšanje procesa. Specifična područja procesa povezana sa upravljanjem kvalitetom su (a) obezbeđivanje kvaliteta procesa i proizvoda, (b) proces verifikacije, i (c) proces validacije. CMMI klasifikuje preglede i revizije kao metode verifikacije, ne kao posebne procese kao (IEEE12207.0-96). U početku je bilo rasprava oko toga da li bi softverski inženjeri trebalo da koriste ISO9001 ili CMMI kako bi obezbedili kvalitet. Ova rasprava je bila dosta objavljivana, a kao rezultat toga, uzet je stav da su oni komplementarni, i da posedovanje ISO9001 sertifikacije u mnogome može pomoći u postizanju viših nivoa zrelosti od CMMI. 1.3.2 Kvalitet softverskog proizvoda Softver inženjer bi trebalo da, kao prvo, utvrdi stvarnu svrhu softvera. U tom pogledu, najznačajnije je imati na umu da zahtevi kupaca dolaze na prvom mestu i da oni obuhvataju zahteve kvaliteta, a ne samo funkcionalne zahteve. Prema tome, softver inženjer ima odgovornost da izvuče zahteve kvaliteta koji možda nisu eksplicitno objašnjeni, i razmotri njihovu važnost, kao i nivo težine njihovog ostvarivanja. Svi procesi povezani s kvalitetom softvera (na primer, izgradnja, proveravanje i poboljšanje kvaliteta) će biti dizajnirani u skladu ovim zahtevima, i oni nose dodatne troškove. Standard (ISO9126-01) definiše, za dva, od svoja tri modela kvaliteta, povezane karakteristike i podkarakteristike kvaliteta, kao i mere koje su korisne za ispunjenje kvaliteta softverskog proizvoda. Značenje termina "proizvod" je prošireno kako bi uključilo bilo koji predmet (artefakt) koji je izlaz iz bilo kojeg procesa korišćenog za izgradnju finalnog softverskog proizvoda. Primeri proizvoda uključuju, ali nisu ograničeni na njih, celi sistem specifikacije zahteva, specifikaciju softverskih zahteva za softverskim komponentama sistema, dizajn modul, kod, dokumentaciju testa, ili izveštaje nastale kao rezultat zadataka analize kvaliteta. Dok je većina tretmana kvaliteta opisana u vidu konačnog softvera i sistemskih performansi, ispravno inženjerstvo u praksi zahteva da i međuproizvodi relevantni za kvalitet, budu procenjeni tokom samog procesa softverskog inženjerstva. 1.4 Unapređenje kvaliteta (Quality Improvement)10
10
National Institute of Standards and Technology, “Baldrige National Quality Program,” http://www.quality.nist.gov (accessed January 14, 2012). G.M. Weinberg, “Measuring Cost and Value,” (Quality Software Management: First-Order Measurement , vol. 2, chap. 8, Dorset House, 1993).
26
Kvalitet softverskih proizvoda može se unaprediti kroz iterativni proces kontinualnih poboljšanja koji zahteva kontrolu menadžmenta, koordinaciju i povratne informacije od strane više konkurentnih procesa: (1) procesa životnog ciklusa softvera, (2) procesa otkrivanja, uklanjanja i prevencije grešaka/defekata, i (3) procesa unapređenja kvaliteta. Teorija i koncepti iza unapređenja kvaliteta, kao što je izgradnja kvaliteta kroz prevenciju i ranu detekciju grešaka, kontinualna poboljšanja, i usmerenost na kupce, značajni su za softversko inženjerstvo. Ovi koncepti su bazirani na radu eksperata u oblasti kvaliteta, koji navode da je kvalitet proizvoda direktno povezan sa kvalitetom procesa koji je korišćen u njegovom kreiranju. Pristupi kao što je Totalno upravljanje kvalitetom (Total Quality Management (TQM)) obrađuju procese Plan, Do, Check, i Act (PDCA) koji predstavljaju alate preko kojih se ispunjavaju ciljevi kvaliteta. Pokroviteljstvo menadžmenta podržava proces i procenu proizvoda kao i dobijene rezultate. Tada je unapređeni program razvijen identifikovanjem detaljnih akcija i projekata unapređenja koje bi trebalo ispuniti u izvodljivom vremenskom okviru. Podrška menadžmenta podrazumeva da svaki projekat unapređenja ima dovoljno resursa za postizanje cilja, definisanog za njega. Pokroviteljstvo menadžmenta mora se frekventno tražiti implementacijom proaktivnih aktivnosti komunikacija. Uključenost radnih grupa, kao i podrške srednjeg nivoa menadžmenta i resursi alocirani na projektnom nivou, razmatraju se u oblasti znanja procesa softverskog inženjeringa (Software Engineering Process KA). 2. Menadžment procesi
kvaliteta softvera (Software Quality Management Processes)
Menadžment kvaliteta softvera (SQM) primenjuje se na sve perspektive softverskih procesa, proizvode i resurse. On definiše procese, vlasnike procesa i zahteve za ovim procesima, merenja procesa i njihovih izlaza, kao i kanale povratnih informacija (feedback). Proces menadžmenta kvaliteta softvera sastoji se od dosta aktivnosti. Neke mogu direktno da otkriju defekte, dok druge ukazuju gde može biti korisno raditi dalja ispitivanja. Druge se takođe, nazivaju aktivnosti direktnog otkrivanja defekata (directdefect-finding). Mnoge aktivnosti se koriste u oba slučaja. Planiranje kvaliteta softvera uključuje: 1. Definisanje željenog proizvoda u pogledu njegovih karakteristika kvaliteta 27
2. Planiranje procesa radi postizanja željenog proizvoda Ovi aspekti se razlikuju od, na primer, samostalnog planiranja SQM procesa, koji procenjuje planirane karakteristike kvaliteta u odnosu na implementaciju tih planova. Procesi menadžmenta kvaliteta softvera moraju se odnositi na to koliko dobro će softverski proizvodi zadovoljiti zahteve kupaca i stejkholdera, obezbediti vrednost za kupce i druge stejkholdere, i obezbediti kvalitet softvera koji je potreban za ispunjenje softverskih zahteva.
SQM se može koristiti za procenu međuproizvoda kao i finalnog proizvoda. Neki od specifičnih SQM procesa su definisani u standardu (IEEE12207.096): •
Proces osiguranja kvaliteta (Quality assurance process)
•
Proces verifikacije (Verification process)
•
Proces validacije (Validation process)
•
Proces pregleda (Review process)
•
Proces revizije (Audit process)
Ovi procesi podstiču kvalitet i, takođe, nalaze moguće probleme. Ali se malo razlikuju u svojom značaju. SQM procesi pomažu da se obezbedi kvalitet softvera u datom projektu. Oni, takođe obezbeđuju, kao sporedni proizvod, opšte informacije za menadžment, uključujući indikaciju kvaliteta čitavog procesa softverskog inženjerstva. Proces softverskog inženjerstva (The Software Engineering Process) i oblasti znanja menadžmenta softverskog inženjerstva (Software Engineering Management KA) razmatraju programe kvaliteta za organizaciju koja razvija softver. SQM može da obezbedi relevantne povratne informacije u ovim oblastima. Procesi SQM-a se sastoje od zadataka i tehnika koje ukazuju kako se softverski planovi (na primer, menadžment, razvoj, menadžment konfiguracije) implementiraju i koliko dobro međuproizvodi i finalni proizvodi ispunjavaju svoje specifične zahteve. Rezultati ovih zadataka su sastavljeni u okviru izveštaja za menadžment pre sprovođenja korektivnih akcija. Menadžment SQM procesa ima zadatak da obezbedi da su rezultati ovih izveštaja tačni. Kao što je opisano u ovoj oblasti znanja, SQM procesi su blisko povezani; oni mogu da se preklapaju i ponekad su čak kombinovani. Izgleda da su jako reaktivni u prirodi jer mogu da upute procese kao u praksi i proizvode kao što je napravljeno; ali imaju bitnu ulogu u fazi planiranja, jer moraju da budu proaktivni u pogledu procesa i 28
procedura potrebnih za dobijanje karakteristika kvaliteta i stepena kvaliteta softvera potrebnog za stejkholdere. Upravljanje rizikom (Risk Management ), takođe, može imati značajnu ulogu u isporuci kvalitetnog softvera. Uključivanje disciplinovane analize rizika i menadžment tehnika u procese životnog ciklusa softvera može povećati potencijal za proizvodnju kvalitetnog proizvoda. 2.1 Osiguranje
kvaliteta softvera (Software Quality Assurance) 11
Procesi SQA pružaju obezbeđenje da softverski proizvodi i procesi u životnom ciklusu projekta odgovaraju njihovim datim zahtevima planiranjem, propisima i izvođenjem skupa aktivnosti kako bi se obezbedilo adekvatno poverenje da je kvalitet ugrađen u softver. Ovo znači osiguranje da je problem jasno i adekvatno naveden i da su zahtevi rešenja ispravno definisani i izraženi. SQA teži da održi kvalitet kroz razvoj i održavanje proizvoda putem izvršavanja više aktivnosti na svakoj fazi, što može rezultirati ranom identifikacijom problema, gotovo neizbežne pojave u bilo kojoj kompleksnoj aktivnosti. Uloga SQA u odnosu na proces je osiguranje da su planirani procesi prikladni i kasnije implementirani prema planu, i da je relevantan proces merenja obezbeđen za prikladnu organizaciju. SQA plan definiše sredstva koja će biti korišćena kako bi se obezbedilo da softver, razvijen za određeni proizvod, zadovoljava korisnikove zahteve i da je najvećeg mogućeg kvaliteta unutar ograničenja projekta. Kako bi se to uradilo mora se prvo obezbediti da je cilj kvaliteta jasno definisan i shvaćen. Mora se uzeti u obzir menadžment, razvoj i planovi održavanja za softver. Za više detalja pogledajte standard (IEEE730-98). Određene aktivnosti i zadaci kvaliteta su izloženi, zajedno sa njihovim troškovima i zahtevima za resurse, njihovim ukupnim ciljevima menadžmenta, i njihovim rasporedom u vezi sa onim ciljevima u menadžmentu softverskog inženjerstva, razvoja, ili planova održavanja. SQA plan mora biti konzistentan sa planom menadžmenta softverske konfiguracije (detaljnije u Software Configuration Management KA). SQA plan identifikuje dokumenta, standarde, prakse i konvencije kojima se 11
F.A. Ackerman, “Software Inspections and the Cost Effective Production of Reliable Software”, (2002). R.G. Ebenau and S. Strauss, Software Inspection Process, (McGraw-Hill, 1994). D.P. Freedman and G.M. Weinberg, Handbook of Walkthroughs, Inspections, and Technical Reviews, (Little, Brown and Company, 1998). R.B. Grady, Practical Software Metrics for Project Management and Process Management , (Prentice Hall, 1992). J. W. Horch, Practical Guide to Software Quality Management , (Artech House Publishers, 2003). G.C. Schulmeyer and J.I. McManus, Handbook of Software Quality Assurance,( third ed., Prentice Hall, 1999). I. Sommerville, Software Engineering , (seventh ed., Addison-Wesley, 2005). J. Voas, “Certifying Software For High Assurance Environments,” (IEEE Software, vol. 16, iss. 4, July-August 1999), pp. 48-54.
29
reguliše projekat, i kako će se oni proveravati i pratiti radi obezbeđenja adekvatnosti i usaglašenosti. Plan SQA takođe, identifikuje mere, statističke tehnike, procedure za izveštavanje o problemima kao i korektivne akcije, resurse kao što su, alati, tehnike, metodologije, obezbeđenje fizičkih medija, trening, i SQA izveštavanje i dokumentacija. Štaviše, SQA plan se odnosi i na aktivnosti obezbeđenja kvaliteta softvera bilo kog drugog tipa aktivnosti opisanog u planu softvera, kao što je nabavka od dobavljača softvera do projekta ili instalacije komercijalnog offthe-shelf softvera (COTS), i servisiranje nakon isporuke softvera. Takođe, može sadržati kriterijume prihvatanja kao i aktivnosti izveštavanja i upravljanja koje su kritične za kvalitet softvera.
2.2 Verifikacija
i validacija (Verification & Validation)12
Radi uproštenosti, verifikacija i validacija (V&V) se razmatraju kao jedna tema u ovom Vodiču, pre nego dve posebne teme kao u standardu (IEEE12207.0-96). „Softverska V&V predstavlja disciplinovan pristup procene softverskih proizvoda tokom životnog ciklusa proizvoda. Napori V&V teže obezbeđenju kvaliteta ugrađenog u softver kao i da softver ispunjava korisničke zahteve“ (IEEE1059-93). V&V se direktno odnosi na kvalitet proizvoda softvera i koristi tehnike testiranja koje mogu da lociraju defekte, tako da se oni mogu ispitati. Takođe ocenjuju i međuproizvode, i ipak, pri ovom kapacitetu, međukorake procesa životnog ciklusa proizvoda. Proces V&V određuje da li razvijeni proizvodi ili oni koji su dobijeni aktivnostima održavanja ispunjavaju zahteve koje je ta aktivnost trebalo da ispuni, i da li finalna verzija softvera ispunjava predviđenu svrhu i zahteve korisnika. Verifikacija je pokušaj obezbeđenja da je proizvod pravilno napravljen, u smislu da izlazni proizvodi aktivnosti ispunjavaju specifikacije date u prethodnim aktivnostima. Validacija predstavlja pokušaj da se obezbedi da je pravi proizvod napravljen, odnosno, da proizvod ispunjava svoju određenu svrhu. Oba procesa, i proces verifikacije i proces validacije, počinju u ranoj fazi razvoja ili fazi održavanja. Oni omogućavaju ispitivanje najvažnijih karakteristika proizvoda u odnosu na prethodni oblik proizvoda i specifikaciju koja mora da se zadovolji. Svrha planiranja V&V je da se obezbedi da je svaki resurs, uloga, kao i odgovornost jasno određena. Rezultujući plan V&V dokumentuje i opisuje različite resurse, njihove uloge 12
S.L. Pfleeger, Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001). Wallace and R.U. Fujii, “Software Verification and Validation: An Overview,” (May 1989), pp. 10-17.
30
D.R.
i aktivnosti, kao i tehnike i alate koji će biti korišćeni. Razumevanje različitih svrha svake od V&V aktivnosti pomoći će u pažljivom planiranju tehnika i resursa koji su potrebni da bi ispunili svoje svrhe. Standardi (IEEE1012-98:s7 and IEEE1059-93: Appendix A) određuju šta obično ide u V&V plan. Plan se, takođe, odnosi i na menadžment, komunikacije, politiku i procedure V&V aktivnosti i njihovu interakciju, kao i izveštavanje o defektima i zahtevima dokumentacije. 2.3 Pregledi
i revizije (Reviews and Audits)
Zbog svrhe kratkog prikaza, pregledi i revizije su posmatrane kao jedna tema u ovom Vodiču, u odnosu na dve posebne teme kao u (IEEE12207.096). Proces pregleda i revizije široko je definisan u (IEEE12207.0-96) i detaljnije u (IEEE1028-97). Pet tipova pregleda ili revizija su prikazani u IEEE1028-97 standardu: •
Revizije menadžmenta (Management reviews)
•
Tehničke revizije (Technical reviews)
•
Inspekcije (Inspections)
•
Pregledi (Walk-throughs)
•
Provere (Audits)
2.3.1
Revizije menadžmenta
„Svrha revizije menadžmenta je nadgledanje progresa, utvrđivanje statusa planova i rasporeda, potvrda zahteva i njihove alokacije, ili procena efektivnosti upravljačkog pristupa korišćenog za postizanje usklađivanja zbog svrhe“ [IEEE1028-97]. Oni podržavaju odluke o promenama i korektivnim akcijama koje su potrebne u toku softverskog projekta. Revizije menadžmenta određuju adekvatnost planova, rasporeda, zahteva i nadziru njihov progres ili nekonzistentnost. Ove revizije se mogu izvršavati nad proizvodima kao što su izveštaji revizije, izveštaji o progresu, V&V izveštaji, planovi više vrsta, koji uključuju menadžment rizika, projektni menadžment, menadžment konfiguracije softvera, bezbednost softvera i procenu rizika, između ostalih. 2.3.2. Tehničke revizije „Svrha tehničke revizije je da proceni softverski proizvod kako bi utvrdila da li je prikladan za nameravanu upotrebu. Cilj je utvrđivanje odstupanja od odobrene specifikacije i standarda. Rezultati bi trebalo da omoguće 31
menadžmentu dokaze o potvrdi (ili ne) da proizvodi odgovoraju specifikaciji i pridržavaju se standarda, i da su sve promene kontrolisane“ (IEEE102897). Specifične uloge se moraju utvrditi prilikom tehničke revizije: donosilac odluka, vođa revizije, zapisivač, i tehničko osoblje za podršku aktivnosti revizije. Tehnička revizija zahteva da se obavezni ulazi ispune kako bi se nastavilo: •
Izjava o ciljevima
•
Specifičan softverski proizvod
•
Poseban plan projektnog menadžmenta
•
Lista problema u vezi da ovim proizvodom
•
Procedura tehničke revizije
Tim prati proceduru revizije. Tehnički kvalifikovana osoba prikazuje pregled proizvoda i ispitivanje se sprovodi tokom jednog ili više sastanaka. Tehnička revizija je završena kada se sve aktivnosti koje su navedene u ispitivanju završe. 2.3.3
Inspekcije13
„Svrha inspekcije je da otkrije i identifikuje anomalije softverskog proizvoda“ (IEEE1028-97). Dve značajne razlike inspekcije od revizije su naredne: 1. Individua koja je pretpostavljena bilo kom od članova tima za inspekciju ne bi trebalo da učestvije u inspekciji. 2.
Inspekciju bi trebalo da vodi nepristrasan moderator koja je obučen da vrši inspekciju. Inspekcije softvera uvek uključuju autora međuproizvoda ili finalnog proizvoda, dok kod ostalih revizija to ne mora da bude slučaj. Inspekcija, takođe, uključuje vođu, snimatelja, čitača, i nekoliko (2 do 5) inspektora. Članovi tima inspekcije mogu posedovati različita ekspertna znanja, kao što su poznavanje oblasti, ekspertiza metode dizajniranja ili ekspertizu jezika. Inspekcija se obično sprovodi na jednom relativno malom broju proizvoda, istovremeno. Svaki član tima mora da ispita softverski proizvod i druge ulaze za reviziju prioritetne za sastanak revizije, možda primenjujući analitičku tehniku na malom delu proizvoda, ili na celom proizvodu sa fokusom na samo jednom aspektu, na primer, interfejsu. Bilo koja otkrivena anomalija se dokumentuje i šalje vođi
13
T. Gilb and D. Graham, Software Inspections, (Addison-Wesley, 1993). Radice, High Quality Low Cost Software Inspections, (Paradoxicon, 2002), p. 479.
32
R.
inspekcije. Tokom inspekcije, vođa sprovodi sesiju i verifikuje da su svi spremni za inspekciju. Lista, sa anomalijama i pitanjima povezanim sa problemima od interesa, je uobičajen alat koji se koristi u inspekcijama. Rezultujuća lista često klasifikuje anomalije (više u IEEE1044-93) i razmatrana je njena potpunost i tačnost od strane tima. Izlazne odluke inspekcije moraju da odgovaraju jednom od tri naredna kriterijuma: 1. Prihvatanje bez ili sa najmanjim prepravkama 2. Prihvatanje sa verifikacijom prepravki 3. Ponovna inspekcija Sastanci inspekcije obično traju nekoliko sati, dok tehničke revizije i provere obično su opštije i traju duže. 2.3.4 Pregledi (Walk-throughs ) „Svrha pregleda je ocena softverskog proizvoda. On se može sprovesti za svrhu edukovanja publike o softverskom proizvodu.“ (IEEE1028-97) Glavni ciljevi su [IEEE1028-97]: •
Nalaženje anomalija
•
Unapređenje softverskog proizvoda
•
Razmatranja alternativnih implementacija
•
Ocena saglasnosti prema standardima i specifikacijama
Pregled je sličan inspekciji ali se obično smatra za manje formalan način. Prezentacija se primarno organizuje od strane softverskog inženjera kako bi dao svojim članovima tima šansu da izvrše reviziju njegovog rada, kao tehnika uverenja. 2.3.5 Provere „Svrha softverske provere je obezbeđivanje nezavisne procene usklađenosti softverskih proizvoda i procesa u odnosu na primenljive regulacije, standarde, smernice, planove i procedure“ [IEEE1028-97]. Provera je formalno organizovana aktivnost, gde učesnici imaju specifične uloge, kao što su glavni revizor, pomoćni revizor, snimatelj, ili inicijator, i uključuju predstavnika organizacije u kojoj se vrši provera. Provera će identifikovati sve slučajeve odstupanja i kao rezultat toga dati izveštaj u kome se zahteva od tima da sprovedu korektivne akcije. Iako postoji dosta formalnih naziva za revizije i preglede, kao oni koji su navedeni u standardu (IEEE1028-97), značajno je da ona mogu da se pojave za skoro bilo koji proizvod na bilo kojoj fazi razvoja ili procesa održavanja.
33
3. Praktična razmatranja 3.1.
Zahtevi kvaliteta softvera (Software Quality Requirements)14
3.1.1.
Faktori uticaja (Influence factors)
Različiti faktori utiču na planiranje, menadžment i selekciju SQM aktivnosti i tehnika, uključujući: •
•
•
•
•
•
Domeni sistema u kojem će se nalaziti softver (sigurnosno-kritični, kritični u odnosu na misiju, poslovno-kritični) Sistemski i softverski zahtevi Komercijalne (eksterne) ili standardne (interne) komponente koje će se koristiti u sistemu Primena specifičnih standarda softverskog inženjerstva Metode i softverski alati koji će se koristiti za razvoj i održavanje, kao i za ocenjivanje kvaliteta i poboljšanja Budžet, osoblje, organizacija projekta, planovi i raspored svih procesa
•
Namenjeni korisnici i upotreba sistema
•
Nivo integrisanosti sistema
Informacije o uticajima ovih faktoria na to kako su SQM procesi organizovani i dokumentovani, kako se biraju specifične SQM aktivnosti, koji su resursi potrebni i koji će pomerati granice napora. 3.1.2 Zavisnost U slučajevima kada sistemski otkazi mogu imati izuzetno ozbiljne posledice, ukupna pouzdanost (hardver, softver i ljudi) je osnovni zahtev kvaliteta iznad osnovne funkcionalnosti. Softverska zavisnost uključuje i takve karakteristike kao što su tolerancija na greške, sigurnost, bezbednost, i upotrebljivost. Pouzdanost je takođe i kriterijum koji se može definisati terminima zavisnosti (ISO9126). Literarno telo za sisteme mora biti jako zavisno („visoko poverenje“ ili „sistemi visokog integriteta“). Terminologija za tradicionalne mehaničke i električne sisteme koji mogu da ne uključuju softvere, uvedena je zbog diskusija o pretnjama ili hazardima, rizicima, integritu sistema i povezanih koncepata.
14
J. W. Horch, Practical Guide to Software Quality Management , (Artech House Publishers, 2003). Lewis, Independent Verification and Validation: A Life Cycle Engineering Process for Quality Software, (John Wiley & Sons, 1992).
34
R.O.
3.1.3 Nivoi integriteta softvera Nivo integriteta softvera se određuje na osnovu mogućih posledica otkaza softvera i verovatnoće otkaza. Za softver u kojem je važna sigurnost ili bezbednost, tehnike kao što je analiza hazarda za bezbednost ili analiza pretnji za sigurnost, mogu se koristiti za razvoj plana aktivnosti, koji će identifikovati gde se nalazi tačka potencijalnih problema. Istorija neuspeha sličnog softvera takođe može pomoći u identifikovanju koje tehnike će biti najkorisnije u otkrivanju defekata i procenjivanju kvaliteta. Nivoi integriteta (na primer, gradacija integriteta) su predloženi u (IEEE1012-98). 3.2 Karakterizacija defekata (Defect Characterization)15
SQM procesi pronalaze defekte. Karakterizacija tih nedostataka vodi do razumevanja proizvoda, olakšava korekcije na procesu ili proizvodu, i informiše projektni menadžment ili kupce o statusu procesa ili proizvoda. Postoje mnoge taksonomije za defekate (nedostatke), i iako su izvršeni pokušaji da se dobije konsenzus o taksonomiji otkaza i defekata, literatura ukazuje da postoji dosta termina u upotrebi. Karakterizacija defekta (anomalija) se takođe koristi u revizijama i pregledima gde vođa revizije često prezentuje listu anomalija dobijenih od članova tima radi razmatranja, na sastancima revizije. Kako nove metode dizajna i jezika evoluiraju, uz napredak opšte softverske tehnologije, nove vrste defekata se pojavljuju i mnogo truda je potrebno za interpretiranje prethodno definisanih klasa. Kada se prate defekti, softverski inženjer se interesuje ne samo za broj defekata, već i za tip. Informacija sama, bez neke klasifikacije, i nije od neke koristi u utvrđivanju osnovnih uzroka defekata, jer bi određene vrste problema trebalo da budu grupisane zajedno kako bi se donele odluke o njima. Suština je da se uspostavi taksonomija defekata, koja je od značaja za samu organizaciju i za softverske inženjere. SQM otkriva informacije na svim fazama softverskog razvoja i održavanja. Tipično, gde je upotrebljena reč „defekat“, odnosi se na „nedostatak“ kao što je definisano ispod. Ipak, različite kulture i standardi mogu upotrebljavati nešto drugačija značenja ovih termina, što vodi pokušaju da se definišu. Delimične definicije uzete iz standarda (IEEE610.12-90) su: •
Greška (Error): “Razlika….između izračunatog rezultata i tačnog rezultata”
15
M.A. Friedman and J.M. Voas, Software Assessment: Reliability, Safety Testability, (John Wiley & Sons, 1995). Handbook of Usability Testing: How to Plan, Design, and Conduct Effective Tests, (John Wiley & Sons, 1994).
35
J. Rubin,
•
Defekat (Fault): “Pogrešan korak, proces ili definicija podataka u kompjuterskom programu”
•
Otkaz (Failure): “[netačan] rezultat nastao na osnovu defekta”
•
Pogreška (Mistake): “Ljudska akcija koja proizvodi netačan rezultat”
Otkazi otkriveni u testiranju kao rezultat softverskih defekata su uključeni kao neuspesi u diskusiji u ovom delu. Modeli pouzdanosti su izgrađeni od podataka o otkazima prikupljenih tokom testiranja softvera ili iz softvera tokom primene, i prema tome, mogu se koristiti za predviđanje budućih otkaza i kao pomoć u odlukama o tome kada zaustaviti testiranje. Jedna moguća akcija koja proizilazi iz otkrića SQM-a, je uklanjanje nedostataka iz proizvoda pod ispitivanjem. Ostale akcije omogućavaju dostizanje pune vrednosti iz nalaza SQM aktivnosti. Te radnje uključuju analizu i sumiranje nalaza, i korišćenje tehnika merenja kako bi se poboljšao proizvod i procesa, kao i praćenje nedostataka i njihovo uklanjanje. Unapređenje procesa se primarno razmatra u oblasti znanja procesa softverskog inženjeringa, gde je SQM bio izvor informacija. Podaci o neadekvatnostima i nedostacima pronađenim tokom implementacije SQM tehnika mogu biti izgubljeni, osim ukoliko nisu snimljeni. Za neke tehnike (na primer, tehničke preglede, revizije, inspekcije), zapisničari su prisutni da evidentiraju takve informacije, zajedno sa pitanjima i odlukama. Kada se koriste automatizovani alati, izlazi alata mogu pružiti informacije o nedostacima. Podaci o nedostacima mogu se prikupiti i snimiti na u formi SCR-a (software change request) i mogu se naknadno uneti u neki tip baze podataka, bilo ručno ili automatski, iz alata analize. Izveštaji o nedostacima su obezbeđeni za menadžment organizacije. 3.3 Menadžment
tehnike kvaliteta Management Techniques)16
softvera
(Software
Quality
SQM tehnike se mogu kategorizovati na više načina: statičke, ljudskiintenzivne (people-intensive), analitičke, dinamičke. 3.3.1 Statičke tehnike ( Static techniques) Statičke tehnike uključuju ispitivanje projektne dokumentacije i softvera, i druge informacije o softverskim proizvodima, bez njihovog izvršavanja. Ove tehnike mogu da uključuju ljudski-intenzivne aktivnosti ili analitičke aktivnosti sprovedene od strane pojedinaca, sa ili bez pomoći automatizovanih alata. 16
V.R. Basili and D.M. Weiss, “A Methodology for Collecting Valid Software Engineering Data,” (November 1984), pp. 728-738. R. Chillarege, “Orthogonal Defect Classification,” ( M. Lyu, ed., IEEE Computer Society Press, 1996). S.D. Conte, H.E. Dunsmore, and V.Y. Shen, ( The Benjamin Cummings Publishing Company, 1986). M.V. Zelkowitz and D.R. Wallace, “ Experimental Models for Validating Technology” , ( 1998), pp. 23-31.
36
3.3.2 Ljudski-intenzivne tehnike ( people-intensive techniques ) Podešavanja za ove tehnike, uključujući preglede i revizije, mogu da variraju od formalnog sastanka do neformalnog sastanka, ali (obično) je uključeno dvoje ili više ljudi. Može biti neophodna priprema unapred. Resursi osim onih pod ispitivanjem mogu uključivati liste i rezultate iz analitičkih tehnika i testiranja. O ovim aktivnostima se govori u (IEEE102897) pri pregledima i revizijama. 3.3.3 Analitičke tehnike (Analytical techniques) Softverski inženjeri obično primenjuju analitičke tehnike. Ponekad nekoliko softverskih inženjera koristi istu tehniku, ali je svaki primenjuje na različit deo proizvoda. Neke tehnike su vođene alatom (tool-driven); druge su manualne. Neke mogu direktno da nađu nedostatke, ali se obično koriste kao podrška drugim tehnikama. Neke, takođe, uključuju različite procene kao deo opšte analize kvaliteta. Primeri ovakvih tehnika uključuju analizu kompleksnosti, analizu kontrolnog toka i algoritamsku analizu. Svaki tip analize ima specifičnu svrhu, i ne primenjuju se svi tipovi na svaki projekat. Primer tehnike podrške je analiza kompleksnosti, koja je korisna za utvrđivanje da li je dizajn ili implementacija suviše kompleksna da bi se mogla pravilno razviti, testirati ili održavati. Rezultati analize kompleksnosti takođe se mogu koristiti u razvoju slučajeva testa. Tehnike za pronalaženje nedostataka, kao što je analiza kontrolnog toka, mogu se koristiti kao podrška drugoj aktivnosti. Za softvere sa puno algoritama značajna je analiza algoritama, posebno kada bi netačan algoritam mogao da izazove katastrofalan rezultat. Postoji previše analitičkih tehnika da bi ih prikazali ovde. Drugi, više formalni, tipovi analitičkih tehnika poznati su kao formalne metode. Oni se koriste za verifikaciju softverskih zahteva i dizajna. Dokaz o ispravnosti primenjuje se na kritične delove softvera. Uglavnom su korišćeni pri verifikaciji krucijalnih delova kritičnog sistema, kao što su posebni bezbednosni i sigurnosni zahtevi. 3.3.4 Dinamičke tehnike (Dynamic techniques) Različite vrste dinamičkih tehnika se izvršavaju tokom razvoja i održavanja softvera. Generalno, ovo su tehnike testiranja, ali tehnike kao što je simulacija, provera modela i simboličko izvršavanje mogu se smatrati dinamičkim. Čitanje koda se smatra statičkom tehnikom, ali iskusni softverski inženjeri mogu izvršavati kod dok ga čitaju. U tom smislu, čitanje koda se može smatrati i dinamičkom tehnikom. Ova protivrečnost u kategorizaciji ukazuje da ljudi sa različitim ulogama u organizaciji mogu na drugačiji način razmatrati i primenjivati ove tehnike. Prema tome, neki 37
testovi se mogu izvršiti u procesu razvoja, SQA procesu, ili V&V procesu, što opet zavisi od organizacije projekta. Zato što se SQM planovi odnose na testiranje, ovaj odeljak uključuje i neke komentare u vezi sa testiranjem. Oblast znanja testiranja softvera obezbeđuje raspravsu i tehničke reference za teoriju, tehnike za testiranje i automatizaciju.
3.3.5
Testiranje (Testing)
Proces uveravanja opisan u SQA i V&V ispituje svaki izlaz bitan za specifikaciju softverskih zahteva kako bi se obezbedilo da se izlazi mogu pratiti, kao i njihova konzistencija, kompletnost, ispravnost i performanse. Ova potvrda, takođe, uključuje izlaze razvojnog procesa i procesa održavanja, prikupljanja, analize i merenja rezultata. SQA obezbeđuje da su prikladni tipovi testova planirani, razvijeni i implementirani, dok V&V razvija planove testa, strategije, slučajeve i procesure. Testiranje se detaljno razmatra u oblasti znanja softverskog testiranja. Dva tipa testiranja mogu pripadati naslovima SQA i V&V, zbog svoje odgovornosti za kvalitet i materijala korišćenih u projektu: •
•
Evaluacija i test alata koji će se koristiti na projektu (IEEE1462-98) Test usaglašenosti (conformance test) komponenti i COTS proizvoda koji će biti upotrebljeni u proizvodu; sada postoji standard za softverske pakete (IEEE1465-98)
Ponekad se traži da nezavisna V&V organizacija nadgleda proces testiranja i ponekad svedoči pravom izvršavanju kako bi se obezbedilo da je proces sproveden u skladu sa određenim procedurama. V&V se može zatražiti za procenu samog testiranja: adekvatnosti planova i procedura, adekvatnosti i tačnosti rezultata. Drugi tip testiranja koji može pripadati naslovu organizacije V&V je testiranje treće strane (third-party). Treća strana nije programer, niti je na bilo koji način u vezi sa razvojem proizvoda. Umesto toga, treća strana je nezavisna ustanova, obično akreditovana od strane nekog zakonodavnog tela. Njena svrha je da testira proizvod radi potvrde specifičnog skupa zahteva. 3.4 Merenja kvaliteta softvera (Software Quality Measurement)17 17
R.B. Grady, Practical Software Metrics for Project Management and Process Management , (Prentice Hall, 1992).
38
Modeli kvaliteta proizvoda softvera često uključuju merenja kako bi se utvrdio stepen svake karakteristike kvaliteta dostignutog u proizvodu. Ukoliko su pravilno izabrane, merenja mogu da podrže kvalitet softvera (među ostalim aspektima procesa životnog ciklusa softvera) na više načina. Mogu pomoći i u procesu donošenja odluka. Mogu naći problematične oblasti i uska grla u softverskom procesu; i mogu pomoći softverskim inženjerima da procene kvalitet svog rada za SQA svrhe i za proces dugoročnog unapređenja kvaliteta. Uz povećavanje sofisticiranosti softvera, pitanja kvaliteta idu izvan toga da li ili ne radi softver, i koliko dobro ispunjava merljive ciljeve kvaliteta. Postoji još nekoliko tema u kojima merenje direktno podržava SQM. One uključuju pomoć pri odlučivanju kada zaustaviti testiranje. Za ovo su korisni modeli i merila pouzdanosti, uz upotrebu podataka o kvarovima i otkazima. Troškovi SQM procesa predstavljaju pitanje koje se skoro uvek postavlja prilikom odlučivanja kako će se organizovati projekat. Često, koriste se opšti modeli troškova koji su bazirani na tome kada se nalazi nedostatak i koliko napora je potrebno da se popravi nedostatak nalaženja problema ranije u procesu razvoja. Podaci projekta mogu dati bolju sliku o troškovima. Informacije u vezi sa tim, mogu se naći u procesu softverskog inženjeringa i oblastima znanja menadžmenta softverskog inženjeringa (Software Engineering Process i Software Engineering Management KAs.) Na kraju, SQM izveštaji obezbeđuju vredne informacije ne samo o tim procesima, već i o tome kako se može unaprediti proces životnog ciklusa softvera. Dok merenja za karakteristike kvaliteta i crta proizvoda mogu biti od koristi i na njima samima (na primer, broj zahteva nedostataka ili proporcija zahteva nedostataka), matematičke i grafičke tehnike se mogu primeniti kao pomoć u interpretaciji merenja. One spadaju pod naredne kategorije: •
Statistički bazirane (na primer, Pareto analiza, tačkasti dijagrami, normalna raspodela)
•
Statistički testovi (na primer, binomni test, hi-kvadrat test)
•
Analiza trenda
•
Predviđanja (na primer, modeli pouzdanosti)
Tehnike sa statističkom osnovom i testovi često pružaju prikaz više problematičnih oblasti od softverskog proizvoda pod ispitivanjem. Rezultujući grafikoni su vizualna pomagala koja donosioci odluka koriste za 39
usmeravanje resursa gde su najpotrebniji. Rezultati analize trenda mogu da ukazuju da nije ispoštovan raspored, kao što je testiranje, ili da određene klase defekta postaju intenzivnije ukoliko se ne sprovedu korektivne akcije u razvoju. Tehnike predviđanja pomažu u planiranju vremena testa kao i u predviđanju otkaza. Veliki broj diskusija na tu temu mogu se naći u procesu softverskog inženjeringa i oblastima znanja menadžmenta softverskog inženjeringa (Software Engineering Process i Software Engineering Management KAs. Više informacija o merenjima testova predstavljeno je u oblasti znanja testiranja softvera. Reference18 obezbeđuju diskusiju o analizi defekta, koja se sastoji od merenja nastajanja defekata, i zatim primene statističkih metoda kako bi se razumeli tipovi defekata koji se najčešće pojavljuju, odnosno, odgovara se na pitanje u cilju ocene njihove gustine. Takođe pomažu pri razumevanju trendova i toga koliko dobro rade tehnike, kao i kako napreduje razvoj i održavanje procesa. Merenja pokrivenosti testa pomažu u proceni koliko preostaje napora da se izvrši, i predviđaju se mogući nedostaci koji će ostati. Za ove metode merenja, mogu se razviti profili nedostataka za određenu oblast aplikacije. Tada, za naredni softverski sistem u okviru organizacije, profili se mogu koristiti za vođenje SQM procesa, odnosno, za proširenje napora na mestima gde je najverovatnije da će problemi nastati. Slično tome, benchmark, ili brojanje grešaka tipičnih za tu oblast, može služiti kao jedna od pomoći u utvrđivanju kada je proizvod spreman za isporuku. Diskusija o upotrebi podataka iz SQM-a radi procesa unapređenja razvoja i održavanja pojavljuje se u menažmentu softverskog inženjerstva i oblastima znanja procesa softverskog inženjerstva (Software Engineering Management i Software Engineering Process KAs).
18
N.E. Fenton and S.L. Pfleeger, Software Metrics: A Rigorous & Practical Approach, (second ed., International Thomson Computer Press, 1998). C. Jones and J. Capers, Applied Software Measurement: Assuring Productivity and Quality, (second ed., McGraw-Hill, 1996). S.H. Kan, Metrics and Models in Software Quality Engineering , (second ed., Addison-Wesley, 2002). S.L. Pfleeger, Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001).
40
Zaključak
Testiranje softvera predstavlja važnu komponentu razvoja aplikacija. Nedostatak strukturiranog i definisanog procesa testiranja može da dovede do visokih troškova ispravljanja koda, probijanja budžeta i nezadovoljnih klijenata. Takođe, sistematično testiranje pomaže u smanjenju rizika i povećanju stepena kontrole. Testiranje softvera je umetnost. Većina metoda testiranja nisu mnogo drugačije od pre dvadeset godina. Te tehnike nisu još zrele iako postoji mnogo dostupnih alata i tehnika za korišćenje. Kvalitetan proces testiranja takođe zahteva kreativnost, iskustvo i intuiciju, uz odgovarajuće tehnike. Testiranje softvera je više nego samo otklanjanje grešaka. Testiranje se ne koristi samo da pronađe defekte i ispravi ih. Takođe se koristi u procesu validacije i verifikacije, i u merenju pouzdanosti. Testiranje se izvodi u svim fazama životnog ciklusa softvera i mogu se testirati gotova programska rešenja ili samo pojedine komponente. Testiranje je skupo. Automatizacija je dobar način da se smanje troškovi i vreme. Efikasnost i efektivnost testiranja predstavlja kriterijum za tehnike testiranja bazirane na pokrivenosti koda. Kompletno testiranje je neizvodljivo. Kompleksnost je koren problema. U nekom trenutku proces testiranja se mora zaustaviti i proizvod mora biti isporučen. Vreme i budžet odlučuju kad će se proces testiranja završiti, ili ukoliko procena pouzdanosti softvera zadovoljava zahteve. Testiranje softvera možda nije najefikasniji metod poboljšanja kvaliteta softvera i neke alternativne metode su možda čak i bolje. Nije moguće dokazati da je softver bez grešaka ali se broj tih grešaka može svesti na minimum.
41
