Lekce 6 - Statické testování

V předchozí lekci, Úrovně testování, jsme si rozlišili různé úrovně testování a různé typy testů a nakonec jsme shrnuli konfirmační a regresní testování.

V dnešní lekci static testingu se podíváme na testování údržby, vysvětlíme si základy i hodnotu static testingu a porovnáme si odlišnosti mezi static a dynamic testingem.

Testování údržby

Údržba softwaru může mít různé podoby, včetně oprav, přizpůsobení změnám prostředí, zlepšení výkonu nebo udržovatelnosti. Údržba může být plánovaná i neplánovaná (např. hotfix). Než ke změnám přistoupíme, je často vhodné provést analýzu dopadu, která pomáhá posoudit potenciální důsledky změn v jiných částech systému. Testování změn v systému, který je již v provozu, zahrnuje jak ověření správnosti implementace, tak zajištění, že změny nezpůsobily regresi v nezměněných částech systému. Rozsah testování údržby závisí na míře rizika změny, velikosti stávajícího systému a rozměru změny:

Spouštěče údržby a testování údržby lze rozdělit takto:

• Úpravy, jako jsou plánovaná vylepšení, opravné změny nebo hotfixy, tedy urgentní opravy softwaru, které se nasazují okamžitě po zjištění kritické chyby, aby se problém rychle vyřešil bez čekání na další plánovanou aktualizaci.
• Aktualizace nebo migrace provozního prostředí, kdy je nutné provést testy spojené s novým prostředím či změněným softwarem, případně testy konverze dat, kdy jsou data z jiné aplikace migrována do systému, který je udržován.
• Vyřazení aplikace z provozu na konci její životnosti. Při vyřazení aplikace nebo systému může být vhodné provést testování archivace dat, a to zejména tehdy, jsou-li pro data požadovány dlouhé lhůty archivace. Pro případ, kdy by bylo během doby archivace nutné načíst některá archivovaná data, je možné otestovat také procesy obnovení a načtení.

Základy static testingu

Na rozdíl od dynamic testingu není při static testingu nutné testovaný software spouštět. Kód, specifikace procesu či architektury systému nebo jiné pracovní produkty jsou hodnoceny a prověřovány buď manuálně, nebo pomocí nástroje. Mezi cíle testování patří zlepšování kvality, odhalování defektů a posuzování vlastností, jako je čitelnost, úplnost, správnost, testovatelnost a konzistence. Static testing lze používat jak pro ověřování, tak pro validaci:

Cíle static testingu

Testeři, zástupci byznysu a vývojáři během popisu příkladů, psaní uživatelských scénářů a zpřesňování backlogu spolupracují tak, aby uživatelské scénáře a související pracovní produkty splňovaly definovaná kritéria, např. definice připravenosti. Techniky revizí lze použít k zajištění toho, aby uživatelské scénáře byly úplné a srozumitelné a obsahovaly testovatelná acceptance criteria. Tím, že testeři kladou správné otázky, vlastně zkoumají, konfrontují a pomáhají vylepšovat navrhované uživatelské scénáře. Například při revizi scénáře pro přidávání položek do košíku testeři navrhnou doplnit, co se stane, když uživatel přidá položku, která není skladem. Kladením otázek testeři zajistí, že acceptance criteria zahrnou i tento okrajový případ a scénář bude srozumitelný a testovatelný.

Static analysis a její přínosy

Static analysis může upozornit na problémy ještě před provedením dynamic testingu, přičemž často vyžaduje menší pracnost – není při ní nutná tvorba test casů a lze u ní využít různé nástroje. Static analysis je často začleněna do nástrojů continuous integration. I když se z velké části používá k odhalování specifických defektů kódu, lze ji také uplatnit k vyhodnocení udržovatelnosti a bezpečnosti. Dalšími příklady nástrojů static analysis jsou nástroje pro kontrolu pravopisu a čitelnosti. Při static analysis kódu e-shopu nástroj například automaticky odhalí potenciální bezpečnostní riziko v podobě špatného zacházení s uživatelskými vstupy, aniž je nutné spouštět testy. Tímto způsobem se problém identifikuje rychleji a bez potřeby vytvářet nové test casy.

Pracovní produkty, které mohou být prověřeny static testingem

Pomocí static testingu může být prozkoumán téměř každý pracovní produkt. Mezi takové produkty patří například specifikace požadavků, zdrojový kód, test plans, test casy, položky produktového backlogu, testovací listiny, projektová dokumentace, smlouvy nebo modely.

Revizi lze použít na jakýkoli pracovní produkt, který lze přečíst a jemuž lze porozumět. Pro static analysis je nutné, aby zkoumané pracovní produkty měly formální strukturu, vůči které mohou být kontrolovány. Pracovní produkty, jež nejsou pro static testing vhodné, jsou obvykle ty, které lidé obtížně interpretují a které by současně neměly být analyzovány nástroji.

Přínosy static testingu

Static testing může odhalit defekty v nejranějších fázích SDLC, čímž naplňuje princip včasného testování. Může také odhalit defekty, které nelze zjistit dynamic testingem. Například nedosažitelný kód, chybně implementované návrhové vzory nebo defekty v nespustitelných pracovních produktech.

Static testing vytváří důvěru v dané pracovní produkty a umožňuje vyhodnotit jejich kvalitu. Ověřením zdokumentovaných požadavků mohou všichni zástupci zainteresovaných stran také zajistit, aby tyto požadavky odrážely jejich skutečné potřeby. Vzhledem k tomu, že static testing může být prováděn v raných fázích SDLC, je možné nastavit pravidla jednotného chápání, čímž se také zlepší komunikace mezi zainteresovanými stranami. Z tohoto důvodu se doporučuje zapojit do static testingu různé typy účastníků.

I když může být provedení revizí nákladné, celkové výdaje na projekt jsou obvykle mnohem nižší, než když se revize neprovádí vůbec. Důvodem je to, že později v projektu není potřeba vynaložit tolik času a pracnosti na opravu defektů. Některé defekty v kódu lze odhalit pomocí static analysis mnohem efektivněji než při dynamic testingu, což obvykle vede k jejich menšímu počtu a tím i nižší celkové pracnosti při vývoji.

Rozdíly mezi static a dynamic testingem

Static a dynamic testovací postupy se vzájemně doplňují. Mají podobné cíle, ale existují mezi nimi také určité rozdíly. Jak static, tak dynamic testing může vést k odhalení defektu, nicméně existují některé typy poruch, které lze nalézt buď jenom static, nebo jenom dynamic testingem:

Static testing najde defekty přímo, zatímco dynamic testing hledá selhání, ze kterých jsou příslušné defekty určeny následnou analýzou. Static testing může také snadněji odhalovat defekty obtížně dosažitelné pomocí dynamic testingu nebo takové, které jsou v kódu v částech spouštěných jen zřídka. Dynamic testing lze použít pouze na spustitelné pracovní produkty, static testing naproti tomu i na nespustitelné. Static testing může měřit kvalitativní charakteristiky nezávislé na spuštění kódu, dynamic testing pouze ty, které jsou na spuštění kódu závislé.

Mezi typické defekty odhalitelné snadněji a levněji static testingem patří:

• defekty v požadavcích,
• defekty v návrhu,
• některé typy defektů při programování,
• odchylky od norem,
• nesprávné specifikace rozhraní,
• některé bezpečnostní zranitelnosti,
• chybějící části nebo nepřesnosti v pokrytí testovací báze.

Praktický příklad

Představme si vývoj webové aplikace pro rezervaci hotelů, kde se uplatňuje static testing.

Tým testerů spolu s vývojáři a zástupci byznysu provádí manuální revizi uživatelských scénářů, které popisují, jak uživatelé mohou rezervovat hotel. Testeři kladou otázky ohledně nejasných scénářů, například jak bude aplikace reagovat, když uživatel zruší rezervaci těsně před jejím dokončením. Před nasazením nové verze aplikace vývojáři spustí static analysis kódu pomocí nástroje, který kontroluje kód na možné chyby, jako jsou nedokončené podmínky, nevyužité proměnné nebo bezpečnostní zranitelnosti. Nástroj odhalí potenciální problém s bezpečností při zpracování uživatelských dat, což by mohlo vést k úniku citlivých informací. Tento problém je opraven dříve, než dojde k dynamic testingu aplikace.

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 následujícím kvízu, Kvíz - DevOps, úrovně testování a statické testování, si vyzkoušíme nabyté zkušenosti z předchozích lekcí.