6. diel - Statické testovanie Nové
V predchádzajúcej lekcii Úrovne testovania sme si rozlíšili rôzne úrovne testovania a rôzne typy testov a nakoniec sme zhrnuli konfirmačné a regresné testovanie.
V dnešnej lekcii static testingu sa pozrieme na testovanie údržby, základy static testingu, vysvetlíme si hodnotu static testingu a porovnáme si odlišnosti medzi static a dynamic testingom.
Testovanie údržby
Údržba softvéru môže mať rôzne podoby, vrátane opráv, prispôsobenie zmenám prostredia, zlepšenie výkonu alebo zlepšenie udržiavateľnosti. Môže byť plánovaná aj neplánovaná (napr. hotfix). Pred vykonaním zmeny je často vhodné vykonať analýzu vplyvu, ktorá pomáha posúdiť potenciálne dôsledky zmeny v iných častiach systému. Testovanie zmien v systéme, ktorý je už v prevádzke, zahŕňa ako overenie správnosti implementácie, tak zaistenie, že zmeny nespôsobili regresiu v nezmenených častiach systému. Rozsah testovania údržby závisí od miery rizika zmeny, veľkosti existujúceho systému a rozsahu zmeny:
Spúšťače údržby a testovanie údržby je možné rozdeliť takto:
- Úpravy ako sú plánované vylepšenia, opravné zmeny alebo hotfixy teda urgentné opravy softvéru, ktoré sa nasadzujú okamžite po zistení kritickej chyby, aby sa rýchlo vyriešil problém bez čakania na ďalšiu plánovanú aktualizáciu.
- Aktualizácia alebo migrácia prevádzkového prostredia, kedy je nutné vykonať testy spojené s novým prostredím a zmeneným softvérom, prípadne testy konverzie dát, kedy sú dáta z inej aplikácie migrované do systému, ktorý je udržiavaný.
- Vyradenie aplikácie z prevádzky na konci jej životnosti. Pri vyradení aplikácie alebo systému môže byť vhodné vykonať testovanie archivácie dát, a to najmä pre také dáta, pre ktoré sú požadované dlhé lehoty archivácie. Pre prípad, kedy by bolo počas doby archivácie nutné načítať niektoré archivované dáta, je možné otestovať aj procesy obnovenia a načítania.
Na rozdiel od dynamic testingu nie je pri static testing nutné testovaný softvér spúšťať. Kód, špecifikácia procesu, špecifikácia architektúry systému alebo iné pracovné produkty sú hodnotené a preverované buď manuálne alebo pomocou nástroja. Medzi ciele testovania patrí zlepšovanie kvality, odhaľovanie defektov a posudzovanie vlastností ako je čitateľnosť, úplnosť, správnosť, testovateľnosť a konzistencia. Static testing je možné používať ako pre overovanie, tak pre validáciu:
Ciele static testingu
Testeri, zástupcovia biznisu a vývojári počas popisu príkladov, písania užívateľských scenárov a spresňovania backlogu spolupracujú tak, aby užívateľské scenáre a súvisiace pracovné produkty spĺňali definované kritériá, napr. definície pripravenosti. Techniky revízií je možné použiť na zabezpečenie toho, aby užívateľské scenáre boli úplné a zrozumiteľné a obsahovali testovateľná aceptancia criteria. Tým, že testeri kladú správne otázky vlastne skúmajú, konfrontujú a pomáhajú vylepšovať navrhované užívateľské scenáre. Napríklad pri revízii scenára na pridávanie položiek do košíka testeri navrhnú doplniť, čo sa stane, keď používateľ pridá položku, ktorá nie je skladom. Kladením otázok zaistí, že aceptance criteria zahrnú aj tento okrajový prípad a scenár bude zrozumiteľný a testovateľný.
Static analysis a jej prínosy
Static analysis môže upozorniť na problémy ešte pred vykonaním dynamic testingu, pričom často vyžaduje menšiu prácnosť – nevyžaduje totiž tvorbu test časov a je možné u nej využiť rôzne nástroje. Static analysis je často začlenená do nástrojov continous integration. Aj keď sa z veľkej časti používa na odhaľovanie špecifických defektov kódu, možno ju tiež použiť na vyhodnotenie udržovateľnosti a bezpečnosti. Ďalšími príkladmi nástrojov static analysis sú nástroje na kontrolu pravopisu a čitateľnosti. Napríklad pri static analysis kóde e-shopu nástroj automaticky odhalí potenciálne bezpečnostné riziko v podobe zlého zaobchádzania s užívateľskými vstupmi bez toho, aby bolo nutné spúšťať testy. Týmto spôsobom sa problém identifikuje rýchlejšie a bez potreby vytvárať nové test casy.
Pracovné produkty, ktoré môžu byť preverené static testingom
Takmer každý pracovný produkt môže byť preskúmaný pomocou static testing. Medzi také produkty patria napríklad špecifikácie požiadaviek, zdrojový kód, test plans, test casy, položky produktového backlogu, testovacie listiny, projektová dokumentácia, zmluvy alebo modely.
Revíziu je možné použiť na akýkoľvek pracovný produkt, ktorý je možné prečítať a porozumieť mu. Pre static analysis je nutné, aby mali skúmané pracovné produkty formálnu štruktúru, voči ktorej môžu byť kontrolované. Pracovné produkty, ktoré nie sú vhodné pre static testing, sú obvykle tie, ktoré sú ťažko interpretovateľné ľuďmi a súčasne by nemali byť analyzované nástrojmi.
Prínosy static testingu
Static testing môže odhaliť defekty v najskorších fázach SDLC, čím napĺňa princíp včasného testovania. Môže tiež odhaliť defekty, ktoré nemožno zistiť dynamic testingom. Napríklad nedosiahnuteľný kód, chybne implementované návrhové vzory alebo defekty v nespustiteľných pracovných produktoch.
Static testing vytvára dôveru v dané pracovné produkty a umožňuje vyhodnotiť ich kvalitu. Overením zdokumentovaných požiadaviek môžu všetci zástupcovia zainteresovaných strán tiež zabezpečiť, aby tieto požiadavky odrážali ich skutočné potreby. Vzhľadom na to, že static testing môže byť vykonávaný v raných fázach SDLC, je možné nastaviť pravidlá jednotného chápania, čím sa tiež zlepší komunikácia medzi zainteresovanými stranami. Z tohto dôvodu sa odporúča zapojiť do static testingu rôzne typy účastníkov.
Aj keď môže byť vykonanie revízií nákladné, celkové náklady na projekt sú obvykle oveľa nižšie, než keď sa revízia vôbec nevykonáva. Dôvodom je to, že neskôr v projekte nie je potrebné vynaložiť toľko času a prácnosti na opravu defektov. Niektoré defekty v kóde je možné odhaliť pomocou static analysis oveľa efektívnejšie ako pri dynamic testingu, čo obvykle vedie k ich menšiemu počtu a tým aj nižšej celkovej prácnosti pri vývoji.
Rozdiely medzi static a dynamic testingom
Static a dynamic testovacie postupy sa vzájomne dopĺňajú. Majú podobné ciele, ale existujú medzi nimi aj určité rozdiely. Ako static, tak dynamic testing môže viesť k odhaleniu defektu, avšak existujú niektoré typy defektov, ktoré možno nájsť buď len static alebo iba dynamic testingom:
Static testing nájde defekty priamo, zatiaľ čo dynamic testing hľadá zlyhanie, z ktorých sú príslušné defekty určené následnou analýzou. Static testing môže tiež ľahšie odhaľovať defekty ťažko dosiahnuteľné pomocou dynamic testingu alebo také, ktoré sú v kóde v častiach spúšťaných len zriedka. Dynamic testing je možné použiť iba na spustiteľné pracovné produkty, static testing aj na nespustiteľné. Static testing je možné použiť na meranie kvalitatívnych charakteristík nezávislých na spustení kódu, dynamic testing iba k tým, ktoré sú na spustení kódu závislé.
Medzi typické defekty odhaliteľné ľahšie a lacnejšie static testingom patria:
- defekty v požiadavkách,
- defekty v návrhu,
- niektoré typy defektov pri programovaní,
- odchýlky od noriem,
- nesprávne špecifikácie rozhrania,
- niektoré bezpečnostné zraniteľnosti,
- chýbajúce časti alebo nepresnosti v pokrytí testovacej bázy.
Predstavme si vývoj webovej aplikácie pre rezerváciu hotelov, kde sa uplatňuje static testing:
Tím testerov spolu s vývojármi a zástupcami biznisu vykonáva manuálnu revíziu užívateľských scenárov, ktoré popisujú, ako používatelia môžu rezervovať hotel. Testeri kladú otázky ohľadom nejasných scenárov, napríklad ako bude aplikácia reagovať, keď používateľ zruší rezerváciu tesne pred jej dokončením. Pred nasadením novej verzie aplikácie spustia vývojári static analysis kódu pomocou nástroja, ktorý kontroluje kód na možné chyby, ako sú nedokončené podmienky, nevyužité premenné alebo bezpečnostné zraniteľnosti. Nástroj odhalí potenciálny problém s bezpečnosťou pri spracovaní užívateľských dát, čo by mohlo viesť k úniku citlivých informácií. Tento problém je opravený skôr, ako dôjde k dynamic testingu aplikácie.
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, Proces spätnej väzby a revízie sa pozrieme na proces spätnej väzby a revízie u statického testovania. Zameriame sa na role a zodpovednosti pri revíziách a typy revízií.
