predgovor cigave potrebe naj bi ta knjiga zadovoljila potrebe preizkusevalcev in razvijalcev programske opreme s preizkusevalci mislim posmeznike ki redno testirajo od drugih programsko opremo ali ki jo trenutno delajo z razvijalci pa mislim posameznike ki programsko opremo redno razvijajo in jo trenutno tudi testirajo obadva tipa testirata programsko opremo in potrjujeta da deluje kot je potrebno ne glede na samo zgradbo to je pomen testiranja crne skatle ko vecina ljudi zacne testirati oz preizkusevati brez kakrsnega koli formalnega predznanja o snovi ponovno odkrijejo testiranje crne skatle alternativa med vedenjskim in funkcionalnim testiranjem to knjigo sem napisal da bi bilo osnovno znanje vedenjskega testiranja tehnik dostopno verjetnim uporabnikom name so vplivali prodajalci tehnik orodij ki so zgradili popacena orodja in bili razocarani ker njihovi preizkusevalci niso vedeli tehnik ki jih njihova orodja vsebujejo tu gre za mrtvo tocko vi preizkusevalci neradi investirate v ucenje tehnik kjer je vse avtomaticno razen ce ne gre za trgovsko orodje prodajalci pa ne morejo narediti glavnih investicij v razvoj orodij ki vsebujejo te tehnike dokler ne vidijo trga potencialnih preizkusevalcev ki vedo nekaj o vsebovanih tehnikah ta knjiga ima namen prekiniti mrtvo tocko in nima namena vstopiti z veliko literature o testiranju in ni nadomestilo za software testing techniques izdaja stt stt je strani razumljiva predstavitev testiranja knjiga je namenjena sirsemu obcinstvu od razvijalcev do preizkusevalcev do raziskovalcev in dodiplomskih ter podiplomskih studentov moja knjiga je premajhna za vse to stt je v ravnotezju med strukturnim in vedenjskim testiranjem moja knjiga pa se ukvarja le z vedenjskim testiranjem in tudi nima namena predstavljati teoreticne literature o testiranju programske opreme to je knjiga za vesce ljudi tega v moji knjigi ne nameravam ne bom tratil vasega casa in govoril da sta testiranje in kvaliteta pomembna tudi se ne ukvarjam z organizacijo managementom politiko financami kulturo ampak s preizkusanjem programske opreme ce se zelite nauciti tehnike vedenjskega testiranja z minimalno truda upam da vas ta knjiga ne bo razocarala manjkajoci modeli splosno za bralce predstavlja to poglavje literaturo o testiranju za bralce ki bi bili z mojimi tehnikami vedenjskega testiranja zbegani poleg tega so tu tudi logicno zasnovani modeli zadal sem si izdelati knjigo ki bi obsegala strani kar je obseg snovi za en semester ta knjiga je narejena kot nadomestilo knjige the art of software testing katera ima strani postalo mi je ocitno da primeri zavzamejo vec prostora kot pa sem pricakoval narediti knjigo s stranmi se je sprva zdelo nemogoce toda med delom sem ugotovil da bom prvotni material moral celo zmanjsati prvoten vir za podatke o seminarju so bili moji seminarji ljudje so zeleli te informacije udelezenci seminarjev so povedali katere tehnike naj bi bile za njih uporabne sedaj in katere v prihodnosti cez let vse te podatke sem zbiral in vzdrzeval stike s svojimi bivsimi studenti ter sponzoriral organizacije ki so ucile katere tehnike uporabljati to knjigo je vodil predvsem njihov odziv umetnost testiranja programske opreme the art of software testing ima namen vsebovati testiranje ki se razume skoraj dve desetletji smo se ukvarjali s testiranjem razvoja tehnologij tako da zvesti udelezenci ne bi bili preseneceni ce je bilo o vsem tem prevec receno v tej knjigi sem imel nacrt poskrbeti za predstavitev tehnik testiranja sodobni pogledi na tehnik ki jih obravnava myars logicno zasciteno testiranje logicno zasciteno testiranje se danes imenuje krmilni potek testiranja ta knjiga se bolj zanima za vedenjske crna skatla kot pa za strukturne bela skatla tehnike enakovredno locevanje vse tehnike testiranja v knjigi so snovane na ideji locevanja vseh moznih vlozkov v enakovredne razrede poglavje in pri vseh gre za metode locenega testiranja mayers se posebno povdarja pregledovanje kod in iz tega oblikovanje enakovrednih razredov za testiranje programov za vsak program se kreirajo posebne tehnike testiranja to je dobra ideja in nezmotno pravilna analiza mejnih vrednosti myersova razprava o analizi mejnih vrednosti spada med bolj splosna in mocna podrocja metod testiranja diagram vzrokov in posledic v praksi te tehnike dokazujejo tezavnostno stopnjo preizkusevalcev kateri nimajo potrebnega znanja o boolovi algebri in teorijah preklapljanja zmotno ugibanje kadarkoli izberemo tehniko testiranja vemo da lahko pricakujemo napake zmotno ugibanje ni tehnika testiranja ampak vidik vseh tehnik testiranja zmotno ugibanje ki temelji na programerjevih statisticnih napakah je dobra ideja in jo v sedanjosti uporabljamo pri izbiri specificnih metod testiranja logicno osnovani modeli logicno osnovani modeli vsebujejo diagram vzrokov in posledic elme myer modele odlocitvenih tabel beiz good in mnogo moznosti ki se uporabljajo ki se uporabljajo kot del razlicnih oblikovnih metodologij vse to so dobre tehnike vendar potrebujejo veliko strani za razlago to pa je ze drugo veliko poglavje ki bi postavilo obseg knjige preko enega semestra logicno osnovanega modela ne moremo proucevati brez boolove algebre in nima pomena proucevati boolove algebre ce ne znas karnaugh veitchove tabele tu ljudje ne bodo uporabljali boolove algebre brez nujno potrebnih orodij tisti ki poznajo boolovo algebro in karnaughov nacrt se lahko tenike naucijo kar sami lahko tudi iz stt rezultat logicno osnovanega testiranja je bilo vedno na dnu liste zazeljenih snovi mrtva tocka mojih studentov in sponzorjev scasoma so to snov odstranili iz seminarjev na testiranju ne bi smel obstajati samo en potek v mlajsih in starejsih letih ko imajo studentje potrebno znanje bi se bilo dobro zaceti ukvarjati z logicno osnovanimi modeli in tudi drugimi ki tu niso omenjeni jezikovno osnovani modeli veliko je modelov ki temeljijo na oblikovanju testov za jezike in pripadajoca orodja osnovni primeri so layc ostr balc belf davi kemm in rich te metode temeljijo na testiranju specificnih jezikov preizkusevalci izrazajo zahtevano vedenje oz obnasanje v teh jezikih jezikovni procesor preverja specifikacijo z dvoumnostjo in navzkriznostjo procesor nato avtomaticno generira testne primere pozitivne in negativne in specifikacije z veliko formalnimi in heuristicnimi tehnikami testiranja je kaj narobe s tem pristopom nic mislim da bo vedno vec testiranj narejenih s temi orodji ta orodja so kompleksna in jih ne moremo razumeti predno bi razumeli tehnike testiranja na katerih temeljijo testni generatorji drugi problem je fundamentalen kateremukoli programskemu jeziku ljudje so programskemu jeziku cobol napovedovali konec ze desetletja toda kot nesmrten vampir je se vedno z nami kaj se dogaja z pl in algolom uspeh operacij programskih jezikov nima nobene povezave z njihovo podedovano lastnostjo jeziki testiranja bodo imeli se bolj muhasto prihodnost upam da se bosta scasoma en ali dva jezika zdruzila za skupna orodja za uporabo potem bo cas za pisanje knjig o tem verjetno knjigo srednje stopnje vmesne stopnje readme doc zakaj readme doc bom imel jaz vec uspeha s tem da boste prebrali to poglavje v knjigi kot pa prodajalci programske opreme s podobnimi poglavji to poglavje je prirocno navodilo za knjigo od vas nisem nic drugacen dobim novo stvar preberem snov ki me interesira se s tem zacnem ukvarjati in ko eventuelno zaidem v tezave grem nazaj in preberem seznam readme doc in poiscem kje sem se zmotil torej naredimo to kot je treba strategija knjige ta knjiga ima strategijo poglavje govori o predvidevanju situacije vasega stanja v zvezi z vasim testiranjem za nekatere se lahko zdi ta snov idealna vendar je realna in vsebuje veliko sprememb v organizaciji za razvoj programske opreme in to je snov h kateri bi morali teziti daje vam vpogled kje ste in kam nameravate poglavje je potreben za poglavja in poglavje pa za in vecina vas je poucenih preizkusevalcev ki delate pod pritiskom tako da vas ne obtizujem ce zelite preskociti to poglavje poglavje zajema veliko novega znanja namesto da se nenehoma ponavljajo osnovne ideje v razlicnih oblikah v vsakem poglavju sem razvil ideja za enkratno testiranje v abstraktni obliki ki jo lahko uporabljam v vsakem poglavju ko razumete poglavje vas lahko poucim o tehnikah v ostalih poglavjih na le nekaj straneh to naredi knjigo manj obsezno in cenejso in vase znanje bolj ucinkovito poglavje do se ukvarja s specificnimi tehnikami ena tehnika in njena variacija je razlozena v vsakem poglavju ta poglavja sem skusal narediti cim bolj neodvisna med seboj graf prikazuje doloceno strukturo potrebnega znanja polna crta pomeni da morate razumeti material v poglavju da imamo popolno korist od tega poglavja crtkane crta pomenijo da potrebno znanje tega poglavja vsebuje definicije ki se bodo potrebovale v podpoglavju poglavje je potrebno znanje drugim poglavjem zadnje poglavje vsebuje definicije iz vseh poglavij zadnje poglavje vsebuje orodja in avtomatizacijo informacije za obsiren vodic za komercialno dostopna orodja lahko najdemo v daic grah sqet in v drugih podobnih vodicih poglavje o strukturi poglavja od do predstavljajo meso te knjige in imajo zelo podobno strukturo pregled kar poglavje izraza in se ne nanasa na kontekst poglavja slovar zunanje potrebno znanje izrazov za tehnicne izraze predvidevam da jih znate in ne bodo razlozeni v tej knjigi anglesko govoreci bralci bodo nasli veliko zelo osnovnih izrazov programske opreme moj namen je vkljuciti te osnovne izraze in pomagati bralcem katerih angleski jezik ni materin jezik ti izrazi jim bodo razbremenili breme pri prevajanju ce ne razumete izrazov ki so v ilustracijah ne bodite prevec zaskrbljeni ker vam bo v breme pri razumevanju tehnik testiranja slovar notranje potrebno znanje izrazov tehnicni izrazi za katere predvidevam da jih ze poznate in so razlozeni v prejsnjem poglavju slovar nove definicije tu so definicije ki naj bi se v poglavju uporabljale ko se definicije opisuje so v povdarjeni obliki definicije so predstavljene v logicnem zaporedju v katerem se poddefinicije nanasajo na prejsnje in naj bi jih brali v predstavljenem redu konflikti v slovarju vcasih boste videli izraz ki bo povdarjen v zunanje in notranje potrebnem znanju ali celo v novi definiciji tu gre predvsem za natancno definicijo o testiranju ki naj bi jo vedeli ce se pojavi izraz v notranje in zunanje potrebnem znanju pomeni da boste izraz razumeli predno boste prebrali knjigo in boste poglavje razumeli teksti se pojavijo v kontekstu v povdarjeni obliki kar pomeni da se od vas ne pricakuje da jih razumete toda tu ni definicije tega izraza in izraz se ne pojavi v poglavju v novem slovarju to pomeni da je izraz nekaj kar se bo definiralo v prihodnjih poglavjih model model na katerih temelji tehnika vsebuje vedenje programske opreme kar ignoriramo in kako predstavimo to vedenje predvidevanje napak vsako testiranje tehnik je osnovano na predvidevanju programske opreme zgradbe uporabnikih in napakah to poglavje vam daje vpogled v ucinkovitost tehnik v vasem primeru tipicne aplikacije tehnika kaj je kako deluje in zakaj deluje primeri tehnika od potreb do samih primerov testiranja ko je bilo mogoce sem zgradil primere ki temeljijo na standardu irs omejitve kaj lahko tehnika naredi in kaj ne izvlecek izvlecek poglavja vsebuje uvodni slovar med primerjanjem izvlecka in kratkega pregleda boste dobili dobro idejo kaj naj bi poglavje ponujalo kviz in vaje samoocenjevanja tu so vaje in vprasanja ki so primerna za to poglavje testiranja ne boste obvladali brez napora tudi predstavljeno terminologijo morate razumeti ker se pricakuje tudi v nasljednjih poglavjih testirajte sebe prav tako sem tudi tu izbral standard irs prav tako se tu pregleda ce ste izpolnili vsa potrebna vprasanja ce ste ze nekaj casa iz sole vam bodo dale te vaje dodatno znanje o racunanju vasih dohodnin ce ste student in se se nikoli niste ukvarjali z vasim dohodkom je cas da se naucite poleg tega pa so realni problemi testiranja veliko bolj kompleksni kot pa te vaje oblike dohodnine in njihova priporocila skiciral sem toliko tehnik kot sem lahko s tem da sem uporabil us federal income tax form iz leta kopije oblik uporabljenih v knjigi so v appendixu a te oblike definirajo zahteve ki jih testiramo skozi to knjigo sem predvideval da ko boste videli primer boste zraven videli tudi primerno obliko potrebno znanje bralcev predvideval sem doloceno vase znanje in izkusnje karkoli iz sledecega naj bi bilo dovolj eno ali vec let podiplomskega studija dve leti v racunalnistvu ali razvoju programske opreme tri ali vec let kot programer z delovnimi izkusnjami ce se trenutno ukvarjate s programiranjem pa ni pomembno kar steje je da vi znate osnovne principe programiranja in kako se to naredi bralci z izkusnjami v testiranju toda brez izkusenj v programiranju ne bodo imeli prednosti morali boste bolj delati da boste razumeli in znali raziskovati poglavje zunanje potrebno znanje vam pove kaj bi morali vedeti za vsako tehnologijo v dolocenem poglavju vecina ljudi njihovo znanje podcenjuje prej kot pa precenjuje opomba od bralcev ne pricakujem da bodo vedeli vse opombe obstajata dva tipa prvi je najpogostejsi in v tekst ne ustreza popolnoma drugi pa je za ucitelje in teoretike s komentarji te opombe so vedno v lezeci pisavi ne samo programska oprema iz prej omenjenega bi se pomislili da je knjiga namenjena samo razvijalcem in prezkusevalcem progrmske opreme vendar ni tako potrebno znanje je zelo sorodno tudi tehniki znanosti poslovanju in racunovodstvu testiranje crne skatle pomeni da nas v resnici ne zanima kako se procesi izvajajo ce ste npr biokemik in zelite povezati testiranje reakcij ki ste jih uporabljali v analizi krvi boste mogoce nasli za vas kaj koristnega ker je bolj malo verjetno da bo izsla knjiga o testiranju krvi uporaba kazala kazalo je obsirno vsako stevilo strani v kazalu ima nekaj svojega o snovi tudi opozorila so v kazalu vkljucena opozorila opozorila niso namenjena zadovoljiti uporabnikove potrebe ampak dajejo dodatne podatke o snovi in celo kontradiktorne podatke o snovi opozorila so bila zakljucena na acm konvenciji prve stiri crke so narejene iz avtorjevega imena kateremu sledi leto izdaje in crko iz abecede po vrsti ce je vec kot en tak avtor v letu beiz c je knjiga beizerja izdana leta in je to ze tretja stvar ki jo je beizer izdal v tem letu c kontrola kvalitete kvaliteta kontrole je vase delo od vas pricakujem da boste nasli napake in podali komentar v zvezi s tem tehnologija vse to se bolj omogoca posljite po fax u ali po e mailu vase komentarje kratek pregled prvo poglavje predstavlja besedisce ki ga uporabljamo pri testiranju in postavlja testiranje kot zelo pomembno fazo v razvoju programske opreme software besedisce testiranje programske opreme ima utrjeno besedisce definicije v tej knjigi so so izredno pomembne zato jih dobro preucite z uporabo le teh boste verjetno delali napake predhodno pomembni izrazi zdruzevanje algoritem analiziranje beta test razvejanje klic poklican klicanje klicni parametri koda kodiranje komunikacija primerjava prevajalnik kompleksnost racun zdruzjivost kontroliranje rusenje podatki podatkovna baza prekinitev prenosa podatkov integracija podatkov odpravljanje napak zamuda planiranje dolocanje razvijanje okolja razvijanje faz disk dokument odstranitev preiskus datoteka flowchart formalne analize funkcije globalni podatki harware hipoteze neodvisno testiranje instalacija interakcije kljucna beseda knjiznica makro vzdrzevanje upravljanje preslikava sporocilo matrika model modul vecupravilnost vecuporabnistvo objektivna navodila objektivno orientirano programiranje preslikava ena ena operacijski sistem izhod zmogljivost razvijanje softwara proces procesiranje program deli programa izjave programa programabilnost programer programiranje protokol kvaliteta zagotovilo kakovosti ram nakljucje zaloga realnost vir veckratna uporaba zaslon varnost zaporedje delitev podatkov simulator software logika softwara izvirna koda prostor izjava statisticni upravljanje s pomnilnikom podprogram podrutina podsistem poskusno orodje tabela prepustnost pravilo uporabnik vrednost spremenljivka objekt splosni izraz ki zavzema podatke in software stanje vrednosti vseh objektov v dani mnozici in v danem trenutku beseda state je pomen za specificiranje mnozice objektov in ali njihovih stanj na primer stanje enote stanje sistema stanje objekta initializacijsko stanje zacetno stanje stanje objekta pred testiranjem koncno stanje stanje objekta po testiranju vhod oznacuje vse stvari ki vstopajo v objekt primeri shranjeni podatki generirani podatki sporocilo potrebno je paziti na vse spremembe stanja objekta ki so priakovane in na pomanjkanje sprememb stanj ko le teh ne pricakujemo primeri novi zaslon napacen vhodni podatek nespremenjen zaslon izid predstavlja koncni rezultat testiranja primeri spremenjeni podatki objekta sporocilo novi zaslon sprememba stanj nespremenjeni objekt pomanjkljivost sporocila prazen zaslon pri testiranju morami biti zaskrbljeni ne le za izhodne podatke outpute temvec tudi za koncni izid to ni le semanticno nasprotovanje da zaslon ostane nespremenjen kot rezultat testiranja pomeni to koncni rezultat ceprav pri tem ne moremo govoriti o kakersnihkoli izhodih prav zaradi tega ne smemo pri testiranju vedno pricakovati outputa saj se nam bo tako v nasprotnem primeru mnogo testov zdelo neuporabnih vsa testiranja torej morajo imeti koncni izid oracle vsako sredstvo s pomocjo katerega lahko napovemo koncni izid testiranja howd nacrtovanje testiranja proces ki doloca objekte zacetna stanja inpute in napoveduje koncni izid in ali koncno stanje objekta zacetno stanje in input testiranje zajema izdelavo nacrta odpravljanje napak in izvajanje testov podtest najmanjsi del testiranja ki sestoji iz objekta zacetnega stanja inputa in napovedanega koncnega izida test eden ali vec podtestov izvedenih v zaporedju saj koncni izid in ali koncno stanje enega od podtestov predstavlja input in ali zacetno stanje naslednjega beseda test oznacuje podteste primerne teste serije testov zbirka testov skupek enega ali vec testov obicajno namenjena enemu samemu objektu s skupnim pomenom in podatkovno bazo obicajno izveden kot serija dvoumnost izjava je lahko dvoumna ce je poskus izveden tako da potrjuje ali pa izpodbija njeno resnicnost zahteve predstavlja nekaj kar naj bi se z objektom moralo zgoditi in ali karakteristike katere naj bi objekt imal izjave so lahko samovoljne vendar morajo biti del sestavka razumno zdruzene in opremljene in najpomembneje biti morajo dvoumne lastnost zazeleno obnasanje objekta izracunana vrednost ustvarjenega z objektom zahteve zdruzujejo lastnosti primer lastnosti so skupek primerov specifikacije obicajno so to delno izrazene zahteve primeri dokument seznam vseh zahtev protip zbirka testov specifikacije so obicajno nepopolne saj je zelo veliko zahtev nerazumljivih za primer software ne bo zrusil ali popacil podatkov najvecja napaka ki jo lahko stori preiskusevalec je predvidevanje da so vse zahteve izrazene s specifikacijami potrditev proces potrditve objekta prikazuje vse njegove ustrezne zahteve testiranje ni edina veljavna metoda ki naj bi jo uporabljali je le edina metoda ki je omenjena v tej knjigi wall dvoumnost proces potrditve objekta prikazuje da ne ustreza vedno vsem zahtevam kriterij potrditve uporablja se za prikaz pravilnosti ali dvomljivosti zahteve primeri ostra primerjava predvidenih vrednosti s specificnimi serijami vrednosti glede na zaporedje dogodkov izid ujemanja dejanski in predvideni izid se ujemata le z upostevanjem specificnih kriterijev potrjevanja testiranje pisave dokument program ali objekt je dolocen za vsak test podtest in zbirko testov testirani objekt zahteva ponavadi primer zacetno stanje inputi pricakovani izid in kriterij potrditve predznak iee failure vsako cudno obnasanje objekta ne le objekta pod testom tako kot dvomljivost zahteve ali napricakovano izvajanje procesov s proizvodom napaka iee fault zasnova napake ki se pojavi na simptomu objekta objekt pod testom ali kak drug objekt kadar je objekt podrejen ustreznemu testu test je uspesen ce je izvrsen kriterij potrditve pravilno uporabljen dejanski izid pa se ujema s predvidenim izidom in ne najdemo nikakrsnih simptomov test ni uspesen ce je izvrsen in se dejanski izid ne ujema s predvidenim izidom in ali se pojavijo simptomi vse to je lahko povzrocil napacen objekt napacen input napacno predvideni izid napacno zacetno stanje napacen kriterij potrditve napacne uporaba kriterija potrditve napaka v planiranju testiranja napak pri izvrsevanju testiranja in kar se mogoce cudno slisi napaka na testiranem objektu testirano objekt je uspesno testiran ko so bili vsi planirani testi izvrseni in se ni pojavil simptom ki bi ga opazili brez napak brezhibnost da je test brezhiben pravimo takrat ko smo prepricani da je sposoben prikazati simptome in njihove vzroke ki se pojavijo na drugih objektih v casu ko je v rabi dovolj majhno stevilo objektov trditev absolutne brezhibnosti je dvomljiva in zato ne more biti le ta tudi zahteva nakljucna pravilnosti uspesna izvrsitev vseh testov ne pomeni da je objekt brezhiben dejanski in predvideni izid se lahko ujemata a se kljub temu pojavijo napake v softwaru saj se izida ujemata le po nakljucju primer program naj bi izracunaval y x pa je napacno programiran in sicer y x vhodna vrednost za x naj bi bila bo rezultat y enak v obeh primerih kljub napaki pri programiranju za program pod tem testom pravimo da je nakljucno pravilen zaslepljenost vsaka metoda testiranja kratko testiranje z vsemi moznimi inputi v vseh moznih zacetnih stanjih je slape za napake ki so specificne za tako tehniko za primer veliko metod je slepih za nakljucno pravilnost enota najmanjsa stvar ki je lahko testirana obicajno je to prvo delo programerjev in ustreza najmanjsim delom prevajalnih programov tako kot podrutina enota kot testirani objekt ponavadi ne vkljucuje podrutin ali funkcij ki jih klice fiksnih tabel in podobnih stvari testiranje enote pri testiranju enote imenovane tudi podrutine in funkcije ki jih obravnavamo kot dele jezika kljucne besede klicane in klicanje komponente so predvidene za pravilno delovanje ali pa so nadomescene s simulatorji testiranje enote ponavadi izvede ustvarjalec enote napaka na enoti odkrijemo jo z dobrim testiranjem enote enota je komponenta komponenta je skupek ene ali vec komponent ki jo lahko testiramo kot celoto primeri enota podrutina funkcija makro program komunikacijske rutine in ves sistem softwara vmesnik med komponentami je sredstvo ki omogoca prenos podatkov primeri klicanje podrutin delitev podatkovnih objektov fizicni vmesnik sporocilo integrirani testi testi ki raziskujejo interakcije in obstoj uspesno testiranih enot to je komponenti a in b sta bili uspesno testirani komponenti integriramo v novo komponento c a b integrirane teste izvrsujemo za razikovanje obsotjecega agregata komponent obnasanje agregata na podlagi zdruzenega testiranja ponavadi vedno opazujemo z vidika vmesnika med komponentami integrirana napaka odkrijemo jo z dobrim integriranim testiranjem integracija proces integriranega testiranja odpravljanje napak na vmesniku in izpopolnjevanje popravljanja napak integracija lahko povzroci novo obliko obnasanja in s tem tudi nove napake ponavadi integracijo izvrsi ustvarjalec komponent ce je ustvarjalcev komponent vec integracijo izvrsi eden izmed njih testiranje komponent testiranje komponent se razlikuje od testiranja enote saj le to testiranje vkljucuje tudi klicalne komponente in podatke o objektu primeri testiranje rutin zdruzeno s klicanjem rutin testiranje rutine in fiksne tabele podatkov dobro testiranje komponent predvideva predhodno uspesno integracijo pomoznih komponent testiranje enote in integrirano testiranje takih komponent testiranje komponent ni enako testiranju enote saj so pri testiranju enote komponente ze integrirane napaka na komponenti odkrijemo jo z dobrim testiranjem komponent sistem sofware skupek komponent kjer je lahko nekater zahteve se vedno testirane ceprav jih nekaj od teh manjka ali pa so nerazumljive testiranje sistema je izvseno za raziskavo obnasanja sistema ki jo je nemogoce izvrsiti s testiranjem enote komponente ali integriranega testiranja primeri predstava instalacija integracija podatkov upravljanje s pomnilniki varnost zanesljivost pogoj za idealno testiranje je uspesna integracija vseh komponent testiranje sistema najveckrat opravijo neodvisni preiskusevalci napaka pri predstavitvi napaka za katero je kriva neustrezna ali skrcena predstavitev zmanjsana propustnost povecanje zamude napaka v varovanju napaka ki nepooblascenim uporabnikom poveca moznost dostopa do sistema le ta dovoljuje nepooblascen pregled in manipulacijo z datotekami izguba vira podatkov napaka ki povzroci izgubo dinamicno razporejenih virov podatkov kot je ram ali prostor na disku napaka na sistemu odkrijemo jo najlazje s testiranjem enote komponent ali integriranim testiranjem napako ki izhaja iz obnasanja ne moremo prisoditi posameznim komponentam ampak le celotnemu sistemu primeri napake pri predstavitvi napake v varovanju izguba vira napak modul podprogram program podsistem natancna izenacitev za komponente za grobo povecevanje obsega okolje kombinacija hardwara softwara in podatkov na podlagi katerih je komponenta oblikovana testirana in uporabljena vsebuje toda ne nujno klicne parametre klicane komponenete komponente operacijski sistem hardware prevajalnik vasi testi orodja seveda in vse drugo kar bi vpivalo na izvedbo komponent nekaj o testiranju poskusevalec in programer skozi knjigo boste lahko opazili podobnosti in razlike med preiskusevalcem in programerjem ce sta to dve osebi taksna nasprotja vas bodo verjetno vodila v prepri~anje da je testiranje s pomocjo crne skatle edino za neodvisne preiskusevalce in ne za prigramerje naslednje mocno prepricanje je moje razmisljanje o tem da bi testiranje in programiranje morala izvajati dva razlicna cloveka neodvisno testiranje zelim prepreciti in ali popraviti taksna razmisljanja programerji morajo nositi dva klobuka klobuk programerja in klobuk preiskusevalca ko opravljajo testiranje naj bi nosili klobuk preiskusevalca in mislili kot preiskusevalci to je za preiskusevalca za katerega sem napisal to knjigo torej preiskusevalec je lahko ali pa tudi ne ista oseba katera je napisala program dobra je govoriti o dveh vlogah ki naj bi jih opravljala dva razlicna cloveka saj sta si razmisljanje o testiranju in o programiranju popolnoma razlicni programsko razmisljanje je zelo staro o njem obstaja veliko knjig in zato nima smisla nanj dajati posebnega poudarka razmisljanje o testiranju pa je relativno novo in je zato nujno potrebno poudariti razliko med njima zakaj testiramo software software testiramo po naslednjem vrstnem redu programerje poucimo kako lahko prepricujejo napake podamo informacije o upravljanju ki so potrebne za ocenitev tveganja pri uporabi objekta doseci brezhibnost objekta v dani situaciji izdelati izvedljiv plan plan ki je lahko veljaven dvomljiv podvoumiti objekt z upostevanjem dolocenih in nedolocenih zahtev myer to imenujemo tudi razbijanje softwara uveljaviti objekt to je pokazati ljudem kako deluje kot drugo informacijo moramo voditi podatke o obsegu stevilo testov ki so bili uspesno izvedeni in stevilo neuspesno izvedenih tako imamo dve vrsti obsegov obseg uspesnih testiranj in obseg neuspesnih testiranj tako torej smo obdelali tri vrste objektov dobro planiranje dvomljivost in veljavnost vse kar je kdajkoli napisal clovek ima napake netestiranje necesa je enako zatrjevanju da je neka stvar brez napake programerji ne uspejo misliti na vse posebno ne na vse interakcije med lastnostmi in razlicnimi deli softwara poiskusamo podreti software saj je to edini prakticni nacin da dosezemo zeljeno zanesljivost ena od zadnjih stvari testiranje je zbiranje informacij o upravljanju z dovolj izkusenj in testiranja lahko izdelamo resnicno bolj udobnejsi software za uporabo v koncni fazi zakaj pa placujemo programerje zato da pomagajo zgraditi uporabni software najvecji cilj testiranja je podpora zagotavljanju kvalitete zbiranje informacij o tem kdaj programer prejme povretno informacijo izogibanje preteklim napakam in boljsi software v prihodnosti umazani test tudi negativni test test katerega glavni namen je ponarejanje to je izdelava testa za zrusenje softwara cisti test tudi pozitivni test test katerega glavna znacilnost je veljavnost to je izvrsitev testa za predstavitev pravilno delovanje softwara test je relavanten ce se rezultati izvrsitve ki vsebujejo napake kazejo v simptomih specifikacije naslavljajo le zahteve ki morajo biti veljavne za kar je bil objekt izdelan in ne nedolocene zahteve katere morajo poiskusiti ponarediti za kar objekt ni namenjen ker je stevilo stvari ki bi jih objekt moral opravljati omejeno stevilo stvari ki naj jih ne bi opravljal pa neomejeno mora cloveku zdrava pamet narekovati uporabo vecjega stevila umazanih testov to je primer v ucinkovitih zbirkah testov je razmerje med umazanimi in cistimi testi ali strategije testiranja strategija testiranja ali tehnika testiranja je sistematicna metoda ki jo uporabljamo za selekcijo in ali zdruzevanje testov v zbirko testov primeri nakljucno izbrani inputi testi na osnovi mojih obcutkov testi na osnovi tvojih obcutkov testi veljavnosti zahteve testi z namenov podvoumljanja podatkov testi v zadnjem trenutku testi razlicni od zadnjih potrebujemo strategijo ki vsebuje pravila s katerimi dolocimo ce je izvrseni test zadosten strategiji v principu bi vsaka strategija morala biti programabilna strategija je ucinkovita ce s testi ki so vkljuceni v strategijo lahko odkrivamo napake na objektu ucinkovitost take strategije je seveda odvisna od narave testov in od narave napak ki pripadajo testom kot v vojni in poslih obstajajo ucinkovite in neucinkovite strategije ker so objekti modificirani za popravljanje njihovih napak ali izboljsanje njihovih lastnosti vrst najdenih napak v objektu ki se scasoma spreminjajo pa vedno vec povecuje ucinkovitost strateskih sprememb medtem ko je teoreticno mozno da strategija proti specificnim objektom napreduje s casom je realno da vecina strategij s casom degradira strategija testiranja obnasanja temelji na zahtevah za primer testiranje vseh lastnosti omenjenih v specifikaciji izvsitev vseh umazanih testov ki pomenijo zahteve testiranje izvrseno v okviru testiranja obnasanja imenujemo vedenjsko testiranje vedenjsko testiranje imenujemo tudi testiranje s pomocjo crne skatle izraz funkcijsko testiranje uporabljamo tudi za vedenjsko testiranje vedenjsko testiranje lahko v principu vendar ne v praksi izvedemo neodvisno od sestave objekta tema te knjige je vedenjsko black box testiranje strategije testiranja struktur izhajajo iz strukture testiranega objekta basi beiz ntaf ostr primeri izvedba vsake izjave vsaj enkrat izvrsitev vsake veje stroke vsaj enkrat testiranje uporabe vseh podatkov objekta izvedba vsakega objekta za katerega nam je navodila posredoval prevajalnik testiranje izvrseno v okviru strategije strukturnega testiranja imenujemo tudi testiranje s pomocjo prozorne skatle ali testiranje s pomocjo bele skatle strategije strukturnega testiranja zahtevajo celoten dostop do strukture objekta to je do izvirne kode ta knjiga le povrsno obravnava tehnike strukturnega testiranja funkcijsko testiranje je izraz ki je najveckrat uporabljen v literaturi toda praktiki rajsi uporabljajo izraz testiranje s pomocjo crne skatle obstaja tudi starejsi in boljsi izraz v racunalniski znanosti vedenjsko testiranje problem z funkcijskem testiranjem je ta da se ta izraz uporablja se za nekatere specificne strategije kot strategije uporabljene v matematicnih funkcijah v tej knjigi bodo trije izrazi funkcijsko testiranje testiranje s pomocjo crne skatle in vedenjsko testiranje izmenicno uporabljeni z jasnim poudarkom na vedenjskem testiranju strategije mesanega testiranja so kombinacija vedenjskega in strukturnega testiranja clar rich med vedenjskim strukturnim in mesanimi strategijami ni nasprotij in za nobeno od teh strategij ne moremo trditi da je boljsa od druge enota in komponente na nizjem nivoju so pogosto testirane s pomocjo strukturnih strategij velike komponente in testiranje sistema se izvaja preko vedenjskih strategij mesane strategije so uporabne na vseh nivojih nobena od strategij ni boljsa od drugih saj je koristnost strategije odvisna od narave testiranega objekta narave napak ter objekta in stopnje znanja paradox pesticidov vecina od nas rada dosega zakljucke torej da ve kaj je bilo storjenega kaj od tega prav in da ve koliko casa bo potrebnega da se loti neke nove zadeve tako pa za software in njegovo testiranje ne moremo reci ce kot preiskusevalci vlozite ogromno energije za odkritje napak in ce je zagotovljena kvaliteta povpratnih informacij o vasih odkritjih do programerjev bo verjetnost za ponavljanje teh napak manjsa ce imajo dobri programerji dovolj casa in virov ki jih potrebujejo ponavadi upostevajo stvari ki jih odkrijejo preiskusevalci preiscejo software da bi odkrili in odstranili napake vse tehnike testiranja so bile privzete iz razlicnih narav napak ki se pojavljajo vsaka tehnika je dolocena za specificno vrsto napak ce se programerji odzivajo na testiranje in informacije o napakah z zmanj evanjem ali odpravljanjem napak njihov software napreduje to pomeni ko se vasi testi iztrosijo se boste morali nauciti izdelati in uporabljati nove teste ki bodo temeljili na novih tehnikah s pomocjo katerih boste lahko odkrivali nove napake narava napak in vzrok za pojav poglejte beiz in ansi za razsirjeno diskusijo o napakah in njihovih kategorijah glavni vzrok da uporabljam besedo bug rajsi kot uraden izraz fault ker izraz fault pomeni da je to napaka za katero nekdo odgovoren pomeni pomanjkanje zavesti pri programerjih njihova lenoba ali nesposobnost napake ki se pojavijo zaradi nesposobnosti programerjev ki delajo na sodobnem kooperativnem softwaru v ustreznem softwar skem razvijajocem se okolju niso krivda nikogar seveda ce zelite je lahko to krivda celega clovestva v dobrem zrelem softwaru napake povzroca kompleksnost in omejene cloveske sposobnosti obvladovanja kompleksnost in ne dvojnost v dobrem sofwaru razvitem v okviru dobrega procesa je vecina napak ki jih najdemo med vedenjskim testiranjem posledica nepredvidenih interakcij med komponentami ali med objekti imenujemo ga pesticidni paradox po pojavu poljedelstva kjer napake se scasoma prilagodijo in postanejo odporne na obstojece programe ki odkrivajo napake se bolj nevidne in zato zelo tezko popravljive prav zaradi tega je potrebno ves cas razvijati nove programe ki omogocajo odkrivanje tudi bolj odpornih napak ce so napake ki jih odkrijemo s pomocjo vedenjskega testiranja enostavne in lahko kategorizirane kazejo na neustrezen proces in ne na neustreznost programerjev predvidevamo namrec da so programerji z vidika zaupanja dobro izuceni da imajo na razpolago vsako potrebna orodja in da so kompetentni le te imenujemo kompetentne programerske hipoteze prav zaradi dejstva da oseba ki bo vrsila vedenjsko testiranje ni tudi napisala softwara si je potrebno to hipotezo zapomniti da proces progamiranja ne motijo osebne koristi in zamere programerja v sirsem smislu napake razdelimo v tri kategorije napake na enoti komponenti integracijske napake in sistemske napake imenovane po fazi razvijanja procesa pri katerem so napake najlazje vidljive napake na enoti komponenti najlazje odkrijemo in se jim tudi najlazje izogibamo ko testiramo sistem in se nam testiranje ne posreci ne moremo zagotovo trditi ali je neuspeh povzrocila enota integracija ali napaka na sistemu sele ko napako razresimo lahko ugotovimo njen vzrok ker je sistemsko testiranje veliko drazje kot testiranje enot komponent boeh vsaka napaka na enoti med sistemskim testiranjem stran vrzen trud pozitivna stran testiranja enote komponente je zmanjsanje stevila napak ki se kasneje pojavijo v fazah procesa integracijske napake je veliko tezje odkriti in jih preprecevati saj se pojavijo skozi interakcije med pravilnimi komponentami interakcije komponent so kombinatoricne to pomeni da stevilo narasca kot n kvadrat stevila vpletenih komponent ali slabse n to stevilo faktorsko integracijsko testiranje zagotavlja izredno majhno ce sploh kaksno stevilo nevarnih interakcij med komponentami ki ostanejo po sistemskem testiranju sisitemsko testiranje pomeni kvalitetno spremembo ceprav je bila med testiranjem enote komponente ali integracijskem testiranjem testirana ce vsaka lastnost je potrebno se enkrat ponoviti testiranje kot del sistemskega testiranja med testiranjem enote komponente ali integracijskem testiranjem ki ga izvajamo se lastnosti obnasajo deterministicno za sistemsko testiranje je znacilna dodatna kompleksnost multitaskinga postopoma tako kot so se stvari dogajale ne moramo vec zanesljivo predvidevati ta negotovost in stiska casa je draga resitev za celo bolj kompleksne napake glavna stvar sistemskega testiranja je potrditev da predvidevano obnasanje deterministicnega softwara ponavljamo v nedeterministicnem podrocju kdaj bo vse storjeno testiranje nudi neskoncno moznosti obeh teoreticnih in pragmaticnih ko moramo prenehati s testiranjem se moramo zavedati da napake ostanejo ce imamo zgodovinske podatke potem si je mozno izmisliti modele ki nam bi dajali informacije o tveganju ko testiranje prekinemo in software postavimo v donosnejse okolje haml musa ce ste v mojih besedah zacutili namig za svarilo si ga vzemite na srce kajti uveljavljanje takih modelov preprosto se ni ustavljena stvar kakorkoli pa napredek narasca vecina uporabnih modelov sluzi za zbiranje informacij med testiranjem posebno pri sistemskem testiranju del podatkov doloca kdaj je potrebno koncati s testiranjem ce inkompetentne programerje ne morete izuciti za kompetentnost se jih preprosto znebite ce je proces poln napak ga popravite in od nikor naj se ne pricakuje da bo polno produktiven brez ustreznega orodja testiranje s pomocjo crne skatle ni vse beiz whi vedenjsko testiranje ni edini test ki naj bi ga opravili nobeno posamezno testiranje ni dovolj ce upostevamo vse testiranje ki naj bi bilo izvrseno za software samo vedenjsko testiranje predstavlja od do odstotkov vsega testiranja relativna koristnost vedenjskega testiranja je odvisna od nacrtovanja ko je enkrat izdelan nacrt z vsem trdim kodiranjem lastnosti z veliko ad hod logike potem prevladujejo strukturne tehnike ko pa nacrtovanje temelji na splosnih algoritmih ki specificirajo obnasanje s podatki v tabelah ali s klicnimi parametri prevladujejo tehnike obnasanja pomembnost vedenjskega testiranja je enako pomembnosti razlicnih navigacijskih tehnik kaj je koristno je odvisno od tega kako blizu je kaka opora kaksna orodja imamo na razpolago dobro bomo delali dokler bomo tekmovali z mojim najbolj priljubljenim avtorjem nathanielom bowditch bowd pameten navigator se zanasa na eno samo tehniko vse ni le testiranje morali bi se veseliti ko nase testiranje odkrije napake hkrati pa bi morali za tem zalovati bodite veseli ena zaskrbujoca stvar manj bodite zalostni saj se proces softwara ni posrecil vendar kljub vsemu bodite veseli saj smo se naucili kako izboljsati proces in prepreciti ponaljanje napak v prihodnosti razvijali smo software vec kot let in ugotovili da je najpomembnejsih stavek ki smo se ga naucili naredite zgodaj boeh prej ko napako odkrijemo in popravimo cenejsi je popravek bolje je vec truda vloziti ce pred nacrtovanjem kot pa sele med izdelavo samega nacrta bolje je najprej vloziti trud v kodiranje ne sele po opravljenem kodiranju trud ki ga porabimo za testiranje enote je boljsi kot pa trud ki ga vlagamo v sistemsko testiranje kar pa je veliko bolje kot pa trud vlagati ze po instalaciji softwara o naprej omenjam nekaj ucinkovitih netestiranih aktivnosti po redu kot so se dogajale razvijanje prototipa prototip softwara je nepopolno opremljen software ki posnema obnasanje ki ga potrebujejo uporabniki stak glavno izdelave prototipov je dati uporabniku nekaj v roke za kar nam lahko pove ali je uporaben zanj in ce ga bo v primeru na e izdelave tudi kasneje kupil za prototip ni nujno da deluje in ponavadi tudi ne deluje izdelujemo software za uporabnike potrebno jih je zaplesti v razvoj cimprej saj se tako izognemo raznim nepotrebnim blodnjam o softwaru objektivno orientirano programiranje je pomembno pri vedenjskem testiranju jasno je da bodo tehnike vedenjskega testiranja bolj pomembne za software ki je izdelan preko odvisne knjiznice ponovno uporabnih objektov struktura katerih je pred nami preudarno skrita toda se vedno pa lahko izvedemo vec testiranj za doseg zanesljivih objektov bera nort analize zahtev zahteve vodijo planiranje yehr ce so zahteve neskladne je nacrt tezko popravljati analize zahtev pomenijo preverjanje zahtev za logicni samoobstoj sposobnost testiranja in izvrsevanja od uporabnikov ne moramo pricakovati da nam bodo posredovali samo izvedljive zahteve saj niso za to izuceni vsak izmed nas bi rad imel avto ki bi za prevozenih kilometrov potreboval le liter vode ne bi onesnazeval z njim bi se lahko peljalo odraslih oseb in bi ga bilo mozno parkirati na parkirni prostor m krat m vsi bi radi mercedes za ceno yugota naloga izdelovalcev softwara ni delati cudezev ali zadovoljiti vsako uporabnikovo kaprico naloga izdelovalca je izdelati vrednost za denar formalne analize ande babe hant wing ne smemo testirati vsega to posebej drzi za vedenjsko testiranje med stvarmi ki jih danes prakticno ne moremo vec testirati ce smo jih sploh kdaj lahko obstaja veliko razlicnih lastnosti ki vplivajo druga na drugo testiranje obnasanja softwara v vsaki mogoci instalaciji je naslednja nemogoca naloga vzroki za to so interakcije nasega paketa z ostalimi paketi vprasanje ali je nas software varen nakateri protokoli informacije in mnogi algoritmi kadarkoli obstaja kombinacija stvari ki testiranje delajo kompleksno ki se veca hiteje kot kompleksnost testiranega objekta formalne analize matematicne verjetnosti jo je bolje testirati se vedno potrebujemo nekaj testiranj za zagotovitev da je nasa analiza razumljivo brez napak nacrtovanje dobri nacrti imajo kar nekaj napak in so la`ji za testiranje preprostejse je izdelati nekaj cesar ne moremo testirati kot pa nekaj kar lahko testiramo lazje je nacrtovati nekaj kar ni mozno vzdrzevati kot pa nekaj kar poterebuje vzdrzevanje formalni pregledi faga gilb wein je ponavljanje potrjevanj kot glavna metoda za preprecevanje napak razvijanje softwara ki ne vsebuje formalnih pregledov je resnicno poln napak in je prevec odvisen od testiranja za odstranjevanje napak samotestiranje programerjevo samotestiranje je bolj ucinkovito kot kakrsnokoli drugo testiranje podobno skupinskemu testiranju je samo razvijanje softwara podobno je testiranje znotraj organizacije razvitega softwara boljse kot kako zunanje testiranje beta testiranje istega softwara to pa ne nasprotuje ideji da je neodvisno testiranje lahko bolj ucinkovito karkoli storimo v softwaru je nagnjeno k napakam formalni matematicni dokaz algoritemske pravilnosti je ranljivost do napak kot katerikoli drug cloveski proces to je preprosto dokazano razmisljanje v vseh clankih v matematicnih revijah ki so naslovljeni racunski primer teorije o ce neodvisni preiskusevalci ponavljajo testiranja ki so jih predhodno opravili razvijalci ne odkrijemo popolnoma nic novega in zato pomeni le majhno vrednost tako testiranje neodvisno ponavljanje razvijalcevih testiranj so uporabni le v primeru da so razvijalci incompetentni ali hudobni vse to pa nasprotuje nasim kompetentnim programerskim hipotezam namen neodvisnega testiraja je dobiti razlicne poglede razlicne teste naprej postaviti take teste v bogatejse in seveda kompleksnej e in dra`je okolje to kar je seveda mogoce za razvijalce namen samotestiranja je odstranitev napak ki se lahko pojavijo pri ni`jih stroskih v enostvnejsem deterministicnem okolju enote komponente ali pa na nizjem nivoju sistemskega testa orodja ko imamo enkrat na razpolago orodje prevajalnik nam ni vec potrebno iskati skladnosti napak s pomocjo izvirne kode nasi programski jeziki in prevajalniki so napredovali za odkrivanje celo bolj nenaravne napake kar je bilo vcasih trd oreh za clovestvo ce je napako lahko odkriti in ali popravljena naj bo avtomaticno popravljena nikoli ne zagovarjajte avtomatizacijo in orodja morali naj bi zagovarjati odkrivanje napak preko rocnih procesov ce slucajno avtomatizacija ni na voljo ce se pojavi luknja med orodjem ki ga dejansko uporabljajo programerji in preiskusevalci in orodjem ki so ga za njih izdelali raziskovalci enostavno poiskusitie zapreti luknjo verjemite izplaca se pa se dobickonosno je nedoseganje rezultatov ki bi jih preiskusevalci morali dobiti s testiranjem testiranje je hkrati tudi kontrola kvalitete zagotovilo kakovosti pomeni preprecevanje napak vedno je bolj dobickonosno preprecevanje napak kot pa njihovo popravljanje nas tekoci proces ceprav je lahko nepopoln je veliko boljsi od procesa desetletje nazaj ne programiramo vec softwara kot pred leti temvec nov nacin izdelave softwara prinasa vecjo kompleksnost napak seveda pa nasi uporabniki pricakujejo vedno boljso kvaliteto v zvezi s tem pa raztezanje na ih testnih sposobnosti in tehnik