7. Testovanie ------------- élohou testovania je overenie, Ÿi vytvorenì produkt vyhovuje po§iadavk m [DeMillo:1990]. Okrem zisœovania korektnosti programu (tzn. Ÿi program rob¡ to, Ÿo predpisuje çpecifik cia) je mo§n‚ pro testovan¡ overovaœ aj Ôalçie charakteristiky produktu: pou§ite–nosœ: pou§ite–nosœ je mo§n‚ definovaœ ako mieru splnenia pou§¡vate–ovìch potrieb. keÔ je korektnì produkt pou§¡vanì sp“sobom povolenìm jeho çpecifik ciou. Pou§ite–nosœ s£vis¡ s jednoduchosœou pou§¡vania, jeho praktickou vyu§ite–nosœou, vzœahom medzi cenou a poskytovanìmi slu§bami atÔ. spo–ahlivosœ: spo–ahlivosœ je mo§n‚ definovaœ ako mieru frekvencie a kritickosti zlyhania programu, ak toto zlyhanie nast va za podmienok povolenìch çpecifik ciou. Spo–ahlivosœ m“§e byœ vyjadren  v pojmoch strednej doby poruchy, strednej doby opravy poruchy, strednej doby opravy n sledkov poruchy (napr. na vìsledkoch) atÔ. robustnosœ: robustnosœ je mo§n‚ definovaœ ako mieru odolnosti voŸi nepriaznivìm vplyvom okolit‚ho prostredia na program. Tieto vplyvy m“§u zahråovaœ zadanie nepovolenìch vstupov, zmenu operaŸn‚ho prostredia (napr. vìmena typu tlaŸiarne), pr¡padne zlyhanie Ÿasti syst‚mu, napr. tlaŸiarne alebo zlyhanie niektor‚ho modulu. vìkonnosœ: vìkonnosœ bìva definovan  pomocou viacerìch dielŸich ukazovate–ov, napr. dobou odozvy, vy§adovanou pam„œou atÔ. Ka§d  z testovac¡ch strat‚gi¡ a techn¡k popisovanìch nesk“r pozost va zo çiestich z kladnìch krokov: 1. urŸenie Ÿo bude testovan‚. Pre ka§dì testovan¡m je potrebn‚ urŸiœ cie– testovania. Cie–om testovania m“§e byœ napr. testovanie koh‚zie modulu, spo–ahlivosti modulu, korektnosti modulu atÔ. 2. urŸenie ako sa bude testovanie vykon vaœ. Òalç¡m krokom je urŸenie sp“sobu, akìm sa bude syst‚m testovaœ na overenie vybranej vlastnosti. V Ôalçej Ÿasti sa budeme zaoberaœ r“znymi met¢dami testovania. 3. vytvorenie testovac¡ch vstupov. Po vìbere met¢dy je potrebn‚ urŸiœ, ak‚ bud£ testovacie vstupy pre jednotliv‚ testovan‚ pr¡pady. 4. definovanie oŸak vanìch spr vnych vìstupov. Je nesmierne d“le§it‚ vedieœ, ak‚ maj£ byœ oŸak van‚ vìstupy syst‚mu pre urŸen‚ testovacie vstupy. Predpovedan‚ vìstupy sa Ÿastokr t nazìvaj£ testovac¡m or kulom. 5. vykonanie testovania. V niektorìch pr¡padoch je potrebn‚ k vykonaniu testov vytvoriœ speci lne programy. Inak sa testovan‚mu syst‚mu zaved£ na vstup definovan‚ testovacie vstupy a zaznamenaj£ sa vìstupy. 6. porovnanie z¡skanìch a oŸak vanìch vìstupov. Akìko–vek rozdiel medzi skutoŸnìmi a oŸak vanìmi vìstupmi signalizuje chybu v syst‚me. V tejto Ÿasti sa budeme s£streÔovaœ najm„ na testovanie korektnosti programu. Testovaniu, resp. meraniun ostatnìch parametrov sa budeme venovaœ v Ôalç¡ch Ÿastiach. Testovanie korektnosti softv‚rov‚ho syst‚mu sa vykon va na dvoch £rovniach: testovanie jednotlivìch modulov a subsyst‚mov syst‚mu, integraŸn‚ testovanie cel‚ho syst‚mu a akceptaŸn‚ testovanie. Testovanie je aktivitou, ktor£ je potrebn‚ pripravovaœ poŸas cel‚ho vìvoja syst‚mu. Aktivity smeruj£ce k zabezpeŸeniu jednotlivìch druhov testovania syst‚mu je mo§n‚ v jednotlivìch etap ch zhrn£œ nasledovne: - çpecifik cia po§iadaviek: definovanie akceptaŸnìch krit‚ri¡ a z nich odvoden‚ho pl nu akceptaŸn‚ho testovania syst‚mu. Pl n testovania mus¡ definovaœ metodiku a postupnosœ testovania cel‚ho syst‚mu, ako aj testovacie d ta, oŸak van‚ vìsledku a sp“sob vyhodnocovania vìsledkov testu. Pri akceptaŸnìch testoch sa hodnot¡ nielen korektnosœ produktu, ale m“§e sa hodnotiœ aj jeho pou§ite–nosœ, spo–ahlivosœ, robustnosœ a vìkonnosœ. Tieto po§iadavky bìvaj£ definovan‚ v skupine kvalitat¡vnych po§iadaviek v çpecifik cii. - architektonickì n vrh: definuje dekompoz¡ciu syst‚mu na z kladn‚ subsyst‚my. Pre ka§dì subsyst‚m je potrebn‚ definovaœ testovacie proced£ry obdobne ako pre akceptaŸn‚ testovanie. V pr¡pade subsyst‚mov je vçak potrebn‚ definovaœ sp“sob pou§itia pomocnìch modulov, ktor‚ generuj£ testovacie £daje a prezetuj£ vìstupy subsyst‚mov. - podrobnì n vrh: podskytuje podrobn£ specifik ciu jednotlivìch modulov syst‚mu. Pre ka§dì modul je potrebn‚ definovaœ metodiku testovania, testovacie £daje a sp“sob vyhodnocovania vìsledkov testov. Testovanie modulov ------------------ Hlavnìm cie–om testovania modulov je overenie korektn‚ho k¢dovania modulu a overenie spr vnosti n¡m realizovanìch funkci¡. Pre testovanie modulov sa najŸastejçie pou§¡vaj£ techniky statickej analìzy, dynamickej analìzy, testovania Ÿiernej skrinky a testovania bielej skrinky, ktor‚ s£ pop¡san‚ nesk“r. IntegraŸn‚ testovanie --------------------- IntegraŸn‚ testovanie sa vzœahuje na overenie vlastnost¡ v„Ÿçej skupiny modulov, resp. cel‚ho syst‚mu. IntegraŸn‚ testovanie sl£§i na pokrytie dvoch oblast¡: - testovanie interfejsovania a integr cie modulov v syst‚me - testovanie funkŸnej vìkonnosti syst‚mu Pri integraŸnom testovan¡ sa pou§¡vaj£ styri z kladn‚ druhy testov: - çtrukt£rne testovanie je ve–mi podobn‚ testovaniu pomocou bielej skrinky na £rovni jednotlivìch modulov. Tento druh testovania zahråuje testovanie logiky integrovanìch modulov a obvykle obsahuje: - testovanie vstupnìch a vìstupnìch parametrov ka§d‚ho modulu - aktiv ciu vçetkìch modulov a vykonanie vçetkìch aktiv ci¡, vr tane aktiv cie podpornìch podprogramov - funkŸn‚ testovanie m  demonçtrovaœ, §e vçetky funkcie çpecifikovan‚ v po§iadavk ch s£ prev dzkovate–n‚. Pre funkŸn‚ testovanie sa Ÿasto pou§¡vaj£ techniky testovania Ÿiernej skrinky. Testovacie vstupy s£ Ÿastokr t nevrhovan‚ na z klade pou§¡vate–skìch manu lov. - testovanie vìkonnosti obsahuje zistenie strojovan‚ho Ÿasu spotrebovan‚ho pri vykon van¡ jednotlivìch funkci¡. Testy vìkonnosti by mali byœ navrhovan‚ tak, aby bolo mo§n‚ overiœ jednotliv‚ po§iadavky na vìkonnosœ syst‚mu v jeho çpecifik cii (napr. doba odozvy). - testovanie zaœa§enia sa zameriava na dosiahnutie limitnìch hodn“t integrovanej Ÿasti syst‚mu, ktor  by mala vydr§aœ zaœa§enie bez zr£tenia sa. Typickìm pr¡kladom testovania zaœa§enia je testovanie syst‚mu na rozsiahlych d tach. AkceptaŸn‚ testovanie --------------------- Cie–om akceptaŸn‚ho testovania je demonçtr cia, §e syst‚m je sp“sobilì k prev dzkovaniu. AkceptaŸn‚ testovanie je vo v„Ÿçine pr¡padov vykon van‚ z kazn¡kom, alebo n¡m poverenou osobou (nie tvorcom syst‚mu). AkceptaŸn‚ testovanie nasleduje po tom, Ÿo tvorca syst‚mu ukonŸ¡ integraŸn‚ testovanie cel‚ho syst‚mu. Potreba akceptaŸn‚ho testovania vyplìva z nasleduj£cich skutoŸnost¡: - aj testovanì softv‚r obsahuje 2-5 chìb na 100 riadkov zdrojov‚ho k¢du - a§ 50% vçetkìch chìb bìva spravidla odhalenìch pou§¡vate–om, a nie vìvojovìm a testovac¡m t¡mom 7.1. Zavedenie z kladnìch pojmov -------------------------------- Testovanie programu mo§no charakterizovaœ ako porovn vanie oŸak van‚ho spr vania sa syst‚mu so skutoŸnìm spr van¡m sa syst‚mu vo vybranìch situ ci ch. OŸak van‚ spr vanie sa syst‚mu popisuje çpecifik cia. æpecifik cia definuje mno§inu vstupnìch £dajov, ktor‚ je program (syst‚m) schopnì spracovaœ, tzn. dom‚nu programu D. Ak oznaŸ¡me symbolom d prvok z dom‚ny programu (d patri D), symbolop P proces reprezentovanì testovanìm syst‚mom a symbolom f oŸak van‚ spracovanie, je mo§n‚ zaviesœ nasledovn£ symboliku: * P (d) - matematick  idealiz cia spr vania sa programu P na d tach d f(D) - reprezent cia oŸak van‚ho spr vania sa syst‚mu na vçetkìch vstupnìch d tach * P (D) - reprezent cia skutoŸn‚ho spr vania sa vytvoren‚ho syst‚mu na vçetkìch vstupnìch d tach Po zaveden¡ tejto symboliky je mo§n‚ definovaœ korektnosœ programu (vytvoren‚ho syst‚mu): * Program je korektnì ak plat¡: P (D) = f(D) V zmysle zavedenej defin¡cie by malo byœ cie–om testovania preuk zaœ platnosœ uveden‚ho vzœahu. Prvìm probl‚mom je * preuk zanie rovnosti P (d) = f(d). V tomto vzœahu je problematick‚ urŸiœ hodnotu f(d), preto§e t to vyplìva zo çpecifik cie syst‚mu. Pre naçe potreby je vçak mo§n‚ predpokladaœ, §e met¢da z¡skavania f(d) bude urŸen , napr. pou§¡vate–om. Probl‚mov s overen¡m korektnosti programu je vçak viac. V praktickìch pr¡padoch Ÿastokr t je ve–mi obtia§ne preuk zaœ * platnosœ P (D) = f(D) pre cel£ dom‚nu programu. Pri testovan¡ sa predpoklad , §e po preuk zan¡ vzœahu pre vybran‚ vstupy, tzn. * preuk zan¡ vzœahu P (D') = f(D'), D' je podmnozinou D, je mo§n‚ zovçeobecniœ platnosœ korektnosti pre D. Znamen  to, §e na z klade platnosti: * f(d ) = P (d ) 0 0 * f(d ) = P (d ) 1 1 . . . * f(d ) = P (d ) n n * by sme radi predpokladali platnosœ f(D) = P (D). Z tohoto predpokladu vçak nie je mo§n‚ vych dzaœ vçeobecne. Ak poznaŸ¡me T mno§inu {d , d , ... ,d }, tak pre t£to mno§inu m“§e platiœ vzœah 0 1 n * f(T) = P (T), ktorì vçak nemus¡ platiœ d patri D - T. n+i Pre mno§inu testovac¡ch £dajov vçak je mo§n‚ definovaœ pojem spo–ahlivosti. Testovacia mno§ina T je spo–ahliv  pre program P, ak * platnosœ vzœahu P (T) = f(T) implikuje platnosœ vzœahu * P (D) = f(D) Spo–ahlivosœ testovacej mno§iny T pre program P umo§åuje predpokladaœ, §e ak je spr vanie sa programu pre prvky T v zhode s predpokladanìm spr van¡m sa syst‚mu, bude toto spr vanie sa zhodn‚ i pre vçetky mo§n‚ vstupy syst‚mu D. Probl‚mom vçak naÔalej ost va vìber spo–ahlivej testovacej mno§iny. Predpokladajme, §e existuje proced£ra C, ktor  pre program P vytvor¡ mno§inu (pr¡padne i nieko–ko mno§¡n) testovac¡ch £dajov. Aby t tto proced£ra generovala spo–ahliv£ testovaciu mno§inu, mus¡ samotn  proced£ra sp’åaœ podmienku spo–ahlivosti a platnosti. Uveden‚ pojmy je mo§n‚ definovaœ nasledovne: Proced£ra C sa nazìva spo–ahlivou, ak pre –ubovo–n£ dvojicu generovanìch testovac¡ch mno§¡n T a T plat¡, 1 2 * * §e P (T ) = f(T ) pr ve vtedy keÔ P (T ) = f(T ). 1 1 2 2 Proced£ra C sa nazìva platnou, ak v pr¡pade, §e program P nie je korektnì, generuje v testovacej mno§ine T * aspoå jeden prvok d, pre ktorì P (d) nerovna sa f(d). Spo–ahlivosœ proced£ry znamen , §e spr vanie sa programu bude ekvivalentn‚ na vçetkìch generovanìch testovac¡ch mno§in ch. Platnosœ proced£ry znamen , §e v pr¡pade chyby programu sa vyberie aspoå jeden vstup, na ktorom sa nespr vnosœ programu prejav¡. Existencia spo–ahlivej a platnej funkcie generuj£cej testovaciu mno§inu je ekvivalentn  korektnosti programu. V praktickìch pr¡padoch vçak je urŸenie vìberovej funkcie s po§adovanìmi vlastnosœami obœia§ne. Zav dza sa preto pojem adekv tnej testovacej mno§iny. T£to mno§inu je mo§n‚ definovaœ nasledovne: Testovacia mno§ina T sa nazìva adekv tna, ak pre * korektnì program P plat¡: P (T) = f(T) a pre vçetky * nekorektn‚ programy Q plat¡: Q (T) nerovna sa f(T) Adekv tnosœ testovacej mno§iny implikuje jej spo–ahlivosœ. T to implik cia vçak neplat¡ v opaŸnom smere. ¦ia–, v praxi nie s£ k dispoz¡cii vçeobecn‚ proced£ry vìberu testovac¡ch mno§¡n, ktor‚ sa vyznaŸuj£ vlastnosœami spo–ahlivosti a platnosti. Cie–om vìskumu v oblasti testovania je zameranie pozornosti na çpecifick‚ kateg¢rie chìb, pre ktor‚ je mo§n‚ vìberov‚ proced£ry so zodpovedaj£cimi vlastnosœami skonçtruovaœ. 7.2. Strat‚gie testovania ------------------------- Testovanie vytv ran‚ho syst‚mu je ch pan‚ ako samostatn‚ testovanie jednotlivìch modulov syst‚mu (napr. proced£r a podprogramov), po ktorom nasleduje integraŸn‚ testovanie zoskupen¡ modulov. Pre tento £Ÿel je potrebn‚ zoh–adniœ dva aspekty: n vrh testovac¡ch £dajov a koordin ciu testovania viacerìch modulov. Testovacie £daje m“§u byœ vyberan‚ na z klade analìzy çpecifik cie syst‚mu, alebo na z klade analìzy k¢du modulu. Testovacie strat‚gie vych dzaj£ce z uvedenìch pr¡stupov s£ "black-box" a "white-box" testovanie. Z h–adiska kombin cie modulov existuj£ dva z kladn‚ pr¡stupy: inkrement lny a neinkrement lny. Neinkrement lny pr¡stup predpoklad  nez visl‚ testovanie jednotlivìch modulov a ich integr ciu do syst‚mu bez n sledn‚ho testovania. Inkrement lny pr¡stup predpoklad  testovanie dan‚ho modulu po jeho integr cii do syst‚mu u§ otestovanìch modulov. Inkrement lny pr¡stup je pri testovan¡ pou§¡vanì castejçie. Umo§åuje skor£ detekciu chìb. Pri sp jan¡ modulov je mo§n‚ detekovaœ i chyby zaveden‚ v d“sledku integr cie modulov, ktor‚ nie je mo§n‚ neinkrement lnym testovan¡m detekovaœ. Pre inkrement lny pr¡stup sa vyu§¡vaj£ dve strat‚gie testovania: testovanie zhora-nadol a testovanie zdola-nahor. Obe uveden‚ strat‚gie predpokladaj£, §e vz jomn£ aktiv ciu jednotlivìch modulov je mo§n‚ reprezentovaì orientovanìm acyklickìm grafom. Pri testovan¡ modulov a subsyst‚mov je mo§n‚ k testovaniu modulov pristupovaœ dvoma sp“sobmi: testovanie met¢dou "Ÿiernej skrinky" (black-box) a testovanie met¢dou "bielej skrinky" (white-box). Akternat¡vnym pr¡stupom, zalo§enom na diagrame syst‚movej verifik cie je testovanie na z klade prel¡nania implement cie a testovania (mozaikov‚ testovanie). Jednotlivìm met¢dam sa budeme venovaœ podrobnejçie. Testovanie modulov met¢dou Ÿiernej skrinky ------------------------------------------ Pri testovan¡ modulov met¢dou Ÿiernej skrinky sa neuva§uje s vn£tornou çtrukt£rou testovan‚ho modulu. Tento sp“sob testovania sa Ÿasto nazìva i funkŸn‚, d tove, alebo vstupno-vìstupn‚ testovanie. Testovania sa obmedzuje na zistenie, Ÿi vstupno-vìstupn‚ spr vanie testovan‚ho modulu vyhovuje jeho çpecifik cii. Vlastnì k¢d modulu, tzn. logika modulu, sa pri testovan¡ nevyu§¡va. Testovacie £daje s£ preto odv dzan‚ priamo zo çpecifik cie programu. Nedostatkom met¢dy Ÿiernej skrinky je jej z vislosœ na korektonosti vstupnej çpecifik cie, ktor  v praxi nemus¡ byœ v§dy zachovan . Pre overenie spr vnosti testovan‚ho modulu je potrebn‚ modul testovaœ pre vçetky mo§n‚ vstupy vyplìvaj£ce zo çpecifik cie. Pri £plnom testovan¡ pomocou met¢dy Ÿiernej skrinky je potrebn‚ zo çpecifik cie odvodiœ mno§inu pr¡pustnìch vstupov a pre ka§dì vstup zodpovedaj£ci spr vny vìstup syst‚mu. V praxi vçak n m“§e kardinalita vstupnej mno§inu dosahonaœ 10 , Ÿ¡m Ÿas testovania m“§e byœ nieko–ko tis¡c a§ mili¢nov rokov. Z tohoto d“vodu sa pre vìber testovac¡ch vstupno-vìstupnìch p rov pou§¡vaj£ r“zne met¢dy, ktorìch cie–om je redukcia vstupnej mno§iny na prijate–n£ mieru. Jednotlivìm met¢dam sa budeme venovaœ podrobnejçie nesk“r, preto na tomto mieste uvedieme iba ich struŸn£ charakteristiku: Met¢da rozdelenia vstupnej mno§iny vych dza z mo§nosti rozdelenia vstupnej mno§iny vych dzaj£c zo çpecifik cie na triedy ekvivalenci¡, pre ktor‚ je spr vanie syst‚mu identick‚. Ka§d  trieda ekvivalencie m“§e byœ nahraden  jej typickìm predstavite–om, ktorì sa vyu§ije pri testovan¡. Proces testovania modulu vzh–adom k celej vstupnej mno§ine sa redukuje na proces testovania modulu vzh–adom na predstavite–om jednotlivìch tried ekvivalencie. Met¢da hraniŸnìch vstupov predstavuje vari ciu met¢dy rozdelenia vstupnej mno§iny. Ako testovacie d ta sa vyberaj£ prvky le§iace na hraniciach jednotlivìch tried ekvivalencie. Met¢da h dania chìb vych dza z existencie zoznamu mo§nìch chìb. Pre ka§d£ chybu sa zostroj¡ vstup, ktorì over¡ vìskyt danej chyby v module. KeÔ§e sa jedn  vo v„Ÿçine pr¡padov o ad-hoc pr¡stup, nie je mo§n‚ definovaœ §iadnu vìberov£ proced£ru. Met¢da n hodn‚ho generovania vstupov vych dza z n hodn‚ho generovania testovac¡ch £dajov. Pre konkr‚tny syst‚m je mo§n‚ pri generovan¡ testovac¡ch £dajov vyu§iœ inform cie o çtatistickej distrib£cii vstupov syst‚mu v prev dzke. T to met¢da sa vçak poklad  za jednu z najmenej spo–ahlivìch. Testovanie modulov met¢dou bielej skrinky ----------------------------------------- Pri testovan¡ modulov met¢dou "bielek skrinky" sa vych dza z logiky modulu. Cie–om testovania je vìber takìch testovac¡Ÿh vstupov, ktor‚ zabezpeŸia pokrytie Ÿo najv„Ÿçej Ÿasti logiky modulu. V praxi sa pou§¡va viacero krit‚ri¡ pokrytia: pokrytie pr¡kazov je zalo§en‚ na myçlienke, §e pri testovan¡ by mal byœ ka§dì pr¡kaz vykonanì aspoå raz. Pro vìbere testovacej mno§iny sa postupuje tak, aby jej prvky pokryli vçetky (alebo definovan£ Ÿasœ) pr¡kazov modulu. pokrytie ciest je zalo§en‚ na rozdelen¡ vstupnej mno§inu do menç¡ch celkov na z klade cesty, ktorou riadenie pro spracovan¡ vstupu bude prech dzaœ (anal¢gia met¢dy rozdelenia vstupnej mno§iny). Pre ka§d£ cestu sa do testovacej mno§iny vyberie jeden reprezentant. V praxi vçak poŸet mo§nìch ciest v programe m“§e byœ rozsiahly, preto je potrebn‚ redukovaœ prvky testovacej mno§iny na pr¡pustn£ mieru. Pr¡kladom poŸtu mo§nìch ciest je OBR.7.1. OBR.7.1. poŸet ciest v grafe pokrytie rozhodovac¡ch blokov predstavuje silnejçiu podmienku pokrytia ako pokrytie pr¡kazov. Vy§aduje sa, aby sa vçetky mo§n‚ vìsl;edky rozhodnut¡ v module vykonali aspoå raz. KeÔ§e ka§d  vetva programu sa vykon  aspoå raz, vykon  sa aspoå raz ka§dì pr¡kaz programu. Aplik cia uveden‚ho krit‚ria problematick  v pr¡pade, §e program nevykon va rozhodnutia, no m  viacero vstupnìch bodov. pokrytie podmienok predstavuje rozç¡renie pokrytia rozhodovac¡ch blokov v tom, §e ka§d  element rna podmienka v rozhodovac¡ch blokoch mus¡ byœ testovan  na vçetky mo§n‚ vìstupn‚ hodnoty. V pr¡pade pokrytia podmienok si vçak treba uvedomiœ, §e pokrytie podmienok nepredstavuje pokrytie rozhodovac¡ch blokov. Testovacie d ta pre jednotliv‚ podmienky nemusia pokrìvaœ vçetky rozhodovania. Testovanie zhora-nadol ---------------------- Testovacia proced£ra v tomto pr¡pade zaŸ¡na najvyçç¡m modulom v hierarchii a pokraŸuje modulmi na ni§ç¡ch £rovniach hierarchie. Pre simulovanie funkcie podradenìch modulov sa vyu§¡vaj£ tzv. simulaŸn‚ moduly, ktor‚ nahradia eçte neotestovan‚ moduly syst‚mu. Hoci neexistuj£ form lne krit‚ri  pre vìber postupnosti testovanìch modulov, je mo§n‚ uplatniœ niektor‚ specifick‚ pravidl . Ako pr¡klad je mo§n‚ uviesœ pravidlo pre kritick‚ moduly, tzn. moduly, na ktorìch podstatnou mierou z vis¡ funkŸnosœ syst‚mu. Tieto moduly by mali byœ bez chìb. Pravidlo doporuŸuje zapoŸaœ s testovan¡m tìchto modulov najsk“r ako je to mo§n‚. Najvìznamnejçou vìhodou testovania zhora-nadol je elimin cia samostatn‚ho testovania modulov a integraŸn‚ho testovania. Chyby v logike hierarchicky najvyçç¡ch modulov, ktorìch odstr nenie je Ÿasovo najn roŸnejçie, s£ identifikovan‚ pomerne skoro. Z tejto skutoŸnosti vyplìva pomerne rovnomern‚ zaœa§enie zdrojov poŸas cel‚ho procesu testovania. Medzi nevìhody testovania zhora-nadol vçak patr¡ potreba vytv rania simulaŸnìch (fikt¡vnych) modulov, ktor‚ po zaŸlenen¡ pr¡sluçn‚ho simulovan‚ho modulu do syst‚mu s£ nepou§ite–n‚. Òalçou nevìhodou testovania zhora nadol je skutoŸnosœ, §e je ve–mi obœia§ne testovaœ syst‚m, ktor‚ho vzœahy medzi modulmi nie je mo§n‚ reprezentovaœ pomocou acyklick‚ho orientovan‚ho grafu (napr. nepriama rekurzia v aktiv ccii modulov). Testovanie zdola-nahor ---------------------- Testovanie zdola-nahor sa zaŸ¡na u modulov na najni§çej £rovni hierarchie. I v tomto pr¡pade je potrebn‚ vytv raœ tzv. generaŸne moduly, ktor‚ simuluj£ nadraden‚ modulyy testovan‚ho modulu. GeneraŸn‚ moduly generuj£ testovacie d ta pre podraden‚ moduly. Po otestovan¡ modulov na ni§çej £rovni abstrakcie s£ generaŸn‚ modulu nahraden‚ skutoŸnìm modulom, ktor‚ho testovan¡m sa pokraŸuje. Vìhodou testovania zdola-nahor je pou§ite–nosœ met¢dy pre testovanie syst‚mu, v ktorom vzœahy medzi modulmi nie je mo§n‚ reprezentovaœ acyklickìm orientovanìm grafom. GeneraŸn‚ moduly v tomto pr¡pade sl£§ia iba na generovanie aktivaŸnìch parametrov modulu pre vçetky testovan‚ vstupy. V pr¡pade, §e kritick‚ moduly sa nach dzaj£ na najni§ç¡ch £rovniach hierarchie je t to met¢da vìhodn . Nevìhodou testovania zdola-nahor je skutoŸnosœ, §e §iadna predbe§n  verzia syst‚mu nie je k dispoz¡cii dovtedy, pokia– nebol otestovanì poslednì modul. N vrh, implement cia a testovanie nie je mo§n‚ prekrìvaœ, preto§e najni§çie moduly sa testuj£ prv‚, priŸom sa navrhuj£ ako posledn‚. Najz va§nejçie chyby predstavuj£ chyby v logike syst‚mu. Tento druh chìb sa pri tejto met¢de testovania identifikuje neskoro, preto zaœa§enie program torov pred pl novanìm koncom projektu m“§e byœ ve–mi ve–k‚. Mozaikov‚ testovanie (Thread testing) ------------------------------------- Mozaikov  testovanie je zalo§en‚ na diagrame syst‚movej verifik cie, ktorì je priamo odvodenì zo çpecifik cie syst‚mu. V tomto pr¡stupe sa vytv ranie a testovanie prekrìva, tzn. neprebieha ani samostatne ani sekvenŸne. Postup pr c na k¢dovan¡, testovan¡ a ontegrovan¡ jednotlivìch Ÿast¡ je urŸenì diagramom verifik cie syst‚mu (DVS). DVS segmentuje celì syst‚m do z kladnìch a pou§¡vate–ovi preuk zate–nìch element rnych funkci¡ (threads). Vìvoj jednotlivìch element rnych funkci¡ je urŸenì harmonogramom. V s£lade s n¡m sa k¢duj£ a testuj£ jednotliv‚ moduly, spojen‚ s realiz ciou danej element rnej funkcie. Element rne funkcie s£ n sledne integrovan‚ do vyçç¡ch Ÿast¡ - blokov (builds), ktor‚ reprezentuj£ z va§n‚ ciastky schopnost¡ vytv ran‚ho syst‚mu. Integr cia do blokov konŸ¡ integr ciou cel‚ho syst‚mu. Mozaikov‚ testovanie sa vyu§¡va pri testovan¡ softv‚ru pracuj£ceho v realnom Ÿase. Kritick‚ Ÿasti m“§u byœ napl novan‚ ako prv‚ v harmonograme pr c vyplìvaj£ceho z diagramu verifik cie syst‚mu. 7.3. Techniky testovania ------------------------ Techniky testovania sl£§ia pre spresnenie jednotlivìch strat‚gi¡ testovania. Spesnenie m“§e byœ ch pan‚ v zmysle defin¡cie sp“sobu vìberu testovac¡ch £dajov, alebo urŸenia sp“sobu overenia istìch po§iadaviek v çpecifik cii. Jednotliv‚ techniky budeme analyzovaœ podrobnejçie. 7.3.1. Statick  analìza ----------------------- Statick  analìza predstavuje analìzu k¢du programu, bez jeho skutoŸn‚ho vykonania. T to analìza m“§e byœ vykon van  ruŸne, alebo automaticky. T to technika sa vçak obmedzuje iba na analìzu referenci¡ na polia, smern¡ky a Ôalçie dynamick‚ objekty. Merania uk zali, §e statickou analìzou je mo§n‚ odhaliœ 30 - 70% chìb v logike a k¢dovan¡ programu. Statick  analìza sa najŸastejçie realizuje inçpekciou, prehliadka a analìza k¢du. Tieto techniky sa vykon vaj£ v skupine inçpektorov, ktorìch £lohou je odhaliœ odchìlky k¢du od jeho çpecifik cie. Inçpekcia k¢du predstavuje mno§inu proced£r, ktorìch £lohou je identifik cia chìb poŸas spoloŸn‚ho prech dzania k¢dom modulu. Pri ka§dom module je potrebn‚ vykonaœ dve aktivity: program tor najsk“r podrobne vysvetl¡ logiku modulu a n sledne sa modul analyzuje vzh–adom na zoznam najŸastejçie sa vyskytuj£cich program torskìch chìb (napr. chyby pri vìpoŸte a porovn van¡, nerieçen‚ vetvenia atÔ.). Prehliadka k¢du je podobn‚ inçpekcii, no proced£ry pre identifik ciu chìb s£ in‚. Na spoloŸnom stretnut¡ inçpektorov je analyzovan  logika modulu vzh–adom k jeho çpecifik cii. Analìza sa vo v„Ÿçine pr¡padov vykon va s vybranìmi testovac¡mi £dajmi. Analìza k¢du sa najŸastejçie vykon va pomocou statick‚ho analyz tora. Tieto prostriedky kontroluj£ tok £dajov a zaznamen vaj£ chyby ako nenainicializovan‚ premenn‚, nekonzistentn‚ interfejsy medzi modulmi, nikdy nevykon van‚ pr¡kazy atÔ. Na z klade tìchto chìb je mo§n‚ odv dzaœ dalçie chybov‚ charakteristiky modulu. Experiment lne vìsledky s pou§it¡m met¢d statickej analìzy ukazuj£, §e kombin ciou met¢d inçpekcie a prehliadky k¢du je mo§n‚ identifikovaœ 30-70% chìb v programe. Kombin ciou met¢d inçpekcie k¢du a analìzy k¢du je mo§n‚ pod–a niektorìch zdrojom identifikovaœ a§ 90% vçetkìch chìb v programe. 7.3.2. Symbolick‚ testovanie ---------------------------- N zov symbolick‚ho testovania je odvodenì od skutoŸnosti, §e poŸas testovania s£ hodnoty vstupov a programovìch premennìch symbolick‚. Symbolick‚ vstupy zodpovedaj£ triedam skutoŸnìch hodn“t vstupov. Vìstupmi symbolick‚ho testovania s£ symbolick‚ formuly alebo predik ty, definuj£ce spr vanie syst‚mu pre danì symbolickì vstup. Spracovanie vstupov z vis¡ od podmienok, ktor‚ sp–åaj£ vstupn‚ udaje. Z tohoto d“vodu je spracovanie symbolickìch vstupnìch £dajov reprezentovan‚ vyhodnocovac¡m stromom. Tento pozost va z uzlov reprezentuj£cich vykon van‚ pr¡kazy a z hr n reprezentuj£cich tok riadenia v programe. Ka§d  cesta v programe (strome vykon vania) je charakterizovan  akumul torom vlastnost¡ vstupov, ktor‚ s£ potrebn‚ pre vìber a vykonanie danej cesty (postupu spracovania) v programe. Tento akumul tor sa nazìva aj podmienka cesty v strome (path condition). Z kladom symbolick‚ho testovania je interpret, nazìvanì symbolickì vyhodnocovaŸ. Tento syst‚m spravidla pozost va zo symbolick‚ho interpr‚ta a zjednoduçovaŸa vìrazov. Pre danì symblickì vstup generuje interpret symbolickì vìstup, viazanì k vlastnostiam ved£cim k dan‚mu vìstupu (napr. a>b), ktor‚ nie je mo§n‚ rozhodn£œ striktne symbolickìm vyhodnoten¡m. Symbolick‚ vyhodnocovanie ------------------------- Symbolick  hodnota m“§e byœ element rna symbolick  hodnota (napr. a), alebo symbolickì vìraz (napr. a+b). Pr¡klad symbolick‚ho vyhodnocovania pre jednoduch£ proced£ru je ilustrovanì na OBR.7.2. OBR.7.2. - symbolick‚ vyhodnocovanie Symbolick‚ vykon vanie programu zaŸ¡na priraden¡m symbolickìch hodn“t vstupnìm premennìm. Symbolick‚ vyhodnocovanie je mo§n‚ pre jednotliv‚ typy pr¡kazov definovaœ nasledovne: PriraÔovac¡ pr¡kaz: vìraz na pravej strane sa vyhodnot¡ na z klade pravidiel o symbolickom vyhodnocovan¡ a zjednoduçovan¡ vìrazov. Vìsledn  hodnota vìrazu sa prirad¡ ako symbolick  hodnota premennej referencovanej na –avej strane pr¡kazu. Podmienenì pr¡kaz: vyhodnot¡ sa logickì vìraz definuj£ci podmienku vetvenia, priŸom sa vyu§ije podmienka cesty charakteristick  pre uzol reprezentuj£ci podmienenì pr¡kaz. Pokia– symbolickì vyhodnocovaŸ vyhodnot¡ logickì vìraz na hodnotu true alebo false, prejde sa k vykonaniu pr¡sluçnej alternat¡vy podmienen‚ho pr¡kazu. V pr¡pade, §e po vyhodnoten¡ predstavuje podmienka vìraz, je potrebn‚ prejsœ k vyhodnocovaniu oboch alternat¡v. Pri vytv ran¡ vyhodnocovacieho stromu to znamen , §e vrchol reprezentuj£ci podmienenì pr¡kaz bude maœ dvoch nasledovn¡kov. Podstromy podmienen‚ho pr¡kazu bud£ maœ oproti vrcholu reprezentuj£ceho podmienenì pr¡kaz rozç¡ren£ podmienku cesty (path condition) o vyhodnotenie podmienky vetvenia, resp. o neg ciu tejto podmienky. Strom vykon vania ----------------- Strom vykon vania reprezentuje mo§n‚ alternat¡vy symbolick‚ho vyhodnocovania dan‚ho programu. Pozost va z uzlov reprezentuj£cich jednotliv‚ pr¡kazy programu a hr n reprezentuj£cich tok riadenia pri vykon van¡ programu. Kazdì uzol je charakterizovanì podmienkou, ktor  definuje vlastnosœ vstupnìch £dajov, pre ktor‚ bude vykon van  dan  vetva stromu. Uzly spojen‚ s priraÔovac¡m pr¡kazom maj£ jedn‚ho nasledovn¡ka. Ak nie je mo§n‚ logickì vìraz v podmienenom pr¡kaze vyhodnotiœ na hodnotu true alebo false, bude maœ zodpovedaj£ci uzol dvoch nasledovn¡kov. Stav spracovania pre ka§dì uzol grafu m“§e byœ charakterizovanì taktie§ hodnotami vçetkìch premennìch programu. Vyhodnocovac¡ strom pre jednoduchì program je ilustrovanì na OBR.7.3. OBR.7.3. - vyhodnocovac¡ strom V pr¡klade je ilustrovan‚ praktick‚ vyu§itie symbolick‚ho vyhodnocovania vìrazov. V pr¡pade druh‚ho podmienen‚ho pr¡kazu je mo§n‚ logickì vìraz reprezentuj£ci podmienku vetvenia vyhodnotiœ na logick£ hodnotu, preto nie je potrebn‚ dalçie spracovanie na z klade tejto podmienky vetviœ. Vìhodou symbolick‚ho testovania vzh–adom ku konvenŸn‚mu testovaniu je, §e symbolick‚ testovanie programu je ekvivalentn‚ testovaniu programu s rozsiahlou mno§inou skutoŸnìch testovac¡ch £dajov. T to vìhoda vçak je diskutabiln  v pr¡pade, §e testovanì program je rozsiahly. V tom pr¡pade je aj vyhodnocovac¡ strom rozsiahly a nemo§no ho presk£maœ celì. ætrukt£rovan‚ programovanie predstavuje jedno z mo§nìch rieçen¡ tohoto probl‚mu. Program je mo§n‚ dekomponovaœ do modulov, pre ktor‚ je mo§n‚ vytv raœ samostatn‚ stromy vyhodnotenia. D“kaz korektnosti ----------------- Symbolick‚ testovanie je mo§n‚ vyu§iœ i pre vytv ranie d“kazov korektnosti programov. Symbolickìm testovan¡m je mo§n‚ priradiœ vstupom, vìstupom a jednotlivìm cyklom logick‚ podmienky, ktor‚ musia byœ splnen‚. Program je preto mo§n‚ ch paœ ako mno§inu "rezov" s priradenìmi tvrdeniami o vlastnostiach premennìch b danom bode rezu. Verifik cia sa potom d  previesœ na d“kazy korektnosti ciest medzi susednìmi rezmi. T to verifik cia pozost va z nasleduj£cich krokov: 1. Predpoklad  sa, §e tvrdenie v poŸiatoŸnom bode rezu cesty je splnen‚ 2. Symbolicky sa vykonaj£ pr¡kazy na ceste medzi susednìmi bodmi rezu 3. Ak z platnosti 1 a na z klade vìsledku 2 je mo§n‚ odvodiœ platnosœ tvrdenia v bode rezu na konci analyzovanej cesty, potom je analyzovan  cesta korektn‚. V opaŸnom pr¡pade nie je. Symbolick‚ testovanie je pou§¡van‚ v mnohìch prostriedkoch pre podporu testovania. Na z klade praktickìch experimentov sa z¡skal £daj, §e pomocou symbolick‚ho testovania je mo§n‚ odhaliœ priemerne 15 z 22 chìb. 7.3.3. Testovanie pomocou mut ci¡ programu ------------------------------------------ Mut cia programu predstavuje techniku merania adekv tnosti mno§iny testovac¡ch £dajov. Adekv tna mno§ina pro program A je tak , ktor  d va spr vne vìsledky pre spr vny program, no nespr vne vìsledky pre vçetky nespr vne programy. Predpokladajme, §e pre program P bola vybran  testovacia mno§ina D. Pre program P sa definuje mno§ina mutantov programu P - M(P), pozost vaj£ca z mno§iny programov, ktor‚ sa od P odliçuj£ jedinou chybou. Mno§ina mutantov sa vytv ra na z klade zoznamu najŸastejçie sa vyskytuj£cich program torskìch chìb. Niektor‚ z mutantov z M(P) m“§u vykazovaœ identick‚ spr vanie ako program P. Budeme ich nazìvaœ ekvivalentn‚ mutanty. Symbolom E(P) budeme oznaŸovaœ mno§inu ekvivalentnìch mutantov programu P. Bud£ vçak existovaœ mutanty, ktorìch vìstupy pre £daje z testovacej mno§ine d t D sa odliçuj£ od vìstupov programu P. T£to skupinu mutantov budeme oznaŸovaœ symbolom DM(P,D). Pod pojmom mutaŸn‚ sk¢re budeme rozumieœ podiel neekvivalentnìch mutantov k celkov‚mu poŸtu mutantov. Ak symbolmi m, a dm oznaŸ¡me poŸet prvkov v M(P) a DM(P,D), je mo§n‚ mutaŸn‚ sk¢re pre P a D vyjadriœ nasledovne: ms(P,D) = dm / (m - e) MutaŸn‚ sk¢re predstavuje hodnotu z intervalu <0,1>. MutaŸn‚ sk¢re bl¡zke hodnote 1 identifikuj, §e testovacia mno§ina D je bl¡zko k adekv tnosti vzh–adom k programu P. N¡zke mutaŸn‚ sk¢re identifikuje "slabosœ" testovacej mno§iny D, tzn. testovacia mno§ina nie je schopn  odl¡çiœ program P od programu P', ktorì obsahuje chyby. Testovanie pomocou mut ci¡ patr¡ do skupiny testovac¡ch techn¡k vych dzaj£cich zo znalosti najŸastejçie sa vyskytuj£cich typov program torskìch chìb. Cie–om tohoto pr¡stupu k testovaniu je overiœ existenciu vybranìch druhov chìb. Testovanie na z klade zn mych chìb predstavuje heuristickì pr¡stup k testovaniu. Testovanie pomocou mmut ci¡ m  nieko–ko vari ci¡. Medzi najzn mejçie vari cie patria: - mutantn‚ oper tory - Ÿiastkov  mut cia - mutaŸn‚ testovanie stopy MutaŸn‚ oper tory ----------------- MutaŸn‚ testovanie pomocou mutaŸnìch oper torov predstavuje automatickì pr¡stup ku generovaniu mutantov. Mno§ina mutaŸnìch oper torov sl£§i na generovanie mut ci¡i programu, na ktor‚ sa aplikuje testovacia mno§ina vstupnìch £dajov. Pomocou vìstupov generovanìch mutantami sa urŸ¡ mutaŸn‚ sk¢re. MutaŸn‚ oper tory s£ odvoden‚ na z klade pozorovania najŸastejçie sa vyskytuj£cich program torskìch chìb. Mutant sa z¡ska aplik ciou pr ve jedn‚ho mutaŸn‚ho oper tora na p“vodnì program. Predpoklad, §e vìskyt preva§nej v„Ÿçiny chìb v programoch mo§no reprezentovaœ zaveden¡m jednoduchej chyby do programu (aplik ciou pr ve jedn‚ho mutaŸn‚ho oper tora), sa nazìva predpoklad kompetentn‚ho program tora. Obmedzenie mutantov na zavedenie jednej chyby do programu je vìsledkom empirickìch analìz chìb vznikaj£cich pri programovan¡. ¬iastkov  mut cia ----------------- Pri Ÿiastkovej mut cii s£ mutantn‚ oper tory aplikovan‚ na jednoduch‚ komponenty programu. MutaŸn‚ sk¢re je v tomto pr¡pade vypoŸ¡tavan‚ ako podiel neekvivalentnìch Ÿiastkovìch mutantov, tzn. mutantov, pre mutovan  Ÿiastka programu d va odliçn‚ vìsledky od p“vodn‚ho programu. V pr¡pade Ÿiastkovej mut cie si vçak treba uvedomiœ, §e celì program m“§e generovaœ spr vny vìystup, hoci jeho mutovanì komponent generuje nespr vny vìsledok. Vysok‚ mutaŸn‚ sk¢re pre Ÿiastkov£ mut ciu preto neznamen , §e triedy chìb reprezentovan‚ jednotlivìmi mutaŸnìmi oper tormi v programe neexistuj£. Testovanie pomocou Ÿiastkovej mut cie m  vçak nieko–ko prednost¡: - Ÿiastov‚ testovanie umo§åuje vyu§itie efekt¡vnejç¡ch met¢d pre urŸenie mutaŸn‚ho sk¢re.k - keÔ§e s£ mut cie definovan‚ vzh–adom na komponenty programu, je mo§n‚ pop¡saœ a-priori testovacie £daje, ktor‚ sp“sobuj£ zlyhanie programov‚ho komponentu nez visle od zvyçku programu MutaŸn‚ testovanie stopy ------------------------ Pri mutaŸnom testovan¡ stopy s£ mutaŸn‚ oper tory aplikovan‚ na p“vodnì program identicky, ako v pr¡pade mutaŸnìch oper torov. Pri porovn van¡ vìsledkov mutovanìch programov a p“vodn‚ho programu sa vçak porovn vaj£ stopy vìpoŸtu, nie iba jednoduch‚ vìsledky. Pri tomto sp“sobe porovn vania mutovanìch programov s p“vodnìm nie je potrebn‚ uva§ovaœ s kompetentnìm program torom, tzn. s mo§nosœou vìskytu jedinej chyby v programe. Nevìhodou mutaŸn‚ho testovania stopy vçak ost va obtia§nosœ automatiz cie tohoto procesu. Identifik cia identickìch st“p vìpoŸtu predstavuje probl‚m s vysokou vìpoŸtovou n roŸnosœou. MutaŸn‚ testovanie vo svojej podstate nepredstavuje skutoŸn£ testovaciu techniku. Je to metrika pre vyhodnocovanie adekv tnosti testovac¡ch £dajov. V spojen¡ s met¢dou pre generovanie testovacej mno§iny pom ha urŸiœ kvalitu generaŸnej proced£ry z h–adiska generovania adekv tnej mno§iny £dajov. 7.3.4. RozŸleåovanie vstupnej mno§iny ------------------------------------- Z kladnou myçlienkou met¢dy rozŸleåovania vstupnej mno§iny je rozŸlenenie vstupnej mno§iny na dom‚ny, pre prvky ktorìch je spr vanie sa programu identick‚. Testovacia mno§ina m“§e byœ potom redukovan  na jeden reprezentat¡vny prvok pre ka§d£ identifikovan£ dom‚nu. Na vytvorenie dom‚n vstupnnìch £dajov je mo§n‚ pou§iœ vìpoŸtov‚ cesty v strome vyhodnocovania programu. VìpoŸtov  cesta v strome vyhodnocovania pozost va z mo§nìch tokov riadenia pri spracov van¡ vstupnìch £dajov. Ka§d  cesta v strome spracovania reprezentuje dom‚nu vo vstupnìch £dajoch a çpecifick£ vìpoŸtov£ funkciu. Podmienky vetvenia definuj£ hranice dom‚n mno§iny vstupnìch £dajov. Symbolick‚ vyhodnotenie predik tov vetvenia m“§e byœ vyu§it‚ pre konçtrukciu rozŸlenenia vstupnej mno§iny na dom‚ny. Testovanie pomocou rozŸlenenia vstupnej mno§iny by malo identifikovaœ nasledovn‚ typy chìb: vìpoŸtov‚ chyby, chyby vìberu vìpoŸtovej cesty vo vyhodnocovacom strome (predik ty pre vetvenie s£ nekorektn‚) a chyby vznikaj£ce z neexistencie vìpoŸtovìch ciest vo vìpoŸtovom strome (s danou alternat¡vou sa nepoŸ¡talo). V praxi sa vyu§¡va viacero vari ci¡ popisovanej met¢dy, ktorìm sa budeme venovaœ podrobnejçie. Analìza ciest v strome vyhodnocovania a testovanie -------------------------------------------------- Testovanie na z klade rozŸlenenia vstupnej mno§iny vych dza z vìberu jednej testovacej hodnoty pre ka§d£ dom‚nu vstupnej mno§iny. Dom‚ny vstupnej mno§iny sa pri tejto vari cii vytv raj£ na z klade identifik cie vìpoŸtovìch ciest v programe. V praxi vçak program m“§e obsahovaœ ve–mi ve–kì, resp. i nekoneŸnì, poŸet mo§nìch vìpoŸtovìch ciest. Pri danej met¢de testovania je preto potrebn‚ vych dzaœ z podmno§iny vçetkìch vìpoŸtovìch ciest. Pre ich vìber je mo§n‚ pou§iœ napr. metriky pokrytia. Medzi najzn mejçie pou§¡van‚ metriky patria pokrytie vetven¡, pokrytie rozhodovac¡ch blokov a pokrytie vetven¡. Tieto metriky umo§åuj£ kvantifikovaœ rozsah programu, ktorì je danìm testovan¡m overenì a tìm aj pravdepodobnosœ, §e vyskytuj£ce sa chyby bud£ identifikovan‚. Pou§itie popisovanej met¢dy vçak nar §a na probl‚m, §e urŸenie vìpoŸtovìch ciest pre –ubovo–nì program a vìber testovac¡ch £dajov pre overenie danej cesty je pre –ubovo–nì program nerieçite–nì. Obmedzen¡m vlastnost¡ programovacieho jazyka je vçak mo§n‚ zvoliœ koneŸn‚ podmno§iny vstupnìch £dajov pre identifik ciu vybranìch typov chìb. Dom‚nov  analìza ---------------- Pri dom‚novej analìze sa chyby pre zvolen£ dom‚nu identifikuj£ vìberom testovac¡ch £dajov pri alebo na hranici medzi susednìmi dom‚nami vstupnìch hodn“t. Predpokladom pou§itia dom‚novej analìze je linearita a s£vislosœ vstupn‚ho priestoru, neexistencia koincidenŸnej korektnosti programu a interpret cia predik tov vo forme jednoduchìch line rnych nerovnost¡. Existuje nieko–ko vari ci¡ dom‚novej analìzy. Pri testovan¡ programov s dvojrozmernou vstupnou dom‚nou, tzn. s dvoma vstupnìmi premennìmi, je mo§n‚ zvoliœ dva vstupy pri hranici zvn£tra analyzovanej dom‚ny (ON) a jeden vstup bezprostredne mimo hran¡c tejto dom‚ny (OFF) v susednej dom‚ne. Dva ON vstupy s£ zvolen‚ tak, aby le§ali bl¡zko koncov hran¡c vstupnej dom‚ny. Vstup OFF by mal byœ zvolenì tak, aby jeho projekcia le§ala v strede medzi ON vstupmi. Popisovan  2 k 1 strat‚gia m“§e byœ na n-rozmerov do N k 1 strat‚gii. Pr¡klad vo–by testovac¡ch vstupov pre strat‚giu 2 k 1 je ilustrovanì na OBR.7.4. OBR.7.4. strat‚gia 2 k 1 Alternat¡vou k strat‚gii 2 ku 1 je strat‚gia 2 ku 2 (2 ON a 2 OFF), resp. jej zovçeobecnenie N ku N a E ku E, kde E reprezentuje poŸet hr n tvoriacich hranicu danej dom‚ny. V strat‚gii 2 ku 2 sa vyberaj£ 2 ON vstupy na okrajoch hranice v analyzovanej dom‚ne a 2 OFF vstupy na okrajoch hranice mimo analzyovanej dom‚ny. Strat‚gia 2 ku 2 nie je schopn  identifikovaœ vçetky chyby vìberu vìpoŸtovej cesty. Strat‚gia E ku E umo§nuje vìber najlepçej mno§iny testovac¡ch vstupov, ktor  je citliv  na zmeny tvaru vstupnej dom‚ny. Nevìhodou vçak je, §e vy§aduje vysok‚ mno§stvo testovac¡ch vstupov. Nevìhodou dom‚novej analìzy je predpoklad linearity predik tov a œa§kosti pre vìber testovac¡ch vstupov pre programy s viacerìmi vstupnìmi premennìmi. Dom‚nov  analìza sa s£streÔuje na identifik cii chìb spojenìch s vìberom vìpoŸtovej cesty. Z tohoto d“vodu je potrebn  jej kombin cia s inìmi testovac¡mi met¢dami. Experimenty s testovan¡m pomocou rozŸleåovania vstupnej mno§iny uk zali, §e je mo§n‚ identifikovaœ 75% vìpoŸtovìch chìb a 33% chìb vìberu vìpoŸtovej cesty. 7.3.5. FunkŸn‚ testovanie ------------------------- FunkŸn‚ testovanie predstavuje pr¡stup zalo§enì na poh–ade na n vrh programu ako na abstraktn£ specifik ciu po§iadaviek a n vrhu. FunkŸn‚ testovanie mo§no rozdeliœ na dva kroky. Prvìm je dekompoz¡cia programu na z kladn‚ funkŸn‚ jednotky zalo§en  na met¢de funkŸnej abstrakcie pou§itej z roveå pri n vrhu programu. Druhìm krokom je generovanie £dajov potrebnìch nez visl‚ pre testovanie jednotlivìch funkŸnìch blokov. FunkŸn  abstrakcia predstavuje strat‚giu, v ktorej s£ programy ch pan‚ ako hierarchie abstraktnìch funkci¡. Ka§d  funkcia m“§e byœ z roveå ch pan  ako kompoz¡cia funkci¡ na ni§çej £rovni abstrakcie. Vytvoren  hierarchia funkci¡ je pou§¡van  pre identifik ciu jednotlivìch testovanìch funkci¡ a ich n sledn‚ samostatn‚ testovanie. Hierarchia funkci¡ obsahuje dva z kladn‚ typy funkci¡: po§iadavkov‚ funkcie a n vrhov‚ funkcie. Po§iadavkov‚ funkcie opisuj£ oŸak van‚ spr vanie programu a m“§u byœ identifikovan‚ analìzou po§iadaviek v çpecifik cii programu. Vlastn  realiz cia po§iadavkovej funkcie m“§e vy§adovaœ zavedenie Ôalç¡ch funkci¡, nazìvanìch n vrhov‚ funkcie. N vrhov‚ funkcie m“§u byœ nazìvan‚ vçeobecn‚ alebo detailn‚, pod–a vçeobecnosti spr vania, ktor‚ implementuj£. N vrhov‚ funkcie sa neodv dzaj£ priamo od po§iadaviek v çpecifik ci¡, ale od sp“sobu sp’åania tìchto po§iadaviek. V d tovej abstrakcii je mo§n‚ modelovaœ strukt£ru £dajov hierarchiou abstraktnìch d tovìch typov, z ktorìch ka§dì predstavuje mno§inu hodn“t. Mno§ina pr¡pustnìch hodn“t pre vstupy a vìstupy programu je taktie§ çpecifikovan  pomocou abstraktnìch £dajovìch typov. Mno§ina mo§nìch hodn“t premennej sa nazìva dom‚na premennej. Najd“le§itejç¡mi ka§dej dom‚ny s£ extr‚mne a çpeci lne hodnoty. Extr‚mne hodnoty s£ tie, ktor‚ le§ia na hraniciach pr¡sliçnej dom‚ny. æpeci lne hodnoty maj£ speci lne matematick‚ vlastnosti, napr. nula, ve–mi mla  alebo ve–k  hodnota. Kombin cia hodn“t dom‚ny premennìch predstavuje probl‚m s kombinaŸnou expl¢ziou. Program s k vstupnìmi premennìmi, z m kktorìch ka§d  m“§e maœ m hodn“t, predstavuje k mo§nìch vstupov. Z tohoto d“vodu je potrebn‚ h–adaœ efekt¡vnejçie pr¡stupy ku kombin cii typickìch hodn“t pre redukciu rozsahu testovacej mno§iny. Vysledky s pou§it¡m funkŸnej analìzy ukazuj£, §e £speçnosœ testovania pomocou tejto met¢dy je pomerne vysok . Pre danì pr¡pad bolo zo 42 zn mych chìb v programe identifikovanìch 38 (20 v po§iadavkovìch funkci ch, 9 vo vçeobecnìch n vrhovìch funkci ch, 9 v detailnìch n vrhovìch funkci ch, z Ÿoho 4 boli odhalen‚ pomocou d tovej abstrakcie). 7.3.6. N hodn‚ testovanie ------------------------- N hodn‚ testovanie predstavuje jednu z mo§nìch pou§it¡ strat‚gie testovania Ÿiernej sktinky. Program je testovanì n hodnìm vìberov vstupov z mno§iny vçetkìch pr¡pustnìch vstupov programu. T to met¢da pova§uje testovanie programov za vzorkovanie programu za £Ÿelom zistenia chyby. V„Ÿçina existuj£cich techn¡k n hodn‚ho testovania sa sna§¡ o zvìçenie pravdepodobnosti identifik cie chyby vybranìch vzoriek vstupov. V s£Ÿasnosti vçak neexistuje met¢da, ktor  by zaruŸila korektnosœ testovan‚ho programu. Mieru korektnosti testovan‚ho programu je v tomto pr¡pade mo§n‚ definovaœ ako pomer nespr vnych testov ku poŸtu vçetkìch testov. Vìber vstupov je mo§n‚ vykon vaœ n hodne, alebo na z klade proced£ry zalo§enej na pravdepodobnostnej distrib£cii vstupnìch sekvenci¡. Takìto pr¡stup umo§åuje modelovaœ funkŸnosœ programu v re lnej prev dzke a umo§åuje odhadn£œ tzv. "operaŸn£ spo–ahlivosœ". 7.3.7. Testovanie zalo§en‚ na gramatik ch ----------------------------------------- Tento pr¡stup k testovaniu je vhodnì pre syst‚my, ktorìch spr vanie je mo§n‚ op¡saœ pomocou koneŸn‚ho automatu. Hlavnìmi komponentami testovacej strat‚gie s£ Procesor Jazyka Po§iadaviek (RLP), Gener tor Testovac¡ch Pl nov (TPG) a Automatickì Vykon vaŸ Testov (ATE). Vstupom RLP je form lny opis syst‚mu, ktorì sa m  testovaœ. Vìstupov je matica stavovìch prechodov, ktor  je reprezent ciou koneŸn‚ho automatu. KeÔ§e sa predpoklad  odhalenie nekonzistenci¡ u§ RLP, mo§no koneŸnì automat reprezentovanì maticou stavovìch prechodov pova§ovaœ za deterministickì. Dosiahnute–nosœ ka§d‚ho stavu je mo§n‚ overiœ vytvoren¡m tranzit¡vneho uz veru. Pou§it¡m vìsledkov te¢rie automatov je mo§n‚ pre danì koneŸnì automat zostrojiœ regul rnu gramatiku, ktor  popisuje jazyk akceptovanì danìm automatom. T£to gramatiku je mo§n‚ ruŸne rozç¡riœ o popisy çpecif¡k jednotlivìych stavovìch prechodov a indik ciou pozorovate–nìch vìstupov koneŸn‚ho automatu (tieto vìstupy musia byœ termin lnymi symbolmi). Regul rna gramatika je vstupom pre TPG. Vìstupom TPG je mno§ina testovac¡ch skriptov, z ktorìch ka§dì obsahuje sekvenciu vstupov a sekvenciu oŸak vanìch vìstupov. ATE vykon  ka§dì skript a vytv ra çtatistiku o spr van¡ testovan‚ho syst‚mu.