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

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]

Kontinuální testování (Continuous testing)

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]

Testování grafického uživatelského rozhraní (GUI)

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.

Testování na různých úrovních
Pyramida automatizace testování navržená Mikeem Cohnem[13]

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]

Úrovně
  • 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 přístupu v automatizaci

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í

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]

Model rozhraní pro automatizovaného testování

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í

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ář

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

Definování hranic mezi automatizačním frameworkem a testovacím nástrojem

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í

Co testovat

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 )

Související články

Reference

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

  1. [s.l.]: [s.n.] ISBN 978-0-470-04212-0.
  2. [s.l.]: [s.n.] ISBN 978-0-7381-5746-7. DOI 10.1109/IEEESTD.2008.4578383.
  3. Dostupné online.
  4. Testing APIs protects applications and reputations, by Amy Reichert, SearchSoftwareQuality March 2015
  5. All About API Testing: An Interview with Jonathan Cooper, by Cameron Philipp-Edmonds, Stickyminds August 19, 2014
  6. Produce Better Software by Using a Layered Testing Strategy, by Sean Kenefick, Gartner January 7, 2014
  7. Part of the Pipeline: Why Continuous Testing Is Essential, by Adam Auerbach, TechWell Insights August 2015
  8. The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola, by Cameron Philipp-Edmonds, Stickyminds December 2015
  9. DevOps: Are You Pushing Bugs to Clients Faster, by Wayne Ariola and Cynthia Dunlop, PNSQC October 2015
  10. Headless Testing with Browsers; https://docs.travis-ci.com/user/gui-and-headless-browsers/
  11. Headless Testing with PhantomJS;http://phantomjs.org/headless-testing.html
  12. Automated User Interface Testing; https://www.devbridge.com/articles/automated-user-interface-testing/
  13. [s.l.]: [s.n.] ISBN 978-0-321-57936-2.
  14. The Practical Test Pyramid, by Ham Vocke
  15. Dostupné online.
  16. Archivovaná kopie [online]. [cit. 2021-01-10]. Dostupné v archivu.

Externí odkazy
This article is issued from Wikipedia. The text is licensed under Creative Commons - Attribution - Sharealike. Additional terms may apply for the media files.