\nn{Úvod}
Při vývoji softwarových aplikací se v dnešní době stále více dbá na testování produktu před vydáním aplikace k zákazníkovi. I když testování vyžaduje další finanční a časové prostředky ve vývoji, v průběhu let se ověřilo, že kontrola produktu vede k lepší jeho kvalitě a k větší spokojenosti klienta. Testování bylo nějakou formou vždy součástí vývoje aplikace. Začínalo se jednoduchým laděním programu při implementaci zdrojového kódu. Později testování bylo považováno jako individuální aktivita, která byla zařazena do vývojového cyklu aplikace. Verifikace správného chování aplikace spíše probíhala manuálně a nebyl takový tlak na automatizaci. Až později s příchodem různých podpůrných nástrojů pro automatizaci, začalo být vnímáno manuální testování jako značně neefektivní a výrazně časově náročné. Přestože k vytváření a k údržbě automatických testů je vyžadována lepší znalost a dovednost v programování, v konečném důsledku automatizace šetří čas a další prostředky. Automatické testy hrají důležitou roli v moderních přístupech při vývoji aplikace. Cílem je dodat zákazníkovi co nejrychleji novou verzi produktu v co nejlepší kvalitě. Tento způsob vývoje je označován jako kontinuální integrace a nasazení, kde automatické testy se používají pro co nejrychlejší kontrolu nové verze aplikace a získání zpětné vazby o kvalitě produktu.

Cílem této diplomové práce je vytvořit testovací aplikaci s automatickými testy, které budou kontinuálně testovat provozované služby poskytující elektronické zdroje. Aplikace bude vytvořena ve spolupráci s knihovnou Univerzity Tomáše Bati ve Zlíně, která poskytuje přístup k elektronickým zdrojům na portálu E-zdroje UTB. Automatické testy budou kontinuálně kontrolovat přihlašovací proces do jednotlivých elektronických zdrojů. Výsledkem bude zpětná vazba o úspěšnosti přihlášení a hlášení případných problému s nedostupností služeb. To bude umožňovat správcům portálu e-zdroje rychle reagovat na případně problémy a také získají aktuální přehled o přístupnosti klíčových zdrojů. 

Testovací sada automatů bude systémově testovat ve webovém prohlížeči proces přihlašování. Jedním z typů přihlášení do služby je přes technologii Shibboleth, která je založena na webovém workflow a přesměrovávání uživatele mezi stránkami. Aby bylo docíleno přesného procesu přihlašování v prohlížeči, je zapotřebí vytvořit automaty typu End-to-End. Automaty budou tedy testovat přihlášení v grafickém uživatelském rozhraní webového prohlížeče. Testovací sada s automaty bude pravidelně spouštěna a výsledky testů budou posílány elektronicky na email správce knihovny.

% ============================================================================ %
\cast{Teoretická část}
\n{1}{Testování}
Softwarové testování je proces vyhodnocování a ověřování, že softwarový produkt nebo aplikace funguje podle očekávání. Umožňuje předcházet chybám a problémům v aplikaci zákazníka. Různou sadou testovacích technik jsme schopni docílit správného fungování aplikace. Hlavní záměr testování je objevovat chyby v softwarovém produktu za pomocí testovacích scénářů, aby bylo možné je včas opravit. Díky verifikaci můžeme odhalit velké množství chyb, ale není možné najít všechny problémy v aplikaci. Produkt není možné otestovat za všech možných podmínek. Ovšem dokážeme zaručit, že aplikace funguje za daných podmínek, které jsme schopni nasimulovat \cite{WWWjavatpoint}. 

\n{2}{Důvody testování}
Každý zákazník používající software očekává, že aplikace bude fungovat bez chyb a podle dokumentace. Pokud zákazník v aplikaci nalézá chyby, nesprávné chování ho blokuje ve své práci a tím přichází o čas. To vede k frustraci a může to skončit nepoužíváním naší aplikace a preferování produktu od konkurence. Některé chyby v softwaru můžou způsobit vážné škody jak na majetku, tak i na osobě \cite{ibm}. 

Při pohledu do historie můžeme zjistit několik incidentů spojené s chybami a problémy v softwarovém produktu. Chyby způsobily nejen škody na majetku, ale mnohdy stály také i životy lidí. Testováním máme větší šanci tyto problémy najít a včas opravit. V roce 1994 26. dubna havarovalo letadlo společnosti Airbus A300 čínských aerolinií, při kterém zahynulo 264 lidí. Chyba byla jak na straně pilotů, tak ale i v palubním počítači. Letadlo se blížilo k letišti Nagoya a byl zapnut autopilot. Piloti se snažili letadlo ovládat manuálně v domnění, že autopilot se vypne. Jak se snažili tlačit letadlo dolů k přistání, autopilot kompenzoval pohyb dolů a letadlo podle palubního počítače směřovalo směrem vzhůru. V kokpitu nebyla žádná indikace použití autopilota a čím víc piloti tlačili letadlo dolů, tím více počítač směřoval letadlo nahoru. To vedlo k pádu letadla \cite{crash}. Jednoduchým testovacím scénářem se dalo zabránit této tragédii. Pokud je zapnutý autopilot a pilot chce provést manuální vstup, je potřeba autopilota vypnout.

Jedna z nejznámějších chyb z vesmírného prostředí stála společnost NASA několik milionů amerických dolarů. Problém byl v nastavení vesmírné rakety, kdy softwarový inženýři se spletli v při čtení jednotek síly. V mezinárodní soustavě fyzikálních veličin je jednotka pro sílu Newton. Kdežto v anglické soustavě veličin je jednotka pro sílu Libra (lbf). To vedlo k nepatrným chybným výpočtům kurzu kosmické lodi, které se postupem času zvětšovaly \cite{wp}. 

Samotné testování ve vývojovém cyklu aplikace stojí čas, ale taky značnou část finančních prostředků. Pokud jsou však nastaveny správné testovací procesy a pravidla, testování dokáže ušetřit ve vývoji spoustu času a peněz. Testování, před vydáním verze na trh, dokáže objevit mnoho chyb a problémů. Vývojové týmy mohou včas tyto chyby a problémy opravit ještě fázi vývoje softwaru. Zákazník dostane verzi aplikace, ve které by měly být vyřešeny problémy týkající se designu, bezpečnosti, škálovatelnosti a celkově problémy spojené s obecným fungováním produktu. Testování zlepšuje spolehlivost a kvalitu produktu. Systém splňující očekávání zákazníka vede k vyšší oblíbenosti a celkově lepšího použití vyvíjené aplikace \cite{ibm}. 

\n{2}{Typy testování}
Softwarové testování je obecně klasifikováno do třech kategorií. První kategorie jsou funkcionální testy, kde se zahrnuje testování funkcionality v aplikaci. Do druhé kategorie ne-funkcionálních testů patří testování výkonu, bezpečnosti, použití a tak dále. Jde o testování, které se zaměřuji spíše na celkové použití aplikace než na její funkce. Doplňková třetí kategorie testů je spíše pro údržbu, kde řadíme regresní testování. Regresní testování je o spuštění opět funkcionálních a ne-funkcionálních testů pro verifikaci aplikace před vydáním nové verze \cite{types}. Grafické rozdělení testů i s příklady můžeme vidět na obrázku \ref{fig:testingTypes}.
\obr{Rozdělení testování \cite{imagetypes}}{fig:testingTypes}{0.8}{graphics/testingTypes.png} 

\n{3}{Funkcionální testování}
Funkcionální testování je typ testování softwaru, který ověřuje softwarový systém podle funkčních požadavků anebo specifikací. Účelem funkčních testů je otestovat každou funkci softwarové aplikace poskytnutím vstupu a verifikace výstupu podle funkčních požadavků. Testování lze provádět ručně anebo pomocí automatických testů. Jako příklad zde můžeme zařadit unit testování, integrační testování, systémové testování, Blackbox testování a další \cite{functest}. Jednotlivé typy testování budou uvedeny v kapitole \ref{n:tests}. 

\n{3}{Ne-funkcionální testování}
Nefunkcionální testování je testování nefunkčních aspektů aplikace, jako je výkon, spolehlivost, použitelnost, bezpečnost a další. Z pohledu životního cyklu vývoje se nejdříve provádí funkcionální testování a až poté nefunkcionální testování. Funkcionální testování zajišťuje správnou funkčnost aplikace. Nefunkcionálním testováním jsme schopni vylepšit kvalitu, spolehlivost a rychlost aplikace. Zaměřuje se spíše na vylepšování uživatelského zážitku, aby například program pracoval rychle. Nefunkcionální testy je obtížné a pracné provádět manuálně, testování probíhá pomocí různých nástrojů (JMeter, Loadrunner, vPerformer). Můžeme zde zařadit testování ohledně výkonu, bezpečnosti, zátěžové testy, testy kompatibility, testování odolnosti a další \cite{functest}.

\n{2}{Evoluce testování}
Programování softwaru se v průběhu dekád vyvíjelo a v důsledku toho prošlo řadou změn i testování, které je nedílnou součástí vývoje softwaru.
Vše začalo s programováním a následným laděním programu. Hledání chyb ve fázi ladění bylo považováno za formu testování. V roce 1957 testování dostalo konkrétní označení pro samostatnou aktivitu, která už byla oddělena od fáze ladění v programování. Do pozdějších 70. let testování představovalo aktivitu, která měla zaručit funkčnost softwaru podle specifických požadavků. Až poté byla aktivita rozšířena o hledání chyb v aplikaci v průběhu vývoje. V 80. letech bylo testování už považováno za proces k docílení lepší kvality aplikace a o pár let později byla fáze testování zařazena do vývojového procesu produktu \cite{evoluce}.

\n{2}{Vývojový proces}{\label{n:sdlc}}
Proces vývoje softwaru je rozdělení vývoje produktu na jednotlivé fáze, které jsou sekvenčně vykonávány. Grafické znázornění s jednotlivými fázemi je zobrazeno na obrázku \ref{fig:sdlc}. V první fázi vývoje je potřeba získat požadavky na vyvíjený software a provést jejich analýzu. Zahrnujeme zde i plánování, jestli dané požadavky jsme schopni splnit v požadovaný čas. Jakmile je první fáze splněna, dostaneme se do druhé fáze životního cyklu. Ta zahrnuje vytváření prototypů a designování nově vznikající funkcionality. Grafici a UX\footnote{UX je označení pro skupinu lidí, kteří se snaží navrhnout takové uživatelské rozhraní, které bude pro uživatele jednoduché a intuitivní a poskytne příjemný uživatelský zážitek \cite{ux}. } experti podle požadavků navrhnou chování aplikace a vytvoří adekvátní uživatelské rozhraní. Dokončením druhé fáze životní cyklus pokračuje do fáze vývoje. Je to proces, kdy vývojové týmy začnou pracovat na implementaci zadaných požadavků. Programují aplikaci pomocí zdrojového kódu tak, jak bylo navrženo v předchozích fázích \cite{sdlc}.

Další fází je část testovací, ke které dochází po naprogramování zadaných požadavků vývojovými týmy. Týmy zajišťující kvalitu ověřují, jestli vytvořená aplikace splňuje zadané požadavky. Verifikují funkčnost a stabilitu produktu. Pomocí manuálního a automatického testování nalézají chyby a problémy, které se snaží vývojové týmy opravit ještě před dodáním softwaru k zákazníkovi. Jakmile týmy zajišťující kvalitu ověří, že vyvíjená funkcionalita funguje správně podle zadaných požadavků, můžeme přejít do další části životního cyklu aplikace. Nejdůležitější částí při vývoji je nasazení nové funkcionality do produkčního prostředí zákazníka. Uživatelé mají možnost vyzkoušet si vytvořenou aplikaci v praxi a poskytnout zpětnou vazby na její fungování. Poslední fází při vývoji je údržba produktu a případné vydání nové verze aplikace. Poslední část vývoje neznamená, že proces životního cyklu je ukončen. Uživatel může změnit své požadavky na fungování softwaru, nalézt chyby a problémy. Vývojové týmy by měly být schopni reagovat na dané změny a tím se životní cyklus opět přesouvá do první fáze \cite{sdlc}. 

V praxi existuje mnoho konkrétních, modelů jak přistupovat k vývoji softwaru. Mezi ty nejznámější můžeme zařadit vodopádový model, inkrementální, prototypový a spirálový model. Modely se liší fázemi, mají různá pravidla pro ukončení a zahájení nové fáze. Některé kladou důraz na častější komunikaci se zákazníkem, jiné zpočátku vytvoří pouze prototyp, který v průběhu cyklů neustále vylepšují. Ovšem všechny modely mají jeden konkrétní cíl, a to vytvořit kvalitní a spolehlivý produkt. 

\obr{Životní cyklus vývoje aplikace \cite{sdlc}}{fig:sdlc}{1}{graphics/sdlc.png}

\newpage
\n{3}{Vodopádový model a testování}
Vodopádový model je jednou z nejstarších a nejtradičnějších metodologií vývoje softwaru. Vodopádový přístup se také nazývá lineární sekvenční model nebo klasický model životního cyklu. Fáze v modelu jsou stejné, jako v teoretickém modelu popsaném v kapitole \ref{n:sdlc}. Hlavní myšlenka modelu je sekvenční vykonávání fází v procesu vývoje. Abychom mohli postoupit ve vývoji z jedné fáze do následující, všechny předchozí fáze musí být kompletně splněny \cite{sdlc}. Grafické znázornění modelu můžeme vidět na obrázku \ref{fig:waterfall}.
\obr{Vodopádový model \cite{imagewaterfall}}{fig:waterfall}{0.5}{graphics/waterfall.png}

Vývoj a testování ve vodopádovém modelu jsou oddělené aktivity. Jakmile je software z pohledu vývojáře hotový, takový software je předán testovacím týmům k verifikaci. Nevýhoda modelu spočívá v tom, že testeři nejsou aktivně zapojeni při sběru a analýze požadavků. Nemají informace o tom, jak zákazník bude software používat a chybí nadhled nad danou funkcionalitou. Testovací scénáře a plány tvoří na základě informací získaných z dokumentace a od vývojářů, kteří implementovali danou funkcionalitu. To vedlo k určitému omezení a testování nebylo komplexní \cite{sdlc}.

\n{3}{Agilní vývoj a testování} \label{n:agile}
Agilní přístup je jeden z nejpopulárnějších metodik vývoje software. Hlavní výhoda agilního vývoje je vysoká přizpůsobitelnost okolním požadavkům. Vývoj je flexibilní, dynamický a iterativní, což vede k lepší kvalitě produktu pro zákazníka. Vývoj aplikace je rozdělen na jeden nebo více sprintů. Sprint neboli iterace je označení pro časové období, které může většinou trvat od jednoho do čtyrech týdnů. Na konci každého sprintu by měla být dodána otestovaná a funkční verze aplikace \cite{sdlc}. Sprint pokrývá všechny fáze životního cyklu, které můžeme vidět na obrázku \ref{fig:agile}. Agilní vývoj podporuje i kontinuální integraci, nasazení a testování, o kterých bude více pojednáno v kapitole \ref{n:ci}.
\obr{Cyklus agilního vývoje \cite{imageagile}}{fig:agile}{0.5}{graphics/agile2.png}

Sprint začíná plánováním, ve kterém vývojové týmy vyberou z backlogu úkoly, které jsou schopni dodat v daném sprintu. Backlog je seznam úkolů, které bychom měli splnit v dané verzi aplikace. Úkoly většinou zadává produktový manažer. V backlogu jsou úkoly seřazeny podle priority a vývojové týmy vybírají do aktuálního sprintu nejprioritnější požadavky.
Po vybrání požadavků do sprintu začnou designéři a UX experti pracovat na grafickém návrhu. Pokud je to možné, zpracují úkoly do vizuální podoby a předají návrhy vývojovému týmu. Vývojové týmy na základě akceptačních kriterií k danému úkolu implementují řešení pomocí zdrojového kódu. Musí brát i v potaz grafický návrh, jak by měli jednotlivé prvky požadavku vypadat v uživatelském rozhraní aplikace \cite{sdlc}.

Testování v agilním přístupu probíhá častěji a zpravidla hned na začátku vývoje. Je to významný rozdíl oproti vodopádovému modelu, kde testeři musí čekat na kompletní řešení od vývojářů. Vývojáři a testeři pracují společně na daném úkolu a komunikace je nezbytnou součásti spolupráce. Verifikace funkcionality podle akceptačních kriterií probíhá v průběhu vývoje. Podle agilní metodologie nepíší testy pouze testeři. Vývojáři používají techniku při vývoji Test-Driven Development (TDD), což má za následek kontinuální testování implementovaného zdrojového kódu \cite{sdlc}. Technikou TDD se více zabývá kapitola \ref{n:tdd}.

Jakmile je funkcionalita otestovaná, další fázi je nasazení nové verze aplikace do produkčního prostředí. Zákazník je už schopen pracovat s novou funkcionalitou a poskytovat zpětnou vazbu. Vývojové týmy monitorují běh aplikace na produkčním prostředí a jsou stále k dispozici, kdyby se zákazník setkal s chybou nebo jiným problémem \cite{sdlc}. 

Vydáním nové verze se dostáváme na konec sprintu. Zákazník na základě zkušenosti s naší aplikací může dostávat nové nápady s vylepšením produktu. Projektový manažeři by měli zaznamenávat jakoukoliv zpětnou vazbu od zákazníka a vytvářet nové požadavky na vývojové týmy. Tím se dostáváme opět k prvním fázi agilního životní cyklu a tím je plánování \cite{sdlc}. 

\n{2}{Kontinuální integrace, nasazení a testování}{\label{n:ci}}
Kontinuální integrace (CI) a kontinuální nasazení (CD) také známe pod zkratkou CI/CD. CI/CD je označení pro sadu procesů a pravidel, které jsou využívány pro spolehlivější a kvalitnější produkci softwarových aplikací. Je to také osvědčený postup, který se používá při agilním vývoji. Spojuje vývojové týmy zodpovědné za implementaci zdrojových kódu a týmy, které provádí nasazeních nových verzí aplikace na produkční prostředí zákazníka \cite{cicd}.

\n{3}{Kontinuální integrace}
Kontinuální integrace je způsob, jakým se dá zajistit sloučení veškerých změn v projektu od jednotlivých vývojových týmu do jedné verze aplikace. Je to sada praktik a procesů, které podporují vývojáře k častějšímu dodávání malých implementací kódu do repozitáře\footnote{Repozitář je označení pro kontejner, kde ukládáme softwarový kód vyvíjené aplikace.} verzovacího systému. To vede k lepší spolupráci mezi vývojáři a ke zlepšení kvalitě kódu. V konečném důsledku i ke spolehlivější a kvalitnější aplikaci. Ve většině moderních aplikací je vývoj kódu podpořen pomocí různých platforem a nástrojů. Jako příklad můžeme uvést třeba verzovací nástroje Git nebo Team Foundation Version Control. CI takové nástroje sjednocuje a pomáhá ve verifikaci změn ve zdrojovém kódu. Pomocí automatizace a kontinuální integrace lze automaticky kompilovat kód, vytvářet balíčky a testovat kontinuálně aplikaci \cite{cicd}.

\n{3}{Kontinuální nasazení}
Kontinuální nasazení (CD) navazuje na kontinuální integraci. Je to zautomatizovaný proces, kde jsou změny ve zdrojovém kódu automaticky zkompilovány, otestovány a připraveny pro vydání do produkce anebo na testovací prostředí. Vývojové týmy tedy mají k dispozici zkompilovanou aplikaci s jejich přidanou novou funkcionalitou, která prošla standardizovaným testovacím procesem. To vývojářům pomáhá důkladněji ověřovat aktualizace a preventivně odhalovat problémy \cite{amazoncd}. Grafické znázornění CI/CD můžeme vidět na obrázku \ref{fig:cicd}.
\obr{Kontinuální integrace a nasazení \cite{imagecicd}}{fig:cicd}{0.6}{graphics/cicd.png}

\n{3}{Kontinuální testování}
Kontinuální testování je proces začlenění automatického testování do různých fázi životního cyklu vývoje softwaru. Testování hraje důležitou roli v procesu CI/CD, díky kterému vývojáři dostanu ihned zpětnou vazbu na fungování jejich implementovanému požadavku \cite{ibmct}.

Jedním z fundamentálních principů v moderním přístupu při vývoji aplikace je co nejrychleji dodat novou verzi produktu na produkční prostředí zákazníka, ale zároveň verze musí být v co nejlepší kvalitě a bez chyb. Manuální ověřování a dávání zpětné vazby vývoji v každé fázi životního cyklu je nevyhovující a neefektivní. Potřebuje spousty časových prostředků pro vykonání, tím se prodlužují fáze v životním cyklu a vydání nové verze se může opozdit \cite{ibmct}.

Zautomatizováním manuálních testovacích procesů dokážeme zefektivnit a zrychlit ověřování nových změn v aplikaci. Poskytováním rychlé zpětné vazby v prvních fázích vývoje zlepšuje kvalitu produktu. Kontinuální testování funguje pomocí automatizovaných nástrojů, které se nahrají jako předdefinované skripty do každé fáze cyklu. Automaticky spouštěné skripty eliminují potřebu lidského zásahu při provádění automatických testů. Pokud automatický test selže, vývojové týmy jsou upozorněni na chybu. Díky tomu jsou schopni rychle zareagovat a provést nezbytné úpravy zdrojového kódu dříve, než to ovlivní další fázi vývoje. Po úspěšném projití všech automatických testů, je projekt automaticky posunut do další fáze životního cyklu \cite{ibmct}. 

Kontinuální testování poskytuje automatizované metody pro zajišťování kvality a pro poskytování zpětné vazby o funkčnosti produktu v každé fázi životního cyklu při vývoji. Vývojové týmy získávají vyhodnocením automatických testů užitečné informace, které pomáhají zlepšovat kompatibilitu a kvalitu zdrojového kódu ještě před nasazení do produkčního prostředí zákazníka \cite{ibmct}. 

Dnešní moderní vývojové architektury jsou komplexní a vícevrstvé. Kontinuální verifikace pomáhá vývojovým týmům rozdělit složité systémy na menší celky, které pomocí automatizovaných testovacích metod můžeme otestovat samostatně. To výrazně zlepšuje zjišťování chyb a zrychluje proces jejich oprav \cite{ibmct}.

Pokročilé metody testování mohou simulovat různé scénáře a způsoby použití aplikace, díky kterým jsou vývojové týmy schopni sledovat chování produktu. Na základě chování ze simulací umožňují vývojářům odstranit z aplikace neefektivitu uživatelského rozhraní a vyhnout se nechtěným překvapením po nasazení produktu do produkce \cite{ibmct}.  

Ve velkých propojených systémech se může objevit chyba pouze v jednom modulu aplikace a způsobit dominový efekt. To může způsobit omezení v používání některých služeb a případně nedostupnost k aplikaci. Poskytovatelé Cloudu\footnote{Cloud je síť vzájemně propojených vzdálených serverů, které mají různé funkce, ale fungují jako jeden ekosystém. \cite{cloud}} se můžou setkat s chybou v systému na jednom konci, která může způsobit ochromení služby v celém regionu a vyřadit tak službu na několik hodin. To může být obzvláště zničující pro organizace, které jsou závislé na vysoké dostupnosti služeb. Kontinuální testování může odhalit tyto chyby hned na začátku na méně komplexnější úrovni. Organizace se tak může vyhnout přerušení svých služeb nebo dokonce nedostupnosti celé aplikace \cite{ibmct}.

\n{2}{Nástroje pro CI/CD}
Nástroje pro kontinuální integraci a nasazení mohou pomoct vývojovým týmům zautomatizovat jejich vývoj, testování a nasazení. Některé platformy se specializují na část integrační (CI), jiné nástroje jsou určeny pro kontinuální nasazování (CD) na produkční prostředí zákazníka a další jsou zaměřeny na zautomatizování testovacích procesů (CT) \cite{commoncicd}.

\n{3}{Jenkins}
Jeden z kvalitních nástrojů pro automatizaci CI/CD, který je dostupný ve verzi open-source\footnote{Open Source je software se zdrojovým kódem, který může kdokoli kontrolovat, upravovat a vylepšovat.\cite{open}}, je server Jenkins. Jenkins je navržen tak, aby zvládl cokoli od jednoduchého CI serveru až po kompletní proces CD. Jedná se o samostatný program založený na programovacím jazyku Java s balíčky pro operační systém Windows, MacOS a další operační systémy podobné Unixu. Se stovkami dostupných pluginů\footnote{Plugin je softwarový doplněk, který se instaluje do programu a rozšiřuje jeho možnosti.} Jenkins podporuje vytváření, nasazování a automatizaci při vývoji softwaru. Jenkins je jednoduchý na instalaci, má jednoduché a přívětivé uživatelské rozhraní, podporuje plánování automatizace a umožňuje upozorňovat o dokončeném běhu CI/CD \cite{katalon}.

\n{3}{Gitlab}
Gitlab je sada nástrojů pro správu různých procesů v souvislosti s vývojem softwaru. Základním produktem je webové rozhraní pro Git repozitář s funkcemi pro sledování chyb, analýzu anebo Wiki. Gitlab umožňuje spouštět kompilace zdrojového kódu, spouštět testy a nasazovat aplikaci při každé změně v repozitáři. Všechny tyto funkce můžeme spouštět na virtuálních počítačích, v Docker kontejnerech anebo na jiných serverech. Pomáhá automatizovat a zkracovat vydávání a nasazování nových verzí aplikací k zákazníkovi \cite{katalon}.

\n{3}{CircleIO}
Dalším známým nástroje pro CI/CD je platforma CircleIO, která umožňuje rychlý softwarový vývoj a publikaci nové verze aplikace. CircleIO podporuje automatizaci napříč všemi fázemi vývoje. Od kompilaci kódu, testování nové funkcionality až po nasazení nové verze softwaru do produkce. Stejně jako Jenkins, CircleIO integruje s různými nástroji pro správu zdrojového kódu jako je GitHub anebo Bitbucket. Automatická kompilace kódu probíhá v kontejnerech anebo na virtuálních zařízeních. Tudíž je možné kompilovat pod všemi operačními systémy. Umožňuje automatické pouštění testů, jejich paralelizaci a opět upozornění o výsledku běhu testů. Nástroj CircleIO poskytuje bezplatnou zkušební verzi aplikace na určitou časovou dobu \cite{katalon}.

\n{3}{Shrnutí}
Mezi další populární služby pro CI/CD patří TeamCity, Buddy anebo Travis CI \cite{katalon}. Existuje mnoho nástrojů, které podporují automatizaci vývojových procesů. Každý nástroj má svá specifika a způsob použití. Některé jsou open-source, jiné mají zkušební verze, ale pro další používání musíme zaplatit. To dává možnost vývojovým týmům použít takový nástroj, který nejvíce splňuje jejich požadavky.


\n{1}{Manuální testování} \label{n:tests}
Manuální testování je typ softwarového testování, ve kterém jsou jednotlivé testovací scénáře prováděny manuálně bez jakéhokoliv použití automatizovaného nástroje. Účelem ručního testování je identifikovat chyby, problémy a závady v softwarové aplikaci. Testováním lze dosáhnout takového stavu aplikace, aby byla bez majoritních chyb a fungovala podle specifikovaných funkčních požadavků. Manuální testování softwaru je nejprimitivnější technika ze všech typů testování, ale také pomáhá najít kritické chyby v aplikaci. Každá nová aplikace musí být ručně otestována, než bude možné její testování automatizovat. Koncepty ručního testování nevyžadují znalost žádného testovacího nástroje. I když manuální testování vyžaduje větší úsilí, tak v dnešní době CI/CD se tomu nedá vyhnout a je pořád důležité. Je možné zautomatizovat většinu funkcionality, ovšem nastanou různé testovací scénáře, které se zautomatizovat nedají. Na manuálním testováním by se měli podílet všichni, kteří jsou součástí vývoje. Manuální testování není výhradně pouze pro testery \cite{manual}.

\n{2}{Postup manuálního testování}
Ze všeho nejdříve se shromáždí veškeré dokumenty a informace potřebné k otestování implementované funkcionality. Tester zanalyzuje požadavky na testovanou funkcionalitu, aby pokryl všechny scénáře uvedené v zadání. Vytvoří testovací scénáře, podle kterých provede test. Pokud test objeví chybu, obrací se tester na vývojáře. Ti chybu zanalyzují a provedou její opravu. Po opravě chyby opět tester provede test podle testovacího scénáře. Pokud test splní očekávané výstupy, funkcionalita by měla být otestována \cite{performManual} .

\n{2}{Výhody}
Manuální testování nevyžaduje znalosti programování při použití metody Black box (viz kapitola \ref{n:black}). Používá se k testování dynamicky se měnícího grafického uživatelského rozhraní (animace). Tester pracuje se se softwarem jako skutečný uživatel, takže je schopen odhalit problémy s použitelností a uživatelským rozhraním. V případě malých projektů, manuální testování je výhodnější v poměru cena-výkon, oproti vytváření komplexnější infrastruktury k automatizaci. Manuální testování je rychlé na naučení \cite{performManual}.

\n{2}{Nevýhody}
Manuální testování v případě větších projektů a kontinuálního testování je časově náročné a nákladné na lidské zdroje. Testeři tvoří testovací scénáře na základě jejich dovedností a zkušeností. To může vést k nepokrytí některých funkčních požadavků. Funkcionalita se v průběhu vývoje mění a tím pádem některé testovací scénáře se musí přizpůsobit a aktualizovat \cite{performManual}.


\n{2}{White box}
White box testování je způsob testování softwaru, při kterém se testuje vnitřní infrastruktura aplikace a její zdrojový kód. Jde o funkcionální testování, kde se verifikuje funkčnost aplikace. Další názvy pro tento způsob jsou Clear box, Open box anebo Code-based testování. Hlavní myšlenkou je, že v průběhu testování je zdrojový kód aplikace viditelný pro testujícího. Testující může být v roli testera i vývojáře \cite{white}.

\obr{Schéma testování White box \cite{imagewhitebox}}{fig:wb}{0.8}{graphics/wb.png}

\n{3}{Účel testování}
White Box testování zahrnuje testování zdrojového kódu, kdy funkce voláme se seznamem předdefinovaných vstupů proti očekávaným nebo požadovaným výstupům. Když konkrétní vstup nevede k očekávanému výstupu, je to chyba. Testují se objekty a příkazy na individuální bázi, ověřuje se funkčnost podmíněných smyček \cite{white}.

\n{3}{Výhody}
Výhoda White box testování je obecně optimalizace a vylepšení zdrojového kódu. Testování je důkladnější, protože jsou obvykle pokryty všechny cesty v kódu. Provádění testů může začít už hned na začátku životního cyklu vývoje, jelikož nemusí být k dispozici grafické uživatelské prostředí \cite{white}.

\n{3}{Nevýhody}
Mezi nevýhody testování se považuje složitost prováděných testů a s tím související větší náklady na čas. Testování vyžaduje znalost zdrojového kódu a pochopení implementace \cite{white}.

\n{2}{Black box}\label{n:black}
Black box testování je testovací technika, při které se testuje funkčnost softwarové aplikace bez znalosti zdrojového kódu, architektury nebo implementačních detailů. Primárním zdrojem testování jsou specifikace požadavků, které stanoví zákazník. Je to metoda, při které tester vybere funkci s předaným vstupem a testuje, jestli výstupní hodnota funkce odpovídá očekávaným požadavkům. Pokud funkce vrací správné hodnoty, je test úspěšný. V případě nalezení chyby je vývojový tým informován a měl by pracovat na její opravě \cite{bb}.

\obr{Schéma testování Black box \cite{bb}}{fig:bb}{0.6}{graphics/bb.png}

\n{3}{Postup Black box testování}
Tester jako první musí shromáždit specifikované požadavky, které se vztahují k testovací funkcionalitě. Poté zanalyzuje požadavky a vytvoří testovací scénáře. Testovací scénáře jsou vytvořeny na základě vstupu a očekávaného výstupu. Scénáře by měly pokrývat jak pozitivní vstupy s platnými hodnotami, tak i nepříznivé vstupy s nevalidními hodnotami. Testování končí provedením všech testovacích scénářů a vyhodnocením jejich výsledků. Testovací scénáře, které vracely neočekávané výstupy, jsou předány vývojovým týmům pro další zkoumání a případnou opravu zdrojového kódu \cite{bb}.

\n{3}{Výhody}
Člověk provádějící Black box testování softwarové aplikace nemusí znát zdrojový kód ani implementační detaily o systému. Testy nejsou tak komplexní, protože testování probíhá z pohledu koncového uživatele \cite{bbpros}.

\n{3}{Nevýhody}
Vyžaduje stanovení priorit testování, ve velkých projektech je prakticky nemožné otestovat veškeré možné cesty v aplikaci. Nevýhodou s tím spojenou je určení, do jaké míry máme pokrytou aplikaci testy. Pokud test selže, může být časově náročné přijít na příčinu \cite{bbpros}.

\n{3}{Porovnání white box a black box testování}
Testování pomocí techniky black box usnadňuje testování komunikace mezi jednotlivými moduly v aplikaci. Oproti tomu white box testuje pouze konkrétní prvky v každém jednotlivém modulu. Black box testování poskytuje abstrakci od kódu a zaměřuje se na testování chování v aplikaci. To nám umožňuje nacházet různé cesty, kterými by se mohl vydata uživatel. U techniky white box jde o pochopení konkrétní implementace a je nutná znalost programování. Tester nemá nadhled nad danou funkcionalitu v aplikaci a je zaměřen pouze na implementační místo ve zdrojovém kódu. White box tedy testuje vnitřní strukturu aplikace, black box je zaměřen na verifikaci specifikovaných požadavků více z pohledu zákazníka. Obě techniky mají své výhody a nevýhody. Pokud software budeme testovat technikou white box i black box, jsme schopni dosáhnout lepší kvality a spolehlivosti aplikace \cite{bb}.

\n{2}{Gray box}
Gray box testování je technika testování softwarové aplikace, kdy tester má částečné znalosti o infrastruktuře a zdrojovém kódu testované aplikace. Gray box je softwarová testovací metoda, která kombinuje white box a black box testování. Účelem testování technikou gray box je vyhledat a identifikovat defekty způsobené nesprávnou strukturou kódu nebo nesprávným používáním aplikace. Ve vývoji dává Gray Box testování možnost testovat obě strany aplikace, prezentační vrstvu i kódovou část. Je primárně užitečný při integračním testování a penetračním testování \cite{gray}.

\obr{Schéma testování Gray box \cite{gpc}}{fig:gb2}{0.8}{graphics/gb2.png}

\n{3}{Výhody}
Testeři provádějící testování techniky gray box nemusí mít veškeré znalosti programovacího jazyka a infrastruktury aplikace jako je tomu u white boxu. Vyhovuje mít pouze částečnou znalost \cite{gpc}.

\n{3}{Nevýhody}
Gray box testování není vhodný pro testování algoritmů. Metoda nemá kompletní přístup ke zdrojovému kódu, což může v některých případech k omezenému testování. Některé testovací scénáře je obtížné navrhnout \cite{gpc}.

\n{2}{Explorativní testování}
Explorativní neboli průzkumné testování je metoda, kdy se testování aplikace netestuje podle napsaných testovacích scénářů, ale verifikace probíhá náhodně s cílem nalézt co největší počet chyb. Testování je zaměřeno spíše na přemýšlení testera, co ho zrovna napadne vyzkoušet v aplikaci. Může jít o jednoduché operace až po ty složitější, které je třeba nákladné na automatizaci, případně náročné vytvářet testovací scénáře. Průzkumné testování je široce používáno v agilním přístupu (\ref{n:agile}) vývoje softwaru. Klade důraz na osobní svobodu a odpovědnost jednotlivého testera. V rámci automatizovaného testování se nejdříve navrhne testovací scénář a později se přistoupí k automatizaci takového scénáře. Explorativní testování je simultánní proces, kde probíhá návrh testu a provedení testu současně \cite{expo}.

\n{3}{Průzkum vs Automatizace}
Přestože současným trendem v testování softwaru je tlak na automatizaci, explorativní testování je způsob jiného přemýšlení nad přístupem k aplikaci. Automaty fungují podle předem napsaných instrukcí, které na sebe musí navazovat. Kdežto explorativní testování je spontánní průzkum aplikace, kde se testování řídí kognitivními dovednostmi testujícího. Kroky v automatu jsou napsány tak, aby splňovaly specifikované požadavky vytvořené projektovými manažery případně zákazníkem. Průzkumným testováním můžeme nalézt jiné uživatelské cesty v aplikaci, které třeba v automatech nemusí být pokryty nebo byly nákladné na automatizaci. I automatizace má své limity, jelikož ne vše se dá zautomatizovat \cite{expo}.


\n{3}{Výhody}
Průzkumné testování je užitečné, když nejsou k dispozici specifikované požadavky na funkcionalitu v aplikaci. Umožňuje více proces vyšetřování, které pomáhá k nalezení více chyb než testování podle testovacích scénářů. Odhaluje chyby, které by mohly být jinými testovacími technikami ignorovány. Může tedy pokrývat různé případy a scénáře. Explorativní testování spoléhá na intuici testerů a pomáhá rozšířit znalost o produktu, což může zvýšit produktivitu. Tester může provést testování na základě svých nápadu a své kreativity \cite{expo}.

\n{3}{Nevýhody}
Explorativní testování není vhodné provádět delší dobu, je důležité si vždy určit časovou dobu. Testující mohou průběhu ztrácet motivaci. Testování je technika na základě zkušeností testera, záleží na jeho intuici a dovednostech \cite{expo}.

\n{2}{Akceptační testování}
Akceptační testování je typ testování prováděné koncovým uživatelem anebo zákazníkem za účelem ověření softwarové aplikaci ještě před nasazením do produkčního prostředí. Testování probíhá v závěrečné fází životního cyklu aplikace po provedení funkčního, integračního a systémového testování. Je testováno stylem Black box, kdy uživatel nezná zdrojový kód ani infrastrukturu aplikace. Koncový uživatel se soustředí na takové funkce a scénáře v aplikaci, které zákazník běžně používá \cite{uat}.

\n{3}{Důvody testování}
I když je akceptační testování až v závěrečné fází vývoje po všech jiných testování, zákazník může najít chyby a problémy, které se by se měly opravit. Pokud se prováděly změny v požadavcích během vývoje, k chybám může docházet díky špatné komunikaci mezi vývojovým týmem a zadavatelem požadavků na produkt. Vývojáři vytváří funkce podle specifikovaných požadavků, ovšem může docházet k jinému pochopení požadavků než zamýšlel zadavatel. Akceptační testování je tedy nutné pro ověření požadavků koncovým uživatelem v aplikaci, aby se potvrdila jejich správná implementace v konečné fázi produktu \cite{reasonat}.

\n{3}{Prerekvizity akceptačního testování}
Předtím než se zahájí akceptační testování, musí být splněno jednotkové testování, integrační a systémové testování. Vývojáři by měli mít implementované všechny specifikované požadavky pomocí zdrojového kódu. Aplikace by měla být bez majoritních chyb a zkontrolována pomocí regresního testování. Povolené jsou pouze chyby, které se týkají kosmetických části aplikace. A v neposlední řadě by mělo být připraveno prostředí, na kterém bude zákazník nebo uživatel provádět akceptační testování \cite{uat}.

\obr{Zařazení akceptačního testování do vývoje \cite{imageuat}}{fig:uat}{1}{graphics/uat.png}

\n{3}{Výhody}
Akceptační testování zvyšuje spokojenost samotných klientů při jejich testování aplikace, jelikož už si sami můžou vyzkoušet fungování produktu. Do budoucna zlepšuje definice požadavků, protože testuje požadavky podle svých potřeb. Informace shromážděné díky akceptačnímu testování podporují k lepšímu pochopení požadavků cílového zákazníka. Obecně zlepšuje kvalitu produktu jako je tomu u každého testování \cite{reasonat}.

\n{3}{Nevýhody}
Aby se akceptační testování mohlo provést je zapotřebí, aby zákazník sepsal své akceptační požadavky na funkcionalitu v aplikaci. To vede k tomu, že zákazník může sepsat požadavky špatně anebo vůbec \cite{reasonat}.

\n{1}{Automatické testování}
Automatické testování je softwarová technika, která provádí testování pomocí automatických testovacích skriptů, které dokáži fungovat bez jakéhokoliv lidského zásahu. Automatický skript nebo také automat je naprogramován tak, aby prováděl jednotlivé kroky z testovacího scénáře a porovnával aktuální výsledek s očekávaným výsledkem v daném kroku. Pomocí automatizačního nástroje je možné testovací sadu složenou z automatů spouštět opakovaně. To přináší jistou výhodu při vývoji softwaru, jelikož při testování specifikovaných požadavků se můžou tvořit opakující se kroky v testovacích scénářích. Jakmile je jednou automat napsán, už nepotřebuji žádný další lidský zásah a tester se může věnovat jiné činnosti \cite{at}.

Cílem automatizace je co nejvíce snížit počet manuálních testovacích scénářů. Manuální testovací scénáře, které jsou vybrány k automatizaci, by měly obsahovat často se opakující testovací kroky. Automaty by také měly testovat funkcionalitu, která je pro náš produkt důležitá a může být zákazníkem často používaná. Celkově je přínosem zautomatizovat takové testovací scénáře, které jsou časově náročné pro ruční testování \cite{at}.

U testovacích scénářů, které pokrývají často se měnící specifikované požadavky není vhodná automatizace. Automatizace není přínosná ani u testovacích scénářů, které se provedou jen jednou. U testovacích scénářů, které by byly časově náročné na automatizaci je vždy potřeba zvážit, jestli by automatizace byla přínosná. Automatizace má své limity a u ojedinělých případů je výhodnější provést testovací scénář ručně \cite{at}.

\n{2}{Důvody automatizace}
Automatizace testů je jedna z nejlepších cest, jak ve vývoji zvýšit rychlost testování požadované funkcionality. Automatizací lze celkově zvýšit efektivnost, spolehlivost a kvalitu vyvíjeného softwaru. Manuální testování všech možných testovací scénářů je časově a finančně náročné. Jelikož automaty nepotřebují zásah člověka při jejich provádění, lze automaty spouštět v průběhu celého dne i noci. Automatizací můžeme pokrýt větší množství funkcionality v aplikaci. Automatickým testováním můžeme předcházet lidskými chybám v testování, pokud je automatický skript sepsán spolehlivě a kvalitně  \cite{atreason}.

\n{2}{Rozdíly mezi manuálním a automatickém testování}
Automatizační testování pro provádění testovacích scénářů používají automatizační nástroje oproti manuální testování, kde testovací scénáře provádí člověk. Čas potřebný na provedení testovacího scénáře je výrazně nižší u automatů než u ručního testování. U ručního testování, oproti automatům, lze využít intuici a zkušenosti testera v explorativním testování. I když je počáteční fáze automatizace výrazně náročnější na časové prostředky než u manuálního testování, z dlouhodobého hlediska se tato investice vyplatí. Manuální testování je náchylnější na lidskou chybu, jelikož testování provádí člověk. Automat je sada příkazů, která se spolehlivě provádí pokaždé stejně. Automaty jsou citlivější na změny v aplikace, ať už jde o infrastrukturu kódu anebo grafické uživatelské rozhraní. Oproti tomu ruční testování takové změny dokáže zpracovat. Automaty lze spustit v paralelním režimu oproti více testovacím prostředím a tak snížit dobu vykonávání. U manuálního testování lze snížit dobu vykonávání tím, že se bude testování věnovat více testerů \cite{diff}.

\n{2}{Životní cyklus automatizace}
Životní cyklus automatizace je proces, při kterém dochází k vytvoření automatu a k zautomatizování testovacího scénáře. Je složen z šesti po sobě jdoucí fází, které jsou vykonávány sekvenčně. Proces je implementován zároveň s životním cyklem softwarového vývoje \cite{atlc}. Grafické znázornění životního cyklu automatizace je na obrázku \ref{fig:alc}.

\n{3}{Definování rozsahu automatizace}
V první fázi životního cyklu automatizace se rozhoduje, které části aplikace se dají zautomatizovat a které ne. Vybírají se testovací scénáře na základě jejich složitosti a časové náročnosti. Testeři diskutují o postupech, jak zautomatizovat konkrétní testovací scénáře. Zjišťují potřebný čas pro automatizaci, analyzují dostupné zdroje, které automat bude potřebovat \cite{atlc}.

\obr{Schéma životního cyklu automatizace \cite{imageatlc}}{fig:alc}{0.5}{graphics/alc.png}

\n{3}{Výběr testovacího nástroje}
Druhá fáze životního cyklu je výběr samotného testovacího nástroje. Fáze se považuje za kritickou, jelikož automatizace testů vysoce závisí na zvoleném testovacím nástroji. Pomocí automatizačního testovacího nástroje můžeme snadno přistupovat k testovacím datům, zvládnout implementaci testu a porovnat skutečný výstup s očekávaným výsledkem. Při výběru je potřeba zvážit, pro jaký typ aplikace (webové, on-premise\footnote{On-premise je označení pro aplikaci, která je nainstalována lokálně na počítač.}) budou automaty vytvářeny. Analyzují se limitace zvoleného nástroje, jestli je nástroj open-source nebo je placený. V potaz se musí brát i zkušenosti lidí, kteří budou s testovacím nástrojem pracovat \cite{atlc}.

\n{3}{Plánování, návrh a strategie}
V další fázi životního cyklu automatizace se tvoří plán a postup automatizace. Probíhá plánování automatizace testovacích scénářů, určí se potřebný čas pro automatizaci a v jakém pořadí budou testovací scénáře automatizovány. Testovací tým zjistí testovací standardy a pravidla zvoleného automatizačního testovacího nástroje. Zanalyzují výhody a nevýhody testovacího nástroje a podle toho zvolí návrhový vzor pro implementaci automatu. Zvolí se strategie, jak často budou automaty pouštěny, proti jakému prostředí budou provozovány a kde budou zobrazovat výsledky \cite{atlc}.

\n{3}{Příprava prostředí}
Fáze příprava prostředí zahrnuje přípravy ohledně prostředí, kde budou automatu pouštěny. Jde o vytvoření a konfiguraci virtuálních strojů, kontejnerů anebo cesta k webovému rozhraní. Testovací prostředí by mělo být nastaveno podobně jako bude nastavení prostředí u zákazníka, aby bylo dosaženo co největší rovnováhy mezi testovacími a produkčními daty. Probíhá konfigurace prostředí pro simulaci testů na podporovaných operačních systémech. Pokud jde o webovou aplikaci, v úvahu se bere testování ve všech podporovaných webových prohlížečích. Konfiguruje se databáze s testovacími daty, kterou budou automaty používat \cite{atlc}.

\n{3}{Vývoj a spuštění testu}
V předposlední fází životní cyklu automatizace probíhá samotný vývoj testu a následné jeho spuštění proti nakonfigurovanému testovacímu prostředí. Automatizace testovacích scénářů probíhá podle plánu, který byl vytvořen ve fázi plánování. Pomocí automatizačního nástroje probíhá přepis kroků z testovacího scénáře do příkazů pomocí zdrojového kódu. Podle navrženého testovacího vzoru se buduje infrastruktura testovacího repozitáře. Testovací kód automatu by měl být napsán tak, aby byl přehledný, srozumitelný a spolehlivý. Změny ve zdrojovém kódu automatu mohou být kontrolovány jinými testery za účelem zkvalitnění psaného automatu \cite{atlc}.

Jakmile automat, obsahující všechny funkční aspekty z testovacího scénáře, je hotov, test je zařazen do testovací sady. Testovací sada automatů se spustí proti nakonfigurovaných prostředí. V případě testování webové aplikace, by automaty měly být spuštěny ve všech podporovaných webových prohlížečích. Testovací sady mohou být spuštěny ručně anebo automaticky podle naplánovaného časového harmonogramu \cite{atlc}.

\n{3}{Výsledky testu}
V poslední fázi životního cyklu je shromáždění výsledků po dokončení všech automatických testů. Týmy zanalyzují výsledky a vyhodnotí automaty, které identifikují chybu. Chyba v automatu může znamenat, že je problém v aplikaci anebo může automat spadnout díky neočekávané situaci, se kterou naprogramovaný skript nepočítal \cite{atlc}.

\n{3}{Údržba automatů}
Údržba automatů nemá svoji vlastní fázi v životním cyklu automatizace, ale probíhá po celou dobu vývoje. Pokud je přidána nová funkcionalita do aplikace anebo proběhla rozsáhlejší změna, je potřeba přizpůsobit stávající automaty v testovací sadě. Testovací sada se musí upravit tak, aby automaty netestovaly zastaralou funkcionalitu, aby nedocházelo k testování duplicit. Cílem je mít co nejrychleji otestovanou funkcionalitu, ale aby pokrytí automatů bylo co nejefektivnější \cite{atlc}.

\n{2}{Výhody}
Automatické testování zabere mnohem méně času než manuální testování. Lidský zásah při vykonávání automatů je minimální a nevyžaduje tolik lidských zdrojů jako u ručního testování. Zlepšuje efektivnost využití času. Automatizační testování je spolehlivější, protože eliminuje skryté chyby opětovným prováděním testovacích případů stejným způsobem. Automaty poskytují opětovnou použitelnost testovacích scénářů při testování různých verzí stejného softwaru. Zajišťuje konzistenci v aplikaci a zlepšuje kvalitu aplikace, jelikož automaty mohou být pouštěny frekventovaně. Tester může zanalyzovat odezvu softwaru, protože se provedení stejné operace v automatu několikrát opakuje \cite{atreason}.

\n{2}{Nevýhody}
Pro automatizaci testovacích scénářů volíme kvalitní automatizační nástroje, které vyžadují znalosti a zkušenosti testerů. Prvotní fáze zprovoznění automatizace je náročná na čas. Automaty mohou být nestabilní, pokud testovací prostředí vykazuje pokaždé jiné chování aplikace. Velké množství automatů v testovací sadě může být náročnější na údržbu, díky častým změnám požadavků v aplikaci. Nekvalitní automaty mohou padat na chyby, které nesouvisí s problémy v aplikaci a jsou náročnější na údržbu \cite{atreason}.


\n{2}{Testovací pyramida}
Testovací pyramida automatizace představuje různé typy testů a množství, s jakou by se měli objevit v testovací sadě. Testovací pyramida má tři základní vrstvy. Nejspodnější vrstvou v pyramidě jsou Unit testy, které by měly mít v testovací sadě největší zastoupení. Jejich vytvoření a následná údržba stojí nejméně času a jejich čas běhu v testovací sadě je nejrychlejší. Více o unit testování v kapitole \ref{n:unit}. Střední vrstvu v testovací pyramidě tvoří Service neboli integrační testy. Jsou to testy, které testují tok dat z jednoho modulu aplikace do druhého. Takové testy v testovací sadě jsou více časově náročné na tvorbu a správu než Unit testy a jejich čas běhu je také o něco delší. Na vrcholu pyramidy je vrstva, kterou tvoří automaty testující grafické rozhraní aplikace neboli End-to-End testy. Více o takových testech v kapitole \ref{n:e2e}. Jsou to testy, které jsou nejvíce časově náročné na tvorbu a následnou údržbu v testovací sadě. Čas potřebný pro otestování aplikace je nejdelší ze všech tří zmíněných typů testů. Proto by v testovací sadě UI\footnote{Automaty testující uživatelské rozhraní aplikace.} testy měli mít co nejmenší zastoupení. Testovací pyramida pomáhá k vytvoření optimální testovací sady, která produkt co nejrychleji otestuje a zároveň kvalita testování bude největší \cite{tp}. Grafické znázornění testovací pyramidy je na obrázku \ref{fig:tp}.

\obr{Testovací pyramida \cite{imagepyramid}}{fig:tp}{0.6}{graphics/test-pyramid.png}

\n{2}{Unit testy}{\label{n:unit}}
Unit testy testují jednotky nebo jednotlivé součásti systému. Cílem testování je ověřit, že jednotka softwarového kódu funguje podle očekávání. Testovací funkci je předán vstup a verifikuje se aktuální vrácená hodnota oproti očekávané. Jednotkové testy oddělují části kódu a ověřují funkčnost jednotlivých modulů, procedur, tříd a metod. Jedná se testování technikou White box, kdy je k dispozici zdrojový kód a infrastruktura aplikace. Testy se tvoří ve vývojové fázi implementace a jejich čas na vytvořené by měl být nejkratší podle testovací pyramidy. Unit testy můžou psát jak vývojáři, tak i testeři \cite{unit}.

\n{3}{Důležitost unit testů}
Unit testování probíhá v testovacím cyklu jako první. Jsou na první úrovní testovací pyramidy před integračními a systémovými testy. Pokud se implementuje nová funkcionalita, pomocí unit testů je vývojář schopen ihned identifikovat problém ještě v implementační fázi. Čas potřebný pro opravení chyby je v takové fázi nejkratší, jelikož se testování pohybuje na úrovni zdrojového kódu. To snižuje pravděpodobnost nalezení chyb v dalších fázích testování, kde čas potřebný na opravu chyby je delší. Unit testování pomáhá testerům a vývojářům lépe porozumět zdrojovému kódu a tím pádem umožňuje rychlejší opravy problémů. Dobré unit testy můžou sloužit i jako dokumentace projektu \cite{unit}.

\n{3}{Výhody}
Unit testování využívá modulový přístup, díky kterému lze testovat různé části zdrojového kódu bez čekání na dokončení jiných částí funkcionality. Správně napsané unit testy poskytují vývojářům přehled o implementované jednotce (třída, metoda, objekt, funkce), aniž by studovali zdrojový kód jednotky. Unit testy pomáhají vývojářům při migraci nebo refaktoru\footnote{Refaktor je označení pro činnost, kdy dochází ke zlepšení zdrojového kódu programu.} kódu, jelikož poskytují očekávané hodnoty, které by měl nový kód vracet. Unit testy snadno odhalí chybu ve zdrojovém kódu \cite{unit}.

\n{3}{Nevýhody}
Unit testy testují pouze jednotky ve zdrojovém kódu aplikace. Unit testy nedokáži odhalit chyby na úrovni integrace s jinými moduly anebo rozsáhlé chyby na úrovní systémových testů. Unit testy je někdy obtížné napsat na rozsáhlou implementaci ve zdrojovém kódu, občas zaberou stejné množství času jako samotná implementace funkcionality. Při unit testování není možné pokrýt všechny cesty v programu. Je zapotřebí dalšího testování na vyšší úrovni \cite{unit}.

\n{3}{Test Driven Development - TDD} \label{n:tdd}
Test Driven Development zkráceně TDD je evoluční technika ve vývoji softwaru, ve které dochází k implementaci unit testů ještě před samotným psaním zdrojového kódu. Jedná se o iterativní přístup, který kombinuje vytváření unit testů, programování a refaktor. Cílem techniky TDD je mít optimalizovaný a kvalitní kód, který je zároveň pokrytý unit testy \cite{tdd}.

\obr{Schéma cyklu TDD \cite{imagetdd}}{fig:tdd}{0.7}{graphics/tdd.png}

TDD má tři fáze vývoje. V první fázi je vytvořen unit test, aby ověřil správnost konkrétních funkcí, které jsou specifikované požadavky. Vývojáři tvoří test na základě svých předpokladů, jaký seznam vstupů bude funkce brát a seznam výstupů, které bude funkce vracet. Na začátku by měl test spadnout, jelikož zatím není implementovaná jednotka, kterou test verifikuje. Ve druhé fázi přístupu vývojář implementuje jednotku tak, aby unit test k dané jednotce procházel. Jakmile unit test prochází, nastává třetí fáze v TDD. V třetí fázi se optimalizuje jednotka tak, aby neobsahovala redundanci a celkově zvýšila svůj výkon \cite{tdd}. Grafické znázornění fází v cyklu TDD je na obrázku \ref{fig:tdd}.

Metoda TDD podporuje tvorbu optimalizovaného a kvalitního zdrojového kódu aplikace. Při tvorbě unit testů pomáhá vývojářům lépe analyzovat a porozumět požadavkům zákazníka. Testovací pokrytí aplikace v rámci TDD na úrovní unit testů je mnohem vyšší, jelikož TDD se zaměřuje už hned od začátku na vytváření testů pro každou funkcionalitu \cite{tdd}.

\n{3}{JUnit}
Je nejrozšířenější open-source nástroj pro unit testování v programovacím jazyce Java. Je užitečný pro psaní a opakované spouštění unit testů. Junit hraje také důležitou rolí při psaní testů a zdrojového kódu technikou Test Driven Development. JUnit prosazuje myšlenku "nejříve testování a pak kódování". Poskytuje anotace k identifikaci testovacích metod. Nástroj nabízí širokou škálu assertovacíh\footnote{Metoda, která srovnává a vyhodnocuje aktuální hodnotu s očekávanou. } metod a podporuje další nástroje pro spouštění testů. Unit testy lze organizovat do testovacích sad. S pomocí JUnit je možné psát testy rychle, efektivně a spolehlivě \cite{junit}.

\begin{figure}
\begin{verbatim}
import org.junit.Assert;		
import org.junit.Test;		

public class SampleTest {				
   	
    @Test		
    public void createAndSetNameTest() {					
        		
        String expected = "Y";					
        String actual = "Y";					

        Assert.assertEquals(expected, actual);					
        System.out.println("SampleTest is successful " + actual);	
    }		
}
\end{verbatim}
\caption{Ukázka testu v JUnit}
\label{fig:junittest}
\end{figure}

\n{3}{NUnit}
Nunit testovací nástroj slouží pro psaní a spoštění unit testů pro všechny typy .NET programovacích jazyků. Nástroj je poskytnut jako open-source aplikace. Ve vývojových prostředí, jako je třeba Visual Studio, je nabízen NUnit jako NuGet\footnote{NuGet je nástroj pro správu balíčků, který je navržen pro sdílení znovupoužitelného zdrojového kódu mezi vývojáři. \cite{nuget}} balíček. Abychom mohli spouštět testy uvnitř vývojového prostředí je zapotřebí také nainstalovat NuGet balíček NUnit Test Adapter. NUnit nabízí také plno assertovacích metod, které pomáhají vývojářům při psaní unit testů. Pomocí atributů lze označit testovací třídy anebo testovací metody. Atribut \verb|[Test Fixture]| označuje testovací třídu, v rámci které jsou vykonávány jednotlivé testovací metody označeny atributem \verb|[Test]|. Atributy \verb|[Setup]| a \verb|[TearDown]| se používají pro označení metod, které mají být provedeny před samotným testováním a po skončení testu. NUnit nabízí implicitně několik dalších atributů a podporuje vytvoření vlastních, specifických pro účely testování \cite{nunit}.

\n{2}{Integrační testování}
Hlavní cílem integračního testování je verifikace modulů nebo komponent při zapojení do systému. Jedná se o kombinaci technik testování Black, White a Gray box. Integrační testování se obvykle provádí po unit testování, kdy máme všechny jednotky vytvořené a pokryté testy. Jakmile jsou jednotky otestovány, jsou postupně integrovány jedna po druhé, dokud nejsou zintegrovány všechny moduly. Testuje se komunikace, stabilita a chování mezi moduly. Integrační testování probíhá během vývoje aplikace a některé moduly nemusí být k testování dispozici. Pokud jde o testovací pyramidu, integrační testy jsou na prostřední pozici mezi unit a systémovém testování. Jejich čas na vytvoření a provádění testů je o něco delší než u unit testování, ale kratší než u testů kontrolující grafické rozhraní aplikace \cite{integration}.

\n{3}{Důležitost integračních testů}
Při vyvíjení aplikace se požadavky rozdělí mezi vývojáře, kteří pracují na jednotlivých požadavcích nebo také modulech. Každý vývojář individuálně implementuje požadavky na základě svých zkušeností a dovedností. Implementace se můžou tedy lišit modul od modulu, proto se používají integrační testy ke kontrole integrace mezi jednotlivými moduly. Dalším důvodem, proč používat integrační testy, je verifikace toku dat mezi jednotlivými moduly. Na jednom modulu data můžou mít jinou strukturu než na tom dalším v celém systému aplikace. Testováním ověříme, že data vystupující z jednoho modulu jsou akceptovány dalším modulem v aplikaci. Moduly v aplikace také komunikují s nástroji nebo API rozhraním třetích stran a integračními testy lze ověřit, že komunikace je správná \cite{integration}.

\obr{Integrační testování \cite{imageintegration}}{fig:it}{0.8}{graphics/integrationTesting.png}

\n{3}{Rozdíly mezi integračním a systémovým testováním}
V systémovém testování jde o testy, které kontrolují chování systému jako celek. Nerozlišují se jednotlivý moduly zvlášť, ale všechny komponenty jsou integrovány dohromady. U integračních testů se verifikují moduly jednotlivě a zaměřují se na funkční aspekt aplikace \cite{integration}.

\n{3}{Výhody}
Integrační testování zajišťuje kontrolu modulů a komponent integrovaných dohromady. Testováním hledáme chyby související s komunikací a přenosem dat mezi moduly. Chyba v malém celku integrovaných komponent lze snáze ladit a opravit, než pokud by chyba byla odhalena v modulu zapojeném do celého systému. Integrační testování může začít hned, jakmile je modul k dispozici. Testování nemusí čekat na dokončení všech modulů v aplikaci \cite{integration}.

\n{3}{Výzvy}
Integrační testování nemá nevýhody jako takové, ale má pár obtížností. Testování je komplexnější, protože do testu se zahrnují různé moduly a části, jakou jsou databáze, různé nástroje a součásti testovaného prostředí. Při integraci modulů používající rozdílné přístupy a techniky může být náročné pro sestavení integračního testu. U testování integrace modulů s nástroji třetích stran může často docházet ke změně některého z modulů, integrační testy se musí aktualizovat a přizpůsobit \cite{integration}.

\obr{Schéma integrovaných modulů}{fig:schemeModule}{0.6}{graphics/schemaIntegration.png}

\n{3}{Přístupy integračního testování}
Existují v zásadě dva typy přístupů k integračnímu testování. První je přístup zvaný Big Bang a tím druhým je přístup Inkrementální. Inkrementální přístup se dále rozlišuje na přístupy Top-down, Bottom-up a Sandwich přístup \cite{integration}.

Big Bang testování je technika integračního testování, kdy všechny jednotky nebo komponenty v systému jsou zintegrovány dohromady a jsou testovány jako jedna jednotka. Tato sada jednotek je považována při testování za entitu. Integrační testování může začít pouze tehdy, když jsou implementovány a zapojeny všechny jednotky v systému \cite{integration}.

V inkrementální přístupu integračního testování jde o integraci dvou nebo více logicky souvisejících modulů, které jsou následně testovány. Postupně jsou integrovány další související moduly, dokud nejsou všechny logicky související moduly zintegrovány a otestovány. Inkrementální testování se dále dělí na Top-Down, Bottom-Up a Sandwich přístup, které se liší podle způsobů integrování a jednotlivých modulů \cite{integration}.

Bottom-up přístup začíná testovat od nejnižší nebo nejvnitřnější jednotky aplikace a postupně pokračuje nahoru k modulům na vyšší úrovni. Integrace pokračuje pořád výš dokud nejsou zintegrovány všechny moduly v aplikaci. Na obrázku \ref{fig:schemeModule} je příklad zintegrovaných modulů. Typem Bottom-Up začíná integrační testování od nejnižších modulů B1C1, B1C2 a B2C1, B2C2, které jsou testování pomocí unit testů. Integrační test verifikuje komunikaci modulů B1 a B2 s nejnižšími moduly B1C1, B1C2 a B2C1, B2C2. Pokud nejsou moduly na vyšších úrovních implementovány, používají se fiktivní programy pro volání funkcionality na nižších vrstvách. Výhodou přístupu Bottom-U, že pokud existuje závažná chyba na nejnižší jednotce programu, je snazší ji odhalit a opravit \cite{integration}.

Top-down přístup integračního testování začíná od nejvyššího modulu a postupně postupuje směrem k nižším modulům. Pouze nejvyšší modul je otestován pomocí unit testů. V případě schématu na obrázku \ref{fig:schemeModule} začíná integrační testování modulem A s moduly nižší vrstvy B1 a B2. Hlavní výhodou Top-down přístupu je testování kritických modulů jako první \cite{integration}.

Sandwich nebo Hybrid strategie je kombinace přístupů Bottom-up a Top-down. Je to technika, ve které jsou zintegrovány moduly nejvyšší úrovně s moduly nižší úrovně a zároveň jsou nejnižší moduly integrovány s vyššími. Takto zintegrované moduly jsou brány jako jeden systém, na kterém je prováděno integrační testování \cite{integration}.


\n{3}{Nástroje}
Existuje několik typů nástroj pro provádění integračního testování. Prvním populárním nástroje je VectorCAST/C++, který je používaný pro unit a integrační testování. V programu je každá jednotka nebo modul testován nezávisle, aby došlo k ověření, že komponenty fungují bez jakékoliv závislosti. Poté jsou během integračního testování moduly zkombinují a verifikuje se jejich správně chování. Program VectorCAST/C++ je určen pro vývojáře programující zdrojový kód v jazyce C++. Další nástroj pro testování je program Citrus, který je open-source software napsaný v Javě podporující automatické integrační testování \cite{inttools}.


\n{2}{Systémové testování}{\label{n:e2e}}
Systémové testování je soustava různých typů testů, které verifikují kompletně celý integrovaný softwarový systém. Testování je prováděnou technikou Black Box, kdy neznáme zdrojový kód aplikace. Cílem testování je ověřit funkčnost a chování všech specifikovaných požadavků v kompletním softwarovém systému. Jde o verifikaci koncových funkcí a scénářů, proto systémové testování se také označuje jako end-to-end testování. V testovací pyramidě (obr. \ref{fig:tp}) se testy nacházejí na vrcholu pyramidy. Z definice pyramidy jde o testy, které jsou nejvíce časově nákladné na jejich tvorbu a údržbu. Z hlediska času je systémové testování nejdelší. V testovacím cyklu je systémové testování prováděno po integračním a unit testováním \cite{importancesystem}.

\obr{Systémové testování \cite{imagesystem}}{fig:system-test}{0.7}{graphics/system-test.jpg}

\n{3}{Důležitost testování}
Testování verifikuje funkčnost kompletního systému a zajišťuje správné chování koncových funkcí, které jsou k dispozici zákazníkovi. Systémové testování se nachází na konci cyklu testování a jde o poslední testování, které se provádí před vydáním nové verze produktu na produkční prostředí. Testy většinou běží na testovacím prostředí, které může být nejblíže k produkčnímu prostředí u zákazníka. Tím pádem testy poskytují takovou zpětnou vazbu, která by se mohla přiblížit zpětné vazbě klienta. Automaty se pouští i po nasazení nové verze na produkci pro zajištění funkčnosti a stabilitě nové verze aplikace. Systémové testování hraje důležitou roli, která pomáhá k vydání spolehlivé a kvalitní aplikaci \cite{importancesystem}.

\n{3}{Typy systémového testování}
Systémové testování zahrnuje mnoho technik, způsobů a typů, jak systémově otestovat aplikaci. Použití některého z nich závisí na produktu, organizačních procesech, časové ose a požadavcích. Mezi nejznámější typy systémového testování patří GUI testování, Smoke testování, Funkcionální, Performance, Regresní, Kompatibilní, testování použitelnosti a zátěžové testování \cite{systemtest}.

GUI neboli testování grafického uživatelského rozhraní testuje funkcionalitu, která je viditelná pro uživatele. Testování zahrnuje kontrolu tlačítek, ikon, dialogových oken, panelů, textových polí a další komponenty, se kterými pracuje uživatel v GUI prostředí \cite{systemtest}.

V regresním testování systémovými testy se provádí verifikace celého systému s cílem identifikovat závady, které se mohli zavést při implementaci změn a požadavků v průběhu celého vývoje. Regresní testování aplikace zajišťuje kontinuální kvalitu aplikace \cite{systemtest}.

Smoke testování obsahuje testovací sadu testů, které mají za úkol zkontrolovat zkompilovanou verzi aplikace pro další její testování a používání. Testy ověřují pouze kritické funkce v aplikaci \cite{systemtest}.

Performance testování nebo také testování výkonu je proces testování softwaru používaný k měření rychlosti, doby odezvy, stability, škálovatelnosti a celkově spolehlivosti aplikaci při zatížení. Hlavním účelem testování je identifikovat a odstranit místa, kde dochází k přehlcení systému při zátěži aplikace \cite{perf}.

Testování použitelnosti spadá pod ne-funkcionální testování. Primárně se zaměřuje na uživatele a jejich práci s aplikací. Cílem testování je zkontrolovat, zda je aplikace použitelná a snadno pochopitelná pro koncové zákazníky. Při použití testování použitelnosti se zjišťuje, jestli je vyvinutý software jednoduchý, přímočarý a usnadňuje práci uživatelům \cite{systemtest}.

Mezi systémové testování se zahrnují testy, které testují kompatibilitu softwaru. Testování má za cíl otestovat kompatibilitu vyvíjené aplikace s různými prohlížeči, operačními systémy, databázemi a jinými nástroji \cite{systemtest}.

\n{3}{Výhody}
Systémové testování zahrnuje verifikaci koncových funkcí, které zákazník používá. Jedná se o end-to-end testování, které obsahuje testy na kontrolu koncových uživatelských cest. Nejčastěji testy běží na testovacím prostředí, 
které nejvíce připomíná produkční. Test mohou být spuštěny také na produkčním prostředí u zákazníka. To může 
odhalit chyby a problémy, se kterými by se klient mohl setkat. Testování zajišťuje správné chování celé aplikaci a pomáhá ověřit funkčnost specifikovaných požadavků od zákazníka anebo projektového manažera \cite{systemtest}.

\n{3}{Nevýhody}
Testování celého systému je časově náročné na provedení, jelikož testy pokrývají celou softwarovou aplikaci. Náklady na tvorbu a údržbu systémových testů jsou vysoké, protože pokrývají architekturu softwaru a správné chování funkčních požadavků. K vytvoření a provedení testu je zapotřebí větších znalosti a zkušenosti testujícího.

\n{3}{Nástroje}
Nástrojů a frameworků\footnote{Framework je softwarová struktura, která pomáhá při vývoji a organizaci jiných softwarových projektů. Může obsahovat pomocné programy, knihovny API a jiné nástroje pro podporu vývoje softwarové aplikace. \cite{framework}} je k dispozici celá řada pro provoz systémového testování. Nástroje pomáhají k tvorbě testovacích scénářů, implementaci testů, následné jejich spuštění a zpracování výsledků. Známým frameworkem pro automatizaci všech testů je nástroj Selenium. Má široké uplatnění ve všech typech testů a podporuje provoz testů v všech webových prohlížečích \cite{uitools}. Více o tomto frameworku budu psát v kapitole \ref{n:selenium}.

Dalším populární nástrojem pro testování je framework Robot. Framework je open-source a používá se pro automatizaci robotických procesů a automatizaci testování. Je napsán v programovacím jazyce Python a lze jej použít s dalšími vhodnými nástroji pro tvorbu automatických testů \cite{uitools}.

\cast{Praktická část}

\n{1}{Testovací aplikace}
Testovací aparát byl vyvíjen ve spolupráci s Knihovnou UTB a jeho hlavním cílem je zaručit kontinuální testování dostupnosti služeb na internetu. Za služby jsou považovány webové aplikace, které poskytují elektronické zdroje informací. Testovací program obsahuje sadu systémových testů, které verifikují funkčnost přihlášení do jednotlivých služeb. Přihlášení probíhá přes grafické uživatelské rozhraní webového prohlížeče. Každý test kontroluje několik možností, jak se přihlásit do konkrétní služby a získat přístup do elektronického zdroje. Testovací sada bude spouštěna na linuxovém serveru v nastavených intervalech. Po dokončení aktuálního běhu testovací sady budou výsledky automatických testů shromážděny a poslány elektronickou poštou do schránky adresáta. Správce bude mít k dispozici aktuální přehled o stavu jednotlivých služeb.

\obr{Portál elektronických zdrojů}{fig:ezdroje}{0.8}{graphics/ezdroje.png}

\n{2}{Elektronické zdroje}
Portál E-Zdroje K.UTB nacházející se na webové stránce \url{https://ezdroje.k.utb.cz} nabízí seznam elektronických informačních zdrojů pro Univerzitu Tomáš Bati ve Zlíně. Ukázka portálu je na obrázku \ref{fig:ezdroje}. Portál spravují techničtí pracovníci z Knihovny UTB. Je zde k dispozici několik desítek elektronický zdrojů, kde každý zdroj je zařazen do několika kategorií. Rozlišují se například podle licence, typu zdroje, typu obsahu, tématiky zdroje anebo podle jazyku. V testovací aplikaci se testy zaměřují pouze na zdroje, které jsou předplacené s licencí. Volně dostupné zdroje a zdroje se zkušebním přístupem se na základě konzultace s pracovníky Knihovny UTB netestují. Každý elektronický zdroj má různé způsoby, jak se přihlásit a získat přístup do dané služby. 


\n{3}{Přístup přes Shibboleth}
Každý elektronický zdroj v databázi má přihlášení přes technologii Shibboleth. Shibboleth je jedním z nejrozšířenějších systému pro správu identit na světe. Technologii používají akademické instituce, federace identit a komerční organizace po celém světe. Umožňuje bezpečný a bezproblémový přístup k chráněným on-line zdrojům a aplikacím. S jedinou identitou se uživatel může přihlašovat do různých systémů. Projekt je open-source a jeho používání je zdarma \cite{shibboleth}.


\n{3}{WAYF}
Další možností přihlášení do služby je způsobem WAYF. WAYF je zkratka pro projekt s názvem \verb|Where Are You From|. Jde o způsob přihlášení do služby za pomocí instituce. Uživatel se naviguje na webové stránky služby, kde zvolí přihlášení pomocí instituce. Vybere ze seznamu institucí, ve které má registrovanou identitu. Po vybrání instituce dojde k přesměrování na instituci, kde uživatel zadá své přístupové iniciály a standardně se přihlásí. Pokud jsou přihlašovací údaje validní, dojde přes technologii WAYF ke přesměrování zpět do služby, ve které už je uživatel přihlášen pod svým účtem z instituce \cite{wayf}. Grafické znázornění WAYF přístupu je na obrázku \ref{fig:wayf}.

\n{3}{WAYFless}
Tzv. WAYFless přihlášení do služby je provedeno navigací na webovou stránku pomocí URL odkazu, který obsahuje identifikátor poskytovatele identity (IdP) Shibboleth a tím umožňuje přeskočit nutnost volby IdP. URL odkazy umožňují přímý přístup na obsah elektronického zdroje použitím autentizace třetí strany. V našem případě je to autentizace za použití technologie Shibboleth. Po úspěšném přihlášení je uživatel přesměrován do služby, kde je rozeznána jeho identita. Přihlášení wayfless způsobem značně redukuje počet kroků, které musí uživatel udělat pro přihlášení do elektronického zdroje \cite{wayfless}.

\n{3}{Proxy}
Pro přístup k elektronickým zdrojům přes Knihovnu UTB může uživatel využít proxy UTB s prefixem URL \verb|https://proxy.k.utb.cz/login?url=|. V URL proxy pak následuje odkaz na danou službu. Pomocí proxy uživatel získává vzdálený přístup k elektronickému zdroji. Na rozdíl od přihlášení přes Shibboleth, vzdálený přístup přes proxy typicky nevyžaduje podporu ze strany provozovatele elektronického zdroje. Do proxy se lze přihlásit přes Shibboleth technologii anebo uživatel může zvolit přihlášení s údaji k LDAP. Po úspěšném přihlášení je uživatel přesměrován na službu, kde je identifikován.

\n{3}{VPN}
Všechny výše zmíněné typy přihlášení přistupují k elektronickým zdrojům s libovolnou IP adresou. Další alternativou, jak se dostat ke službám je použít univerzitní IP adresu. Pokud se přihlašujeme z počítače, který není připojen do interní sítě univerzity, je potřeba se připojit do sítě vzdáleně přes VPN. Jakmile uživatel získá univerzitní IP adresu, může k elektronickým zdrojům přistupovat bez přihlášení. Uživatel může zvolit jakýkoliv způsob přístupu do služby (Shibboleth, WAYF, WAYFless, Proxy), vždy je přesměrován a ve službě identifikován. Nevýhodou přístupu přes VPN je nutnost instalovat aplikaci VPN klienta na stanici koncového uživatele.

\obr{Přihlášení přes WAYF \cite{wayf}}{fig:wayf}{0.7}{graphics/wayf.png}

\n{2}{Důvod testování}
Vzhledem k nárůstu využívání centrálního Identity Providera (IdP) i rozšíření počtu zpřístupňovaných služeb se zviditelnily občasné problémy s dostupností elektronických zdrojů. Jednotlivé elektronické zdroje mohou být nefunkční po aktualizaci nebo změně konfigurace. O nedostupnosti zdroje se správci dozvídají až z reakce uživatelů, někdy se značným časovým odstupem.

\n{2}{Přínos}
Vytvoření nástroje pro pravidelné automatizované testování přihlašovacího procesu do jednotlivých elektronických zdrojů bude předcházet problémům s jejich dostupností. Umožní rychle zareagovat při nedostupnosti služby, kontaktuje správce knihovny o problému. Automaty budou výhodné i pro jednotlivé služby poskytující elektronické zdroje, jelikož budou monitorovat funkčnost přihlášení do jejich portálů. Cílem je zvýšit kvalitu zdrojů knihovny UTB a zvýšit spolehlivost při přihlašování uživatelů do služeb. 


\n{1}{Řešení}
Cílem je vytvořit nástroj pro pravidelné automatizované testování přihlašovacího procesu. Přihlašování přes Shibboleth je založeno na webovém workflow a přesměrování uživatele ze služby poskytující elektronické zdroje na IdP a zpět. Pokud chceme tento workflow proces automatizovat a zároveň zajistit, že se bude chovat stejně pro uživatele i testovací automat, nejvhodnější volbou je spustit workflow ve skutečném prohlížeči a přehrát předem zaznamenané činnosti uživatele. Tento typ testování je nazýván End-to-End. V End-to-End testování jde o zajištění funkčnosti všech komponent přihlašovacího řešení z pohledu uživatele. Verifikuje řešení od zdroje dat o uživatelích (Active Directory) přes Identity Providera po jednotlivé poskytovatele elektronických zdrojů. Testovací aplikace bude provozována na linuxovém serveru, kde bude testovací sada pouštěna v pravidelných intervalech. Shromažďování a zobrazení výsledků v html formátu bude také provádět testovací aplikace za použití python pluginů. Nástroje pro kontinuální integraci a nasazení (CI/CD) nebyly použity, jelikož by to vytvářelo větší komplexitu řešení než ulehčení práce s testovací aplikací pro pracovníky knihovny UTB. Automatické spouštění testovací sady bude pravidelně naplánováno každou hodinu pomocí aplikace \verb|cron| na linuxovém stroji.

\n{2}{Požadavky na řešení}
Testovací aplikace bude určena pro kontinuální testování provozovaných služeb ve webovém rozhraní. Je požadavkem zajistit spouštění testů v podporovaných webových prohlížečích. Automaty budou používat end-to-end testování, tudíž provedení přihlášení bude pomocí grafického uživatelské rozhraní. Je potřeba vybrat takový nástroj k automatizaci, který bude open-source, zdarma a bude mít zákaznickou podporu. V případě nově přidaných služeb poskytující elektronické zdroje, bude mít možnost napsat testovací skript i zaškolený pracovník knihovny UTB. Požadavkem pro vybrání technologie k psaní automatů je tedy uživatelsky přívětivý framework, díky kterému půjde snadno psát nové automaty. Řešení bude mít možnost spouštět testovací sadu pravidelně a výsledky automatů posílat na email. Nástroj by měl podporovat spouštění testů na operačním systému Linux.

\n{2}{Selenium} \label{n:selenium}
Selenium je jedním z nejpoužívanějších open-source nástrojů pro automatické testování webového uživatelského rozhraní. Selenium neumí testovat desktopové aplikace, ale je určen testování webu. Nástroj podporuje automatizaci napříč různými webovými prohlížeči (Google Chrome, Opera, Firefox, Internet Explorer, Safari). Umožňuje spuštění ve všech operačních systémech (Windows, Mac, Unix/Linus). Pro implementace automatických testů framework podporuje několik programovacích jazyků (C\#, Java, Perl, Php, Python, Ruby). Selenium se používá také pro psaní funkcionálních testů a umožňuje integraci dalších automatických nástrojů k dosažení kontinuálního testování (Maven, Jenkins nebo Docker). Lze také použít pro správu a spouštění automatů nástroje jako je NUnit anebo JUnit. Selenium se skládá z několika komponent, které lze použít pro automatizaci \cite{sel}. 

\n{3}{Selenium IDE}
Selenium IDE slouží primárně pro nahrávání a spouštění automatických skriptů ve webovém prohlížeči. Rozšíření pro prohlížeč Firefox nebo Chrome snadno vytváří testy pomocí funkcí pro nahrávání a spouštění automatických skriptů \cite{sel}. 

\n{3}{Selenium RC}
Selenium RC nástroj umožňuje psaní automatických testů ve skriptovacím jazyce, které testují webové rozhraní aplikace. Skládá se ze serverové a klientské knihovny. Testovací skript je vložen do webového prohlížeče, ve kterém skript provádí různé interakce \cite{sel}.

\n{3}{Selenium Grid}
Selenium Grid podporuje souběžné provádění automatických testů na různých prohlížečích, počítačích a operačních systémech současně. Nástroj usnadňuje testování kompatibility mezi prohlížeči. Zkracuje také celkový čas běhu automatů \cite{sel}.

\n{3}{Selenium WebDriver}
Selenium WebDriver je vylepšená verze komponenty Selenium RC. Je to nejdůležitější součást sady Selenium. S pomocí WebDriver lze testovací skripty vyvíjet pomocí libovolných podporovaných programovacích jazyků a umožňuje spouštět tyto skripty ve všech moderních prohlížečích. Testují grafické rozhraní aplikace \cite{sel}.

\n{3}{Výhody}
Selenium umožňuje testovat webové aplikace ve všech podporovaných prohlížečích a na všech operačních systémech. Nástroj je zdarma a volně přístupný jako open-source. Implementace automatických jazyků lze pomocí několika programovacích jazyků. Automaty se dají spouštět paralelně což zkracuje celkovou dobu vyhodnocování testů a zvyšuje efektivnost. Selenium se dá integrovat s JUnit, NUnit, Maven a dalšími nástroji, které slouží pro rychlejší a snadnější testování pomocí automatických skriptů \cite{sel}.

\n{3}{Limitace}
Nástroj slouží pouze pro testování webových aplikací. Pro efektivní vytváření automatických skriptů vyžaduje Selenium kvalitní znalosti a dovednosti v oblasti programování. Nelze provádět automatické testování webových služeb SOAP nebo REST. Konfigurace a příprava testovacího prostředí pro běh Selenium zabere delší čas \cite{sel}.

\n{2}{Cypress}
Cypress je moderní, zdarma a open-source nástroj, který slouží pro automatizaci systémových testů, integračních i unit testů. Automaty se programují pomocí programovacího jazyka Javascript a především slouží pro testování front-end\footnote{Část webové aplikace, se kterou uživatel komunikuje a interaguje. Jde o grafické rozhraní webové aplikace.} aplikace. Je kompatibilní s různými webovými prohlížeči a také operačními systémy (Windows, Mac, Unix/Linux). Umožňuje kontrolovat a spravovat síťový provoz. Cypress lze také integrovat s několika nástroji pro kontinuální integraci a nasazení \cite{cyp}.

Kromě běžného psaní automatických skriptů Cypress poskytuje vizuální rozhraní, ve které zobrazuje aktuálně spuštěné testy a provedené příkazy ve skriptu. Umožňuje testovat vysoce interaktivní a responzivní aplikace. S nástrojem Cypress můžeme přistupovat a manipulovat v aplikaci přes HTML DOM webové stránky, vyplňovat textové pole, odesílat formuláře a testovat přítomnost grafických prvků na stránce \cite{cyp}.

\obr{Cypress \cite{imagecyp}}{fig:cypress}{1}{graphics/cypress.png}

\n{3}{Výhody}
Používání nástroje Cypress poskytuje mnoho výhod a vylepšení. Jedna z hlavních výhod oproti nástroji Selenium je zabudované automatické čekaní na zobrazení elementu na stránce pro pozdější jeho interakci. Automaty se stávají stabilnějšími a spolehlivějšími. Další implicitní funkcí v Cypress je poskytování video záznamu spuštěného testu, který slouží pro pozdější ladění a správu automatického skriptu. Poskytování obrázků při spadnutí testu je samozřejmostí. K dispozici je také vizuální rozhraní Cypressu, kde můžeme testy ladit, spravovat a spouštět. Testy lze integrovat s několika nástroji pro kontinuální testování, testy lze spouštět v různých webových prohlížečích a na různých operačních systémech \cite{cypadv}. 

\n{3}{Limitace}
Cypress je založen pouze na JavaScriptu, tudíž je potřeba nutná znalost tohoto programovacího jazyku. Nástroj neumožňuje používat více záložek v jednom testovacím webovém prohlížeči a s tím související používání více webových oken v jednom testovacím automatu. Cypress nemá možnost automaticky generovat příkazy automatického skriptu a také nepodporuje testování mobilních aplikací \cite{cypadv}.

\n{2}{Playwright}
Nástroj Playwright od společnosti Microsoft je open-source nástroj pro psaní a spouštění automatických testů ve webovém uživatelském rozhraní a v nativních mobilních emulátorech. Jeho používání je zdarma a má dobrou uživatelskou podporu při potížích. Je založen na Node.js a za vytvořením stojí stejní vývojáři, kteří vyvinuli framework Puppeteer. Umožňuje spouštění automatických testů ve většině moderních webových prohlížečů a na všech operačních systémech. Implementaci automatických skriptů v nástroji Playwright lze pomocí několika programovacích jazyků (TypeScript, JavaScript, Python, .NET, Java). Nástroj implicitně poskytuje několik funkcí, díky kterým jsou automatické skripty stabilnější a spolehlivější. Test automaticky čeká, než dojde k zobrazení elementu na stránce pro následující akci s elementem. Má také bohatou sadu introspekčních událostí, které vedou k větší stabilitě testů. V době dynamických webů Playwrigth nabízí plno assertovacích metod, které se automaticky opakují, dokud nejsou splněny dané podmínky. Assertovací metoda porovnává a kontroluje očekávaný výsledek s aktuálním. V Playwrigth je implicitně zabudované opakování této kontroly při nesplnění podmínek, jelikož může docházet k nestabilitám mezi automatem a webových prohlížečem \cite{play}.

\n{3}{Podporující nástroje}
Playwright umožňuje generovat testovací kód v libovolném programovacím jazyce na základě akcí v nástroji Playwright Codegen. Uživatel ve webovém rozhraní klikne na element a Codegen vygeneruje tuto akci ve zdrojovém kódu zvoleného programovacího jazyka, který lze použít v automatickým skriptu. Playwright inspector poskytuje uživatelské rozhraní, ve kterém uživatel může hledat elementy na stránce, generovat selektory k elementům, procházet jednotlivé kroky po provedení testu a další funkce. Playwright Trace Viewer zachycuje všechny informace o provedením testu, jakmile dojde k jeho selhání. Zobrazuje všechny akce provedené v automatické skriptu, zobrazuje dynamické snímky HTML DOMu, zachycuje síťovou komunikace a mnoho dalších funkcí, které pomáhají při prozkoumávání spadlého automatu \cite{playtools}.

\obr{Ukázka nástroje Trace Viewer \cite{imagetrace}}{fig:trace}{1}{graphics/trace.png}

\n{3}{Výhody}
Playwright je nástroj, který poskytuje prostředí pro psaní stabilních a spolehlivých automatických testů, které lze spouštět ve většině moderních webových prohlížečů. Je multiplatformní a zdrojové kódy automatických skriptů lze psát v několika jazycích. Hlavní výhodou je, že poskytuje implicitně automatické čekání na elementy na webové stránce před provedením akce a assertovací metody několikrát opakují své vyhodnocování na dynamické webové stránce. To umožňuje lepší stabilitu a větší spolehlivost automatů. Playwright vytváří jednotlivé kontexty prohlížeče pro každý test, to umožňuje izolaci a nezávislost testů. Playwright také nabízí další funkce, které zrychlují a zlepšují automatizaci. Pomocí Codegen uživatel dokáže rychle a snadno vytvořit nový kód a s pomocí nástroje Trace Viewer uživatel dokáže rychle zjistit problém u neprocházejícího testu \cite{playadv}.

\n{3}{Limitace}
Playwright nepodporuje pouštění automatických skriptů ve webovém prohlížeči Internet Explorer 11 a starší verze prohlížeče Microsoft Edge. Další limitací je, že nelze spustit automaty na reálných mobilních zařízeních. Možností, jak obejít tuhle limitaci je použití mobilního emulátoru v prohlížeči \cite{playadv}.

\n{2}{Výběr řešení} \label{n:solution}
Při výběru řešení pro automatické testování procesu přihlašování do služeb poskytující elektronické zdroje knihovny UTB, bylo bráno v potaz několik faktorů. Nástroj pro automatizaci měl být zdarma, jeho zdrojový kód měl být open-source a měl by umožnit vytvářet stabilní a spolehlivé automatické testy kontrolující grafické rozhraní webové aplikace. Implementace automatických skriptů by měla být co nejjednodušší, aby nové automaty mohl vytvářet i zaškolený pracovník knihovny. Testovací nástroj by měl být ověřený v praxi a měl by mít dobrou dokumentaci. Testy by měly být provozovány ve většině moderních webových prohlížečích a nástroj musí být spustitelný na linuxovém operačním systému. 

Vybíral jsem z několika nástrojů, které jsou open-source, jejich používání je zdarma a snadno dostupné. Existuje mnoho frameworků pro automatické testování grafické webového rozhraní. Zanalyzoval jsem tři frameworky Selenium, Cypress a Playwright, které jsou osvědčenými nástroji pro automatizaci testovacích skriptů. 

Selenium je velmi používaný nástroj pro automatické testování grafického rozhraní ve webovém prohlížeči. Umožňuje psát automaty v různých programovacích jazycích. Bohužel neposkytuje generátor automatického skriptu a je tedy nutná dobrá znalost programovacího jazyka. Jelikož Selenium nemá implicitně zabudované automatické čekání na přítomnost elementu na stránce, vyžaduje při psaní automatů explicitně vytvářet dodatečná čekání před provedení akce na elementu. Ne vždy se taková čekání snadno vytváří a také může dojít k přehlédnutí. To způsobuje nestabilitu a nepřesnost automatických skriptů. Selenium je velmi často používaný frameworkem pro psaní automatů, ale v případě vytváření testovací aplikace pro kontrolu elektronických zdrojů přes své limitace není vhodný nástroj. 

Další nástroje pro automatické testování jsem vybral k analýze Cypress a Playwright. Oba dva jsou moderní nástroje, které mají automatické čekání na přítomnost elementu na stránce předtím, než se provede akce na elementu. Nástroje umožňují sekvenční i paralelní pouštění automatických testů v různých webových prohlížečích. Playwright je vyvíjen velkou společností Microsoft poskytující kvalitní dokumentaci a širokou uživatelskou podporu. I když je Cypress vyvíjen menší společností, také poskytuje detailní dokumentaci a má rozsáhlou komunitu lidí řešící různé problémy spojené s automatizací v Cypressu. Automaty v Cypressu jsou psané pouze pomocí programovacího jazyka Javascript, kdežto u Playwright si uživatel může vybrat z několika jazyků (TypeScript, JavaScript, Python, .NET, Java). Cypress i Playwright zachycují různé informace, které se můžou použít pro analýzu spadlého automatu. Jsou to především záznamy obrazovky, videozáznamy, dynamické zobrazení HTML DOMu a další informace spojené s během spadlého automatu.

Jelikož testovací aplikace se bude v budoucnu rozšiřovat o další nově přidané služby poskytující elektronické zdroje, důležitým faktorem pro zvolení automatizačního nástroje byla jednoduchost psaní nových automatických skriptů. Playwright poskytuje nástroj, díky kterému může zaškolený uživatel snadno generovat zdrojový kód automatu. Takový zdrojový kód dále vloží do testovací aplikace a automat pustit. Cypress žadný generátor kódu nemá. Po konzultaci s pracovníky technického oddělení knihovny UTB, kteří budou spravovat a vytvářet nové automaty v testovací aplikaci, byl zvolen nástroj Playwright pro kontinuální testování provozovaných služeb.

\n{1}{Použité technologie}
Pro vytvoření testovací aplikace, spouštění automatických testů a následné zpracování výsledků jsem použil několik technologií. Technologie by měly být kompatibilní se všemi moderními webovými prohlížeči, zdarma a umožňuje jejich používání na linuxovém stroji. Jde zejména o automatizační framework Playwright a další funkce importovány přes plugin\footnote{Označení pro balík funkcí, které nepracují samostatně, ale různým způsobem rozšiřují funkcionalitu aplikace} balíčky.

\n{2}{Playwright}
Hlavní nástroj pro psaní, správu a spouštění automatických testů jsem zvolil open-source aplikaci Playwright. Důvody, proč byl zvolen tento framework, jsou sepsány v kapitole \ref{n:solution}. Automatické skripty jsou psány programovacím jazykem Python. Python je interpretovaný a objektově orientovaný jazyk, který je multiplatformní a jednoduchý na naučení. Zdrojový kód v pythonu je přehledný a snadno čitelný. Tyhle všechny faktory ovlivnily výběr programovacího jazyka, ve kterém se budou psát automatické skripty v nástroji Playwright. V budoucnu se počítá s rozšiřováním automatických skriptů v testovací aplikaci, jelikož bude zapotřebí testovat nově přidané služby poskytující elektronické zdroje. V programovacím jazyce Python by měli pracovníci knihovny UTB snad vytvořit a dále spravovat takové automatické skripty.

\n{2}{Pytest plugin}
Pytest je open-source framework, který umožňuje snadno vytvářet automatické testy podporující komplexní funkční testování aplikací a knihoven. Automaticky detekuje testy v repozitáři testovací aplikace. Pomocí anotací můžeme testovací metody označit kategorií, případně celou testovací metodu přeskočit. Pomocí pytestu dokážeme spustit specifický test nebo testy patřící do stejné kategorie \cite{pytest}.

\n{2}{Pytest-XDist plugin}
Plugin Pytest-XDist rozšiřuje pytest o další možnosti spouštění testů. Nejpoužívanější technika je distribuce testů do více procesů, což poskytuje rychlejší provádění testů. Uživatel může předem určit, kolik procesů má být k dispozici při spouštění testů anebo je zde možnost automatického přiřazení procesů podle výkonu počítače.

\n{2}{Flaky plugin}
Flaky plugin je nástroj pro automatické spouštění flaky automatických testů. Flaky je označení pro nestabilní test, který vrací náhodně pozitivní a negativní výsledky, aniž by se zdrojový kód aplikace anebo testu změnil. Díky nástroji Flaky můžeme anotovat takové testovací metody, které jsou nestabilní. Při neúspěchu testu se takový test pouští několikrát, dokud nevrátí úspěšný výsledek \cite{flaky}.

\n{2}{Yagmail plugin}
Yagmail plugin je rozšíření, díky kterému lze snadno posílat elektronickou poštu. Je možnost využít klienta pro Gmail službu od společnosti Google anebo klienta SMTP. Pro testovací aplikaci byl vytvořen účet na Gmailu a emaily se posílají přes klienta Gmail v pluginu YagMail.  Pro Yagmail posílá textové emaily, emaily s HTML obsahem a také emaily s libovolnou přílohou. 

\obr{Ukázka výstupu HTML pluginu}{fig:html}{1}{graphics/html.png}

\n{2}{Pytest-Html plugin}
S pomocí pluginu pytest-html testovací aplikace dokáže shromáždit výsledky po běhu automatických skriptů a vygenerovat HTML dokument s výsledky testů. HTML stránka umí zobrazit a filtrovat počet úspěšných, neúspěšných a přeskočených testů. U každého spadlého automatu zobrazí chybu a záznam obrazovky. Ukázka takové HTML souboru je na obrázku \ref{fig:html}.


\n{2}{Git}
Git je verzovací nástroj, který slouží pro ukládání a správu zdrojového kódu aplikace. Umožňuje sledovat změny v kódu programu. Díky nástroji Git může vývojář verzovat svoji aplikaci, vracet zpět nežádoucí funkcionalitu a případně spolupracovat s dalšími vývojáři v rámci jedné aplikace.


\n{1}{Uživatelská příručka}
Uživatelská příručka slouží jako návod pro uživatele, ve kterém je popsána konfigurace prostředí a jak testy spustit. 

\n{2}{Konfigurace prostředí}
Před samotném spuštěním automatických testů musí uživatel nakonfigurovat prostředí, ve kterém testy budou běžet. Pro správné fungování testovací aplikace uživatel musí splnit všechny kroky, které jsou popsány v této kapitole.

\n{3}{Python}
Základem před spuštěním automatických testů je mít nainstalován skriptovací jazyk Python. Na oficiálních stránkách \url{https://www.python.org/downloads} uživatel stáhne instalační soubor a nainstaluje ho na zařízení, ve kterém budou testy spuštěny. Po nainstalování skriptovacího jazyka si uživatel může ověřit verzi přes příkaz \verb|python --version|. Testovací aplikace byla vyvíjena na verzi Pythonu 3.9.6 a je kompatibilní od této verze výše.

\n{3}{Knihovny jazyka Python} \label{n:reqs}
V projektu testovací aplikace uživatel najde soubor s názvem \verb|requirements.txt|. Soubor obsahuje seznam knihoven s jejich verzemi, které jsou nezbytně nutné pro správné chování testovací aplikace. Knihovny se mohou nainstalovat jednotlivě standardním příkazem v Pythonu \verb|pip install [název_pluginu]|. Další možností je nainstalovat knihovny najednou přes příkaz \verb|pip install -r requirements.txt|, ale příkaz musí být provolán na stejné cestě jako se nachází soubor se seznamem knihoven.

\obr{Ukázka konfiguračního souboru config.ini}{fig:config}{0.8}{graphics/config.png}

\n{3}{Konfigurační soubor config.ini} \label{n:configIni}
Testovací projekt obsahuje konfigurační soubor, pomocí kterého uživatel může nastavovat různé parametry pro automatické testy. Na prvních řádcích konfiguračního souboru jsou autentizační parametry, pod kterými se budou automatické testy přihlašovat do služeb poskytující elektronické zdroje. Dalším parametrem je URL adresa, kterou automaty budou používat při přihlašování do služeb přes Proxy UTB. Předposledním parametrem v konfiguračním souboru lze přepínat mezi normálním režimem a režimem VPN. S režimem VPN se automatické testy spoléhají na připojení do služby z univerzitní IP adresy. Tudíž bez potřeby zadávání přihlašovacích údajů a samotného přihlášení do služby. Poslední konfigurační nastavení je o povolení/zakázání notifikací elektronickou poštou s výsledky automatických testů. Při povolení notifikací uživatel vyplní emailovou adresu, na kterou se výsledky automatů budou posílat. 

\n{2}{Spouštění testů}
Spouštění automatických testů je za pomocí pluginu \verb|pytest|. Uživatel se naviguje do složky projektu s testovací aplikací. Než uživatel spustí automatické skripty, je potřeba vyplnit parametry v konfiguračním souboru \verb|config.ini|, který je popsán výše.

Je několik možností, jak testy spouštět. Hromadné spuštění testů začne po zavolání obecného příkazu \verb|python -m pytest| v kořenovém adresáři testovací aplikace. Spustí se všechny testy, který mají předponu anebo koncovku \verb|_test| v názvu třídy automatického testu. Pokud uživatel chce spustit konkrétní automatický skript, obohatí příkaz \verb|python -m pytest| názvem daného automatu a cestou k němu. Příkaz s názvem konkrétního automatu je na obrázku \ref{fig:specifictest}. Automaty jsou rozdělené ve složkách a více o infrastruktuře projektu testovací aplikace je popsáno v kapitole \ref{n:infra}.

\begin{figure}[b]
\begin{verbatim}
python -m pytest Tests/Services/academic_search_complete_ebsco_test.py
\end{verbatim}
\caption{Příkaz pro spuštění konkrétního testu}
\label{fig:specifictest}
\end{figure}

\n{2}{Parametry spouštění a pytest.ini} \label{n:pytestIni}
Testovací aplikace umožňuje spouštět automatické testy v různých režimech a s různým nastavením. Tyto režimy a nastavení se provádějí přidáním parametrů do příkazového řádku při spuštění aplikace. Příkaz, který je na obrázku \ref{fig:command}, je obohacen o několik argumentů pro nastavení a spuštění testů. Jelikož pro uživatele je náročné vyplňovat tyto argumenty při každém spuštění, plugin pytest umožňuje tyto argumenty uložit do souboru \verb|pytest.ini|. Tyto argumenty budou načteny ze souboru a použity při zavolání obecného příkazu \verb|python -m pytest|. Argumenty se vyplňují ručně k parametru \verb|addopts| (viz. obrázek \ref{fig:ini}). Dalším parametrem v souboru \verb|pytest.ini| testovací aplikace je \verb|markers|, kterým jsou označeny automaty běžící v režimu VPN.

\obr{Ukázka souboru pytest.ini}{fig:ini}{0.8}{graphics/pytestini.png}

\begin{figure}[b]
\begin{verbatim}
python -m pytest --headed --browser=firefox --force-flaky -n 5
\end{verbatim}
\caption{Příkaz s různými parametry}
\label{fig:command}
\end{figure}

\n{3}{Parametry pro pytest}
Samotný plugin pytest nabízí mnoho parametrů, které lze použít v příkazové řádce při spouštění testů. Prvním důležitým parametrem je \verb|--headed|, který umožňuje pustit testy v grafickém okně. Bez uvedení tohoto parametru testy běží v headless režimu, ve kterém jsou spuštěny na pozadí bez zobrazení grafického rozhraní webového prohlížeče. Dalším parametrem je \verb|--browser|, ve kterém uživatel specifikuje webový prohlížeč pro automatické testy. Hodnoty jsou \verb|chromium|, \verb|firefox| anebo \verb|webkit|. Existují další příkazové parametry, díky kterým uživatel může ovlivnit běh testů a jejich výstup. Například testy se můžou spustit ve zpomaleném režimu, pro každý test se může zaznamenávat video jeho provádění, případně záznam obrazovky při neúspěchu a další možnosti.

\n{3}{Parametr pro flaky}
Testovací aplikace obsahuje plugin flaky, díky kterému lze označit nestabilní automaty. Takto označené automaty se v případě selhání pustí několikrát. K označení automatů se používají dekorátory v Pythonu. V případě pluginu flaky vypadá dekorátor takhle \verb|@flaky(max_runs=3)|. V tomto případě se automat spustí opakovaně maximálně třikrát, pokud bude automat nestabilní. V testovací aplikaci nejsou dekorátory označeny žádné automaty, ale ověřená metoda je spustit testy s globálně nastaveným atributem \verb|--force-flaky|. Takto jsou všechny testy považovány za nestabilní a v případě selhání se test pustí znova. K nestabilitě může dojít například zpomalením internetové sítě anebo jiných okolností, které dopředu neznáme. 

\n{3}{Parametr pro xdist}
Díky pluginu xdist je uživatel schopen pustit testovací sadu paralelně. Tím se ušetří čas na provedení všech testů a k dosažení rychlejší zpětné vazby od služeb poskytující elektronické zdroje. Pro paralelní spuštění uživatel zadá do příkazové řádky atribut \verb|-n| a hodnotu \verb|auto| anebo konkrétní počet procesů. V případě \verb|-n auto| režimu plugin vytvoří počet procesů podle výkonu počítače, na kterém jsou testy provozovány. Procesy jsou oddělené a v jednom procesu může běžet právě jeden automat. Po skončení testování se výsledky automatů z každého procesu shromáždí a uloží jako jeden celek.

\n{2}{Výsledky testů a report\_sent.txt} \label{n:reportsent}
Po každém běhu testovací sady jsou výsledky testů shromážděny a vyexportovány do HTML souboru. V projektu jsou HTML soubory s výsledky uloženy ve složce \verb|htmlReports|. Jakmile automatický test narazí na chybu při svém běhu, vyfotí aktuální zobrazenou stránku na obrazovce a uloží v podobě obrázku. Záznamy obrazovky neúspěšných automatů jsou uloženy v testovacím projektu ve složce \verb|screenshots|. Tyto záznamy obrazovky se nacházejí i v HTML reportu s výsledky automatů. Ukázka HTML souboru je na obrázku \ref{fig:html}.

Testovací aplikace obsahuje soubor \verb|report_sent.txt|, ve kterém se ukládá seznam spadlých automatů. Upozorňující email s výsledky automatických skriptů je poslán, jakmile je do souboru se seznamem spadlých automatů je uložen nový záznam o neúspěšném automatu. Pokud v aktuálním testovacím běhu spadnou automaty, které jsou už obsažené v souboru \verb|report_sent.txt|, email s výsledky se nepošle. Uživatel v tomto případě bude upozorňován pouze na nově neúspěšné automaty. Tento mechanismus předchází zahlcení emailové schránky adresáta. Uživatel může soubor ručně upravovat. 


\n{1}{Programátorská příručka}
V programátorské příručce rozeberu infrastrukturu projektu. Jaké složky a soubory testovací aplikace obsahuje a popíšu z jakých částí se implementačně skládá automatický skript. Uvedu zde i návod, jak rozšířit testovací aplikaci o další automaty, které budou testovat nově přidané služby.

\n{2}{Návrhový vzor Page Object Model} \label{n:pom}
V testovací aplikaci je použit návrhový vzor Page Object Model (POM). Je jedním z populárních vzorů, které se používají při automatizaci testů kontrolující grafické rozhraní softwaru. Primárním cílem použití tohoto vzoru je vyhnout se duplicitě zdrojového kódu a zlepšit znovupoužitelnost napsaného kódu. To zvyšuje přehlednost, údržbu automatických testů a snadnější psaní nových automatů.

Automatické testy se navigují na různé webové stránky v prohlížeči. Pomocí vhodných lokátorů jsou identifikovány elementy na HTML stránce, se kterými se provádějí různé akce. S využitím návrhového vzoru POM tyto elementy v rámci jedné HTML stránky zabalí do jediného objektu. Elementy v objektu jsou zapouzdřeny a interakce jsou prováděny přes metody objektu. Jakmile se automatický test naviguje na webovou stránku, vytvoří se nová instance objektu reprezentující danou stránku. Přes tuto instanci automat provádí interakce se HTML stránkou \cite{pom}.

\obr{Schéma použití návrhového vzoru POM}{fig:pom}{0.9}{graphics/pom.png}

\n{3}{Důvod použití}
Při automatizaci testů grafického rozhraní se automat naviguje na různé webové stránky a používá pro ovládání stránky různé grafické prvky (tlačítka, textová pole, přepínače a další). Pro identifikování a následnou akci s elementy se používají lokátory. Neustálé psaní lokátorů elementů v každém automatu zvyšuje náročnost na správu takového automatu, dochází k duplicitním použití lokátorů a celkově zvyšuje náklady na údržbu. Při změně grafického uživatelského rozhraní aplikace by musely být lokátory přepsány na všech místech a to by opět zvýšilo časovou náročnost na opravu automatů. Tyto důvody vedly k použití návrhového vzoru Page Object Model, kdy elementy s lokátory jsou zapouzdřeny v objektu na jednom místě a pomocí funkcí dochází k interakci s elementy. Elementy v objektu lze volat v různých testovacích automatech, tím se zvyšuje znovupoužitelnost zdrojového kódu a nedochází k psaní duplicitních lokátorů pro elementy. Jelikož jsou objekty s lokátory odděleny od automatů, automatické testy se stávají přehlednějšími a je snadnější čtení kódu \cite{pom}.


\n{2}{Infrastruktura projektu} \label{n:infra}
V kořenovém adresáři testovacího projektu se nacházejí soubory:
\begin{itemize}
    \item \verb|requirements.txt| (\ref{n:reqs})
    \item \verb|pytest.ini| (\ref{n:pytestIni})
    \item \verb|config.ini| (\ref{n:configIni})
    \item \verb|report_sent.txt| (\ref{n:reportsent})
    \item \verb|conftest.py|
\end{itemize}

Conftest.py je skriptovací soubor, ve kterém jsou definované metody provádějící se před anebo po spuštění testovací sady. Před spuštěním testů se ve funkci \newline \verb|read_report_file()| načítá seznam automatů ze souboru \verb|report_sent.txt|. Po skončení automatů se porovnává seznam načtených automatů se seznamem neúspěšných automatů z aktuálního běhu. Provede se množinová operace rozdíl mezi těmito seznamy. Pokud v seznamu právě neúspěšných automatů přebývají záznamy, provede se emailová notifikace právě s těmito přebývajícími automaty. V emailu se nachází příloha typu ZIP, která je vytvořena funkcí \verb|create_zip_file_with_report()|. ZIP soubor obsahuje HTML s výsledky a záznamy obrazovky spadlých automatů.

\n{2}{Složka Helpers}
Jak již název napovídá, složka \verb|Helpers| obsahuje skriptovací soubory, které pomáhají při práci s daty, obsahuje pomocné assertovací funkce a další. 

\n{3}{Asserts.py}
Třída \verb|Asserts| obsahuje funkce, které slouží pro efektivnější kontrolovaní datových prvků ve webovém prohlížeči. 
Funkce v třídě:
\begin{itemize}
    \item \verb|is_exists(self, selector, message, timeout=20000)| - slouží pro kontrolu, jestli element existuje na stránce
    \item \verb|check_inner_text(self, selector, text)| - verifikuje, jestli element obsahuje text, který je předán v parametru
    \item \verb|check_inner_html(self, selector, html)| - kontroluje, jestli element obsahuje HTML kód, který je předán v parametru
\end{itemize}

\begin{figure}[t]
\begin{verbatim}
def check_inner_text(self, selector, text):
    self.test.assertTrue(self.utils.is_exist(selector, 20000), 
                   f"Element with {text} is not exist.")
    it = 0
    while it < 5 and text not in self.page.inner_text(selector).rstrip():
        self.page.wait_for_timeout(2000)
        it += 1
    self.test.assertIn(text, self.page.inner_text(selector))
\end{verbatim}
\caption{Metoda pro kontrolu textu}
\label{fig:innertext}
\end{figure}


\n{3}{Data.py}
Třída \verb|Data| zpracovává a ukládá informace, které byly načteny z konfiguračního souboru \verb|config.ini|. Informace se týkají přihlašovacích údajů pro uživatele, nastavení notifikací, proxy a režimu VPN. Dalším atributem ve třídě \verb|Data| jsou informace o elektronických zdrojích, které jsou dostupné na URL adrese \url{https://www-new.k.utb.cz/eresources-list.php}. Třída obsahuje funkce, které jsou potřebné pro správnou manipulaci a uložení takových dat.

\n{3}{Utils.py}
Třída \verb|Utils| obsahuje pouze pomocné funkce, které jsou často volány a zlepšují tím přehlednost zdrojového kódu.

\n{2}{Složka Pages}
Složka obsahuje tři třídy, které představují konkrétní stránky ve webovém prohlížeči. Každá třída obsahuje selektory k vyhledávání elementů na stránce. Třídy také obsahují funkce, které s těmito elementy pracují. Jedná se o použití návrhového vzoru Page Object Model (\ref{n:pom}), ve kterém je webová stránka v prohlížeči reprezentována třídou s atributy ve zdrojovém kódu. 

\n{3}{LoginUtbPage.py}
Třída \verb|LoginUtbPage| představuje webovou stránku pro přihlášení do služby Shibboleth. Jednotlivé atributy jsou vytvořeny na základě selektorů k elementům na webové stránce. 
Atributy jsou: 
\begin{itemize}
    \item \verb|login_username_input(self)| - atribut, který slouží pro lokalizaci textového pole pro zadání přihlašovacího uživatelského jména
    \item \verb|login_password_input(self)| - atribut, který slouží pro lokalizaci textového pole pro zadání přihlašovacího uživatelského hesla 
    \item \verb|login_button(self)| - atribut, který lokalizuje tlačítko pro přihlášení
    \item \verb|gdpr_confirm_button(self)| - atribut, který lokalizuje tlačítko pro souhlas se zpracováním osobních údajů
\end{itemize}
Funkce třídy \verb|LoginUtbPage|: 
\begin{itemize}
    \item \verb|login_and_accept_gdpr(self)| - funkce, která za použití atributů uživatelského jména a hesla vyplní textová pole pro přihlášení a potvrdí akci kliknutím na tlačítko \verb|Přihlásit se|
\end{itemize}

\n{3}{ProxyPage.py}
Třída slouží pro reprezentaci webové stránky, která je používána pro přihlašování uživatele přes PROXY UTB.
Atributy jsou: 
\begin{itemize}
    \item \verb|shibboleth_button(self)| - atribut reprezentující tlačítko pro přihlášení přes Shibboleth
    \item \verb|ldap_button(self)| - atribut reprezentující tlačítko pro přihlášení přes LDAP
    \item \verb|login_ldap_button(self)| - atribut reprezentující tlačítko pro potvrzení přihlášení
    \item \verb|login_ldap_username_input(self)| - atribut reprezentující textové pole pro zadání uživatelského jména
    \item \verb|login_ldap_password_input(self)| - atribut reprezentující textové pole pro zadání uživatelského hesla
\end{itemize}

Funkce třídy \verb|ProxyPage|: 
\begin{itemize}
    \item \verb|navigate(self, link_native_home)| - funkce, která se naviguje na webovou stránku přes URL adresu. URL adresa je vytvořena spojením PROXY URL s URL dané služby
    \item \verb|login_shibboleth(self)| - funkce provádějící přihlášení přes Shibboleth
    \item \verb|login_ldap(self)| - funkce provádějící přihlášení přes LDAP
\end{itemize}

\n{3}{ClarivatePage.py}
Existuje pár služeb s elektronickými zdroji, do kterých se přihlašuje přes poskytovatele Clarivate. Ve třídě \verb|ClarivatePage| jsou elementy a funkce, které s takovou webovou stránku pracují.
Atributy jsou: 
\begin{itemize}
    \item \verb|select_institution_combobox(self)| - element, pomocí kterého se vybírá typ přihlášení
    \item \verb|czech_academic_value(self)| - element představující hodnotu v kombinovaném poli
    \item \verb|go_to_institution_button(self)| - atribut reprezentující tlačítko pro přihlášení
    \item \verb|bata_input(self)| - atribut reprezentující textové pole
\end{itemize}
Funkce třídy \verb|ClarivatePage|: 
\begin{itemize}
    \item \verb|login_via_clarivate(self)| - metoda, která vybere typ přihlášení, vyplní hodnoty a klikne na tlačítko pro přihlášení
    \item \verb|assert_login(self)| - metoda, která kontroluje úspěšné přihlášení do služby
\end{itemize}

\newpage
\n{2}{Složka Tests}
Složka \verb|Tests| obsahuje: 
\begin{itemize} \label{list:base}
    \item Složku \verb|Services| - obsahuje automatické testy, které testují dostupnost přihlášení do služby poskytující elektronické zdroje
    \item Test \verb|CheckListOfServices()| - test, který kontroluje seznam aktuálních elektronických zdrojů získaných z knihovny UTB se seznamem služeb, které jsou pokryté automatickými testy. Jakmile dojde ke změně seznamu služeb Knihovny UTB, automat zahlásí chybu.
    \item Bázovou třídu \verb|TestBase(unittest.TestCase)| - bázová třída slouží umístění společných funkcí a elementů, které jsou využívány v jednotlivých automatech testující přihlášení.
\end{itemize}

\n{3}{TestBase.py}
Bázová třída, ze které dědí každý automatický test. Obsahuje funkce a atributy, které jsou využívány všemi automaty. Funkce jsou:
\begin{itemize}
    \item \verb|setup(self, page, source_id)| - jde o funkci, která se provolá před spuštěním automatického testu. Jejím účelem je načtení dat a příprava prostředí pro automat.
    \item \verb|get_e_source(self, source_id)| - metoda, která na základě identifikátoru elektronického zdroje načte informace o daném zdroji
    \item \verb|wayfless(self)| - funkce, která obsahuje společnou funkcionalitu pro testování přihlášení způsobem WAYFless 
    \item \verb|proxy_shibboleth(self)| - funkce, která obsahuje společnou funkcionalitu pro testování přihlášení přes PROXY způsobem Shibboleth
    \item \verb|proxy_ldap(self)| - funkce, která obsahuje společnou funkcionalitu pro testování přihlášení přes PROXY způsobem LDAP
    \item \verb|wayf(self)| - funkce, která obsahuje společnou funkcionalitu pro testování přihlášení způsobem WAYF 
    \item \verb|vpn(self)| - funkce, která obsahuje společnou funkcionalitu pro testování přihlášení přes VPN. 
\end{itemize}


\n{3}{Automatický test}
V rámci jednoho automatického testu se testuje jedna služba, která poskytuje elektronické zdroje. Každý elektronický zdroj obsahuje jedinečný identifikátor (například \verb|source_id=UTB00015|), pod kterým je uveden na portále Knihovny UTB. Identifikátor je ručně přidán každému automatu, aby došlo k rozpoznání elektronického zdroje. Automat je složen z funkcí:
\begin{itemize} \label{list:automat}
    \item \verb|setup(self, page: Page)| - jde o funkci, která se provolá před spuštěním automatického testu. Metoda v sobě obsahuje volání \verb|setup(self, page, source_id)| z bázové třídy. V automatu je předán pouze parametr \verb|source_id|.
    \item \verb|test_wayfless(self)| - testovací metoda, která volá funkci \verb|wayfless(self)| z bázové třídy a verifikuje úspěšné přihlášení do služby způsobem WAYFless
    \item \verb|test_proxy_shibboleth(self)| - testovací metoda, která volá funkci \newline \verb|proxy_shibboleth(self)| z bázové třídy a verifikuje úspěšné přihlášení do služby přes PROXY s možností Shibboleth
    \item \verb|test_proxy_ldap(self)| - testovací metoda, která volá funkci \verb|proxy_ldap(self)| z bázové třídy a verifikuje úspěšné přihlášení do služby přes PROXY s možností LDAP
    \item \verb|test_wayf(self)| - testovací metoda, která volá funkci \verb|wayf(self)| z bázové třídy a verifikuje úspěšné přihlášení do služby způsobem WAYF
    \item \verb|test_vpn(self)| - testovací metoda, která volá funkci \verb|wayf(self)| z bázové třídy a verifikuje úspěšné přihlášení do služby přes VPN
    \item \verb|assert_access(self)| - assertovací funkce, která obsahuje kontrolu přístupu na službu po úspěšném přihlášení
\end{itemize}


\n{2}{Jak rozšířit testovací aplikaci o další testy}
Testovací aplikace je navržena tak, aby vytvoření nového automatického testu dokázal i zaškolený pracovník knihovny UTB. V případě přidání nové služby poskytující elektronické zdroje je uživatel schopen vytvořit snadno nový automatický skript pro tuto službu. Automat bude přidán do testovací sady a spouštěn stejným způsobem jako dosavadní automaty.

\n{3}{Vytvoření souboru}
Prvním krokem k vytvoření nového automatu je vytvořit nový skriptovací soubor s koncovkou \verb|.py| ve složce \verb|Test/Services|. Soubor je vhodné pojmenovat stejným názvem jako se jmenuje služba, která bude automatem testována. Pro identifikaci automatu pluginem Pytest je nutné, aby název souboru začínal anebo končil slovem \verb|test|. Například název souboru pro automat testující službu Springer Link je \verb|springer_link_test.py|.

\n{3}{Vytvoření třídy s metodou setup()}
Do nově vytvořeného skriptovacím souboru uživatel definuje třídu, která bude mít název testované služby. Třída bude dědit z bázové třídy \verb|TestBase| (\ref{list:base}). Uživatel začne implementací první metody s název \verb|setup|, která provádí nastavení automatu. Uživatel pomocí dekorátoru \verb|@pytest.fixture(autouse=True)| označí tuto metodu, aby se volala jako první před spuštěním automatu. Metoda \verb|setup| obsahuje pouze volání stejnojmenné metody z bázové třídy, ve které je pomocí parametru předáno \verb|source_id|. Hodnota \verb|source_id| obsahuje identifikátor, kterým je označena každá služba na portále e-zdroje knihovny UTB. 

\begin{figure}[t]
\begin{verbatim}
class SpringerLink(TestBase):

    @pytest.fixture(autouse=True)
    def setup(self, page: Page):
        super(SpringerLink, self).setup(page, "UTB00001")
\end{verbatim}
\caption{Třída s metodou setup()}
\label{code:setup}
\end{figure}

\n{3}{Vytvoření testovacích metod}
Automat testuje různé typy přihlášení do služby, která poskytuje elektronické zdroje. Ne všechny služby podporují všechny typy přihlášení (WAYF, WAYFless, Proxy). Uživatel v automatu definuje takové testovací metody, které jsou validní pro danou službu. Případně může využít dekorátor \verb|@pytest.mark.skip(reason="not working in WAYF")| pro přeskočení testovací metody v testovací sadě. 

U služby, která podporuje všechny typy přihlášení, uživatel definuje všechny testovací metody (\ref{list:automat}). Testovací metody \verb|test_wayfless|, \verb|test_proxy_shibboleth| a \verb|test_proxy_ldap| obsahují pouze volání stejnojmenných metod z bázové třídy a kontrolující metodu úspěšného přihlášení. 

\begin{figure}[h]
\begin{verbatim}
def test_wayfless(self):
    super(SpringerLink, self).wayfless()
    self.assert_access()
\end{verbatim}
\caption{Testovací metoda pro typ přihlášení WAYFless}
\label{code:wayfless}
\end{figure}

\begin{figure}[h]
\begin{verbatim}
def test_proxy_shibboleth(self):
    super(SpringerLink, self).proxy_shibboleth()
    self.assert_access()
\end{verbatim}
\caption{Testovací metoda pro typ přihlášení PROXY Shibboleth}
\label{code:proxyshib}
\end{figure}

\begin{figure}[h]
\begin{verbatim}
def test_proxy_ldap(self):
    super(SpringerLink, self).proxy_ldap()
    self.assert_access()
\end{verbatim}
\caption{Testovací metoda pro typ přihlášení PROXY LDAP}
\label{code:proxyldap}
\end{figure}

Testovací metoda \verb|test_vpn| kontrolující přihlášení do služby přes VPN obsahuje opět volání bázové metody, URL navigaci na webovou stránku služby a volání metody pro kontrolu přihlášení. Testovací metoda je označena dekorátorem \verb|@pytest.mark.vpn|, který zařazuje test do kategorie VPN. Uživatel je potom schopný spustit automaty pouze s touhle kategorií.

\begin{figure}[h]
\begin{verbatim}
@pytest.mark.vpn
def test_vpn(self):
    super(SpringerLink, self).vpn()
    self.page.goto(self.e_source.link_native_home)
    self.assert_access()
\end{verbatim}
\caption{Testovací metoda pro přihlášení přes VPN}
\label{code:vpn}
\end{figure}


\begin{figure}[h]
\begin{verbatim}
def test_wayf(self):
    super(SpringerLink, self).wayf()
    self.page.goto(self.e_source.link_native_home)
    self.page.click("text=» Sign up / Log in")
    self.page.click("text=Access via your institution")
    self.page.fill("input[name=\"search\"]", "bata")
    self.page.press("input[name=\"search\"]", "Enter")
    with self.page.expect_navigation():
        self.page.click("text=Tomas Bata University in Zlín")
    login_page = LoginPage(self.page, self.data)
    login_page.login_and_accept_gdpr()
    self.assert_access()
\end{verbatim}
\caption{Testovací metoda pro typ přihlášení WAYF do služby Springer Link}
\label{code:wayf}
\end{figure}

Nejsložitější pro uživatele je definice testovací metody \verb|test_wayf|, protože průběh takového testu je velmi variabilní. Základ testovací metody je stejný a to volání stejnojmenné metody z bázové třídy. Po navigaci automatu na webovou stránku musí automat provést přihlášení do služby. Bohužel obsah HTML stránky je jiný pro každou službu podporující WAYF a nelze definovat takové obecné lokátory pro elementy, které by platily ve všech službách. Uživatel tedy musí napsat lokátory a testovací kroky do automatu, aby docílil automatického přihlášení přes WAYF. Testovací kroky s lokátory může uživatel vytvořit sám anebo použít nástroj od Playwright pro generování příkazů (\ref{n:generovani}). Ukázka testovací metody WAYF pro službu Springer Link je na obrázku \ref{code:wayf}.

\n{3}{Vytvoření metody pro kontrolu přihlášení}
Posledním krokem pro napsání automatického skriptu je definování metody, která bude provádět kontrolu přihlášení do služby. V testovací aplikaci je název této metody \verb|assert_access| obsažen v každém automatu za účelem lepší čitelnosti zdrojového kódu. V těle metody je volána assertovací funkce, která kontroluje požadovaný výsledek s aktuálním. Většinou se jedná o kontrolu konkrétního textu, který je zobrazen po přihlášení. Příklad pro službu Springer Link je na obrázku \ref{code:assert}.

\obr{Ukázka použití code generátoru}{fig:codegen}{1}{graphics/codegen.png}

\begin{figure}[h]
\begin{verbatim}
def assert_access(self):
    self.asserts.check_inner_text("//*[@id=\"diagnostic-info\"]",
        "the Library of Tomas Bata University in Zlin")
\end{verbatim}
\caption{Kontrolující metoda pro službu Springer Link}
\label{code:assert}
\end{figure}

\newpage
\n{2}{Generátor testovacích příkazů}\label{n:generovani}
Playwright nabízí nástroj, pomocí kterého uživatel může generovat testovací příkazy do zdrojového kódu. V případě testovací aplikace uživatel musí generovat příkazy do programovacího jazyka Python. Uživatel v příkazové řádce zavolá příkaz spolu s webovou stránku, kterou má webový prohlížeč načíst. Příkaz je ukázán na obrázku \ref{code:codegen}. Nástroj otevře okno Playwright Inspector, ve kterém je vytvořen základní automatický skript. Spolu s tímto oknem je otevřen i webový prohlížeč, ve kterém je načtena webová stránka zadána v příkazu. Uživatel svými akcemi s webovou stránkou generuje zdrojový kód, který je postupně přidáván do automatu v oknu Playwright Inspector. Například pokud klikne uživatel na tlačítko nebo do textového pole, vygeneruje se kód v Pythonu \verb|page.click("input[name=\"userid\"]")|. Takový kód je potom zkopírován do testovací aplikace do automatického skriptu. Pokud je spuštěn nástroj Playwright Inspector, uživatel při najetí myši na element také zjistí jeho lokátor, pod kterým lze daný element hledat na webové stránce. Ukázka použití nástroje Playwright Inspector a také zjištění lokátoru pro textové pole se nachází na obrázku \ref{fig:codegen}.

\begin{figure}[h]
\begin{verbatim}
npx playwright codegen https://www.acs.org/content/acs/en.html
\end{verbatim}
\caption{Příkaz pro otevření code generátoru}
\label{code:codegen}
\end{figure}

% ============================================================================ %
\nn{Závěr}
Ve spolupráci s knihovnou UTB byla vytvořena testovací aplikace se sadou automatických testů, které kontinuálně testují proces přihlašování do služeb poskytující elektronické zdroje. Seznam elektronických zdrojů je uveden na portále e-zdroje, který spravuje knihovna Univerzity Tomáše Bati ve Zlíně. Testy pro kontrolu přihlašování do služeb používají grafické uživatelské rozhraní ve webovém prohlížeči. Verifikují různé typy přihlášení, mezi které patří typ WAYF, WAYFless, PROXY a přihlášení pod univerzitní IP adresou přes VPN. Díky kontinuálnímu testování budou mít správci portálu e-zdroje přehled o dostupnosti jednotlivých zdrojů a v případě problémů budou moct rychle reagovat.

Automaty byly navrženy tak, aby jejich správa a případně rozšíření bylo co nejjednodušší. Byl vybrán open-source nástroj Playwright, který poskytuje podporu při automatizaci testů. Disponuje různými nástroji a pluginy, díky kterým je vytváření, spouštění a údržba automatů snadná. Testovací aplikace umožňuje pomocí konfiguračních souborů spustit automaty v různých režimech a v různých webových prohlížečích. Aplikace je také spustitelná ve všech operačních systémech.

Testovací sada automatů bude pravidelně spouštěna po určitých intervalech. Aplikace poběží na linuxovém stroji a plánování bude zajištěno linuxovým nástrojem cron. Po skončení běhu testovací sady budou výsledky automatů shromážděny a poslány elektronickou poštou. Email bude obsahovat seznam aktuálně neúspěšných automatů a bude připojena příloha v podobě ZIP souboru. ZIP soubor obsahuje výsledky automatů ve formě HTML spolu se záznamem obrazovky u neúspěšných testů.
% ============================================================================ %