TIE-21200 Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori
Vaiheet 3 & 4: Järjestelmätestaus 27.10.2014 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ää 27.10.2014 3
Testattavat ominaisuudet Periaatteessa testattavana koko editori Kaikki toiminnallisuus, kaikki käyttötapaukset Kuten yksikkötestauksessakin, keskitytään ainoastaan toiminnalliseen testaukseen Käytännössä koko editorin kattavaa testausta ei ole mahdollista suorittaa harjoitustyön puitteissa Priorisointi välttämätöntä jedit on tarkoitettu erityisesti ohjelmointikäyttöön, joten kannattaa keskittyä nimenomaan ohjelmoijien tarvitsemiin ominaisuuksiin 27.10.2014 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 Hyödyllisiä ajatuksia on myös Matti Vuoren kalvosetissä http://www.mattivuori.net/extra/ohjelmiston_yleisia_testattavia_asioit a.pdf Käytännössä testauksen perustuttava pitkälti kokemukseen ja terveeseen järkeen 27.10.2014 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ää 27.10.2014 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? 27.10.2014 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ä 27.10.2014 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ä 27.10.2014 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 27.10.2014 10
Lähestymistapa B: Tutkiva testaus 1/2 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 tiettyihin tarkoituksiin 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 27.10.2014 11
Lähestymistapa B: Tutkiva testaus 2/2 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 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 27.10.2014 12
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 27.10.2014 13
Lähestymistapa C: Testiautomaatio 2/2 Oleellista: Hyvän työkalun valinta: käytettävyys, testien ylläpidettävyys jne. Hyvä testien rakenne 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 27.10.2014 14
Lähestymistapa D: Mallipohjainen testaus 1/2 Generoidaan testitapaukset ja suoritetaan ne automaattisesti Vaihe 3: Tunnista testikohteen oleellisimmat ominaisuudet Suunnittele automaatio: työkalut, mallinnusmenetelmät Laadi testimalli Dokumentoi testausympäristö ja työkalun käyttö Vaihe 4: Generoi ja suorita testitapaukset työkalulla Raportoi virheet ja testauksen kulku 27.10.2014 15
Lähestymistapa D: Mallipohjainen testaus 2/2 Oleellista: Hyvän työkalun valinta: käytettävyys, mallin ylläpidettävyys jne. Hyvä mallinnustekniikka: ymmärrettävyys, ylläpidettävyys jne. Kuten perinteisen automaation kohdalla, testauksen kattavuuden ei tarvitse olla yhtä korkea kuin manuaalisissa lähestymistavoissa 27.10.2014 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 mallipohjainen testaus, muiden ominaisuuksien tutkiva testaus Kattava tutkiva testaus, automaattisten testien laatiminen havaituille virheille korjatun version testausta varten 27.10.2014 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 27.10.2014 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 27.10.2014 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 27.10.2014 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 27.10.2014 21
Testilokit Testatuista asioista on jäätävä jälki dokumentaatioon Mitä, miten, kuka, milloin, Testitapauksiin pohjautuvassa 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) Mallipohjaisessa testauksessa työkalu tuottaa kuvauksen testauksen aikana tehdyistä asioista 27.10.2014 22
Työkalut 27.10.2014 23
Testauksen automaatiotyökalut Automaattiseen testaukseen on tarjolla paljon erilaisia työkaluja Kurssilla pari tuettua vaihtoehto, mutta myös muita saa vapaasti käyttää oman mielenkiinnon mukaan Testien suorituksen automaatio: Jemmy, fmbt Testien generoinnin automaatio: fmbt Katsaus tuettuihin työkaluihin löytyy sivulta http://www.cs.tut.fi/~testaus/s2014/project/tools/ 27.10.2014 24
Jemmy Työkalu Java-sovellusten käyttöliittymien testaukseen Testattava ohjelma käynnistetään Jemmyn koodin kautta, ja sen käyttöliittymäkomponentteihin päästään Javan kautta käsiksi Soveltuu sekä manuaalisesti luotujen että mallipohjaisesti generoitujen testien ajoon Voidaan käyttää suoraan JUnitilla kirjoitetuista testitapauksista käsin http://java.net/projects/jemmy 27.10.2014 25
fmbt Tapahtumiin perustuva mallipohjainen työkalu Mallit luodaan AAL-kielellä, tapahtumien sisältö määritetään ohjelmointikielellä kuten Python tai Java Python selkeästi parhaiten tuettu, Javan toiminta valitettavasti epäluotettavaa Sisältää myös Python-rajapintoja sovellusten käyttöliittymien käsittelyyn eri ympäristöissä Soveltuvat mallipohjaisen testauksen lisäksi perinteiseen automaatioon https://01.org/fmbt/ 27.10.2014 26
Työkalujen käyttö Jemmy on Javaa, ja sen 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 Oleellisimmat työkalut fmbt-editor malli.py.aal testi.conf fmbt-scripter malli.py.aal fmbt testi.conf Python-kirjasto käyttöliittymien käsittelyyn Linuxilla fmbtx11 27.10.2014 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/ Javan päälle rakennettuja mallipohjaisia työkaluja OSMO Tester http://code.google.com/p/osmo/ ModelJUnit http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/ 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 27.10.2014 28