5. diel - Úrovne testovania Nové

V predchádzajúcej lekcii, Testovanie v priebehu SDLC druhýkrát - DevOps a automatizácia , sme sa pozreli na vývoj softvéru riadený testovaním, vysvetlili sme si, čo je DevOps a shift-left prístup. Nakoniec sme si vysvetlili retrospektívy a zlepšovanie procesov.

V dnešnej lekcii, v ktorej sa venujeme úrovniam testovania, si rozlíšime rôzne úrovne testovania a rôzne typy testov. Pozrieme sa tiež na confirmation a regression testing.

Úrovne testovania a typy testov

Úrovne testovania sú skupiny testovacích aktivít vykonávaných v rôznych fázach vývoja softvéru, od jednotlivých komponentov až po celé systémy alebo systémy systémov. Každá úroveň je špecifickou inštanciou testovacieho procesu, ktorý zodpovedá danej fáze vývoja softvéru.

Tieto úrovne sú úzko prepojené s ostatnými činnosťami v rámci SDLC. V sequential development models sú úrovne testovania jasne oddelené, kde výstup jednej úrovne tvorí vstup do ďalšej. Napríklad pri vývoji aplikácie pre správu úloh tím najprv definuje všetky požiadavky a potom navrhne, naprogramuje a otestuje aplikáciu ako celok. Akonáhle sa začne s ďalšou fázou, nie je ľahké sa vrátiť späť a meniť fázy predchádzajúce:

V iterative development models sa však môžu úrovne testovania prekrývať a vývojové aktivity môžu prebiehať naprieč viacerými úrovňami. Pri vývoji aplikácie pre správu úloh teda tím najprv vytvorí základnú funkciu na pridávanie úloh, otestuje ju a postupne pridáva ďalšie funkcie, ako pripomienky alebo zdieľanie. Každú verziu aplikácie môže tím priebežne vylepšovať na základe spätnej väzby:

Typy testov sú skupiny aktivít zamerané na konkrétne kvalitatívne vlastnosti softvéru a môžu byť vykonávané v ľubovoľnej úrovni testovania. Typy testov si vysvetlíme ďalej v lekcii.

Úrovne testovania

Aby nedochádzalo k prekrývaniu činností pri testovaní v jednotlivých úrovniach, čiastkové úrovne testovania sa odlišujú špecifickou definíciou rôznych atribútov. Medzi najdôležitejšie atribúty patrí testovaný objekt, ciele testovania, testovacie bázy, defekty a zlyhania, prístup a zodpovednosti. Popíšeme si päť úrovní testovania:

Unit testing

Unit testing (testovanie komponentov) sa zameriava na testovanie izolovaných komponentov. Na ich vykonávanie je často potrebný špeciálny softvér, napr. rôzne sady testovacieho vybavenia alebo frameworky na jednotkové testovanie. Unit testing obvykle vykonávajú vývojári vo svojich vývojových prostrediach. Vývojár napríklad testuje funkciu na výpočet ceny objednávky v e-shope, aby sa ubezpečil, že správne počíta cenu na základe množstva či zľavy. Tento test prebieha v jeho vývojovom prostredí a je izolovaný od ostatných častí aplikácie.

Component integration testing

Component integration testing (integračné testovanie komponentov) sa zameriava na testovanie rozhrania a interakcií medzi komponentmi. Toto testovanie je silne závislé na zvolenej integračnej stratégii. Tím môže treba testovať, či modul pre pridanie položiek do košíka správne komunikuje s platobným systémom, aby overil, že po pridaní položky je možné korektne vykonať platbu.

System testing

System testing (systémové testovanie) sa zameriava na celkové správanie a schopnosti celého systému alebo produktu, často vrátane functional testing (funkcionálneho testovania) komplexných úloh a non-functional testing (nefunkcionálneho testovania) kvalitatívnych charakteristík. Niektoré z nich je vhodnejšie testovať na úplnom systéme vo vhodnom testovacom prostredí. Okrem iného je možné využívať simuláciu subsystémov. System testing vychádza zo špecifikácií systému a môže byť vykonávaný nezávislým testovacím tímom. Testovací tím napríklad testuje celú e-shopovú aplikáciu, vrátane toho, ako funguje správa užívateľských účtov, spracovanie objednávok a doručovanie. Testeri skúmajú, či systém funguje podľa špecifikácií, a vykonávajú ako functional, tak aj non-functional testy, napríklad meranie výkonu pri vysokom zaťažení.

System integration testing

System integration testing (systémové integračné testovanie) sa zameriava na testovanie rozhrania medzi testovaným systémom a ďalšími systémami alebo externými službami. Pre system integration testing je potrebné mať vhodné testovacie prostredie, pokiaľ možno podobné prevádzkovému. Tím napríklad testuje, či e-shop správne integruje platobnú bránu tretej strany a externú službu na sledovanie zásielok, aby sa ubezpečil, že komunikácia medzi systémami prebieha bez problémov.

Aceptance testing

Acceptance testing (akceptačné testovanie) sa zameriava na preukázanie pripravenosti systému na nasadenie do produkčného prostredia a validuje, že systém spĺňa užívateľove biznisové potreby. V ideálnom prípade by aceptance testing mali vykonávať koncoví užívatelia. Najčastejšími formami aceptance testing sú user aceptance testing (užívateľské akceptačné testovanie, UAT), operational aceptance testing (prevádzkové akceptačné testovanie), contractual aceptance testing (zmluvné akceptačné testovanie), regulatory aceptance testing (regulátorné akceptačné testovanie), alpha testing beta testing (beta testovanie). Tu napríklad koncoví používatelia testujú e-shop pred jeho uvedením do prevádzky, aby overili, že systém spĺňa všetky biznisové požiadavky, ako je správne spracovanie objednávok a jednoduchá správa zákazníckych dát.

Typy testov

Existuje mnoho typov testov, ktoré je možné na projektoch použiť. My sa budeme zaoberať štyrmi typmi testov:

Functional testing overuje funkcionality, ktoré by komponent alebo systém mali vykonávať. Hlavným cieľom functional testingu je kontrola funkcionálnej úplnosti, funkcionálnej správnosti a funkcionálnej vhodnosti. Tester napríklad overuje, či používateľ môže správne pridať tovar do nákupného košíka, zobraziť jeho obsah a dokončiť objednávku. Cieľom je zistiť, či všetky tieto funkcie pracujú podľa požiadaviek.

Non-functional testing vyhodnocuje nefunkcionálne charakteristiky komponentu alebo systému a dáva tak odpoveď na otázku, ako dobre sa systém chová. Zoznam nefunkcionálnych charakteristík kvality softvéru možno nájsť v norme ISO/IEC 25010:

• výkonnostná efektivita,
• kompatibilita,
• použiteľnosť,
• bezporuchovosť (spoľahlivosť),
• bezpečnosť,
• udržiavateľnosť,
• prenositeľnosť.

Non-functional testy môžu byť odvodené z functional testov, kedy sa overuje, či sú nefunkčné požiadavky splnené pri vykonávaní konkrétnej funkcie. Neskoré odhalenie nefunkčného defektu môže ohroziť úspech projektu. Preto niekedy non-functional testing začína už v raných fázach SDLC a môže vyžadovať špeciálne prostredie, ako je laboratórium na testovanie použiteľnosti. Tester napríklad vykonáva výkonnostné testy na e-shope, aby zistil, ako rýchlo sa načítajú stránky pri veľkom množstve užívateľov alebo ako dobre aplikácia zvláda záťaž počas nákupných sezón.

Black-box testing (testovanie čiernej skrinky) je založené na špecifikácii a odvodzuje testy z dokumentácie testovaného objektu. Hlavným cieľom black-box testingu je kontrola správania systému podľa jeho špecifikácie. Tester môže treba testovať funkciu výpočtu celkovej ceny v e-shope iba na základe špecifikácie bez toho, aby skúma vnútorný kód. Zadá rôzne kombinácie tovaru, zliav a dopravy a kontroluje, či systém vracia správnu celkovú cenu.

White-box testing (testovanie bielej skrinky) je založený na štruktúre a odvodzuje testy z implementácie systému alebo z jeho vnútornej štruktúry, čo je napr. kód, architektúra, pracovné toky (workflows) alebo dátové toky. Hlavným cieľom white-box testingu je dosahovať dostatočné pokrytie testovanej štruktúry. Vývojár alebo tester napríklad skúmajú kód funkcie pre výpočet ceny v e-shope a overujú, že všetky vetvy a podmienky v kóde boli pokryté testami, aby zabezpečili, že žiadna časť kódu nebola zabudnutá.

Všetky tieto testy je možné aplikovať na rôznych úrovniach testovania, pričom konkrétna implementácia sa môže líšiť. Rôzne techniky testovania možno použiť na odvodenie testovacích podmienok a prípadov pre každý z týchto typov testov.

Confirmation a regression testing

Pri vykonávaní zmien v komponente alebo systéme, či už ide o opravy, alebo rozšírenie, je dôležité zahrnúť tak confirmation, ako aj regression testing.

Confirmation testing overuje, či bol pôvodný defekt úspešne opravený. V závislosti od rizika je možné otestovať opravenú verziu softvéru niekoľkými rôznymi spôsobmi, napr. vykonaním všetkých test časov, ktoré predtým zlyhali kvôli defektu, alebo pridaním nových testov s cieľom pokryť všetky zmeny potrebné na opravu defektu. V prípadoch s obmedzenými zdrojmi môže confirmation testing spočívať iba v opakovaní krokov, ktoré pôvodne viedli k zlyhaniu, av overení, že už k nemu nedochádza.

Regression testing zaisťuje, že po zmenách nedošlo k nežiaducim vedľajším efektom, ktoré by mohli ovplyvniť ako upravený komponent, tak ďalšie časti systému, alebo dokonca prepojené systémy. Preto je vhodné vopred vykonať analýzu vplyvu, ktorá identifikuje oblasti softvéru, ktoré by mohli byť zmenami ovplyvnené. Regression testing nie je obmedzený iba na daný objekt, ale môže zahŕňať aj testovanie prostredia. Sady regression testov sa obvykle spúšťajú opakovane a ich rozsah sa s každou iteráciou zvyšuje, preto sú ideálnym kandidátom na automatizáciu, ktorú je vhodné začať implementovať už v raných fázach projektu. Automated regression tests sa často zaraďujú do CI pipeline a môžu sa vykonávať na rôznych úrovniach testovania.

Confirmation i regression testing sa vykonáva na úrovniach testovania, kde boli vykonané opravy alebo zmeny.

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

V budúcej lekcii, Statické testovanie , sa pozrieme na testovanie údržby, vysvetlíme si základy aj hodnotu statického testovania a porovnáme si odlišnosti statického a dynamického testovania.