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 dataarvoilla) 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