TIE-21200 Ohjelmistojen testaus

Harjoitustyön esittely osa 2:

Vaiheet 3 & 4

Antti Jääskeläinen

Matti Vuori

Vaiheet 3 & 4:

Järjestelmätestaus

28.10.2013 2

Päämäärä

• jEdit-ohjelmointieditorin järjestelmätestaus

• Tarkoituksena on testata, onko editori valmis tuotantokäyttöön tai

julkaistavaksi

• Testaus suoritetaan käyttöliittymätasolla

– Mustalaatikkotestausta, ei näkymää lähdekoodiin

• Testaus loppukäyttäjän näkökulmasta; testaajien ja

testisuunnittelijoiden on ymmärrettävä, mikä on loppukäyttäjälle

oleellista, ja sen perusteella päätettävä

– Mitä testataan

– Miten testataan, millaisia testejä on syytä kehittää

28.10.2013 3

Testattavat ominaisuudet

• Testattavana koko editori

– Kaikki toiminnallisuus, kaikki käyttötapaukset

– Kuten yksikkötestauksessakin, keskitytään ainoastaan toiminnalliseen

testaukseen

• Käytännössä koko editorin kattavaa testaus ei ole mahdollista

suorittaa harjoitustyön puitteissa

– Priorisointi välttämätöntä

• jEdit on tarkoitettu nimenomaan ohjelmointikäyttöön, joten kannattaa

keskittyä nimenomaan ohjelmoijien tarvitsemiin ominaisuuksiin

28.10.2013 4

Lähtökohdat

• Jos käytettävissä olisi vaatimusmäärittely, se ohjaisi testausta

– Täsmällisen vaatimusmäärittelyn puuttuminen ei ole tosielämässä

harvinaista, etenkään sisäiseen käyttöön tarkoitetulle työkalulle

– Käytännössä laadukaskaan vaatimusmäärittely harvemmin kuvaa

yleistä toiminnallisuutta, kuten tiedostojen avaamista tai tulostusta

• jEditin käyttäjille suunnattua dokumentaatiota voi käyttää

lähtökohtana: http://www.jedit.org/users-guide/index.html

• Käytännössä testauksen perustuttava pitkälti kokemukseen ja

terveeseen järkeen

28.10.2013 5

Dokumentointi 1/2

• Järjestelmätestauksen etenemistä ja tuloksia seuraavat tarkasti

sekä johtoporras että asiakkaat

• Voitava osoittaa, että testaus

– on hyvin suunniteltu – testataan oikeat asiat, oikein tavoin

– on hyvin suoritettu – metriikat ja joskus lokit

– on kattanut oikeat asiat – vaatimuskattavuus (koodikattavuutta ei

yleensä tarkkailla järjestelmätasolla)

• Dokumentointi on siis tärkeää

28.10.2013 6

Dokumentointi 2/2

• Yksikkötestauksen suorittaa yleensä kehittäjä yksinään

• Järjestelmätestauksen tekee usein erillinen tiimi, eivätkä testien

suunnittelusta ja suorituksestakaan välttämättä vastaa samat

henkilöt

– Eri tiimit saattavat vieläpä työskennellä eri puolilla maapalloa

• Dokumentteja tarvitaan siis myös välittämään tietoa

testausorganisaation sisällä

– Voiko joku muu suorittaa testauksen oikein suunnitelmien perusteella?

– Osaako joku muu korjata virheet raporttien perusteella?

– Ymmärtääkö testauspäällikkö raporttien perusteella, missä tilassa

järjestelmän kehitys on?

28.10.2013 7

Harjoitustyön vaiheet

• Testaus tehdään kahdessa vaiheessa, kuten

yksikkötestauksessakin

– Vaihe 3: testauksen suunnittelu

– Vaihe 4: testauksen toteutus

• Käytettävissä oleva jEditin versio vaihdetaan vaiheiden välissä

– suoritusvaiheessa käytettävissä on versio, johon on kylvetty virheitä

28.10.2013 8

Lähestymistapa

• Järjestelmätestauksen suoritukseen on valittavissa useita eri

lähestymistapoja

• Lähestymistavan voi valita vapaasti esim. tehokkuuden,

mielenkiinnon tai omien oppimistavoitteiden perusteella

• Tosielämässä järjestelmän testaukseen käytettäisiin useita tapoja

rinnakkain

• Perusvaihtoehdot ovat

– A: Systemaattinen manuaalinen testaus

– B: Tutkiva testaus

– C: Perinteinen testiautomaatio

– D: Mallipohjainen testaus

– E: Jokin yhdistelmä edellisistä

28.10.2013 9

Lähestymistapa A:

Manuaalinen testaus

• Perinteisin ja laajimmin käytetty testauksen muoto

• Vaihe 3:

– Tunnista testikohteen oleellisimmat ominaisuudet

– Suunnittele testijoukot

– Laadi testitapaukset

• Vaihe 4:

– Suorita testitapaukset

– Raportoi virheet ja testauksen kulku

• Oleellista:

– Hyvä testitapausten suunnittelu

– Hyvä testitapausten kehityksen dokumentointi, niin että testauksen

kattavuuteen voidaan luottaa

– Hyvä virheraportointi

28.10.2013 10

Lähestymistapa B:

Tutkiva testaus 1/3

• Ketterässä kehityksessä yleisesti käytetty lähestymistapa

• Käytetään myös usein systemaattisempien lähestymistapojen

tukena

• Myös tutkiva testaus tarvitsee suunnittelua ja suuntaviivoja

testauksen kulkua ohjaamaan, esim.

– Esimerkkikäyttäjiä: kuvataan hypoteettisia henkilöitä, jotka käyttävät

sovellusta tietyissä olosuhteissa ja tietyin tavoin

– Käyttöskenaarioita: kuvataan realistisia tilanteita ja tapoja, joilla

sovellusta odotetaan käytettävän

– Ominaisuuskokonaisuuksia: kuvataan oleellisia ominaisuusjoukkoja ja

olosuhteita, joissa niiden on toimittava

• Suuntaviivoja tarvitaan, jotta testauksen suorittajat pystyvät

hahmottamaan, mitä kaikkea pitäisi käydä läpi

28.10.2013 11

Lähestymistapa B:

Tutkiva testaus 2/3

• Vaihe 3:

– Valitse tapa jäsentää testikohteen käyttöä ja ominaisuuksia

– Tunnista edellisen pohjalta testikohteen oleellisimmat osat

– Esitä näiden perusteella suuntaviivat testauksen suoritukselle

• Vaihe 4:

– Käytä sovellusta laadittujen suuntaviivojen pohjalta

– Kirjaa testauksen aikana tehdyt asiat testilokiin

– Raportoi virheet ja testauksen kulku

28.10.2013 12

Lähestymistapa B:

Tutkiva testaus 3/3

• Oleellista:

– Järkevän kontekstin valinta – oletukset käyttäjistä, käyttötilanteista yms.

– Sovelluksen toiminnan havainnointi lennossa

– Epäilyttävien havaintojen huolellinen tutkiminen vian paikallistamiseksi

– Testauksen kulun raportointi, jotta sen kattavuuteen voi luottaa

– Hyvä virheraportointi

28.10.2013 13

Lähestymistapa C:

Testiautomaatio 1/2

• Laaditaan testitapaukset manuaalisesti, suoritetaan ne

automaattisesti

• Vaihe 3:

– Tunnista testikohteen oleellisimmat ominaisuudet

– Suunnittele automaatio: työkalut, testitapausten rakenne, testidata jne.

– Suunnittele testijoukot

– Laadi testitapaukset automaatiotyökalulle sopivaan muotoon

– Dokumentoi testiympäristö ja työkalun käyttö

• Vaihe 4:

– Suorita testitapaukset työkalulla

– Raportoi virheet ja testauksen kulku

28.10.2013 14

Lähestymistapa C:

Testiautomaatio 2/2

• Oleellista:

– Hyvän työkalun valinta: käytettävyys, testien ylläpidettävyys jne.

– Koska testien laatiminen vaatii joka tapauksessa samaa osaamista kuin

lähestymistavassa A, emme vaadi suurta määrää testitapauksia –

näyttö automaation hallinnasta korvaa pienemmän kattavuuden

– Hyvä virheraportointi

28.10.2013 15

Lähestymistapa D:

Mallipohjainen testaus

• Generoidaan testitapaukset ja suoritetaan ne automaattisesti

• Vaihe 3:

– Tunnista testikohteen oleellisimmat ominaisuudet

– Suunnittele automaatio: työkalut, mallinnusmenetelmät

– Laadi testimalli

• Vaihe 4:

– Generoi ja suorita testitapaukset työkalulla

– Raportoi virheet ja testauksen kulku

• Oleellista:

– Hyvän työkalun valinta: käytettävyys, mallin ylläpidettävyys jne.

– Kuten perinteisen automaation kohdalla, testauksen kattavuuden ei

tarvitse olla yhtä korkea kuin manuaalisissa lähestymistavoissa

– Hyvä virheraportointi

28.10.2013 16

Lähestymistapa E:

Eri tapojen yhdistelmä

• Suoritetaan testausta kahdella tai useammalla tavoista A-D

• Demonstroi hyvin laaja-alaista testausosaamista

• Esimerkiksi:

– Kattava systemaattinen manuaalinen testaus, havaittujen virheiden ja

epäselvyyksien tarkempi tarkastelu tutkivalla testauksella

– Tärkeimpien perusomaisuuksien automaattinen testaus, muiden

ominaisuuksien tutkiva testaus

– Kattava tutkiva testaus, automaattisten testien laatiminen havaituille

virheille korjatun version testausta varten

28.10.2013 17

Testitapaukset 1/2

• Tunniste

• Alustus: ohjelman tila, tarvittavat tiedostot yms.

• Syötteet: yksi testitapaus testaa vain yhden asian (poikkeuksena

datapohjainen testaus, jossa samat asiat tehdään useilla eri data-

arvoilla)

• Tulokset: ohjelman tulosteet, muutokset tiedostoihin yms.

• Prioriteetti: oleellinen etenkin manuaalisessa testauksessa, jossa

osa testeistä voidaan joutua jättämään suorittamatta ajan

puutteessa

28.10.2013 18

Testitapaukset 2/2

• (Automaattisessa) yksikkötestauksessa

– Testikoodi dokumentoi useimmat oleelliset asiat

– Muu dokumentointi muistuttaa tuotantokoodin kommentointia

– Syötteet on tyypillisesti kovakoodattu testitapauksiin

• (Manuaalisessa) järjestelmätestauksessa

– Testiaskeleet on määritettävä kirjallisesti

– Testitapaukset voidaan laatia siten, että testaajan on helppo vaihdella

syötteitä, kannattaa esittää suoritettavat testiaskeleet ja käytettävät

syötteet erikseen

28.10.2013 19

Raportin teko

• Mitä on testattu?

• Poikettiinko suunnitelmista? Jos, niin miten?

– kaikki sujuu harvoin täsmälleen suunnitelman mukaan, poikkeamia voi

tehdä tarpeen vaatiessa

• Kuinka kattava testaus oli?

• Millaisessa kunnossa testikohde testauksen perusteella on?

• Läpäiseekö testikohde testauksen?

• Mitä virheitä on löydetty?

– virheraportit kirjoitetaan löydetyistä virheistä, ei epäonnistuneista

testeistä: usealle samaan ongelmaan törmänneelle testille yhteinen

raportti

28.10.2013 20

Virheraportin rakenne

• Kerro, mikä testikohteessa on vialla

– pitäisi näkyä jo otsikossa, jotta vikaluettelosta saisi yleiskuvan

testikohteen kunnosta

• Missä ja miten vika ilmenee

– testiympäristö

– syötteet

– odotetut ja saadut tulokset

– jne.

• Motivoi ihmisiä korjaamaan virhe

– vaikutukset käyttäjään

– vaikutukset kehitykseen ja testaukseen

28.10.2013 21

Testilokit

• Testatuista asioista on jäätävä jälki dokumentaatioon

– Mitä, miten, kuka, milloin, …

• Systemaattisessa testauksessa

– testitapaukset kertovat testikohteella suoritettavat toimenpiteet

– kirjanpito suoritetuista testitapauksista dokumentoi testauksen

• Tutkivassa testauksessa

– ei ole testitapauksia, joista näkisi, mitä kaikkea on testattu

– kattavuus täytyy osoittaa erillisellä testilokilla, johon kirjataan testauksen

aikana suoritetut toimet ja tehdyt havainnot (pohja lokille löytyy

harjoitustyön nettisivulta)

28.10.2013 22

Työkalut

28.10.2013 23

Automaatiotyökalut

• Automaattiseen testaukseen on tarjolla paljon erilaisia työkaluja

• Kurssilla muutama tuettu vaihtoehto, mutta myös muita saa vapaasti

käyttää oman mielenkiinnon mukaan

– Testien suorituksen automaatio: Jemmy

– Testien generoinnin automaatio: OSMO Tester, ModelJUnit, fMBT

• Katsaus tuettuihin työkaluihin löytyy sivulta

http://www.cs.tut.fi/~testaus/s2013/project/tools/

28.10.2013 24

Tuetut työkalut 1/2

• Jemmy

– Työkalu Java-sovellusten käyttöliittymien testaukseen

– Ohjelma käynnistetään Jemmyn koodin kautta, ja sen

käyttöliittymäkomponentteihin päästään Javan kautta käsiksi

– Voidaan käyttää manuaalisesti laadittujen tai automaattisesti

generoitujen testien suoritukseen

– http://java.net/projects/jemmy

• OSMO Tester

– Mallipohjainen testiengenerointityökalu

– Testikohteen toiminnallisuus esitetään tapahtumapohjaisina malleina:

milloin tapahtuma voidaan suorittaa, mitä tapahtuu kun se suoritetaan

– Mallit ovat annotoitua Java-koodia

– http://code.google.com/p/osmo/

28.10.2013 25

Tuetut työkalut 2/2

• ModelJUnit

– OSMO Testeriä suuresti muistuttava mallipohjainen

testiengenerointityökalu

– http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/

• fMBT

– Kolmas tapahtumiin perustuva mallipohjainen työkalu

– Mallit luodaan AAL-kielellä, tapahtumien sisältö määritetään

ohjelmointikielellä kuten C++ tai Python

– https://01.org/fmbt/

28.10.2013 26

Työkalujen käyttö

• Jemmy, OSMO Tester ja ModelJUnit ovat Javaa, ja ne saa käyttöön

yksinkertaisesti liittämällä ohjelman paketin jEdit-projektiin

• fMBT on asennettu Lintulaan

– Ympäristön pystytys

source /share/ohjcourses/testaus/setup_testenv.sh

– Mallin luominen

fmbt-editor malli.py.aal testi.conf

– Testin generointi

fmbt –l loki.log testi.conf

• jEditin käskyttäminen fMBT:stä valitettavasti hankalaa

– AAL/Java-variantti heikosti tuettu, toimivuus epävarmaa

– Javan accessibility-rajapintaa hyödyntävät Python-työkalut (Dogtail,

LDTP) eivät toimi Lintulassa

– Muita mahdollisuuksia testaus omassa ympäristössä tai off-line-testaus

28.10.2013 27

Muita automaatiotyökaluja

• Javan automaatiotyökaluja:

– http://java-source.net/open-source/testing-tools

• JUnit käytössä pääosin yksikkötestauksessa, mutta kirjastojen avulla

käytettävissä myös korkeammilla testauksen tasoilla

– http://www.junit.org/

– UI-testauskirjasto FEST: http://code.google.com/p/fest/

• Järjestelmä- ja UI-testaustyökaluja

– jEdit käyttää Marathonia http://www.marathontesting.com/

– UISpec4J http://www.uispec4j.org/

– Jameleon http://jameleon.sourceforge.net/index.html

28.10.2013 28