9. diel - Techniky testovania bielej skrinky Nové

V predchádzajúcej lekcii, Testovacia analýza a návrh testov, sme si ukázali prehľad testovacích techník a potom sme sa zamerali na techniky testovania čiernej skrinky.

V dnešnej lekcii o technikách white-box testingu si povieme niečo o testovaní a pokrytí príkazov, potom sa zameriame na testovanie a pokrytie vetiev a pozrieme sa na význam white-box testingu. Ďalšou témou budú techniky experience-based testingu, odhadovanie chýb, prieskumné testovanie a nevynecháme ani testovanie založené na kontrolných zoznamoch.

Techniky white-box testingu

Dvoma najbežnejšími technikami white-box testingu sú statement testing (testovanie príkazov) a branch testing (testovanie vetiev), ktoré slúžia na overovanie kódu:

White-box testing sa však neobmedzuje iba na tieto základné techniky a úroveň component testingu. Existujú pokročilejšie spôsoby, ktoré sa používajú v bezpečnostne, prevádzkovo alebo integračne kritických prostrediach, kde je cieľom dosiahnuť vyšší stupeň pokrytia. Tieto techniky sa využívajú aj na vyšších úrovniach testovania a môžu zahŕňať aj meranie pokrytia, ktoré nie je výhradne zamerané na kód.

Pokrytie príkazov

Statement testing sa zameriava na to, aby každý spustiteľný príkaz v kóde bol aspoň raz otestovaný. Cieľom je navrhnúť test casy, ktoré dosiahnu určitú úroveň pokrytia všetkých týchto príkazov. Miera pokrytia sa vyjadruje percentuálne – teda aká časť z celkového počtu spustiteľných príkazov bola skutočne pri testovaní vykonaná.

Keď sa podarí dosiahnuť 100% pokrytie príkazov, znamená to, že každý spustiteľný príkaz v kóde bol vykonaný aspoň raz. To pomáha nájsť potenciálne chyby, ktoré by sa mohli prejaviť pri spustení týchto príkazov.

Je však dôležité vedieť, že ani 100% pokrytie príkazov nezaručuje odhalenie všetkých chýb – napríklad chyby súvisiace so špecifickými dátami alebo kombináciami podmienok. Navyše táto technika nemusí vždy pokryť celú logiku rozhodovania v kóde, pretože niektoré vetvy (rozdielne podmienky alebo cesty) môžu zostať netestované.

Pokrytie vetiev

Vetva je miesto v kóde, kde sa môže zmeniť smer vykonávania programu, čo znamená, že kód sa môže vydať rôznymi cestami. Predstavme si to ako križovatku. Na každej križovatke – vetve – môže program ísť rovno alebo odbočiť podľa podmienky. Tento prechod môže byť:

• Nepodmienený – kód sa vykonáva bez podmienok, teda lineárne (napr. po jednom príkaze nasleduje priamo ďalší).
• Podmienený – kód sa rozdelí podľa výsledku nejakého rozhodnutia (napr. ak je hodnota premennej väčšia ako 10, kód vykoná jednu akciu, inak vykoná inú).

Pri branch testingu sa snažíme pokryť všetky vetvy, teda všetky možné cesty, ktorými sa kód môže vydať. Cieľom je vytvoriť test casy tak, aby dosiahli pokrytie čo najviac vetiev.

Pokrytie vetiev sa meria ako percento všetkých vetiev, ktoré boli otestované. Stopercentné pokrytie vetiev znamená, že boli otestované všetky možné cesty, ktorými sa kód môže vydať. Avšak aj vtedy sa môže stať, že sa neodhalia niektoré chyby, zvlášť tie, ktoré sa objavia len pri určitej kombinácii ciest.

Dôležité je, že pokrytie vetiev automaticky zahŕňa aj pokrytie príkazov. Keď 100% pokryjeme vetvy, znamená to, že sme automaticky prešli všetkými príkazmi kódu. Naopak to ale neplatí - úplným pokrytím príkazov nemusíme pojať všetky možné cesty kódom, teda vetvy.

Praktický príklad

Ukážme si na praktickom príklade rozdiel medzi pokrytím príkazov a pokrytím vetiev. Máme e-shop a chceme dávať zákazníkom množstevnú zľavu, ak si nakúpi viac ako 10 kusov tovaru:

public class OrderCalculator {

    public static double calculatePrice(int quantity, double pricePerUnit, double discount) {
        double totalPrice;

        if (quantity > 10) {
            totalPrice = quantity * pricePerUnit * (1 - discount);  // Apply discount if quantity is greater than 10
        } else {
            totalPrice = quantity * pricePerUnit;  // No discount
        }

        return totalPrice;
    }
}

Metóda calculatePrice prijíma tri parametre. Množstvo, cenu za kus a zľavu, ktorá sa aplikuje iba pri nákupe viac ako 10 kusov. Pokiaľ je quantity väčšie ako 10, zľavu uplatníme. Inak sa cena počíta bez zľavy.

Pokrytie príkazov

Pri pokrytí príkazov otestujeme metódu s parametrami calculatePrice(15, 100, 0.1). Metóda teda vykoná príkaz:

totalPrice = quantity * pricePerUnit * (1 - discount);

Prvý parameter metódy je quantity > 10, čím dosiahneme 100% pokrytie príkazov, pretože každý spustiteľný príkaz v metóde calculatePrice je vykonaný aspoň raz.

Pokrytie vetiev

Pre 100% pokrytie vetiev musíme otestovať obe cesty v podmienke - if (quantity > 10) aj vetva else. Pridáme teda ďalší testovací prípad calculatePrice(5, 100, 0.1). Ten vykoná príkaz z vetvy else:

totalPrice = quantity * pricePerUnit;

Keďže je quantity < 10, zaistíme 100% pokrytie vetiev, pretože máme testovacie prípady pre obe možné cesty v podmienke.

Význam white-box testingu

Hlavnou výhodou techník white-box testingu je, že berú do úvahy implementáciu softvéru, čo uľahčuje odhaľovanie defektov, najmä ak je špecifikácia softvéru nejasná, zastaraná alebo neúplná. Slabou stránkou je, že tieto techniky nemusia odhaliť defekty spôsobené opomenutím implementácie niektorých požiadaviek.

Tieto techniky je možné využiť pri static testingu, napríklad pri revízii kódu alebo pseudokódu, kedy kód ešte nie je pripravený na spustenie. Umožňujú tiež analyzovať logiku vyššej alebo nižšej úrovne, ktorá môže byť modelovaná pomocou grafu riadiaceho toku.

Na rozdiel od techník black-box testingu, ktoré neodhaľujú mieru pokrytia kódu, poskytuje white-box testing objektívne meranie pokrytia kódu. Vďaka tomu poskytuje cenné informácie pre vytváranie ďalších testov, ktoré zvyšujú pokrytie kódu a tým aj dôveru v jeho správnosť.

Techniky experience-based testingu

Najznámejšie používané techniky experience-based testingu popísané v nasledujúcich kapitolách sú bug estimation (odhadovanie chýb), exploratory testing (prieskumné testovanie) a checklist-based testing (testovanie založené na kontrolných zoznamoch).

Bug estimation

Bug estimation je technika používaná na predvídanie výskytu chýb, defektov a zlyhaní na základe znalostí testerov. Táto technika čerpá z:

• Toho, ako fungovala aplikácia v minulosti.
• Typických vývojárskych chýb a typických defektov, ktoré sú dôsledkom týchto chýb.
• Typických zlyhaní, ktorá nastala v iných aplikáciách.

Chyby môžu súvisieť so vstupmi, výstupmi, logikou, výpočtami, rozhraniami alebo dátami. Jednou z metód tejto techniky je útok na vady, pri ktorom testeri zostavujú zoznam potenciálnych chýb, defektov a zlyhaní. Na základe tohto zoznamu navrhujú testy, ktoré majú za cieľ tieto problémy identifikovať, odhaliť alebo vyvolať. Zoznamy chýb môžu byť zostavené z osobných skúseností, dát o defektoch, zlyhaniach alebo zo všeobecného pochopenia príčin zlyhávania softvéru.

Praktický príklad

Predstavme si tím, ktorý testuje nový modul e-shopu na výpočet celkovej ceny objednávky, vrátane daní a zliav. Testeri vedia, že v predchádzajúcich verziách aplikácie sa často objavovali chyby spojené s nesprávnym výpočtom DPH pri rôznych typoch tovaru. Preto pri test planingu navrhujú scenáre, ktoré sa zamerajú na správne uplatnenie DPH pri rôznych produktoch.

Exploratory testing

Exploratory testing je metóda, pri ktorej sú testy navrhované, vykonávané a vyhodnocované v reálnom čase, zatiaľ čo testeri získavajú znalosti o testovanom objekte. Cieľom je hlbšie preskúmať softvér, odhaliť doposiaľ netestované oblasti a vytvoriť cielené testy.

Exploratory testing je možné štruktúrovať pomocou testovania v reláciách, kedy testeri pracujú v definovaných časových úsekoch a používajú tzv. testovaciu listinu, ktorá špecifikuje ciele testovania. Po relácii nasleduje debriefing, kde sa diskutujú výsledky so zainteresovanými stranami. Testovacie relácie sú dokumentované pomocou test session sheets, ktoré zaznamenávajú vykonané kroky a zistenia.

Táto technika je užitočná v situáciách, keď špecifikácia chýba, je nedostatočná alebo keď je na testovanie málo času. Exploratory testing môže efektívne dopĺňať iné testovacie techniky a je najúčinnejší, keď sú testeri skúsení, majú znalosti z domény a sú vybavení analytickými schopnosťami, zvedavosťou a kreativitou.

Praktický príklad

Predstavme si, že tím testuje mobilnú aplikáciu na rezerváciu reštaurácií, ale dokumentácia je nedostatočná a chýbajú podrobné špecifikácie funkcií.

Tester dostane 60 minút na preskúmanie časti aplikácie, ktorá umožňuje používateľom rezervovať stôl v reštaurácii. Bez vopred definovaných test casov prechádza aplikáciu, skúša rôzne scenáre. Tester má za cieľ preskúmať, ako sa aplikácia chová pri zmene rezervácie, zrušení rezervácie alebo pri pokuse rezervovať reštauráciu, ktorá je plne obsadená. Tento cieľ je súčasťou jeho testovacej listiny, ktorá ho pri testovaní vedie. Po dokončení relácie tester vykoná debriefing s vývojovým tímom, kde zhrnie svoje zistenia. Tester taktiež zdokumentuje kroky a chyby v test session sheet pre budúce využitie a prípadné opravy.

Checklist-based testing

Pri checklist-based testingu testeri vytvárajú, implementujú a vykonávajú testy za účelom pokrytia podmienok uvedených v kontrolnom zozname. Kontrolné zoznamy vznikajú na základe skúseností testerov, znalostí o tom, čo je dôležité pre užívateľov, alebo na základe pochopenia dôvodov, prečo softvér zlyháva.

Kontrolné zoznamy by mali byť konkrétne a neobsahovať automatizovateľné položky, príliš všeobecné body alebo položky vhodné ako vstupné či výstupné kritériá. Položky sú často formulované ako otázky a malo by ich byť možné overiť oddelene. Kontrolné zoznamy môžu zahŕňať požiadavky, vlastnosti používateľského rozhrania, kvalitatívne charakteristiky a ďalšie formy testovacích podmienok. Podporujú functional aj non-functional testing:

Testovací tím prejde každú položku zoznamu a overí, či aplikácia spĺňa dané podmienky, pričom výsledky testovania zaznamená a kontrolný zoznam pravidelne aktualizuje na základe nájdených problémov.

Postupom času môžu byť niektoré položky menej efektívne, pretože vývojári sa vyhýbajú predchádzajúcim chybám. Preto je dôležité kontrolné zoznamy pravidelne aktualizovať na základe analýzy defektov, pridávať nové položky podľa závažnosti novo objavených chýb, ale tiež sa vyvarovať nadmerného predlžovania zoznamu.

V prípadoch, keď nie sú k dispozícii podrobné test casy, môže testovanie založené na kontrolných zoznamoch poskytnúť určitý rámec a konzistenciu. Pretože ide však o všeobecné zoznamy, môže sa objaviť variabilita v test execution, čo síce môže viesť k širšiemu pokrytiu, ale aj k menšej opakovateľnosti testov.

Zdrojom tejto lekcie sú Učebné osnovy – Certifikovaný tester základnej úrovne ver. 4.0. Copyright © 2023 autori verzie 4.0: Renzo Cerquozzi, Wim Decoutere, Klaudia Dussa-Zieger, Jean-François Riverin, Arnika Hryszko, Martin Klonk, Michaël Pilaeten, Meile Posthuma, Stuart Reid, Eric Riou du Cosquer (predseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (podpredseda), Eshraka Zakaria

V nasledujúcom kvíze, Kvíz - Revízia, návrh testov a white-box testing, si vyskúšame nadobudnuté skúsenosti z predchádzajúcich lekcií.