Diplomsko delo - COnnecting REpositories · Key words: Android platform, mobile application development, software testing, robotium, unit testing UDK: 621.395:004.77(043.2) Abstract

Tomaž Buzeti

Testiranje aplikacij za platformo Android

Diplomsko delo

Maribor, oktober 2011

I

Diplomsko delo visokošolskega strokovnega študijskega programa


Študent: Tomaţ Buzeti

Študijski program: VS ŠP Informatika in tehnologije komuniciranja

Smer: Sistemska podpora informatiki in tehnologijam komuniciranja

Mentor(ica): izr. prof. dr. Aleš Ţivkovič

Somentor(ica): asist., Uroš Goljat, univ. dipl. inţ. rač. in inf.

Lektor(ica): Brigita Buzeti, učiteljica slovenskega jezika

Maribor, oktober 2011

II

III

ZAHVALA

Zahvaljujem se mentorju izr. prof. dr. Alešu Ţivkoviču

in somentorju asist. Urošu Goljatu za pomoč in

vodenje pri opravljanju diplomskega dela.

Posebna zahvala velja staršem, ki so mi omogočili

študij.

IV


Ključne besede: platforma Android, razvoj mobilnih aplikacij, testiranje programske

opreme, robotium, testiranje enot

UDK: 621.395:004.77(043.2)

Povzetek

V diplomskem delu smo predstavili mobilno platformo Android, razvoj mobilne aplikacije -

myWallet, ki omogoča pregled osebnih financ, ter različne pristope testiranja programske

opreme za platformo Android. Podrobno smo opisali orodja in pristope, ki so primerni za

testiranje aplikacij na platformi Android ter z njimi testirali aplikacijo myWallet, ki smo jo

razvili v sklopu diplomske naloge. Osredotočili smo se predvsem na testiranje po principu

črne skrinje, testiranja enot z orodji za avtomatizacijo testov ter profiliranju uporabniškega

vmesnika.

V

TESTING THE ANDROID PLATFORM APPLICATION

Key words: Android platform, mobile application development, software testing, robotium,

unit testing

UDK: 621.395:004.77(043.2)

Abstract

In the following bachelor thesis we presented a mobile platform Android, Android application

development and various techniques in software testing appropriate for the Android platform.

We took a deeper look into the tools and techniques, which we used for testing on our own

application named myWallet. MyWallet’s functionality is taking care of a user’s personal

finances. Our main focus was on black box testing and unit testing using automatic tools and

also profiling graphic user interface.

VI

Vsebina 1 UVOD............................................................................................................................. 1

2 PLATFORMA ANDROID .............................................................................................. 2

2.1 Uvod ......................................................................................................................... 2

2.2 Kratka zgodovina platforme Android ........................................................................ 3

2.3 Arhitektura................................................................................................................ 3

2.4 Android market ......................................................................................................... 6

2.5 Primerjava Google Android in Apple iOS ................................................................. 7

2.6 Android SDK ............................................................................................................ 8

2.7 Android naprave ter virtualna naprava....................................................................... 9

3 RAZVOJ APLIKACIJE ................................................................................................ 10

3.1 Opis aplikacije ........................................................................................................ 10

3.2 Oblikovanje zaslonov .............................................................................................. 11

3.3 Izdelava zaslonov .................................................................................................... 11

4 PREGLED PRISTOPOV K TESTIRANJU PROGRAMSKE OPREME ....................... 16

4.1 Funkcionalno testiranje ........................................................................................... 17

4.1.1 Testiranje po principu bele skrinje (ang. white box testing) .............................. 17

4.1.2 Testiranje po principu črne skrinje (ang. black box testing) .............................. 18

4.1.3 Testiranje enot (ang. unt testing) ...................................................................... 18

4.1.4 Integracijsko testiranje (ang. integration testing) .............................................. 19

4.1.5 Regresijsko testiranje (ang. regression testing) ................................................. 19

4.2 Nefunkcionalno testiranje ....................................................................................... 19

4.2.1 Obremenitveno testiranje (ang. stress testing) .................................................. 19

4.2.2 Testiranje uporabnosti (ang. usability testing) .................................................. 20

VII

4.3 Avtomatizacija testiranja programske opreme ......................................................... 20

5 VRSTE TESTIRANJ IN ORODJA UPORABLJENA ZA PLATFORMO ANDROID .. 21

5.1 Testiranje po principu črne skrinje .......................................................................... 21

5.2 Testiranje po principu bele skrinje .......................................................................... 21

5.3 Testiranje enot ........................................................................................................ 22

5.4 Integracijsko testiranje ............................................................................................ 22

5.5 Regresijsko testiranje .............................................................................................. 22

5.6 Obremenitveno testiranje ........................................................................................ 23

5.7 Testiranje uporabnosti ............................................................................................. 23

5.8 Testiranje podatkovne baze SQLite s sqlite3 ........................................................... 24

5.9 Orodja za avtomatizacijo testiranja.......................................................................... 25

5.9.1 Orodje Robolectric........................................................................................... 25

5.9.2 Orodje Robotium ............................................................................................. 26

5.9.3 Orodje Monkeyrunner ...................................................................................... 27

5.10 Orodja za profiliranje uporabniškega vmesnika ................................................... 27

5.10.1 Optimiziranje pogledov z orodjem layoutopt .................................................... 27

5.10.2 Orodje Hierarchy Viewer ................................................................................. 28

5.10.3 Orodje Pixel Perfect ......................................................................................... 28

6 TESTIRANJE APLIKACIJE MYWALLET ................................................................. 29

6.1 Testne naprave ........................................................................................................ 30

6.2 Priprava testnih podatkov ........................................................................................ 30

6.3 Predloga testnih primerov- scenarijev ..................................................................... 31

6.4 Testiranje po principu črne skrinje .......................................................................... 32

6.5 Testiranje po principu bele skrinje .......................................................................... 32

VIII

6.6 Testiranje enot ........................................................................................................ 36

6.7 Regresijsko testiranje .............................................................................................. 36

6.8 Integracijsko testiranje ............................................................................................ 38

6.9 Testiranje SQL stavkov z adb shell – sqlite3 ........................................................... 38

6.10 Testiranje uporabnosti ......................................................................................... 39

6.11 Testiranje enot z orodji za avtomatizacijo testiranja ............................................. 41

6.11.1 Testiranje aktivnosti s TestCase2 razredom ...................................................... 41

6.11.2 Orodje Robolectric........................................................................................... 42

6.11.3 Orodje Robotium ............................................................................................. 43

6.11.4 Orodje UI/Application Exerciser Monkey ........................................................ 44

6.11.5 Orodje Monkeyrunner ...................................................................................... 45

6.12 Profiliranje uporabniškega vmesnika ................................................................... 46

6.12.1 Optimiziranje pogledov z orodjem layoutopt .................................................... 46

6.12.2 Orodje Hierarchy Viewer ................................................................................. 46

6.12.3 Orodje Pixel Perfect ......................................................................................... 48

7 REZULTATI TESTIRANJA ......................................................................................... 50

7.1 Funkcionalno testiranje ........................................................................................... 50

7.2 Nefunkcionalno testiranje ....................................................................................... 50

8 SKLEP .......................................................................................................................... 52

9 VIRI, LITERATURA .................................................................................................... 53

10 Priloge........................................................................................................................... 56

10.1 Kazalo slik .......................................................................................................... 56

10.2 Kazalo tabel ........................................................................................................ 57

10.3 Priloge na CD ...................................................................................................... 59

IX

10.4 Ostali testni primeri in scenariji ........................................................................... 59

X

UPORABLJENI SIMOBILI / UPORABLJENE KRATICE

ADT – Android Dvelopment Tools

API – Application Programming Interface

GPS – Global Positioning System

IDE – Integrated Development Environment

JVM – Java Virtual Machine

QA – Quality Assurance

SDK – Software Development Kit

SQL – Structured Query Language

XML – Xtensible Markup Language

Testiranje aplikacij za platformo Android Stran 1

1 UVOD

Vse večja popularnost in zmogljivost mobilnih naprav čedalje več ljudi pritegne k razvoju

aplikacij za mobilne naprave. Mobilne naprave še nekaj časa ne bodo tako zmogljive kot so

osebni računalniki, zato je toliko bolj pomembno, da so aplikacije napisane čim bolj optimalno

ter kakovostno. Za dosego le tega je potrebno posvetiti precej pozornosti tudi testiranju

programske opreme, s katerim zagotavljamo višjo kakovost aplikacije. Testiranje je zelo

pomemben del ţivljenjskega cikla razvoja aplikacij, ki pa mu razvijalci običajno posvečajo

premalo pozornosti.

Testiranje moramo začeti ţe v zgodnji fazi. Testiranje je proces izvajanja programa z

namenom odkrivanja napak. Namen testiranja je dokazovanje prisotnosti napak in ne

odpravljanje napak. Testiranje si lahko olajšamo z uporabo orodij, s katerimi doseţemo

avtomatizacijo testov. S tem načinom prihranimo veliko časa, še posebej pri testnih metodah,

ki jih ponavljamo znova in znova. Testne primere si vnaprej pripravimo in jih nato izvajamo

nad aplikacijo.

V diplomskem delu smo najprej predstavili mobilno platformo Android, na kateri smo testirali

aplikacijo poimenovano myWallet, ki smo jo razvili v sklopu diplomske naloge in je

predstavljena v tretjem poglavju. Četrto poglavje vsebuje teoretičen opis testiranja programske

opreme, medtem ko smo v petem poglavju opisali vrste testiranj ter orodja, ki smo jih

uporabili za testiranje Android aplikacije. V šestem poglavju so navedeni praktični primeri

testiranja aplikacije myWallet. V zadnjem poglavju smo opisali testne rezultate, ki smo jih

dobili s testiranjem aplikacije.

Za testiranje aplikacij smo uporabili napravo Samsung Galaxy S z nameščenim operacijskim

sistemom Android ter navidezno napravo znotraj razvojnega okolja Android SDK.


2 PLATFORMA ANDROID

2.1 Uvod

Android je operacijski sistem za mobilne naprave, kot so mobilni telefoni in tablični

računalniki, ki temelji na jedru Linux s programskim vmesnikom Java.

Beseda izhaja iz angleške besede »android«, ki predstavlja robota, čigar izgled in obnašanje

spominjata na človeka[1].

Android je odprtokodna rešitev, ki je izdana pod licenco Apache in uspešno tekmuje proti

drugim mobilnim platformam kot so platforme podjetij Apple, Microsoft, Nokia, Sony

Ericsson, HP, Samsung, itd. Android je trenutno najbolj razširjen operacijski sistem na

mobilnih napravah[2][3]. Ravno ta odprtokodna rešitev privabi v razvojno skupnost čedalje

več ljudi, kar seveda pomeni tudi več aplikacij.

Android omogoča razvoj aplikacij, ki izrabljajo prednosti celotne naprave s čimer omogoča

izdelavo bogatih aplikacij. Dodatne aplikacije lahko spreminjajo ali zamenjujejo osnovne

aplikacije ter komponente uporabniškega vmesnika. Z aplikacijami lahko kličemo, pošiljamo

sporočila, uporabljamo kamero, pridobivamo lokacijo, uporabljamo zaslon občutljiv na dotik,

ipd. Razvijalec lahko kombinira podatke s spleta in podatke s telefona (imenik, koledar,

lokacija) za zagotavljanje koristnejših aplikacij za končnega uporabnika. Aplikacije tečejo v

ozadju, vendar so pri tem še vedno aktivne ter beleţijo informacije, uporabljajo vmesnike

strojne opreme ter nas sproti obveščajo o nekaterih dogodkih.

Android podpira 2D in 3D grafiko z uporabo knjiţnic OpenGL. Shranjevanje podatkov

omogoča s podatkovno bazo SQLite[4].

Vsaka Android aplikacija je ločen proces in ima lasten uporabniški identifikator (ang. userid),

ki je generiran avtomatsko v času izvedbe aplikacije. Aplikacija je tako izolirana od ostalih


aplikacij in ne škoduje drugim aplikacijam. Android ne razlikuje med aplikacijami, saj so zanj

vse aplikacije enake. Pred nameščene in tudi tiste, ki jih nalagamo sami, so grajene isto in

imajo enak dostop[5].

2.2 Kratka zgodovina platforme Android

Google Inc. je v letu 2005 odkupil prvotnega razvijalca programske opreme - Android Inc.[6].

Trenutno ga razvijajo skupaj s člani skupine - Open Handset Alliance[7]. Skupino sestavlja

več kot 80 vodilnih podjetij iz različnih področij, kot so mobilni operaterji, proizvajalci strojne

in programske opreme ter podjetja, ki se ukvarjajo s prodajo mobilnih naprav. Google jih je

zdruţil leta 2007 z idejo gradnje platforme za mobilne naprave, ki bo prilagojena razvijalcem

in uporabnikom, saj jo bo moţno uporabljati na veliko različnih napravah. Android je v prvi

vrsti namenjen mobilnim telefonom, vendar deluje tudi na drugih napravah kot so npr. tablični

računalniki, širi pa se tudi na druga področja, recimo v avtomobilsko industrijo[8].

2.3 Arhitektura

Slika 2-1 prikazuje glavne komponente odprtokodnega operacijskega sistema Android. Vsak

nivo, ki je nad drugim, lahko uporablja storitve, ki jih ponuja nivo pod njim.


Slika 2-1: Prikaz arhitekture platforme Android[4]

Aplikacije (ang. Applications)

Operacijski sistem Android je na voljo z nekaj osnovnimi aplikacijami kot so odjemalec

elektronske pošte, koledar, zemljevid, internetni brskalnik, imenik in drugo. Vse aplikacije so

napisane v programskem jeziku Java[4].

Aplikativno ogrodje (ang. Application framework)

Android ponuja razvijalcem gradnjo bogatih in inovativnih aplikacij. Razvijalci lahko

neomejeno izkoristijo prednosti strojne opreme naprave, dostopajo do informacij o lokaciji,

poganjajo storitve, ki tečejo v ozadju, nastavljajo alarme, opomnike, dodajajo opozorila v

statusno vrstico in še mnogo več.


Razvijalci imajo poln dostop do ogrodja kot sistemske aplikacije. Aplikativna arhitektura je

narejena tako, da poenostavi ponovno uporabo komponent. Vsaka aplikacija lahko objavi

svoje storitve in katerakoli druga aplikacija lahko te zmoţnosti uporabi.

Vsako aplikacijo sestavlja skupek storitev in sistemov, vključujoč[4]:

- bogat in razširljiv skupek pogledov (ang. Views) - uporabljeni so za gradnjo aplikacij.

S pogledi določamo postavitev naših elementov v aplikaciji.

- ponudniki vsebin (ang. Content provider) – priskrbijo dostop do podatkov iz drugih

aplikacij ali za deljenje lastnih podatkov.

- upravitelj virov (ang. Resource manager) - omogoča dostop do virov, ki niso v kodi.

Take datoteke so lokacijske datoteke, grafične datoteke, besedilne datoteke, datoteke z

določeno postavitvijo elementov.

- upravitelj obvestil (ang. Notification manager) – aplikaciji omogoča prikazovanje

opozoril v statusni vrstici.

- upravitelj aktivnosti (ang. Activity manager) - sluţi za upravljanje ţivljenjskega cikla

aplikacije.

Sistemske knjižnice (ang. System libraries)

Android vključuje knjiţnice napisane v programskem jeziku C/C++, ki jih uporabljajo ostale

Android komponente. Nekaj glavnih knjiţnic[4]:

- System C library – implementacija standardne C sistemske knjiţnice (libc),

prilagojene za vgrajene naprave, osnovane na operacijskem sistemu Linux.

- Media Libraries – knjiţnica podpira predvajanje in snemanje avdio in video zapisov,

kot tudi zajemanje statičnih slikovnih datotek, vključno z MPEG4, H.264, MP3, AAC,

AMR, JPG in PNG

- Surface Manager – knjiţnica upravlja dostop do prikazovalne površine.

- LibWebCore – spletni brskalnik, ki se uporablja kot Android brskalnik in kot vgrajen

brskalnik pri uporabi spletnega pogleda (ang. web view).

- SGL – 2D grafično orodje


- 3D libraries – knjiţnica implementirana na osnovi OpenGL ES 1.0. Uporablja strojni

3D pospeševalnik (če je na voljo) ali visoko optimizirano programsko 3D rasterizacijo.

- FreeType – bitne in vektorske pisave.

- SQLite – relacijska podatkovna baza, ki je na voljo vsem aplikacijam.

Izvajalno okolje (ang. Android runtime)

Vsaka Android aplikacija je ločen proces z lastno različico Dalvik virtualnega stroja (ang.

Dalvik Virtual Machine). Dalvik je napisan tako, da lahko naprava učinkovito poganja več

virtualnih strojev. Dalvik poganja dex datoteke (ang. Dalvik Executable), ki nastanejo v času

povezovanja in so optimizirane za minimalno porabo pomnilnika. Dalvik virtualni stroj teče

na jedru Linux[4].

Linux jedro (ang. Linux kernel)

Android uporablja Linux različico 2.6 za sistemske storitve kot so varnost, upravljanje s

pomnilnikom, upravljanje s procesi, mreţno opremo in gonilnike naprave. Do tega sloja ne

moremo dostopati direktno. Jedro se obnaša kot vmesna plast med strojno opremo in

preostalim programskim delom[4].

2.4 Android market

Android market je bil naznanjen avgusta leta 2008, na voljo pa je od oktobra 2008. V začetku

so bile aplikacije brezplačne nato pa je februarja 2009 bila predstavljena podpora za plačljive

aplikacije v ZDA in Veliki Britaniji, kasneje, septembra 2010, pa še podpora novim 29

drţavam [9][10]. Trenutno je na voljo preko 200.000 aplikacij, večina jih je brezplačnih[11].

Android market je spletna aplikacija za Android naprave, razvita s strani podjetja Google, in je

nameščena na večini Android naprav. Uporabniku omogoča brskanje in prenašanje aplikacij,

ki so jih objavili drugi razvijalci. Uporabnik lahko išče tudi po imenu aplikacije. Na voljo je

tudi podroben opis aplikacije, komentarji in ocene drugih uporabnikov te aplikacije.


2.5 Primerjava Google Android in Apple iOS

Google in Apple sta dve največji podjetji, ki se borita za prevladujočo pozicijo na trgu

mobilnih naprav, zato ju bomo primerjali v nekaj pogledih.

Razvoj

Obe platformi imata na voljo veliko virov za razvijalce. Android ponuja brezplačen Android

SDK (ang. Software Development Kit) in precej člankov na temo razvoja aplikacij.

Apple zahteva, da se prijavimo v program razvijalcev (ang. iPhone developer program) z letno

članarino v višini 99$. S tem si lahko prenesemo iPhone SDK in dostopamo do virov,

namenjenih razvijalcem[12].

Android uporablja za razvoj aplikacij programski jezik Java, medtem ko iPhone (iOS)

uporablja programski jezik »Objective C« s Cocoa Touch API (ang. Application Programming

Interface).

Stroški

Google zaračuna enkraten znesek 25$ za registracijo kot Android razvijalec in objavo

aplikacije v Android market[13]. Na drugi strani Apple zaračuna 99$ za registracijo kot

razvijalec in dovoli nalaganje aplikacij v Apple App Store zatem, ko opravimo proces

preverjanja[12].

Tako Google kot Apple vzameta 30% zneska od vsake prodane aplikacije.

Velikost tržnice

Apple App Store je veliko večji kot Android market, čeprav ga Android market hitro dohiteva.

Podatki iz maja 2011 kaţejo, da ima Apple App Store več kot 350.000 aplikacij, medtem ko je

Android market v mesecu marcu 2011 dosegel število 250.000[13].

Iskanje aplikacij

Iskanje aplikacij je na obeh platformah zahtevno, saj zaradi velikega števila aplikacij le to

teţko najdemo, z razvojnega vidika pa teţje doseţemo, da je naša aplikacija vidna. Zaradi


manjšega števila aplikacij ima Android market trenutno prednost. Android market je

uporabniku manj prijazen kot Apple App Store in nima namizne aplikacije za brskanje po

trţnici.

Vračilo kupnine

Android market ponuja tudi vračilo denarja v primeru, da aplikacije več ne ţelimo imeti.

Zahtevamo ga lahko samo enkrat v 15-ih minutah odkar smo naloţili aplikacijo

Tudi Apple App Store podpira vračilo kupnine, vendar je postopek zahtevnejši, saj jo moramo

zahtevati preko programa iTunes.

Dostopnost sistema

Apple App Store je popolnoma zaprt in je kontroliran s strani podjetja Apple. Ko naloţimo

aplikacijo v sistem nimamo zagotovila, da bo objavljena. Apple pregleda vsako aplikacijo

preden jo objavi, medtem ko Google tega ne stori in prav zaradi tega je znano, da so na Apple

App Store bolj kakovostne aplikacije.

Android market dovoli objavo skoraj vsake aplikacije, razen če kršijo avtorske pravice.

2.6 Android SDK

Android SDK omogoča razvoj aplikacij za Android platformo. Vsebuje različne primere

projektov z izvorno kodo, razvojna orodja, virtualno napravo in potrebne knjiţnice za

izgradnjo aplikacij za Android.

Zahteve, ki ga moramo izpolniti, če ţelimo razvijati aplikacije za Android s pomočjo

razvojnega okolja Eclipse:

1. imeti moramo računalnik, ki je dovolj zmogljiv in podpira Javo;

2. namestimo SDK začetni paket;

3. namestimo ADT vtičnik za Eclipse (ang. plugin);


4. dodamo čim več Android platform oz. tiste, za katere mislimo, da jih bomo

potrebovali;

5. v okolju Eclipse pokaţemo pot do Android SDK. Če smo vse korake uspešno opravili,

se v orodni vrstici prikaţe ikona Android (Slika 2-2). S klikom na to ikono se odpre

»Android SDK in AVD manager«, pripomoček, ki sluţi za ustvarjanje in poganjanje

virtualnih naprav. Projekt izdelamo tako, da gremo na »file -> new -> Android

project«.

Slika 2-2: Statusna vrstica po namestitvi ADT vtičnika in Android SDK

2.7 Android naprave ter virtualna naprava

Virtualna naprava (ang. emulator)

Android omogoča testiranje aplikacij preko virtualne naprave, torej za razvoj niti ne

potrebujemo dejanske Android naprave. Seveda to ni priporočljivo, saj je vedno dobro testirati

aplikacijo na čim več napravah.

Virtualna naprava oz. emulator lahko posnema katerokoli napravo, saj lahko nastavimo

poljubno verzijo naprave in tudi velikost ter ločljivost zaslona. Na virtualni napravi delamo

enako kot na Android napravi, razlika je le v tem, da namesto, da bi se dotikali zaslona,

vlečemo miškin kazalec po zaslonu.

Android naprave

Android je operacijski sistem, ki ga najdemo na veliko različnih napravah, katere grupiramo v

naslednje kategorije: pametni telefoni, tablični računalniki, e-čitalniki, netbooki ter druge

naprave kot so npr. razni predvajalniki.


3 RAZVOJ APLIKACIJE

3.1 Opis aplikacije

Aplikacija myWallet je primerna za mobilne telefone z operacijskim sistemom Android in je

namenjena vsem, ki bi ţeleli boljši nadzor nad osebnimi financami. Uporabniku omogoča, da

si kategorizira svoje dohodke in odhodke kar mu omogoča boljši vpogled nad osebnimi

financami. Uporabnik ima moţnost vnesti več računov oz. »denarnic«, kategorij in transakcij.

Cilj aplikacije je, da bi uporabnik vpisoval vse prihodke/odhodke na različnih računih ter jih

kategoriziral v primerne kategorije. Aplikacija ponuja izpis naslednjih poročil:

- izpis vseh transakcij;

- izpis zadnjih 10 transakcij;

- izpis transakcij zadnjih 7 dni;

- izpis transakcij za tekoč mesec;

- izpis transakcij glede na podan

časovni okvir;

- izpis transakcij po kategoriji;

- izpis transakcij glede na račun;

- izpis prihodkov;

- izpis odhodkov.

Slika 3-1: Interakcija uporabnik-mobilni telefon

Slika 3-1 prikazuje dvosmerno komunikacijo med uporabnikom in mobilnim telefonom.

Uporabnik vnaša podatke, aplikacija odgovarja z raznimi sporočili ter prikazovanjem

podatkov.

Podatki se shranjujejo v podatkovno bazo tako, da so na voljo vedno, ko ţelimo do njih

dostopati preko aplikacije.


3.2 Oblikovanje zaslonov

Android pozna več načinov ureditve elementov (Slika 3-2), ki jih med sabo kombiniramo[14]:

- linearni prikaz elementov;

- relativen prikaz elementov;

- tablični prikaz elementov;

- mreţni prikaz elementov;

- jezični prikaz elementov;

- elementi v obliki seznama.

V aplikaciji myWallet je večinoma uporabljena kombinacija linearnega in relativnega prikaza

elementov. Linearni prikaz elementov je enostavnejši, elemente lahko postavljamo samo

enega poleg drugega oz. enega pod drugega, medtem ko pri relativnem lahko točno

nastavljamo pozicije ter poravnave.

Slika 3-2: Prikaz ureditve elementov

3.3 Izdelava zaslonov

Pozdravni zaslon (main.xml - Slika 3-3) prikaţe izbirni meni. Zanj smo uporabili linearni

prikaz. Korenski element je značka LinearLayout, v katero vpišemo nekaj osnovnih podatkov,

kot je velikost ter orientacija elementov in stil, ki predstavlja barvo ozadja. Znotraj tega

elementa gnezdimo ostale značke, ki v tem primeru predstavljajo gumbe.


Slika 3-3: Pozdravno okence

Programska koda ki skrbi, da se bo ob kliku odprla nova aktivnost, je v datoteki

MyWalletActivity.java. V programski kodi določimo, katero obliko uporabljamo v tej

aktivnosti:

@Override

public void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.main);

}

Zaslona računi (racuni.xml) in kategorije (kategorije.xml) sta zgrajena na enak način. Oba sta

narejena z LinearLayout in vsebujeta gumb za dodajanje računov/kategorij, bliţnjico do

domačega zaslona ter seznam, v katerega se naloţijo vsi računi(Slika 3-4) oz. kategorije. Če v

podatkovni bazi nimamo računov/kategorij, se izpiše opozorilo (Slika 3-5).


Slika 3-4: Zaslon računi

Slika 3-5: Prazen zaslon kategorij

Na vsakem elementu seznama računov in kategorij imamo poslušalca dogodkov, ki čakata na

kratek ali dolgi klik (onItemClick, onItemLongClick). V primeru kratkega klika se odprejo vse

transakcije določenega računa ali kategorije. V primeru dolgega klika na vrstico se bo vrstica

odstranila iz seznama in podatkovne baze.

@Override

public void onItemClick(AdapterView<?> arg0, View arg1, int position, long id) {

Intent i = new Intent(this,porocilaIzpis.class);

i.putExtra("mojId", m_accounts.get(position).getAccountId());

startActivity(i); }

Oblika za posamezno vrstico seznama računov in kategorij je v ločeni datoteki

(racuni_row.xml), na katero se sklicujemo ob vsakem dodanem elementu v seznam. Vrstica

računa je sestavljena iz ikone ter tekstovnih polj v katere se vpisujejo podatki iz podatkovne

baze. Stanje na računu se posodobi z vsako novo transakcijo.

Zaslon transakcije (dodaj_transakcijo.xml) sluţi za dodajanje transakcij. Gre za kombinacijo

relativne in linearne postavitve elementov. Zaslon je sestavljen iz dveh spustnih seznamov

(računi in kategorije), ki iz podatkovne baze izpišeta vse račune oz. kategorije.

Posebnost pri tem zaslonu je moţnost izbire datuma z razredom datepicker[16] (Slika 3-7). Če

ne izpolnimo vseh vnosnih polj okenca dodajanje transakcij, se izpiše napaka (Slika 3-6).


Slika 3-6: Napaka pri dodajanju transakcij

Slika 3-7: Izbira datuma z razredom datepicker

Zaslona dodajanje računa (dodaj_racun.xml) in dodajanje kategorije (dodaj_kategorijo.xml)

sta si zelo podobna, saj imata enako funkcionalnost. Skrbita za zajem uporabnikovega vnosa

podatkov katere nato shranjujeta v podatkovno bazo. Če je katero od polj prazno, nas bo

aplikacija opozorila (Slika 3-8). Prav tako nas bo aplikacija opozorila, če ţelimo dodati

račun/kategorijo z imenom, ki ţe obstaja (Slika 3-9). Oba zaslona imata tudi gumb »Izbriši« s

katerim lahko postavimo vnosna polja na privzete – prazne vrednosti.

Slika 3-8: Izpis napake pri dodajanju računa

Slika 3-9: Izpis napake pri dodajanju kategorij

Podatke dodajamo v podatkovno bazo preko razreda ContentValues in metode put.

ContentValues values = new ContentValues();

values.put(DbHelper.colName, ime);

values.put(DbHelper.colValue, stanje);

values.put(DbHelper.colAccType, tip);

Zaslon poročila (porocila.xml - Slika 3-10) vsebuje meni preko katerega določimo kriterij za

izpis transakcij.


Koda, ki se skriva za gumbi je podobna kot v

MyWalletActivity.java. Razlika je le v tem, da tukaj

pred odpiranjem nove aktivnosti pošljemo določene

podatke s trenutne aktivnosti na drugo. Te podatke

potrebujemo kasneje za pravilen izbor kriterija za sortiranje

transakcij.

Slika 3-10: Zaslon poročila

Zaslon za izpisovanje poročil (porocilaizpis.xml) je grajen na enak način kot racuni.xml in

kategorije.xml, saj skrbi za prikaz podatkov v seznam.

V primeru, da nobena transakcija ne ustreza kriteriju se izpiše »ni transakcij«. Izgled vrstic

transakcij je določen v datoteki (porocilaizpis_row.xml). Če je transakcija pozitivna, se

prikaţe ikona za pozitivne transakcije, v nasprotnem primeru za negativne (Slika 3-11)

Slika 3-11: Izpis transakcij


4 PREGLED PRISTOPOV K TESTIRANJU PROGRAMSKE OPREME

Testiranje je proces, ki poda informacijo o kakovosti ter oceni, ali je program sprejemljiv za

končne uporabnike.

- Kakovost ni absolutna. Testiranje ne more zagotoviti popolnosti produkta.

- Proces testiranja je le del procesa zagotavljanja kakovosti (QA – ang. Quality

Assurance).

- Testira se v vseh fazah razvoja. Predmet in kontekst testiranja se skozi razvoj

spreminjata.

Pri testiranju programske opreme ţelimo le-tej dodati vrednost. Dodajanje vrednosti skozi

testiranje pomeni višanje kakovosti in zanesljivosti aplikacije. Večjo zanesljivost dobimo z

iskanjem in odpravljanjem napak oz. hroščev v celotnem ali pa samo v delu programa[17].

Napaka je odpoved ali odstopanje od podanih funkcionalnih in nefunkcionalnih zahtev. Kadar

se lotimo testiranja, moramo predpostavljati, da program, aplikacija ali sistem vsebuje napake.

S testiranjem ne dokaţemo, da je program brez napak. Namen testiranja je dokazati prisotnost

napak in ne odpravljanje napak. Testiranje je analiza produkta in primerjava med dejanskim

stanjem produkta ter med pričakovanim oziroma zahtevanim.

V literaturi najdemo več definicij za področje testiranja med katerimi smo izbrali naslednje:

»Testiranje programske opreme je nekaj, kar moramo videti v programski opremi v

negativnem smislu, saj moramo poiskati nekaj, kar manjka ali ne deluje, kot

pričakujemo« – Deepak Chennoria.

»Testiranje je proces izvajanja programa z namenom iskanja napak«[17].

Uspešnost testiranja se kaţe kot število najdenih napak v programu. Natančno število napak v

določenem programu je nemogoče vnaprej predvideti.


Večina programske opreme ima ciljno skupnost. Ciljna skupnost za video igre je popolnoma

drugačna kot za programsko opremo za bančništvo, zato mora organizacija, ki razvija

programsko opremo, oceniti, ali bo končni izdelek sprejemljiv za končnega uporabnika.

Testiranje programske opreme je proces, ki skuša to doseči.

Testiranje programske opreme je zelo pomembno in ga je potrebno začeti čimprej, ţe v

zgodnji fazi razvoja, saj se stroški popravljanja napak s časom višajo in jih je čedalje teţje

odkriti.

Testiranje sestavljajo naslednje aktivnosti:

- definiranje ciljev;

- načrtovanje testnih primerov;

- pisanje testnih primerov;

- izvedba testnih primerov;

- poganjanje sistema ali pa samo njegove komponente;

- opazovanje in beleţenje rezultatov tega poganjanja;

- vrednotenje rezultatov;

- vzdrţevanje testnih primerov.

4.1 Funkcionalno testiranje

4.1.1 Testiranje po principu bele skrinje (ang. white box testing)

Pri testiranju po principu bele skrinje se izvaja podrobno testiranje s poznavanjem strukture

programa ter popolnega vpogleda v kodo programa. Brez vpogleda v skrinjo ni moţno

preveriti določenih načinov delovanja aplikacije. Testiranje zastavimo tako, da se vsak

element/del programa izvede vsaj enkrat. Testni primeri so pripravljeni na podlagi raziskave

logičnih poti sistema[17].


Program lahko prikaţemo kot graf (Slika 4-1), ki je

sestavljen iz:

- vozlišč - predstavljajo trditve, ki so lahko

uporabljene pri izvajanju programa;

- vejnih vozlišč – vozlišča z več izhodi;

- poti – moţne poti po katerih se lahko premikamo od

enega vozlišča do drugega.

Pokritost testiranja se računa glede na število izvedenih

poti skozi graf in jo računamo za:

- odločitve;

- stavke;

- spremembo pogojev(zanke);

- klic drugih delov.

Slika 4-1: Program predstavljen kot

graf

Za računanje pokritosti testov običajno uporabljamo namenska orodja.

4.1.2 Testiranje po principu črne skrinje (ang. black box testing)

Testiranje po principu črne skrinje obravnava aplikacijo kot »črno skrinjo« brez kakršnegakoli

znanja o njeni zgradbi in pri tem ignorira interne mehanizme ali komponente. Osredotočeni

smo izključno na izhod, ki ga generirajo izbrani vhodni podatki v aplikaciji, kjer iščemo

situacije, v katerih se program ne obnaša v skladu s specifikacijo. Testni primeri so

pripravljeni na podlagi funkcionalnosti sistema. Zaradi nepoznavanja zgradbe se lahko zgodi,

da preizkuševalec opravi preveč nepotrebnih testnih primerov, ali pa izpusti kateri del[17].

Testiranje programske opreme po principu bele in črne skrinje sta pristopa, ki sta dobila ime

po preizkuševalčevem vidiku aplikacije.

4.1.3 Testiranje enot (ang. unt testing)

Testiranje enot se nanaša na testiranje, ki preverja delovanje posameznih delov kode oz.

segmentov. Enote so lahko moduli, komponente, razredi in vmesniki.


Pri testiranju enot si izberemo enoto, ki jo testiramo, ostali del izvorne kode pa izoliramo. Pred

integracijo testiramo vsako enoto posebej in jo šele po uspešnem testiranju integriramo[15].

4.1.4 Integracijsko testiranje (ang. integration testing)

To je testiranje sestavljenih/zdruţenih delov aplikacije z namenom, da se preveri pravilnost

skupnega delovanja [15].

Deli aplikacije so lahko moduli, samostojne aplikacije in mreţne aplikacije.

Lahko ga izvajamo postopoma ali v celoti. Na teţave lahko naletimo pri integraciji delov,

katerih lastnik kode je nekdo drug.

4.1.5 Regresijsko testiranje (ang. regression testing)

Je testiranje sistema zaradi sprememb, ki so bile narejene v razvoju, razhroščevanju (ang.

debugging), vzdrţevanju ali ob izdaji nove različice aplikacije. Ponovno »selektivno«

testiranje funkcionalnosti z namenom, da se preveri nenamerna škoda, imenujemo regresijsko

testiranje. Običajne metode regresijskega testiranja so poganjanje prejšnjih testov in ponovno

preverjanje, ali so se prej odpravljene napake spet pojavile. Regresijsko testiranje, zaradi

velikega števila ponovitev izvajamo z avtomatiziranimi orodji.

4.2 Nefunkcionalno testiranje

Poznamo še posebne metode, ki preverjajo izpolnjevanje nefunkcionalnih zahtev. V primerjavi

s funkcionalnim testiranjem, ki preverja napake v programski opremi, nefunkcionalno

testiranje preverja izbrane lastnosti aplikacije in ne kaj aplikacija dela.

4.2.1 Obremenitveno testiranje (ang. stress testing)

Obremenitveno testiranje je oblika testiranja, s katero določimo stabilnost programske opreme,

kjer simuliramo »stresne« pogoje kot so mnoţično ponavljanje določenih akcij, vnos velikih

vrednosti, istočasno delo več ljudi na sistemu, ipd. S tem načinom testiranja prever jamo

zanesljivost aplikacije.


4.2.2 Testiranje uporabnosti (ang. usability testing)

Pri teh testih gre za analizo uporabnosti. Testi uporabnosti morajo biti narejeni tako, da

preverijo, ali je uporabniški vmesnik dovolj preprost za razumevanje. Testi so v glavnem

osredotočeni na uporabo aplikacije.

Testi uporabnosti ne le, da morajo oceniti uporabnost aplikacije, ampak tudi podati podatke o

uporabljenih metodah, s katerimi lahko izboljšamo uporabniško izkušnjo[18].

4.3 Avtomatizacija testiranja programske opreme

Avtomatizacijo testov uporabljamo, da bi prihranili čas. Z avtomatizacijo testov se ukvarjajo

posebej usposobljeni inţenirji. Avtomatizacijo testov lahko uporabimo za popolno ali delno

opravljanje testiranja. Vseh vrst testiranj ne moremo avtomatizirati. Orodja so zmoţna tudi

hitrega računanja pokritosti testiranja ter generiranja poročil. Avtomatizacijo testov običajno

izberemo za:

- večkratno ponavljanje istih testnih primerov (regresija);

- izvedbo testov, ki se jih ročno ne da preveriti (zmogljivostno, obremenitveno

testiranje);

- pripravo testnih podatkov, ki jih večkrat uporabljamo;

- pripravo testnega okolja nad katerim izvajamo teste;

- izdelavo poročil pokritosti testiranja.


5 VRSTE TESTIRANJ IN ORODJA UPORABLJENA ZA PLATFORMO ANDROID

5.1 Testiranje po principu črne skrinje

Pred pričetkom testiranja po principu črne skrinje si pripravimo testne podatke. Testne

podatke pripravimo na podlagi funkcionalnosti sistema. Testiranje lahko poteka na realni ali

virtualni napravi Android. Upoštevamo postopek, ki je opisan kot zaporedje ukazov v predlogi

testnega scenarija, pozorni smo na izhodne rezultate aplikacije. Po končanem zaporedju

ukazov v predlogo testnih primerov, vpišemo ugotovljene rezultate.

Android OS ne dovoli vpisa napačnih tipov podatkov v aplikacijo, če imamo pravilno

definirane tipe vnosnih polj. Če aplikacija pričakuje številčno vrednost bo dovolila vnos le

številčnih vrednosti. Napačnih podatkov ni moţno vnesti niti z zamenjavo tipkovnice ali s

kopiranjem napačnih podatkov v vnosna polja, saj napačne podatke aplikacija ignorira.

5.2 Testiranje po principu bele skrinje

Testiranje po principu bele skrinje omogoča vpogled v izvorno kodo aplikacije, na podlagi

katere prikaţemo del aplikacije kot graf, ki je sestavljen iz vozlišč in moţnih poti po aplikaciji.

Z moţnostjo pogleda izvorne kode lahko računamo tudi pokritost testiranja, ki prikazuje

število razredov, metod in vrstic kode, ki so bile izvedene v času testiranja. Za izračun

pokritosti testiranja običajno uporabimo orodja, ki pokritost računajo samodejno (ant

coverage, EMMA).

Testni primeri so pripravljeni na podlagi grafa aplikacije in poti po njem.


5.3 Testiranje enot

Osredotočeni smo na testiranje aktivnosti. Aktivnosti so komponente aplikacije, ki

predstavljajo zaslon, s katerim uporabnik komunicira (dodajanje računov, pregled računov,

dodajanje kategorij, pregled kategorij, dodajanje transakcij, izpis poročil).

Testiranje izvajamo s pomočjo orodij za avtomatizacijo testov. Testiranje enot smo izvajali s

pomočjo orodja Robotium s katerim smo napisali testne primere. Testni primeri za

avtomatizacijo testov so običajno pisani v programskem jeziku Java, lahko pa so tudi v

programskem jeziku Python.

5.4 Integracijsko testiranje

Module, ki smo testirali ločeno kot teste enot, sedaj zdruţimo ter testiramo njihovo skupno

delovanje in medsebojno odvisnost. Aktivnosti so običajno medsebojno odvisne in zahtevajo

integracijo s sistemom.

Naše aktivnosti dostopajo do podatkovne baze ter v njo pišejo oz. iz nje berejo podatke,

pošiljajo podatke iz ene aktivnosti v drugo, ipd. Testiramo obnašanje ene aktivnosti v

odvisnosti od rezultatov druge aktivnosti ter njuno skupno delovanje.

5.5 Regresijsko testiranje

Regresijsko testiranje izvajamo ţe v zgodnji fazi razvoja aplikacije, saj z njim testiramo le

dele kode. Izvajamo ga sproti z implementacijo novih funkcionalnosti v aplikacijo. Izvajamo

ga z avtomatiziranimi orodji, zato je potrebna predhodna priprava testnih primerov v

programski kodi. Preverjamo, ali del aplikacije, ki je ţe deloval, še vedno deluje ob

spremembi drugega dela aplikacije.

Teste smo izvajali s pomočjo ogrodja Robotium, ki je opisano v poglavju 5.9.2.


5.6 Obremenitveno testiranje

Obremenitveno testiranje izvajamo z orodjem UI/Application Exerciser Monkey, imenujemo

ga monkey.

Monkey[20] je program, ki teče na napravi ali virtualni napravi in generira pseudo naključne

klike, dotike, premike in sistemske dogodke. Uporabljamo ga za obremenitveno testiranje

aplikacije z naključnim, vendar ponovljivim obnašanjem. Izvaja se v ukazni vrstici. Vključimo

ga lahko na katerokoli virtualno napravo ali Android napravo. Ponuja več opcij, ki jih delimo

v štiri kategorije[20]:

- konfiguracija osnovnega izbora, kot je nastavljanje števila dogodkov, ki jih bomo

izvedli;

- omejevanje testov na en paket;

- tipi dogodkov in frekvenca;

- opcije razhroščevanja.

Monkey med delovanjem generira dogodke in jih pošilja v sistem, hkrati pa tudi opazuje

sistem pod testom in čaka na naslednje pogoje:

- poskus preklopa na drugi paket, če smo določili, da monkey sproţimo samo na

določenem paketu. Vse poskuse preklopa blokira.

- sesutje ali pojavo izjeme, ki je ne zna razrešiti. Monkey se bo ustavil in javil napako.

- pojavo »application not responding error«. Monkey se bo ustavil in javil napako.

5.7 Testiranje uporabnosti

Pri razvoju mobilnih aplikacij se splača biti še posebej pozoren na naslednje stvari, saj smo

ravno na njih pozorni pri testiranju uporabnosti[21]:

- v aplikaciji mora biti moţnost razveljavljanja akcij;

- priporočljiva je uporaba celotnega zaslona;

- moţnost skrivanje tipkovnice;


- gumbi morajo biti pravilne velikosti, tako da so primerni tudi za ljudi z večjimi prsti;

- gumbi z enako funkcionalnostjo naj imajo enako barvo;

- naravne in konsistentne ikone;

- besedila naj bodo kratka, jasna in enostavna;

- vnos besedila v polje naj se začne z veliko črko;

- velikost besedila mora biti primerna, ne premajhna in ne prevelika;

- potrditvenih sporočil se izogibamo;

- če aplikacija ţeli prenesti večjo količino podatkov z interneta, naj nas obvesti;

- aplikacijo velikokrat zapiramo in ponovno odpiramo, ob ponovnem odprtju naj

aplikacija povrne prejšnje stanje;

- orientacija zaslona naj spremeni pozicijo elementov;

- poraba baterije mora biti minimalna.

Testiranje uporabnosti se mora izvajati na Android napravi in ne na navidezni napravi, saj

nekaterih stvari, kot so geo-lokacija, zajemanje fotografij, ugotavljanje pravilne velikosti

elementov ne moramo testirati na virtualni napravi tako, kot jo lahko na Android napravi.

Testiranje uporabnosti lahko izvaja kdorkoli, priporočljivo je, da ga izvede čimveč različnih

ljudi.

5.8 Testiranje podatkovne baze SQLite s sqlite3

Android Debug Bridge (adb) je orodje, ki teče v ukazni vrstici in omogoča komunikacijo z

napravo. Z njim lahko v ukazni vrstici uporabljamo program sqlite3, s katerim nadzorujemo

podatkovno bazo SQLite. Sqlite3 vsebuje mnogo uporabnih ukazov, kot so:

- .tables – prikaţe tabele, ki imamo kreirane;

- .dump – prikaţe vsebino tabel;

- .schema – prikaţe SQL create stavke, s katerimi smo kreirali podatkovno bazo;

- .import – uvozi podatke v tabelo;

- .backup – izdela varnostne kopije podatkovne baze.


Orodje sqlite3[22] lahko uporabimo za vpisovanje in brisanje testnih podatkov v podatkovno

bazo v tabele. Uporabimo ga lahko tudi za testiranje delovanja posameznih SQL stavkov.

5.9 Orodja za avtomatizacijo testiranja

Z orodji lahko avtomatiziramo skoraj vse teste, običajno pa jih uporabljamo pri testih, ki jih

velikokrat ponavljamo.

Testni primeri avtomatiziranih orodji so vsebovani v testnih paketih, ki so podobni paketom

glavne aplikacije, pisanje testnih primerov pa poteka v programski kodi. Testi enot so običajno

povezani z nadomestnimi objekti. Nadomestne (angl. mock) objekte uporabljamo za izoliranje

odvisnosti enot, za nadzorovanje interakcije ter večkratno moţnost ponavljanja testov[15].

Android testni primeri so osnovani na testnem ogrodju JUnit. JUnit je de facto standard

testiranja enot za Android. Gre za odprtokodno ogrodje namenjeno samodejnemu testiranju

enot.

5.9.1 Orodje Robolectric

Robolectric je ogrodje za izvajanje testov enot, ki preoblikuje .jar datoteko razvojnega okolja

na tak način, da omogoči testiranje aplikacije, ki se izvaja znotraj Java navidezne naprave

(ang. Java Virtual Machine). Testiranje poteka hitreje kot testiranje na virtualni napravi z

Dalvik.

Robolectric omogoča prestrezanje nalaganja Android razredov ter prepisovanje metod.

Metode ponovno definira tako, da vrnejo null (0, false), ali pa posreduje klice metod kopijam

Android objektov z enakim obnašanjem (Slika 5-1). Nudi veliko število kopij metod, ki

pokrivajo velik del aplikacije.


Slika 5-1: Prikaz delovanja mock objektov

Robolectric je v fazi razvoja, zaradi česar se vsakodnevno izboljšuje pokritost razvojnega

okolja. Omogoča testiranje, ki je podobno testiranju po principu črne skrinje[23].

5.9.2 Orodje Robotium

Robotium[24] je testno ogrodje za izdelavo enostavnih, močnih ter robustnih avtomatskih

testov po principu črne skrinje. Razvijalci lahko pišejo funkcije, sistemske in prevzemne testne

scenarije, ki se raztezajo čez več aktivnosti.

Robotium ima popolno podporo za aktivnosti, dialoge, »toast« sporočila, menije ter vsebinske

menije. Prednosti Robotium-a:

- testne primere lahko gradimo z minimalnim poznavanjem aplikacije;

- ogrodje zna avtomatsko delati z več aktivnostmi;

- ni potrebnega veliko časa za pisanje solidnih testov;

- čitljivost testnih programov je veliko boljša v primerjavi s standardnimi testi;

- testni primeri so robustnejši zaradi povezav na komponente grafičnega vmesnika;

- hitro izvajanje testov.

Z razliko od nekaterih drugih orodij, ki ustvarjajo kopije objektov, Robotium uporablja prave

objekte, kar pomeni, da delamo s pravimi podatki.

Pred začetkom pisanja skripte moramo v projekt dodati robotium-solo-2.4.jar kot zunanjo .jar

datoteko v Java Build Path.

Imena testnih funkcij se morajo začeti s test, vrstni red je določen z abecednim vrstnim redom.


5.9.3 Orodje Monkeyrunner

Monkeyrunner[25] je orodje z vmesnikom API za pisanje programov, ki kontrolirajo Android

napravo ali navidezno napravo izven Android kode. Z njim lahko pišemo programe v

programskem jeziku Python, ki se namestijo v aplikacijo ali testni paket, se zaţenejo ter v

aplikacijo pošiljajo pritiske tipk in zajemajo slike zaslona. Primarna funkcija monkeyrunnerja

je testiranje aplikacij in naprav na njihovi funkcijski ravni za izvajanje testov enot.

Monkeyrunner ni povezan z UI/Application Exerciser Monkey orodjem. Za razliko od

monkey monkeyrunner kontrolira napravo in virtualno napravo z delovnega okolja s

pošiljanjem specifičnih komand in dogodkov. Tehnike testiranja z monkeyrunner:

- kontroliranje več naprav: monkeyrunner lahko poganja teste na več napravah ali

virtualnih napravah. Priklopimo lahko vse naprave ali poţenemo vse virtualne naprave

naenkrat ter nato poganjamo teste.

- funkcionalno testiranje: monkeyrunner lahko poganja samodejni test za testiranje

celotne aplikacije. Vhodne podatke zagotovi programer, program rezultate pokaţe v

obliki slik, ki jih zajame z naprave.

- regresijsko testiranje: monkeyrunner lahko testira stabilnost naprave s poganjanjem

aplikacije in primerjavo izhodnih slik zaslona s skupkom slik zaslona, ki prikazujejo

pravilne izhode.

- razvijemo lahko popoln sistem Python modulov in programov za kontroliranje Android

naprav.

5.10 Orodja za profiliranje uporabniškega vmesnika

Uporabniški vmesniki lahko upočasnjujejo aplikacije. Za identificiranje takih teţav v pogledih

(ang. View) uporabimo orodji, ki sta del Android SDK- Hierarchy Viewer in layoutopt.

5.10.1 Optimiziranje pogledov z orodjem layoutopt

Layoutopt[26] je orodje za analiziranje datotek XML, ki definirajo uporabniški vmesnik. Test

poţenemo preko ukazne vrstice. Ukaz za pričetek testa je:


- Layoutopt <xmlfiles>; argument <xmlfiles> je seznam vseh virov datotek XML, ki jih

ţelimo analizirati.

5.10.2 Orodje Hierarchy Viewer

Hierarchy Viewer[26] omogoča iskanje napak in optimizacijo uporabniškega vmesnika.

Aplikacija vizualno prikaţe hierarhijo pogledov ter podroben prikaz le teh. Program poţenemo

preko ukazne vrstice z ukazom hierarchyviewer. Postavljeni moramo biti v mapi /tools, ki se

nahaja v korenski mapi Android SDK. Iz varnostnih razlogov lahko program poganjamo samo

na virtualni napravi.

5.10.3 Orodje Pixel Perfect

Pixel Perfect[26] je orodje za preiskovanje in razvijanje uporabniškega vmesnika. Z njim

lahko preiskujemo lastnosti posameznih točk (ang. pixlov) naše slike. Uporabimo ga lahko

tudi za pomoč pri nastavljanju pozicij elementov uporabniškega vmesnika.

Zaradi varnosti ga lahko poganjamo samo na virtualni napravi. Pixel Perfect poţenemo preko

hierarchyviewerja s klikom na gumb »Inspect Screenshot«.


6 TESTIRANJE APLIKACIJE MYWALLET

Slika 6-1 prikazuje aktivnosti aplikacije.

Slika 6-1: Prikaz aktivnosti aplikacije


6.1 Testne naprave

Testiranje smo opravljali z:

- Android emulator verzije 2.3.3 ter z različnimi nastavitvami

ločljivosti;

- Samsung galaxy S (Slika 6-2)

o Operacijski sistem: Android

o Verzija: 2.3.3

o Velikost zaslona: 4.0 inč

o Ločljivost: 480x800pixlov.

Slika 6-2: Naprava

Samsung galaxy S

6.2 Priprava testnih podatkov

Pred pričetkom testiranja si moramo pripraviti testne podatke.

Pri testiranju uporabimo naslednje tipe testnih podatkov[19]:

- ne vnesemo podatkov. Testni primer izvedemo brez podatkov ali s privzetimi

vrednostmi. Preverjamo, ali se izpišejo ustrezna sporočila o pomanjkljivosti

podatkov.

- pravilen vnos podatkov. Preverjamo, ali aplikacija deluje pravilno in ali se testni

podatki vpišejo v podatkovno bazo oz., ali dobimo pravilen odziv aplikacije.

- napačen vnos podatkov. Preverjamo, ali se ob vnosu napačnih podatkov prekine

izvajanje aplikacije in ali nas opozori na napačno vnesene podatke. Napačne

podatke določimo na podlagi pričakovanih podatkov aplikacije.

- napačna oblika zapisa podatka. Preverjamo, ali aplikacija sprejema podatke v

napačni obliki zapisa ter ali nas ob vnosu takih podatkov obvesti o napaki.

- mejna vrednost podatka. Preverjamo, ali aplikacija sprejema podatke, ki so izven

pričakovanih vrednosti. Preverjamo spodnje in zgornje mejne vrednosti.


6.3 Predloga testnih primerov- scenarijev

Testni primer je skupek pogojev in spremenljivk, s katerimi preizkuševalec določi, ali

aplikacija oz. del aplikacije deluje pravilno. Testni primeri morajo biti napisani za vhodne

podatke, ki so neveljavni in nepričakovani kot tudi za veljavne in pričakovane [17]. Testni

primeri so običajno sestavljeni iz identifikacijske številke testnega primera, opisa, zaporedja

izvajanja ukazov, kategorije, avtorja, pričakovanih in dejanskih rezultatov in podatka, ali je bil

test uspešno opravljen ali ne. Uspešen testni primer je tisti, ki odkrije do sedaj še neodkrito

napako [17].

Za beleţenje testnih primerov- scenarijev uporabljamo naslednjo predlogo (Tabela 1).

Tabela 1: Predloga testnega scenarija

ID Identifikacijska številka ali ime, s katerim identificiramo testni scenarij.

Opis Opis testnega scenarija, kjer razloţimo, kaj testiramo in na kakšen način ter s

kakšnimi testnimi podatki.

Zaporedje

ukazov

Navedemo zaporedje ukazov, ki so potrebni za izvedbo testnega scenarija.

Kategorija Določitev kategorije testa.

Pričakovani

rezultati

Podamo opis pričakovanih rezultatov ob izvedbi testnega scenarija.

Dejanski

rezultati

Opis rezultatov izvedbe testnega scenarija.

Uspešnost Testni scenarij označimo kot uspešen ali neuspešen.


6.4 Testiranje po principu črne skrinje

Testiramo testni scenarij dodajanja računov s pričakovanimi vhodnimi podatki (Slika 6-3).

Slika 6-3: Vnos pričakovanih vrednosti

Tabela 2: Testni scenarij dodajanja računa s pričakovanimi vrednostmi

ID 01

Opis Testiranje aktivnosti računi – klik na dodajanje računa. V aplikacijo dodamo nov račun, ki ga

ţelimo imeti izpisanega na seznamu računov. Vnesli bomo pričakovane vrednosti.

Zaporedje

ukazov

Klik na aktivnost računi – klik na dodaj račun – vnos imena (tomaz), vnos začetnega stanja (50) in

vnos tipa računa (osebni) – pritisk gumba Potrdi.

Kategorija Dodajanje računov.

Pričakovani

rezultati

Na seznam računov se doda račun, ki smo ga pravkar dodali.

Dejanski

rezultati

Račun, ki smo ga dodali, je bil uspešno dodan na seznam računov.

Uspešnost Test je bil uspešno opravljen.

Ostali testni primeri so v prilogi.

6.5 Testiranje po principu bele skrinje

Za testiranje po principu bele skrinje smo si izbrali enoto dodajanjeTransakcij.


Slika 6-4: Graf aplikacije - enota dodajanjeTransakcij

Del skripte:

public void test03DodajTransakcijo1() throws Exception {

solo.clickOnImageButton(1);

solo.assertCurrentActivity("mywallet", "dodajTransakcijo");

solo.pressSpinnerItem(0, 1);

solo.enterText(0,"100");

solo.clickOnButton("Nastavi datum");

solo.setDatePicker(0, 2011, 9, 10);

solo.clickOnButton("Set");

solo.pressSpinnerItem(1, 1);

solo.clickOnButton("Potrdi");

assertTrue(solo.searchText("Dodaj transakcije")); }

}

ID 40

Opis Testiranje dodajanja transakcije s pravilnim vnosom podatkov.


Zaporedje

ukazov

Klik na aktivnost transakcije – izbira računa s spustnega seznama – vnos zneska – klik na gumb

nastavi datum – potrditev datuma – izbira kategorije s spustnega seznama – klik na gumb Potrdi.

Kategorija Dodajanje transakcije.

Pričakovani

rezultati

Pričakujemo, da bomo uspešno dodali transakcijo.

Dejanski

rezultati

Aplikacija nas obvesti o uspešno dodani transakciji.

Uspešnost Test je bil uspešen.

Izračun pokritosti testiranja z orodjem EMMA:

EMMA Coverage Report (generated Wed Sep 21 02:12:52 CDT 2011)

[all classes]

OVERALL COVERAGE SUMMARY

name class, % method, % line, %

all classes 100% (1/1) 71% (5/7) 62% (132/210)

OVERALL STATS SUMMARY

total packages: 1

total executable files: 1

total classes: 1

total methods: 7

total executable lines: 210

COVERAGE BREAKDOWN BY PACKAGE


tomzi.net.src.dodajTransakcijo 100% (1/1) 71% (5/7) 62% (132/210)

[all classes]

EMMA 2.0.4015 (stable) (C) Vladimir Roubtsov

Poročilo prikazuje rezultate pokritosti testa, ki smo ga izvedli na razredu dodajTransakcijo.

Z izvedenim testnim primerom smo dosegli 100% pokritost razredov, saj testiramo samo en

razred in 71% pokritost metod, ter 62% pokritost vrstic.

http://emma.sourceforge.net/

http://sourceforge.net/projects/emma


Izvedenih je bilo 10 odločitvenih stavkov:

Tabela 3: Tabela izvedenih odločitvenih stavkov

Št. Vrstice Pogoj True False

92 if (e != null) cursor e ima

nastavljeno vrednost

cursor e ni nastavljen

93 if (e.moveToFirst()) cursor e najde zapis v

podatkovni bazi

cursor e ne najde zapisa

v podatkovni bazi

104 if (d != null) cursor d ima


cursor d ni nastavljen

105 if (d.moveToFirst()) cursor d najde zapis v

podatkovni bazi

cursor d ne najde zapisa

v podatkovni bazi

142 (c != null ) cursor c ima


cursor c ni nastavljen

143 if (c.moveToFirst()) cursor c najde zapis v

podatkovni bazi

cursor c ne najde zapisa

v podatkovni bazi

162 (c != null ) cursor c ima


cursor c ni nastavljen

163 if (c.moveToFirst()) cursor c najde zapis v

podatkovni bazi

cursor c ne najde zapisa

v podatkovni bazi

224 if(etx1.getText().length() < 1 ||

spin1.getSelectedItem().toString()

== "Izberite račun..." ||

spin2.getSelectedItem().toString()

== "Izberite kategorijo...")

etx1 je manjši od 1 ali

spin1 ima vrednost

»Izberite račun…« ali

spin2 ima vrednost

»Izberite kategorijo…«

etx1 je večji od 1 in

spin1 ni nastavljen na

»Izberite račun…« in

spin2 ni nastavljen na

»Izberite kategorijo…«

227 if(napaka==0) napaka=0, če ni bilo

najdenih napak v

vnosnih poljih.

napaka != 0, če je bila

najdena napaka v

vnosnih poljih.


6.6 Testiranje enot

Test enote testira delovanje enote preverjanja, ali uporabnik vnaša ţe obstoječo kategorijo. Če

bo test označen kot pravilen, pomeni, da enota, ki preverja, ali dodajamo ţe obstoječo

kategorijo, deluje. Izsek skripte testiranje enot:

public void testUnit() throws Exception {


solo.assertCurrentActivity("mywallet", "kategorije1");

solo.clickOnButton("Dodaj kategorijo");

solo.assertCurrentActivity("mywallet", "dodajKategorijo");

solo.enterText(0, "placa");


solo.clickOnButton("Dodaj kategorijo");

solo.assertCurrentActivity("mywallet", "dodajKategorijo");

solo.enterText(0, "placa"); solo.clickOnButton("Potrdi");

assertTrue(solo.searchText("Kategorija s takim imenom ţe obstaja!"));

}

Slika 6-5: Uspešno izveden test

6.7 Regresijsko testiranje

Regresijsko testiranje je potekalo skozi celoten razvoj aplikacije, saj se je velikokrat zgodilo,

da so določene spremembe v aplikaciji povzročile napake na drugih delih aplikacije.

Regresijsko testiranje smo izvajali s pomočjo avtomatiziranega orodja Robotium. Slika 6-6

prikazuje uspešno izveden test s pomočjo orodja Robotium.


Slika 6-6: Uspešno izveden test

Skripta – izsek regresijskih testov:

public void test01NiRacunov() throws Exception {


solo.assertCurrentActivity("mywallet", "racuni1");

assertTrue(solo.searchText("ni računov"));

}

public void test02DodajRacunTomaz() throws Exception {



solo.clickOnButton("Dodaj račun"); solo.assertCurrentActivity("mywallet", "dodajRacun");

solo.enterText(0, "Tomaz");

solo.enterText(1, "2000");

solo.enterText(2, "osebni racun");


assertTrue(solo.searchText("Tomaz"));

}

public void test03DodajRacunTomaz() throws Exception {



solo.clickOnButton("Dodaj račun"); solo.assertCurrentActivity("mywallet", "dodajRacun");

solo.enterText(0, "Tomaz");

solo.enterText(1, "150");

solo.enterText(2, "osebni racun");


assertTrue(solo.searchText("Račun s takim imenom ţe obstaja!"));

}

public void test04BrisiRacun() throws Exception {



solo.clickLongInList(0);

assertTrue(solo.searchText("ni računov")); }


6.8 Integracijsko testiranje

Integracijsko testiranje smo izvedli z namenom testiranja pravilnosti skupnega delovanja

komponente stanje na računu v odvisnosti od dodajanja novih transakcij.

Tabela 4: Testni scenarij testa integracije

ID 70

Opis Testiranje dodajanja transakcije ter posodabljanje stanja na računu ob vnosu pravilnih podatkov.

Zaporedje

ukazov

Klik na aktivnost transakcije – izbira računa s spustnega seznama – vnos negativnega zneska – klik

na gumb nastavi datum – potrditev datuma – izbira kategorije s spustnega seznama – klik na gumb

Potrdi - klik na ikono hišice – klik na aktivnost računi.

Kategorija Dodajanje transakcije in posodobitev stanja računa.

Pričakovani

rezultati

Pričakujemo, da bomo dodali transakcijo z negativnim zneskom ter, da se na izbranem računu

spremeni stanje na računu za tolikšno vrednost, kot je bil znesek transakcije.

Dejanski

rezultati

Stanje na izbranem računu se je spremenilo glede na vnesen znesek transakcije.


6.9 Testiranje SQL stavkov z adb shell – sqlite3

Povezava na podatkovno bazo SQLite (Slika 6-7).

Slika 6-7: Povezava na podatkovno bazo SQLite

Vsak SQL stavek, ki smo ga v aplikaciji uporabili smo predhodno testirali, saj smo na tak

način lahko preverili, če vključujemo pravilne poizvedbe (Slika 6-8). S testiranjem SQL

stavkov smo se prepričali, ali poizvedbe vračajo podatke.


Slika 6-8: Testiranje SQL stavkov

Aplikacija pravilno prikaţe tudi decimalna števila katera lahko vnašamo preko SQL poizvedb

(Slika 6-9). Uporabljena SQL poizvedba za dodajanje novega zapisa:

insert into Transakcije values ('47', '2011-09-14', '155.99', '195', '78');

Slika 6-9: Uspešno dodan decimalni zapis s sqlite3

6.10 Testiranje uporabnosti

Testiranje uporabnosti smo izvajali na izbrani napravi Android z upoštevanjem nasvetov za

testiranje mobilnih aplikacij (glej poglavje 5.7). Rezultati testiranja so bili sledeči:

- gumbi so pravilne velikosti in omogočajo enostavno uporabo tudi, če imamo debelejše

prste;

- ikone so naravne in dobro predstavljajo posamezne elemente;

- besedila so kratka in jasna;

- vnos besedila v vnosno polje se ne začne z veliko črko;

- velikost besedil je pravilna, saj so vsa besedila dobro vidna;

- potrditvenih sporočil je malo, imamo jih le ob dodajanju transakcij;

- aplikacija povrne pravilno stanje tudi ob večkratnem zapiranju in odpiranju aplikacije;

- poraba baterije je minimalna, saj aplikacija ni odvisna od zunanjih virov kot so

bluetooth, uporaba internetne povezave in prenos podatkov, uporaba GPS, uporaba

brezţičnega omreţja. Običajno so našteti zunanji viri povzročitelji večje porabe

baterije.


- v primeru, da uporabnik pritisne gumb, ki ga ni ţelel, lahko akcijo razveljavi s klikom

na gumb nazaj;

- aplikacija uporablja celoten zaslon;

- skrivanje tipkovnice doseţemo s pritiskom na gumb nazaj;

Spremembe orientacije

Android zazna spremembo orientacije, ko uporabnik zasuka napravo ali pošlje določeno

kombinacijo tipk v navidezno napravo (ctrl+f12).

Moţni sta dve postaviti zaslona:

- leţeče (landscape) – horizontala je daljša od vertikale;

- pokončno (portrait) – vertikala je daljša od horizontale.

Tabela 5: Testni primer spremembe orientacije

ID 50

Opis Testiranje rotacije zaslona.

Zaporedje

ukazov

Zagon aplikacije – zasukamo napravo.

Kategorija Orientacija zaslona.

Pričakovani

rezultati

Pričakujemo, da ob spremembi orientacije aplikacija postavi elemente zaslona v pravilno lego.

Dejanski

rezultati

Ob rotaciji zaslona aplikacija ne zamenja postavitve elementov.


Slika 6-10: Pokončna postavitev zaslona

Slika 6-11: Leţeča postavitev zaslona

Uspešnost Test ni bil uspešen.

6.11 Testiranje enot z orodji za avtomatizacijo testiranja

6.11.1 Testiranje aktivnosti s TestCase2 razredom

Rezultati se pojavijo v okolju Eclipse v JUnit View okencu. Kot je prikazano na Slika 6-12,

JUnit View prikaţe rezultate testiranja v dveh delih. V zgornjem delu izpiše povzetek testa, v

spodnjem delu pa najdemo morebitne napake, na katere smo naleteli. Z naslednjo testno

skripto smo izvedli test, s katerim smo preverjali vsebinsko ustreznost dveh spustnih

seznamov ter dveh vnosnih polj. Test je neuspešen (Slika 6-12), ker znesek ni enak iskani

vrednosti. Neuspešnost testa je prikazana z rdečim trakom v zgodnjem desnem delu okenca.

Testna skripta:

package tomzi.net.test;

import tomzi.net.dodajTransakcijo;

import android.test.ActivityInstrumentationTestCase2;

import android.widget.Button;

import android.widget.EditText;

import android.widget.Spinner; import android.widget.TextView;

public class DodajTransakcijoTest extends ActivityInstrumentationTestCase2<dodajTransakcijo> {


private dodajTransakcijo mActivity;

private TextView mView;

private Spinner rSpin;

private Spinner kSpin;

private EditText datum;

private EditText znesek;

private Button potrdi;

public DodajTransakcijoTest() {

super("tomzi.net", dodajTransakcijo.class);

}

@Override protected void setUp() throws Exception {

super.setUp();

mActivity = this.getActivity();

mView = (TextView) mActivity.findViewById(tomzi.net.R.id.textViewTransakcije);

rSpin = (Spinner) mActivity.findViewById(tomzi.net.R.id.spinnerracuni);

kSpin = (Spinner) mActivity.findViewById(tomzi.net.R.id.spinnerkategorije);

datum = (EditText) mActivity.findViewById(tomzi.net.R.id.editTextdatum);

znesek = (EditText) mActivity.findViewById(tomzi.net.R.id.editTextznesek); }

public void testText() {

assertEquals("Dodaj transakcije",(String)mView.getText()); }

public void testSpinnerRacuni() { assertEquals("tomaz", rSpin.getItemAtPosition(1).toString()); }

public void testSpinnerKategorije() {

assertEquals("placa", kSpin.getItemAtPosition(1).toString()); }

public void testDatum() {

assertEquals("28.8.2011", datum.getText().toString()); }

public void testznesek() {

assertEquals("150", znesek.getText().toString()); }

}

Slika 6-12: Primer neuspešnega testa

6.11.2 Orodje Robolectric

Robolectric skripta s katero preverimo, ali je seznam računov prazen:

@RunWith(RobolectricTestRunner.class)

public class MyWalletTest {

private Activity activity;

private ImageButton racuni; private TextView ni_racunov;

@Before

public void setUp() throws Exception {

activity = new MyActivity();

activity.onCreate(null);


racuni = (ImageButton) activity.findViewById(R.id.imageButton1);

ni_racunov = (TextView) activity.findViewById(R.id.empty);

}

@Test

public void test() throws Exception {

racuni.performClick();

String ni_racunov = ni_racunov.getText().toString();

assertThat(resultsText, equalTo(“ni računov”);

}

}

Test je neuspešen v primeru, da je seznam napolnjen z vsaj enim računom (Slika 6-13) .

Slika 6-13: Neuspešen test robolectric

6.11.3 Orodje Robotium

S testnim ogrodjem Robotium smo izvedli popoln test aplikacije po principu črne skrinje.

Izvedli smo 34 testnih primerov, ki se nahajajo v prilogi v testnem projektu

myWalletRoboTest.

Poročilo prikazuje doseţeno pokritost izvorne kode, ki smo jo dosegli z izvedbo testnega

projekta myWalletRoboTest.

EMMA Coverage Report (generated Wed Sep 21 02:01:32 CDT 2011)

[all classes]

OVERALL COVERAGE SUMMARY


all classes 95% (19/20) 98% (112/114) 99% (1729/1736)

OVERALL STATS SUMMARY

total packages: 1

total executable files: 1

total classes: 20

total methods: 114

total executable lines: 1736

COVERAGE BREAKDOWN BY PACKAGE


tomzi.net.src 95% (19/20) 98% (112/114) 99% (1729/1736)

[all classes]

EMMA 2.0.4015 (stable) (C) Vladimir Roubtsov

http://emma.sourceforge.net/

http://sourceforge.net/projects/emma


S testi smo dosegli 95% pokritost razredov, 98% pokritost metod in 99% pokritost vrstic

celotne aplikacije.

6.11.4 Orodje UI/Application Exerciser Monkey

Monkey[20] lahko poganjamo preko ukazne vrstice ali preko skript. Program teče v našem

okolju, zato ga moramo pognati preko ukazne vrstice tako, da pri vsakem ukazu pripišemo adb

shell ali pa ukaze vnašamo direktno v ukazno vrstico.

Primer zagona programa z zahtevo po 1000 naključnih pseudo dogodkih (Slika 6-14):

$ adb shell monkey -p tomzi.net -v 1000

Slika 6-14: Zagon orodja monkey z zahtevo po 1000 pseudo dogodkih

Zraven končnega poročila (Slika 6-15) pa lahko sproti spremljamo tudi potek samega

testiranja, s katerega lahko razberemo zaporedje izvajanja ukazov (Slika 6-16).

Slika 6-15: Poročilo orodja UI Exerciser Monkey


Slika 6-16: Potek monkey testa

6.11.5 Orodje Monkeyrunner

Monkeyrunner skripta[25], ki smo jo uporabili za testiranje.

# Vključimo monkeyrunner module, ki jih uproabljamo v programu from com.android.monkeyrunner import MonkeyRunner, MonkeyDevice # Poveţemo se z napravo, katera vrne MonkeyDevice objekt device = MonkeyRunner.waitForConnection() # Namestimo Android paket. device.installPackage(myWallet/bin/ myWallet.apk') # v sprejemljivko shranimo ime paketa package = tomzi.net' # v sprejemljivko shranimo ime Aktivnosti v paketu activity = 'tomzi.net.MyWalletActivity' # nastavimo ime komponente, ki jo zaţenemo runComponent = package + '/' + activity # Zaţene komponento device.startActivity(component=runComponent) # Pritisne gumb Meni device.press(„DRAP_DOWN‟,'DOWN_AND_UP')

device.press(„DRAP_CENTER,'DOWN_AND_UP') # Zajema sliko zaslona result = device.takeSnapshot() # Shrani sliko zaslona v datoteko result.writeToFile('myWallet/shot1.png','png')

Rezultat testa je zaslonska slika (Slika 6-17) aplikacije.


Slika 6-17: Zaslonska slika narejena z orodjem monkeyrunner

6.12 Profiliranje uporabniškega vmesnika

6.12.1 Optimiziranje pogledov z orodjem layoutopt

Orodje analizira datoteke XML, njihove definicije in hierarhijo, na koncu pa dobimo izpis

vseh analiziranih datotek in naslednje informacije (Slika 6-18):

- ime analizirane datoteke;

- številke vrstic, kjer se je pojavil problem;

- opis teţave.

Slika 6-18: Poročilo orodja layoutopt

Ugotovljena napaka je bila v datoteki racuni_pregled.xml, kjer smo definirali odvečen

LinearLayout element.

6.12.2 Orodje Hierarchy Viewer

Ko ob zagonu programa le ta prepozna naše naprave in trenutne aktivnosti, izberemo aktivnost

ter kliknemo na gumb “Load View Hierarchy”.


Orodje hierarchyview omogoča:

- prikaz drevesne strukture – vsako vozlišče predstavlja določen pogled (Slika 6-21).

Spreminjamo lahko ozadje pogleda ter pridobimo informacije o mejah med elementi in

vsebino.

- prikaz postavitve elementov – če kliknemo na vozlišče, se bo obarval prostor, ki ga

zavzema, na rdeče (Slika 6-22).

- prikaz lastnosti posameznih elementov- desno zgoraj (Slika 6-22).

- zajemanje informacij iz hierarchviewer v sliko. Drevesno strukturo lahko shranimo v

.png datoteko (Slika 6-19) ali v photoshop datoteko, kjer je vsak pogled lastna plast.

- prikazovanje časov, ki so potrebni za izvedbo določenega pogleda- levo(Slika 6-22).

Časi so izračunani za merjenje, risanje ter prikazovanje elementov. Prikazani so s

pikami na dnu vozlišča (Slika 6-20). Rdeča pikica označuje, da je potrebno veliko časa

za določeno akcijo. Počasnejša izvedba še nujno ne pomeni, da nekaj ni v redu.

Določeni elementi so zgrajeni na način, za katerega je potrebno več časa za prikaz kot

za ostale (prikaz seznama z veliko elementi potrebuje več časa kot prikaz gumba).

Slika 6-19: Drevesna struktura, ki smo jo izvozili iz orodja


Slika 6-20: Vozlišče

Slika 6-21: Izgled vozlišča v aplikaciji

Slika 6-22: Prikaz postavitve in lastnosti elementov ter časi izvedbe

6.12.3 Orodje Pixel Perfect

Pixel perfect okence (Slika 6-23):

- desna stran prikazuje, kako pogled izgleda v virtualni napravi – naredi zaslonsko sliko.

- leva stran prikazuje drevesno strukturo elementov na tem pogledu. Ko kliknemo na

element, se na desni strani obrobi z rdečo barvo.

- srednji del prikazuje pribliţan del pogleda, kjer dobimo informacije o vsakem pikslu

(barva piksla, pozicija).

- omogoča shranjevanje zaslonske slike aktivnosti.


Slika 6-23: Pixel perfect okno

- omogoča prikazovanje slike preko trenute zaslonske slike – overlay. S tem načinom si

lahko pomagamo pri načrtovanju grafičnega vmesnika. Prekrivani sliki lahko

nastavljamo transparentnost. V našem primeru je označena s svetlo rdečo barvo (Slika

6-24).

Slika 6-24: Prikaz prekrivanja zaslonske slike z drugo sliko


7 REZULTATI TESTIRANJA

7.1 Funkcionalno testiranje

S funkcionalnim testiranjem smo ugotovili naslednje napake oz. pomanjkljivosti:

- aplikacija ne omogoča vnašanja decimalnih števil;

- aplikacija ne dovoli ročnega vnosa datuma.

Drugih napak nismo odkrili, kljub temu, da smo izvedli test aplikacije s skoraj popolno

pokritostjo testiranja (95% pokritost razredov, 98% pokritost metod in 99% pokritost vrstic

aplikacije).

Vnos napačnih podatkov v aplikacijo ni mogoč, saj Android OS sprejema samo podatke kateri

so pravilni za določeno vnosno polje. V vnosnih poljih, kjer vnašamo zneske sprejema samo

številčne vrednosti ter predznak, ki mora biti na prvem mestu. V poljih z besedili aplikacija

prepušča uporabniku prosto izbiro vnosa katerega koli podatka, saj gre za niz znakov, kjer je

dolţina omejena na 20 znakov.

7.2 Nefunkcionalno testiranje

Rezultati nefunkcionalnega testiranja so pokazali, da:

- aplikacija ne podpira rotacije zaslona. Zaslon je vedno postavljen v vertikalno

postavitev;

- se vnos besedila v vnosna polja ne začne z veliko črko;

- je uporabniški vmesnik zgrajen v skladu z navodili za gradnjo dobrega uporabniškega

vmesnika za mobilne naprave;

- se aplikacija tudi ob večji obremenitvi ne sesuje.


Pri profiliranju uporabniškega vmesnika smo ugotovili pomanjkljivost, ki upočasnjuje

aktivnost pregled računov. Definirali smo namreč odvečen element Linear Layout.


8 SKLEP

V sklopu diplomske naloge smo razvili Android aplikacijo myWallet, na kateri smo izvajali

različne testne metode. Testiranje aplikacij Android bi lahko opravili tudi nad katero drugo

aplikacijo, za katero ni nujno, da bi bila naša, vendar smo se odločili za razvoj lastne

aplikacije z ţeljo učenja razvoja Android aplikacij.

V diplomskem delu smo poskušali predstaviti pomembne dele aplikacije ter prikazati nekaj

delov izvorne kode, ki poskrbijo za delovanje aplikacije. Ob razvoju aplikacije smo se

domislili še nekaj moţnih izboljšav, kot so omogočanje urejanja zapisov, izris grafa stanja na

računu, moţnost lastnega sortiranja računov in transakcij (sedaj so izpisi sortirani po datumu),

izbira valut, menjava jezikov in še kaj.

Opisali smo tudi večino metod, s katerimi lahko testiramo programsko opremo na platformi

Android. Posebej smo izpostavili orodja, ki poskrbijo za avtomatizacijo testov, primerna za

testiranje in profiliranje aplikacij Android. Precej pozornosti smo posvetili orodju Robotium, s

katerim smo izvajali večino funkcionalnega testiranja po principu črne skrinje. S pomočjo

orodja Robotium smo merili tudi čas, potreben za izvedbo celotnega testa, s čimer smo

ugotovili, da je testiranje z navidezno napravo počasno in je priporočljivo uporabljati napravo

Android. Z nefunkcionalnim testiranjem smo ugotovili, da aplikacija deluje v skladu s

pričakovanji tudi ob večji obremenitvi ter, da je uporabniški vmesnik dobro zgrajen.


9 VIRI, LITERATURA

[1] Kaj je Android?,

http://slo-android.si/prispevki/kaj-je-android.html, zadnji obisk avgust 2011

[2] Google's Android becomes the world's leading smart phone platform,

http://www.canalys.com/newsroom/google%E2%80%99s-android-becomes-

world%E2%80%99s-leading-smart-phone-platform, zadnji obisk avgust 2011

[3] Android Now Top-Selling Smartphone Operating System,

http://mashable.com/2010/08/04/android-top-selling-smartphone-os/, zadnji obisk avgust 2011

[4] What is Android?,

http://developer.android.com/guide/basics/what-is-android.html, zadnji obisk avgust 2011

[5] Android Official Website,

http://www.android.com/about/, zadnji obisk september 2011

[6] Google buys android for its mobile arsenal,

http://www.businessweek.com/technology/content/aug2005/tc20050817_0949_tc024.htm,

zadnji obisk avgust 2011

[7] Open Handset Alliance,

http://en.wikipedia.org/wiki/Open_Handset_Alliance, zadnji obisk september 2011

[8] Now in Production: The First Google Android Car,

http://mashable.com/2010/03/19/android-roewe-350/, zadnji obisk september: 2011


[9] Android Market update: support for priced applications,

http://android-developers.blogspot.com/2009/02/android-market-update-support-for.html,

zadnji obisk september 2011

[10] More Countries, More sellers, More buyers,

http://android-developers.blogspot.com/2010/09/more-countries-more-sellers-more-

buyers.html, zadnji obisk avgust 2011

[11] Android Market,

http://en.wikipedia.org/wiki/Android_Market, zadnji obisk avgust 2011

[12] iOS Developer Program,

http://developer.apple.com/programs/ios/, zadnji obisk avgust 2011

[13] Android Market vs iphone App Store,

http://www.brighthub.com/mobile/google-android/articles/74976.aspx, zadnji obisk avgust

2011

[14] Hello, Views | Android developers,

http://developer.android.com/resources/tutorials/views/index.html, zadnji obisk avgust 2011

[15] Diego Torres Milano, Android Application Testing Guide, Packt Publishing, 2011

[16] Date Picker | Android developer,

http://developer.android.com/resources/tutorials/views/hello-datepicker.html, zadnji obisk

avgust 2011

[17] G. J. Myers, The art of software testing Second edition, John Wiley & Sons, 2004

[18] Testing Best Practice,

http://www.chillarege.com/authwork/TestingBestPractice.pdf, zadnji obisk september 2011


[19] Test data preparation,

http://www.geekinterview.com/talk/8965-test-data-preparation.html, zadnji obisk september

2011

[20] UI/Application Exerciser Monkey | Android developer,

http://developer.android.com/guide/developing/tools/monkey.html, zadnji obisk avgust 2011

[21] Tips on Android Usability Testing,

http://www.mobileapptesting.com/tips-on-android-usability-testing/2011/03/, zadnji obisk

september 2011

[22] Android Debug Bridge | Developers Android,

http://developer.android.com/guide/developing/tools/adb.html#sqlite, zadnji obisk september

2011

[23] Robolectric,

http://pivotal.github.com/robolectric/, zadnji obisk september 2011

[24] Robotium,

http://code.google.com/p/robotium/, zadnji obisk september 2011

[25] Monkeyrunner | Android developer,

http://developer.android.com/guide/developing/tools/monkeyrunner_concepts.html, zadnji

obisk avgust 2011

[26] Debugging and Profiling User Interface | Android developer,

http://developer.android.com/guide/developing/debugging/debugging-ui.html, zadnji obisk

avgust 2011


10 PRILOGE

10.1 Kazalo slik

Slika 2-1: Prikaz arhitekture platforme Android [4] ................................................................. 4

Slika 2-2: Statusna vrstica po namestitvi ADT vtičnika in Android SDK ................................. 9

Slika 3-1: Interakcija uporabnik-mobilni telefon ................................................................... 10

Slika 3-2: Prikaz ureditve elementov ..................................................................................... 11

Slika 3-3: Pozdravno okence ................................................................................................. 12

Slika 3-4: Zaslon računi ........................................................................................................ 13

Slika 3-5: Prazen zaslon kategorij ......................................................................................... 13

Slika 3-6: Napaka pri dodajanju transakcij ............................................................................ 14

Slika 3-7: Izbira datuma z razredom datepicker ..................................................................... 14

Slika 3-8: Izpis napake pri dodajanju računa ......................................................................... 14

Slika 3-9: Izpis napake pri dodajanju kategorij ...................................................................... 14

Slika 3-10: Zaslon poročila ................................................................................................... 15

Slika 3-11: Izpis transakcij .................................................................................................... 15

Slika 4-1: Program predstavljen kot graf ............................................................................... 18

Slika 5-1: Prikaz delovanja mock objektov ............................................................................ 26

Slika 6-1: Prikaz aktivnosti aplikacije ................................................................................... 29

Slika 6-2: Naprava Samsung galaxy S ................................................................................... 30

Slika 6-3: Vnos pričakovanih vrednosti ................................................................................. 32

Slika 6-4: Graf aplikacije - enota dodajanjeTransakcij ........................................................... 33

Slika 6-5: Uspešno izveden test ............................................................................................. 36

Slika 6-6: Uspešno izveden test ............................................................................................. 37

Slika 6-7: Povezava na podatkovno bazo SQLite................................................................... 38


Slika 6-8: Testiranje SQL stavkov ......................................................................................... 39

Slika 6-9: Uspešno dodan decimalni zapis s sqlite3 ............................................................... 39

Slika 6-10: Pokončna postavitev zaslona ............................................................................... 41

Slika 6-11: Leţeča postavitev zaslona ................................................................................... 41

Slika 6-12: Primer neuspešnega testa .................................................................................... 42

Slika 6-13: Neuspešen test robolectric ................................................................................... 43

Slika 6-14: Zagon orodja monkey z zahtevo po 1000 pseudo dogodkih ................................. 44

Slika 6-15: Poročilo orodja UI Exerciser Monkey ................................................................. 44

Slika 6-16: Potek monkey testa ............................................................................................. 45

Slika 6-17: Zaslonska slika narejena z orodjem monkeyrunner .............................................. 46

Slika 6-18: Poročilo orodja layoutopt .................................................................................... 46

Slika 6-19: Drevesna struktura, ki smo jo izvozili iz orodja ................................................... 47

Slika 6-20: Vozlišče .............................................................................................................. 48

Slika 6-21: Izgled vozlišča v aplikaciji .................................................................................. 48

Slika 6-22: Prikaz postavitve in lastnosti elementov ter časi izvedbe ..................................... 48

Slika 6-23: Pixel perfect okno ............................................................................................... 49

Slika 6-24: Prikaz prekrivanja zaslonske slike z drugo sliko .................................................. 49

10.2 Kazalo tabel

Tabela 1: Predloga testnega scenarija .................................................................................... 31

Tabela 2: Testni scenarij dodajanja računa s pričakovanimi vrednostmi ................................ 32

Tabela 3: Tabela izvedenih odločitvenih stavkov .................................................................. 35

Tabela 4: Testni scenarij testa integracije .............................................................................. 38

Tabela 5: Testni primer spremembe orientacije ..................................................................... 40

Tabela 6: Testni scenarij dodajanja računov .......................................................................... 59

Tabela 7: Testni scenarij dodajanje računov .......................................................................... 60

Tabela 8: Testni primer brisanje računov ............................................................................... 60

Tabela 9: Testni scenarij dodajanje računov .......................................................................... 61

Tabela 10: Testni scenarij dodajanje računov ........................................................................ 61


Tabela 11: Testni primer pregleda računov ............................................................................ 62

Tabela 12: Testni scenarij dodajanje kategorij ....................................................................... 62

Tabela 13: Testni scenarij dodajanja kategorij ....................................................................... 62


Tabela 15: Testni primer brisanja kategorij ........................................................................... 63


Tabela 17: Testni scenarij pregleda kategorij ......................................................................... 64

Tabela 18: Testni scenarij dodajanje transakcij ...................................................................... 65


Tabela 20: Testni scenarij dodajanje računov ........................................................................ 66


Tabela 22: Testni scenarij izpisa transakcij ............................................................................ 67













Tabela 35: Testni scenarij dodajanja transakcij ...................................................................... 73


10.3 Priloge na CD

- Aplikacija myWallet

- Testni projekt myWalletRobotest

- Testni projekt myWalletTest

- Testni projekt myWalletWhiteBox

- Testni projekt Regression

- Testni projekt myWalletUnitTest

- Emma poročilo pokritosti testiranja (myWalletRoboTest-coverage.html)

- Emma poročilo pokritosti testiranja (myWalletWhiteBoxTest-coverage.html)

10.4 Ostali testni primeri in scenariji

Testni primeri za testiranje po principu črne skrinje

Tabela 6: Testni scenarij dodajanja računov

ID 02

Opis Testiranje aktivnosti računi – dodajanje računa. V aplikacijo poskušamo dodati račun s posebnimi

znaki in dolgimi imeni ter dolgim negativnim stanjem, s čimer bomo testirali zgornjo mejo

sprejemljive dolţine znakov.

Zaporedje

ukazov

Klik na aktivnost računi – klik na dodaj račun – vnos imena

(»o9/%@{jdsa/()")?=?"!+**//;:00000sda«), vnos začetnega stanja (-45685295715436500078),

vnos tipa računa (»o9/%@{jdsa/()")?=?"!+**//;:00000sda«) - pritisk gumba Potrdi.


Pričakovani

rezultati

Dodali bomo račun z negativnim stanjem, vendar bo aplikacija omejila dolţino vnosa imen.

Dejanski

rezultati

Aplikacija omeji vnos imena in tipa računa na 20 znakov in sprejme negativno začetno stanje,

vendar ga zapiše na krajši način. Račun je prikazan na seznamu računov. Vnos napačnih podatkov

ni mogoč, saj aplikacija omogoča samo vnos pravilnih podatkov tako, da pri določenem polju

prikaţe ustrezno tipkovnico z znaki, ki so primerni za določeno polje.



Tabela 7: Testni scenarij dodajanje računov

ID 03

Opis Testiranje aktivnosti računi – klik na dodajanje računa. V aplikacijo poskušamo dodati račun brez

vhodnih podatkov. Vnosna polja bodo privzete vrednosti.

Zaporedje

ukazov

Klik na aktivnost računi – dodaj račun – pritisk gumba Potrdi.


Pričakovani

rezultati

Aplikacija nas bo opozorila na napačen vnos podatkov.

Dejanski

rezultati

Privzete vrednosti vnosnih polj so prazne vrednosti, zato nas aplikacija opozori z izpisom napake

»Niste izpolnili vseh polj!«.


Tabela 8: Testni primer brisanje računov

ID 04

Opis Testiranje aktivnosti računi – brisanje računa. V aplikacijo dodamo račun s pravilnimi podatki, ki

ga poskušamo izbrisati iz seznama računov z dolgim pritiskom na račun.

Zaporedje

ukazov

Klik na aktivnost računi – klik na dodaj račun – vnos imena (»Tomaz«), začetnega stanja (50) in

tipa računa (»osebni racun«) – pritisk gumba Potrdi – dolgi pritisk na prej vnesen račun – ponoven

zagon aplikacije.

Kategorija Brisanje računov.

Pričakovani

rezultati

Račun, ki ga poskušamo izbrisati iz seznama bo izginil in se ob ponovnem zagonu aplikacije ne bo

več pojavil.

Dejanski

rezultati

Ob dolgem pritisku na račun se račun izbriše in se ob ponovnem zagonu aplikacije več ne pojavi.




ID 05

Opis Testiranje aktivnosti računi – brisanje vnosnih polj. V aplikaciji bomo izpolnili vnosna polja,

katera nato izpraznimo.

Zaporedje

ukazov


tipa računa (»osebni racun«) – pritisk gumba Izbriši.


Pričakovani

rezultati

Vnosna polja se bodo izbrisala.

Dejanski

rezultati

Vnosna polja se izbrišejo oz. nastavijo na privzete vrednosti.



ID 06

Opis Testiranje aktivnosti računi – dodajanje računov. V aplikaciji bomo dodali račun z enakim imenom

kot ţe obstaja in različnim tipom računa.

Zaporedje

ukazov


tipa računa (»osebni racun«) – pritisk gumba Potrdi – klik gumba dodaj račun – vnos imena

(»Tomaz«), vnos začetnega stanja (5000), vnos tipa računa (»varcevalni racun«) – pritisk gumba

Potrdi.


Pričakovani

rezultati

Aplikacija bo dodala račun na seznam računov.

Dejanski

rezultati

Aplikacija doda račun na seznam računov.



Tabela 11: Testni primer pregleda računov

ID 07

Opis Testiranje aktivnosti računi – pregled računov. Ţelimo pregledati seznam računov brez

predhodnega dodajanja računa.

Zaporedje

ukazov

Klik na aktivnost računi.

Kategorija Pregled računov.

Pričakovani

rezultati

Aplikacija bo prikazala prazen seznam računov.

Dejanski

rezultati

Aplikacija prikaţe besedilo »ni računov«.


Tabela 12: Testni scenarij dodajanje kategorij

ID 08

Opis Testiranje aktivnosti kategorije – dodajanje kategorij. V aplikacijo dodamo kategorijo, ki jo ţelimo

imeti izpisano na seznamu kategorij. Vnesli bomo pričakovane vrednosti.

Zaporedje

ukazov

Klik na aktivnost kategorije – dodaj kategorijo – vnos imena (»stipendija«) – pritisk gumba Potrdi.

Kategorija Dodajanje kategorij.

Pričakovani

rezultati

Na seznamu kategorij se bo prikazala kategorija, ki smo jo pravkar dodali.

Dejanski

rezultati

Kategorija je bila uspešno dodana na seznam kategorij.


Tabela 13: Testni scenarij dodajanja kategorij

ID 09


Opis Testiranje aktivnosti kategorije – dodajanje kategorij. V aplikacijo poskušamo dodati kategorijo s

posebnimi znaki v imenu in dolgim imenom, s čimer bomo testirali zgornjo mejo sprejemljive

dolţine znakov.

Zaporedje

ukazov

Klik na aktivnost kategorije – klik na dodaj kategorijo – vnos imena

(»o9/%@{jdsa/()")?=?"!+**//;:00000sda«) - pritisk gumba Potrdi.


Pričakovani

rezultati

Dodali bomo kategorijo, vendar bo aplikacija omejila dolţino imena.

Dejanski

rezultati

Aplikacija omeji vnos imena na 20 znakov. Kategorija je prikazana na seznamu kategorij. Vnos

napačnih podatkov ni mogoč, saj aplikacija omogoča samo vnos pravilnih podatkov tako, da pri

določenem polju prikaţe ustrezno tipkovnico z znaki, ki so primerni za to polje.



ID 10

Opis Testiranje aktivnosti kategorije – dodajanje kategorij. V aplikacijo poskušamo dodati kategorijo

brez vhodnih podatkov. Vnosno polje bo vsebovalo privzeto vrednost.

Zaporedje

ukazov

Klik na aktivnost kategorije – klik na dodaj kategorijo –pritisk gumba Potrdi.


Pričakovani

rezultati

Aplikacija nas bo opozorila na napačen vnos podatkov.

Dejanski

rezultati

Privzete vrednosti vnosnih polj so prazne vrednosti, zato nas aplikacija opozori z izpisom napake

»Niste izpolnili vseh polj!«.


Tabela 15: Testni primer brisanja kategorij

ID 11


Opis Testiranje aktivnosti kategorije – brisanje kategorij. V aplikacijo dodamo kategorijo s pravilnimi

podatki, ki jo poskušamo izbrisati iz seznama kategorij z dolgim pritiskom na njo.

Zaporedje

ukazov

Klik na aktivnost kategorije – klik na dodaj kategorijo – vnos imen (»stipendija«) – pritisk gumba

Potrdi – dolgi pritisk na vneseno kategorijo – ponoven zagon aplikacije.

Kategorija Brisanje kategorij.

Pričakovani

rezultati

Kategorija, ki jo poskušamo izbrisati iz seznama bo izginila in se ob ponovnem zagonu aplikacije

ne bo več pojavila.

Dejanski

rezultati

Ob dolgem pritisku na kategorijo se kategorija izbriše in se ob ponovnem zagonu aplikacije več ne

pojavi.



ID 12

Opis Testiranje aktivnosti kategorije – brisanje vnosnih polj. V aplikaciji bomo izpolnili vnosna polja, ki

jih nato izpraznimo.

Zaporedje

ukazov

Klik na aktivnost kategorije – klik na dodaj kategorijo – vnos imena (»stipendija«) – pritisk gumba

Izbriši.


Pričakovani

rezultati

Vnosna polja se bodo izbrisala in nastavila na privzete vrednosti.

Dejanski

rezultati

Vnosna polja se izbrišejo oz. nastavijo na privzete vrednosti.


Tabela 17: Testni scenarij pregleda kategorij

ID 13

Opis Testiranje aktivnosti kategorije – pregled kategorij. Ţelimo pregledati seznam kategorij brez

predhodnega dodajanja kategorij.


Zaporedje

ukazov

Klik na aktivnost kategorije.

Kategorija Pregled kategorij.

Pričakovani

rezultati

Aplikacija bo prikazala prazen seznam kategorij.

Dejanski

rezultati

Aplikacija prikaţe besedilo »ni kategorij«.


Tabela 18: Testni scenarij dodajanje transakcij

ID 14

Opis Testiranje aktivnosti transakcije – dodajanje transakcije. V aplikacijo poskušamo dodati

transakcijo brez vhodnih podatkov. Vnosna polja bodo privzete vrednosti.

Zaporedje

ukazov

Klik na aktivnost transakcije - klik na gumb Potrdi.


Pričakovani

rezultati

Aplikacija nas bo obvestila o nepravilno izpolnjenih poljih.

Dejanski

rezultati

Aplikacija izpiše napako »Niste izpolnili vseh polj!«.



ID 15


transakcijo z negativnim dolgim številom.

Zaporedje

ukazov


vnos tipa računa (osebni) – pritisk gumba Potrdi - klik na aktivnost kategorije – dodaj kategorijo –

vnos imena (»stipendija«) – pritisk gumba Potrdi - klik na aktivnost transakcije – izbira računa


»tomaz« s spustnega seznama – vnos negativnega zneska dolgega 20 znakov (-

25478965471000035877) – klik na gumb nastavi datum – potrditev datuma - izbira kategorije

»stipendija« s spustnega seznama - klik gumb Potrdi.


Pričakovani

rezultati

Aplikacija bo dodala transakcijo in nas o tem obvestila.

Dejanski

rezultati

Aplikacija nas obvesti o dodani transakciji.



ID 16


transakcijo z decimalnim številom.

Zaporedje

ukazov




»tomaz« s spustnega seznama – vnos decimalnega zneska »50.5« – klik na gumb nastavi datum –

potrditev datuma - izbira kategorije »stipendija« s spustnega seznama - klik na gumb Potrdi.


Pričakovani

rezultati

Aplikacija bo dodala transakcijo in nas o tem obvestila.

Dejanski

rezultati

Aplikacija ne omogoča vnosa decimalnega števila.



ID 17

Opis Testiranje aktivnosti transakcije – dodajanje transakcije. Pri dodajanju transakcije poskušamo


ročno nastaviti datum.

Zaporedje

ukazov




»tomaz« s spustnega seznama – vnos zneska »500« – klik na vnosno polje datuma – vnos datuma

»15.09.2011« - izbira kategorije »stipendija« s spustnega seznama - klik na gumb Potrdi.


Pričakovani

rezultati

Aplikacija ne omogoča ročnega vnosa datuma, saj je vnosno polje zasenčeno.

Dejanski

rezultati

Aplikacija ne omogoča ročnega vnosa datuma, saj ne moramo klikniti na vnosno polje datuma.


Tabela 22: Testni scenarij izpisa transakcij

ID 18

Opis Testiranje aktivnosti poročila – izpis vseh transakcij.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb vse transakcije.

Kategorija Izpis transakcij

Pričakovani

rezultati

Aplikacija izpiše vse obstoječe transakcije. V primeru, da nimamo vnesene nobene transakcije

prikaţe prazen seznam.

Dejanski

rezultati

Aplikacija izpiše vse transakcije, ki obstajajo v aplikaciji.



ID 19

Opis Testiranje aktivnosti poročila – izpis zadnjih 10 transakcij.


Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb zadnjih 10 transakcij.


Pričakovani

rezultati

Aplikacija izpiše zadnjih 10 transakcij. V primeru, da nimamo vnesene nobene ustrezne transakcije

prikaţe prazen seznam.

Dejanski

rezultati

Aplikacija izpiše zadnjih 10 ali manj transakcij.



ID 20

Opis Testiranje aktivnosti poročila – izpis transakcij zadnjih 7 dni.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb zadnjih 7 dni.


Pričakovani

rezultati

Aplikacija izpiše vse obstoječe transakcije zadnjih 7 dni. V primeru, da nimamo vnesene nobene

ustrezne transakcije prikaţe prazen seznam.

Dejanski

rezultati

Aplikacija izpiše vse obstoječe transakcije zadnjih 7 dni.



ID 21

Opis Testiranje aktivnosti poročila – izpis transakcij tekočega meseca.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb tekoč mesec.


Pričakovani Aplikacija izpiše vse obstoječe transakcije tekočega meseca. V primeru, da nimamo vnesene


rezultati nobene ustrezne transakcije prikaţe prazen seznam.

Dejanski

rezultati

Aplikacija izpiše vse obstoječe transakcije tekočega meseca.



ID 22

Opis Testiranje aktivnosti poročila – po kategoriji.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb po kategoriji – s spustnega seznama izberemo

kategorijo.


Pričakovani

rezultati

Aplikacija izpiše vse obstoječe transakcije izbrane kategorije. V primeru, da nimamo vnesene

nobene ustrezne transakcije prikaţe prazen seznam.

Dejanski

rezultati

Aplikacija izpiše vse obstoječe transakcije določene kategorije.



ID 23

Opis Testiranje aktivnosti poročila – izpis po računu.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb po računu – s spustnega seznama izberemo račun.


Pričakovani

rezultati

Aplikacija izpiše vse obstoječe transakcije izbranega računa. V primeru, da nimamo vnesene

nobene ustrezne transakcije prikaţe prazen seznam.

Dejanski

rezultati

Aplikacija izpiše vse obstoječe transakcije na določenem računu.




ID 24

Opis Testiranje aktivnosti poročila – izpis pozitivnih transakcij.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb samo pozitivne transakcije.


Pričakovani

rezultati

Aplikacija izpiše vse obstoječe pozitivne transakcije. V primeru, da nimamo vnesene nobene


Dejanski

rezultati

Aplikacija izpiše vse obstoječe pozitivne transakcije.



ID 25

Opis Testiranje aktivnosti poročila – izpis negativnih transakcij.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb samo negativne transakcije.


Pričakovani

rezultati

Aplikacija izpiše vse obstoječe negativne transakcije. V primeru, da nimamo vnesene nobene


Dejanski

rezultati

Aplikacija izpiše vse obstoječe negativne transakcije.




ID 26

Opis Testiranje aktivnosti poročila – izpis transakcij v izbranem časovnem obdobju.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb po datumu – klik na zgornji gumb nastavi datum –

izberemo datum »15.09.2011« – potrdimo s klikom na gumb set – klik na spodnji gumb nastavi

datum– izberemo novejši datum od prejšnjega datuma »20.09.2011«– klik na gumb set – klik na

gumb Potrdi.


Pričakovani

rezultati

Aplikacija izpiše vse obstoječe transakcije v podanem časovnem obdobju. V primeru, da nimamo

vnesene nobene ustrezne transakcije prikaţe prazen seznam.

Dejanski

rezultati

Aplikacija izpiše vse obstoječe transakcije v določenem časovnem obdobju.



ID 27

Opis Testiranje aktivnosti poročila – izpis transakcij v izbranem časovnem obdobju. Datum od je

novejši od datuma do.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb po datumu – klik na zgornji gumb nastavi datum –

izberemo datum »20.09.2011« – potrdimo s klikom na gumb set – klik na spodnji gumb nastavi

datum– izberemo starejši datum od prejšnjega datuma »10.09.2011« – klik na gumb set – klik na

gumb Potrdi.


Pričakovani

rezultati

Aplikacija nas bo opozorila, da je datum do starejši od datum od.

Dejanski

rezultati

Aplikacija javi napako »Drugi datum mora biti niţji od prvega!«.




ID 28

Opis Testiranje aktivnosti poročila – izpis transakcij po kategoriji brez izbire kategorije.

Zaporedje

ukazov

Klik na aktivnost poročila – klik na gumb po kategoriji – klik na gumb Potrdi.


Pričakovani

rezultati

Aplikacija nas opozori na napačen vnos podatkov.

Dejanski

rezultati

Aplikacija izpiše napako »Izberite kategorijo!«.



ID 29

Opis Testiranje aktivnosti transakcije – dodajanje transakcij. Dodajanje transakcij, kadar imamo pod

istim imenom računa več različnih tipov računa.

Zaporedje

ukazov


tipa računa (»osebni racun«) – pritisk gumba Potrdi – klik gumba dodaj račun – vnos imena

(»Tomaz«), vnos začetnega stanja (5000), vnos tipa računa (»varcevalni racun«) – pritisk gumba

Potrdi - klik na aktivnost transakcije – s spustnega seznama izberemo račun »tomaz«– vnesemo

znesek – kliknemo na gumb nastavi datum – potrdimo datum s klikom na set – izberemo

kategorijo »osebni racun« s spustnega seznama – kliknemo na Potrdi.


Pričakovani

rezultati

Pričakujemo, da bomo dodali ţeleno transakcijo.

Dejanski

rezultati

Pri izbiri računa aplikacija prikaţe imena računov in v primeru, da imamo pod enim imenom več

različnih računov, ne vemo, kateri račun je pravi. Transakcija bo ob pravilnem vnosu podatkov

pravilna, vendar moţno, da bo zapisana na napačnem računu.




ID 30

Opis Testiranje aktivnosti računi – prikaz transakcij na izbranem računu.

Zaporedje

ukazov

Klik na aktivnost računi – klik na račun.


Pričakovani

rezultati

Aplikacija bo izpisala seznam vseh transakcij na tem računu.

Dejanski

rezultati

Aplikacija izpiše vse transakcije določenega računa.


Tabela 35: Testni scenarij dodajanja transakcij

ID 31

Opis Testiranje dodajanje transakcij – kopiranje napačnih podatkov v vnosno polje.

Zaporedje

ukazov

V tekstovnem urejevalniku napišemo besedilo »testkopiranja1« ter ga skopiramo v odloţišče

»clipboard«. Zaţenemo aplikacijo mywallet - klik na aktivnost Transakcije – prilepimo besedilo iz

odloţišča v vnosno polje znesek.

Kategorija Dodajanje transakcij

Pričakovani

rezultati

Aplikacija ne bo dovolila vnosa napačnih podatkov.

Dejanski

rezultati

Aplikacija v vnosno polje znesek vpiše le število »1«, znakovne znake pa ignorira, saj polje

sprejema samo številčne vrednosti.





Documents

Diplomsko delo - COnnecting REpositories · Key words: Android platform, mobile application development, software testing, robotium, unit testing UDK: 621.395:004.77(043.2) Abstract