Automatizace testování

V testování softwaru je automatizace testů možná za použití softwaru k řízení a provádění testů a následné porovnání získaných výsledků s předpokládanými výsledky.^[1] Automatizace testů může automatizovat některé opakované, ale nezbytné úkoly ve formalizovaném procesu testování, který se již používá, nebo provést další testování, které by bylo obtížné provést manuálně. Automatizace testů je zásadní pro průběžné doručování (continuous delivery) a průběžné testování (continuous testing).

Existuje mnoho přístupů k automatizaci testů, níže jsou však vypsány nejvíce užívané přístupy:

• Testování grafického uživatelského rozhraní - Testovací rozhraní, které generuje události uživatelského rozhraní, jako jsou stisknutí kláves a kliknutí myší. Následně sleduje změny, které vedou k uživatelskému rozhraní, aby ověřil, že je pozorované chování programu správné.
• Testování na základě API - Testovací rozhraní, které využívá programovací rozhraní k aplikaci, aby se ověřilo testované chování. Testování řízené API obvykle úplně obchází uživatelské rozhraní aplikace. Může se také jednat o testování veřejných rozhraní tříd, modulů či knihoven, které jsou testovány pomocí různých vstupních argumentů k ověření správnosti navrácených výsledků.

Jedním ze způsobů, jak automaticky generovat testovací případy, je testování založené na modelu (model-based testing) prostřednictvím modelu systému pro generování testovacích případů, ale stále pokračuje výzkum alternativních metodik k automatickému generování testovacích případů. V některých případech umožňuje přístup založený na modelu netechnickým uživatelům vytvářet automatizované případy obchodních testů v prosté angličtině, takže není nutná znalost programování jakéhokoli druhu pro to, aby bylo možné je konfigurovat pro více operačních systémů, prohlížečů a chytrá zařízení.^[2]

Co automatizovat, kdy automatizovat, nebo dokonce, zda opravdu je potřeba automatizace, jsou zásadní rozhodnutí, která musí testovací (nebo vývojový) tým učinit.^[3] Přehled literatury 52 odborníků a 26 akademických zdrojů zjistil, že při rozhodování o potřebě automatizace testů je třeba vzít v úvahu pět hlavních faktorů: 1) Testovaný systém (SUT), 2) typy a počet testů, 3) testovací nástroj, 4) lidská a organizační témata a 5) průřezové faktory. Nejčastěji identifikované jednotlivé faktory ve studii byly: potřeba regresního testování, ekonomické faktory a vyspělost SUT.

Rostoucím trendem ve vývoji softwaru je používání frameworků pro testování jednotek, jako jsou frameworky xUnit (například JUnit a NUnit ), které umožňují provádění testů jednotek k ověření, zda jednotlivé části kódu fungují podle očekávání a za různých okolností. Testovací případy popisují testy, které je třeba spustit v programu, aby se ověřilo, že program běží dle očekávání.

Automatizace testů, většinou pomocí testování jednotek, je klíčovým prvkem extrémního programování a agilního vývoje softwaru, kde je označováno jako programování řízené testy (TDD). Testy jednotek lze psát k definování funkčnosti ještě před psaním kódu. Tyto jednotkové testy se však postupně vyvíjejí a jsou rozšiřovány současně s postupem kódování programu, nebo objevení chyb či problémů v programu, a nebo je kód je podroben refaktoringu. Pouze za předpokladu, že projdou všechny testy všech požadovaných funkcí, je kód považován za kompletní. Zastánci tvrdí, že toto řešení produkuje software, který je spolehlivější a méně nákladný než kód testovaný manuálním průzkumem kódu. Spolehlivějším považován tak proto, že pokrytí kódu je lepší, a protože je spuštěno neustále během vývoje, nikoli jednou na konci vodopádového vývojového cyklu. Vývojář zjistí vady ihned po provedení změny, kdy je její oprava nejméně nákladná. Nakonec i refaktorování kódu je bezpečnější, pokud se používá testování jednotky. Také transformace kódu do jednodušší formy s menší duplikací kódu, ale ekvivalentním chováním, je mnohem méně pravděpodobné, že způsobí nové vady, když je refaktorovaný kód pokryt jednotkovými testy.

Některé úlohy testování softwaru (například rozsáhlé regresní testování rozhraní na nízkých úrovních) mohou být namáhavé a časově náročné pro provádění manuálního testování. Manuální přístup nemusí být vždy efektivní při hledání určitých tříd vad. Automatizace testů tím nabízí možnost provádět tyto typy testování efektivně.

Jakmile jsou vyvinuty automatizované testy, mohou být rychle a opakovaně spouštěny. Mnohokrát to může být nákladově efektivní metoda pro regresní testování softwarových produktů, které jsou zamýšleny k dlouhé životnosti. Dokonce i drobné opravy mohou způsobit přerušení stávajících funkcí, které fungovaly dříve, a proto je dobrá automatizace, jež se postará o dlouhou životnost programu.

Zatímco společnosti zabývající se vývojem softwaru oceňují opětovnou použitelnost automatizovaných testů, lze tuto vlastnost považovat za nevýhodu. Jelikož vede k takzvanému "paradoxu pesticidů" („Pesticide Paradox“), kde opakovaně prováděné skripty přestanou detekovat chyby, které jdou nad rámec jejich rozhraní V takových případech může být manuální testování lepší investicí. Tato nejednoznačnost opět vede k závěru, že rozhodnutí o automatizaci testů by mělo být učiněno individuálně s ohledem na požadavky a zvláštnosti projektu.

Nástroje pro automatizaci testování mohou být drahé a obvykle se používají v kombinaci s manuálním testováním. Automatizaci testů lze z dlouhodobého hlediska učinit nákladově efektivní, a to zejména při opakovaném použití v regresním testování. Dobrým kandidátem na automatizaci testů je testovací případ pro běžnou funkci aplikace, protože je nutné test provést (regresní testování) při každém vylepšení aplikace. Automatizace testů snižuje úsilí spojené s manuálním testováním. K vývoji a údržbě automatických kontrol a kontrole výsledků testů je i tak zapotřebí manuálního úsilí.

Při automatickém testování musí testovací technik nebo osoba zajišťující kvalitu softwaru být schopna kódovat, protože testovací případy jsou psány ve formě zdrojového kódu, který při spuštění produkuje výstup na základě určitého tvrzení, která jsou jeho součástí. Některé nástroje pro automatizaci testů umožňují vytváření testů pomocí klíčových slov namísto kódování, což nevyžaduje znalost programování.

Testování API je softwarovými testery také široce používáno, jelikož jim umožňuje ověřovat požadavky nezávisle na jejich implementaci v GUI, obvykle se testují již během vývoje a tím zajišťují, aby samotný test dodržoval zásady čistého kódu, zejména princip jedné odpovědnosti. Zahrnuje přímé testování API jako součást testování integrace, aby se zjistilo, zda splňuje stanovená očekávání týkající se funkčnosti, spolehlivosti, výkonu a zabezpečení.^[4] Protože samotné API postrádá GUI rozhraní, testování API se tak provádí pouze ve vrstvě zpráv.^[5] Testování API je považováno za kritické, pokud API slouží jako primární rozhraní k logice aplikace.^[6]

Průběžné testování (Continuous testing) je proces provádění automatizovaných testů jako součást dodávky softwaru, aby se zajistila okamžitá zpětná vazba o obchodních rizicích spojených s kandidátem na vydání softwaru.^[7][8] V případě průběžného testování se rozsah testování rozšiřuje od ověřování požadavků zdola nahoru nebo uživatelských příběhů (user stories) až po hodnocení systémových požadavků, jež zastřešují související obchodní cíle.^[9]

Mnoho nástrojů pro automatizaci testů poskytují funkci záznamu a přehrávání, které uživatelům umožňuje interaktivně zaznamenávat samotné akce uživatelů a opakovaně je přehrávat zpět, přičemž porovnávají skutečné výsledky s očekávanými. Výhodou tohoto přístupu je, že vyžaduje malou až žádnou znalost s vývojem softwaru. Tento přístup lze také aplikovat na jakoukoli aplikaci, která má nějaké grafické uživatelské rozhraní. Avšak spolehnutí se na tyto funkce může představovat následné problémy se spolehlivostí a udržovatelností nahraných testů. Jakákoli změna označení tlačítka nebo jeho přesunutí do jiné části okna může vyžadovat opětovné zaznamenání testu. Záznam a přehrávání také často přidává irelevantní aktivity, které do samotného testovacího případu nepatří nebo některé aktivity nesprávně zaznamená. 

Varianta tohoto typu nástroje je například vhodná pro testování webových stránek. Kde je „rozhraním“ webová stránka. Takový framework však využívá zcela odlišné techniky, protože místo událostí operačního systému vykresluje HTML a poslouchá DOM události. Pro tento účel se obvykle používají prohlížeče bez grafického uživatelského rozhraní nebo řešení založená na Selenium Web Driver.^[10][11][12]

Další variantou tohoto typu nástroje pro automatizaci testů je testování mobilních aplikací. Jedná se o velmi užitečnou variantu vzhledem k počtu různých velikostí obrazovek, rozlišení obrazovek a operačních systémů používaných v mobilních telefonech. Pro tuto variantu se framework používá k vytvoření instance akcí na mobilním zařízení a následnému shromáždění výsledků provedených akcí.

Další variantou je automatizace testů bez skriptů, která nepoužívá záznam a přehrávání, ale místo toho vytváří model aplikace a poté umožňuje testerovi vytvářet testovací případy jednoduchým vložením testových parametrů a podmínek, což nevyžaduje žádné skriptovací dovednosti.

Strategií rozhodování o potřebném množství testů k automatizaci je využívána pyramida automatizace testů. Tato strategie navrhuje napsat tři typy testů s různou granularitou. Čím vyšší úroveň, tím menší je počet potřebných testů k zápisu.^[13]

• Jako pevný základ poskytuje testování jednotek (Unit) robustnost softwarových produktů. Testování jednotlivých částí kódu usnadňuje psaní a spuštění testů.
• Vrstva služeb (Service) odkazuje na testování služeb aplikace odděleně od jejího uživatelského rozhraní, tyto služby jsou cokoli, co aplikace dělá v reakci na nějaký vstup nebo sadu vstupů.
• Na nejvyšší úrovni máme testování uživatelského rozhraní (UI), které má méně testů kvůli mnoha různým atributům, díky nimž je běh složitější. Například křehkost testů, kde malá změna v uživatelském rozhraní může mnoho testů rozbít a tím vyvolá potřebnou údržbu těchto testů.^[13][14]

Framework automatizace testů je integrovaný systém, který určuje pravidla automatizace konkrétního produktu. Tento systém integruje knihovny funkcí, zdroje testovacích dat, detaily objektů a různé opakovaně použitelné moduly. Tyto komponenty fungují jako malé stavební bloky, které je nejprve potřeba sestavit, aby představovaly daný obchodní proces. Framework poskytuje základ automatizace testů, a tak zjednodušuje úsilí automatizace.

Hlavní výhodou frameworku předpokladů, konceptů a nástrojů, jež poskytují podporu pro automatické testování softwaru, jsou nízké náklady na jejich údržbu. Pokud tedy dojde ke změně libovolného testovacího případu, je potřeba aktualizovat pouze soubor změněného testovacího případu, avšak skript ovladače a spouštěcí skript zůstanou stejné. V ideálním případě není tedy nutné skripty aktualizovat pro případné změny v aplikaci.

Výběr správné techniky frameworku / skriptování pomáhá udržovat nižší náklady. Náklady spojené s testovacím skriptováním jsou způsobeny hlavně úsilím o vývoj a údržbu. Přístup skriptování, který byl použit během automatizace testu má tak vliv na náklady.

Obecně se používají různé techniky frameworku / skriptování:

1. Lineární (procedurální kód, případně generovaný nástroji, jako jsou ty, které používají záznam a přehrávání)
2. Strukturované (používá řídicí struktury - typicky „if-else“, „switch“, „for“, „while“ podmínky / příkazy)
3. Na základě dat (data jsou uchovávány mimo testy v databázi, tabulce nebo jiném mechanismu)
4. Na základě klíčových slov
5. Hybridní (používají se dva nebo více vzorů uvedených výše)
6. Agilní automatizační framework

Testovací framework je zodpovědný za:^[15]

1. definování formátu, ve kterém lze vyjádřit daná očekávání
2. vytvoření mechanismu pro připojení či řízení testované aplikace
3. provádění testů
4. hlášení výsledků

Rozhraní pro automatizaci testování jsou platformy, které poskytují jeden ucelený pracovní prostor pro začlenění více testovacích nástrojů a frameworků pro systémové/integrační testování aplikace. Cílem rozhraní pro automatizované testování je zjednodušení procesu mapování testů na obchodní kritéria, aniž by tomu procesu bránilo nějaké kódování. Očekává se tedy, že rozhraní pro automatizované testování má za cíl zlepšit účinnost a flexibilitu údržby testovacích skriptů.^[16]

Rozhraní pro automatizovaného testování se skládá z následujících základních modulů:

• Engine rozhraní
• Rozhraní prostředí
• Objektový repozitář

Engine rozhraní jsou postaveny na vrcholu rozhraní prostředí. Engine rozhraní se skládá z parseru a testovacího běžce. Parser je přítomen k analýze souborů objektů, jež pocházejí z objektového repozitáře, do skriptovacího jazyka specifického pro daný test. Testovací běžec provádí testovací skripty pomocí testovacího svazku.^[16]

Objektový repozitář je souborem dat uživatelského rozhraní/objektu aplikace zaznamenaných testovacím nástrojem při zkoumání testované aplikace.^[16]

Nástroje jsou speciálně navrženy tak, aby cílily na určité testovací prostředí, jako jsou například Windows a nástroje pro automatizaci webu atd. Nástroje slouží jako hnací agent pro automatizační proces. Automatizační framework však není nástrojem k provádění konkrétního úkolu, ale spíše infrastrukturou, jež poskytuje řešení, kde různé nástroje mohou vykonávat svou práci jednotným způsobem. To poskytuje společnou platformu pro automatizačního inženýra.

Existují různé typy frameworků. Jsou kategorizovány na základě automatizační komponenty, kterou využívají. Jedná se o:

1. Testování na základě dat
2. Testování založené na modularitě
3. Testování na základě klíčových slov
4. Hybridní testování
5. Testování na základě modelu
6. Testování na základě kódu
7. Vývoj založený na chování

Testovací nástroje mohou pomoci automatizovat úkoly, jako je instalace produktu, tvorba testovacích dat, interakce s grafickým uživatelským rozhraním, detekce problémů, protokolování defektů atd., aniž by bylo nutné automatizovat testy principem konec-konec (end-to-end) způsobem.

Když uvažujeme o automatizaci testů, je zapotřebí neustálé uspokojování populárních požadavků:

• Nezávislost na platformě a OS
• Schopnost řídit data (vstupní data, výstupní data, metadata )
• Přizpůsobení Reporting (DB Data Base Access, Crystal Reports )
• Snadné ladění a protokolování
• Přátelské pro verzování - minimální binární soubory
• Rozšiřitelný & Přizpůsobitelný (Otevřená rozhraní API k integraci s dalšími nástroji)
• Běžný ovladač (Například ve vývojovém ekosystému Java to znamená Ant nebo Maven a populární IDE ). To umožňuje integraci testů s pracovními postupy vývojářů.
• Podporujte bezobslužné testovací běhy pro integraci s procesy sestavení a dávkovými běhy. Servery pro nepřetržitou integraci to vyžadují.
• E-mailová oznámení, jako jsou okamžité zprávy
• Podpora prostředí distribuovaného spuštění (distribuované testovací zařízení )
• Podpora distribuovaných aplikací (distribuovaný SUT )

• Testování
• Fuzzing
• Smoke test
• Testování softwaru
• Regresní testování
• Test jednotky

V tomto článku byl použit překlad textu z článku Test automation na anglické Wikipedii.

• Praktické zkušenosti s automatizovaným testováním
• Automatizace testů: přináší obchodní hodnotu
• Test Automation Snake Oil od Jamese Bacha
• Kdy by měl být test automatizován? Brian Marick
• Pokyny pro rámec Automation Test
• Pokročilá automatizace testů
• Faktory úspěchu pro testování na Archivováno 18. 4. 2015 na Wayback Machine. základě klíčových slov Archivováno 18. 4. 2015 na Wayback Machine. od Hanse Buwaldy
• Automatizace, která se učí: Váš počítač bude pracovat pro vás Jeremy Carey-Dressler
• Zdroje a osvědčené postupy pro automatizaci testování Archivováno 22. 3. 2018 na Wayback Machine. Joe Colantonio