VŠB – Technická univerzita Ostrava Fakulta elektrotechniky a informatiky
Katedra informatiky
Absolvování individuální odborné praxe Individual Professional Practice in the
Company
Rád bych na tomto místě poděkoval všem, kteří mi s prací pomohli, protože bez nich by tato
Abstrakt
Cílem této práce bylo popsat činnosti, které byly vykonány v rámci individuální odborné praxe ve firmě profiq s.r.o. Součástí praxe bylo několik projektů, které uvnitř této práce zmiňuji.
Pro každý projekt je uveden jeho stručný popis a konkrétní úkoly, které byly v průběhu praxe vykonány. Nejkomplexnějším úkolem byla práce na projektu DivvyPay, z toho důvodu je tomuto projektu věnována samostatná kapitola. V závěru práce jsou shrnuty získané dovednosti.
Klíčová slova: odborná praxe, profiq s.r.o., automatizace testování, testování na mobilních platformách, bankovní transakce
Abstract
The aim of this work is a description of an individual professional practise in the company profiq s.r.o. Several projects are described in the thesis. Every project contains a short description and an overview of concrete tasks. Project DivvyPay is in extra section, because it is larger and more complex than the other projects. The conclusion resumes the taken skills.
Key Words: professional practise, profiq s.r.o., automation of tests, testing on mobile platforms, bank transactions
Obsah
Seznam použitých zkratek a symbolů 8
Seznam obrázků 9
Seznam výpisů zdrojového kódu 10
1 Úvod 11
1.1 O firmě . . . 11
1.2 Cíle testování a automatizace . . . 11
1.3 Požadavky na produkt . . . 11
1.4 Obecný postup testování . . . 11
2 Použité technologie 13 2.1 GIT . . . 13
2.2 Selenium . . . 13
2.3 Appium . . . 13
2.4 WebdriverIO . . . 13
2.5 React . . . 14
2.6 React Native . . . 14
2.7 Jira . . . 14
2.8 Mocha . . . 14
3 Souhrn projektů 16 3.1 Mulesoft Anypoint studio . . . 16
3.2 SlamData . . . 17
3.3 Liferay Portal . . . 17
4 Projekt DivvyPay 19 4.1 Teoretické principy služby . . . 19
4.2 Testování mobilní aplikace . . . 19
4.3 Testování webové stránky pro vedoucí organizace . . . 25
4.4 Testování webové stránky pro systémové administrátory . . . 26
4.5 Testování platebních karet v reálném prostředí . . . 27
5 Závěr 28
Literatura 29
Seznam použitých zkratek a symbolů
CI – Continous Integration
DOM – Document Object Model
GUI – Graphical User Interface
HTTP – Hypertext Transfer Protocol
MVC – Model View Controller
NPM – Node package management
PR – Pull Request
SW – Software
UI – User Interface
USB – Universal Serial Bus
QA – Quality Assurance
8
Seznam obrázků
1 Přidělování priorit na projektu Liferay . . . 15
2 Program v Anypoint studio . . . 16
3 Nahlášená chyba v systému Liferay . . . 18
4 Výsledek ručního testování v tabulce . . . 21
5 Příklad chyby mobilní aplikace DivvyPay . . . 21
6 Správa rozpočtu ve webové aplikaci pro vedoucí organizace . . . 25
7 Formulář pro přidávání transakcí v testovacím prostředí . . . 26
Seznam výpisů zdrojového kódu
1 Příklad použití rámce Mocha . . . 14
2 Příklad testu přejmenování složky ve funkcionálním jazyce PureScript . . . 17
3 Konfigurace automatických testů na systému Android . . . 22
4 Konfigurace automatických testů na systému iOS . . . 22
5 Identifikátor elementu jako celá cesta vs. id . . . 23
6 Test resetu hesla přes e-mail . . . 23
10
1 Úvod
1.1 O firmě
Firma profiq s. r. o. provádí pro zákazníky testování, automatizaci testů a vývoj aplikací pro mobilní zařízení, počítače i webový prohlížeč.
Má pracovní pozice je Technology research (technologický průzkum). Mým úkolem je po- chopení technologií, které zákazník v aplikaci používá, najít chyby a prostor pro vylepšení.
Zpracovat ukázkové řešení (demo), jaké služby jsme schopni zákazníkovi nabídnou. Demo pře- vážně obsahuje automatizované testy a články, jak s produktem pracovat. Jestliže máme přístup ke zdrojovým kódům aplikace, snažíme se implementovat nějakou novou menší funkci, nebo opravit chyby. Výsledky práce se poté prezentují zákazníkovi, který se rozhodne, zda-li bude dlouhodobě spolupracovat.
1.2 Cíle testování a automatizace
Cílem testování je aplikace bez chyb, která jde jednoduše používat a obsahuje všechny potřebné funkce. Otestovat aplikaci ručně trvá dlouho, proto se používají automatizované testy. Cílem automatizovaných testů je snížit pravděpodobnost výskytu chyby v aplikaci. Vývojář aplikace provede změnu v kódu a spustí testy. Testy mohou být spuštěny na počítači vývojáře nebo na serveru. Ideálně v co nejkratším čase testy vrátí výsledek. Pokud všechny funkce aplikace fungují bez problému, testy skončí bez chyby. Pokud nějaká funkce nefunguje, jak má, testy vrátí informaci, kde konkrétně se chyba nachází. Testy se většinou také spouštějí pro každý Pull Request (PR) ve verzovacím systému GIT, viz sekce 2.1.
Jako vedlejší efekt nižší chybovosti jsou nižší náklady na vývoj [3], jelikož není nutné chyby opravovat. S aplikací bez chyb jsou spokojení i uživatelé.
1.3 Požadavky na produkt
Všechny části produktu musí být pro uživatele intuitivní a musejí dávat smysl. Produkt funguje, pokud všechny možné vstupy vždy vedou ke správnému výstupu. Nevalidní vstupy musí být ošetřeny. Vstupy musí mít ošetřenou délku, včetně délky maximální. Pokud by nebyla omezena maximální délka vstupů, pak se při uložení data nemusí vejít do databáze a jedná se tedy o ztrátu dat. Ztráta dat bez vědomí uživatele je nepřípustná.
1.4 Obecný postup testování
Prvním krokem je analýza aplikace – co aplikace dělá a jakým způsobem je používána. Analýza je specifická pro každý produkt. Pracujeme na produktech určených pro běžné uživatele, pro programátory, produktech pracují s velkými objemy dat, nebo produkty pro velké firmy.
Druhý krok je popis jednotlivých bodů testování do jednodušších částí. Jednodušší část znamená např. vyplnit jméno, heslo a odeslat formulář. V této části píšeme, jaký je očekávaný výstup, např. po přihlášení se otevře stránka s naším jménem.
Třetí krok je sepsání priorit k jednotlivým částem aplikace. Větší prioritu mají složitější části, části často používané a části důležité pro zisk, např. funkčnost nákupního košíku v internetovém obchodě.
Čtvrtý krok je vytváření automatizovaných testů. Jako první se automatizují části s nejvyšší prioritou, to jsou zpravidla obchodní části (objednávání, placení), nebo části kde manuální tes- tování zabírá hodně času. S vývojem aplikace se vyvíjí i testy, vývoj testů je v podstatě nekončící proces.
Dalším krokem je tzv. průběžná integrace (CI - Continuous Integration). Každá změna ve zdrojovém kódu aplikace automaticky spustí testy. O případných chybách v aplikaci je infor- mován tester i programátor, který aplikaci upravil.
12
2 Použité technologie
Tato kapitola stručně popisuje nejčastěji používané technologie. Zbývající kapitoly se na tyto technologie odkazují.
2.1 GIT
GIT je systém na verzování zdrojového kódu. Nejmenší uložená část kódu v systému GIT se na- zývácommit. Commit obsahuje informace o autorovi, datu vytvoření, obsahu souborů a odkazuje na navazující commity [4].
Nové commity se do systému GIT přidávají procesem zvanýmPull Request (PR). Po schvá- lení PR se sloučí poslední verze zdrojového kódu s kódem v PR. V moment, kdy programátor navrhuje PR, se spouští integrační nástroje a provádí se testy. Často bývá schválení PR podmí- něno splněním testů.
2.2 Selenium
Nástroj v jazyce Java, který komunikuje s testovacím programem a prohlížečem. Testovací pro- gram odesílá HTTP požadavky, ve formátu WebDriver protokolu [9]. Selenium požadavek zpra- cuje a přeloží jej na sadu instrukcí, které pošle do prohlížeče. Instrukce se liší dle použitého prohlížeče, protože každý prohlížeč používá jiný způsob automatizace. Po provedení instrukcí Selenium vrátí HTTP odpověď.
Selenium je vrstva mezi testovacím programem a prohlížečem, aby testovací program nemusel implementovat všechny rozdílnosti prohlížečů. Samotný testovací program používá knihovny, jenž umí odesílat požadavky ve formátu WebDriver protokolu [9].
2.3 Appium
Program v jazyce JavaScript, který taktéž komunikuje s testem pomocí WebDriver protokolu [9]
a dokáže ovládat aplikace v mobilních systémech Android a iOS. Program vnitřně používá mnoho dalších programů na dílčí úkoly, jako je hledání zařízení přes USB, instalace aplikace, zaznamenávání událostí atd. Některé dílčí programy nejsou dostupné pro všechny platformy.
Programy pro ovládání iOS jsou součástí pouze vývojářské sady Xcode [1], která je dostupná pouze pro systém MacOS. Pro testování aplikace v systému iOS je nutné mít správně nastavený certifikát vývojáře, jinak zařízení nepovolí testování. Appium dokáže také pracovat s webovou stránkou na mobilním zařízení. Tato funkce však nebyla během praxe potřeba.
2.4 WebdriverIO
Knihovna v jazyce JavaScript. Odesílá příkazy přes WebDriver protokol a přijímá výsledky.
Funkce fungují synchronně, nemusíme tedy čekat na výsledky. Díky tomu jsou testy jednodušší.
2.5 React
React je webový rámec v jazyce JavaScript. Nepoužívá dělení na MVC. Kombinuje JavaScript, HTML a kaskádové styly dohromady. React aplikace je složena z komponent, což jsou znovupo- užitelné, nezávislé části aplikace. Komponenty lze sjednocovat, skládat do jiných komponent a tímto způsobem vytvářet výslednou aplikaci.
2.6 React Native
React Native funguje velmi podobně jako React (kapitola 2.5). Staví na principu znovupouži- telných komponent. Komponenty v rámci React zobrazují elementy díky webovému prohlížeči.
React Native k zobrazování jednotlivých elementů využívá vizuální prvky dostupné v operač- ním systému. Výsledná aplikace graficky působí velmi podobně jako aplikace vyvinutá přímo pro daný systém. Výhodou je znovupoužitelnost komponent, kde lze použít téměř totožný kód pro aplikaci ve webovém prohlížeči, systému Android a iOS.
2.7 Jira
Jira je nástroj na zaznamenávání chyb, návrhů vylepšení i vývojářských úkolů obecně [2].
Převážně je používán pro zaznamenávání chyb. Umožňuje integraci do dalších nástrojů jako např. GIT. Dokáže dohledat commit (viz kapitola 2.1) se změnou, díky tomu se lze podívat na samotnou změnu ve zdrojovém kódu a tím např. identifikovat problém. V systému Jira jsou zaznamenávány nejenom chyby, ale i funkce které je v plánu implementovat.
Chyby i úkoly obecně mají přidělenou prioritu. Pravidla pro prioritu jsou dána vnitřní po- litikou projektu. Na obrázku 1 je znázorněn způsob přidělování priority na projektu Liferay Portal (kapitola 3.3). Priority chyby se odvíjí od závažnosti a pravděpodobnosti. Na obrázku 1 v horním řádku zleva doprava jsou napsány závažnosti triviální,nízká,vysoká,kritická a kata- strofická. V levém sloupci shora dolů jsou napsány pravděpodobnostivzácná,nepravděpodobná, pravděpodobná,velmi pravděpodobná a jistá. Samotné priority jsou číslovány od 1 (velmi nízké riziko) do 5 (velmi vysoké riziko), kde priorita 1 je pro chyby triviální a vzácné a priorita 5 je pro chyby katastrofické a jisté.
2.8 Mocha
Rámec pro psaní testů v jazyce JavaScript. Testy jsou organizovány ve skupinách. Obsahuje funkce, které určují pořadí spouštění kódů, viz výpis 1.
describe(’Název skupiny’, function() {
before(function(){ /* Tento kód bude spuštěn jako první */ });
beforeEach(function(){ /* Tento kód bude spuštěn před každým testem */ });
it(’Název testu’, function(){ /* Testovací kód */ });
afterEach(function(){ /* Tento kód bude spuštěn po každém testu */ });
14
after(function(){ /* Tento kód bude spuštěn po jako poslední */ });
});
Výpis 1: Příklad použití rámce Mocha
LIFERAY PORTAL EE
1
Appendix
SEVERITY
• S1 - No notable loss of functionality; off-by-pixel(s) alignment issues; one-of-kind visual imperfections in lesser used areas of the product
• S2 - Minor loss of functionality - straightforward workaround exists; some impact on user experience; noticeable one-off visual imperfection - typo, alignment, or other UX inconsistency
• S3 - Major loss of functionality - difficult or annoying workaround may exist; very noticeable visual or UX inconsistency; lack of adequate localization
• S4 - Severe memory leak; security issue; significant loss of functionality; likely to lead to server crash/data loss; obvious UI or UX inconsistency;
very high likelihood of preventing or interrupting operations for a client(s)
• S5 - Crashes the server; corrupts/loses data; total loss of product functionality; certainty of disrupting live or go-live operations for client(s)
LIKELIHOOD
• L1 - Only occurs in a very specific set of circumstances; occurs in a configuration or environment that clients and users are not on; involves a difficult to invoke race condition; issue occurs in a functional area of the product that is very rarely used
• L2 - Occurs in a specific set of circumstances; issue only occurs in a small subset of environments/configurations that clients use; involves a race condition; involves product functionality that is infrequently used
• L3 - Occurs in some common circumstances; does not require complex setup to reproduce; occurs in some of the most commonly used environments; involves components of the product that some users will utilize
• L4 - Is very likely to occur for most users; occurs across several certified environments; issue involves components of the product that most users will likely utilize
• L5 - Occurs within 5 clicks of using the product; occurs across all certified environments; Involves components of product that many customers are confirmed to utilize
Risk Assessment Matrix
Severity: How severe is this issue that I have discovered?
Trivial S1
Minor S2
Major S3
Critical S4
Catastrophic S5
Likelihood: How likely or easily reproducible is this issue?
Rare L1
Very Low Risk 1
Very Low Risk 1
Low Risk 2
Moderate Risk 3
Moderate Risk 3
Unlikely L2
Very Low Risk 1
Low Risk 2
Moderate Risk 3
Moderate Risk 3
High Risk 4
Likely L3
Low Risk 2
Moderate Risk 3
Moderate Risk 3
High Risk 4
Very High Risk 5
Very Likely L4
Moderate Risk 3
Moderate Risk 3
High Risk 4
Very High Risk 5
Very High Risk 5
Certain L5
High Risk 4
High Risk 4
Very High Risk 5
Very High Risk 5
Very High Risk 5
Obrázek 1: Přidělování priorit na projektu Liferay
3 Souhrn projektů
Tato kapitola je věnována jednotlivým projektům, které tvořily součást praxe.
3.1 Mulesoft Anypoint studio
Zákazník Mulesoft vyvíjí desktopovou aplikaci Anypoint studio, kde lze pomocí grafického roz- hraní vytvořit program, jenž pracuje s vstupy a výstupy. Program se skládá s pomocí bloků, kde každý blok provádí jeden úkon, např. práce s databází, e-mail, http server. Také lze do- programovat vlastní blok. Pomocí aplikace lze nahrát program na servery firmy Mulesoft, kde se automaticky škáluje a přizpůsobí se množství dat. Anypoint studio je nadstavbou prostředí Eclipse1. Z nastavených bloků v uživatelském rozhraní generuje kód v jazyce Java.
Mým úkolem bylo seznámit se s aplikací Anypoint studio a najít v ní chyby. V průběhu jsem dospěl k závěru, že bude jednodušší najít chyby při vytváření konkrétního projektu.
Zpracoval jsem program, kde se čtou commity (viz kapitola 2.1) ze služby GitHub2 a jejich textový popis se posílá na službu Twitter3. Podrobný návod, jak program vytvořit, jsem popsal na blogu [8]. Výsledný program v grafickém zobrazení je na obrázku 2.
Obrázek 2: Program v Anypoint studio
Program v obrázku 2 se skládá pouze pomocí bloků. Bloky jsou vstupní nebo výstupní. První blok (Github Webhooks na obr. 2) dostane informaci o nové operaci commit. Blok je nastaven, aby čekal na HTTP požadavek a předal jej dalším blokům. BlokJSON to Object transformuje
1Vývojové prostředí
2Vývojová platforma pro GIT
3Sociální síť na principu posílání krátkých zpráv
16
data z HTTP požadavku na vnitřní formát. Dále blokEvent namevytvoří proměnnou obsahující název události, o které GitHub informuje. V blokuChoice eventse program dělí na dvě možnosti, buď událost nese informace o operaci commit a data se pošlou do dalšího bloku, nebo jde o jinou událost a data se zahodí. Pro každý commit se vytvoří proměnná s textem pro Twitter a pošle se doTwitter Flow, kde se text uloží do souboru a odešle se na Twitter. Z výsledných dat se vytvoří proměnná s odpovědí na HTTP požadavek a HTTP konektor odešle odpověď.
Když odpověď obsahuje potvrzení přijetí, GitHub bere událost za vyřízenou. Pokud ne, GitHub bude HTTP požadavek pravidělně opakovat, dokud nedojde k potvrzení.
3.2 SlamData
Zákazník SlamData vyvíjí produkt, se kterým lze ve webovém prohlížeči nastavit a zobrazit souhrnná data z databáze. Mým úkolem bylo pochopit jak produkt funguje a začít s automatizací testů.
Produkt je napsán v jazyce PureScript, což je funkcionální jazyk, ze kterého se vygeneruje kód v jazyce JavaScript. Mým úkolem bylo najít v aplikaci chyby a rozvíjet automatizované testy.
Pochopit, jak kód funguje, bylo poměrně komplikované, protože jsem se s funkcionálním pro- gramováním setkal poprvé. Studoval jsem proto Haskell a principy funkcionálního programování obecně. Jazyk PureScript umožňuje přidávat vlastní operátory a umožňuje také používat speci- ální znaky v operátorech (např.←,⋃,⋂,⨀), což komplikuje čtení kódu bez znalosti významu operátorů. Proto jsem převážně testoval aplikaci manuálně (tj. bez automatických testů).
Ve výpisu 2 je test přejmenování složky. Vytvoří se složka, přejmenuje se a otestuje, že pře- jmenovaná složka existuje.
test :: SlamFeature Unit test = do
connector <- getConnector
fileScenario afterRename "Rename a folder" noIssues do Interact.createFolder
Interact.renameFileOrFolder "Untitled Folder" "Patients"
Expect.noRenameErrorFor "Patients"
successMsg "** Successfully ran Renamed a folder test **"
Výpis 2: Příklad testu přejmenování složky ve funkcionálním jazyce PureScript
3.3 Liferay Portal
Firma Liferay vyvíjí produkt Liferay Portal. Produkt je určen pro velké firmy, aby na něm posta- vily své portálové řešení. Portál obsahuje funkce pro správu webového obsahu, blogu, nápovědy, souborů, vyhledávání, dynamických dat a další. Má práce obnášela procházení a sepisování funkcí
Na obr. 3 je nahlášená chyba, kde stránka vrátí chybový stav 414. Tuto chybu jsem odhalil při plánovaném ručním testováním portálu. K chybě dochází, když uživatel odešle formulář s daty ve špatném formátu a poté klikne na odkaz na jinou sekci nastavení. Portál vloží neuložené hodnoty do adresy stránky. To vede k chybě 414 (adresa stránky je příliš dlouhá), pokud formulář obsahuje velké množství dat.
Obrázek 3: Nahlášená chyba v systému Liferay
18
4 Projekt DivvyPay
Firma DivvyPay vyvíjí produkt pro správu a přerozdělování peněz v rámci organizací [5]. Je kla- den velký důraz na bezpečnost, protože systém sdílí data s bankou a zpracovává platební trans- akce. Systém funguje v souladu se standardem PCI4 pro práci s kreditními kartami [6].
4.1 Teoretické principy služby
Pro jednodušší pochopení, jak DivvyPay funguje, jsem zvolil popis systému na reálném příkladu.
Takto funguje běžná firma bez využití služeb DivvyPay:
• Firma má zaměstnance, kterým přiděluje peníze na služební cesty.
• Každý zaměstnanec má firemní kreditní kartu, kde je nastaven limit útraty.
• Pokud chce firma přidat účtenku do nákladů, musí ji zaměstnanec uschovat a předat účetní.
Tato firma s použitím služeb DivvyPay by fungovala takto:
• Firma má zaměstnance. Vedoucí pracovníci mohou prostřednictvím aplikace nastavit útratu zaměstnancům.
• Každý zaměstnanec má DivvyPay fyzickou kreditní kartu a současně mobilní aplikaci, se kterou lze provádět platby.
• Zaměstnanci po každé platbě vyfotí přes mobilní aplikaci účtenku. Účetní dostane souhrn transakcí.
4.2 Testování mobilní aplikace
Jak je z kapitoly 4.1 zřejmé, uživatelé budou nejčastěji používat mobilní aplikaci. Mobilní apli- kace má velkou prioritu pro vývoj i testování, zejména aby šla používat jednoduše a přirozeně.
Aplikace pro účely testování je sestavena tak, aby komunikovala pouze s testovacím serverem.
Aplikace nekomunikuje s produkčními servery a proto nehrozí přečtení nebo poškození citlivých osobních údajů. Cílem praxe bylo objevit v aplikaci chyby a přijít na zlepšení a zjednodušení.
Průběh testování probíhal opakovaně obvykle podle následujícího scénáře:
1. Nainstalovat novou verzi aplikace na Android a iOS, viz kapitola 4.2.1
2. Zkontrolovat úkoly ze systému Jira, které jsou ve stavuČeká na otestování, viz 4.2.2 3. Ruční testování aplikace podle plánu, viz 4.2.3
4. Automatizace testů na Android a iOS, viz 4.2.4
4Bezpečnostní standard pro práci s citlivými daty
4.2.1 Aktualizace mobilní aplikace
Každý den se automaticky z poslední verze zdrojových kódů sestaví aplikace a nahraje se do HockeyApp a TestFlight5. Díky tomu máme každý den přístup k nové verzi aplikace. Pro- střednictvím aplikací HockeyApp v systému Android a TestFlight v iOS lze aplikaci DivvyPay nainstalovat přímo ze zařízení. Vývoj DivvyPay je poměrně dynamický, průběžně vznikají nové funkce a opravují se chyby, je proto nutné mít vždy k dispozici poslední sestavení aplikace.
4.2.2 Testování opravených chyb a nových funkcí
V systému Jira (viz kapitola 2.7) na projektu DivvyPay spolupracuje přibližně 20 zaměstnanců, byl jsem pověřen otestovat úkoly ve stavuČeká na otestování. Typicky se testují 2 typy úkolů:
Nové funkce Vývojový proces je nastaven tak, že každá nová funkce musí být otestována a potvrzena, že je bez chyb. Do té doby nesmí být vložena do stabilního kódu aplikace.
Pokud nová funkce obsahovala chyby, bylo nutné přidat komentář, v čem konkrétně je chyba a úkol nastavit do stavu Čeká na vývoj.
Chyby V případě chyby se testuje, že za stejných podmínek chyba již nenastává a současně, že opravou původní chyby nevznikla chyba nová. Pokud chyba není opravena, přidáme komentář, že chyba setrvává a vrátíme chybu do stavu Čeká na opravení.
Tomuto vývojovému procesu se přezdívá Agilní vývoj. Jde o vývoj v iteracích, kdy se produkt malými kroky denně posouvá kupředu. Vývoj je efektivnější s rychlejší a kvalitnější komunikací, jako je upřesňování chyb a odpovídání na otázky co nejrychleji.
4.2.3 Ruční testování aplikace
Podle plánu jsem pravidelně prováděl manuální testování aplikace. Testuje se současně na sys- témech Android a iOS. Každý týden se používají jiné verze mobilního systému, aby se pokrylo co nejvíce verzí na trhu.
iOS má na trhu pouze desítky zařízení, zato Android má více než 4000 zařízení6 [7]. Proto jsem aplikaci pro Android testoval na vícero zařízeních s různým rozlišením obrazovky a různou verzí systému.
Pro každou část aplikace (např. přihlášení) jsem prvně sepsal konkrétní kroky, tzv.test case, jak aplikaci otestovat. A poté jsem aplikaci otestoval a chyby nahlásil do systému Jira (viz ka- pitola 2.7). Na obrázku 4 je částečně vyplněná tabulka s testy. Testy bez chyby jsou označeny zeleně s textem Passed a testy s chybou, jsou označeny červeně s textem Failed. Testy, které ještě nebyly provedeny jsou označeny s textemNot Run. Chyby s nejvyšší prioritou (např. apli- kace přestane pracovat) jsem nahlásil zodpovědné osobě v DivvyPay, aby chyba mohla být co nejrychleji opravena.
5Nástroje pro distribuci aplikace
6Ke konci roku 2015
20
Login functionality
LOGIN_001 Login with valid employeed credentials PASSED PASSED
LOGIN_002 Login with valid manager credentials NOT RUN PASSED
LOGIN_003 Login with empty email and empty password NOT RUN PASSED
LOGIN_004 Login with invalid email - non existing user NOT RUN PASSED
LOGIN_005 Login with invalid email - non email format NOT RUN PASSED
LOGIN_006 Login invalid email - with special characters NOT RUN PASSED
LOGIN_007 Login valid email - very long email (at least 20 characters) NOT RUN PASSED
LOGIN_008 Login with valid email - very short mail (a@a.cz) NOT RUN PASSED
LOGIN_009 Login with just email (leave password empty) NOT RUN PASSED
LOGIN_010 Login with invalid password - very long (at least 20 characters) NOT RUN PASSED
LOGIN_011 Login with invalid password - short one NOT RUN PASSED
LOGIN_012 Login with invalid password - with special characters NOT RUN PASSED
LOGIN_013 Login with valid password - very long (at least 20 characters) NOT RUN NOT RUN
LOGIN_014 Login with valid password - with special characters NOT RUN NOT RUN
LOGIN_015 Login with just password (leave email field empty) NOT RUN PASSED
LOGIN_016 Login from another device with alredy logged user NOT RUN NOT RUN
LOGIN_017 Reset password with invalid email NOT RUN PASSED
LOGIN_018 Reset password with not registered email NOT RUN FAILED
LOGIN_019 Reset password with valid email NOT RUN NOT RUN
LOGIN_020 Working button Forgot your password? NOT RUN FAILED
Obrázek 4: Výsledek ručního testování v tabulce
DEFECT ID 003
PRIORITY Bug
SYNOPSIS Application not resized after rotation portrait <-> landscape DESCRIPTION
Android 6.0.1
Application version 0.0.0-7d4a39f REPORTED BY Michal
DEFECT ID 004
PRIORITY Bug
SYNOPSIS Application has stopped in offline
DESCRIPTION Exists many situations, where application has stopped, if is offline.
1. On show list of activities 2. On open activity 3. On show teams REPORTED BY Michal
DEFECT ID 005
PRIORITY SYNOPSIS DESCRIPTION REPORTED BY
Obrázek 5: Příklad chyby mobilní aplikace DivvyPay
Obrázek 5 obsahuje příklad chyby, kde se aplikace neumí přizpůsobit režimu na šířku.
4.2.4 Automatizace testování
Systémy Android a iOS mají mnoho rozdílů a nejsou mezi sebou kompatibilní. Proto je potřeba mít zvláštní konfiguraci pro oba systémy.
21
Výhodou systému Android je otevřenost. Existuje mnoho nástrojů, které se systémem umí pracovat. Nástroje pro Android jsou dostupné pro Linux, MacOS i Windows.
{
’appium-version’: ’1.6’,
platformName: ’Android’, deviceName: ’...’,
appPackage: ’com.divvypay.Divvy.test’, appActivity: ’com.divvypay.MainActivity’, name: ’Android’,
}
Výpis 3: Konfigurace automatických testů na systému Android
K automatizaci používáme nástroj Appium, viz kapitola 2.3. Výpis 3 obsahuje konfigu- raci pro systém Android. Parametr deviceName je povinný, ale s jedním připojeným zařízením přes USB se parametr ignoruje. Pokud Appium nenajde reálné zařízení splňující požadavky, automaticky spustí emulátor.
Oproti otevřenému systému Android, je systém iOS uzavřený a vývojář musí splnit určité požadavky. Pro vývoj a testování aplikací na iOS je nutné mít nainstalován program Xcode, který je dostupný zdarma a pouze pro systém MacOS. Aby šlo aplikaci nahrát do zařízení, musí být aplikace podepsaná platným certifikátem vývojáře a zařízení musí být na seznamu povolených pro vývoj. Princip povolených zařízení obchází oficiální aplikace TestFlight od společnosti Apple, která umožňuje nahrát aplikaci až na 10 tisíc zařízení. Bohužel aplikace TestFlight není vhodná k distribuci ovladače, který Appium používá.
{
platformName: ’iOS’,
automationName: ’XCUITest’,
xcodeOrgId: ’W4B7EB9LW5’, // id organizace xcodeSigningId: ’iPhone Developer’,
// Cesta k aplikaci nebo klíč aplikace
// app: ’DivvyPay.app’, // Nainstaluje aplikaci
bundleId: ’com.divvypay.Divvy.test’, // Použije existující aplikaci
// iOS verze na zařízení platformVersion: ’11.0’,
// Použití simulátoru nebo reálného zařízení
deviceName: ’iPhone 6’, // Název zařízení v simulátoru
udid: ’7837bc45a6106d8584e82d000efb451f998b729e’ // Identifikátor zařízení
22
}
Výpis 4: Konfigurace automatických testů na systému iOS
Výpis 4 obsahuje konfiguraci pro iOS. Pokud je v konfiguraci uvedeno udid (unikátní iden- tifikátor zařízení), použije se reálné zařízení. Pokud ne, použije se simulátor. Android emulátor a iOS simulátor fungují odlišně, proto zde uvádíme jejich stručné srovnání:
Android emulátor Emulátor emuluje hardware a běží na něm plná verze systému Android.
Výhodou je, že aplikace bude fungovat stejně. Totožné sestavení aplikace lze spustit v emu- látoru i na reálném zařízení.
iOS simulátor V simulátoru běží systém iOS sestaven pro počítačový hardware. Výhodou je, že je mnohem rychlejší oproti Android emulátoru. Na simulátor se dá nainstalovat pouze aplikace, která byla pro simulátor sestavena. Není tedy možné nainstalovat stejné sestavení aplikace, jako pro reálné zařízení.
Automatizované testy simulují uživatelskou interakci skrze grafické uživatelské rozhraní, tj. např. kliknutí na tlačítko, vepsání textu do textového pole apod. Problémem bylo, že tlačítka a vstupy neměly v kódu přímé identifikátory. Musely se tedy psát identifikátory, jako celá cesta k tlačítku (viz první část výpisu 5). Při změně aplikace se změnila i cesta a test přestal fungo- vat. Proto jsme požádali vývojáře DivvyPay, aby do kódu aplikace přidali přímé identifikátory (viz druhá část výpisu 5). Poté se výrazně zvýšila stabilita testů.
# Identifikátor jako XPath cesta
//XCUIElementTypeApplication[1]/XCUIElementTypeWindow[1]/XCUIElementTypeOther [2]/XCUIElementTypeOther[1]/XCUIElementTypeOther[1]/XCUIElementTypeOther [1]/XCUIElementTypeOther[2]/XCUIElementTypeOther[1]/XCUIElementTypeOther [2]/XCUIElementTypeOther[3]
# Identifikátor jako unikátní id
~LOGOUT
Výpis 5: Identifikátor elementu jako celá cesta vs. id
V automatizovaných testech jsem pracoval s testovacím nástrojem Mocha (viz kapitola 2.8).
V testech se zásadně vyhýbáme přímého použití adresace prvků v aplikaci, kdyby došlo v aplikaci ke změně, museli bychom najít všechny místa kde je uložena adresa prvku. Místo toho používáme třídu, ve které jsou uloženy všechny potřebné adresy prvků a všechny testy třídu používají.
Se změnou aplikace stačí změnit adresy v jedné třídě.
it(’LOGIN_019 Reset password with valid email’, () => { const email = ’qadivvypay+test.email@gmail.com’;
resetPassword.click();
const emailInput = $(Locator.authResetEmail);
emailInput.setValue(email);
browser.hideDeviceKeyboard();
if (browser.isAndroid) $(Locator.text(’SEND’)).click();
$(Locator.text(’Password Reset Request Successful’), 10000);
const gmail = new Gmail();
return gmail.waitForEmail(email) .catch(() => {
throw new Error(’Missing email’);
});
});
Výpis 6: Test resetu hesla přes e-mail Test ve výpisu 6 funguje následujícím způsobem:
1. Test počká, až se v mobilní aplikaci objeví tlačítko pro reset hesla, a poté na něj klikne.
2. Test zadá e-mail, na který je účet registrován.
3. Test skrze Appium (viz kapitola 2.3) zavře SW klávesnici, což funguje stejně, jako když uživatel klikne na tlačítko potvrzení (vpravo dole na klávesnici).
4. Na systému iOS nelze ve formuláři pouze zavřít klávesnici, protože zavřením se formu- lář odešle. Proto na systému Android musí být formulář odeslán dodatečně, kliknutím na odesílací tlačítko.
5. Test čeká, než se v aplikaci zobrazí text o potvrzení resetování hesla. Limit na čekání je 10s.
6. S použitím služby Gmail7 se čeká na příchozí e-mail.
7. Přijde-li e-mail do nastaveného časového limitu, test je označen za úspěšný, pokud e-mail nepřijde, test je neúspěšný.
Test je plně automatizovaný včetně čekání na příchozí e-mail. Samotný obsah e-mailu nemá vliv na výsledek testu, záleží pouze, zda-li e-mail dorazí na určenou adresu.
7Služba na e-maily od společnosti Google
24
Vzhledem k odlišnosti obou systému bylo v určitých případech nutné použít jiný kód pro daný systém. Při vývoji testů je vhodné testovat na systémech Android a iOS současně, ověříme tím funkčnost testů a aplikace v obou systémech.
Testy dokáží zpracovávat příkazy velmi rychle, proto test musí často před kliknutím na tla- čítko počkat, než se tlačítko zobrazí. Mobilní aplikace často používá asynchronní načítání dat přes internet a nějakou dobu trvá, než se data a uživatelské rozhraní načte. Pokud test nepočká, Appium hledané tlačítko nenajde a příkaz v testu skončí chybou.
4.3 Testování webové stránky pro vedoucí organizace
Vedoucí organizace má k dispozici webovou stránku, kde může spravovat zaměstnance, pracovat s rozpočtem (viz obr. 6), procházet transakce, atd.
Obrázek 6: Správa rozpočtu ve webové aplikaci pro vedoucí organizace
Práce s webovou stránkou pro vedoucí organizace probíhala obdobně, jako s mobilní aplikací, s tím rozdílem, že webovou stránku je možné otevřít v prohlížeči na počítači a dá se s ní pracovat mnohem pohodlněji. Vývoj testů je rychlejší, protože se dá jednoduše dostat do vývojářské konzole. Testy lze také spouštět paralelně, např. v 5-ti oknech prohlížeče současně. Testy také lze spustit na více prohlížečích současně, limitem bývá velikost operační paměti a výkon procesoru.
Snazší je také nastavení prostředí tak, aby bylo možné automatické testy spouštět. Jedinou externí závislostí testů je webový prohlížeč, zbylé závislosti se stáhnou automaticky přes NPM
Webová stránka se testuje s použitím nejnovější verze webového prohlížeče. Testuje se na pro- hlížečích podle zastoupení trhu. Střídá se testování na prohlížečích Chrome, Firefox, Safari, Internet Explorer a Edge.
Testy je možné spustit přes internet na vzdáleném zařízení, nebo na testovacích serverech.
Reálně jsem tuto funkci v rámci praxe nepoužil. V dlouhodobém horizontu bylo plánováno testy spouštět na serverech externí služby. Běžely by současně na mnoha prohlížečích a výsledky by byly známy velmi rychle. Mít rychlé výsledky se hodí zejména v pokročilé integraci, kde je čekání nepohodlné a zpomaluje vývojáře v práci.
4.4 Testování webové stránky pro systémové administrátory
Stránka je určena pro zaměstnance DivvyPay, aby mohli kontrolovat a upravovat konfiguraci jednotlivých organizací. Jelikož je pouze pro interní použití, není stránka přímo dostupná z inter- netu. Tuto stránku jsem používal spíše k testování jiných částí systému, než k testování stránky samotné.
Nejčastěji jsem používal formulář pro přidávání transakcí (obrázek 7), většinou v souvislosti s testováním mobilní aplikace (viz kapitola 4.2.2). Mnoho testů vyžaduje přidávání transakcí v průběhu testování. Simulátor je jedinou možností, jak toho dosáhnout, protože v testovacím prostředí nelze reálně platit, jelikož čísla virtuálních kreditních karet jsou náhodně generovaná.
Obrázek 7: Formulář pro přidávání transakcí v testovacím prostředí
Dále jsem používal formulář pro přidávání nové organizace. Ve formuláři jsem nastavil e-mail administrátora organizace a po odeslání formuláře jsem ručně jsem ověřil, zda e-mail přišel, fungují v něm odkazy a text e-mailu dává smysl. V e-mailu jsem použil odkaz pro dokončení registrace, zadal jsem všechny potřebné údaje a registraci dokončil. Po dokončení registrace jsem přidal do organizace zaměstnance, abych otestoval, že celý proces s přidáváním organizace
26
funguje. Vývojáři DivvyPay tento proces často optimalizovali, aby případná chyba neodradila potencionální zákazníky. Kontroloval jsem tedy změny v tomto procesu.
4.5 Testování platebních karet v reálném prostředí
V testovacím prostředí nelze otestovat platbu kartou. Hledal jsem proto způsob, jak zaplatit kartou v reálném prostředí co nejmenší částku přes internet. Jako nejlepší řešení jsem našel postup, kdy je možné zaplatit libovolnou částku větší než $0.03 v obchodě HumbleBundle8. Poté jsem testoval platby v reálném prostředí s použitím vygenerovaných čísel kreditní karty z mobilní aplikace. Testování probíhalo následujícím způsobem:
1. V mobilní aplikaci (na produkčním prostředí) jsem vytvořil rozpočet s částkou $0.05.
2. Do aplikace jsem zadal co a proč chci zaplatit. Obdržel jsem čísla virtální kreditní karty.
3. V obchodě HubleBundle jsem zadal čísla karty z aplikace a zaplatil jsem částku $0.03.
4. Zkontroloval jsem, že v aplikaci na útratu zbývá $0.02.
5. Pokusil jsem se provést další platbu s tím, že obchod HumbleBundle objednávku zrušil, protože na kartě nebyl dostatečný zůstatek.
Dále jsem kontroloval, že informace v transakci odpovídají zadané částce a datu. Tím jsem odhalil chybu, kde čas transakce je o 8 hodin menší než čas, kdy jsem transakci provedl. Chyba je způsobena tím, že vývojáři zapomněli přepočítávat čas v aplikaci podle nastavené časové zóny v zařízení. Ověřil jsem také, že informace o transakci z mobilní aplikace se shodují s informacemi z webové stránky pro vlastníka organizace. V plánu bylo také testovat fyzické platební karty, to se bohužel v průběhu praxe nestihlo.
5 Závěr
Hlavním cílem této práce bylo popsat činnosti, které jsem vykonával během bakalářské praxe formou individuální odborné praxe.
Podílel jsem se na Agilním vývoji a přesvědčil jsem se o tom, jak dokáže dobrá komunikace zefektivnit vývoj. Byl jsem součástí týmu, který hlídá kvalitu produktů a hlásí jakékoli chyby i náměty pro zlepšení. Dobrých výsledků jsme dosahovali i díky kvalitní týmové spolupráci, což pro mě mělo velký přínos, neboť jsem do té doby ještě v týmu nepracoval.
Díky práci na více projektech jsem se seznámil s mnoha technologiemi a naučil se pracovat s jazykem JavaScript. K tomu mi pomohly školní předměty, jako jsou Softwarové inžerýství, Vývoj informačních systémů, Počítačové sítě, Tvorba aplikací pro mobilní zařízení a Správa ope- račních systémů. Při psaní této práce jsem využil znalostí z předmětu Elektronické poblikování.
Během praxe jsem hodně komunikoval v anglickém jazyce, který jsem se učil i ve škole.
V rámci praxe jsem se potkal zcela poprvé s funkcionálním programováním. Také jsem denně používal systém GIT a ocenil bych předmět, který by se tímto systémem zabýval. Osobně jsem GIT používal i na školních projektech, což mi usnadnilo práci především v oblasti zálohování kódu a také v kontrole provedených změn. V rámci praxe bylo použití verzovacího systému (v mém případě GIT) nutností pro správu zdrojového kódu, do kterého přispívalo více lidí z týmu.
Absolvování praxe pro mě bylo velkým přínosem a do budoucna počítám se zaměstnáním podobného typu, jakého byla praxe.
28
Literatura
[1] Apple Inc.: Xcode - Apple Developer. Dostupné z: <https://developer.apple.com/
xcode/>, [cit. 16. 4. 2018].
[2] Atlassian: Jira | Issue & Project Tracking Software | Atlassian. Dostupné z: <https://www.
atlassian.com/software/jira>, [cit. 16. 4. 2018].
[3] BUREŠ, Miroslav, Miroslav RENDA, Michal DOLEŽEL, Peter SVOBODA, Zdeněk GRÖSSL, Martin KOMÁREK, Ondřej MACEK a Radoslav MLYNÁŘ: Efektivní testo- vání softwaru: klíčové otázky pro efektivitu testovacího procesu. Praha: Grada, 2016, ISBN 9788024755946, str. 180.
[4] CHACON, Scott: Pro Git: [everything you need to know about the Git distibuted source control tool]. New York, NY: Apress, 2014, ISBN 978-1-4842-0076-6.
[5] DivvyPay, Inc.: Simple Expenses and Business Budgeting App | Divvy Pay Inc. Dostupné z:
<https://getdivvy.com/>, [cit. 16. 4. 2018].
[6] DivvyPay, Inc.: Terms and Conditions - Divvy. Dostupné z: <https://getdivvy.com/
terms-and-conditions/>, [cit. 16. 4. 2018].
[7] Google: Official Google Blog: S’more to love across all your screens. Dostupné z: <https://
googleblog.blogspot.cz/2015/09/smore-to-love-across-all-your-screens.html>, [cit. 16. 4. 2018].
[8] profiq inc.: Be informed about GitHub commits via Twitter » profiq. Dostupné z: <https://
www.profiq.com/be-informed-about-github-commits-via-twitter/>, [cit. 16. 4. 2018].
[9] W3C: WebDriver. Dostupné z: <https://www.w3.org/TR/webdriver/>, [cit. 16. 4. 2018].
