Testiranje softvera

Uvod Testiranje je aktivnost koja se izvodi identifikacijom defekata i problema radi procene kvaliteta proizvoda, kao i za njegovo unapreenje. Testiranje softvera se sastoji iz dinamike verifikacije ponaanja programa na konanom skupu testiranja, pogodno selektovanog iz uglavnom beskonanih podruja izvravanja, u odnosu na oekivano ponaanje. U gore navedenoj definiciji, rei napisane ukoso odgovaraju kljunim problemima identifikacije oblasti znanja softverskog testiranja. Pojedinano: Dinamiko: Ovaj termin znai da testiranje uvek podrazumeva izvravanje programa na (validnim) ulazima. Preciznije, sama vrednost ulaza nije uvek dovoljna za odreivanje testa, jer kompleksan, nedeterministiki sistem moe da reaguje na isti ulaz razliitim ponaanjem, u zavisnosti od stanja sistema. U ovoj oblasti znanja, ipak, odrae se termin ulaz, uz podrazumevanje da njegovo znaenje ukljuuje i posebno stanje ulaza, u onim sluajevima u kojima je potrebno. Razliite od testiranja i njemu komplementarne su statistike tehnike. Konano: ak i u jednostavnijim programima, veliki broj skupova testiranja je mogu pa bi se iscrpni testovi izvravali mesecima ili godinama do zavretka. Zbog toga se generalno itav skup za testiranje moe posmatrati kao konaan. Testiranje uvek podrazumeva kompromis izmeu ogranienih resursa i vremenskog rasporeda u odnosu na sutinski neograniene zahteve testa. Selektovano: Razlikuje se veliki broj ponuenih tehnika testiranja, pre svega u tome kako se vri selekcija skupa za testiranje. Softverski inenjeri moraju biti svesni da razliiti kriterijumi selekcije mogu da proizvedu veoma razliite stepene efikasnosi. Kako izabrati najpogodniji kriterijum selekcije u odnosu na date uslove predstavlja veoma kompleksan problem; u praksi, moraju se primeniti tehnike analize rizika kao i strunost inenjera. Oekivano: Mora biti mogue, iako nije uvek lako, odluiti da li su posmatrani ishodi izvrenog programa prihvatljivi ili ne, u suprotnom testiranje bi bilo beskorisno. Posmatrano ponaanje se moe ispitati u odnosu na oekivanja korisnika (to se obino naziva testiranje validacije),
1

u odnosi na specifikaciju (testiranje verifikacije), ili, na kraju, u odnosu na oekivano ponaanje iz implicitnih zahteva ili razumnih oekivanja. Pogled testiranja softvera evoluirao je ka vie konstruktivnom. Testiranje se vie ne vidi kao aktivnost koja poinje samo kada je zavrena faza kodiranja, sa ogranienom svrhom otkrivanja greaka. Sada se na testiranje softvera gleda kao na aktivnost koja bi trebalo da prati itav proces razvoja i odravanja, i kao takva je zanaajan deo konstrukcije proizvoda. Zaista, planiranje testiranja bi trebalo poeti u ranim fazama procesa ispitivanja, planovi testiranja i procedure moraju se sistematski i u kontinuitetu razvijati, i preraivati, kako razvoj odmie. Ove aktivnosti planiranja i dizajniranja same predstavljaju koristan ulaz za dizajnere isticanjem potencijalnih slabosti (kao to su propusti u dizajnu ili kontradiktornosti, kao i propusti i dvosmislenosti u dokumentaciji). Sada se smatra da je pravi stav ka kvalitetu jedna od prevencija: Oigledno je mnogo bolje izbei probleme nego ih ispravljati. Tada se testiranje mora videti kao primarno sredstvo za proveru ne samo efektivnosti prevencije, ve i za identifikovanje greaka u onim sluajevima gde, iz nekog razloga, nije bilo efektivno. Moda je oigledno, ali vredno napomene, da ak i posle uspenog zavretka obimnog testiranja, softver i dalje moe sadrati greke. Lek za softverske greke nakon isporuke je obezbeivanje korektivnih akcija odravanja. U softverskom kvalitetu (Software Quality Management Techniques), tehnike upravljanja softverskim kvalitetom kategorisane su u statike tehnike (bez izvravanja koda) i dinamike tehnike (izvravanje koda). Obe kategorije su korisne. Ova oblast znanja se fokusira na dinamike tehnike. Testiranje softvera je povezano i sa softverskom konstrukcijom (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 softverskog testiranja (Software Testing Fundamentals). Ona pokriva osnovne definicije u oblasti testiranja softvera, osnovnu terminologiju i kljuna pitanja, kao i njenu vezu sa drugim aktivnostima. Druga podoblast, Nivoi testiranja (Test Levels), sainjena je iz dve (ortogonalne) teme: 2.1 prikazuje nivoe u kojima je testiranje velikih softvera tradicionalno podeljeno; i 2.2 razmatra testiranje za posebne
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 mogui tip naveden. Cilj testiranja i objekat testiranja zajedno utvruju kako se identifikuje skup testiranja, obazirui se na konzistenciju koliko testiranja je dovoljno za postizanje eljenog cilja i svoju kompoziciju koje sluajeve testa bi trebalo selektovati za postizanje eljenog cilja. Kriterijumi za prvo pitanje se nazivaju kriterijumi adekvatnosti testa, dok se oni koji se odnose na drugo pitanje nazivaju kriterijumi selekcije testa. Vie tehnika za testiranje (test techniques) je razvijeno proteklih nekoliko decenija, i dalje se predlau nove. Opte prihvaene tehnike su pokrivene u podoblasti 3. Mere u vezi sa testom (Test-related Measures) su razmotrene u podoblasti 4. Na kraju, problemi sa procesom testa (Test 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.

Terminologija vezana za testiranje (Testing-related terminology)

1.1.1. Definicije testiranja i povezana terminologija1

Sveobuhvatan uvod u oblast znanja softverskog testiranja data je u preporuenim referencama.

1.1.2. Greke nasuprot neuspehu

Mnogo termina u literaturi softverskog inenjeringa se koristi da bi se opisala greka u radu, kao to su termini defekt (fault), otkaz (failure), greka (error) i drugi. Ova terminologija se precizno definie u IEEE Standardu 610.12-1990, standardnom reniku terminologije softverskog inenjeringa (IEEE610-90), i takoe je razmatrana u oblasti znanja softverskog kvaliteta. Bitno je napraviti jasnu razliku izmeu uzroka greke, za koji e se ovde koristiti termin nedostatak ili defekat (defect), i neeljenog efekta posmatranog u sistemu isporuke, koji e se nazivati otkaz. Testiranje moe otkriti otkaze, ali defekti su ti koji se mogu i moraju ukloniti. Ipak, trebalo bi prihvatiti da uzrok otkaza ne moe uvek biti nedvosmisleno utvren. Ne postoje teoretski kriterijumi kojima bi se definitivno odredilo koji je nedostatak izazvao posmatrani neuspeh. Moe se rei 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 preferiraju da govore o ulazima koji izazivaju otkaze (failure-causing inputs), a ne o manama odnosno o onom skupu ulaza koji utie na pojavu otkaza.

1.2.
1

Kljuna pitanja (Key issues)2

B. Beizer, Software Testing Techniques, (International Thomson Press, 1990), Chaps. 1. P. C. Jorgensen, Software Testing: A Craftsman's 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 Methods for Software Testing, (John Wiley & Sons, 1995), Chap. 1. S. L. Pfleeger, Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001), Chap. 8.
2

B. Beizer, Software Testing Techniques, (International Thomson Press, 1990), Chaps. 3, 13.

1.2.1. Kriterijum selekcije testa/Kriterijum adekvatnosti testa (ili pravila

zaustavljanja) Kriterijum selekcije testa (Test selection criterion) je sredstvo za odluivanje koji je prikladan skup testova. Kriterijum selekcije se moe koristiti za izbor test sluajeva ili za proveru da li je odabran paket testa adekvatan odnosno, za odluivanje da li se testiranje moe zaustaviti.
1.2.2. Efektivnost testiranja (Testing effectiveness) /Ciljevi testiranja

Testiranje je opservacija uzorka programskih izvravanja. Selekcija uzorka moe biti voena razliitim ciljevima: da li se efektivnost testa moe proceniti zavisi od cilja koji se sledi.
1.2.3. Testiranje

radi identification)

identifikacije

defekata

(Testing

for

defect

U testiranju radi identifikacije defekta, uspean test je onaj koji izaziva neuspean rad sistema. Ovo je razliito u odnosu na testiranje radi demonstracije da softver ispunjava specifikacije ili druge eljene karakteristike, u ijem sluaju je testiranje uspeno ukoliko se ne zabelee (znaajni) neuspesi.
1.2.4. Problem predskazivanja (The oracle problem)

Predskaziva je bilo koji (ljudski ili mehaniki) izvrilac koji odluuje da li se program ponaao u skladu sa testom, i prema tome stvara presudu o prolasku ili neuspehu. Postoji veliki broj razliitih vrsta predskazivaa, i automatizacija moe biti jako teka i skupa.
1.2.5. Teoretska i praktina ogranienja testiranja

Teoretsko testiranje nas upozorava na nejednak nivo poverenja serija testova. Na alost, veina utvrenih 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 moe biti upotrebljeno da pokae prisustvo bagova, ali nikada da pokae 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. H. Zhu, W. C. Kaner,

mora biti sprovedeno zasnovano na rizicima i moe biti posmatrano kao strategija menadmenta rizika.
1.2.6. Problem nedostinih putanja (Theoretical and practical limitations

of testing) Neizvrive 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 izvoenju ulaza testa za tehnike testiranja bazirane na kodu.
1.2.7. Mogunost testiranja (Testability)

Termin software testability ima dva vezana, ali razliita znaenja: u jednom sluaju, odnosi se na stepen do kojeg je softveru lako da ispuni dati kriterijum pokrivenosti testa kao u (Bac90), u drugom sluaju, definisan je kao mogunost i verovatnoa merena statistiki, da e softver otkriti otkaze pod testiranjem, ukoliko su zaista defekti, kao u (Voa95, Ber96a). Oba znaenja su vana.
1.3.

Veze testiranja sa drugim aktivnostima (Relationships of testing to other activities)

Testiranje softvera je povezano, ali ujedno i razliito od statinih tehnika menadmenta softverskog kvaliteta (software quality management techniques), dokaza korektnosti (proofs of correctness), debugging-a i samog programiranja. Ipak, informativno je razmatrati testiranje sa take gledita analize kvaliteta softvera i sertifikata.

2. Nivoi testiranja (Test levels)3 2.1.

Cilj testa (The target of the test)

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.

Testiranje softvera se obino izvrava na razliitim nivoima tokom razvoja i odravanja procesa. Odnosno, cilj testiranja moe da varira: jedan modul, grupa takvih modula (povezanih svrhom, upotrebom, ponaanjem 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 vei znaaj 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 vee komponente napravljene od usko vezanih jedinica. Test jedinica je preciznije definisana u IEEE Standard for Software Unit Testing (IEEE1008-87), koji takoe opisuje integrisani pristup sistematskog i dokumentovanog testiranja jedinice. Obino, testiranje jedinice nastaje sa pristupom kodu koji se testira i uz pomo debugging alata, i moe da ukljuuje programere koji su napisali kod.
2.1.2. Testiranje integracije (Integration tetsing)

Testiranje integracije je proces verifikacije interakcije izmeu komponenti softvera. Klasine 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 voene arhitekturom, to navodi na integraciju komponenti softvera ili podsistema baziranih na identifikovanim funkcionalnim temama. Testiranje integracije je kontinualna aktivnost, na svakoj fazi softverski inenjeri moraju izdvojiti perspektive niih nivoa i koncentrisati se na perspektive nivoa koji integriu. Osim za male, jednostavne softvere, sistematske, inkrementalne integracione strategije testiranja se obino preferiraju stavljanjem svih komponenti zajedno, to se slikovito zove big bang testiranje.
2.1.3. Testiranje sistema (System testing)

Testiranje sistema se razmatra uz ponaanje itavog sistema. Veina funkcionalnih greaka ve bi trebalo da su identifikovane tokom testiranja jedinice i integracije. Testiranje sistema se obino smatra prikladnim za poreenje sistema i ne-funkcionalnih sistemskih zahteva, kao to su bezbednost, brzina, tanost, i pouzdanost. Eksterni interfejsi prema drugim aplikacijama, uslunim programima, hardverskim ureajima ili operativnom okruenju, takoe su procenjeni na ovom nivou.
7

2.2.

Ciljevi testiranja (Objectives of Testing)

Testiranje se izvrava pri odreenim ciljevima, koji su manje ili vie eksplicitno izraeni, i sa varirajuim stepenima preciznosti. Postavljanje ciljeva precizno, kvantitativnim terminima, omoguava da kontrola bude ustanovljena tokom procesa testiranja. Testiranje moe biti namenjeno za verifikaciju razliitih osobina. Sluajevi testa se mogu osmisliti kako bi proverili da li su funkcionalne specifikacije tano implementirane, to se u raznim sluajevima u literaturi naziva testiranje usaglaenosti (conformance testing), korektnosti (correctness), ili funkcionalno (functional) testiranje. Ipak, nekoliko drugih nefunkcionalnih osobina se mogu testirati, ukljuujui performanse, pouzdanost, i korisnost, pored ostalih. Drugi znaajni ciljevi za testiranje ukljuuju (ali nisu ogranieni na) merenje pouzdanosti, procenu korisnosti i prihvatanja, za koje bi trebalo primeniti razliite pristupe. Moe se zapaziti da objekat testa varira sa ciljem testa; uopteno, razliite svrhe se ispunjavaju razliitim nivoom testiranja. Neke vrste testiranja su prikladnije za softverske pakete pravljene po meri, testiranje instalacija (installation), na primer; i druge generike proizvode, kao beta (beta) testiranje.
2.2.1. Testiranje prihvatanja/kvalifikacije (Acceptance/qualification

testing) Testiranje prihvatanja proverava ponaanje sistema u osnosu na zahteve kupaca, bez obzira na to kako su izraeni; kupci preduzimaju ili odreuju tipine zadatke kako bi proverili da su njihovi zahtevi zadovoljeni ili da je organizacija identifikovala njih za ciljno trite softvera. Ova aktivnost testiranja moe ali ne mora ukljuivati one koji razvijaju sistem.

2.2.2. Testiranje instalacije (Installation testing)

Nakon kompletiranja testiranja softvera i prihvatljivosti softver se moe verifikovati u odnosu na instalaciju u ciljnoj sredini. Testiranje instalacije moe se posmatrati kao sistemsko testiranje izvoeno jo jednom prema zahtevima hardverske konfiguracije. Procedure instalacije mogu, takoe, 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 izvetavaju o problemima sa proizvodom. Alfa i beta upotreba su esto nekorelisane i esto se na njih ne upuuje u planu testa.
2.2.4. Testiranje usaglaenosti/Funkcionalno testiranje/Testiranje

tanosti

(Conformance testing/Functional testing/Correctness testing)

Testiranje usaglaenosti usmereno je na validaciju bez obzira da li posmatrano ponaanje testiranog softvera odgovara svojim specifikacijama.
2.2.5. Postizanje pouzdanosti i procena (Reliability achievement and

evaluation) Kako bi se pomogla identifikacija greaka, testiranje bi trebalo da pobolja pouzdanost. Nasuprot tome, statistike mere pouzdanosti se mogu izvesti sluajnim generisanjem sluajeva testa prema operativnom profilu. Korienjem 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 neeljene efekte... U praksi, ideja je da se pokae da softver koji je prethodno proao testove i dalje to moe. Beizer to definie kao bilo koje ponavljanje testova sa namerom da se pokae da je ponaanje softvera nepromenjeno, osim ukoliko se to ne zahteva. Oigledno je da se mora izvriti kompromis izmeu osiguranja datog regresionim testiranjem svakog puta kada se izvri 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 veba softver na maksimumu optereenja, kao i preko toga.

9

2.2.9. Back-to-back testiranje

Jedan test se izvrava 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 sluajevima kada je softver izgraen kako bi sluio razliitim korisnicima, testiranje konfiguracije analizira softver pod razliito odreenim konfiguracijama.
2.2.12.

Testiranje upotrebljivosti (Usability testing)

Ovaj proces procenjuje koliko je lako krajnjim korisnicima da naue da rade sa softverom, ukljuujui dokumentaciju; koliko efektivno funkcije softvera podravaju zadatke korisnika; i, na kraju, sposobnost oporavka nakon greaka korisnika.
2.2.13.

Razvoj voen testom (Test-driven development)

Ovaj razvoj nije na prvi pogled tehnika, zalaui 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 greaka mogu, i mnoge tehnike su razvijene na osnovu ovoga, tehnike koje pokuavaju da slome program, izvravanjem jednog ili vie testova izvedenog iz identifikovanih klasa ekvivalenta egzekucija. Vodei princip ovih tehnika je da budu to sistematinije u identifikaciji reprezentativnog skupa programskog ponaanja; na primer, posmatranje podklasa oblasti ulaza, scenario, stanja i toka podataka. Teko je nai 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 inenjera, kao i specifikacije, strukture koda, (realne ili vetake) greke koje bi trebalo nai, 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 sluajevi testiranja oslanjaju samo na ulaz/izlaz ponaanje. Poslednja kategorija odnosi se na kombinovanu upotrebu dve ili vie tehnika. Oigledno, ove tehnike se ne koriste podjednako esto. Ukljuene su u listu one koje bi inenjer trebalo da zna. 3.1 Bazirane na intuiciji i iskustvu softverskih inenjera4 3.1.1 Ad hoc testiranje Verovatno najrasprostranjenija tehnika ostaje ad hoc testiranje: testovi se izvode oslanjajui se na inenjersko umee, intuiciju, i iskustvo sa slinim programima. Ad hoc testiranje moe biti korisno za identifikaciju specijalnih testova, onih koje nije lako zabeleiti formalizovanim tehnikama. 3.1.2 Istraivako testiranje (Explorarity testing) Ovo testiranje je definisano kao simultano uenje, dizajn testa i izvravanje testa; odnosno, testovi nisu odreeni unapred u okviru utvrenog plana testa, ve su dinamiki dizajnirani, izvreni i modifikovani. Efektivnost ovih testova oslanja se na znanje inenjera, koje se moe izvesti iz mnogo izvora: posmatranog ponaanja proizvoda tokom testiranja, upoznatosti sa aplikacijom, platformom, procesom neuspeha, tipom moguih greaka i mana, rizika povezanog sa posebnim proizvodom i slino. 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 odreenim relacijama, i reprezentativan skup testova (ponekad samo jedan) je uzet iz svake klase.

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. S. 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

3.2.2 Analize vrednosti granica (Boundary-value analysis) Sluajevi testa izabrani su na ili blizu granica oblasti ulaza promenljivih, sa obrazloenjem kao osnovom da mnoge greke imaju tendenciju da se koncentriu blizu ekstremnih vrednosti ulaza. Proirenje ove tehnike su testiranja robustnosti, gde su sluajevi testa takoe izabrani izvan ulazne oblasti promenljivih, kako bi se testirala robustnost programa prema neoekivanim ili pogrenim ulazima. 3.2.3 Tabela odluka (Decision table) Tabele odluka predstavljaju logike veze izmeu uslova (grubo reeno, ulaza) i akcija (grubo, izlaza). Sluajevi testa su sistematino dobijeni razmatranjem svake mogue kombinacije uslova i akcija. Tehnika povezana sa ovom je grafiko predstavljanje uzrok-efekat. 3.2.4 Konanog stanja bazirane na maini (Finite-state machine-based) Modeliranjem programa kao maine konanih 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 omoguava automatsku derivaciju funkcionalnih sluajeva testa i istovremeno, obezbeuje referentni izlaz, oracle, za proveru rezultata testa. Metode postoje i za dobijanje sluajeva testa iz onih baziranih na modelu ili algebarskih specifikacija. 3.2.6 Sluajno testiranje (Random testing) Testovi su generisani samo sluajno, ali ih ne bi trebalo meati sa statistikim 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 sluajne take unutar nje.

3.3 Tehnike bazirane na kodu (Code-based) 3.3.1 Kriterijum baziran criteria) na kontrolnom protoku (Control-flow-based

Ovi kriterijumi su usmereni za pokrivanje svih naredbi ili blokova naredbi u programu, ili njihovih posebnih kombinacija. Nekoliko kriterijuma je
12

predloeno kao pokrivanje uslov/odluka. Najjai od kriterijuma baziranih na kontrolnom toku je testiranje puta (path testing), koje ima za cilj izvravanje 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 izvrene makar jednom u testu, 100% pokrivenosti grana se kae da je postignuto. 3.3.2 Kriterijum baziran na toku podataka (Data flow-based criteria) U ovakvom testiranju, kontrolni grafik toka belei se sa informacijama o tome kako su promenljive u programu definisane, koriene, i ubijene (nedefinisane). Najjai kriterijum, sve definicije koriste puteve, zahteva da se za svaku promenljivu, svaki segment putanje kontrolnog toka iz definicije te promenljive koristi dok se izvrava. 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 grafiki se prikazuje korienjem 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 izmeu vorova. 3.4 Tehnike bazirane na defektima (Fault-based techniques) Sa razliitim nivoima formalizacije, ove tehnike testiranja smiljaju sluajeve za testiranja posebno namenjene za otkrivanje kategorija verovatno ili unapred definisanih defekata.

3.4.1 Pogaanje greaka (Error guessing) U pogaanju greaka, sluajevi za testiranje su posebno dizajnirani od strane softverskih inenjera koji su pokuavali da otkriju najprihvatljivije greke datog programa. Dobar izvor informacija je istorija greaka otkrivenih u ranijim projektima, kao i inenjerska ekspertiza. 3.4.2 Testiranje mutacija (Mutation tetsing)
13

Ovo je blago izmenjena verzija programa pod testom, razlikujui se malom, sintaksikom promenom. Ukoliko je sluaj testiranja uspean u utvrivanju razlike izmeu 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 sluajno generisani dok se dovoljan broj mutacija ne ubije, ili su testovi posebno dizajnirani da ubiju preivele mutacije. U drugom sluaju testiranje mutacija moe se kategorisati kao tehnika bazirana na kodu. Osnovna pretpostavka testiranja mutacija, efekat zdruivanja, je ta da se traenjem jednostavnih sintaksikih greaka nalaze kompleksnije ali realni defekti. Kako bi tehnika bila efektivna, na sistematian nain 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 okruenje testa mora reprodukovati operativno okruenje softvera to je blie mogue. Ideja je da se iz posmatranih rezultata testa zakljuuje budua pouzdanost softvera kada je u pravoj upotrebi. Kako bi se to uradilo, ulazima se dodeljuje raspodela verovatnoe, 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 voeno ciljevima pouzdanosti i oekivanim relativnim korienjem i kritinostima razliitih 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 izvoenje 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 usaglaenosti protokola Testiranje sistema realnog vremena Testiranje bezbednosno-kritinih 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 razliite izvore informacija i dokazano je da daju akcenat na razliite vrste problema. Mogu se koristiti u kombinaciji, u zavisnosti od budeta. 3.7.2 Deterministike nasuprot sluajnim Sluajevi testa se mogu izabrati na deterministiki nain, prema raznim tehnikama koje su nabrojene, ili sluajno iz nekih raspodela ulaza, kao to se obino radi u testiranju pouzdanosti. Nekoliko analitikih i empirijskih poreenja 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 meaju sa ciljevima testa. Tehnike testa treba gledati kao sredstva koja pomau da se postignu ciljeva testa. Na primer, pokrivenost grane je popularna tehnika testa. Dostizanje odreenih mera pokrivenosti grane ne bi trebalo posmatrati kao cilj testiranja samo po sebi: to je sredstvo kako bi se poboljale anse nalaenja kvarova sistematskim vebama svake grane programa iz take odluke. Kako bi izbegli takve nesporazume, mora se napraviti jasna razlika izmeu mera povezanih sa testom, koje obezbeuju evaluaciju programa pri testu baziranom na posmatranim izlazima testa, i onih koje procenjuju temeljnost skupa testa. Mere se obino smatraju za instrument analize kvaliteta. Mere se mogu koristiti za optimizaciju planiranja i izvravanja testova. Menadment moe koristiti nekoliko mera procesa kako bi nadgledali napredak. 4.1 Procena testiranog programa (IEEE982.1-98) 4.1.1 Merenja programa koja pomau planiranju i dizajniranju testa Mere bazirane na veliini programa (na primer, izvorne linije koda ili funkcionalne take) ili strukture programa (kao to je kompleksnost) koriste se za voenje programa. Strukturne mere, takoe, mogu ukljuivati merenja meu modulima programa u pogledu uestalosti kojom se moduli pozivaju meusobno. 4.1.2 Tipovi defekata, klasifikacija i statistike U literaturi se moe nai dosta klasifikacija i taksonomija defekata. Kako bi testiranje bilo efektivnije, bitno je znati koji tip nedostatka se moe nai u softveru prilikom testiranja, i njegova uestalost sa kojom su se ovakvi nedostaci pojavljivali u prolosti. Ova informacija moe biti veoma korisna prilikom predvianja kvaliteta, kao i za unapreenje procesa. 4.1.3 Gustina defekata (Fault density) Program pod testom se moe oceniti brojanjem i klasifikacijom otkrivenih defekata po njihovim tipovima. Za svaku klasu defekata meri se gustina defekata kao odnos izmeu broja defekata naenih i veliine programa.
5

B. Beizer, Software Testing Techniques, (International Thomson Press, 1990), Chaps. 2, 7. P. C. Jorgensen, Software Testing: A Craftsman's Approach, (second edition, CRC Press, 2004), Chaps. 2, 9. S. L. Pfleeger, Software Engineering: Theory and Practice, (second ed., Prentice Hall, 2001), 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 Statistika procena pouzdanosti softvera, koja se moe dobiti dostizanjem pouzdanosti i evaluacijom, moe se koristiti za procenu proizvoda i na osnovu toga doneti odluka da li se testiranje moe ili ne moe zaustaviti. 4.1.5 Modeli rasta pouzdanosti Ovi modeli obezbeuju predvianje pouzdanosti na osnovu posmatranih defekata pod dostignutom pouzdanou i evaluacijom. Oni pretpostavljaju, u optem sluaju, da su defekti koji su izazvali posmatrane neuspenosti popravljeni (iako neki modeli prihvataju nesavrenosti), i prema tome, u proseku, pouzdanost proizvoda prikazuje trend rasta. Sada postoji vie modela. Mnogi su zasnovani na optim pretpostavkama, dok se drugi razlikuju. Zapaamo, da su ovi modeli podeljeni u modele koji broje defekte i one koji uzimaju vreme izmeu defekata.

4.2 Evaluacija izvrenih testova 4.2.1 Mere pokrivenosti/temeljnosti (Coverage/thoroughness measures) Neki kriterijumi adekvatnosti testa zahtevaju da sluajevi testiranja sistematski ispituju skup elemenata identifikovanih u programu ili specifikaciji. Kako bi procenili temeljnost izvrenog testa, testeri mogu da nadgledaju pokrivene elemente, tako da dinamiki mogu meriti odnos izmeu pokrivenih elemenata i njihovog ukupnog broja. Na primer, mogue je meriti procenat pokrivenih grana u grafu toka programa, ili procenat funkcionalnih zahteva ostvarenih meu onima koji su navedeni u listi dokumenta specifikacije. Kriterijum adekvatnosti baziran na kodu zahteva prikladanu instrumentaciju programa pod testom. 4.2.2 Uvoenje defekata (Fault seeding) Neki defekti se vetakim putem uvode u program pre testiranja. Kada se testovi izvravaju, neki od ovih postavljenih defekata bie otkriveni, kao verovano jo neki koji su ve postojali. U teoriji, u zavisnosti od toga koji su vetaki defekti otkriveni i koliko, moe se proceniti efektivnost testiranja i moe se proceniti broj preostalih pravih greaka. U praksi, statistiari sumnjaju u raspodelu i reprezentativnost uvedenih defekata u odnosu na prave defekte i male veliine na kojoj se bazira ekstrapolacija.
17

Neki navode da bi ovu tehniku trebalo koristiti sa velikom panjom, jer uvoenje defekata u softver ukljuuje oigledan 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 moe biti mera efektivnosti izvrenog testa. 4.2.4 Poreenje i relativna efektivnost razliitih tehnika Sprovedeno je nekoliko studija kako bi se poredila relativna efektivnost sa razliitim tehnikama testa. Bitna je preciznost karakteristika u odnosu na koje se tehnike procenjuju; ta je, na primer, tano znaenje termina efektivnost? Mogua tumaenja su: broj potrebnih testova kako bi se pronaao prvi defekt, odnos broja defekata naenih tokom testiranja u odnosu na sve greke naene tokom i nakon testiranja, ili u kojoj meri je pouzdanost unapreena. Analitika i empirijska poreenja razliitih tehnika sprovedena su prema svakom pojmu efektivnosti odreenom iznad.

5. Proces testa (Test process)

Koncepti testa, strategije, tehnike i mere potrebno je da budu integrisani u odreen i kontrolisan proces koji vode ljudi. Proces testiranja podrava aktivnosti testiranja i omoguava voenje timovima testiranja, od planiranja testa do procene izlaza testa, kao to obezbeuje opravdano osiguranje da e ciljevi testiranja biti efikasno ispunjeni. 5.1 Praktina razmatranja6 5.1.1 Programiranje bez stavova/bezlino programiranje (Attitudes/Egoless programming) Veoma bitna komponenta uspenog testiranja je stav saradnje za testiranje i kvalitetne aktivnosti uverenja. Menaderi imaju kljunu ulogu u usvajanju opteg pozitivnog prihvatanja otkrivanja defekata tokom razvoja i odravanja; na primer, prevencijom razmiljanja o vlasnitvu koda meu
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.

S. L. C. Kaner, K. C.

18

programerima, tako da se ne oseaju odgovornim za defekte koji su otkriveni njihovim kodom.

5.1.2 Voenje testova (Test guides) Faza testiranja moe biti voena raznim ciljevima, na primer: u testiranju baziranom na riziku, koje koristi rizik proizvoda radi utvrivanja prioriteta i fokusiranja na strategiju testa; ili u testiranju baziranom na scenariju, u kojem su sluajevi testa bazirani na utvrenom scenariju softvera. 5.1.3 Menadment procesa testa Aktivnosti testa sprovedene na razliitim 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 ukljueni u pet primarnih pocesa ivotnog ciklusa kao i u procese podrke. U IEEE Std 1074, testiranje je grupisano sa drugim aktivnostima evaluacije, kao znaajno 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) obezbeuje dobar opis dokumentacije testa i njihove meusobne veze i veze sa procesom testiranja. Dokumentacija testa moe ukljuivati, izmeu ostalog, plan testa, specifikaciju dizajna testa, specifikaciju procedure testa, specifikaciju sluajeva testa, log testa, i incidente testa ili izvetaj o problemima. Softver pod testom se dokumentuje kao predmet testiranja. Dokumentacija testa bi trebalo da bude oformljena i kontinualno aurirana, do istog nivoa kvaliteta kao i drugi tipovi dokumentacije u softverskom inenjeringu. 5.1.5 Interni vs. Nezavisni tim (Internal vs. independent test team) Formalizacija procesa testiranja moe ukljuivati formalizaciju i organizacije tima koji vri testiranje. Ovaj tim mogu sainjavati interni lanovi (odnosno, projektni tim, ukljuen ili ne u konstrukciju softvera), ili eksterni lanovi, sa ciljem da se dobiju objektivne, nezavisne perspektive, ili, na kraju, da bude sainjen i od internih i od eksternih lanova. Razmatranja trokova, vremena, zrelosti nivoa ukljuene organizacije, i kritinost aplikacije mogu presuditi u odluivanju.

19

5.1.6 Procena trokova/napora i druge mere procesa (Cost/effort estimation and other process measures) Nekoliko mera povezanih sa resursima potroenim za testiranje, kao i u vezi sa relativnom efektivnou pronalaenja defekata na razliitim fazama testa, koriste menaderi kako bi kontrolisali i unapredili proces testa. Ove mere testa mogu pokrivati aspekte kao to su broj odreenih sluajeva testa, broj izvrenih sluajeva testa, broj sluajeva koji su proli, broj sluajeva koji su bili neuspeni, izmeu ostalih. Evaluacija faza testa moe se kombinovati sa analizom korenih uzroka (root cause) kako bi se procenila efektivnost procesa testa u nalaenju defekata to je ranije mogue. Takva procena se moe povezati sa analizom rizika. Povrh toga, resursi potroeni za testiranje trebalo bi da budu propocionalni sa upotrebom/kritinou primene: razliite tehnike imaju razliite trokove i daju razliite nivoe poverenja pouzdanosti proizvoda. 5.1.7 Zavretak (Termination) Potrebno je doneti odluku koliko je testiranja dovoljno i kada se moe zavriti faza testiranja. Temeljne mere, kao to je dostignuta pokrivenost koda ili funkcionalna kompletnost, kao i procene gustine defekata ili operativne pouzdanosti, omoguuju korisnu podrku, ali same nisu dovoljne. Odluka takoe ukljuuje razmatranja o trokovima i rizicima nastalim iz potencijalnih preostalih defekata, nasuprot trokovima koji bi podrazumevali nastavak testa.

5.1.8 Ponovna upotreba testa i obrasci testa Kako bi se testiranje ili odravanje sprovelo na organizovan i trokovnoefikasan nain, sredstva koriena za testiranje svakog dela softvera trebalo bi se sistematski ponovo koristiti. Ovo skladite materijala za testiranje mora biti pod kontrolom menadmenta za softversku konfiguraciju, tako da se promene zahteva softvera ili dizajna odraavaju u promenama prostora sprovedenog testa. Reenja testa prihvaena za testiranje nekih tipova aplikacija pod odreenim okolnostima, sa motivacijom iza sprovedene odluke, formiraju obrazac testa koji se moe dokumentovati za kasnije ponovne upotrebe u slinim 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.

S. B. Beizer,

20

Pod ovom temom dat je kratak pregled aktivnosti testa; kao to se esto podrazumeva narednim opisom, uspeno upravljanje aktivnostima testa u velikoj meri zavisi od procesa menadmenta softverske konfiguracije. 5.2.1 Planiranje (Planning) Kao i bilo koji drugi aspekt projektnog menadmenta, i aktivnosti testiranja mogu biti planirane. Kljuni aspekti planiranja testa ukljuuju koordinaciju zaposlenih, upravljenje dostupnih objekata za testove i opreme (koja moe da ukljuuje magnetske medije, planove i procedure testova), i planiranje moguih neeljenih ishoda. Ukoliko se odrava vie od jedne osnovne linije softvera, tada se kao glavno razmatra vreme i napor potreban za obezbeivanje da je okruenje za test postavljeno na odgovarajuoj konfiguraciji. 5.2.2 Generisanje test-sluajeva (Test-case generation) Generisanje test-sluajeva je bazirano na nivou testiranja koji treba izvriti i u odnosu na posebne tehnike testiranja. Test-sluajevi bi trebalo da budu pod kontrolom menadmenta softverske konfiguracije i ukljuuju oekivane rezultate za svaki test. 5.2.3 Razvoj okruenja testa (Test environment development) Okruenje korieno za testiranje trebalo bi da je kompatibilno sa alatima softverskog inenjeringa. Trebalo bi da olaka razvoj i kontrolu testsluajeva, kao i povraaj oekivanih rezultata, skripti, i drugih materijala za testiranje. 5.2.4 Izvravanje (Execution) Izvravanje testa bi trebalo da otelotvori osnovni princip naunog eksperimentisanja: sve to je uraeno tokom testa trebalo bi da je izvreno i dokumentovano dovoljno jasno da bi druga osoba mogla da ponovi rezultate. Stoga, testiranje bi trebalo izvravati 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 uspean. U veini sluajeva, uspean znai da je softver dao oekivane rezultate i nije imao veih problema sa neoekivanim izlazima. Nisu svi neoekivani izlazi obavezno defekti. Pre nego to se defekt moe 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 znaajni, moe se sazvati formalni sastanak za pregled kako bi to procenio. 5.2.6 Izvetavanje problema (Problem reporting)/Test log Aktivnosti testiranja mogu se uneti u log testa kako bi se identifikovalo kada je test izvren, ko je izvrio test, koja je softverska konfiguracija bila osnova za testiranje, i druge relevantne informacije. Neoekivani ili netani rezultati testa mogu se zabeleiti u sistemu izvetavanja problema, podaci od kojih se formira baza za kasnije popravljanje greaka koji su bili zapaeni kao defekti tokom testiranja. Takoe, anomalije koje nisu klasifikovane kao defekti mogu se dokumentovati za sluaj da se kasnije ispostavi da su vanije od onoga to se prvo smatralo. Izvetaji testa su takoe ulaz za promenu procesa upravljanja. 5.2.7 Praenje kvarova (Defect tracking) Neuspesi posmatrani tokom testiranja najee nastaju zbog defekata ili kvarova softvera. Takvi kvarovi se mogu analizirati kako bi se utvrdilo kada su uvedeni u softver, kakve greke su dovele do njihovog nastanka (loe definisane potrebe, netane deklaracije promenljivih, curenje memorije, greka programske sintakse) i kada su prvi put mogle biti primeene u softveru. Informacije o praenju kvarova koriste se za utvrivanje koje aspekte softverskog inenjeringa bi trebalo unaprediti i koliko su bile uspene 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 razliite naine su definisali termin kvalitet. Za Phil Crosby-a, to je bila potvrda zahteva korisnika. Watts Humphrey ga naziva postizanje odlinih nivoa prikladnosti za upotrebu, dok je IBM dao frazu kvalitet voen tritem (market-driven quality), koji je baziran na dostizanju potpunog zadovoljstva kupaca. Kriterijum Baldrige-a za organizacijski kvalitet (NIST03) ima slinu frazu, kvalitet voen kupcem (customer-driven quality), i ukljuuje 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)

Usaglaavanje o zahtevima kvaliteta, kao i jasna komunikacija sa softverskim inenjerom o tome ta predstavlja kvalitet, zahteva da mnogi aspekti kvaliteta budu formalno definisani i razmatrani. Softverski inenjer bi trebalo da razume osnovna znaenja koncepta kvaliteta i karakteristika kao i njihovih vrednosti za softver prilikom razvoja ili do odravanja. Znaajan koncept je taj da softverski zahtevi definiu potrebne
23

karakteristike kvaliteta softvera i uticaj metoda merenja i kriterijuma prihvatanja za procenu ovih karakteristika. 1.1 Kultura i etika softverskog inenjerstva (Software Engineering Culture and Ethics) Oekuje se da softverski inenjeri dele posveenost za softverskim kvalitetom kao deo njihove kulture. Zdrava kultura softverskog inenjerstva opisana je u [Wie96]. Etika moe imati znaajnu ulogu u softverskom kvalitetu, kulturi, i stavovima softver inenjera. IEEE Computer Society i ACM [IEEE99] razvili su etiki kodeks i profesionalnu praksu na osnovu osam principa kako bi pomogli softverskim inenjerima da ojaaju stavove u vezi sa kvalitetom i nezavisnou svog posla. 1.2 Vrednost i trokovi kvaliteta (Value and Costs of Quality)8 Pojam kvaliteta nije tako jednostavan kao to moe da izgleda. Za bilo koji projektovani proizvod postoji vie eljenih kvaliteta koji su relevantni za posebnu perspektivu proizvoda koji se moraju razmatrati i utvrditi za vreme za koje se definiu zahtevi proizvoda. Karakteristike kvaliteta mogu biti obavezne ili ne, ili mogu biti traene do vieg ili nieg nivoa, i meu njima se mogu izvriti kompromisi. Trokovi kvaliteta mogu biti podeljeni na trokove prevencije, trokove procene, unutranje trokove otkaza i spoljanje trokove otkaza. Motivacija iza softverskog projekta je elja za stvaranjem softvera koji ima vrednost, a ta vrednost moe biti, ili ne, oznaena kao troak. Korisnik e imati neke maksimalne cene u vidu u zamenu za koju se oekuje da e osnovna svrha softvera biti ispunjena. Korisnik e imati i neka oekivanja u pogledu kvaliteta softvera. Ponekad klijenti ne razmiljaju o pitanjima kvaliteta ili vezanim trokovima. Da li je ta karakteristika samo dekorativna, ili je od kljunog znaaja za softver? Ako se odgovor nalazi izmeu, kao to je gotovo uvek sluaj, onda je pitanje ukljuivanja klijenta delom u proces odluke, i potpuno obavetenje i o trokovima i o koristima. U idealnom sluaju, veina 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 Practitioners 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 odreeno pravilo o tome kako bi ova odluka trebalo da bude doneena, ali softverski inenjer bi trebalo da bude u stanju da predstavi alternative kvaliteta i njihovih troova.

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 razliite hijerarhijske nivoe i razliit 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 inenjerstva Upravljanje kvalitetom softvera i kvalitet procesa softverskog inenjerstva imaju direktan uticaj na kvalitet softverskog proizvoda. Modeli i kriterijumi koji procenjuju sposobnosti softverske organizacije prvenstveno su projektne organizacije i pitanja menadmenta, i kao takvi prikazani u okviru oblasti znanja upravljanja softverskog inenjerstva (Software Engineering Management) i procesa softverskog inenjerstva (Software Engineering Process). Naravno, nije mogue u potpunosti razlikovati kvalitet procesa od kvaliteta proizvoda. Kvalitet procesa, razmatran u oblasti znanja procesa softverskog inenjeringa u okviru ovog Vodia, utie na karakteristike kvaliteta softverskih proizvoda, to zauzvrat utie na kvalitet u upotrebi vien od strane kupaca. Dva vana 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 takoe, 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 Software, 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 Practitioners Guide, (Artech House, 1997). Capability Maturity Model Integration for Software Engineering (CMMI), (Carnegie Mellon University, 2002).

25

procesa softverskog inenjeringa. CMMI ima nameru da obezbedi smernice za poboljanje procesa. Specifina podruja procesa povezana sa upravljanjem kvalitetom su (a) obezbeivanje 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 poetku je bilo rasprava oko toga da li bi softverski inenjeri 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 moe pomoi u postizanju viih nivoa zrelosti od CMMI. 1.3.2 Kvalitet softverskog proizvoda Softver inenjer bi trebalo da, kao prvo, utvrdi stvarnu svrhu softvera. U tom pogledu, najznaajnije 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 inenjer ima odgovornost da izvue zahteve kvaliteta koji moda nisu eksplicitno objanjeni, i razmotri njihovu vanost, kao i nivo teine njihovog ostvarivanja. Svi procesi povezani s kvalitetom softvera (na primer, izgradnja, proveravanje i poboljanje kvaliteta) e biti dizajnirani u skladu ovim zahtevima, i oni nose dodatne trokove. Standard (ISO9126-01) definie, za dva, od svoja tri modela kvaliteta, povezane karakteristike i podkarakteristike kvaliteta, kao i mere koje su korisne za ispunjenje kvaliteta softverskog proizvoda. Znaenje termina "proizvod" je proireno kako bi ukljuilo bilo koji predmet (artefakt) koji je izlaz iz bilo kojeg procesa korienog za izgradnju finalnog softverskog proizvoda. Primeri proizvoda ukljuuju, ali nisu ogranieni na njih, celi sistem specifikacije zahteva, specifikaciju softverskih zahteva za softverskim komponentama sistema, dizajn modul, kod, dokumentaciju testa, ili izvetaje nastale kao rezultat zadataka analize kvaliteta. Dok je veina tretmana kvaliteta opisana u vidu konanog softvera i sistemskih performansi, ispravno inenjerstvo u praksi zahteva da i meuproizvodi relevantni za kvalitet, budu procenjeni tokom samog procesa softverskog inenjerstva. 1.4 Unapreenje 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 moe se unaprediti kroz iterativni proces kontinualnih poboljanja koji zahteva kontrolu menadmenta, koordinaciju i povratne informacije od strane vie konkurentnih procesa: (1) procesa ivotnog ciklusa softvera, (2) procesa otkrivanja, uklanjanja i prevencije greaka/defekata, i (3) procesa unapreenja kvaliteta. Teorija i koncepti iza unapreenja kvaliteta, kao to je izgradnja kvaliteta kroz prevenciju i ranu detekciju greaka, kontinualna poboljanja, i usmerenost na kupce, znaajni su za softversko inenjerstvo. Ovi koncepti su bazirani na radu eksperata u oblasti kvaliteta, koji navode da je kvalitet proizvoda direktno povezan sa kvalitetom procesa koji je korien u njegovom kreiranju. Pristupi kao to je Totalno upravljanje kvalitetom (Total Quality Management (TQM)) obrauju procese Plan, Do, Check, i Act (PDCA) koji predstavljaju alate preko kojih se ispunjavaju ciljevi kvaliteta. Pokroviteljstvo menadmenta podrava proces i procenu proizvoda kao i dobijene rezultate. Tada je unapreeni program razvijen identifikovanjem detaljnih akcija i projekata unapreenja koje bi trebalo ispuniti u izvodljivom vremenskom okviru. Podrka menadmenta podrazumeva da svaki projekat unapreenja ima dovoljno resursa za postizanje cilja, definisanog za njega. Pokroviteljstvo menadmenta mora se frekventno traiti implementacijom proaktivnih aktivnosti komunikacija. Ukljuenost radnih grupa, kao i podrke srednjeg nivoa menadmenta i resursi alocirani na projektnom nivou, razmatraju se u oblasti znanja procesa softverskog inenjeringa (Software Engineering Process KA).
2. Menadment

procesi kvaliteta softvera (Software Quality Management Processes)

Menadment kvaliteta softvera (SQM) primenjuje se na sve perspektive softverskih procesa, proizvode i resurse. On definie procese, vlasnike procesa i zahteve za ovim procesima, merenja procesa i njihovih izlaza, kao i kanale povratnih informacija (feedback). Proces menadmenta kvaliteta softvera sastoji se od dosta aktivnosti. Neke mogu direktno da otkriju defekte, dok druge ukazuju gde moe biti korisno raditi dalja ispitivanja. Druge se takoe, nazivaju aktivnosti direktnog otkrivanja defekata (directdefect-finding). Mnoge aktivnosti se koriste u oba sluaja. Planiranje kvaliteta softvera ukljuuje: 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 menadmenta 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 moe koristiti za procenu meuproizvoda kao i finalnog proizvoda. Neki od specifinih 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 podstiu kvalitet i, takoe, nalaze mogue probleme. Ali se malo razlikuju u svojom znaaju. SQM procesi pomau da se obezbedi kvalitet softvera u datom projektu. Oni, takoe obezbeuju, kao sporedni proizvod, opte informacije za menadment, ukljuujui indikaciju kvaliteta itavog procesa softverskog inenjerstva. Proces softverskog inenjerstva (The Software Engineering Process) i oblasti znanja menadmenta softverskog inenjerstva (Software Engineering Management KA) razmatraju programe kvaliteta za organizaciju koja razvija softver. SQM moe 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, menadment, razvoj, menadment konfiguracije) implementiraju i koliko dobro meuproizvodi i finalni proizvodi ispunjavaju svoje specifine zahteve. Rezultati ovih zadataka su sastavljeni u okviru izvetaja za menadment pre sprovoenja korektivnih akcija. Menadment SQM procesa ima zadatak da obezbedi da su rezultati ovih izvetaja tani. 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), takoe, moe imati znaajnu ulogu u isporuci kvalitetnog softvera. Ukljuivanje disciplinovane analize rizika i menadment tehnika u procese ivotnog ciklusa softvera moe poveati potencijal za proizvodnju kvalitetnog proizvoda.
2.1 Osiguranje kvaliteta softvera (Software Quality Assurance)11

Procesi SQA pruaju obezbeenje da softverski proizvodi i procesi u ivotnom ciklusu projekta odgovaraju njihovim datim zahtevima planiranjem, propisima i izvoenjem skupa aktivnosti kako bi se obezbedilo adekvatno poverenje da je kvalitet ugraen u softver. Ovo znai osiguranje da je problem jasno i adekvatno naveden i da su zahtevi reenja ispravno definisani i izraeni. SQA tei da odri kvalitet kroz razvoj i odravanje proizvoda putem izvravanja vie aktivnosti na svakoj fazi, to moe rezultirati ranom identifikacijom problema, gotovo neizbene 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 obezbeen za prikladnu organizaciju. SQA plan definie sredstva koja e biti koriena kako bi se obezbedilo da softver, razvijen za odreeni proizvod, zadovoljava korisnikove zahteve i da je najveeg mogueg kvaliteta unutar ogranienja projekta. Kako bi se to uradilo mora se prvo obezbediti da je cilj kvaliteta jasno definisan i shvaen. Mora se uzeti u obzir menadment, razvoj i planovi odravanja za softver. Za vie detalja pogledajte standard (IEEE730-98). Odreene aktivnosti i zadaci kvaliteta su izloeni, zajedno sa njihovim trokovima i zahtevima za resurse, njihovim ukupnim ciljevima menadmenta, i njihovim rasporedom u vezi sa onim ciljevima u menadmentu softverskog inenjerstva, razvoja, ili planova odravanja. SQA plan mora biti konzistentan sa planom menadmenta 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

regulie projekat, i kako e se oni proveravati i pratiti radi obezbeenja adekvatnosti i usaglaenosti. Plan SQA takoe, identifikuje mere, statistike tehnike, procedure za izvetavanje o problemima kao i korektivne akcije, resurse kao to su, alati, tehnike, metodologije, obezbeenje fizikih medija, trening, i SQA izvetavanje i dokumentacija. tavie, SQA plan se odnosi i na aktivnosti obezbeenja kvaliteta softvera bilo kog drugog tipa aktivnosti opisanog u planu softvera, kao to je nabavka od dobavljaa softvera do projekta ili instalacije komercijalnog offthe-shelf softvera (COTS), i servisiranje nakon isporuke softvera. Takoe, moe sadrati kriterijume prihvatanja kao i aktivnosti izvetavanja i upravljanja koje su kritine za kvalitet softvera.

2.2 Verifikacija i validacija (Verification & Validation)12

Radi uprotenosti, verifikacija i validacija (V&V) se razmatraju kao jedna tema u ovom Vodiu, 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 tee obezbeenju kvaliteta ugraenog u softver kao i da softver ispunjava korisnike 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. Takoe ocenjuju i meuproizvode, i ipak, pri ovom kapacitetu, meukorake procesa ivotnog ciklusa proizvoda. Proces V&V odreuje da li razvijeni proizvodi ili oni koji su dobijeni aktivnostima odravanja ispunjavaju zahteve koje je ta aktivnost trebalo da ispuni, i da li finalna verzija softvera ispunjava predvienu svrhu i zahteve korisnika. Verifikacija je pokuaj obezbeenja da je proizvod pravilno napravljen, u smislu da izlazni proizvodi aktivnosti ispunjavaju specifikacije date u prethodnim aktivnostima. Validacija predstavlja pokuaj da se obezbedi da je pravi proizvod napravljen, odnosno, da proizvod ispunjava svoju odreenu svrhu. Oba procesa, i proces verifikacije i proces validacije, poinju u ranoj fazi razvoja ili fazi odravanja. Oni omoguavaju ispitivanje najvanijih 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 odreena. Rezultujui plan V&V dokumentuje i opisuje razliite 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.

D.R.

30

i aktivnosti, kao i tehnike i alate koji e biti korieni. Razumevanje razliitih svrha svake od V&V aktivnosti pomoi e u paljivom planiranju tehnika i resursa koji su potrebni da bi ispunili svoje svrhe. Standardi (IEEE1012-98:s7 and IEEE1059-93: Appendix A) odreuju ta obino ide u V&V plan. Plan se, takoe, odnosi i na menadment, komunikacije, politiku i procedure V&V aktivnosti i njihovu interakciju, kao i izvetavanje 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 Vodiu, 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 menadmenta (Management reviews) Tehnike revizije (Technical reviews) Inspekcije (Inspections) Pregledi (Walk-throughs) Provere (Audits) Revizije menadmenta

2.3.1

Svrha revizije menadmenta je nadgledanje progresa, utvrivanje statusa planova i rasporeda, potvrda zahteva i njihove alokacije, ili procena efektivnosti upravljakog pristupa korienog za postizanje usklaivanja zbog svrhe [IEEE1028-97]. Oni podravaju odluke o promenama i korektivnim akcijama koje su potrebne u toku softverskog projekta. Revizije menadmenta odreuju adekvatnost planova, rasporeda, zahteva i nadziru njihov progres ili nekonzistentnost. Ove revizije se mogu izvravati nad proizvodima kao to su izvetaji revizije, izvetaji o progresu, V&V izvetaji, planovi vie vrsta, koji ukljuuju menadment rizika, projektni menadment, menadment konfiguracije softvera, bezbednost softvera i procenu rizika, izmeu ostalih. 2.3.2. Tehnike revizije Svrha tehnike revizije je da proceni softverski proizvod kako bi utvrdila da li je prikladan za nameravanu upotrebu. Cilj je utvrivanje odstupanja od odobrene specifikacije i standarda. Rezultati bi trebalo da omogue
31

menadmentu dokaze o potvrdi (ili ne) da proizvodi odgovoraju specifikaciji i pridravaju se standarda, i da su sve promene kontrolisane (IEEE102897). Specifine uloge se moraju utvrditi prilikom tehnike revizije: donosilac odluka, voa revizije, zapisiva, i tehniko osoblje za podrku aktivnosti revizije. Tehnika revizija zahteva da se obavezni ulazi ispune kako bi se nastavilo:

Izjava o ciljevima Specifian softverski proizvod Poseban plan projektnog menadmenta Lista problema u vezi da ovim proizvodom Procedura tehnike revizije

Tim prati proceduru revizije. Tehniki kvalifikovana osoba prikazuje pregled proizvoda i ispitivanje se sprovodi tokom jednog ili vie sastanaka. Tehnika revizija je zavrena kada se sve aktivnosti koje su navedene u ispitivanju zavre.
2.3.3 Inspekcije13

Svrha inspekcije je da otkrije i identifikuje anomalije softverskog proizvoda (IEEE1028-97). Dve znaajne razlike inspekcije od revizije su naredne: 1. Individua koja je pretpostavljena bilo kom od lanova tima za inspekciju ne bi trebalo da uestvije u inspekciji.
2. Inspekciju bi trebalo da vodi nepristrasan moderator koja je obuen

da vri inspekciju. Inspekcije softvera uvek ukljuuju autora meuproizvoda ili finalnog proizvoda, dok kod ostalih revizija to ne mora da bude sluaj. Inspekcija, takoe, ukljuuje vou, snimatelja, itaa, i nekoliko (2 do 5) inspektora. lanovi tima inspekcije mogu posedovati razliita ekspertna znanja, kao to su poznavanje oblasti, ekspertiza metode dizajniranja ili ekspertizu jezika. Inspekcija se obino 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, moda primenjujui analitiku 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 voi
R.

13

T. Gilb and D. Graham, Software Inspections, (Addison-Wesley, 1993). Radice, High Quality Low Cost Software Inspections, (Paradoxicon, 2002), p. 479.

32

inspekcije. Tokom inspekcije, voa sprovodi sesiju i verifikuje da su svi spremni za inspekciju. Lista, sa anomalijama i pitanjima povezanim sa problemima od interesa, je uobiajen alat koji se koristi u inspekcijama. Rezultujua lista esto klasifikuje anomalije (vie u IEEE1044-93) i razmatrana je njena potpunost i tanost 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 obino traju nekoliko sati, dok tehnike revizije i provere obino su optije i traju due. 2.3.4 Pregledi (Walk-throughs) Svrha pregleda je ocena softverskog proizvoda. On se moe sprovesti za svrhu edukovanja publike o softverskom proizvodu. (IEEE1028-97) Glavni ciljevi su [IEEE1028-97]: Nalaenje anomalija Unapreenje softverskog proizvoda Razmatranja alternativnih implementacija Ocena saglasnosti prema standardima i specifikacijama

Pregled je slian inspekciji ali se obino smatra za manje formalan nain. Prezentacija se primarno organizuje od strane softverskog inenjera kako bi dao svojim lanovima tima ansu da izvre reviziju njegovog rada, kao tehnika uverenja. 2.3.5 Provere Svrha softverske provere je obezbeivanje nezavisne procene usklaenosti softverskih proizvoda i procesa u odnosu na primenljive regulacije, standarde, smernice, planove i procedure [IEEE1028-97]. Provera je formalno organizovana aktivnost, gde uesnici imaju specifine uloge, kao to su glavni revizor, pomoni revizor, snimatelj, ili inicijator, i ukljuuju predstavnika organizacije u kojoj se vri provera. Provera e identifikovati sve sluajeve odstupanja i kao rezultat toga dati izvetaj 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), znaajno je da ona mogu da se pojave za skoro bilo koji proizvod na bilo kojoj fazi razvoja ili procesa odravanja.

33

3. Praktina razmatranja
3.1.

Zahtevi kvaliteta softvera (Software Quality Requirements)14

3.1.1. Faktori uticaja (Influence factors)

Razliiti faktori utiu na planiranje, menadment i selekciju SQM aktivnosti i tehnika, ukljuujui:

Domeni sistema u kojem e se nalaziti softver (sigurnosno-kritini, kritini u odnosu na misiju, poslovno-kritini) Sistemski i softverski zahtevi Komercijalne (eksterne) ili standardne (interne) komponente koje e se koristiti u sistemu Primena specifinih standarda softverskog inenjerstva Metode i softverski alati koji e se koristiti za razvoj i odravanje, kao i za ocenjivanje kvaliteta i poboljanja Budet, 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 specifine SQM aktivnosti, koji su resursi potrebni i koji e pomerati granice napora. 3.1.2 Zavisnost U sluajevima kada sistemski otkazi mogu imati izuzetno ozbiljne posledice, ukupna pouzdanost (hardver, softver i ljudi) je osnovni zahtev kvaliteta iznad osnovne funkcionalnosti. Softverska zavisnost ukljuuje i takve karakteristike kao to su tolerancija na greke, sigurnost, bezbednost, i upotrebljivost. Pouzdanost je takoe i kriterijum koji se moe definisati terminima zavisnosti (ISO9126). Literarno telo za sisteme mora biti jako zavisno (visoko poverenje ili sistemi visokog integriteta). Terminologija za tradicionalne mehanike i elektrine sisteme koji mogu da ne ukljuuju 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).

R.O.

34

3.1.3 Nivoi integriteta softvera Nivo integriteta softvera se odreuje na osnovu moguih posledica otkaza softvera i verovatnoe otkaza. Za softver u kojem je vana 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 taka potencijalnih problema. Istorija neuspeha slinog softvera takoe moe pomoi u identifikovanju koje tehnike e biti najkorisnije u otkrivanju defekata i procenjivanju kvaliteta. Nivoi integriteta (na primer, gradacija integriteta) su predloeni u (IEEE1012-98).

3.2 Karakterizacija defekata (Defect Characterization)15 SQM procesi pronalaze defekte. Karakterizacija tih nedostataka vodi do razumevanja proizvoda, olakava korekcije na procesu ili proizvodu, i informie projektni menadment ili kupce o statusu procesa ili proizvoda. Postoje mnoge taksonomije za defekate (nedostatke), i iako su izvreni pokuaji da se dobije konsenzus o taksonomiji otkaza i defekata, literatura ukazuje da postoji dosta termina u upotrebi. Karakterizacija defekta (anomalija) se takoe koristi u revizijama i pregledima gde voa revizije esto prezentuje listu anomalija dobijenih od lanova tima radi razmatranja, na sastancima revizije. Kako nove metode dizajna i jezika evoluiraju, uz napredak opte softverske tehnologije, nove vrste defekata se pojavljuju i mnogo truda je potrebno za interpretiranje prethodno definisanih klasa. Kada se prate defekti, softverski inenjer se interesuje ne samo za broj defekata, ve i za tip. Informacija sama, bez neke klasifikacije, i nije od neke koristi u utvrivanju osnovnih uzroka defekata, jer bi odreene vrste problema trebalo da budu grupisane zajedno kako bi se donele odluke o njima. Sutina je da se uspostavi taksonomija defekata, koja je od znaaja za samu organizaciju i za softverske inenjere. SQM otkriva informacije na svim fazama softverskog razvoja i odravanja. Tipino, gde je upotrebljena re defekat, odnosi se na nedostatak kao to je definisano ispod. Ipak, razliite kulture i standardi mogu upotrebljavati neto drugaija znaenja ovih termina, to vodi pokuaju da se definiu. Delimine definicije uzete iz standarda (IEEE610.12-90) su:

Greka (Error): Razlika.izmeu izraunatog rezultata i tanog 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).

J. Rubin,

35

Defekat (Fault): Pogrean korak, proces ili definicija podataka u kompjuterskom programu Otkaz (Failure): [netaan] rezultat nastao na osnovu defekta Pogreka (Mistake): Ljudska akcija koja proizvodi netaan rezultat

Otkazi otkriveni u testiranju kao rezultat softverskih defekata su ukljueni kao neuspesi u diskusiji u ovom delu. Modeli pouzdanosti su izgraeni od podataka o otkazima prikupljenih tokom testiranja softvera ili iz softvera tokom primene, i prema tome, mogu se koristiti za predvianje buduih otkaza i kao pomo u odlukama o tome kada zaustaviti testiranje. Jedna mogua akcija koja proizilazi iz otkria SQM-a, je uklanjanje nedostataka iz proizvoda pod ispitivanjem. Ostale akcije omoguavaju dostizanje pune vrednosti iz nalaza SQM aktivnosti. Te radnje ukljuuju analizu i sumiranje nalaza, i korienje tehnika merenja kako bi se poboljao proizvod i procesa, kao i praenje nedostataka i njihovo uklanjanje. Unapreenje procesa se primarno razmatra u oblasti znanja procesa softverskog inenjeringa, gde je SQM bio izvor informacija. Podaci o neadekvatnostima i nedostacima pronaenim tokom implementacije SQM tehnika mogu biti izgubljeni, osim ukoliko nisu snimljeni. Za neke tehnike (na primer, tehnike preglede, revizije, inspekcije), zapisniari su prisutni da evidentiraju takve informacije, zajedno sa pitanjima i odlukama. Kada se koriste automatizovani alati, izlazi alata mogu pruiti 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 runo ili automatski, iz alata analize. Izvetaji o nedostacima su obezbeeni za menadment organizacije.
3.3 Menadment

tehnike kvaliteta Management Techniques)16

softvera

(Software

Quality

SQM tehnike se mogu kategorizovati na vie naina: statike, ljudskiintenzivne (people-intensive), analitike, dinamike. 3.3.1 Statike tehnike (Static techniques) Statike tehnike ukljuuju ispitivanje projektne dokumentacije i softvera, i druge informacije o softverskim proizvodima, bez njihovog izvravanja. Ove tehnike mogu da ukljuuju ljudski-intenzivne aktivnosti ili analitike aktivnosti sprovedene od strane pojedinaca, sa ili bez pomoi 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) Podeavanja za ove tehnike, ukljuujui preglede i revizije, mogu da variraju od formalnog sastanka do neformalnog sastanka, ali (obino) je ukljueno dvoje ili vie ljudi. Moe biti neophodna priprema unapred. Resursi osim onih pod ispitivanjem mogu ukljuivati liste i rezultate iz analitikih tehnika i testiranja. O ovim aktivnostima se govori u (IEEE102897) pri pregledima i revizijama. 3.3.3 Analitike tehnike (Analytical techniques) Softverski inenjeri obino primenjuju analitike tehnike. Ponekad nekoliko softverskih inenjera koristi istu tehniku, ali je svaki primenjuje na razliit deo proizvoda. Neke tehnike su voene alatom (tool-driven); druge su manualne. Neke mogu direktno da nau nedostatke, ali se obino koriste kao podrka drugim tehnikama. Neke, takoe, ukljuuju razliite procene kao deo opte analize kvaliteta. Primeri ovakvih tehnika ukljuuju analizu kompleksnosti, analizu kontrolnog toka i algoritamsku analizu. Svaki tip analize ima specifinu svrhu, i ne primenjuju se svi tipovi na svaki projekat. Primer tehnike podrke je analiza kompleksnosti, koja je korisna za utvrivanje da li je dizajn ili implementacija suvie kompleksna da bi se mogla pravilno razviti, testirati ili odravati. Rezultati analize kompleksnosti takoe se mogu koristiti u razvoju sluajeva testa. Tehnike za pronalaenje nedostataka, kao to je analiza kontrolnog toka, mogu se koristiti kao podrka drugoj aktivnosti. Za softvere sa puno algoritama znaajna je analiza algoritama, posebno kada bi netaan algoritam mogao da izazove katastrofalan rezultat. Postoji previe analitikih tehnika da bi ih prikazali ovde. Drugi, vie formalni, tipovi analitikih tehnika poznati su kao formalne metode. Oni se koriste za verifikaciju softverskih zahteva i dizajna. Dokaz o ispravnosti primenjuje se na kritine delove softvera. Uglavnom su korieni pri verifikaciji krucijalnih delova kritinog sistema, kao to su posebni bezbednosni i sigurnosni zahtevi. 3.3.4 Dinamike tehnike (Dynamic techniques) Razliite vrste dinamikih tehnika se izvravaju tokom razvoja i odravanja softvera. Generalno, ovo su tehnike testiranja, ali tehnike kao to je simulacija, provera modela i simboliko izvravanje mogu se smatrati dinamikim. itanje koda se smatra statikom tehnikom, ali iskusni softverski inenjeri mogu izvravati kod dok ga itaju. U tom smislu, itanje koda se moe smatrati i dinamikom tehnikom. Ova protivrenost u kategorizaciji ukazuje da ljudi sa razliitim ulogama u organizaciji mogu na drugaiji nain razmatrati i primenjivati ove tehnike. Prema tome, neki
37

testovi se mogu izvriti 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 ukljuuje i neke komentare u vezi sa testiranjem. Oblast znanja testiranja softvera obezbeuje raspravsu i tehnike 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, takoe, ukljuuje izlaze razvojnog procesa i procesa odravanja, prikupljanja, analize i merenja rezultata. SQA obezbeuje da su prikladni tipovi testova planirani, razvijeni i implementirani, dok V&V razvija planove testa, strategije, sluajeve 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 korienih u projektu: Evaluacija i test alata koji e se koristiti na projektu (IEEE1462-98) Test usaglaenosti (conformance test) komponenti i COTS proizvoda koji e biti upotrebljeni u proizvodu; sada postoji standard za softverske pakete (IEEE1465-98)

Ponekad se trai da nezavisna V&V organizacija nadgleda proces testiranja i ponekad svedoi pravom izvravanju kako bi se obezbedilo da je proces sproveden u skladu sa odreenim procedurama. V&V se moe zatraiti za procenu samog testiranja: adekvatnosti planova i procedura, adekvatnosti i tanosti rezultata. Drugi tip testiranja koji moe pripadati naslovu organizacije V&V je testiranje tree strane (third-party). Trea strana nije programer, niti je na bilo koji nain u vezi sa razvojem proizvoda. Umesto toga, trea strana je nezavisna ustanova, obino akreditovana od strane nekog zakonodavnog tela. Njena svrha je da testira proizvod radi potvrde specifinog 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 ukljuuju merenja kako bi se utvrdio stepen svake karakteristike kvaliteta dostignutog u proizvodu. Ukoliko su pravilno izabrane, merenja mogu da podre kvalitet softvera (meu ostalim aspektima procesa ivotnog ciklusa softvera) na vie naina. Mogu pomoi i u procesu donoenja odluka. Mogu nai problematine oblasti i uska grla u softverskom procesu; i mogu pomoi softverskim inenjerima da procene kvalitet svog rada za SQA svrhe i za proces dugoronog unapreenja kvaliteta. Uz poveavanje 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 podrava SQM. One ukljuuju pomo pri odluivanju kada zaustaviti testiranje. Za ovo su korisni modeli i merila pouzdanosti, uz upotrebu podataka o kvarovima i otkazima. Trokovi SQM procesa predstavljaju pitanje koje se skoro uvek postavlja prilikom odluivanja kako e se organizovati projekat. esto, koriste se opti modeli trokova koji su bazirani na tome kada se nalazi nedostatak i koliko napora je potrebno da se popravi nedostatak nalaenja problema ranije u procesu razvoja. Podaci projekta mogu dati bolju sliku o trokovima. Informacije u vezi sa tim, mogu se nai u procesu softverskog inenjeringa i oblastima znanja menadmenta softverskog inenjeringa (Software Engineering Process i Software Engineering Management KAs.) Na kraju, SQM izvetaji obezbeuju vredne informacije ne samo o tim procesima, ve i o tome kako se moe 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), matematike i grafike tehnike se mogu primeniti kao pomo u interpretaciji merenja. One spadaju pod naredne kategorije: Statistiki bazirane (na primer, Pareto analiza, takasti dijagrami, normalna raspodela) Statistiki testovi (na primer, binomni test, hi-kvadrat test) Analiza trenda Predvianja (na primer, modeli pouzdanosti)

Tehnike sa statistikom osnovom i testovi esto pruaju prikaz vie problematinih oblasti od softverskog proizvoda pod ispitivanjem. Rezultujui grafikoni su vizualna pomagala koja donosioci odluka koriste za
39

usmeravanje resursa gde su najpotrebniji. Rezultati analize trenda mogu da ukazuju da nije ispotovan raspored, kao to je testiranje, ili da odreene klase defekta postaju intenzivnije ukoliko se ne sprovedu korektivne akcije u razvoju. Tehnike predvianja pomau u planiranju vremena testa kao i u predvianju otkaza. Veliki broj diskusija na tu temu mogu se nai u procesu softverskog inenjeringa i oblastima znanja menadmenta softverskog inenjeringa (Software Engineering Process i Software Engineering Management KAs. Vie informacija o merenjima testova predstavljeno je u oblasti znanja testiranja softvera. Reference18 obezbeuju diskusiju o analizi defekta, koja se sastoji od merenja nastajanja defekata, i zatim primene statistikih metoda kako bi se razumeli tipovi defekata koji se najee pojavljuju, odnosno, odgovara se na pitanje u cilju ocene njihove gustine. Takoe pomau pri razumevanju trendova i toga koliko dobro rade tehnike, kao i kako napreduje razvoj i odravanje procesa. Merenja pokrivenosti testa pomau u proceni koliko preostaje napora da se izvri, i predviaju se mogui nedostaci koji e ostati. Za ove metode merenja, mogu se razviti profili nedostataka za odreenu oblast aplikacije. Tada, za naredni softverski sistem u okviru organizacije, profili se mogu koristiti za voenje SQM procesa, odnosno, za proirenje napora na mestima gde je najverovatnije da e problemi nastati. Slino tome, benchmark, ili brojanje greaka tipinih za tu oblast, moe sluiti kao jedna od pomoi u utvrivanju kada je proizvod spreman za isporuku. Diskusija o upotrebi podataka iz SQM-a radi procesa unapreenja razvoja i odravanja pojavljuje se u menamentu softverskog inenjerstva i oblastima znanja procesa softverskog inenjerstva (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

Zakljuak

Testiranje softvera predstavlja vanu komponentu razvoja aplikacija. Nedostatak strukturiranog i definisanog procesa testiranja moe da dovede do visokih trokova ispravljanja koda, probijanja budeta i nezadovoljnih klijenata. Takoe, sistematino testiranje pomae u smanjenju rizika i poveanju stepena kontrole. Testiranje softvera je umetnost. Veina metoda testiranja nisu mnogo drugaije od pre dvadeset godina. Te tehnike nisu jo zrele iako postoji mnogo dostupnih alata i tehnika za korienje. Kvalitetan proces testiranja takoe zahteva kreativnost, iskustvo i intuiciju, uz odgovarajue tehnike. Testiranje softvera je vie nego samo otklanjanje greaka. Testiranje se ne koristi samo da pronae defekte i ispravi ih. Takoe 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 reenja ili samo pojedine komponente. Testiranje je skupo. Automatizacija je dobar nain da se smanje trokovi 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 isporuen. Vreme i budet odluuju kad e se proces testiranja zavriti, ili ukoliko procena pouzdanosti softvera zadovoljava zahteve. Testiranje softvera moda nije najefikasniji metod poboljanja kvaliteta softvera i neke alternativne metode su moda ak i bolje. Nije mogue dokazati da je softver bez greaka ali se broj tih greaka moe svesti na minimum.

41

42