UNICORN COLLEGE. Bakalářská práce

Transkript

1 UNICORN COLLEGE Katedra informačních technologií Bakalářská práce Možnosti a způsoby automatického testování aplikací vyvíjených na platformě Unicorn Universe Autor BP: Ladislav Kšír Vedoucí BP: Mgr. Jan Kupka 2016 Praha

2 Čestné prohlášení Prohlašuji, že jsem svou bakalářskou práci na téma Možnosti a způsoby automatického testování aplikací vyvíjených na platformě Unicorn Universe vypracoval samostatně pod vedením vedoucího bakalářské práce a s použitím výhradně odborné literatury a dalších informačních zdrojů, které jsou v práci citovány a které jsou také uvedeny v seznamu literatury a použitých zdrojů. Jako autor této bakalářské práce dále prohlašuji, že v souvislosti s jejím vytvořením jsem neporušil autorská práva třetích osob a jsem si plně vědom následků porušení ustanovení 11 a následujících autorského zákona č. 121/2000 Sb. V Praze dne. (Ladislav Kšír)

3 Poděkování Děkuji vedoucímu bakalářské práce Mgr. Janu Kupkovi za účinnou metodickou, pedagogickou a odbornou pomoc a další cenné rady při zpracování mé bakalářské práce.

4

5

6 Možnosti a způsoby automatického testování aplikací vyvíjených na platformě Unicorn Universe Possibilities and different ways of the automated software testing for the applications developed on the Unicorn Universe platform 6

7 Abstrakt Vývoj aplikací v cloudovém prostředí přináší nečekané problémy a má také svá specifika. To se týká i testování, jakožto významné složky vývoje softwaru. Další výzvy pak přináší jedna z forem testování, a tou je testování za využití různých stupňů automatizace. Takové testování, i přes vyšší počáteční náklady, může významným způsobem zvýšit výslednou kvalitu vytvářeného softwaru, a zároveň snížit celkové náklady na vývoj. Tato práce si klade za cíl analyzovat současný stav testování aplikací vyvíjených na cloudouvé platformě Unicorn Universe a navrhnout způsoby automatizace. Validita řešení je ověřena na jedné vybrané aplikaci. Klíčová slova: Automatické testování, Vývoj softwaru, Unicorn Universe, Cloud, Ruby, Testování softwaru, Řízení kvality Abstract Software development in a cloud-based environment raises unexpected problems, and is specific in its own ways. Same applies on software testing, as an important part of software development. Automated software testing, which is testing which uses various degrees of automation, brings even more difficulties. Automated software testing, can significantly decrease cost and improve the quality of software, even though it brings additional costs sometimes. The purpose of this work is to analyse current state of testing for applications developen for cloud-based platform, Unicorn Universe. It also aims to propose possible ways, how to automate parts of testing process. After that, were validated on one selected application. Keywords: Quality Assurance, Software Testing, Cloud, Ruby, Unicorn Universe, Software Development, Automated Software Testing 7

8 Obsah 1. Testování softwaru Pojem testování Motivace k testování Základní pojmy Statické a dynamické testování Testy splněním a testy selháním Testy podle znalosti fungování systému Invazivní a neinvazivní testy Úrovně a typy testů Testování jednotek Smoke testy Systémové testy Akceptační testy Automatické testování Výhody a nevýhody automatického testování Mýty o automatickém testování Techniky automatizovaného testování Automatické testy v kontextu uuapps Platforma Unicorn Universe Operating System Vývoj aplikací pro Unicorn Universe Specifika aplikací vyvíjených nad platformou Unicorn Universe Automatické testování uuapps Současný stav testování uuapps Výběr aplikace pro realizaci testování Vlastní realizace testů Závěr Seznam použitých zdrojů Seznam použitých obrázků Seznam použitých tabulek

9 Úvod Testování softwaru je významnou a bohužel často zanedbávanou součástí procesu vývoje softwaru. Kvalitní testování je nezbytné. Zároveň bývá velmi nákladné, ať už svou časovou náročností, nároky na lidské zdroje nebo nároky na technologické vybavení. Jedním ze způsobů, jak tyto náklady snížit, je využití automatického testování. A právě automatickému testování, zvláště pak pro platformu Unicorn Universe Operating System (dále jen uuos nebo jinak označovanou Unicorn Universe), se budu ve své práci věnovat. Nad platformou uuos, kterou blíže popíši v kapitole 2.1, jsou vyvíjeny a provozovány aplikace nazývané Unicorn Universe Applications (dále jen uuapps). Jejich formální definice zní Unicorn Universe Applications označuje sadu mnoha různých řešení vytvořených na platformě Unicorn Universe. 1 V počátcích fungování platformy se jednalo o jednoduché aplikace, u kterých byl velmi krátký cyklus vývoje a testování. Jak uvádí dokumentace k vývoji: Vytvoření aplikace pomocí technologie uuos je velice jednoduché a zabere pouhých pár minut. Nepotřebujete znát složité technologie, stačí mít základní znalost programování a základní přehled v principech uuos. 2 Výše uvedené jistě platí: jsou uuapps, jejichž implementace je velmi rychlá, a jejichž komplexnější testování by bylo delší a dražší než samotná jejich implementace. Spolu s rozvojem technologie uuos a jejích možností vzrůstala složitost aplikací, které byly pro platformu vytvářeny. V případě těch větších a složitějších uuapps se vývoj pohybuje v řádu měsíců a průběžné zajišťování jejich kvality, mimo jiné testováním, tak má svůj velký význam. V současné době jsou možnosti testování, a zvláště pak možnosti automatického testování těchto aplikací velmi omezené. Testování ve většině případů probíhá tak, že po implementaci dané části aplikace je tato část otestována ručně způsobem, že tester 1 Unicorn Universe Applications [online]. Praha: Unicorn Universe. [cit ] Dostupné z URL: < 2 Úvod do vývoje aplikací v Unicorn Universe [online]. Praha: Unicorn Universe. [cit ] Unicorn Universe artefakt: <VPH-BT: >. 9

10 reálně aplikaci používá a zaznamenává případné nesoulady specifikace a implementovaného řešení. Protože uuos je svým způsobem unikátní technologie, testování aplikací pro tuto platformu přináší nové a často netriviální problémy. V případě automatického testování je pak celá problematika ještě složitější. Na druhé straně využití automatických testů může být přínosem, zejména pro možné snížení nákladů na vývoj aplikace a zkrácení doby implementace. Ve své práci se budu věnovat možnostem a způsobům automatického testování, které by mohly být využitelné v procesu vývoje aplikací pro technologii uuos. Cílem je navrhnout způsob, pomocí kterého bude možné v daleko větší míře využít automatických testů. 10

11 1. Testování softwaru 1.1 Pojem testování Testování softwaru je velmi široký pojem, zahrnuje množství procesů a metodik testování. Jako pojem samotný má velké množství významů. Na začátek vymezím, jak pojem testování softwaru chápu já a jak ho ve své bakalářské práci budu používat. Při své práci vývojáře se s testováním setkávám každý den, je to významná součást práce mého týmu. V našem pojetí je testování, zjednodušeně řečeno, ověření toho, že námi implementovaný produkt bude odpovídat požadavkům zákazníka. Požadavky lze vymezit například takto: Požadavky vyjadřují přání zákazníka, respektive budoucího uživatele. Popisují určité funkce či vlastnosti, které od vytvářeného systému očekávají. 3 Podmínka, aby software odpovídal požadavkům zákazníka, je bohužel zcela nedostatečná. Vysvětlení je celkem jednoduché a lze se na něj podívat z různých pohledů. Pokud se podíváme na definice softwarové chyby podle Pattona: hovoříme o softwarové chybě, pokud je splněna jedna nebo více následujících podmínek (pravidel): 1) Software nedělá něco, co by podle specifikace produktu dělat měl. 2) Software dělá něco, co by podle údajů specifikace produktu dělat neměl. 3) Software dělá něco, o čem se produktová specifikace nezmiňuje. 4) Software nedělá něco, o čem se produktová specifikace nezmiňuje, ale měla by se zmiňovat. 5) Software je obtížně srozumitelný, těžko se s ním pracuje, je pomalý, nebo podle názoru testera softwaru jej koncový uživatel nebude považovat za správný. 4 Z této definice je vidět, že chyby typu 3, 4 a 5 se mohou vyskytovat i v řešení, které naprosto přesně odpovídá požadavkům. Ale proč vlastně k tomuto problému dochází? Patton uvádí: U softwarových chyb je příčinou číslo 1 specifikace. 5 3 ROUDENSKÝ, Petr, HAVLÍČKOVÁ, Anna: Řízení kvality softwaru. 1. vydání, Computer Press, 2013, ISBN PATTON, Ron: Testování softwaru. 1. vydání, Computer Press, 2002, ISBN

12 Specifikace Návrh Programový kód Jiné Obrázek 1: Příčiny chyb podle R. Pattona, vlastní zpracování Naopak Sakthi Kumaresh ve svém příspěvku, který zkoumá výskyt chyb v pěti různých projektech, uvádí Ukazuje se, že 70 až 80 procent chyb je způsobených špatnou implementací. 6 S ohledem na specifika automatických testů, které už z principu nemohou odhalovat chybnou specifikaci, ani chyby, které ze specifikace nevyplývají, se dále budu držet pouze prvních dvou případů z výše uvedené definice. 1.2 Motivace k testování Proč vlastně software testovat? Důvodů je celá řada. Zřejmě každého napadne, že prvním důvodem je snaha zjistit, zda software vůbec funguje. Zda je software funkční se dá ověřit snadno stačí jej spustit. Samotný fakt, že aplikaci lze spustit, ale vůbec nevypovídá o její kvalitě. Vladimír Kovář ve své disertační práci 7 uvádí 10+1 vlastností dobrého systému, z nichž některé se přímo vztahují k problematice testování. 5 PATTON, Ron: Testování softwaru. 1. vydání, Computer Press, 2002, ISBN KUMARESH, Sakthi: Defect Analysis and Prevention for Software Process Quality Improvement, International Journal of Computer Applications, listopad 2010, roč. 8, č. 7 12

13 Obrázek 2: 10+1 vlastností dobrého systému Kvalitní testování podle mne přispívá k naplnění zejména následujících bodů: Spolehlivý systém je systém, který pro dané vstupy podává opakovaně stejné výsledky. Spolehlivost, tak jak je zde definovaná, jde otestovat. A dál, co by mohlo být vhodnější oblastí pro automatizaci, než opakující se činnosti, respektive testy, které ověřují správnost těchto činností? Ergonomický systém je uživatelsky přívětivý. Neobsahuje žádnou chybu pátého typu podle toho, jak definuje softwarovou chybu Patton. Podrobněji tyto definice rozvádím v kapitole 1.1. Stabilní. Stabilitu systému lze ověřit testováním, příkladem může být zátěžový test. Bezpečný systém je zajištěn proti vnějším i vnitřním negativním vlivům. I toto lze testovat, je to náplní bezpečnostních testů. Z výše uvedeného je zřejmé, že testování může zásadně zvýšit výslednou kvalitu softwaru. Samozřejmě za předpokladu, že výsledky testování budou zohledněny a nalezené chyby budou opraveny. Samotné vykonání testu principiálně nemůže kvalitu zvýšit. Není však reálné, aby software neobsahoval chyby žádné, dokonce jej nelze ani úplně a bezezbytku otestovat. Na to poukazuje i jeden ze základních axiomů testování: Žádný netriviální program nelze otestovat úplně. 8 7 KOVÁŘ, Vladimír: Unicorn Enterprise System Powered Company: Metodika pro řízení podniku a organizací s přímou podporou informačního systému. Praha, Dizertační práce (Ph.D.). Univerzita Hradec Králové, Fakulta informatiky a managementu, Katedra informatiky a kvalitativních metod. 8 ROUDENSKÝ, Petr, HAVLÍČKOVÁ, Anna: Řízení kvality softwaru. 1. vydání, Computer Press, 2013, ISBN

14 Je nutné si uvědomit, že všeobjímající otestování by bylo časově a finančně náročné, proto jej stačí otestovat v rozumné a efektivní míře. K tomu autoři Stephens, Rosenberg v knize Testování softwaru řízené návrhem uvádějí: Úplnost v testování není o všeobecném pokrytí kódu, ale o zajištění, aby byla adekvátně otestována klíčová místa v kódu (logické softwarové funkce). 9 Stručně řečeno, testování má za úkol hledat chyby. Zároveň, pokud má být testování kvalitní, musí tyto chyby najít včas. Patton uvádí, že Cílem softwarového testera je vyhledávat chyby, vyhledat je co nejdříve a zajistit jejich nápravu. 10 Proč včas? Nestačí otestovat hotový software a odstranit nalezené chyby? Nestačí. Platí totiž, že náklady na odstranění chyby jsou přímo úměrné tomu, v jaké fázi vývoje byla chyba nalezena. Opravit chybu nalezenou například až v akceptačních testech, může být několikanásobně dražší, než opravit stejnou chybu nalezenou na začátku implementačního procesu. Tento vztah zachycují autoři Roudenský a Havlíčková 11 v následujícím grafu: Obrázek 3: Náklady na odstranění chyby, vlastní zpracování 9 STEPHENS, Matt, ROSENBERG, Doug: Testování softwaru řízené návrhem. 1. vydání, Computer Press, 2011, ISBN PATTON, Ron: Testování softwaru. 1. vydání, Computer Press, 2002, ISBN , str ROUDENSKÝ, Petr, HAVLÍČKOVÁ, Anna: Řízení kvality softwaru. 1. vydání, Computer Press, 2013, ISBN

15 Zároveň platí, že samotná funkčnost a relativní bezchybnost nestačí. Ano, software musí fungovat, ale musí fungovat přesně a správně. Může se zdát, že pojmy přesně a správně vyjadřují to stejné, ale není tomu tak. Software může fungovat přesně, ale ne správně, a platí to i naopak. Správnost znamená, že program provádí se vstupy správné operace, ale jejich výsledek není tak přesný, jaký by měl být. Přesnost znamená, že program vrací přesné výsledky, bez ohledu na správnost provedených operací. Mějme metodu, která přijímá dva parametry, čísla x a y. Úkolem této metody je vrátit jejich součet. Pokud například pro čísla 4.0 a vrátí výsledek 10, pak funguje správně. Použila správnou matematickou operaci, čísla sečetla, ale výsledek není úplně přesný. Pokud pro stejná čísla vrátí výsledek , pak funguje přesně, ale ne správně. Vrátila totiž naprosto přesně jejich součin, přičemž měla vrátit jejich součet. Metoda funguje správně a přesně až v okamžiku, kdy výsledek jejího volání je Ověření toho, že software funguje přesně a správně, je právě jedním z cílů testování. Důvodem pro dostatečné testování může být jistota, že výsledný software bude za všech okolností fungovat správně. Vzpomínám si na svou první přednášku o programování, kde nám lektor říkal Testujte! Nikdy a nic mi nezpůsobilo tolik bezesných nocí, jako spuštění funkčního, ale důkladně neotestovaného e-shopu. 1.3 Základní pojmy V kapitole výše jsem stručně představil oblast testování softwaru. Dále vysvětlím některé základní pojmy z problematiky testování Statické a dynamické testování Pod pojmem statické testování se skrývá celá řada procesů a činností, které mají společného jmenovatele není pro ně zapotřebí funkční a spustitelný produkt, respektive 15

16 jeho část. Může jít o zkoumání specifikace, návrhu implementované aplikace, ale i o zkoumání již vytvořeného kódu, ovšem bez jeho faktického spuštění. Patří sem například určení, zda jednotliví programátoři dodržují dohodnuté konvence a zda je jejich kód přehledný. Statické testování je možné provádět už od samotného počátku projektu, aniž by byl napsán jediný řádek kódu. Tento způsob není předmětem mé práce a tak se mu nebudu dále věnovat. Dynamické testování pak odpovídá obecné představě o testování. Testování lze definovat jako proces řízeného spouštění softwarového produktu s cílem zjistit, zda splňuje specifikované či implicitní potřeby uživatelů. 12 Skoro to stejné, i když jednodušeji, říká definice: Dynamické testování se nám nejspíše při vyslovení pojmu testování vybaví jako první software spustíme a pracujeme s ním. Ze své podstaty jsou dynamické testy používány až v pozdějších fázích vývoje, kdy je k dispozici ucelený a spustitelný blok kódu, pokud ne přímo spustitelný prototyp Testy splněním a testy selháním Testy, ať už prováděné manuálně nebo automaticky, lze rozdělit do dvou základních kategorií: testy splněním a testy selháním. U testu splněním, zjednodušeně řečeno, testujeme, že se systém, pokud jsou mu poskytnuty správné vstupy, chová očekáváným způsobem a zda toto jeho chování odpovídá specifikaci. U tohoto typu testů není cílem záměrně vyvolat chybu nebo uvést systém do nestabilního stavu. Také není cílem zkoušet, jaké jsou hranice systému, co ještě zvládne a co už ne. Testování splněním převažuje v začátku, a také ve smoke testech, o kterých píšu níže. 12 ROUDENSKÝ, Petr, HAVLÍČKOVÁ, Anna: Řízení kvality softwaru. 1. vydání, Computer Press, 2013, ISBN

17 Přesným opakem výše uvedeného jsou testy selháním. Jejich cílem je prozkoumat, jak se systém bude chovat v situaci, kdy jsou mu poskytnuty chybné údaje, nelze se připojit k databázi nebo je používán neočekávaným způsobem Testy podle znalosti fungování systému Podle toho, zda při testování máme k dispozici informace o vnitřním fungování systému, například ve formě zdrojových kódů, rozlišujeme testy černé a testy bílé skřínky. Pokud znalosti o vnitřním fungování systému nemáme, můžeme si software představit jako černou skřínku, která nám neznámým způsobem přeměňuje vstupy ve výstupy. O testech bílé skřínky naopak mluvíme v situaci, kdy víme, jak přesně software funguje. Například jakým způsobem provádí výpočty, v jaké podobě ukládá data, nebo jakým způsobem komunikuje se svým okolím Invazivní a neinvazivní testy Tyto dva přístupy k testování se liší ve v tom, zda zkoumaný software ovlivňují nebo pouze sledují jeho chování. Doslovnou definici těchto typů uvádí například Patton: Jestliže určitý nástroj slouží pouze k monitorování a zkoumání softwaru, aniž by jej jakkoliv modifikoval, považujeme jej za neinvazivní. Pokud ale nástroj jakkoli kód programu modifikuje, nebo pokud libovolným způsobem manipuluje s jeho operačním prostředím, jedná se o invazivní nástroj PATTON, Ron: Testování softwaru. 1. vydání, Computer Press, 2002, ISBN

18 1.4 Úrovně a typy testů Je celkem logické, že v různých fázích vývoje se ve větší či menší míře využívají různé úrovně testování. K ukázce může sloužit V model 14, který zobrazuje právě vztah mezi fázemi vývoje softwaru a úrovněmi testování. Je z něj dobře patrné, jaké nachází uplatnění v jednotlivých fázích vývoje Testování jednotek Obrázek 4: V Model 14 V případě testování jednotek jde o testování nejmenších testovatelných celků. V objektově orientovaném programování jde o metody, třídy a moduly, které je třeba otestovat izolovaně jako samostatné jednotky. Často je třeba využít zástupné objekty, nazývané mock a stub objekty. Bližší pohled na jejich význam podává Martin Fowler, ikona vývoje software, ve svém článku Mocks Aren't Stubs 15 Mock objekt, česky maketa, poskytuje předem definované odpovědi na stanovené volání. Například ověřují a zaznamenávají, že metoda byla zavolána s příslušným počtem parametrů, a také že jednotlivé parametry jsou správným datovým typem. Na druhé 14 Using V Models for Testing [online]. Carnegie Mellon University, Pittsburgh, U.S.A. [cit ] Dostupné z URL: < 15 FOWLER, Martin: Mocks Aren't Stubs [online]. Chicago, U.S.A. [cit ]. Dostupné z URL: < 18

19 straně stub objekt, česky někdy nazýván pahýl, je falešný objekt, který umožňuje vykonat test. Jedná se objekt, který může být zavolán, ale už neověřuje validitu volání. V některých agilních metodikách, například v metodice Extrémní programování (XP), jsou jednotkové testy implementovány dříve než samotné testované jednotky. Takový způsob vývoje se nazývá programování řízené testy, anglicky Test Driven Development. Jak může vypadat vývoj softwaru, pokud je řízen testy, ukazuje William Wake ve své knize Extreme Programming Explored: Cyklus testování/kódování Napiš jeden test. Spusť test. Nemělo by to jít, protože jsi ještě nenapsal žádný testovatelný kód Napiš minimální část kódu nutnou ke spuštění testu. Spusť test a sleduj, jak selže. Napiš další část kódu, aby test prošel. Spusť test a sleduj, jak je splněn. Uprav kód, pro přehlednost a pro odstranění nadbytečností. Opakuj shora Integrační testy Výše jsem uvedl, že jednotkové testování zkoumá funkčnost izolovaných částí. V okamžiku, kdy jsou k dispozici alespoň dvě části, které úspěšně prošly jednotkovými testy, lze přistoupit k další úrovni testování, k integračním testům. Takové testy zkoumají, jak spolu jednotlivé součásti spolupracují, a hledají chyby způsobené jejich integrací. Nezřídka se totiž stává, že jednotky otestované izolovaně a v simulovaném prostředí po připojení do systému nefungují správně. 16 WAKE, William: Extreme Programming Explored. 1. vydání, Addison-Wesley Professional, 2001, ISBN

20 Roudenský, Havlíčková uvádějí čtyři základný přístupy k integračnímu testování. Jsou to Velký třesk (big bang), přístup shora-dolů (top-down), přístup zdola-nahoru (bottom-up) a přístup kombinovaný (combined/sandwich). 17 První přístup, velký třesk, je vhodný zejména pro menší projekty. Znamená totiž, že všechny moduly jsou integrovány naráz, a pak jsou testovány jako jeden celek. Provedení je jednoduché, o to těžší je pak hledání chyby, pokud test selže. Může se totiž stát, že některá jednotka způsobí chybu a ta se projeví až o několik jednotek dál. Přístupy shora-dolů a zdola-nahoru jsou velmi podobné, liší se směrem, jakým jsou jednotlivé moduly připojovány. V přístupu shora-dolů je nejprve připojen hierarchicky nejvyšší modul a pak jsou postupně připojovány moduly nižší a nižší. Přístup zdola-nahoru funguje přesně obráceně. Kombinovaný přístup využívá druhého a třetího přístupu na různých úrovních následujícím způsobem: Na nejvyšší úrovni jsou integrovány hlavní moduly přístupem shora-dolů, na spodní úrovni jsou integrovány často využívané moduly přístupem zdolanahoru a zbývající moduly jsou umístěny do prostřední úrovně Smoke testy Smoke testy přicházejí na řadu v okamžiku, kdy je hotová základní, ale funkční část aplikace, tedy ve chvíli, kdy jsou úspěšně splněny integrační testy. Jedná se o krátké testy, které ověřují, že všechny klíčové části aplikace jsou funkční a lze tedy přistoupit další fázi testování. 17 ROUDENSKÝ, Petr, HAVLÍČKOVÁ, Anna: Řízení kvality softwaru. 1. vydání, Computer Press, 2013, ISBN

21 1.4.4 Systémové testy Po úspěšném vykonání integračních testů přichází na řadu testy systémové. Jsou prováděny v pozdějších fázích vývoje, jako poslední testy před samotným předáním aplikace zákazníkovi. V podstatě slouží jako výstupní kontrola aplikace. V systémových testech je aplikace testována jako funkční celek, kdy se podle předem připravených scénářů testují různé situace, které mohou během používání aplikace nastat Akceptační testy Akceptační testy jsou již, na rozdíl od všech předchozích testů, prováděny zákazníkem. Aplikaci je vhodné předat zákazníkovi až v situaci, kdy proběhly všechny testy na straně dodavatele a to bez závažnějších nedostatků. Akceptační testy jsou typicky prováděny v několika iteracích. Celý proces probíhá tak, že testovací tým, zajištěný zákazníkem, provádí své vlastní systémové testování. Nalezené chyby zaznamenává a reportuje vývojovému týmu. Ten pak tyto chyby v co nejkratším možném čase opravuje. Celý proces se opakuje až do okamžiku, kdy zákazník akceptuje aplikaci jako hotovou a bezchybnou. 21

22 1.5 Automatické testování Jak jsem zmínil v úvodu, automatické testování je testování s využitím různých úrovní automatizace. Důvodů, proč tento způsob testování využít, je celá řada. Zřejmě tím hlavním je snaha snížit náklady na vývoj. Testování je totiž časově náročné, a tedy drahé. Jak uvádí autoři v úvodu knihy The Art of Software Testing: V době první publikace této knihy, v roce 1979, byl obecně známý fakt, že v typickém projektu je přibližně 50 procent celkového času a více než polovina celkových nákladů spotřebována na testování vyvíjeného programu nebo systému. Dnes, o třicet let a dvě knihy později to stále platí. 18 Jako příklad zde uvedu počty hodin, které náš tým strávil při implementaci čtvrté etapy aplikace +4U OSVČ, o které pojednávám dále. Tabulka ukazuje, že testování zabralo více než třetinu času celkové implementace. Zdůrazním, že v tabulce nejsou zahrnuty akceptační testy provedené zákazníkem. Oblast Počet hodin Management 24,25 Schůzky 13 Design 205,25 Implementace 834,25 Metodika 75,25 Testování 681,75 Změny 3 Problém 19,75 Součet 1656,5 Tabulka 1: Počty hodin podle oblasti 18 MYERS, Glenford, COREY, Sandler, BADGETT, Tom: The Art of Software Testing, 3. vydání, John Wiley & Sons, 2012, ISBN , (vlastní překlad) 22

23 V situaci, kdy testování zabírá velkou část celkové doby vývoje, jsou snahy tuto dobu zkrátit celkem pochopitelné. Je přeci mnohem rychlejší a hlavně levnější nechat celou aplikaci otestovat přes noc pomocí softwaru, než platit množství testerů, kteří budou dlouhé hodiny a dny realizovat jednotlivé testy. Jak ukáži dále, toto platit nemusí Výhody a nevýhody automatického testování Vedle motivace snížit náklady mohou být pro využití automatizace i další důvody. Například následující: Automatické testy jsou přesné. I ten nejlepší tester dělá chyby. Navíc po vykonání desítek nebo stovek testů se jeho pozornost pravděpodobně oslabí. To u automatických testů neplatí ty jsou vždy vykonány naprosto přesně. Automatické testy umožnují vyšší efektivitu práce. Tím, že zkracují čas nutný k provedení testů, umožnují testerům pracovat na jiných činnostech, jako jsou například důkladnější návrh testovacích scénářů, plánování testů nebo provádění neautomatizovaných testů. Automatizace testů může urychlit a usnadnit proces vývoje. S jejich využitím získává vývojář možnost okamžitě po implementaci části projektu možnost spustit testy a ověřit, zda je jeho kód v pořádku. Případné chyby také může ihned napravit a nemusí čekat, až jeho kód bude otestován příslušným testerem. Samozřejmě musím zmínit i nevýhody automatických testů, které nemusejí být na první pohled zřejmé: Implementace automatických testů klade vyšší nároky na odbornost a schopnosti jejich tvůrce. V některých případech je potřeba investovat do nákupu potřebných technologií. Nevhodné použití automatických testů může zvýšit celkové náklady na vývoj a přitom nijak nepřispět k vyšší kvalitě výsledného software. 23

24 1.5.2 Mýty o automatickém testování Mohlo by se zdát, že automatické testy jsou universálním řešením, které sníží náklady na vývoj a zvýší kvalitu výsledného softwaru, bez ohledu na kontext projektu. Podle mého názoru to tak není. Je to jen jeden z mýtů, které o automatickém testování kolují. Nejznámější mýty uvádí Roudenský, Havlíčková Zavedeme-li automatizaci, snížíme počet testerů a redukujeme náklady spojené s testováním. Tento mýtus se týká hlavně prvních projektů, ve kterých jsou automatické testy zaváděny. Platí však spíše opak - než je vyvinut potřebný framework a stávající testy jsou přizpůsobeny pro automatizaci, je zapotřebí dokonce vyšší počet pracovníků. Náklady tím rostou, převážně z důvodu nákupu nových technologií, které jsou pro automatizaci nezbytné. 2. Automatizujme 100 % testovacích případů pro lepší výsledky! Snaha pokrýt všechny testovací případy automatickými testy je nesmyslná. Ne proto, že by to bylo nereálné. Je to ale neefektivní a nepraktické. Některé testovací případy se z důvodu jejich důležitosti, četnosti a nákladů na automatizaci jednoduše automatizovat nevyplatí. 3. Automatizace se nám ihned vyplatí. Dalším častým omylem je očekávání, že vysoké počáteční náklady, potřebné pro zavedení automatizace, se rychle vrátí. Většinou platí, že návratnost se pohybuje v řádu měsíců a let, a málokdy se tak vrátí v průběhu projektu, pro který byla původně automatizace zavedena. 4. Automatizace vyřeší naše problémy s neorganizovaným testováním. Pochopitelný, ale častý mýtus. Automatizaci jednoduše nemá smysl zavádět tam, kde chybí organizace či jasné vymezení procesu testování. Automatizace tyto problémy nevyřeší, naopak je spíše prohloubí. 19 ROUDENSKÝ, Petr, HAVLÍČKOVÁ, Anna: Řízení kvality softwaru. 1. vydání, Computer Press, 2013, ISBN

25 Shrnutím výše uvedeného lze dospět k poznání, že automatizované nástroje slouží k urychlení práce testera či jeho zefektivnění, nikdy ne k jeho nahrazení Techniky automatizovaného testování K samotné automatizaci je možné přistoupit různými způsoby. Zřejmě nejznámějším způsobem automatizace je zachycení a přehrávání aktivity uživatele. Systém nejprve pomocí vhodného nástroje zaznamená aktivity uživatele v rámci daného testovacího scénáře, a následně již sám takové aktivity opakuje. Na konci vyhodnotí, zda výsledek testu odpovídá očekáváné hodnotě, často například zda daná komponenta obsahuje správnou hodnotu, či zda je v databázi vytvořen správný záznam. Tento způsob nachází uplatnění zejména při testování uživatelského rozhraní v pozdějších fázích testování. Dalším způsobem je modifikace zaznamenaných skriptů. Spočívá v úpravě skriptů, které byly vygenerovány na základě záznamu aktivity uživatele. Umožňuje provádět daleko variabilnější a komplexnější testy. Také umožnuje vstupy pro test generovat dynamicky, příkladem může být použití aktuálního data, což předchozí způsob neumožňuje. Pokud je třeba otestovat funkčnosti pomocí velkého množství variabilních vstupů a výstupů, je možné použít testování řízené daty. Vstupy a výstupy jsou odděleny od samotného kódu, často ve formě databázové tabulky, nebo CSV souboru. Systém pak řádek po řádku tyto vstupy načítá a po vykonání potřebných operací je porovnává s očekávanými výstupy Nástroje pro testování V poslední kapitole teoretické části mé práce se věnuji nástrojům, které bych mohl v praktické části využít. Protože hlavním programovacím jazykem pro uuapps je jruby, zaměřil jsem svou pozornost právě na knihovny pro jruby. 25

26 Minitest Na prvním místě musím zmínit Minitest, Framework pro testování, který je nainstalován spolu se samotným Ruby nebo jruby. Je součástí základního distribučního balíčku, a proto je okamžitě připravený k použití. Minitest/test je malý a neuvěřitelně rychlý framework pro jednotkové testy. Poskytuje bohatou sadu nástrojů pro ověřování a dělá tak Vaše testy čisté a čitelné. 20 Minitest poskytuje širokou škálu funkčností, spolu s mnoha dostupnými rozšířeními a možností implementovat rozšíření vlastní. Práce s Minitestem je jednoduchá a intuitivní. Z mého pohledu je Minitest výborný nástroj, ale využití pro něj vidím spíše v nižších úrovních testů, jako jsou například jednotkové testy. Samotné testování je založeno na porovnání očekávaného a skutečného výsledku pomocí různých assertion metod. Kompletní seznam všech dostupných porovnání lze nalézt v příslušné dokumentaci 21, v příkladu níže ukazuji pouze ty nejzákladnější. Obrázek 5: Příklad assertion metod frameworku Minitest, vlastní zpracování Cucumber Velmi zajímavým způsobem k testování přistupuje Cucumber, komplexní ekosystém určený pro vývoj řízený požadavky na chování. 22 Podle mého názoru má Cucumber velké výhody: Zaprvé, spojuje specifikaci požadavků a dokumentaci pro testy do jednoho celku. Dalším plusem je, že umožňuje psát testy i méně zkušeným programátorům či například analytikům. 20 Minitest/test [online]. International. [cit ] Dostupné z URL: < (vlastní překlad) 21 MiniTest::Assertions [online]. Dokumentace. [cit ] Dostupné z URL: < 22 Anglicky Behaviour driven development 26

27 Capybara V kapitole 1.4 jsem zmiňoval, že testování softwaru má své fáze a že v každé z nich nachází uplatnění jiný typ testů. Pro jednotkové testy jsem zmiňoval framework Minitest. Na opačném konci testování jsou testy akceptační pro jejich tvorbu a realizaci je možné použít právě framework Capybara. Její autoři uvádí: Capybara Vám pomáhá testovat webové aplikace tím, že simuluje, jak by reálný uživatel interagoval s Vaší aplikací. 23 Capybara je velmi rozsáhlý framework a poskytuje velkou škálu funkčností. Lze jej mimo jiné integrovat i s frameworky Minitest, Cucumber, RSpec, a nebo pro GUI testy s automatizačním nástrojem Selenium. Selenium V kapitole jsem uváděl zaznamenání a přehrání skriptů jako jeden z možných způsobů automatizace. Selenium je jedním z nástrojů, které k tomu lze použít. Jedná se pro automatizaci činností prováděných ve webovém prohlížeči. Hlavním využitím je tedy testování, vedle toho lze Selenium využít i pro jiné, opakující se činnosti Teamcapybara/Capybara [online]. International. [cit ] Dostupné z URL: < (vlastní překlad) 24 Selenium - Web Browser Automation [online]. ThoughtWorks, Chicago, U.S.A. [cit ] Dostupné z URL: < 27

28 2. Automatické testy v kontextu uuapps 2.1 Platforma Unicorn Universe Operating System Unicorn Universe Operating System je univerzální platforma pro vývoj a provoz komplexních informačních systémů. Umožňuje řízení všech podnikových procesů, usnadňuje komunikaci, podporuje správu a sdílení různých typů informací, rozvíjí spolupráci mezi lidmi nebo celými organizačními celky Vývoj aplikací pro Unicorn Universe V prostředí Unicorn Universe jsou definovány tři typy aplikací. Dokumentace uvádí: V Unicorn Universe známe tři typy aplikací. První je uuapp, což je aplikace instalovaná do Business Territory. Druhý je uudevapp, což je aplikace určená pro vývoj. Třetí je uuappbox, což je kontejner umístěný ve skladišti aplikací (uuappwarehouse) který obsahuje sadu pro instalaci aplikace do Business Teritorií. 26 V práci se zaměřuji na první a druhý typ. Poslední typ je pro mou práci irelevantní, jedná se o úložiště informací potřebných pro instalaci dané aplikace. 25 Unicorn Universe Operating System [online]. Česká Republika. [cit ] Dostupné z URL: < 26 Úvod do vývoje aplikací v Unicorn Universe [online]. Praha: Unicorn Universe. [cit ] Unicorn Universe artefakt: <VPH-BT: >. 28

29 2.3 Specifika aplikací vyvíjených nad platformou Unicorn Universe Výkonná logika uuapps je vytvořena v programovacím jazyce jruby. jruby je Java implementace nativního Ruby, určená pro spouštění v Java Virtual Machine (JVM). Aplikace vytvořené pro Unicorn Universe Operating System zajišťují hlavní funkčnosti následujícími způsoby: Vizuální případy užití Makra uucommandy Vizuální případy užití V rámci implementace uuapps se nejčastěji jedná o vizuální případy užití. Rozumí se tím takové situace, kdy uživatel přímo interaguje s uživatelským rozhraním. Označují se jako uu Visual Use Case (dále jen VUC) a svou architekturou přibližně odpovídají Model-View- Controller (časteji MVC) architektuře. Obrázek 6: Schéma MVC, vlastní zpracování podle předlohy 27 Myšlenka MVC je jednoduchá, snaží se rozdělit aplikaci na tři relativně nezávislé části takovým způsobem, že změna jedné části nemá žádné nebo jen minimální dopady na ostatní prvky. Definujeme tzv. Model, View, Controller. 27 FOWLER, Martin: Patterns of Enterprise Application Architecture. 1. vyd. Crawfordsville: Addison-Wesley Professional, ISBN

30 Model zastřešuje data a také business logiku zpracování těchto dat. Příkladem zpracování může být získání určitých dat z databáze, provedení výpočtů nad těmito daty a případně uložení výsledků. Kromě toho Model také zastřešuje i validaci a komunikaci s okolním prostředím, respektive s ostatními aplikacemi. Model samotný nijak nekomunikuje s View, tuto interakci zajišťuje Controller. View je uživatelským rozhraním, stará se o zobrazení dat uživateli a zároveň slouží jako uživatelský vstup. Realizaci View v uuapps se podrobněji věnuji níže. Controller představuje prvek propojující Model a View. Reaguje na akci, kterou uživatel provedl v uživatelském rozhraní. Na základě toho aktualizuje model a aktualizuje uživatelské rozhraní podle změn v modelu. Pro uuapps je View definován následujícím způsobem: Grafické uživatelské rozhraní pro uu Visual Use Case je reprezentováno komponentou View, která do sebe agreguje uu Visual Use Case Components, které tvoří jednotlivé prvky uživatelského rozhraní. 28 View tedy obsahuje komponenty pro vykreslení uživatelského rozhraní, ale i další informace. Následující obrázek ukazuje, co všechno tvoří View v případě uuapps: Obrázek 7: struktura třídy View v kontextu uuapps 28 Podívám-li se blíže na strukturu třídy View, pak: Event reprezentuje událost vyvolanou na základě uživatelské akce. Eventem tak může být kliknutí na tlačítko, změna hodnoty komponenty a další. Context zastřešuje parametry a informace o spuštění 28 Guideline: Controller a jeho vlastnosti [online]. Praha: Unicorn Universe. [cit ] Unicorn Universe artefakt: <VPH-BT: >. 30

31 případu užití, příkladem mohou být informace o uživateli, předmětném artefaktu, případně parametry pro spuštění a další. Components jsou jednotlivé komponenty pro uživatelské rozhraní. Spolu s Messages, které umožnují zobrazovat zprávy, jde o prvky přímo viditelné uživatelem. Navigation nese informace a metody důležité pro přechod mezi různými případy užití. Pro názorné vysvětlení spolupráce jednotlivých tříd uvedu příklad, jak může probíhat komunikace mezi jednotlivými prvky v modelu MVC: Obrázek 8: Schéma interakce controlleru s modelem a view 1) Uživatel provede v prohlížeči nějakou akci tím může být kliknutí na tlačítko, změna nebo zadání hodnoty do komponenty, odeslání formuláře a další. 2) Controller obdrží z uživatelského rozhraní zprávu o vykonané akci. 3) Pokud je to potřeba, Controller přistoupí k Modelu a na základě provedené akce jej aktualizuje. 4) Model může využít persistentního uložení dat, to v případě, že business logika takovou akci vyžaduje. 5) Controller aktualizuje View pomocí aktuálního Modelu. 6) View aktualizuje uživatelské rozhraní na základě aktuálního Modelu. A celý proces se může opakovat. 31

32 V kontextu uuapps může být Controller popsán následujícím způsobem: Controller je typicky realizován Ruby skriptem. Controller může manipulovat s uu Visual Use Case Component prostřednictvím API na View. Typický Controller pokrývá 4 hlavní funkčnosti: validuje prerekvizity spuštění, nastavuje jednotlivé komponenty, reaguje na změny ve formuláři a zajišťuje odeslání formuláře. Validace prerekvizit. Jde o věření toho, zda vůbec případ užití může být spuštěn. V tomto bodě ještě nedochází k vykreslení uživatelského rozhraní, i když Controller již dostává třídu View pomocí parametru. Důvod je prostý jak jsem uvedl výše View neobsahuje pouze komponenty uživatelského rozhraní, ale i další informace potřebné ke spuštění případu užití. Validace může vypadat následovně: Obrázek 9: Příklad implementace metody on_before_init, vlastní zpracování Nastavení jednotlivých komponent. V této fázi Controller nejprve získá z modelu potřebná data a podle nich pak nastaví a zobrazí formulář. Obrázek 10: Příklad implementace metody on_init, vlastní zpracování 32

33 Změny ve formuláři. Některé komponenty mohou mít nastaven atribut submitvaluechange. Toto nastavení umožňuje reagovat na uživatelskou změnu hodnoty dané komponenty. Zde nedochází, respektive nemělo by docházet, k vykonání složitější logiky. Controller má za úkol reagovat na uživatelem vyvolané změny a podle nich aktualizovat View, případně získat z Modelu aktualizované informace. Obrázek 11: Příklad implementace metody on_value_change, vlastní zpracování Odeslání formuláře. Nastává v okamžiku, kdy uživatel chce dokončit práci s formulářem a odeslat jej ke zpracování. Controller musí zajistit vykonání 4 klíčových úkolů: V prvním kroku je třeba získat data z View, respektive hodnoty jednotlivých komponent. Poté je třeba provést validaci těchto dat podle business pravidel a případně zamezit odeslání formuláře, pokud data validní nejsou. Jakmile jsou k dispozici ověřená data z formuláře, lze přistoupit k hlavním funkčnostem případu užití, zde se jedná o vytvoření vydané faktury. Posledním krokem je navigace na nově vytvořený artefakt. Obrázek 12: Příklad implementace metody on_submit, vlastní zpracování 33

34 2.1.2 Makra Makra využívají starší, dnes již také deprekované UES API a jsou na rozdíl od vizuálních případů užití asynchronní, uživatel typicky nečeká na jejich dokončení. Jedná se o již deprekovaný, přesto stále ve velké míře využívaný způsob poskytování funkčností. U maker vidím velmi malý potenciál pro automatizaci. Rozhodně nepůjde tvořit testy automaticky jako u vizuální případů užití. Je to dáno už samotným způsobem, jakým jsou makra používána. Makro jako takové je v systému reprezentováno artefaktem vytvořeným podle meta artefaktu typu Makro. Skript samotný je uložen v příloze skriptového artefaktu, odkud je v okamžiku spuštění nahrán a vykonán. Pokud nebudu počítat práva ke spuštění v podobě Uživatel X smí / nesmí spustit makro Y, pak není spuštění makra nijak omezeno, což může být problém. Velká část maker, se kterými jsem se setkal, předpokládá spuštění nad konkrétním artefaktem. Pokud dojde ke spuštění nad artefaktem jiným, tak to skript v nejlepším případě odhalí při validaci vstupních podmínek. V horším případně skončí chybou, pokud vstupní podmínky nevaliduje. Druhým problémem je způsob, jak makro pracuje s Ruby gemy. Při svém běhu může makro využívat pouze takové gemy, které jsou dostupné na příslušném uunode. To je rozdíl oproti VUC, kde jsou všechny gemy součástí webového archivu (WAR) dané aplikace. Tento fakt komplikuje vývoj a testování maker. Vývojář je totiž postaven před následující rozhodnutí: 1. Může oddělit výkonnou logiku makra do samostatného Ruby gemu, zajistit nasazení tohoto gemu na příslušný uunode a v makru pouze využívat dostupných funkčností. Zřejmou výhodou tohoto řešení je možnost otestovat, alespoň na úrovni unit testů, samotný gem izolovaně a následně pak provést jednoduchý integrační test. Ten již pouze ověří, že makro dokáže gem načíst a využívat jeho veřejné metody. Musím také zmínit výhodu v podobě snadného udržování zdrojového kódu ten se nachází pouze na jednom místě. Nevýhodou je samotné nasazení gemu, které nemůže provést vývojář sám, ale musí o to požádat správce příslušného uunode. 34

35 2. Jinou možností je zapsání výkonného kódu přímo do makra. Na jednu stranu se tak makro stává nezávislé na Ruby gemech dostupných na příslušném uunode, na kterém je makro spuštěno. Na druhou stranu dochází k velké duplicitě, každé makro obsahuje kopii kódu, který využívá. Tento způsob je také značně nevhodný pro provádění unit testů. Bohužel, většina maker, se kterými jsem přišel do styku, je realizována právě takto uucommandy Pro platformu uuos jsou v současné době dostupné dva typy uucommandů. První typ, také označovaný jako uucommand v1 označuje funkčnosti uuos a je dostupný přes REST API. Jako příklad uucommandu v1 mohu uvést získání atributů artefaktu. Vývoj a testování tohoto typu není součástí vývoje uuapps a proto jsem se mu ve své práci nevěnoval. Druhý typ, uucommandy v2, tvoří aplikační rozhraní jednotlivých uuapps a jde o nevizuální typ případu užití. Opět jsou dostupné přes REST API, na rozdíl od předchozího typu je ale jejich vývoj součástí samotné implementace uuapps. Obrázek 13: Příklady volání uucommandů v1 a v2 Obecně mohou být uucommandy dvojího typu: synchronní a asynchronní. Svou implementací jsou si podobné. Rozdíl je zejména v tom, že v případě asynchronního zpracování je v synchronní části, samozřejmě po validaci parametrů, zadáno vykonání asynchronní části. Synchronní část tím končí, asynchronní úloha je zařazena do fronty a bude zpracována v okamžiku, kdy dojde na řadu. 35

36 Samotný uucommand je v podstatě izolovaný kontejner pro běh business logiky aplikace, což mimo jiné usnadňuje testování. Implementace může vypadat následovně: Obrázek 14: Příklad implementace výkonné logiky commandu, vlastní zpracování V následující kapitole popíši, jak jsem jednotlivé způsoby testoval a k jakým závěrům jsem dospěl. 36

37 3. Automatické testování uuapps Stěžejním cílem mé práce bylo analyzovat současný stav testování uuapps, navrhnout, jaké testy by mohly být automatizovány a následně vyzkoušet automatické testování na vybrané aplikaci. V této kapitole se pokusím shrnout, jak jsem postupoval a čeho jsem dosáhl. Před samotnou volbou, jaké prostředky a nástroje při automatizaci použít, jsem narazil na potřebu definovat základní body: Jakou aplikaci chci testovat. Volba má dalekosáhlé dopady, určuje, s jakými technologiemi budu pracovat. Ačkoliv mají uuapps základní jádro společné, mohou se případ od případu lišit svou implementací. Například persistenci dat mohou řešit pomocí JSON uuproperty, uuobjectstore 29 nebo klasickou SQL databázi a tomu je třeba testování přizpůsobit. Co chci testovat. Tedy jaké druhy testů chci provést, jaké funkčnosti chci otestovat. Je zřejmé, že pro testování jednotlivých knihoven, respektive v kontextu uuaplikací jednotlivých Ruby Gemů je třeba zvolit jiné prostředky, než pro testování například vizuálních případů užití. 3.1 Současný stav testování uuapps Při implementaci uuapps je v současné době drtivá většina testů realizována manuálně, což nemusí být v určitých situacích nutně na škodu. Pro některé typy testů je využití automatizace značně neefektivní a živý tester je plně dostačující. Uvedené přestává platit v případě opakujících se testů. Na základě vlastní zkušenosti vím, že je vhodné po každém sestavení aplikace provést alespoň minimalistický smoke test. Zde by byl přínos automatizace prokazatelně obrovský. V případě složitější aplikace zabere množství času i pouhé ověření toho, že každý jednotlivý VUC lze spustit a 29 uuobjectstore - HLC [online]. Praha: Unicorn Universe. [cit ] Unicorn Universe artefakt: <VPH- BT: >. 37

38 formulář se bezchybně načte. V případě, že by mělo být testováno i odeslání formuláře, případně různé alternativní toky, pak potřebný čas samozřejmě narůstá. V dnešní situaci záleží na kvalitách daného testera, jak komplexně dokáže danou aplikaci otestovat. Co je horší, zažil jsem i případ, kdy šlo o takzvané Monkey Testing 30, tedy o situaci, kdy tester nezná problémovou doménu aplikace a ani nemá k dispozici připravené testovací scénáře. Chtěl bych poznamenat, že takový přístup může být v určitých situacích přínosný, ale rozhodně jej nelze považovat za dostačující! Spolu s rostoucím významem uuapps rostou i nároky na jejich kvalitu a relativní bezchybnost. Existují formálně definované testovací scénáře. Zároveň je možné aplikaci nechat důkladně otestovat prostřednictvím burzy aplikací. Testování uucommandů už využívá automatizace součástí Ruby gemu s názvem uu_os_cmd je dokonce připravený Rake task, který spustí všechny testy v projektu. 3.2 Výběr aplikace pro realizaci testování Pro testování uucommandů jsem zvolil aplikaci TESCO Manažerský reporting, která slouží k podpoře manažerských rozhodnutí pracovníků známého obchodního řetězce. Nejedná se o běžnou uuapp, protože neobsahuje ani jeden vizuální případ užití. V ostatním se ale ničím neodlišuje a je tak pro testování použitelná. V aplikaci TESCO jsou uucommandy použity jako veřejné REST API pro mobilní zařízení. Z bezpečnostních důvodů nemohou jednotlivá zařízení přistupovat přímo do databáze, pro tento přístup jsou použity právě uucommandy. Pro testování vizuálních případů užití jsem zvolil aplikaci +4U OSVČ, na jejíž implementaci jsem se také podílel a důvěrně jí znám. Aplikace je dostatečně rozsáhlá na to, aby umožnila ukázat na výhody automatického testování. Podle propagačních 30 What is Monkey testing? Types, Advantages and Disadvantages [online]. [cit ]. Dostupné z URL: < 38

39 materiálů lze +4U OSVČ popsat jako: Jediná aplikace pro české živnostníky s online fakturací, přímým napojením na datové schránky a dalšími užitečnými funkčnostmi. 31 Aplikace +4U OSVČ používá skoro všechny dostupné možnosti, jak poskytovat funkčnosti a realizovat tak jednotlivé případy užití: Většinu všech případů užití tvoří vizuální případy užití, celkem jich je 81. Dále jsou to asynchronní makra, využívající již deprekované UES API, celkem aplikace obsahuje 53 maker. Poslední rozšíření aplikace, které bude nasazeno na začátku roku 2017 také obsahuje synchronní a asynchronní uucommandy, ovšem v minimálním počtu 8 commandů. Bohužel, co se týká použitých technologií, není aplikace jednotná a mohou nastat celkem zajímavé situace. Například případ užití Odeslat fakturu kombinuje vše: Vstupním bodem je vizuální use case s názvem Odeslat fakturu vydanou. Ten pro načtení aplikační konfigurace používá již deprekovaný způsob ukládání dat ve formě JSON, uloženého jako vlastnost typu BLOB na konfiguračním artefaktu. Co se ale týká samotné faktury, data jsou uložena v uuobjectstore, což je dokumentová MongoDB přizpůsobená potřebám platformy uuos. Samotné odeslání je také realizováno různými způsoby pokud uživatel chce odeslat fakturu pomocí datové zprávy nebo em, tak příslušný Controller využívá starších maker, které pracují s UES API. Pokud ale uživatel zvolí možnost odeslat pomocí služby Plus4U, pak je zavolán uucommand v2, který již pracuje s novějším UU API U OSVČ [online]. Česká Republika. [cit ] Dostupné z URL: < 39

40 3.3 Vlastní realizace testů Svou zkušenost a výsledky realizovaných testů strukturuji z pohledu tří způsobů, pomocí kterých uuapps poskytují své funkčnosti a které jsem blíže popsal v kapitole 2.3 své práce Vizuální případy užití Ve věci vizuálních případů užití jsem se rozhodl dosáhnout následujícího: Umožnit spouštění předem definovaných testů, a to jak na lokálním vývojovém prostředí, tak i v prostředí již nasazené aplikace. Také jsem chtěl vyzkoušet způsob, jak alespoň částečně realizovat smoke test po nasazení aplikace. Nechtěl jsem, aby smoke test spočíval pouze ve spuštění připravených testů. Naopak mým cílem byl chytrý test, který umí prozkoumat danou aplikaci a který dokáže jednoduché testy vytvořit sám. K testování jsem přistupoval programově, nechtěl jsem se omezit na testování uživatelského rozhraní například pomocí nahraných skriptů. Snažil jsem se vytvořit testy, které budou nezávislé na výsledné podobě GUI. Toto rozhodnutí mělo svůj důvod v tom, že v použité aplikaci +4U OSVČ často dochází ke změnám podoby grafického rozhraní. Často se mění umístění komponent ve formuláři, velikost komponent, mění se typ komponent. Každá taková změna znamená nutnost úpravy nahraných skriptů. V programovém přístupu umístění komponenty, její velikost a další vlastnosti, které určují výslednou podobu formuláře, nehrají roli. Dalším důvodem je kontrola výsledků. Mám-li například jako vzorový objekt fakturu, tak není problém její tvorbu automatizovat pomocí skriptu, který bude simulovat chování uživatele v GUI. Problém nastává v okamžiku, kdy chci zkontrolovat výsledek. Ne všechny informace jsou v GUI viditelné a pro důslednou kontrolu by byl potřeba další skript, který by zkontroloval přímo uložená data. 40

41 Testování modelu Prvním krokem bylo logicky testování modelu, a to jak unit testů, tak i testů integračních. Pro tento účel jsem zvolil framework Minitest, o kterém se zmiňuji v kapitole Tato volba měla dva důvody. Zaprvé, Minitest je součástí všech verzí jruby, které se pro vývoj uuapps používají, existuje pro něj mnoho různých rozšíření a protože je vydán pod MIT licencí, lze jej v případě potřeby libovolně modifikovat. Druhým důvodem je fakt, že všechny aktuálně existující unit testy jsou realizovány právě pomocí Minitestu. Každý vývojář uuapps tento framework alespoň rámcově zná a do vývoje tak nebude zanesena potřeba nové technologie. Zjednodušeně řečeno, cílem této fáze bylo otestování jednotlivých metod, tříd a modulů. Otestovat bylo třeba jak jejich veřejné API, tak i privátní metody. Provádění unit testů v prostředí uuos je ve srovnání s realizací ostatních testů, nejjednodušší. Je to z toho důvodu, že všechny funkčnosti lze testovat nezávisle na pohledu nebo Controlleru. U unit testů pro třídy, moduly a metody, které nevolají funkčnosti platformy je situace zdaleka nejsnadnější. Pro automatický test stačí získat aktuální zdrojové kódy ze sdíleného úložiště, pokud je potřeba, tak sestavit anebo nainstalovat aktuální verzi použitých knihoven, spustit sérii jednotlivých testů a na závěr zpracovat výsledky. Takový test je snadno spustitelný bez ohledu na okolní testovací prostředí, co je zřejmé i v následující ukázce: Obrázek 15: Metoda testovatelná bez přístupu k Unicorn Universe 41

42 Situace se stává složitější v situaci, kdy je třeba interakce s platformou UU. Zde již není možné test provést nezávisle minimálně je třeba zajistit internetové připojení, přístupové údaje, testovací prostředí, připravit testovací objekty a další. Metodu, kterou uvádím v následujícím příkladu, nelze otestovat samostatně, tak, jak je implementovaná. Na řádku číslo 14 dochází k volání funkčností platformy, pomocí UU API. Před samotným testováním metody je tak třeba zajistit přihlášení do UU a také zajistit, aby přihlášený uživatel měl přístup do cílového teritoria. Musí mít samozřejmě i příslušná oprávnění pro využití funkčností UU. Obrázek 16: Metoda netestovatelná bez přístupu k Unicorn Universe Je relativně snadné spustit jednotlivé připravené testy a to, i pokud nevím, jaké testy se v projektu nacházejí. Zde vycházím z předpokladu, že je dodržována alespoň základní konvence, co se týká struktury projektu a pojmenování souborů s testy. Platí-li tento předpoklad, pak lze snadno skriptem projít projekt, shromáždit všechny soubory s testy a spustit je. Dalším krokem je shromáždění výsledků testů. Nabízí se několik možností, z mého pohledu ideální je využití rozšíření pro framework Minitest s názvem Minitest-reporters 32. Ten umožňuje nastavení, jakým způsobem je výstup zpracován. Já jsem zvolil JUnit reporter, který výsledky zapisuje do XML souborů, které jsou vhodné pro následné strojové zpracování. Samotné použití reporterů je snadné, stačí na začátek souboru s testem přidat definici, jaké formáty chci použít. V mém případě vypadá definice následovně: 32 Minitest Reporters [online]. International. [cit ] Dostupné z URL: < 42

43 Obrázek 17: Použití reporterů v testu, vlastní zpracování Standardní konzolový výstup, který může vypadat následovně: Obrázek 18: Standardní konzolový výstup, vlastní zpracování Je nahrazen.xml souborem s následujícím obsahem: Obrázek 19: XML podoba výsledků testu, vlastní zpracování Zpracování jednotlivých výstupů pak bylo, díky strojově zpracovatelnému formátu xml, velmi snadné Integrační testy Pro integrační testy jsem zvolil přístup zdola nahoru a postupoval jsem následujícím způsobem: V prvním kroku jsem provedl unit testy tříd, metod a modulů. V dalším kroku přijdou na řadu složitější testy, které vyžadují spolupráci více tříd, tyto testy by měly ověřit funkčnost celého modelu. 43

44 Testování Controlleru ve spolupráci s Modelem už je obtížnější než testování samotného Modelu. Jde o to, že Controller z definice zajišťuje komunikaci mezi View a Model, a pokud tyto nejsou k dispozici, těžko může být Controller otestován. Není to neřešitelná situace. Pro první prototyp jsem použil jednoduchou třídu, která simuluje chování Modelu, a tedy poskytuje jeden vstup pro Controller. Jak ale získat View, když zatím nemám k dispozici uživatelské rozhraní a chci si vytvořit vlastní třídu? Má myšlenka je následující: Potřebuji programově vytvořit View, který se pro Controller bude tvářit jako skutečný. Je třeba, aby obsahoval všechny potřebné komponenty, které navíc musí mít správné atributy. Komponenty tedy musí být správného typu, musejí míst správný kód, je třeba, aby měly implementované všechny metody, které nad nimi může controller volat a další. Samotné komponenty ale nestačí jak jsem ukázal dříve, v kontextu uuapps je View nositelem dalších informací, které je třeba také dodat a nasimulovat. Jedná se hlavně o kontext, bez něj by byl View pro controller naprosto nepoužitelný. Naštěstí knihovny používané při vývoji již obsahují metody, které umožnují View složit programově, podle předem zadaných parametrů. Konkrétně se jedná o gem uu_adk 33 S jeho pomocí je pak možné vytvořit instanci třídy View pomocí jednoduchého volání: Obrázek 20: Příklad vytvoření třídy View podle zadaných parametrů, vlastní zpracování Konstruktoru je třeba předat správné parametry ve formátu JSON nebo Ruby hash, problém tvorby umělé třídy View se tak zužuje na problém získání a nastavení těch správných parametrů. Minimální parametry, potřebné pro nasimulování třídy View, jsou následující: Definice komponent ve formuláři a kontext případu užití. Komponenty pro vizuální případy užití jsou definovány na jeho předloze, konkrétně na artefaktu vytvořeném podle vzoru Visual Use Case. Postup, který jsem použil, je tento: 33 gem lze stáhnout příkazem gem install uu_adk --source spuštěným z příkazové řádky operačního systému 44

45 Nejprve jsem získal definici uživatelského rozhraní, ve strojově zpracovatelné podobě. Pro další zpracování je ideální formát UXML, který je zároveň i defaultním datovým typem, který metoda get_sheet_data vrací. Z UXML jsem pak pomocí Nokogiri a xpath metody vybral definice jednotlivých komponent, které předám jako parametr při tvorbě třídy View. Samozřejmě je možný i jiný přístup, například mít seznam komponent uložený v externím souboru a definici komponent načítat z něj. Takový přístup je, alespoň podle mě, značně nevhodný. Při aktualizaci uživatelského rozhraní je třeba i aktualizace externího souboru. Naopak můj přístup vždy používá aktuální data, přesně taková, jaká by třída View získala při reálném spuštění případu užití Makra Testování maker je samo o sobě problematické a tím obtížnější je i automatizace těchto testů. Makro v rámci uuapps vystupuje jako nedělitelný celek a je třeba drobná úprava, aby bylo možné testování pouze jeho části nebo vybrané metody. Tato úprava spočívá v podmíněném vytvoření instance hlavní třídy makra. Pro potřeby uuapps je makro implementováno následujícím způsobem: Obrázek 21: Příklad implementace makra, vlastní zpracování 19 Veškerý kód makra je zapsaný právě v jednom Ruby souboru, na jehož konci dojde k vytvoření instance výše definované třídy. Tento způsob umožňuje spuštění makra pouhým načtením souboru, zároveň ale představuje překážku pro testování. 45

46 První problém jsem vyřešil jednoduše definoval jsem metodu s názvem test_run? a s její pomocí pak instanci vytvářel podmíněně. Tím jsem zabránil tomu, aby v okamžiku načtení souboru rovnou došlo k jeho spuštění. Obrázek 22: Podmíněné spuštění makra, vlastní zpracování Nyní již dokážu načíst soubor s příslušným makrem a cíleně spouštět veřejné metody jednotlivých tříd. Využil jsem toho a vše, co otestovat šlo, jsem otestoval izolovaně, v podobě unit testů. Na další problém jsem narazil v okamžiku, kdy jsem chtěl spustit makro celé a simulovat tak reálnou situaci, ovšem na mém počítači. Stejně jako vizuální případy užití, i makro potřebuje pro svůj korektní běh znát kontext případu užití. Mezi takové informace patří například UESURI artefaktu, nad kterým byl případ užití spuštěn, kým byl spuštěn, jaké mu byly předány parametry a další. Tato data lze získat pomocí třídy UESScriptContext, respektive její metody getparameter(parametername). Bohužel, třída neimplementuje metodu setparameter a nelze tak před spuštěním testu nastavit vlastní, testovací kontext. Pro potřeby mé práce jsem tedy testované makro upravil takovým způsobem, že nejdříve provede kontrolu, zda společně s předanými parametry byl předány i kontextové informace a pokud ano, jsou pro běh makra použity uucommandy Testování uucommandů bylo z celé mojí práce nejjednodušší. Je to dáno faktem, že samotná technologie uucommandů již s automatickými testy počítá. Součástí Ruby gemů pro vývoj je integrovaný server, pomocí kterého lze spustit testy bez reálného nasazení na plus4u.net. K lepší testovatelnosti přispívá i samotná struktura uucommandů, kterou popisuji v kapitole Je tedy možné provést unit testy na třídách a modulech, 46