Lekce 5 - Úrovně testování

V předchozí lekci, Testování v průběhu SDLC podruhé - DevOps a automatizace, jsme se podívali na vývoj softwaru řízený testováním, vysvětlili jsme si, co je DevOps a shift-left přístup. Nakonec jsme si vysvětlili retrospektivy a zlepšování procesů.

V dnešní lekci, ve které se věnujeme úrovním testování, si rozlišíme různé úrovně testování a různé typy testů. Podíváme se také na confirmation a regression testing.

Úrovně testování a typy testů

Úrovně testování jsou skupiny testovacích aktivit prováděných v různých fázích vývoje softwaru, od jednotlivých komponent až po celé systémy nebo systémy systémů. Každá úroveň je specifickou instancí testovacího procesu, který odpovídá dané fázi vývoje softwaru.

Tyto úrovně jsou úzce propojeny s ostatními činnostmi v rámci SDLC. V sequential development models jsou úrovně testování jasně oddělené, kde výstup jedné úrovně tvoří vstup do další. Například při vývoji aplikace pro správu úkolů tým nejprve definuje všechny požadavky a pak navrhne, naprogramuje a otestuje aplikaci jako celek. Jakmile se začne s další fází, není snadné se vrátit zpět a měnit fáze předchozí:

V iterative development models se však mohou úrovně testování překrývat a vývojové aktivity mohou probíhat napříč více úrovněmi. Při vývoji aplikace pro správu úkolů tedy tým nejprve vytvoří základní funkci pro přidávání úkolů, otestuje ji a postupně přidává další funkce, jako připomínky nebo sdílení. Každou verzi aplikace může tým průběžně vylepšovat na základě zpětné vazby:

Typy testů jsou skupiny aktivit zaměřené na konkrétní kvalitativní vlastnosti softwaru a mohou být prováděny v libovolné úrovni testování. Typy testů si vysvětlíme dále v lekci.

Úrovně testování

Aby nedocházelo k překrývání činností při testování v jednotlivých úrovních, dílčí úrovně testování se odlišují specifickou definicí různých atributů. Mezi nejdůležitější atributy patří testovaný objekt, cíle testování, testovací báze, defekty a selhání, přístup a zodpovědnosti. Popíšeme si pět úrovní testování:

Unit testing

Unit testing (testování komponent) se zaměřuje na testování izolovaných komponent. Pro jejich provádění je často potřebný speciální software, např. různé sady testovacího vybavení nebo frameworky pro jednotkové testování. Unit testing obvykle provádějí vývojáři ve svých vývojových prostředích. Vývojář například testuje funkci pro výpočet ceny objednávky v e-shopu, aby se ujistil, že správně počítá cenu na základě množství či slevy. Tento test probíhá v jeho vývojovém prostředí a je izolován od ostatních částí aplikace.

Component integration testing

Component integration testing (integrační testování komponent) se zaměřuje na testování rozhraní a interakcí mezi komponentami. Toto testování je silně závislé na zvolené integrační strategii. Tým může třeba testovat, zda modul pro přidání položek do košíku správně komunikuje s platebním systémem, aby ověřil, že po přidání položky lze korektně provést platbu.

System testing

System testing (systémové testování) se zaměřuje na celkové chování a schopnosti celého systému nebo produktu, často včetně functional testing (funkcionálního testování) komplexních úkolů a non-functional testing (nefunkcionálního testování) kvalitativních charakteristik. Některé z nich je vhodnější testovat na úplném systému ve vhodném testovacím prostředí. Kromě jiného lze využívat simulace subsystémů. System testing vychází ze specifikací systému a může být prováděn nezávislým testovacím týmem. Testovací tým například testuje celou e-shopovou aplikaci, včetně toho, jak funguje správa uživatelských účtů, zpracování objednávek a doručování. Testeři zkoumají, zda systém funguje podle specifikací, a provádějí jak functional, tak non-functional testy, například měření výkonu při vysokém zatížení.

System integration testing

System integration testing (systémové integrační testování) se zaměřuje na testování rozhraní mezi testovaným systémem a dalšími systémy nebo externími službami. Pro system integration testing je potřebné mít vhodné testovací prostředí, pokud možno podobné provoznímu. Tým kupříkladu testuje, zda e-shop správně integruje platební bránu třetí strany a externí službu pro sledování zásilek, aby se ujistil, že komunikace mezi systémy probíhá bez problémů.

Acceptance testing

Acceptance testing (akceptační testování) se zaměřuje na prokázání připravenosti systému k nasazení do produkčního prostředí a validuje, že systém splňuje uživatelovy byznysové potřeby. V ideálním případě by acceptance testing měli provádět koncoví uživatelé. Nejčastějšími formami acceptance testing jsou user acceptance testing (uživatelské akceptační testování, UAT), operational acceptance testing (provozní akceptační testování), contractual acceptance testing (smluvní akceptační testování), regulatory acceptance testing (regulatorní akceptační testování), alpha testing (alfa testování) a beta testing (beta testování). Zde například koncoví uživatelé testují e-shop před jeho uvedením do provozu, aby ověřili, že systém splňuje všechny byznysové požadavky, jako je správné zpracování objednávek a jednoduchá správa zákaznických dat.

Typy testů

Existuje mnoho typů testů, které lze na projektech použít. My se budeme zabývat čtyřmi typy testů:

Functional testing ověřuje funkcionality, které by komponenta nebo systém měly vykonávat. Hlavním cílem functional testingu je kontrola funkcionální úplnosti, funkcionální správnosti a funkcionální vhodnosti. Tester například ověřuje, zda uživatel může správně přidat zboží do nákupního košíku, zobrazit jeho obsah a dokončit objednávku. Cílem je zjistit, zda všechny tyto funkce pracují podle požadavků.

Non-functional testing vyhodnocuje nefunkcionální charakteristiky komponenty nebo systému a dává tak odpověď na otázku, jak dobře se systém chová. Seznam nefunkcionálních charakteristik kvality softwaru lze nalézt v normě ISO/IEC 25010:

• výkonnostní efektivita,
• kompatibilita,
• použitelnost,
• bezporuchovost (spolehlivost),
• bezpečnost,
• udržovatelnost,
• přenositelnost.

Non-functional testy mohou být odvozeny z functional testů, kdy se ověřuje, zda jsou nefunkční požadavky splněny při provádění konkrétní funkce. Pozdní odhalení nefunkčního defektu může ohrozit úspěch projektu. Proto někdy non-functional testing začíná již v raných fázích SDLC a může vyžadovat speciální prostředí, jako je laboratoř pro testování použitelnosti. Tester například provádí výkonnostní testy na e-shopu, aby zjistil, jak rychle se načítají stránky při velkém množství uživatelů nebo jak dobře aplikace zvládá zátěž během nákupních sezon.

Black-box testing (testování černé skříňky) je založeno na specifikaci a odvozuje testy z dokumentace testovaného objektu. Hlavním cílem black-box testingu je kontrola chování systému podle jeho specifikace. Tester může třeba testovat funkci výpočtu celkové ceny v e-shopu pouze na základě specifikace, aniž zkoumá vnitřní kód. Zadá různé kombinace zboží, slev a dopravy a kontroluje, zda systém vrací správnou celkovou cenu.

White-box testing (testování bílé skříňky) je založen na struktuře a odvozuje testy z implementace systému nebo z jeho vnitřní struktury, což je např. kód, architektura, pracovní toky (workflows) nebo datové toky. Hlavním cílem white-box testingu je dosahovat dostatečného pokrytí testované struktury. Vývojář nebo tester kupříkladu zkoumají kód funkce pro výpočet ceny v e-shopu a ověřují, že všechny větve a podmínky v kódu byly pokryty testy, aby zajistili, že žádná část kódu nebyla opomenuta.

Všechny tyto testy lze aplikovat na různých úrovních testování, přičemž konkrétní implementace se může lišit. Různé techniky testování lze použít k odvození testovacích podmínek a případů pro každý z těchto typů testů.

Confirmation a regression testing

Při provádění změn v komponentě nebo systému, ať už jde o opravy, nebo rozšíření, je důležité zahrnout jak confirmation, tak regression testing.

Confirmation testing ověřuje, zda byl původní defekt úspěšně opraven. V závislosti na riziku lze otestovat opravenou verzi softwaru několika různými způsoby, např. provedením všech test casů, které dříve selhaly kvůli defektu, nebo přidáním nových testů s cílem pokrýt všechny změny potřebné k opravě defektu. V případech s omezenými zdroji může confirmation testing spočívat pouze v opakování kroků, které původně vedly k selhání, a v ověření, že už k němu nedochází.

Regression testing zajišťuje, že po změnách nedošlo k nežádoucím vedlejším efektům, které by mohly ovlivnit jak upravenou komponentu, tak další části systému, nebo dokonce propojené systémy. Proto je vhodné předem provést analýzu dopadu, která identifikuje oblasti softwaru, jež by mohly být změnami ovlivněny. Regression testing není omezen pouze na daný objekt, ale může zahrnovat také testování prostředí. Sady regression testů se obvykle spouštějí opakovaně a jejich rozsah se s každou iterací zvyšuje, proto jsou ideálním kandidátem pro automatizaci, kterou je vhodné začít implementovat už v raných fázích projektu. Automated regression tests se často zařazují do CI pipeline a mohou se vykonávat na různých úrovních testování.

Confirmation i regression testing se provádí na úrovních testování, kde byly provedeny opravy nebo změny.

Zdrojem této lekce jsou Učební osnovy – Certifikovaný tester základní úrovně ver. 4.0. Copyright © 2023 autoři verze 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 (předseda), Adam Roman, Lucjan Stapp, Stephanie Ulrich (místopředseda), Eshraka Zakaria

V příští lekci, Statické testování, se podíváme na testování údržby, vysvětlíme si základy i hodnotu statického testování a porovnáme si odlišnosti statického a dynamického testování.