Miika Eronen
ALUSTARIIPPUMATON AUTOMAAT- TINEN SOVELLUSTESTAUS ROBOT
FRAMEWORKIN AVULLA
Tekniikka
2019
TIIVISTELMÄ
Tekijä Miika Eronen
Opinnäytetyön nimi Alustariippumaton automaattinen sovellustestaus Robot Frameworkin avulla
Vuosi 2019
Kieli suomi
Sivumäärä 57
Ohjaaja Pirjo Prosi
Tämä opinnäytetyö on tehty toimeksiantona Vaasassa toimivalle ohjelmistoalan yritykselle Devatukselle. Opinnäytetyön tarkoituksena oli toteuttaa ohjelmistopro- jektissa kehitettävälle sovellukselle uusi alustariippumaton automatisoitu testaus- järjestelmä, joka korvaisi projektissa käytetyn vanhan järjestelmän. Vanha auto- matisoitu testausjärjestelmä käyttää sovelluksen alustojen välillä useita erilaisia tekniikoita, mikä saattaa heikentää testituloksien vertailukelpoisuutta. Työn tavoit- teena oli toteuttaa sovelluksen käyttöliittymän automatisoitua testausta varten uusi järjestelmä, mikä käyttää testaamiseen samaa työkalua sovelluksen alustasta riip- pumatta.
Tässä opinnäytetyössä selvitetään, kuinka Robot Frameworkin avulla saadaan luo- tua mahdollisimman vertailukelpoisia testejä kahden eri alustalla toimivan sovel- luksen välille käyttäen erilaisia testauskirjastoja. Samalla käydään läpi, kuinka Robot Frameworkilla suoritetaan testejä, sekä miten sen tuottamia testituloksia luetaan. Opinnäytetyön teoriaosuudessa esitellään testauksen eri tasoja, sekä käy- dään läpi työssä käytettyjä menetelmiä ja työkaluja.
Opinnäytetyön tuloksena suunniteltiin ja toteutettiin ohjelmistoprojektille uusi au- tomatisoitu testausjärjestelmä, joka tuottaa vertailukelpoisia testituloksia käyttö- alustojen väliltä. Testattavan sovelluksen käyttöalustoina toimii Windows–
käyttöjärjestelmällinen tietokone, sekä mobiililaite, jonka käyttöjärjestelmänä toimii Android.
Avainsanat Robot Framework, testausautomaatio, ohjelmistotestaus, Android
Information Technology
ABSTRACT
Author Miika Eronen
Title Platform-independent Automated Application Testing with Robot Framework
Year 2019
Language Finnish
Pages 57
Name of Supervisor Pirjo Prosi
This thesis was commissioned by Devatus, a software company located in Vaasa.
The purpose of this thesis was to implement a new platform-independent automat- ed testing system for the application that is being developed in a software project, which would replace the old automated testing system used in that project. The old system uses several different techniques and tools between application plat- forms, which may weaken the comparability of the test results. The aim of the work was to implement a new system for automated testing of the application, which uses the same tool for testing regardless of the application platform.
This thesis will explain how Robot Framework can be utilized for creating as comparable tests as possible between applications that are used in two different platforms, which uses different test libraries. At the same time, we look at how the testing is done with Robot Framework and how the test results it produces can be read. The theoretical part of the thesis contains more information about testing and the methods and tools that are used in the thesis.
As a result of this thesis, a new automated testing system was designed and im- plemented for the software project, which produces comparable test results be- tween the operating platforms. The platforms for the application that is being test- ed are desktop computer that uses Windows as its operating system, and a mobile device with Android as its operating system.
Keywords Robot Framework, automated testing, application testing and An- droid
TIIVISTELMÄ ABSTRACT
KUVA- JA TAULUKKOLUETTELO
1 JOHDANTO ... 9
2 TEKNOLOGIAT JA TYÖKALUT ... 10
2.1 Lyhenteitä ja avainsanoja ... 10
2.2 Visual Studio Code ... 12
2.2.1 Visual Studio Code – laajennukset ... 12
2.3 Git ... 13
2.4 Python ... 13
2.5 Selenium ... 13
2.6 Appium ... 14
2.7 Chromedriver ... 14
3 TESTAAMINEN ... 16
3.1 Testauksen tasot ... 16
3.1.1 Yksikkötestaus ... 16
3.1.2 Integraatiotestaus... 16
3.1.3 Validaatiotestaus ... 17
3.1.4 Järjestelmätestaus ... 17
3.2 Manuaalinen testaus ... 17
3.3 Automaattinen testaus ... 18
4 ROBOT FRAMEWORK ... 19
4.1 Mikä on Robot Framework? ... 19
4.2 Avainsanat... 19
4.3 Kirjastot... 20
4.3.1 Standardikirjastot ... 21
4.3.2 Ulkoiset kirjastot ... 22
4.3.3 Kirjastojen käyttäminen ... 23
5 TOTEUTUS ... 26
5.1 Käytetyt työkalut ... 26
5.2 Kirjastot... 27
5.4.1 Esivalmistelut ... 29
5.4.2 Android Debug Bridge ... 29
5.4.3 ADB Shell ja natiivisovelluksien löytäminen ... 30
5.4.4 UI Automator Viewer ... 31
5.4.5 Laitteen käyttöönotto ja sovelluksen käynnistäminen Robot Frameworkilla ... 32
5.4.6 Testien kirjoittaminen ... 35
5.5 Sovelluksen testaus Windows-ympäristössä... 40
5.5.1 AutoItLibrary & AutoIt v3 Window Info ... 40
5.5.2 Testien kirjoittaminen ... 42
5.6 Testien ajaminen ... 46
5.7 Testitulokset ... 48
5.8 Vertailukelpoiset testitulokset molemmilta alustoilta ... 50
6 JOHTOPÄÄTÖKSET JA POHDINTA ... 53
LÄHTEET ... 55
KUVA- JA TAULUKKOLUETTELO
Kuva 1. Käyttäjän luoma avainsana ”Change Language To Deutsch”. ... 20
Kuva 2. Käyttäjän luoma avainsana "Change Language To Deutsch" osana testitapausta. ... 20
Kuva 3. Kirjastojen määrittäminen tiedoston sisällä. ... 24
Kuva 4. Kirjaston määrittäminen avainsanan yhteydessä. ... 25
Kuva 5. Kirjastojen järjestys “Set Library Search Order” avainsanalla. ... 25
Kuva 6. Android Debug Bridgen komento laitteiden listaamiseen. ... 30
Kuva 7. Android Debug Bridgen komento laitteiden listaamiseen tarkemmilla tiedoilla. ... 30
Kuva 8. Android Debug Bridgen komento laitteen tietojen yksityiskohtaiseen tulostukseen. ... 30
Kuva 9. Android-natiivisovelluksen paketin nimen löytäminen. ... 31
Kuva 10. UI Automator Viewer – kuvakaappauksen ottaminen laitteen näkymästä ... 31
Kuva 11. UI Automator Viewer - kuvankaappaus laitteen näkymästä ... 32
Kuva 12. Käyttäjän luoma avainsana Get Android Devices. ... 33
Kuva 13. Käyttäjän luoma avainsana Appium-palvelimen käynnistämiseen ... 34
Kuva 14. Appium-palvelimen käynnistämiseen käytetty komento ... 34
Kuva 15. Käyttäjän luoma avainsana mobiilisovelluksen avaamiseen. ... 35
Kuva 16. Käyttäjän luoma avainsana Appium-palvelimen tarkastamiseen. ... 35
Kuva 17. Käyttäjän luoma avainsana "Start Application" pitää sisällään kaikki tarvittavat avainsanat sovelluksen käynnistämistä varten. ... 35
Kuva 18. Testi muistion toiminnallisuuden varmistamiselle. ... 36
Kuva 19. UI Automator Viewer - työkalun käyttäminen elementtien paikantamiseen. ... 37
Kuva 20. Käyttäjän luoma avainsana uuden dokumentin luomiselle... 37
Kuva 21. Käyttäjän luoma avainsana tekstin syöttämiselle. ... 38
Kuva 22. Käyttäjän luoma avainsana tekstin tallentamiseen muistiosovelluksessa. ... 39
Kuva 23. Käyttäjän luoma avainsana sovelluksen yläpalkin tekstin todentamiseen.
... 39
Kuva 24. Muistiosovelluksen näkymä avainsanan ”Save Text” jälkeen. ... 39
Kuva 25. Ohjelman Au3Info sijainti. ... 41
Kuva 26. Au3Info käytössä. ... 41
Kuva 27. Kirjaston AutoItLibrary liittäminen tiedostoon. ... 42
Kuva 28. Testitapaus työpöytäsovelluksen toiminnallisuuden varmistamiselle .. 42
Kuva 29. Ikkunan otsikon toteaminen AutoIt v3 Window Info-työkalun avulla. 43 Kuva 30. Työpöytäsovellus hakemistopolkuineen tallennettuna muuttujaan. ... 43
Kuva 31. Käyttäjän luoma avainsana työpöytäsovelluksen käynnistämiseen. ... 43
Kuva 32. Käyttäjän luoma avainsana uuden dokumentin luomiseen työpöytäsovelluksella. ... 44
Kuva 33. Käyttäjän luoma avainsana tekstin syöttämiselle työpöytäsovelluksessa. ... 44
Kuva 34. Tallennuspainikkeen paikantaminen AutoIt v3 Window Info - työkalun avulla. ... 45
Kuva 35. Käyttäjän luoma avainsana tiedoston tallentamiselle työpöytäsovelluksessa. ... 45
Kuva 36. Käyttäjän luoma avainsana työpöytäsovelluksen sulkemiselle. ... 45
Kuva 37. Tiedoston avaaminen ja sisällön toteaminen työpöytäsovelluksessa. .. 46
Kuva 38. Yksittäisen testitiedoston ajaminen Robot Frameworkilla. ... 47
Kuva 39. Testihakemiston ajaminen Robot Frameworkilla. ... 47
Kuva 40. Tiedostojen tallentaminen hakemistoon testisuorituksen jälkeen. ... 47
Kuva 41. Testitiedoston ajaminen sisältäen vain "Notepad"-tunnisteen omaavat testit. ... 47
Kuva 42. Yleiskatsaus Robot Frameworkin luomasta tiedostosta report.html. ... 48
Kuva 43. Yleiskatsaus onnistuneesta testitapauksesta Robot Frameworkin luomasta tiedos-tosta log.html. ... 49
Kuva 44. Yleiskatsaus epäonnistuneesta testitapauksesta Robot Frameworkin luomasta tiedostosta report.html. ... 49
Kuva 45. Tarkempi katsaus onnistuneen testitapauksen sisällöstä Robot Frameworkin luomasta tiedostosta log.html. ... 50
Kuva 46. Tarkempi katsaus epäonnistuneesta testitapauksesta Robot Frameworkin luomasta tiedostosta log.html. ... 50 Kuva 47. Molempien testitiedostojen yhtäaikainen ajaminen Robot Frameworkilla. ... 51 Kuva 48. Yhteisien testituloksien näkymä report.html tiedostossa. ... 51 Kuva 49. Testitulokset avattuna lokinäkymässä. ... 52
Taulukko 1. Lista projektissa käytetyistä Robot Frameworkin sisäisistä standar- dikirjastoista ja lyhyt kuvaus niiden käyttötarkoituksesta ... 21 Taulukko 2. Lista projektissa käytetyistä Robot Frameworkin ulkoisista kirjas- toista ja lyhyt kuvaus niiden käyttötarkoituksesta ... 22
1 JOHDANTO
Iso osa ohjelmiston kehitysprosessia on koodin toimivuuden varmistaminen. Lisä- tessä uusia muutoksia ja toiminnallisuuksia koodiin, on myös oltava varma siitä, että aikaisemmin toteutetut toiminnallisuudet eivät vahingoitu. Ketterän ohjelmis- tokehityksen mallin kasvaessa suosiotaan, astuvat myös testaus ja sen automati- sointi isoon rooliin ohjelmistokehityksen maailmassa.
Mobiililaitteiden kehittyessä ja niiden käytön yleistyessä yhä useampi ohjelmisto- projekti pyrkii tuottamaan perinteisen työpöytäohjelman lisäksi myös mobiililait- teessa toimivan version. Kehitettävän ohjelman pääpainon ollessa joko mobiili-, tai työpöytäversio, on tärkeää saada molemmista versioista mahdollisimman kat- tavia ja vertailukelpoisia testituloksia, jotta uusien muutoksien ja ominaisuuksien lisääntyessä pystytään tarkkailemaan, että molemmat versiot pysyvät ajan tasalla.
Robot Framework on Suomessa hyvin tunnettu testiautomaatiotyökalu, joka eroaa sen vastaavista kilpailevista työkaluista avainsanapohjaisella ohjelmoinnillaan.
Avainsanapohjaisuus tekee testien kirjoittamisesta käyttäjäystävällisempiä, sillä avainsanojen tekninen toiminnallisuus pyritään piilottamaan testaajalta, mikä te- kee testien kirjoittamisesta ja lukemisesta helppoa. /1/
Opinnäytetyössäni selvitetään, kuinka saadaan luotua Robot Frameworkin avulla mahdollisimman vertailukelpoisia testituloksia samasta ohjelmasta eri alustoilla.
Työssä käytetään esimerkkinä Android-laitteen natiivisovellusta Muistiota, sekä Windows-käyttöjärjestelmän vastaavaa sovellusta Notepad++. Ohjelmat eroavat selvästi toisistaan, mutta ovat silti vertailukelpoisia toiminnallisuuksillaan.
2 TEKNOLOGIAT JA TYÖKALUT
Automaattiseen ohjelmistotestaukseen on monia erilaisia työkaluja, joista jokai- nen omaa käyttäjille ja projekteille sopivia toiminnallisuuksia. Tässä luvussa käy- dään läpi niitä, jotka ovat projektin onnistumisen kannalta tarpeellisia. Luvun alussa käydään läpi myös lyhenteitä ja avainsanoja, jotka esiintyvät läpi opinnäy- tetyön.
2.1 Lyhenteitä ja avainsanoja
HTML – Hyper Text Markup Language on tänä päivänä kaikkein yleisin kieli verkkosivujen luomiseen ja sen toiminnallisuuden kehittämiseen. /2/
CSS – Lyhenne sanoista Cascading Style Sheets. CSS on kieli, jonka avulla luo- daan HTML-sivujen ulkoasu ja tyylit. /3/
CSS Selector – Määrittää elementin, johon määrätty tyyliominaisuus on osoitettu.
Elementti voidaan kohdentaa sen tyypin, luokan, tunnisteen tai sen ominaisuuk- sien mukaan. CSS Selectorin avulla voidaan luoda myös yhdistettyjä, monipuoli- sempia hakuja, jotka voivat osoittaa yhteen tai useampaan elementtiin. /4/
XPATH – Samoin kuin CSS Selector, XPath eli XML Path Language tarjoaa kei- non kohteiden paikannukseen ja kohdentamiseen. Sitä käytetään usein myös testa- tessa asiakirjan osoitettujen solmujen yhteensopivuutta tiettyihin kaavoihin. /5/
UI – UI on lyhenne sanoista User Interface, eli suomeksi käyttöliittymä. Käyttö- liittymällä tarkoitetaan ohjelmistojen ja tietokoneistettujen laitteiden ulkonäköä ja tyyliä. Usein isommissa ohjelmistoprojekteissa on käytössä erilliset käyttöliitty- mäsuunnittelijat, joiden tarkoitus on pyrkiä luomaan mahdollisimman helppokäyt- töinen ja kohdeyleisöä miellyttävä graafinen ulkoasu sovellukselle. /6/
UX – UX on lyhenne sanoista User Experience, eli käyttökokemus. UX kattaa sisällään myös käyttöliittymäsuunnitteluun nähden tärkeitä näkökohtia, mutta vie- lä tärkeämpiä osa-alueita ovat muun muassa tuotemerkin, suunnittelun, käytettä- vyyden ja toiminnan näkökohdat. /7/
Versionhallinta - Versionhallintajärjestelmä on ohjelmistotekniikassa käytetty työkalu, jonka avulla samassa ohjelmointiprojektissa työskentelevä tiimi voi halli- ta ja seurata ohjelmistokoodiin tehtyjä muutoksia ja lisäyksistä. Versionhallinnan avulla käyttäjät voivat myös, virheen tapahtuessa, palata vanhoihin muutoksiin ja korjata tehdyt virheet sen avulla. /8/ Muutamia tunnetuimpia versionhallintajärjes- telmiä ovat GIT ja SVN.
Ohjelmistokehys – Ohjelmistokehys on alusta ohjelmistojen kehittämiselle. Se tarjoaa perustan, jonka avulla kehittäjät voivat luoda ohjelmia valitsemalleen alus- talle. Eri kehykset kattavat erilaisia toimintoja, jotka voivat tehostaa kehityspro- sessia, minkä perusteella kehittäjä voi valita kehittämälleen ohjelmalle sopivan alustan. Oikean ohjelmistokehyksen valitseminen voi vähentää huomattavasti oh- jelmiston kehityksessä ilmeneviä ongelmia ja kysymyksiä. /9/
Skripti – Tekstieditorien avulla luotu komentosarja, joka sisältää joukon komen- toja saavuttaakseen jonkin toiminnan. Skriptit, eli komentosarjat, helpottavat käyt- täjiä käymästä pitkiä ja monimutkaisia komentoja yksitellen läpi. Skriptejä voi- daan myös käyttää tietokoneen prosessien automatisoimiseen. /10/
Ohjelmistorajapinta (API) – Ohjelmistorajapinta, eli API, määrittää säännöt, kuinka ohjelmistokehittäjien kuuluu toimia, jotta voivat olla vuorovaikutuksessa käyttämänsä ohjelmistokielen ja ohjelmistokehyksen kanssa. Rajapinta tarjoaa käyttäjälle toimintoja, jotka mahdollistavat käyttäjän kommunikoinnin ohjelman ja palvelimen välillä. Yleisin palvelimen kanssa kommunikoimisen tarkoitus on tiedonhaku.
Web-ohjelmistorajapinta käyttää yleisesti pyyntöjä ja vastauksia kommunikoides- saan käyttöliittymän kanssa. Verkkosivupyynnöt palauttavat pääosin HTML-, CSS- ja JavaScript-tiedostoja, jotka rakentavat verkkosivun. Web-sovelluksen ra- japinnat palauttavat tietosisältöä sen raa’assa muodossa, joka on pakattu useimmi- ten JSON- tai XML-tiedostomuotoon.
Ohjelmistorajapinnat käyttävät yleisesti kommunikoimiseen HTTP-pyyntöjä. Se tarjoaa käytäntöjä, kuten POST, GET, DELETE, joiden avulla käyttäjä voi joko hakea, lähettää, muokata tai poistaa dataa palvelimelta. /11/
Avoin lähdekoodi – Avoin lähdekoodi on nimensä mukaisesti ohjelmiston lähde- koodi, joka on julkisesti avoin kaikille. Tämä tarkoittaa sitä, että kuka tahansa käyttäjä pääsee käsiksi lähdekoodiin ja voi tarkkailla sitä, tehdä muutoksia sekä parannuksia. /12/
2.2 Visual Studio Code
Visual Studio Code on Microsoftin luoma avoimen lähdekoodin tekstieditorityö- kalu Windows-, Linux- ja MacOS – käyttöjärjestelmille. Tekstieditori pitää sisäl- lään työkalut vianetsintään ja sisäisen GIT - versionhallintajärjestelmän. Visual Studio Code tukee yli 40 erilaista ohjelmointikieltä, ja se on helposti muokattavis- sa käyttäjän tarpeiden mukaisesti eri laajennuksien avulla. /13/
2.2.1 Visual Studio Code – laajennukset
Visual Studio Code tarjoaa Robot Frameworkin kehitystä varten laajan valikoi- man erilaisia käyttäjää avustavia laajennuksia. Listassa on projektissa käytetyt laa- jennukset, sekä lyhyt selite mitä mikäkin laajennus tarjoaa.
- Markdown All in One: Laajennus, jonka avulla Git-projektin dokumen- taatioon tarvittavan Markdown-tiedoston editointi on käyttäjälle helpom- paa. Markdown-tiedosto sisältää usein projektin käyttämiseen tarvittavat ohjeet.
- Python: Tarjoaa käyttöä parantavia työkaluja pythonille, kuten tiettyjen funktioiden ja sanojen korostamisen sekä vianetsintään ja ohjelmistokoo- din muotoilemiseen tarkoitettuja työkaluja.
- Robot Framework Intellisense: Robot Frameworkin kehitystä Visual Studio Codessa parantava laajennus. Laajennus sisältää mm. näppäinyh- distelmiä, jotka auttavat navigoimiseen, sekä avainsanojen ja muuttujien etsimiseen ja niiden käyttämiseen. Esimerkiksi korostaessa avainsanaa ja
painaessa näppäintä F12, työkalu ohjaa käyttäjän tiedostoon, jossa avain- sana on luotu.
2.3 Git
Git on Linus Torvaldsin vuonna 2005 kehittämä moderni versionhallintajärjestel- mä. Se on avoimen lähdekoodin projekti, joka on tällä hetkellä laajimmin käytetty versionhallintajärjestelmä ohjelmistoprojekteissa. Sitä käytetään niin isoissa kau- pallisissa projekteissa kuin pienemmissä yksittäisten käyttäjien luomissa projek- teissa. Git-hakemisto on myös tietovarasto, joka säilyttää jokaisen projektin täy- dellisen historian. /14/
2.4 Python
Python on alustariippumaton ohjelmointikieli, jonka yleisin käyttötarkoitus on skriptaus ja automaatio.
Python erottuu muiden ohjelmointikielten joukosta sen helppokäyttöisyyden ja monipuolisuuden vuoksi. Toiminnallisuus kattaa jokaisen suuren käyttöliittymän ja alustan. Monissa ohjelmistokirjastoissa ja ohjelmistorajapintoja käyttävissä pal- veluissa on sisäänrakennettu tuki Pythonille, joka mahdollistaa Pythonin käyttö- liittymän käyttää vapaasti niiden kirjastoja ja palveluita. /15/ Ohjelmointikielenä Python sopii niin aloittaville kuin kokeneillekin ohjelmoijille.
2.5 Selenium
Selenium on avoimen lähdekoodin ohjelmistotyökalu, joka mahdollistaa web- ohjelmien automaattisen testaamisen. Työkalu pitää sisällään tuen lähes jokaiseen web-selaimeen ja se on myös hyvin edustettuna lukuisissa muissa selaimissa käy- tettävissä automaatiotyökaluissa, sovelluskehyksissä ja ohjelmistorajapinnoissa.
Selenium pitää sisällään useita erilaisia ohjelmistotyökaluja, jotka tekevät testaus- automaatiosta helpomman. Työkalupaketti keskittyy erityisesti kaikkien web- ohjelmien testaamiseen ja niiden parantamiseen. Toimintoja on laaja kattaus ja ne ovat erittäin mukautumiskykyisiä, mikä mahdollistaa erilaisiin tapoihin paikantaa
UI-elementtejä, sekä testituloksien vertailemiseen odotettujen testituloksien ja to- dellisen sovelluskäyttäytymisen välillä. /16/
2.6 Appium
Appium on ilmainen, avoimen lähdekoodin testiautomaatiotyökalu mobiililaittei- den testaamiseen. Se on monialustainen, joka tarjoaa mahdollisuuden testata usei- ta eri alustoja käyttäen sama rajapintaa. Appium mahdollistaa mobiililaitteiden sovelluksien testausautomaation iOS- ja Android-käyttöjärjestelmällisillä puheli- milla ja tablettilaitteilla. Mobiililaitteille kehitettävät sovellukset voivat olla joko natiivi- tai hybridisovelluksia. /17/
Natiivisovelluksilla tarkoitetaan sovelluksia, jotka on kehitetty iOS- tai Android- käyttöjärjestelmille. Nämä sovellukset ovat usein laitteissa valmiiksi asennettuina tai ne ovat asennettavissa laitteen sovelluskaupoista. Natiivisovelluksia kehitetään niille tarkoitetuissa kehitysympäristöissä, kuten Android Studio tai xCode, sekä käyttävät eri ohjelmointikieliä. Natiivisovellukset ovat usein suorituskyvyltään parempia verrattaessa niitä muihin mobiililaitteille kehitettäviin sovelluksiin, mut- ta itse kehitysprosessi voi olla paljon monimutkaisempaa. Monialustaista sovel- lusta kehittäessä on luotava jokaiselle alustalle oma sovellus. /38/
Hybridisovellus pyrkii yhdistämään ja käyttämään elementtejä sekä mobiili- että natiivisovelluksista. Hybridisovellus kehitetään käyttäen web-ohjelmointikieliä, kuten HTML, CSS ja JavaScriptiä. Ne on pakattuna näkymään, joka hyödyntää mobiililaitteen selainmoottoria tuottaakseen HTML- ja CSS-ohjelmointikielillä kehitetyn ulkoasun sekä käsitelläkseen JavaScriptiä paikallisesti. Hybridisovelluk- set ovat monialustaisia, joten työpöydälle kehitetty sovellus voidaan pakata mobii- lisovellukseksi, joka toimii kummassakin mobiililaitteen käyttöjärjestelmässä. /39/
2.7 Chromedriver
Chromedriver on työkalu, joka mahdollistaa web-ohjelmien automaattisen testaa- misen Chrome-selaimessa. Tällä hetkellä Chromedriver on käytettävissä Android- laitteissa sekä työpöytäversioissa Mac-, Linux-, Windows- ja ChromeOS- käyttöliittymissä. Chromedriverin tarjoamiin toimintoihin kuuluu muun muassa
verkkosivujen navigointi, käyttäjän ja sovelluksen välinen kommunikointi, kuten tekstin syöttö, JavaScript-koodin suorittaminen sovelluksessa sekä monia muita erilaisia toimintoja. /18/
3 TESTAAMINEN
Testaamisella tarkoitetaan yleisesti ohjelmistokehityksen prosessia, jossa kehitet- tävää ohjelmaa tai sen tuottamia tuloksia tarkastellaan ja arvioidaan laajemmin.
Maksimoidakseen ohjelmistokehityksen tuottavuuden, on tärkeää muistaa kehitet- tävän ohjelman testaaminen. Testaaminen eri kehitysvaiheissa on elintärkeää pro- jektin onnistumisen kannalta. Uusien muutoksien ja toiminnallisuuksien lisäänty- essä kehitettävässä ohjelmassa on oltava tarkka siitä, ettei jo aikaisemmin toteute- tut muutokset vahingoitu. /19/
Tässä luvussa käydään läpi millaisia testausmenetelmiä ja tapoja ohjelmistokehi- tyksessä on olemassa.
3.1 Testauksen tasot
Ohjelmiston testauksessa voidaan käyttää useita erilaisia menetelmiä, jotka voi- daan jakaa neljään eri kategoriaan; yksikkö-, integraatio-, validaatio-, sekä järjes- telmätestaus. /20/
3.1.1 Yksikkötestaus
Yksikkötestaus tehdään ohjelman pienintä mahdollista osaa vasten, ja sen tarkoi- tuksena on pyrkiä saamaan varmistus siitä, että testattava osa toimii kuten sen pi- tääkin toimia ja, että mahdolliset virhetilanteet kyseiltä osilta on tunnistettu ja en- nakoitu. Monessa tapauksissa ohjelman pienimmät osat ovat sen yksittäisiä funk- tioita, aliohjelmia tai metodeja. Testattavien osien ei tarvitse olla riippuvaisia muista ulkoisista järjestelmistä. Yksikkötestit pyritään pitämään aina automatisoi- tuina. /21/
3.1.2 Integraatiotestaus
Integraatiotestauksessa pyritään saamaan varmistus siitä, että ohjelman itsenäisesti toimivat osat toimivat keskenään ja pystyvät kommunikoimaan odotetulla tavalla.
Testeissä pyritään ajamaan mahdollisimman paljon suorituksia, jotka kulkevat useamman eri osion kautta. /20/
3.1.3 Validaatiotestaus
Validaatiotestauksen päällimmäinen tarkoitus on varmistaa kokonaisen ohjelman yhteensopivuus ja toimivuus. Tarkoitus on myös saada varmistus siitä, että ohjel- ma toimii sille laadittujen vaatimusmäärittelyjen ja käyttötapauksien mukaisesti.
Testeissä pyritään hyödyntämään ohjelman suunnitteluvaiheessa luotuja kuvauk- sia käyttäjän ja ohjelman toiminnan välisestä vuorovaikutuksesta erilaisissa käyt- tötilanteissa, joita kutsutaan käyttötapauksiksi. Ohjelman toimivuus pyritään to- teamaan mahdollisimman aidoissa käyttötilanteissa. /20/
3.1.4 Järjestelmätestaus
Järjestelmätestauksessa testataan ohjelmaa siinä ympäristössä, jossa ohjelma on tarkoitettu toimimaan. Ympäristöön voi, ohjelmasta riippuen, sisältyä tietokantoja, erilaisia käytettäviä laitteistoja ja varsinaisia käyttäjiä. /20/
Testauksen tuloksista pystytään usein toteamaan, vastaako ohjelma sille asetettuja vaatimuksia ja käyttötarkoitusta.
3.2 Manuaalinen testaus
Ohjelman manuaalisella testaamisella tarkoitetaan käyttäjän suorittamaa ohjelman testaamista. Testaamisen suorittava käyttäjä pyrkii varmistamaan, että kehitettävä ohjelma toimii kuten pitääkin testitapauksiin kirjoitettujen olosuhteiden mukaises- ti.
Manuaalinen testaus voi usein olla hyvinkin aikaa kuluttava prosessi, varsinkin isoissa ohjelmistoprojekteissa. Tiettyihin tarkoituksiin manuaalinen testaaminen on suositeltavaa, kuten ohjelman käyttäytymisen tarkkaileminen sellaisissa olo- suhteissa, jota ei voida simuloida automaattisten testien välityksellä. Manuaalinen testaus on myös hyödyllistä silloin, kun testitapaus tulisi saada suoritetuksi vain muutaman kerran, eikä sitä tarvitse toistaa jatkuvasti. Manuaalinen testaaminen auttaa myös käyttäjiä havainnoimaan kehitettävän ohjelman käyttäjäystävällisyy- den, joka on iso osa asiakaskokemuksen parantamista. /22/
3.3 Automaattinen testaus
Automaattinen testaaminen suoritetaan ihmiskäyttäjän sijaan ohjelmistojen, ko- mentosarjojen ja erilaisten työkalujen avulla. Testaaja on luonut erilaisia ennalta määrättyjä testitapauksia ja ne suoritetaan tietokoneen toimesta. Automatisoitujen testien jälkeen voidaan vertailla saatuja testituloksia odotettuja testituloksia vas- ten. /22/
Kuten myös manuaalinen testaaminen, automaattinen testaaminen auttaa kehittäjiä todentamaan, käyttäytyykö kehitettävä ohjelma odotetulla tavalla. Automaattinen ohjelmistotestaus on erittäin hyödyllinen suurissa projekteissa, jotka edellyttävät samojen osa-alueiden testaamista jatkuvasti kehityksen yhteydessä.
4 ROBOT FRAMEWORK
Tässä luvussa käydään läpi Robot Frameworkin toiminnallisuutta ja tärkeimpiä ominaisuuksia, sekä asioita, jotka ovat itse opinnäytetyöhön liittyvän projektin kannalta olennaisia. Luvun aiheiden on määrä antaa lukijalle peruskäsitys siitä, miten Robot Framework toimii ja kuinka sitä voidaan käyttää automaattisessa tes- taamisessa.
4.1 Mikä on Robot Framework?
Robot Framework on vuonna 2008 julkaistu avoimen lähdekoodin testiautomaa- tiotyökalu, joka käyttää pohjanaan Python nimistä ohjelmointikieltä. Robot Fra- meworkin kehitys on alkanut jo vuodesta 2004, jolloin prototyypin kyseisestä tes- tiautomaatiotyökalusta diplomityönään luonut Pekka Klärck sai mahdollisuuden jatkaa luomaansa konseptiaan Nokia Networksilla. Tänä päivänä Robot Fra- mework on yksi parhaista ja käytetyimmistä automaatiotestauksen työkaluista.
Suomessa suurimpiin loppukäyttäjiin kuuluu yrityksiä, kuten Kone, Vaisala, Met- so ja RAY. Tuhannet yritykset Suomen ulkopuolellakin käyttävät Robot Fra- meworkia testaustyökalunaan. /23/
Robot Framework on avoimen lähdekoodin ohjelmistokehys, mikä tarkoittaa, että se on täysin ilmainen, sekä jokaisella käyttäjällä on mahdollisuus päästä käsiksi ohjelmiston lähdekoodiin ja tehdä muutoksia. Lähdekoodi on löydettävistä versi- onhallintajärjestelmä GitHubista. /24/
4.2 Avainsanat
Robot Framework eroaa muista testiautomaatiokehyksistä sen avainsanapohjaisel- la ohjelmointityylillään. Avainsanat piilottavat niiden teknisen toiminnallisuuten- sa pois käyttäjän nähtäviltä, mikä tekee testien kirjoittamisesta ja luettavuudesta yksinkertaisempaa. /1/
Robot Framework mahdollistaa käyttäjän luomaan uusia korkeamman tason avainsanoja, jotka yhdistävät olemassa olevia kirjastojen avainsanoja yhteen, luo- den halutun kokonaisuuden (Kuva 1). Erottuakseen muista alemman tason kirjas-
tojen avainsanoista, kutsutaan näitä käyttäjän avainsanoiksi. Käyttäjän avainsanat voivat koostua useista käyttäjän luomista avainsanoista, kirjastoista saaduista alemman tason avainsanoista ja niiden yhdistelmistä. Käyttäjän avainsanojen ni- met ovat ensimmäisessä sarakkeessa ja sisällä olevat kirjastojen tai itse luomat avainsanat toisessa sarakkeessa. /25/
Testitapaukset koostuvat useista eri avainsanoista ja rakenteeltaan ne ovat saman- laisia kuin käyttäjän luomat avainsanat (Kuva 2).
Kuva 1. Käyttäjän luoma avainsana ”Change Language To Deutsch”.
Kuva 2. Käyttäjän luoma avainsana "Change Language To Deutsch" osana testi- tapausta.
4.3 Kirjastot
Robot Framework omistaa hyvin monipuolisen ekosysteemin, joka sisältää erilai- sia yleisiä kirjastoja ja käyttöä helpottavia työkaluja. Testit koostuvat avainsanois- ta, ja kirjastot tuovat mukanaan tärkeitä testausominaisuuksia avainsanoillaan.
/26/
Lista käytössä olevista standardikirjastoista ja asennettavista ulkoisista kirjastoista löytyy osoitteesta https://robotframework.org/#libraries
4.3.1 Standardikirjastot
Ohjelmistokehyksen sisällä on useita valmiita standardikirjastoja, joita ei tarvitse erikseen asentaa. Nämä standardikirjastot kattavat lähinnä testauksen peruskäyt- töön tarvittavia avainsanoja. /27/ Taulukossa 1 on lyhyt kuvaus projektissa käyte- tyistä sisäänrakennetuista kirjastoista.
Taulukko 1. Lista projektissa käytetyistä Robot Frameworkin sisäisistä standar- dikirjastoista ja lyhyt kuvaus niiden käyttötarkoituksesta.
BuiltIn Testeissä käytettäviä yleisimpiä avain-
sanoja, joita voidaan käyttää mm. tar- kistustoimenpiteisiin, kuten yhdenver- taisuuden ja sisällön tarkistamiseen, sekä yleiset yksikköjen muunnokset (esimerkiksi merkkijonosta numeroyk- sikköön).
String Merkkijonon käsittelemiseen, muunta-
miseen ja manipuloimiseen käytettäviä avainsanoja.
OperatingSystem Käyttöjärjestelmän kanssa kommuni-
koimiseen tarvittavat avainsanat.
Avainsanojen avulla voidaan muun muassa ajaa erillisiä ohjelmia, luoda ja poistaa tiedostoja ja hakemistoja, sekä hallita ympäristömuuttujia
Process Sisältää prosessin hallintaan tarvittavia
avainsanoja, jotka hyödyntävät Pytho- nin aliprosessimoduulia, ”Popen”- luokkaa. Avainsanojen avulla voidaan ajaa ulkoisia prosesseja, kuten skriptejä
ja ohjelmia.
Collections Tarjoaa avainsanoja, joiden avulla
käyttäjä voi testeissään helposti hallita ja käsitellä luetteloita ja sanakirjoja.
Sisältää myös listan sisällön tarkistami- seen ja vertaamiseen tarvittavat avain- sanat.
4.3.2 Ulkoiset kirjastot
Standardikirjastojen lisäksi on olemassa erillisinä hankkeina luotuja ja kehitettyjä ulkoisia kirjastoja, joita käyttäjä voi tuoda testeihinsä tarpeidensa mukaan. Robot Frameworkin ollessa avoimen lähdekoodin omaava ohjelmistokehys, on sen yh- teisö tuottanut useita testaamista helpottavia kirjastoja, jotka eivät ole valmiiksi pakattuna ydinkehykseen. /28/
Ulkoiset kirjastot voivat omistaa täysin erilaisen mekanismin liittyen niiden käyt- töönottoon ja asennukseen, mutta yleensä ne sisältävät selkeät käyttöohjeet ja asiakirjat.
Ulkoisia kirjastoja on huomattavasti enemmän kuin standardikirjastoja ja tarkoi- tukseltaan ne ovat usein luotuja toisten ohjelmistokehyksien ja työkalujen käytön liittämiseen Robot Frameworkin kanssa. Taulukossa 2 on tärkeimmät ulkoiset kir- jastot, jotka ovat projektissa käytössä.
Taulukko 2. Lista projektissa käytetyistä Robot Frameworkin ulkoisista kirjas- toista ja lyhyt kuvaus niiden käyttötarkoituksesta.
AppiumLibrary Kirjasto mobiilisovelluksien testaami-
seen. Sisältää tarvittavat avainsanat tes- tien ajamiseen Android- ja iOS- ympäristössä.
AutoItLibrary Avainsanakirjasto, joka mahdollistaa Windows-käyttöliitymän automatisoin- nin.
SeleniumLibrary Tuo mukanaan tarvittavat avainsanat web-sovelluksien testaamiseen. Kirjas- ton tuomat avainsanat ovat yleensä hy- vin helppokäyttöisä, mutta vaativat usein toteutukseen liittyviä argumentte- ja toimiakseen kunnolla. Yleisiä avain- sanoja ovat mm. elementin toteaminen ruudulla ja sen kanssa kommunikoimi- seen tarkoitetut menetelmät, kuten tekstin kirjoittaminen ja sen löytämi- nen.
4.3.3 Kirjastojen käyttäminen
Robot Framework tarjoaa sivuillansa kattavat valikoimat erilaisia kirjastoja, jotka kaikki sisältävät linkit kirjaston käyttöohjeisiin ja avainsanojen dokumentaatioon.
https://robotframework.org/#libraries
Ulkoisia kirjastoja varten yleisin asennusmenetelmä on PIP. PIP on lyhenne sa- noista ”Python Installs Packages”, joka on Pythonin oma pakettienhallintajärjes- telmä. Kirjastoja saa lisättyä projektiin mukaan ajamalla asennukseen tarvittavat komennot komentorivillä.
Sisäänrakennettuja standardikirjastoja varten käyttäjän ei tarvitse tehdä Robot Frameworkin asennuksen jälkeen mitään ylimääräisiä toimenpiteitä saadakseen ne käyttöönsä, muuta kuin tuoda kirjastot manuaalisesti koodin käyttöön. Ainoa poikkeus sisäänrakennetuissa kirjastoissa on BuiltIn, joka on automaattisesti käy- tössä, ilman sen tuomista koodiin mukaan.
Kirjastojen tuominen testaukseen mukaan voidaan toteuttaa useammalla tavalla.
Tavallisesti testien sisältävässä tiedostossa voidaan määritellä käytettävät kirjastot
”Settings”-osiossa koodin alkupäässä (Kuva 3.).
Osaan kirjastoista voidaan lisätä manuaalisesti käytettävyyttä parantavia lisätoi- minnallisuuksia ja ominaisuuksia antamalla tälle argumentteja sen tuomisen yh- teydessä. /29/ Esimerkiksi SeleniumLibrary voi vastaanottaa lisäargumentteina kauanko avainsanat, jotka alkavat ”Wait Until…”, odottavat ennen suoriutumis- taan. Testien epäonnistuessa voidaan suorittaa käyttäjän haluama toiminto, joka voi olla kuvankaappauksen säilyttäminen hetkeltä, jolloin testi epäonnistuu tai lähdekoodin tulostaminen testiraporttiin.
Argumentit ovat kirjastoille yksilöityjä ja lisätietoa kirjastojen valinnaisista argu- menteista löytyy niiden tarjoamilta dokumentaatiosivuilta.
Kuva 3. Kirjastojen määrittäminen tiedoston sisällä.
Kirjastot voidaan myös tuoda ajaessa tiettyä avainsanaa tai testiä. Tällöin käyte- tään sisäänrakennetun BuiltIn-kirjaston valmista avainsanaa ”Import Library”.
Avainsanalle annetaan argumenttina kirjasto, joka halutaan ottaa käyttöön tietyn avainsanan ajamisen yhteydessä.
Eri kirjastot voivat sisältää saman nimen omaavia avainsanoja, jolloin käyttäjän on määritettävä avainsanan ajon yhteydessä, mihin kirjastoon se kuuluu. Kuvasta 4 voidaan huomata, kuinka avainsanoille korkeamman tason avainsanan sisällä on määritetty kirjasto, johon ne kuuluvat. Tällöin avainsanat ajetaan aina niille kuu- luvasta kirjastosta.
Esimerkiksi AppiumLibrary ja SeleniumLibrary sisältävät useamman samalla ni- mellä toimivan avainsanan. Testien ajamisen yhteydessä voidaan myös määrittää,
missä järjestyksessä kirjastoista etsitään avainsanoja ”Set Library Search Order”
avainsanan avulla (Kuva 5). Tämä asettaa, mistä kirjastosta samannimiset avain- sanat haetaan, ellei käyttäjä ole määrittänyt kirjastoa.
Kuva 4. Kirjaston määrittäminen avainsanan yhteydessä.
Kuva 5. Kirjastojen järjestys “Set Library Search Order” avainsanalla.
5 TOTEUTUS
Tässä luvussa käydään läpi, miten projektin automaattinen testaus on toteutettu Robot Frameworkin avulla ja kuinka testisuorituksia ajetaan eri alustoilla. Luvun alussa käydään läpi projektissa käytettyjä työkaluja ja kirjastoja, sekä millainen hakemistorakenne testejä varten on ympäristössä luotu.
Testit ajetaan kahdella eri alustalla, Android-laitteella ja tietokoneella. Molemmis- ta alustoista on luvussa kirjoitettu, miten testit käynnistetään ja esitetään lyhyt esimerkki miltä testitapaukset näyttävät kummallakin alustalla.
5.1 Käytetyt työkalut
Projektissa työskennellään Visual Studio Code-tekstieditorin avulla. Visual Studio Coden valittiin projektiin sen helppokäyttöisyyden vuoksi. Se on helposti muokat- tavissa oleva tekstieditori, joka tuo mukanaan mahdollisuuden päästä käsiksi usei- siin eri laajennuksiin ja työkaluihin, jotka helpottavat työntekoprosessia. Näihin laajennuksiin, erityisesti tässä projektissa kuuluu muun muassa ”Robot Fra- mework Intellisense”, joka tuo lisäkomentoja ja avustavia työkaluja Robot Fra- mework kehitykseen.
Mobiililaitteen testaaminen onnistuu niin fyysisellä laitteella kuin emulaattorilla.
Fyysisenä laitteena testien kehittämisessä käytettiin Huawein Honor 8 Lite- puhelinta. Emulaattori käynnistetään Android Studion kautta, joka tarjoaa mah- dollisuuden Android-laitteiden kanssa toimivien sovelluksien kehitykseen.
Työpöytäsovelluksena toimii Notepad++, joka on avoimen lähdekoodin työkalu tekstin editoimiseen. Notepad++ on ladattavissa osoitteesta https://notepad-plus- plus.org/
5.2 Kirjastot
Projektin käytössä on suurin osa Robot Frameworkin sisäänrakennetuista avainsa- nakirjastoista, kuten Process, OperatingSystem, String ja Collection. Mobiilialus- talla ajaessa testejä tarvitaan ulkoista kirjastoa AppiumLibrary. Työpöytäsovel- luksen testaamisessa käytetään apuna kirjastoa nimeltä AutoItLibrary
5.3 Hakemistorakenne
Projektin tämänhetkinen hakemistorakenne selitettynä. Hakemistot on lihavoitu ja tiedostot sisältävät aina tiedostopäätteen.
- Resources: Hakemisto testeissä käytettäville ulkoisille tiedostoille ja työ- kaluille, kuten Chromedriver-tiedstoille ja testattavalle sovellukselle, joka asennetaan mobiililaitteelle testejä ajaessa.
- Results: Testisuorituksen päätteeksi Robot Framework luo omat HTML- ja XML-tiedostot, joista käyttäjä näkee ajetun testin tulokset. Hakemisto pitää sisällään kaksi hakemistoa kummallekin alustalle, joihin testisuori- tuksen käynnistämisen yhteydessä tulokset ohjataan.
- Test: Sisältää yksilölliset testit molemmille käytetyille alustoille sekä yh- teisen hakemiston, joka sisältää avainsanoja, joita voidaan käyttää mo- lemmilla alustoilla.
o Windows: Hakemisto sisältää työpöytäsovellukselle osoitetut testit ja niiden avainsanat.
▪ Suites: Sovellus, jota testataan, voi sisältää useita eri nä- kymiä. Tämä hakemisto pitää sisällään testitiedostoja, joista jokainen käsittelee oman näkymänsä testitapauksia.
• Suite1.robot
• Suite2.robot
• Suite3.robot
• …
▪ Keywords: Sisältää hakemiston jokaiselle testattavalle nä- kymälle, jotka pitävät sisällään niissä käytettäviä avainsa- noja. Osa sivuista saattaa sisältää useamman testattavan
osan, jonka takia Suite-hakemisto voi sisältää useamman kuin yhden tiedoston avainsanoille.
• Suite1
o suite1_1-keywords.robot o suite1_2-keywords.robot
• Suite2
o suite2_1-keywords.robot
• Suite3
o suite3_1-keywords.robot o suite3_2-keywords.robot
• …
o Mobile: Hakemistorakenne on samanlainen kuin Windows- hakemistossa. Tiedostot pitävät sisällään yksilöityjä testejä, jotka toimivat testattavan sovelluksen mobiiliversiossa.
o Shared: Yleisiä avainsanoja ja tiedostoja, joita voidaan käyttää alustasta riippumatta.
▪ Scripts: Robot Frameworkin ja Pythonin avulla voidaan suorittaa erilaisia testausprosessia avustavia skriptejä. Ha- kemisto sisältää molemmilla alustoilla ajettavia skriptitie- dostoja (tässä tapauksessa Python-, Powershell- ja Ja- vaScript-tiedostoja).
• script1.py
• script2.ps1
• script3.js
• …
▪ Helpers.robot: Testausta avustavia avainsanoja, joita voi- daan käyttää sovelluksessa useammassa kuin yhdessä nä- kymässä.
▪ HelperVariables.robot: Muuttujia, jotka avustavat testauk- sessa. Esimerkiksi syöttökenttien toimivuutta testatessa voidaan käyttää kyseisen tiedoston sisältämiä arvoja.
▪ Navigation.robot: Sovelluksen eri näkymien navigoimiseen käytettävät avainsanat.
5.4 Sovelluksen automaattinen testaaminen mobiiliympäristössä
Projektissa on luotu automaattiset UI-testitapaukset kahdelle eri käyttöalustalle, Windows-käyttöjärjestelmän työpöytäsovellukselle ja Android-käyttöjärjestelmän omaavalle mobiililaitteelle. Testitapaukset kattavat sovelluksen avaamisen mo- lemmilla alustoilla sekä sovelluksen toimintojen, kuten tiedostoon kirjoittamisen, lukemisen ja tallentamisen suorittamisen. Kappaleessa käydään aluksi läpi, kuinka sovellus käynnistetään Robot Frameworkin avulla, miten ja millä työkaluilla se saadaan suoritettua ja miten testitapauksia luodaan.
5.4.1 Esivalmistelut
Ennen testien ajoa tulee käyttäjällä olla joko fyysinen puhelin, jossa on Android- käyttöjärjestelmä tai vastaava laite emulaattorilla. Kyseisessä projektissa on käy- tetty molempia, mutta seuraavaksi on esitettynä, kuinka saadaan otettua fyysinen laite käyttöön testausta varten.
5.4.2 Android Debug Bridge
Jotta fyysistä mobiililaitetta pystyttäisiin käyttämään testeissä, tarvitaan työkalu nimeltä Android Debug Bridge. Android Debug Bridge on komentorivillä ajettava työkalu, joka mahdollistaa käyttäjän ja laitteen välisen kommunikoinnin. Työkalu kattaa toiminnallisuudellaan muun muassa laitteen vianetsinnän ja sovelluksien asennuksen laitteille. Se tarjoaa myös komentorivillä suoritettavia komentoja, joi- ta voidaan käyttää laitteella suoritettavia tehtäviä varten ja laitteen tietojen tulos- tamiseen. /30/
Kun fyysinen mobiililaite on liitettynä käytettävään tietokoneeseen tai avattuna emulaattorissa käyttäjä voi tarkistaa, onko laite löydettävissä komennolla ”adb devices”, joka tulostaa liitetyn laitteen nimen ja laitetyypin (Kuva 6). Jos käyttä- jällä on tarve saada enemmän tietoa laitteesta, kuten lisätietoa laitteen tyypistä ja sen mallista, ajetaan komento ”adb devices -l” (Kuva 7). Vielä yksityiskohtai-
sempia laitteen tietoja saadaan tulostettua komennolla ”adb -s (laitteen ID) shell getprop”, joka tulostaa laitteen jokaisen tiedon komentokehotteeseen (Kuva 8).
Jotta saadaan juuri tietty tieto esille, liitetään edelliseen komentoon halutun tiedon otsikko, esimerkiksi ajamalla komento ”adb -s (laitteen ID) shell getprop ro.build.version.release”, saadaan selville laitteen käyttöjärjestelmän versio.
Kuva 6. Android Debug Bridgen komento laitteiden listaamiseen.
Kuva 7. Android Debug Bridgen komento laitteiden listaamiseen tarkemmilla tie- doilla.
Kuva 8. Android Debug Bridgen komento laitteen tietojen yksityiskohtaiseen tu- lostukseen.
5.4.3 ADB Shell ja natiivisovelluksien löytäminen
Kun Android-laite on liitettynä tietokoneeseen ja se on löydettävissä ”adb devi- ces”-komennolla, voidaan käynnistää komentorivi ja ajaa komento ”adb shell”, joka antaa käyttäjälle mahdollisuuden kommunikoida laitteen kanssa komentori- vin välityksellä. Seuraava askel on navigoida laitteella sovellukseen, joka halutaan avatuksi Robot Frameworkin testejä luodessa. Kun sovellus on avattuna laitteella, ajetaan komentorivillä komento ”dumpsys window windows | grep -E ’mCurrent- Focus’”, jolla saadaan selvitettyä laitteessa auki olevan sovelluksen tietoja (Kuva 9). /31/ Näitä tietoja tarvitaan myöhemmin sovelluksen aukaisemiseen tarkoitettua avainsanaa luodessa.
Kuva 9. Android-natiivisovelluksen paketin nimen löytäminen.
5.4.4 UI Automator Viewer
UI Automator Viewer on työkalu, joka tarjoaa käyttäjälle mahdollisuuden analy- soida Android-laitteessa näkyvää ulkoasua ja komponentteja. Työkalun avulla käyttäjä näkee sovelluksen komponenttien ominaisuuksia, joita voidaan käyttää testejä luodessa (Kuva 11). /32/ UI Automator Viewer on osa Android SDK Ma- nageria ja se on käytettävissä kyseisen työkalun asennuksen jälkeen.
Työkalu sijaitsee hakemistopolussa:
”c:\users\<username>\AppData\Local\Android\sdk\tools”.
Ohjelman ollessa käynnissä ja Android-laiteen ollessa yhdistettynä tietokonee- seen, työkalu mahdollistaa kuvakaappauksen ottamisen laitteella auki olevasta nä- kymästä (Kuva 10).
Kuva 10. UI Automator Viewer – kuvakaappauksen ottaminen laitteen näkymästä
Kuva 11. UI Automator Viewer - kuvankaappaus laitteen näkymästä
Kuvankaappauksesta nähdään, mitä ominaisuuksia kyseisen näkymän komponen- tit pitävät sisällään. Kuvassa 11 on tarkasteltavissa yksityiskohtaisesti, mitä omi- naisuuksia ”Uusi muistiinpano” – painike sisältää.
5.4.5 Laitteen käyttöönotto ja sovelluksen käynnistäminen Robot Fra- meworkilla
Kuvassa 12 on käyttäjän luoma avainsana, joka pitää sisällään edellä mainittuja komentoja. Ensiksi ajetaan komento ”adb devices” ja muutetaan saatu tulos listak- si. Lista muodostetaan avainsanalla ”Split To Lines”, joka muuntaa sille osoitetun tekstin listaksi. Avainsanalle annetaan lisäargumentti ”1”, mikä jättää tekstin en- simmäisen rivin pois listasta. Seuraavaksi tarkistetaan, onko liitettyjä laitteita olemassa, ja jos laitteita on listassa useampi kuin yksi, käytetään ensimmäistä lai- tetta listassa. Jos laitteita ei löydy, testin suorittaminen lopetetaan. Seuraavaksi käytetään Robot Frameworkin sisäisesti rakennettujen kirjastojen ”Collection” ja
”String” tarjoamia avainsanoja ”Get From List” ja ”Fetch From Left”, jotta saatai- siin vain ja ainoastaan testattavan laitteen tunnistenumero esille. Lopuksi ajetaan komennot laitteen tietoja, kuten versionumeroa, mallia, ja markkinointinimeä var- ten ja ohjataan ne omille muuttujillensa. Osaa laitteen tiedoista tarvitaan sovelluk- sen käynnistämiseen ja testiraportin selkeytykseen.
Kuva 12. Käyttäjän luoma avainsana Get Android Devices.
Kun testattava laite on selvitettynä, seuraava vaihe on Appium-palvelimen käyn- nistäminen. Appium käynnistetään Robot Frameworkin sisäänrakennetun kirjas- ton ”Process” sisältämän avainsanan ”Start Process” avulla. Avainsana käynnis- tää tietokoneelle uuden prosessin ja suorittaa sille komennon “appium – chromedriver-executable (chromedriver tiedoston sijaintipolku)” (Kuva 13).
Appium tukee verkkosivuja sekä hybridisovelluksia, jotka ovat Chrome-taustaisia hallitsemalla Chromedriver ilmentymää. Appiumissa on automaattisesti taustalla Chromedriverin uusin versio, mutta joissain tapauksissa uusin versio ei aina ole yhteensopiva käytettävän laitteen kanssa. Tällöin käyttäjän on manuaalisesti ladat- tava oikea versio Chromedriveristä ja syötettävä Appiumille sen käynnistyksen yhteydessä komento, joka käynnistää palvelimen oikealla Chromedriverillä. /33/
Chromedriverin voi ladata osoitteesta
http://chromedriver.chromium.org/downloads
”Start Process”-avainsanalle on annettu lisäargumenteiksi ”stdout” ja ”stderr”, joihin on määritetty tiedostopolku, mihin Appium tallentaa tulostamansa tiedot.
Tämä voi auttaa käyttäjää paikantamaan virhetilanteen tapahtuessa sen syyn.
Kuva 13. Käyttäjän luoma avainsana Appium-palvelimen käynnistämiseen
Kuva 14. Appium-palvelimen käynnistämiseen käytetty komento
Jokainen Android-käyttöjärjestelmän omaava mobiililaite sisältää oletuksena muistiosovelluksen. Muistio on Android-laitteen natiivisovellus, joka saadaan käynnistettyä Robot Frameworkilla käyttäen ulkoista kirjastoa ”AppiumLibrary”.
Kirjasto sisältää avainsanan ”Open Application”, johon syötetään argumentteina testattavan laitteen tietoja, kuten alusta (Android/iOS), alustan versio ja laitteen nimi sekä sovellus, joka halutaan aukaista (Kuva 15). Käynnistettävä sovellus voi olla laitteelle valmiiksi asennettu sovellus tai erillinen tiedosto, joka asennetaan laitteelle testisuorituksen yhteydessä. Tällöin avainsanalle annetaan lisäargumentti
”app”, johon määrätään tiedostopolku, joka sisältää kyseisen tiedoston.
”appPackage” on kehittäjien tarjoama sovelluksen tekninen nimi. Se on paketti, jonka alla sijaitsee sovelluksen kaikki lähdekoodit. ”appActivity” puolestaan viit- taa erilaisiin toimintoihin, joita sovelluspaketti tarjoaa. /31/ Edellisissä kappaleissa selvitettiin, kuinka Android-natiivisovelluksen ”appPackage” ja ”appActivity”
saadaan selvitettyä ADB shellin sekä UI Automator Viewer - työkalun avulla.
Kyseisessä tapauksessa Androidin muistiosovellus ”com.android.notepad” sisäl- tää avattuaan päänäkymän, joka on ”NotePadActivity”. Avainsanan päätteeksi tar- kistetaan vielä, että sovellus on avattuna näytöllä. ”Wait Until Keyword Succeeds – Get Activity” suorittaa avainsanaa ”Get Activity” käyttäjän määräämän ajan ver- ran, kunnes avainsana toteutuu. Tässä kyseisessä tapauksessa ”Get Activity” pa- lauttaa arvon ”NotePadActivity”.
Kuva 15. Käyttäjän luoma avainsana mobiilisovelluksen avaamiseen.
Lopuksi pakataan edellä mainitut käyttäjän luomat avainsanat yhdeksi avainsa- naksi, jotta sen käyttö olisi yksinkertaisempaa (Kuva 17). Avainsana selvittää en- siksi testattavan laitteen olemassaolon ja sen tiedot, jonka jälkeen tarkistetaan Ap- pium-palvelimen tila. Jos palvelin ei ole käytössä, käynnistetään se avainsanalla
”Start Appium Server”, ja jos palvelin on testin alkaessa käynnissä, palautetaan komentoriville varmistava teksti (Kuva 16).
Kuva 16. Käyttäjän luoma avainsana Appium-palvelimen tarkastamiseen.
Kuva 17. Käyttäjän luoma avainsana "Start Application" pitää sisällään kaikki tarvittavat avainsanat sovelluksen käynnistämistä varten.
5.4.6 Testien kirjoittaminen
Mobiililaitteella suoritettavia testejä ovat uuden dokumentin luominen, tekstin kir- joittaminen luotuun dokumenttiin, sekä sen tallentaminen ja tallennuksen toden- taminen. Kappaleen ensimmäisessä testissä käydään läpi, kuinka natiivisovelluk-
sen elementtejä paikannetaan ja kuinka niitä voidaan käyttää testejä luodessa. Pai- kantamiseen on käytetty UI Automator Viewer-työkalua.
Kuva 18. Testi muistion toiminnallisuuden varmistamiselle.
Kuvassa 18 on luotu testitapaus nimeltä ”Notepad Funcionality”, jonka tarkoitus on testata muistiosovelluksen perustoiminnallisuuksia. Testitapaukselle on annettu dokumentaatio ja tunnisteet, jotka auttavat selkeyttämään lopuksi luotua testira- porttia.
Luodessa uutta dokumenttia mobiililaitteen muistiosovelluksella, ensimmäinen tehtävä on paikantaa ja painaa ”Uusi muistiinpano” painiketta. Kuvassa 20 on käyttäjän luoma avainsana, jossa on ensiksi varmistettu, että sivu sisältää kyseisen komponentin ennen kuin sitä painetaan. Tämän jälkeen varmistetaan, että sivulla on uuden dokumentin tekstinäkymä esillä.
Kuva 19. UI Automator Viewer - työkalun käyttäminen elementtien paikantami- seen.
Kuva 20. Käyttäjän luoma avainsana uuden dokumentin luomiselle.
Kuvassa 21 on käyttäjän luoma avainsana ”Insert Text”, johon käyttäjä syöttää argumenttina kirjoituskenttään kirjoitettavan tekstin. Argumenttina annettu teksti tallennetaan globaaliin muuttujaan, joka tarkoittaa sitä, että sitä voidaan käyttää muissakin käyttäjän luomissa avainsanoissa tarpeen tullen. Avainsanassa käyte- tään AppiumLibraryn avainsanaa ”Input Text”, johon syötetään kirjoitettava teksti ja kohde-elementti, johon teksti kirjoitetaan. Tekstin syöttämisen jälkeen varmis- tetaan, että syötetty teksti on näytöllä esillä.
Kuva 21. Käyttäjän luoma avainsana tekstin syöttämiselle.
Tekstin tallentamiseen ja tallennuksen toimivuuden varmistamiseen on luotu avainsana ”Save Text” (Kuva 22). Avainsana sisältää ”Tallenna”-napin painalluk- sen, jonka jälkeen tarkistetaan, että kyseinen elementti ei sivulla enää ole näkyvis- sä. Sovelluksen yläosassa on teksti, joka muuttuu käyttäjän käyttäessä muistioso- velluksen eri toiminnallisuuksia. Yläosan tekstin tarkistamista varten on luotu avainsana ”Actionbar Text Should Be”, johon syötetään argumentiksi teksti, jonka testaaja haluaa sovelluksen yläosassa lukevan (Kuva 23). Avainsanaa käytetään toisen sisäänrakennetun avainsanan ”Wait Until Keyword Succeeds” yhteydessä, jotta sovelluksen viive ei estäisi testin onnistumista. Ennen tallentamista kyseinen elementti pitää sisällään tekstin ”Muokkaa merkintää”, ja tallennuksen jälkeen saman elementin teksti tulee olla ”Muistio”. Seuraava tehtävä on navigoida takai- sin aloitusruudulle sovelluksessa, joka sisältää listan muistioon luoduista doku- menteista. Avainsanassa tarkistetaan, että palatessa takaisin etusivulle, tekstin edi- tointiruutu on pois käyttäjän näkyvistä ja, että yläosan teksti vaihtuu oikeaksi. Lo- puksi vielä tarkistetaan, että juuri luotu uusi dokumentti on listassa näkyvillä (Kuva 24).
Kuva 22. Käyttäjän luoma avainsana tekstin tallentamiseen muistiosovelluksessa.
Kuva 23. Käyttäjän luoma avainsana sovelluksen yläpalkin tekstin todentamiseen.
Kuva 24. Muistiosovelluksen näkymä avainsanan ”Save Text” jälkeen.
5.5 Sovelluksen testaus Windows-ympäristössä
Robot Frameworkin avulla luodun esimerkkinä toimivan testitapauksen sovelluk- sena on käytetty Notepad++-työpöytäsovellusta. Mobiili- ja työpöytäsovellus ei- vät ole tässä tapauksessa täsmälleen samoja, mutta kattavat toiminnallisuuksillaan samoja ominaisuuksia, kuten kirjoittamisen, tallentamisen ja lukemisen. Testita- paukset on myös luotu eri kirjastoja käyttäen, joten sisällöltään testit eroavat huomattavasti.
5.5.1 AutoItLibrary & AutoIt v3 Window Info
AutoItLibrary on Python-pohjainen avainsanakirjasto Robot Framework – ohjel- mistokehykselle. Kirjasto perustuu Windows-käyttöliittymän automatisointiin tar- koitettuun työkaluun AutoIt. /34/ Automatisointiin AutoIt käyttää yhdistelmiä hii- ren liikkumisesta, näppäimistön simuloinnista ja sovelluksien ikkunoiden manipu- lointia /35/.
AutoItLibrary asennetaan ajamalla komento ”pip install robotframework- autoitlibrary” komentoriville. Asennuksen jälkeen hakemistosta C:\RobotFramework\Extensions\AutoItLibrary löytyy ohjelma nimeltä
”Au3Info”, joka on AutoIt:n oma työkalu ikkunoiden tietojen ja ominaisuuksien hallitsemiseen (Kuva 25). Työkalun avulla voidaan kätevästi paikantaa testita- pauksissa tarvittavia komponentteja sovelluksen sisältä (Kuva 26).
Kuva 25. Ohjelman Au3Info sijainti.
Kuva 26. Au3Info käytössä.
AutoItLibraryn tarjoamia avainsanoja pääsee testitapauksissa käyttämään liittä- mällä kirjasto testitiedoston yläosaan (Kuva 27). Avainsanojen dokumentaatio löytyy hakemiston C:\RobotFramework\Extensions\AutoItLibrary tiedostosta
”AutoItLibrary.html”.
Kuva 27. Kirjaston AutoItLibrary liittäminen tiedostoon.
AutoItLibrary käyttää sovelluksen kanssa kommunikoimiseen näppäimistön simu- lointia, ja iso osa testeistä kattaa näppäinyhdistelmien ja tekstin lähettämistä.
Osoitteesta https://www.autoitscript.com/autoit3/docs/functions/Send.htm löytyy kirjaston tarjoaman avainsanan ”Send” kanssa käytettäviä näppäimistön kirjai- mien ja erikoismerkkien koodeja, jotka ovat testejä kirjoittaessa hyödyllisiä.
5.5.2 Testien kirjoittaminen
Työpöytäsovelluksen testien kirjoittamiseen on tässä tapauksessa käytetty erilaista lähestymistapaa mobiilialustan testeihin verrattuna. Tämä ei kuitenkaan tarkoita sitä, etteikö molempien alustojen testit olisi vertailukelpoisia keskenään, sillä vaikka testien sisältö eroaa toisistaan, on molempien testien kokonaisuus toimin- nallisuudeltaan sama (Kuva 18 ja Kuva 28).
Kuva 28. Testitapaus työpöytäsovelluksen toiminnallisuuden varmistamiselle Sovellus käynnistetään AutoItLibraryn tarjoamalla avainsanalla ”Run”, jolle syö- tetään argumentiksi sovelluksen hakemistopolku, joka sisältää käynnistämiseen tarvittavan ajotiedoston (Kuva 31). Sovelluksen hakemistopolku on tässä tapauk- sessa määritetty omaksi muuttujaksi tiedoston yläosassa (Kuva 30). Kun sovellus on käynnistetty, odotetaan, että aktiivinen ikkuna sisältäisi tekstin ”new 1 – No- tepad++”, joka on oletuksena sovelluksen käynnistyessä. Tämä saadaan selville käyttäen ”AutIt v3 Window Info”-työkalua (Kuva 29).
Kuva 29. Ikkunan otsikon toteaminen AutoIt v3 Window Info-työkalun avulla.
Kuva 30. Työpöytäsovellus hakemistopolkuineen tallennettuna muuttujaan.
Kuva 31. Käyttäjän luoma avainsana työpöytäsovelluksen käynnistämiseen.
Uuden dokumentin luomiseen on käytetty AutoItLibraryn tarjoamaa toimintoa kommunikoida näppäimistön kanssa. Notepad++ sisältää näppäinyhdistelmiä eri- laisten toimintojen suorittamiseen. Uusi dokumentti luodaan näppäinyhdistelmällä
”ctrl + n”, ja yhdistäessä sen avainsanaan ”send”, suoritetaan komento testattavan sovelluksen sisällä (Kuva 32).
Kuva 32. Käyttäjän luoma avainsana uuden dokumentin luomiseen työpöytäso- velluksella.
Tekstin syöttämiseen on käytetty samaa menetelmää kuin dokumentin luomiseen.
Käyttäjä syöttää avainsanalle ”Insert Text” muistioon kirjoitettavan tekstin, jonka jälkeen tekstistä tehdään globaali muuttuja myöhempää käyttöä varten. Teksti kir- joitetaan muistioon käyttäen ”Send”-avainsanaa (Kuva 33).
Kuva 33. Käyttäjän luoma avainsana tekstin syöttämiselle työpöytäsovelluksessa.
Tiedoston tallentaminen onnistuu sovelluksen tarjoaman näppäinyhdistelmän ”ctrl + alt + s” avulla. Tätä näppäinyhdistelmää hyödynnetään käyttäjän luomassa avainsanassa ”Save Text” (Kuva 35). Kyseinen näppäinyhdistelmä lähetetään so- vellukselle muodossa ”^!s”, jonka jälkeen sovellus tarjoaa käyttäjälle mahdolli- suuden tallentaa tiedoston haluamallaan nimellä. Nimeksi valitaan testin suorituk- sen kellonaika, jotta vältytään samannimisiltä tiedostoilta. Tiedostonimi tallenne- taan myös globaaliksi muuttujaksi, jotta sitä voidaan käyttää myöhemmässä vai- heessa. Kun tiedoston nimi on lähetetty sovellukselle, painetaan ”Tallenna” - painiketta. Painikkeen painamiseen tarvitaan AutoIt v3 Window Info – työkalun tarjoamia ominaisuuksia (Kuva 34). Avainsana ”ControlClick” tarvitsee toimiak- seen kolme pakollista argumenttia, ikkunan otsikon, komponentin tekstin ja tun- nusluvun.
Kuva 34. Tallennuspainikkeen paikantaminen AutoIt v3 Window Info - työkalun avulla.
Kuva 35. Käyttäjän luoma avainsana tiedoston tallentamiselle työpöytäsovelluk- sessa.
Tallennuksen jälkeen on mahdollista sulkea kyseinen sovellus. Käyttämällä näp- päinyhdistelmää ”alt + f” avataan sovelluksessa näkymä, joka sisältää sovelluksen toimintoja. Yksi listassa olevista toiminnoista on ”exit”, joka voidaan valita myös painamalla näippäintä ”x” (Kuva 36).
Kuva 36. Käyttäjän luoma avainsana työpöytäsovelluksen sulkemiselle.
Viimeinen askel testitapauksessa on tallennetun tiedoston sisällön todentaminen.
Tiedoston aukaisemiseen on käytetty Robot Frameworkin sisäistä kirjastoa, Ope- ratingSystemiä, joka tarjoaa avainsanan nimeltä ”Get File”. Avainsanalle syöte- tään tiedosto, joka halutaan avatuksi. Aiemmin tallentaessa tiedostoa luotiin tie- dostonimestä globaali muuttuja, joten tiedostonimi on käyttäjällä tallennettuna.
Tiedostot tallennetaan tässä tapauksessa automaattisesti projektin juurihakemis- toon, jolloin tiedostoon pääsee käsiksi syöttämällä sille etuliitteen ”./”. Tiedoston avaamisen jälkeen verrataan, onko tiedoston sisältö sama kuin sille aikaisemmin syötetty teksti. Tekstin yhtäläisyyden todentamiseen käytetään sisäänrakennettua avainsanaa ”Should Be Equal” (Kuva 37).
Kuva 37. Tiedoston avaaminen ja sisällön toteaminen työpöytäsovelluksessa.
5.6 Testien ajaminen
Testien suorittaminen Robot Frameworkin avulla on yksinkertaisimmillaan erit- täin helppoa ja vaivatonta. Kappaleessa käydään läpi muutama erilainen keino käynnistää testisuoritukset. Lisätietoja ja monipuolisimpia komentorivin asetuksia
robotin ajamiseen löytyy osoitteesta:
http://robotframework.org/robotframework/latest/RobotFrameworkUserGuide.ht ml#all-command-line-options
Automaattisia testejä suorittaessa mobiilialustalla tulee muistaa, että fyysinen laite on kytkettynä tietokoneeseen kiinni, ja puhelimen asetuksista on sallittuna tiedon- siirto. Ilman näitä askelia testejä ei saada suoritetuksi puhelimella.
Testit voidaan käynnistää ilman mitään viitteitä (Kuva 38), jolloin ”robot”- komennolle annetaan vain tiedosto, joka sisältää testitapaukset.
Kuva 38. Yksittäisen testitiedoston ajaminen Robot Frameworkilla.
Kun halutaan, että robotti ajaa projektin kaikki luodut mobiilitestit kerrallaan, voidaan antaa arvoksi pelkkä hakemisto, joka sisältää testitiedostot, jolloin robotti suorittaa jokaisen tiedoston yksitellen (Kuva 39).
Kuva 39. Testihakemiston ajaminen Robot Frameworkilla.
Lisäargumentti ”-d” tarjoaa käyttäjälle mahdollisuuden osoittaa robotille hakemis- ton, jonne testisuorituksen aikana generoidut tiedostot, sekä lopuksi luodut raport- titiedostot menevät (Kuva 40).
Kuva 40. Tiedostojen tallentaminen hakemistoon testisuorituksen jälkeen.
Lisäargumentti ”-i” puolestaan tarkoittaa sitä, että robotti ajaa ne testit, jotka omistavat argumentin jälkeen kirjoitetut tunnisteet (Kuva 41). Tunnisteita voi olla useampi kuin yksi.
Kuva 41. Testitiedoston ajaminen sisältäen vain "Notepad"-tunnisteen omaavat testit.
5.7 Testitulokset
Testisuorituksen päätyttyä Robot Framework luo automaattisesti kolme raportti- tiedostoa: log.html, report.html ja output.xml. Tiedostot sisältävät yleiskuvan tes- tisuorituksen tuloksista, kuten luettelon suoritetuista testeistä, sekä niihin liittyviä tilastoja. Raporttitiedostoista on myös käyttäjien helppo tarkistaa, mikä osa testis- sä aiheuttaa epäonnistumisen ja miten kirjoitettu testi käyttäytyy suorituksen aika- na (Kuva 42). /36/ Lokitiedoston tarkoitus on antaa käyttäjälle korkeamman tason yleiskatsaus testisuorituksista /37/. Rakenteeltaan lokitiedosto on raporttitiedostoa hierarkkisempi, joka helpottaa yksittäisten testisuoritusten lukemista (Kuva 43).
Kuva 42. Yleiskatsaus Robot Frameworkin luomasta tiedostosta report.html.
Kuva 43. Yleiskatsaus onnistuneesta testitapauksesta Robot Frameworkin luo- masta tiedos-tosta log.html.
Kuva 44. Yleiskatsaus epäonnistuneesta testitapauksesta Robot Frameworkin luomasta tiedostosta report.html.
Kuva 45. Tarkempi katsaus onnistuneen testitapauksen sisällöstä Robot Fra- meworkin luomasta tiedostosta log.html.
Kuva 46. Tarkempi katsaus epäonnistuneesta testitapauksesta Robot Framewor- kin luomasta tiedostosta log.html.
5.8 Vertailukelpoiset testitulokset molemmilta alustoilta
Opinnäytetyössä on käytetty vain yhtä testitapausta alustaa kohden. Halutessa tar- kempia ja vertailukelpoisia testituloksia, on testitapauksien määrä oltava huomat- tavasti suurempi. Esimerkkitapaukset on luotu lähinnä havainnollistamistarkoituk- seen. Tuloksista voidaan päätellä, että molemmat testitapaukset toimivat testatta- vissa ympäristöissään.
Testituloksen on mahdollista ajaa erikseen tai yhdessä. Erikseen ajettuna testitu- lokset luodaan erillisiin raporttitiedostoihin, jolloin vertaileminen voi olla hanka- lampaa. Robot Framework tarjoaa kuitenkin mahdollisuuden ajaa useamman testi- tiedoston samaan aikaan, jolloin tässä tapauksessa molempien alustojen testita- paukset saadaan samaan raporttiin. Testaus suoritetaan komennolla ”robot (en- simmäisen tiedoston sijainti) (toisen tiedoston sijainti)” (Kuva 47). Tiedostonimiä on muutettu selkeyttämään raporttia.
Kuva 47. Molempien testitiedostojen yhtäaikainen ajaminen Robot Frameworkil- la.
Testin raportti tarjoaa näkymän, josta voidaan päätellä molempien testitapauksien onnistuneen (Kuva 48). Testitapaus sisältää sille annetun dokumentaation ja tun- nisteet sekä testin suorittamisajan.
Kuva 48. Yhteisien testituloksien näkymä report.html tiedostossa.
Raporttitiedostosta voidaan siirtyä suoraan lokitiedostoon klikkaamalla testita- pauksen nimeä tai painamalla sivun yläosassa oikealla sijaitsevaa ”LOG”- painiketta.
Lokitiedosto kattaa yksityiskohtaisemman näkymän testitapauksista, sisältäen jo- kaisen avainsanan ja niiden tietoja. Kuvasta voidaan päätellä, että jokainen testita- pauksen avainsana on toiminut onnistuneesti ja testitulokset vastaavat niiden odo- tettuja tuloksia (Kuva 49).
Kuva 49. Testitulokset avattuna lokinäkymässä.
