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 techniky white-box testing 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 testing. Ďalšou témou budú techniky experience-based testing, odhadovanie chýb, prieskumné testovanie a nevynecháme ani testovanie založené na kontrolných zoznamoch.

Techniky white-box testing

Dve najbežnejšie techniky white-box testing sú statement testing (testovanie príkazov) a branch testing (testovanie vetiev) a 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 techniky, ktoré sa používajú v bezpečnostne, prevádzkovo alebo integračne kritických prostrediach, kde je cieľom dosiahnuť vyšší stupeň pokrytia. testovanie, 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. pri testovaní.

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 aj 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. :

• 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 vetví.

Pokrytie vetiev sa meria ako percento všetkých vetiev, ktoré boli otestované. 100% pokrytie vetiev znamená, že boli otestované všetky možné cesty, ktorými sa kód môže vydať. 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ď máme 100% pokrytie vetiev, znamená to, že sme automaticky prešli všetkými príkazmi kódu. možné cesty kódom.

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 KalkulackaObjednavky {

    public static double vypocetCeny(int mnozstvi, double cenaZaKus, double sleva) {
        double celkovaCena;

        if (mnozstvi > 10) {
            celkovaCena = mnozstvi * cenaZaKus * (1 - sleva);  // Aplikujeme slevu, pokud je množství větší než 10
        } else {
            celkovaCena = mnozstvi * cenaZaKus;  // Bez slevy
        }

        return celkovaCena;
    }
}

Metóda vypocetCeny mnozstvi tri parametre. Množstvo, cenu za kus a zľavu, ktorá sa aplikuje iba pri nákupe viac ako 10 kusov, zľavu uplatníme.

Pokrytie príkazov

Pri pokrytí príkazov bude metóda s parametrami vypocetCeny(15, 100, 0.1), vykoná teda príkaz:

celkovaCena = mnozstvi * cenaZaKus * (1 - sleva);

Pretože prvý parameter metódy mnozstvi > 10. Tým dosiahneme 100% pokrytie príkazov, pretože každý spustiteľný príkaz v metóde vypocetCeny je vykonaný aspoň raz.

Pokrytie vetiev

Pre else % pokrytie vypocetCeny(5, 100, 0.1) musíme otestovať obe cesty v podmienke if (mnozstvi > 10) i vetva else.

celkovaCena = mnozstvi * cenaZaKus;

Pretože mnozstvi < 10. Takto zaistíme 100% pokrytie vetiev, pretože máme testovacie prípady pre obe možné cesty v podmienke.

Význam white-box testing

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

Tieto techniky je možné využiť pri static testing, 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, 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 testing

Najznámejšie používané techniky experience-based testing popísané v nasledujúcich kapitolách sú bug estimation (odhadovanie chýb), exploratory testing (prieskumné testovanie), 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.

• ako fungovala aplikácia v minulosti,
• typické vývojárske chyby a typické defekty, ktoré sú dôsledkom týchto chýb,
• typické zlyhania, ktoré nastali 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í. problémy identifikovať, odhaliť alebo vyvolať Zoznamy chýb môžu byť zostavené z osobných skúseností, dát o defektoch, zlyhaniach alebo z 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. , ktoré sa zamerajú na správne uplatnenie DPH na rôzne produkty.

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ť doteraz 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. ktoré zaznamenávajú vykonané kroky a zistenia.

Táto technika je užitočná v situáciách, keď špecifikácia chýba alebo 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 časov prechádza aplikáciu, skúša rôzne scenáre. je plne obsadená. Tento cieľ je súčasťou jeho testovacej listiny, ktorá ho vedie pri testovaní. debriefing s vývojovým tímom, kde zhrnie svoje zistenia. Tester tiež zdokumentuje kroky a chyby v teste session sheet pre budúce využitie a prípadné opravy.

Checklist-based testing

Pri checklist-based testing 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á Často sú položky formulované ako otázky a každú položku by malo byť možné overiť oddelene Kontrolné zoznamy môžu zahŕňať požiadavky, vlastnosti uží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 sú zaznamenané a kontrolný zoznam je pravidelne aktualizovaný 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. Avšak, pretože ide 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šie opakovateľnosti testov.

Zdrojom tejto lekcie sú Učebné osnovy - Certifikovaný tester základnej úrovne ver. 4.0. Stuart Reid, Eric Riou du Cosquer (predseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (podpredseda), Eshraka Zakaria

V budúcej lekcii, Prístupy k testovaniu založené na spolupráci , si ukážeme poslednú techniku - prístupy k testovaniu založené na spolupráci, ktoré zahŕňajú spoločné písanie užívateľských scenárov, akceptačné kritériá a vývoj riadený akceptačnými testami.