TIE Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4. Antti Jääskeläinen Matti Vuori

Transkriptio

1 TIE Ohjelmistojen testaus Harjoitustyön esittely osa 2: Vaiheet 3 & 4 Antti Jääskeläinen Matti Vuori

2 Vaiheet 3 & 4: Järjestelmätestaus

3 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ää

4 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

5 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: Käytännössä testauksen perustuttava pitkälti kokemukseen ja terveeseen järkeen

6 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ää

7 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?

8 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ä

9 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ä

10 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

11 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

12 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

13 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

14 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

15 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

16 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

17 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

18 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

19 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

20 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

21 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

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

23 Työkalut

24 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

25 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 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

26 Tuetut työkalut 2/2 ModelJUnit OSMO Testeriä suuresti muistuttava mallipohjainen testiengenerointityökalu fmbt Kolmas tapahtumiin perustuva mallipohjainen työkalu Mallit luodaan AAL-kielellä, tapahtumien sisältö määritetään ohjelmointikielellä kuten C++ tai Python

27 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 Muita automaatiotyökaluja Javan automaatiotyökaluja: JUnit käytössä pääosin yksikkötestauksessa, mutta kirjastojen avulla käytettävissä myös korkeammilla testauksen tasoilla UI-testauskirjasto FEST: Järjestelmä- ja UI-testaustyökaluja jedit käyttää Marathonia UISpec4J Jameleon