tie-21200 ohjelmistojen testaus harjoitustyön esittely osa...
TRANSCRIPT
TIE-21200 Ohjelmistojen testaus
Harjoitustyön esittely osa 2:
Vaiheet 3 & 4
Antti Jääskeläinen
Matti Vuori
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
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