Aktuální vydání

celé číslo

05

2021

Perspektivy automatizace, umělá inteligence v automatizaci; prostředky automatizace v době lockdownu
celé číslo

Testování a diagnostika softwaru

Automa 8/2000

Ing. Luboš Král, Ph.D., Ing. Tomáš Hazdra,
Katedra kybernetiky ČVUT Praha

Testování a diagnostika softwaru

Článek připomíná důvody vedoucí k potřebě testovat a diagnostikovat chování softwaru, zejména pro kritické aplikace, a stručně popisuje základní používané členění testů a testovací metody.

Testování a diagnostika softwaru nabývají s rostoucím počtem počítačových aplikací a intenzivní automatizací technických procesů stále většího významu. Velký podíl vyvíjených systémů tvoří zařízení používaná v kritických místech, ať již jde např. o výrobní linky nebo zařízení pro podporu životně důležitých funkcí lidského organismu. Selhání aplikace může v těchto případech způsobit velké materiální škody, popř. újmu na zdraví.

Zároveň neustále rostou složitost i rozsah počítačových programů. Při jejich vývoji již není možné spoléhat na vývojové metody typu pokus-omyl a na ty pracovní postupy, kdy úspěch záleží na individuálním „hrdinství“ a entuziasmu každého pracovníka. Technologie vývoje softwaru směřuje ke zvyšování požadavků na výslednou spolehlivost produktu a na dodržení kvality v průběhu vývoje a testování aplikace. Tyto požadavky a snaha zmenšit možná rizika vedou k růstu podílu testování na celkovém objemu prací při vývoji softwaru. Příkladem je udávaný poměr počtu testovacích pracovníků k počtu vývojářů, který se v současné době u větších projektů pohybuje okolo 1 : 3 až 1 : 4 (společnost Microsoft uvádí poměr 1 : 1).

Testování v procesu vývoje softwaru
Nejjednodušším způsobem testování softwaru je jeho opakované spouštění a zadávání různých vstupních dat s cílem prověřit co největší počet jejich možných kombinací a uživatelských situací. Tento přístup je však při vývoji rozsáhlejších aplikací zcela nedostačující. Pojem testování je třeba rozšířit a chápat spíše jako specifickou skupinu činností vztažených k jednotlivým etapám procesu vývoje softwaru.

Obr. 1.

Standardní proces vývoje softwaru postupuje nejčastěji podle tzv. V-modelu, znázorněného na obr. 1 [1]. Základními aktivitami realizovanými v procesu testování softwaru jsou revize a inspekce požadavků a specifikací, identifikace testovacích požadavů a návrh, provedení a vyhodnocení testů. Stručně je popíšeme.

Revize a inspekce požadavků a specifikací softwaru
Veškerá dokumentace, která popisuje vyvíjený systém, podléhá revizím. Cílem revize primárně je odhalit chyby v návrhu softwaru a doplnit případné nejasnosti. Zároveň je nutné již v počátečních fázích vývoje vnést do návrhu požadavky na budoucí možnost testovat software a rovněž zkontrolovat, zda existující požadavky je možné podrobit testu. Formulace typu např. „hodnota parametru je pravidelně aktualizována“ je příliš vágní a pod pojmem „pravidelná aktualizace“ se může skrývat velké množství možných definic.

Při návrhu je také nutné uvažovat o budoucí automatizaci testování a navrhnout příslušná rozhraní pro testovací nástroje. Přizpůsobení softwaru pro testování je z hlediska vývoje časově náročná práce, se kterou je nutné počítat při plánování celkové doby trvání projektu.

Identifikace testovacích požadavků
Proces identifikace testovacích požadavků spočívá ve výběru všech požadavků, které souvisejí s předmětem testu. Jde především o výběr podmnožin specifikovaných systémových a softwarových požadavků a o definování nových požadavků na základě analýzy dokumentace návrhu.

Návrh testů
Návrh testů zahrnuje specifikaci testovacího zařízení a definici jednotlivých testovacích postupů. Navržené testovací postupy musí ověřit všechny identifikované testovací požadavky.

Provedení testů a regresní testování
Při uskutečňování testů je nutná především pečlivá dokumentace provedení každého jednotlivého kroku každého z postupů tak, aby bylo možné testy v případě potřeby přesně reprodukovat. Regresní testování představuje opakování všech testů, jejichž předmět byl upraven nebo změněn za účelem odstranění chyb detekovaných během předchozího testování. Právě vzhledem k časové náročnosti regresních testů, a to zejména v závěrečných etapách projektu, vyvstává nutnost automatizovat testování softwaru.

Vyhodnocení testů
Důležitou součástí testování je vyhodnocení testů. Testy se vyhodnocují na základě různých měření [2], která se vždy definují během plánovací fáze projektu. Často se využívají kombinace souhrnných a strukturovaných měření (např. podíl chyb na celkovém počtu vykonaných testů a podíl chyb v rámci jednotlivých komponent). Z hlediska zhodnocení úspěšnosti testů je důležité sledovat poměr chyb nalezených během uskutečňování navržených testů a chyb nalezených náhodnými neplánovanými testy.

Strategie testování
Testovací strategie (technika) je systematická metoda použitá k výběru nebo generování testu, který bude zahrnut do skupiny testů. Testovací strategií jsou definována pravidla, podle kterých je možné objektivně posoudit, zda daný test vyhovuje vybrané strategii. Strategii lze také automatizovat. Testovací strategie se v zásadě dělí na:

  • funkční (black-box) testy [3]: návrh testů vychází z definic požadavků na software a popisu jeho funkce; testy na základě této strategie teoreticky mohou být navrženy bez znalosti testovaného objektu, i když v praxi se využívá znalosti návrhu kódu;
  • strukturální (glass-box, white-box) testy [4]: jsou odvozeny přímo ze znalosti struktury testovaného objektu; strukturou je zde třeba rozumět architekturu softwaru a způsob jeho implementace;
  • hybridní testy: kombinace funkčních a strukturálních testů.

Typy testů
Testy softwaru jsou rozděleny do čtyř základních etap (viz levá část V-modelu na obr. 1):

  • Testy komponent, které bývají často zahrnovány do fáze vývoje, protože je uskutečňují přímo vývojoví pracovníci v rámci ladění kódu. Cílem těchto testů je ověřit funkční schopnosti izolovaných modulů programu na základě ověření všech funkcí vstupně-výstupního rozhraní.
  • Integrační testy, určené k ověřování správnosti spolupráce integrovaných modulů na základě dokumentace návrhu. Obvykle vyžadují simulaci činnosti nehotových modulů, popř. vytváření speciálních ovládačů pro ověřování komunikace mezi moduly. Jednotlivé moduly se při těchto testech považují za uzavřené systémy. Z hlediska modulů tedy jde o funkční testy, zatímco z hlediska celého programu jde spíše o testy hybridní.
  • Systémové testy, kterými se ověřuje činnost systému jako celku, tedy včetně hardwaru, se kterým je software distribuován. Program je testován jako tzv. černá skříňka. Typické jsou především zátěžové testy, testy správnosti hospodaření s operační pamětí a funkční testy při různých konfiguracích systému.
  • Kvalifikační testy, zajišťující kompletní ověření všech systémových funkcí garantovaných zákazníkovi. Slouží jako výstupní kontrola výsledného produktu.

Automatizace testů
Proces návrhu a provádění testů softwaru je většinou omezen dobou, která je na testování vyhrazena v rámci projektu. Opakovatelnost testů a preciznost jejich uskutečňování hrají také důležitou roli, ale z hlediska termínů dokončení projektu jsou určující zejména počet a časová náročnost testů. Například pro otestování běžné aplikace pro zdravotnictví je zapotřebí software podrobit dvěma až třem tisícům testů. Průměrná doba trvání jednoho testu při ručním zpracování je v rozsahu řádově minut až desítek minut. Ruční otestování celé aplikace zabere přibližně dva měsíce. Při vývoji aplikace po krocích je nutné testy celé aplikace zopakovat po každém vývojovém kroku, tedy změně kódu. Za těchto podmínek je nutné testování automatizovat.

Automatizací se rozumí použití vhodného testovacího nástroje, který je schopen ovládat testovanou aplikaci tak, jak by to při jejím testování dělal člověk. Testovací nástroj musí umožnit vytvářet testovací aplikace, tedy testy. Nejčastěji se testy píší ve skriptovacím jazyku, podobném např. jazyku Basic, který je navržen pro potřeby testovacího nástroje.

Běžným typem funkčních testů jsou testy uskutečňované pomocí standardních rozhraní testované aplikace, nejčastěji pomocí grafického uživatelského rozhraní. Pro tento typ testů existuje velké množství komerčně dostupných nástrojů, jako je např. ATF (Softbridge), WinRunner (Mercury Interactive), Rational Robot (Rational) aj.

Pro méně standardní rozhraní je nutné vytvořit vlastní testovací nástroj, který musí být vyvíjen s testovanou aplikací. Součástí vývoje aplikace se tak stává také vývoj testovacího nástroje. Mnohdy jde o testovací aplikace velmi propracované, jež musí být navrhovány již v počátečních fázích návrhu testovaného softwaru.

Závěr
V článku jsou zmíněny pouze některé aspekty procesu vývoje softwaru a jeho testování. Toto téma je velmi rozsáhlé a obsahuje zajímavé problémy, jako je automatické generování testovacích případů, automatické mapování aplikace pro přípravu automatických testů, návrh měření pro vyhodnocování testů, analýza kritických míst softwaru z hlediska možnosti výskytu chyb apod. Další informace je možné získat v uvedené literatuře.

Lze říci, že testování softwaru je v současné době věnována stále větší pozornost. Stále více manuální práce při testování je automatizováno. V praxi to znamená, že se zkracuje doba potřebná k vykonání testů, ale proces se prodlužuje o dobu potřebnou pro vývoj a údržbu testovacího prostředí.

Stále větší část procesu testování je převáděna na počátek postupu vývoje softwaru. Jsou vytvářeny funkční nebo symbolické modely, na kterých jsou ověřovány vyvíjené algoritmy a funkční schopnosti systému. Používají se programovací nástroje pro rychlý vývoj prototypů (rapid-prototyping) softwaru, jako jsou jazyky Perl, Python, které umožňují rychle vyvinout testovatelný prototyp.

Hlavním hybatelem v oblasti testovacích aktivit je požadavek na dodržení kvality celého vývojového procesu a nalezení a odstranění všech chyb softwaru, které by mohly mít vážné následky pro uživatele. Zcela bezchybný software však představuje, i s použitím zmíněných testovacích metod, bohužel stále nedostižnou metu.

Literatura:

[1] RAKITIN, S. R: Software Verification and Validation (A Practitioner’s Guide). Artech House Publishers 1997.

[2] IEEE Standard 1061-1992: IEEE Standard for a Software Quality Metrics Methodology, 1993.

[3] BEIZER, B.: Black-Box Testing (Techniques for Functional Testing of Software and Systems). John Wiley & Sons 1995.

[4] KIT, E.: Software Testing in the Real World. Addison-Wesley 1995.

[5] RUMBAUGH, J. – BLAHA, M. – PREMERLANI, W. – EDDY, F. – LORENSEN, W.: Object-Oriented Modeling and Design. Prentice Hall 1991.