zswi/pC-testova´nı´.d
10. kveˇtna 2003
1
White-box testova ´nı ´ ------------------* white-box testova ´nı ´ = vyuz ˇı ´va ´me znalost implementace - obvykle se pouz ˇı ´va ´ pro testova ´nı ´ relativne ˇ maly ´ch c ˇa ´stı ´ programu, jako jsou podprogramy v modulu, metody tr ˇı ´dy - tj. testova ´nı ´ jednotek - pokud jsou moduly integrova ´ny do syste ´mu, sloz ˇitost naru ˚sta ´ tak, z ˇe jsou struktura ´lnı ´ techniky prakticky neproveditelne ´; ne ˇktere ´ proveditelne ´ techniky uvedeme da ´le - se zvys ˇova ´nı ´m rozsahu projektu testy jednotek zabı ´rajı ´ mens ˇı ´ podı ´l na celkove ´m c ˇasu vy ´voje (35% az ˇ cca 8%) * pokud zna ´me strukturu implementace, mu ˚z ˇeme pro testova ´nı ´ pouz ˇı ´t ope ˇt tr ˇı ´dy ekvivalence a testovat be ˇz ˇne ´ a hranic ˇnı ´ podmı ´nky se znalostı ´ ko ´du * ilustrovat budu na za ´klade ˇ bina ´rnı ´ho vyhleda ´va ´nı ´ v jazyce Java: - pro ty kdo znajı ´ pouze Pascal uva ´dı ´m ekvivalentnı ´ konstrukce v Pascalu: ---------------------------------------------Java Pascal Java Pascal { begin int x; var x: integer; } end a = b; a := b; // { komenta ´r ˇ } ---------------------------------------------class BinSearch { // bina ´rnı ´ vyhleda ´va ´nı ´ // key - klı ´c ˇ // elemArray - ser ˇazene ´ pole prvku ˚ , ve ktere ´m se vyhleda ´va ´ // r - vy ´sledek, obsahuje r.index a boolovskou hodnotu // r.found, ktera ´ je true pokud byl klı ´c ˇ v poli public static void search(int key, int elemArray[], Result r) { int bottom = 0; int top = elemArray.length - 1; int mid; r.found = false; r.index = -1; while (bottom <= top) { mid = (top + bottom) / 2; if (elemArray[mid] == key) { r.index = mid; r.found = true; return; } else { if (elemArray[mid] < key) bottom = mid + 1; else top = mid - 1; } // konec ”if” } // konec ”while” } // konec ”search()”
// // // // // // // // // // // // // // //
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
} // konec ”BinSearch” - z ko ´du mu ˚z ˇeme zjistit, z ˇe bina ´rnı ´ vyhleda ´va ´nı ´ rozde ˇluje vyhleda ´vacı ´ prostor do tr ˇech c ˇa ´stı ´ (prostr ˇednı ´ prvek pole elemArray[mid], zac ˇa ´tek pole, konec pole), kaz ˇda ´ c ˇa ´st tvor ˇı ´ tr ˇı ´du ekvivalence
equivalence class boundaries elements < mid
elements > mid
mid point
- pro testova ´nı ´ bychom mohli pouz ˇı ´t napr ˇı ´klad na ´sledujı ´cı ´ testovacı ´ pr ˇı ´pady:
2
10. kveˇtna 2003
zswi/pC-testova´nı´.d
vstupnı ´ pole (elemArray) klı ´c ˇ vy ´stup tr ˇı ´da ekvivalence (elemArray) (key) (found, index) (pole, prvek) -------------------------------------------------------------------------17 17 true, 1 jedna hodnota, vy ´skyt v poli 17 0 false, ?? jedna hodnota, nenı ´ v poli 17, 21, 23, 29 17 true, 1 vı ´ce hodnot, prvnı ´ prvek 9, 16, 18, 30, 31, 41, 45 45 true, 7 vı ´ce hodnot, poslednı ´ prvek 17, 18, 21, 23, 29, 38, 41 23 true, 4 vı ´ce hodnot, prostr ˇednı ´ prvek 17, 18, 21, 23, 29, 33, 38 21 true, 3 vı ´ce hodnot, soused prostr ˇednı ´ho 12, 18, 21, 23, 32 23 true, 4 vı ´ce hodnot, soused prostr ˇednı ´ho 21, 23, 29, 33, 38 25 false, ?? vı ´ce hodnot, nenı ´ v poli - testova ´nı ´ bychom provedli vytvor ˇenı ´m ovladac ˇe (napr ˇ. metody s na ´zvem ”test”, pr ˇı ´padne ˇ ”main”), ktery ´ bude volat testovany ´ podprogram nebo metodu - zadane ´ vstupy (pr ˇı ´padne ˇ i vy ´stupy) mohou by ´t zako ´dova ´ny v ovladac ˇi, pr ˇevzaty z pr ˇı ´kazove ´ho r ˇa ´dku, zada ´ny uz ˇivatelem, pr ˇec ˇteny ze souboru apod. - vytva ´r ˇenı ´ testu ˚ si vynucuje dobry ´ na ´vrh - ma ´-li by ´t ko ´d testovatelny ´, je tr ˇeba, aby moduly/tr ˇı ´dy byly volne ˇ va ´zane ´, nevyz ˇadovaly sloz ˇitou inicializaci apod. * z ko ´du mu ˚z ˇeme urc ˇit take ´ dals ˇı ´ typ hranic ˇnı ´ podmı ´nky, ktery ´ nasta ´va ´ pokud docha ´zı ´ ke kombinaci vstupnı ´ch hodnot - napr ˇı ´klad pokud podprogram hodnoty na ´sobı ´, testovacı ´ pr ˇı ´pady mohou zahrnovat dve ˇ velka ´ kladna ´ c ˇı ´sla, dve ˇ velka ´ za ´porna ´ c ˇı ´sla apod.
Pokrytı ´ ko ´du testovacı ´mi pr ˇı ´pady ................................ * pr ˇi white-box testova ´nı ´ na ´s zajı ´ma ´, do jake ´ mı ´ry testovacı ´ pr ˇı ´pady pokry ´vajı ´ zdrojovy ´ text programu - jak uz ˇ jsme si uvedli, otestovat vs ˇechny cesty v programu je obvykle neproveditelne ´, proto se o to nebudeme pokous ˇet - prakticke ´ metody by me ˇly testovat pouze rozumnou podmnoz ˇinu cest v programu * je dobry ´m krite ´riem alespon ˇ jedno vykona ´nı ´ kaz ˇde ´ho pr ˇı ´kazu? (statement coverage, pokrytı ´ vs ˇech pr ˇı ´kazu ˚) - napr ˇı ´klad me ˇjme pr ˇı ´kaz: if (a>1) and (b=0) then x = x/a; - oba pr ˇı ´kazy (if a pr ˇir ˇazovacı ´ pr ˇı ´kaz) by bylo moz ˇne ´ pokry ´t jediny ´m testovacı ´m pr ˇı ´padem (a=2, b=0) - pr ˇı ´klady defektu ˚, ktere ´ by testem zu ˚ staly neodhaleny: mı ´sto ”and” ma ´ by ´t ”or”, mı ´sto ”a>1” ma ´ by ´t ”a>=1” nebo ”a>0” apod. - podmı ´nka pokrytı ´ vs ˇech pr ˇı ´kazu ˚ je nutna ´, ale nikoli postac ˇujı ´cı ´ * krite ´rium pokrytı ´ zesı ´lı ´me - je dobry ´m krite ´riem pokrytı ´ vs ˇech rozhodovacı ´ch pr ˇı ´kazu ˚ tak, aby byly vykona ´ny vs ˇechny jejich ve ˇtve? (branch coverage) - musı ´me vytvor ˇit tolik testovacı ´ch pr ˇı ´padu ˚, aby se v kaz ˇde ´m pr ˇı ´kazu ”if” vykonala alespon ˇ jednou ve ˇtev pr ˇi podmı ´nce ”false” a alespon ˇ jednou ve ˇtev pr ˇi podmı ´nce ”true” atd. . pro sloz ˇite ˇjs ˇı ´ podprogramy se vyplatı ´ modelovat cestu podprogramem pomocı ´ orientovane ´ho grafu, popisujı ´cı ´ho moz ˇny ´ tok r ˇı ´zenı ´ v podprogramu . uzly reprezentujı ´ pr ˇı ´kaz nebo c ˇa ´st pr ˇı ´kazu (pr ˇir ˇazovacı ´ pr ˇı ´kazy, vola ´nı ´ podprogramu ˚, pr ˇı ´padne ˇ jednotlive ´ podmı ´nky rozhodovacı ´ch pr ˇı ´kazu ˚) . kaz ˇdy ´ pa ´r uzlu ˚ pro ktery ´ je moz ˇny ´ pr ˇenos r ˇı ´zenı ´ je spojen hranou . pr ˇı ´klad - graf toku pro bina ´rnı ´ vyhleda ´va ´nı ´:
zswi/pC-testova´nı´.d
10. kveˇtna 2003 n1 n2
bottom > top
n3
while bottom <=top
n4 n5 n6 n7
if (elemArray [mid] == key) if (elemArray [mid] < key)
n10 n11
n8
n13 n15
nf
. neza ´visla ´ cesta = musı ´ procha ´zet alespon ˇ jednu novou hranu v grafu, tj. prove ´st jednu nebo vı ´ce novy ´ch podmı ´nek - kvu ˚li ”patologicky ´m pr ˇı ´padu ˚m” (podprogram neobsahuje rozhodova ´nı ´, ma ´ vı ´ce vstupnı ´ch bodu ˚ apod.) pr ˇipojujeme jes ˇte ˇ podmı ´nku pokrytı ´ vs ˇech pr ˇı ´kazu ˚ - postac ˇovalo by, pokud bychom me ˇli vz ˇdy jedinou podmı ´nku v rozhodovacı ´m pr ˇı ´kazu - pro uvedeny ´ ko ´d je sta ´le jes ˇte ˇ slabe ´ krite ´rium: pokud otestujeme pomocı ´ (a=2, b=0) a (a=2, b=1), neodhaleny by zu ˚ staly defekty jako mı ´sto ”a>1” ma ´ by ´t ”a>=1” * rozumny ´m krite ´riem je pokrytı ´ vs ˇech kombinacı ´ podmı ´nek v rozhodovacı ´m pr ˇı ´kazu (multiple condition coverage) - oproti branch coverage navı ´c vyz ˇaduje, aby byly otestova ´ny vs ˇechny kombinace hodnot logicky ´ch operandu ˚ v podmı ´nce - vy ´s ˇe uvedeny ´ pr ˇı ´kaz ”if” mu ˚z ˇeme otestovat c ˇtyr ˇmi testovacı ´mi pr ˇı ´pady: . (a=2, b=0) => obe ˇ podmı ´nky jsou true, ve ˇtev ”then” se provede . (a=2, b=1) => true, false, ve ˇtev ”then” se neprovede . (a=1, b=0) => false, true, ve ˇtev ”then” se neprovede . (a=1, b=1) => false, false, ve ˇtev ”then” se neprovede * dals ˇı ´m moz ˇny ´m krite ´riem je pokrytı ´ smyc ˇek - vyz ˇaduje 3 testovacı ´ pr ˇı ´pady: - pr ˇi prvnı ´m vyhodnocenı ´ bude test ”false”, tj. te ˇlo smyc ˇky se nevykona ´ - pr ˇi prvnı ´m vyhodnocenı ´ bude test ”true”, pote ´ ”false”, tj. te ˇlo smyc ˇky se vykona ´ pra ´ve ˇ jednou - test bude ”true” nejme ´ne ˇ dvakra ´t, tj. te ˇlo se vykona ´ nejme ´ne ˇ dvakra ´t * pro urc ˇenı ´ pokrytı ´ velky ´ch sad testu ˚ spous ˇte ˇny ´ch na cele ´ syste ´my jsou uz ˇitec ˇne ´ tyto podmı ´nky: - pokrytı ´ podprogramu ˚ - zda byl podprogram vyvola ´n alespon ˇ jednou - pokrytı ´ vola ´nı ´ - zda kaz ˇdy ´ podprogram volal vs ˇechny podprogramy, ktere ´ mu ˚z ˇe volat * testy prova ´de ˇne ´ bez me ˇr ˇene ´ pokrytı ´ ko ´du typicky pokry ´vajı ´ pouze 55% ko ´du (Grady 1993) - pro zjis ˇte ˇnı ´, ktere ´ cesty byly vykona ´ny se pouz ˇı ´vajı ´ dynamicke ´ analyza ´tory programu . pr ˇi pr ˇekladu je ke kaz ˇde ´mu pr ˇı ´kazu pr ˇipojen ko ´d, ktery ´ poc ˇı ´ta ´ kolikra ´t byl dany ´ pr ˇ´ ıkaz vykona ´n . po be ˇhu mu ˚z ˇeme zjistit, ktere ´ c ˇa ´sti programu nebyly pokryty pr ˇı ´slus ˇny ´m testovacı ´m pr ˇı ´padem . pr ˇı ´klad na ´stroje: GCT (Generic Coverage Tool) volne ˇ s ˇı ´r ˇeny ´ na ´stroj pro jazyk C, viz ftp://ftp.cs.uiuc.edu/pub/testing/gct.files Testova ´nı ´ tr ˇı ´d .............. * objekty jako samostatne ´ komponenty jsou obvykle rozsa ´hlejs ˇı ´ nez ˇ samostatne ´ podprogramy * pr ˇi testova ´nı ´ objektu bychom me ˇli prove ´st: - samostatne ´ otestova ´nı ´ kaz ˇde ´ metody . ne ˇktere ´ metody lze testovat az ˇ po pr ˇedchozı ´m vyvola ´nı ´ jiny ´ch metod, napr ˇ. po inicializaci objektu
3
10. kveˇtna 2003
4
. pokud pouz ˇı ´va ´me de ˇdic ˇnost, musı ´me testovat i vs ˇechny zde ˇde ˇne ´ operace (mohou obsahovat pr ˇedpoklady o dals ˇı ´ch operacı ´ch a atributech, ktere ´ ale mohly by ´t potomkem zme ˇne ˇny; obdobne ˇ musı ´me znovu otestovat potomky pr ˇi zme ˇne ˇ rodic ˇe) - testovat nastavenı ´ vs ˇech atributu ˚ objektu, dotaz na vs ˇechny atributy - testovat pru ˚chod vs ˇemi stavy objektu, pr ˇı ´padne ˇ simulace vs ˇech uda ´lostı ´ ktere ´ zpu ˚sobujı ´ zme ˇnu stavu objektu . pokud jsme vytvor ˇili stavovy ´ diagram objektu, mu ˚z ˇeme z ne ˇj urc ˇit posloupnost pr ˇechodu ˚ ktere ´ chceme testovat, a najı ´t posloupnost uda ´lostı ´ ktere ´ jı ´ zpu ˚sobı ´ Integrac ˇnı ´ testova ´nı ´ -------------------* po otestova ´nı ´ individua ´lnı ´ch komponent musı ´me komponenty integrovat = sestavit do c ˇa ´stec ˇne ´ho nebo ´ uplne ´ho syste ´mu * vy ´sledek musı ´me otestovat na proble ´my, ktere ´ vznikajı ´ interakcı ´ komponent * ”big bang” (velky ´ tr ˇesk) - po otestova ´nı ´ jednotlivy ´ch modulu ˚ je z nich v jedine ´m kroku sestavena aplikace - pouz ˇitelne ´ pouze pro male ´ programy - pro ve ˇts ˇı ´ syste ´my nejme ´ne ˇ efektivnı ´ zpu ˚sob integrace = vysoka ´ pravde ˇpodobnost neu ´spe ˇchu * hlavnı ´m proble ´mem je lokalizace chyb, protoz ˇe vztahy mezi komponentami mohou by ´t znac ˇne ˇ sloz ˇite ´ - proto se c ˇasto pro integraci a testova ´nı ´ pouz ˇı ´va ´ inkrementa ´lnı ´ pr ˇı ´stup - nejprve integrujeme minima ´lnı ´ konfiguraci syste ´mu, otestujeme - k syste ´mu pr ˇida ´va ´me inkrementy, po kaz ˇde ´m pr ˇida ´nı ´ syste ´m otestujeme - pokud nastaly proble ´my, budou pravde ˇpodobne ˇ (ale ne nutne ˇ) zpu ˚sobeny pr ˇida ´nı ´m poslednı ´ho inkrementu * ve skutec ˇnosti nebude tak jednoduche ´, protoz ˇe ne ˇktere ´ vlastnosti budou rozpty ´leny do ne ˇkolika komponent, vlastnost mu ˚z ˇeme otestovat az ˇ po integraci te ˇchto komponent => pr ˇi pla ´nova ´nı ´ testu ˚ je tr ˇeba poc ˇı ´tat s c ˇasovy ´m pla ´nem na dokonc ˇenı ´ modulu ˚ * pokud ma ´ du ˚lez ˇity ´ modul neoc ˇeka ´vane ´ proble ´my, mu ˚z ˇe se tı ´m zdrz ˇet cela ´ integrace (programa ´tor r ˇes ˇı ´ proble ´m, zatı ´mco vs ˇichni ostatnı ´ na ne ˇj c ˇekajı ´) Testova ´nı ´ rozhranı ´ .................. * cı ´lem testova ´nı ´ rozhranı ´ je detekovat chyby ktere ´ mohou vzniknout chybnou interakcı ´ mezi moduly nebo podsyste ´mu nebo chybny ´m pr ˇedpokladem o rozhranı ´ * testova ´nı ´ rozhranı ´ je obtı ´z ˇne ´, protoz ˇe ne ˇktere ´ typy chyb se projevı ´ pouze za neobvykly ´ch podmı ´nek * uvedu pouze obecna ´ pravidla (volne ˇ podle Sommerville 2001): - v testovane ´m ko ´du najde ˇte vs ˇechna vola ´nı ´ externı ´ch komponent - navrhne ˇte mnoz ˇinu testu ˚ tak, aby externı ´ komponenty byly vola ´ny s parametry, ktere ´ jsou extre ´my jejich rozsahu (napr ˇ. pra ´zdny ´ r ˇete ˇzec, dlouhy ´ r ˇete ˇzec ktery ´ by mohl zpu ˚sobit pr ˇetec ˇenı ´ apod.) - navrhne ˇte testy, ktere ´ by me ˇly zpu ˚sobit neu ´spe ˇch externı ´ komponenty (zde jsou c ˇasto chybne ´ pr ˇedpoklady) - v syste ´mech s pr ˇeda ´va ´nı ´m zpra ´v pouz ˇijte za ´te ˇz ˇove ´ testova ´nı ´ (viz nı ´z ˇe) - pokud spolu komponenty komunikujı ´ prostr ˇednictvı ´m databa ´ze, sdı ´lene ´ pame ˇti apod., navrhne ˇte testy ve ktery ´ch se bude lis ˇit por ˇadı ´ aktivace komponent; testy mohou odhalit implicitnı ´ pr ˇedpoklady programa ´tora o por ˇadı ´, v jake ´m por ˇadı ´ budou sdı ´lena ´ data produkova ´na a konzumova ´na * mnoho chyb rozhranı ´ odhalı ´ staticke ´ testy - napr ˇ. silna ´ typova ´ kontrola v pr ˇekladac ˇı ´ch jazyka Java - pro slabe ˇ typovane ´ jazyky (napr ˇ. C) by se pr ˇed integrac ˇnı ´m testova ´nı ´m me ˇly pouz ˇı ´t staticke ´ analyza ´tory (code checkers) . nejstars ˇı ´ ze zna ´my ´ch staticky ´ch analyza ´toru ˚ je program lint(1), ktery ´ byl souc ˇa ´stı ´ historicky ´ch syste ´mu ˚ UNIX . v souc ˇasnosti se c ˇasto pouz ˇı ´va ´ volne ˇ s ˇı ´r ˇeny ´ lclint(1) . detekuje neinicializovane ´ prome ˇnne ´, odchylky od standardu ˚ apod. . me ˇl by se pouz ˇı ´t vz ˇdy pr ˇed inspekcemi
zswi/pC-testova´nı´.d
zswi/pC-testova´nı´.d
10. kveˇtna 2003
5
* ne ˇktere ´ inspekce se mohou zame ˇr ˇit take ´ na rozhranı ´ komponent a jejich pr ˇedpokla ´dane ´ chova ´nı ´ Testy syste ´mu ------------* po dokonc ˇenı ´ integrace mu ˚z ˇeme syste ´m testovat na vlastnosti jako je vy ´konnost, kompatibilitu, bezpec ˇnost, instalovatelnost, spolehlivost, udrz ˇovatelnost apod. Za ´te ˇz ˇove ´ testova ´nı ´ .................. * testy vy ´konnosti ove ˇr ˇujı ´, zda syste ´m mu ˚z ˇe sne ´st zamy ´s ˇlenou za ´te ˇz ˇ - obvykle se pouz ˇı ´vajı ´ testy, kde se za ´te ˇz ˇ postupne ˇ zvys ˇuje, dokud nenı ´ vy ´konnost syste ´mu neakceptovatelna ´ * ne ˇktere ´ syste ´my jsou navrz ˇeny pro urc ˇitou za ´te ˇz ˇ, napr ˇ. zpracova ´nı ´ 100 transakcı ´ za sekundu - za ´te ˇz ˇove ´ testova ´nı ´ = pokrac ˇova ´nı ´ testu ˚ za maxima ´lnı ´ za ´te ˇz ˇ pro kterou byl syste ´m navrz ˇen dokud syste ´m nehavaruje - ove ˇr ˇenı ´ zda hava ´rie syste ´mu nepos ˇkodı ´ data apod. - mu ˚ˇ ze odhalit defekty, ktere ´ se norma ´lne ˇ neprojevı ´ - du ˚ lez ˇite ´ zejme ´na v distribuovany ´ch syste ´mech, kde se vysoce zatı ´z ˇene ´ syste ´my mohou zahltit, protoz ˇe si vyme ˇn ˇujı ´ c ˇı ´m da ´l vı ´ce koordinac ˇnı ´ch dat, c ˇı ´mz ˇ se zvys ˇuje za ´te ˇz ˇ syste ´mu atd. Akceptac ˇnı ´ testova ´nı ´, alfa a beta testova ´nı ´ ........................................... * akceptac ˇnı ´ testova ´nı ´ = zadavatel urc ˇı ´, zda produkt spln ˇuje zada ´nı ´ - testuje se na rea ´lny ´ch datech * pro genericke ´ produkty nenı ´ ve ˇts ˇinou moz ˇne ´ vykonat akceptac ˇnı ´ testova ´nı ´ u kaz ˇde ´ho za ´kaznı ´ka, proto alfa a beta testova ´nı ´ - alfa testy: na pracovis ˇti, kde se SW vyvı ´jı ´ (zna ´me ´ prostr ˇedı ´) . testuje uz ˇivatel, vy ´vojovı ´ pracovnı ´ci ho sledujı ´ a zaznamena ´vajı ´ chyby - beta testy: testujı ´ vybranı ´ uz ˇivatele ´ ve sve ´m prostr ˇedı ´ (vy ´voja ´r ˇ˚ um nezna ´me ´m) . chyby ohla ´s ˇene ´ uz ˇivateli jsou opraveny => fina ´lnı ´ produkt Na ´stroje pro testova ´nı ´ SW ------------------------* v rozsa ´hly ´ch syste ´mech mu ˚z ˇe cena testova ´nı ´ dosa ´hnout 50% ceny vy ´voje, mohou existovat stovky az ˇ tisı ´ce strojove ˇ generovany ´ch testovacı ´ch pr ˇı ´padu ˚ - proto potr ˇeba automatizace testu ˚ - automatizace testu ˚ take ´ sniz ˇuje cenu zme ˇn - programa ´tor ˇi se nemusejı ´ tolik oba ´vat, z ˇe zme ˇnou zanesou do ko ´du chybu, protoz ˇe testy by chybu (s urc ˇitou pravde ˇpodobnostı ´) odhalily - obvykle ´ je na ´sledujı ´cı ´ uspor ˇa ´da ´nı ´:
test data generator
specification
test manager
test data
oracle
program being tested
actual test results
result predictions
file comparator
report generator
test results report
10. kveˇtna 2003
6
zswi/pC-testova´nı´.d
* jednotlive ´ programy majı ´ na ´sledujı ´cı ´ fce: - spra ´vce testu ˚ (test manager) - r ˇı ´dı ´ be ˇh testu ˚ - genera ´tor testovacı ´ch dat (test data generator) - generuje testovacı ´ vstupnı ´ data pro testovany ´ SW - ora ´kulum (oracle) - generuje pr ˇedpokla ´dane ´ vy ´stupnı ´ hodnoty . ora ´kulum lze vyvinout jako novy ´ program (obsahujı ´cı ´ podmnoz ˇinu funkc ˇnosti, co nejme ´ne ˇ pracna ´ implementace) . c ˇasto lze vyuz ˇı ´t prototyp SW, pr ˇedchozı ´ verze SW, konkurenc ˇnı ´ SW apod. . pokud se jako ora ´kulum pouz ˇı ´va ´ pr ˇedchozı ´ verze SW, pouz ˇı ´va ´ se na ´zev regresivnı ´ testova ´nı ´ (regression tests = porovna ´va ´me vy ´sledky stare ´ a nove ´ verze, rozdı ´ly znamenajı ´ potencia ´lnı ´ proble ´m v nove ´ verzi) - program pro porovna ´nı ´ souboru ˚ (file comparator) - porovna ´ vy ´sledky skutec ˇne ´ho be ˇhu s pr ˇedpokla ´dany ´mi hodnotami vygenerovany ´mi ora ´kulem; c ˇasto lze pouz ˇı ´t univerza ´lnı ´ programy jako cmp(1) a diff(1) v UNIXu apod. - genera ´tor zpra ´v (report generator) - umoz ˇn ˇuje definovat a generovat zpra ´vy o vy ´sledcı ´ch testu ˚ Pozna ´mka (regresivnı ´ vs. progresivnı ´ testova ´nı ´) Proces testova ´nı ´ ma ´ testova ´nı ´ pr ˇida ´va ´ a a jejich rozhranı ´ s du ˚sledky zme ˇn v jiz ˇ
svou progresivnı ´ i regresivnı ´ fa ´zi. Progresivnı ´ fa ´ze testuje nove ´ fce (nove ˇ pr ˇidane ´ nebo modifikovane ´ moduly jiz ˇ integrovany ´mi moduly). Regresivnı ´ fa ´ze testuje integrovany ´ch c ˇa ´stech.
[] * jako jednoduchou uka ´zku uvedu c ˇa ´st pr ˇı ´kazove ´ho souboru pro pr ˇı ´kazovy ´ interpret (shell) v UNIXu, ktery ´ prova ´dı ´ testova ´nı ´ aplikace: test-mkdata > data.test test-oracle < data.test > result1.test aplikace < data.test > result2.test if cmp result1.test result2.test; then echo Test 1: PASSED else echo Test 1: FAILED fi
# # # # #
Vytvor ˇı ´ testovacı ´ data ”data.test”. Ora ´kulum pr ˇedpovı ´ vy ´sledky ”result1.test”. Testujeme aplikaci. Porovna ´me skutec ˇne ´ a pr ˇedpove ˇzene ´ vy ´sledky. Soubory stejne ´ -> test pros ˇel.
# Soubory rozdı ´lne ´ -> test nepros ˇel.
* na ´stroje pro zachycenı ´ a pozde ˇjs ˇı ´ pr ˇehra ´nı ´ testu ˚ (capture-replay tool) - informace prote ´kajı ´ SW syste ´mem - na vhodne ´ mı ´sto toku vloz ˇı ´me na ´stroj, ktery ´ tekoucı ´ data zaznamena ´ - tester spustı ´/vykona ´ a zaznamena ´ testovacı ´ pr ˇı ´pady - pozde ˇji mu ˚z ˇe zaznamenane ´ testovacı ´ pr ˇı ´pady spustit znovu (regresivnı ´ testova ´nı ´) - existujı ´ komerc ˇnı ´ capture-replay na ´stroje pro zachycenı ´/pr ˇehra ´nı ´ stisku ˚ kla ´ves a pohybu ˚ mys ˇi, obsahujı ´cı ´ i na ´stroje pro zachycenı ´ a porovna ´nı ´ vy ´stupu ˚ na obrazovku - pouz ˇı ´vane ´ pro GUI aplikace . pro ve ˇts ˇinu ostatnı ´ch ´ uc ˇelu ˚ (testova ´nı ´ zapouzdr ˇeny ´ch syste ´mu ˚ apod.) je tr ˇeba vytvor ˇit vlastnı ´ SW * kolik chyb lze oc ˇeka ´vat a kolik z nich lze najı ´t testova ´nı ´m? - podle kvality vy ´voje lze oc ˇeka ´vat asi 10 az ˇ 50 chyb na 1000 r ˇa ´dek ko ´du pr ˇed testova ´nı ´m . napr ˇ. Microsoft Application Division 10-20 defektu ˚/1000 r ˇa ´dek ko ´du (Moore 1992) - testy najdou obvykle me ´ne ˇ nez ˇ 60% chyb, proto je vhodne ´ je kombinovat s inspekcemi - ne ˇkter ˇı ´ autor ˇi uva ´de ˇjı ´, z ˇe chyby jsou c ˇaste ˇji v testovacı ´ch pr ˇ´ ıpadech nez ˇ v testovane ´m ko ´du (McConnell 1993) - pro kriticke ´ syste ´my je vhodne ´ pouz ˇı ´vat kombinaci forma ´lnı ´ch metod vy ´voje, inspekcı ´ a testova ´nı ´ (napr ˇ. pro Cleanroom metodiku v pru ˚me ˇru 2.3 defektu ˚/1000 r ˇa ´dek ko ´du, pro ne ˇktere ´ syste ´my az ˇ 0 defektu ˚)
Lade ˇnı ´ ====== * testova ´nı ´m nalezneme chyby, na ´sleduje proces lade ˇnı ´ (angl. debugging) * lade ˇnı ´ = identifikace pr ˇı ´c ˇiny chyby (90% c ˇasu) a jejı ´ oprava (10% c ˇasu) * me ˇlo by probı ´hat v 5 krocı ´ch - (1) stabilizace chyby, (2) nalezenı ´ pr ˇı ´c ˇiny,
zswi/pC-testova´nı´.d
10. kveˇtna 2003
7
(3) oprava, (4) otestova ´nı ´ opravy chyby, (5) vyhleda ´nı ´ obdobny ´ch chyb * stabilizace chyby - potr ˇebujeme, aby se chyba projevovala spolehlive ˇ - proto nejprve hleda ´me testovacı ´ pr ˇı ´pad, ktery ´ chybu reprodukuje - testovacı ´ pr ˇı ´pad co nejvı ´ce zjednodus ˇı ´me, aby se chyba jes ˇte ˇ projevovala - pr ˇi zjednodus ˇova ´nı ´ testovacı ´ho pr ˇı ´padu c ˇasto jiz ˇ mu ˚z ˇeme vytva ´r ˇet hypote ´zu, proc ˇ chyba nasta ´va ´ - existujı ´ chyby, ktere ´ se neprojevujı ´ spolehlive ˇ, napr ˇı ´klad neinicializovane ´ prome ˇnne ´, neplatny ´ ukazatel, chyby c ˇasove ´ho soube ˇhu . ne ˇktere ´ z te ˇchto chyb mu ˚z ˇeme zviditelnit; napr ˇı ´klad neinicializovane ´ prome ˇnne ´ - pr ˇed spus ˇte ˇnı ´m programu pame ˇt’ zaplnit na ´hodny ´mi hodnotami apod. . chyby c ˇasove ´ho soube ˇhu lze zviditelnit pomocı ´ vloz ˇenı ´ yield(), pr ˇı ´padne ˇ na ´hodne ´ho prokla ´da ´nı ´ (o chyba ´ch c ˇasove ´ho soube ˇhu - viz pr ˇedme ˇt ZSWI) * nalezenı ´ pr ˇı ´c ˇiny chyby - napr ˇ. hleda ´nı ´ zu ´z ˇenı ´m podezr ˇele ´ c ˇa ´sti ko ´du: systematicky vynecha ´va ´me ko ´d (i na ´ ukor funkc ˇnosti), testujeme zda se chyba jes ˇte ˇ vyskytuje . adaptace metody bina ´rnı ´ho vyhleda ´va ´nı ´ - vynecha ´ se pr ˇibliz ˇne ˇ polovina ko ´du, pokud se chyba projevuje ope ˇt rozde ˇlı ´me na poloviny atd. . vynecha ´va ´nı ´ vola ´nı ´ podprogramu - pouz ˇitı ´ ladı ´cı ´ho programu nebo ladı ´cı ´ch vy ´pisu ˚ - sledujeme kde nastane chyba . pr ˇeskakujeme ty c ˇ´ asti programu ktere ´ nejsou relevantnı ´, mu ˚z ˇeme pouz ˇı ´t obdobne ´ metody jako vy ´s ˇe (aniz ˇ bychom vynecha ´vali ko ´d) - ne ˇkdy pomu ˚z ˇe se vyspat (podve ˇdomı ´ pracuje za na ´s) * oprava chyby - pokud jsme chybu nalezli, by ´va ´ oprava pome ˇrne ˇ jednoducha ´, ale je vysoke ´ nebezpec ˇı ´ zanesenı ´ dals ˇı ´ chyby (podle ne ˇktery ´ch vı ´ce nez ˇ 50%) - podle studie z 1986 majı ´ ve ˇts ˇı ´ s ˇanci prove ´st opravu spra ´vne ˇ programa ´tor ˇi s celkovou znalostı ´ programu (oproti programa ´toru ˚m kter ˇı ´ se sezna ´mı ´ pouze s opravovanou c ˇa ´stı ´ programu) - proto je pr ˇed opravou tr ˇeba rozume ˇt jak proble ´mu, tak opravovane ´mu programu * opravu je tr ˇeba otestovat - chyby je nutne ´ opravovat po jedne ´, po jedne ´ otestovat - pote ´ program otestovat jako celek, nejle ´pe regresivnı ´mi testy, aby se uka ´zaly pr ˇı ´padne ´ vedlejs ˇı ´ efekty opravy - pro pr ˇı ´pad chyby v oprave ˇ je vhodne ´ mı ´t uchova ´nu pr ˇedchozı ´ verzi (ruc ˇne ˇ, SCM), porovnat obe ˇ verze (napr ˇ. v UNIXu programem diff(1)), z toho je c ˇasto moz ˇne ´ zjistit proble ´m.
❉
