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, vysvetlíme si základy aj 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 udržiavateľnosti. Údržba môže byť plánovaná aj neplánovaná (napr. hotfix). Než k zmenám pristúpime, je často vhodné vykonať analýzu vplyvu, ktorá pomáha posúdiť potenciálne dôsledky zmien 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 rozmeru 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 problém rýchlo vyriešil 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 či 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ä vtedy, ak sú pre dáta 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 testingu nutné testovaný softvér spúšťať. Kód, špecifikácia procesu či 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ícia 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 testeri zaistia, ž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ť – nie je pri nej nutná tvorba test časov a je možné u nej využiť rôzne nástroje. Static analysis je často začlenená do nástrojov continuous integration. Aj keď sa z veľkej časti používa na odhaľovanie špecifických defektov kódu, je možné ju tiež uplatniť 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. Pri static analysis kóde e-shopu nástroj napríklad 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
Pomocou static testingu môže byť preskúmaný takmer každý pracovný produkt. 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 ktorému možno porozumieť. Pre static analysis je nutné, aby skúmané pracovné produkty mali formálnu štruktúru, voči ktorej môžu byť kontrolované. Pracovné produkty, ktoré nie sú pre static testing vhodné, sú obvykle tie, ktoré ľudia ťažko interpretujú a ktoré by súčasne 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é výdavky na projekt sú obvykle oveľa nižšie, než keď sa revízia nevykonáva vôbec. 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 porúch, ktoré možno nájsť buď iba static, alebo len 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 naproti tomu aj na nespustiteľné. Static testing môže merať kvalitatívne charakteristiky nezávislé na spustení kódu, dynamic testing iba tie, 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 vývojári spustia 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 nasledujúcom kvíze, Kvíz - DevOps, úrovne testovania a statické testovanie, si vyskúšame nadobudnuté skúsenosti z predchádzajúcich lekcií.
