6.3 Virheiden kylväminen

Transkriptio

1 6.3 Virheiden kylväminen Error seeding Lisätään tietoisesti virheitä ohjelmakoodiin, jotta Voidaan yrittää arvioida jäljellä olevien oikeiden virheiden määrää testauksen avulla löytyneiden kylvettyjen virheiden määrästä Arvioida testauksen tehokkuutta Merkitään V o :lla oikeiden ja V k :lla kylvettyjen virheiden kokonaismäärää sekä V ol :lla ja V kl :lla löydettyjen oikeiden ja kylvettyjen virheiden määrää Oletetaan lisäksi, että V o /V ol = V k /V kl Jäljellä olevien virheiden määrän arvioksi saadaan (V ol x (V k /V kl )) - V ol Mika Katara: Ohjelmistojen testaus, Kylvämisen ongelmia: Minkälaisia virheitä pitäisi kylvää? Onko kaikki kylvetyt virheet muistettu poistaa? Paljonko menetelmästä aiheutuu ylimääräistä työtä? Tekniikkaa voi harrastaa dokumenttien tarkastusmenettelyssä Voidaan mitata sitä, kuinka hyvin tarkastajat ovat perehtyneet dokumenttiin Vaatii paljon organisaatiolta Mika Katara: Ohjelmistojen testaus,

2 Mutaatiotestaus Virheiden kylvämistekniikan erikoistapaus Tuotetaan ohjelmasta versioita, joissa kaikissa on kylvettynä eri virhe Voidaan käyttää Testauksen tehokkuuden arviointiin (kuinka monta mutanttia löydettiin) Sen testaukseen, kuinka hyvin ohjelma kykenee toipumaan virheistä Aikaisemmin mutaatioiden tuottamista on käytetty myös testauskurssin harjoitustöiden generointiin! Mika Katara: Ohjelmistojen testaus, Pablon virheidenkylvökone C++-ohjelma, joka saa syötteenään toisen C++-ohjelman ja generoi siitä mutantin Mutanttiin kylvetyt virheet saa selville vertaamalla sitä alkuperäiseen ohjelmaan (Unix-ympäristössä esim. diff) Määrittelee mm. operaattoreiden ja tyyppien joukkoja, joiden alkioita voidaan vaihtaa keskenään Esim. {+,*,/}: jos ohjelmassa esiintyy jokin joukon alkio, vaihdetaan se joksikin muuksi alkioksi Esim. {short, int, long}: vaihdetaan tyyppiä Mika Katara: Ohjelmistojen testaus,

3 Osaa myös lisätä ja poistaa continue- ja break-lauseita silmukan sisältä Ongelma: kaikki tuotetut mutantit eivät ole laillisia C++ohjelmia Ratkaisu: kutsutaan gcc:tä ja kelpuutetaan vain sellaiset mutantit, jotka menevät kääntäjästä läpi Hajautettu kylvökone onnistui tuottamaan lyhyessä ajassa noin mutanttia, joista riitti jokaiselle harjoitustyöryhmälle omansa Mika Katara: Ohjelmistojen testaus, Ekskursio: miten voi päästä virheen jäljille Mukailtu lähteestä [Kaner et al. 02] Uudet asiat: uusimmat ominaisuudet voivat toimia väärin Uudet tekniikat: uudet käsitteet johtavat uusiin virheisiin Uudet markkinat: erilaiset käyttäjät käyttävät ohjelmaa eri tavalla Muutos: muutokset saattavat rikkoa aiemmin toimineen koodin Myöhäinen muutos: kiireiset päätökset ja kiireiset ihmiset johtavat virheisiin Kiireinen työ: kun projektille ei ole budjetoitu tarpeeksi aikaa, työn laatu kärsii Mika Katara: Ohjelmistojen testaus,

4 Oppimiskäyrä: huolimattomuusvirheitä Huono suunnittelu tai vaikeasti ylläpidettävä järjestelmä: joidenkin suunnittelupäätösten takia järjestelmä on niin huonosti ylläpidettävä, että vikojen korjaukset johtavat säännönmukaisesti uusiin vikoihin Väsyneet ohjelmoijat: usean viikon kestävät ylityöjaksot johtavat tehottomuuteen ja virheisiin Muut henkilöstöasiat: henkilökohtaiset ongelmat, perheongelmat, ongelmat työyhteisössä (jos kaksi ohjelmoijaa eivät puhu keskenään, tuskin puhuvat heidän koodinsakaan) Mika Katara: Ohjelmistojen testaus, Just slipping it in: projektijohdon tietämättä lisätty ohjelmoijan lempiominaisuus ei välttämättä toimi muun koodin kanssa Ei keksitty täällä: ulkoiset komponentit voivat aiheuttaa ongelmia Ei budjetoitu: budjetin ulkopuoliset työt tehdään usein puolivillaisesti Moniselitteisyys: moniselitteiset spesifikaatiot voivat johtaa virheellisiin tai ristiriitaisiin toteutuksiin Ristiriitaiset vaatimukset: moniselitteisyys peittää usein ristiriidan Liikkuva maali: asiakas keksii mitä haluaa vasta kun tuotetta jo kehitetään Mika Katara: Ohjelmistojen testaus,

5 Bugisuus: ominaisuudet, joissa on paljon tunnettuja bugeja voivat sisältää paljon myös tuntemattomia bugeja Riippuvuudet: häiriöt voivat aiheuttaa muita häiriöitä Untestability: järjestelmää on vaikea (ellei mahdoton) testata Vähäinen yksikkötestaus: ohjelmoijien tulisi löytää ja korjata suurin osa omista virheistään Aikaisempi keskittyminen kapeisiin testausstrategioihin: regressio- ja funktiotestauksen jäljiltä voi ohjelmistoon jäädä suuri määrä virheitä, jotka pysyvät versiosta toiseen Heikot testaustyökalut: mikäli ei käytetä työkaluja esim. karanneiden osoittimien paikallistamiseen, näillä virheillä on hyvät mahdollisuudet jäädä huomaamatta Mika Katara: Ohjelmistojen testaus, Ohjelmointikielille tyypillisiä virheitä: C-kielen esimerkkejä Kommentin loppumerkki unohtunut: a=b; /* kommentti alkaa c=d; /* toinen kommentti */ Sijoitus vs. yhtäsuuruusvertailu: if(a=b) ++c; Paikalliset muuttujat pitää muistaa alustaa: void foo(a) { int b; if (b) {} } Mikä on lauseen i = i++ semantiikka? Onneksi C-kielen heikot kohdat on jo hyvin dokumentoitu ja fiksut kääntäjät osaavat varoittaa epäilyttävistä kohdista Mika Katara: Ohjelmistojen testaus,

6 Ohjelmointikielille tyypillisiä virheitä: C++ esimerkkejä Vaikka kielessä on bool-tyyppi, on implisiittinen konversio bool->int silti sallittu: if (-0.5 <= x <= 0.5) return 0; Oletusrakentajan kutsu ja funktion esittely menevät helposti sekaisin: int main() { string a("hello"); string b(); // funktion esittely string c = string("world"); //... return 0; } Mika Katara: Ohjelmistojen testaus, Ohjelmointikielille tyypillisiä virheitä: Java esimerkkejä Vanhemmassa koodissa luettelotyypin (enum) puuttuminen on johtanut puolivillaisiin kiertoteihin Epätietoisuus siitä, mitä class-tiedostoja ladataan (jar, CLASSPATH, piste CLASSPATH:ssa) Kaikki olioihin viittaavat muuttujat ovat oikeastaan implisiittisiä osoittimia: munolio a, b; // muuttujat alustetaan arvoon null a = b; // osoittimien kopiointi a = new munolio(b); // uuden olion luonti Mika Katara: Ohjelmistojen testaus,

7 7. Ketterä testaus Elämää on V-mallin ulkopuolella eräs selvimpiä trendejä testauksessa on siirtyminen ketterämpiin ja vähemmän suunnitelmaohjattuihin prosesseihin. Mika Katara: Ohjelmistojen testaus, Perinteiseen, vesiputousmallia noudattavaan ohjelmistoprosessiin testaus liitetään V-mallin mukaisesti V-mallin vasen sivu kuvaa vesiputousmallia, jossa edetään ylhäältä alas ensin vaatimusmäärittelystä toiminnalliseen määrittelyyn ja siitä arkkitehtuurisuunnitteluun ja lopulta moduulisuunnitteluun ja toteutukseen Jokaisessa vaiheessa laaditaan testaussuunnitelmat vastaaville testausvaiheille (oikea sivu) Kun testattavissa olevaa toteutusta alkaa olla olemassa, aletaan sitä testata Edetään V-mallin oikeaa sivua alhaalta ylös toimien em. testaussuunnitelmien mukaan Mika Katara: Ohjelmistojen testaus,

8 Testataan kullakin tasolla sitä, vastaako toteutus määrittelyä/suunnittelua Käytettävät tekniikat vaihtelevat riippuen siitä, missä vaiheessa ollaan menossa Esim. testaus on alemmilla tasoilla yleensä enemmän lasi- kuin mustalaatikkotyyppistä ja ylemmillä tasoilla taas toisin päin Jäljitettävyys eri vaiheiden välillä helpottaa virheiden alkuperän selvittämistä Kun virhe on paikallistettu, voidaan testausprosessia yrittää parantaa siten, että ko. tyypin virheet havaitaan aikaisemmin Mika Katara: Ohjelmistojen testaus, Monesti vaatimukset selviävät vasta matkan varrella Kaikkea ei voi tietää projektin aluksi ja muutoksiin on pakko varautua Perinteinen tulkinta V-mallista ei kuitenkaan tue iteratiivista kehitystä, jossa ohjelmasta tuotetaan väliversioita Järjestelmä pyritään tekemään kerralla valmiiksi asti Mallin vaiheet käydään uudestaan läpi vasta sitten kun tehdään järjestelmän seuraavaa versiota Malli myös tekee oletuksia siitä, mitä dokumentoidaan, mistä dokumenteista tuotetaan eri tasojen testitapauksia ja missä vaiheessa tuotetut testit ajetaan Mika Katara: Ohjelmistojen testaus,

9 Yksikkötestausta ketterästi: Test-Driven Development Tapa ajatella, suunnitella, kommunikoida ja kirjoittaa koodia Tavoite: yksinkertainen, selkeä ja toimintavarma ohjelmisto Taustalla extreme Programming -ideat Sivuvaikutuksena syntyy kattava kokoelma automatisoituja yksikkö/integrointitason testejä Ei näin: stressiä -> testataan vähemmän -> enemmän virheitä -> lisää stressiä Vaan näin: stressiä -> testataan -> vähemmän virheitä -> vähemmän stressiä Mika Katara: Ohjelmistojen testaus, Menetelmä lyhyesti: kirjoita testi koodaa toteutus siisti toteutus (refaktorointi) Entä muut mallinnus-, suunnittelu-, dokumentointi-, toteutusja testausmenetelmät? niitä käytetään tarpeen mukaan, jos ne auttavat toimivan ohjelmiston saavuttamisessa Mika Katara: Ohjelmistojen testaus,

10 Periaatteet: Muutosvalmius Asiakkaan läsnäolo Metaforat: projektin yhteinen käsitteistö Suunnittelupeli käyttäjien tarinat (user stories) vaatimukset, käyttötapaukset Pystypalaverit päivittäinen palaveri kestää korkeintaan niin kauan kuin ihmiset jaksavat seistä Mika Katara: Ohjelmistojen testaus, Pyritään valitsemaan yksinkertaisin toimiva ratkaisu Pariohjelmointi parien kierrätys Koodausstandardit tyylioppaat yms. koodista ei pitäisi pystyä sanomaan kuka sen on kirjoittanut Yhteisomistus kaikki ovat vastuussa kaikesta koodista Mika Katara: Ohjelmistojen testaus,

11 Jatkuva integrointi toimimattomuus huomataan heti eikä viikon päästä Koodin siistiminen myös testikoodia pitää siistiä Vähittäistoimitus pienet inkrementit Jaksamisen rajoissa 40 tunnin työviikot Mika Katara: Ohjelmistojen testaus, Testit Tavoitteet: luottamuksen saavuttaminen toimivuuteen, toiminnan dokumentointi, suunnittelu Sykli: kirjoita testi, käännä, aja testit kirjoita koodi, käännä, aja testit Testauksen liikennevalot: testit punaisella testit vihreällä siisti toteutus, käännä, aja testit, integroi, käännä, aja testit, tsekkaa sisään versionhallintaan, kirjoita testi,... Mika Katara: Ohjelmistojen testaus,

12 Myös testikoodia pitää siistiä aika ajoin Tavoitteena suurin piirtein yhtä paljon testikoodia kuin testattavaa koodia jos testikoodia on vähemmän: jotain jää luultavasti testaamatta jos testikoodia on enemmän: testikoodissa luultavasti redundanssia (testien ajamiseen voi kulua liikaa aikaa) Mika Katara: Ohjelmistojen testaus, Kysymyksiä Kuinka isoja askelten pitää olla? Mitä ei tarvitse testata? Mistä tietää, ovatko testit hyviä? Kuinka paljon testejä pitää olla? Milloin testi pitäisi poistaa? Miten ohjelmointikieli ja -ympäristö vaikuttavat? Voiko isoja järjestelmiä tehdä testausohjatusti? Miten TDD otetaan käyttöön kesken projektin? Sulautettujen järjestelmien testaus? Mika Katara: Ohjelmistojen testaus,

13 TDD kokonaisuutena TDD jakaa ongelman pienempiin osiin ja koko ryhmän vastuulle Saavatko sukkela suunnittelu, jatkuva integrointi ja koodin siistiminen koodaamisen ja testaamisen tuntumaan tasaisesti etenevältä luovalta työltä? Pienin askelin etenevässä työssä virheen löytäminen on helpompaa erillinen siistimisvaihe antaa mahdollisuuden keskittyä yhteen asiaan kerrallaan Itsekuria pitää olla: testit pitää kirjoittaa ensin sen sijaan, että tyytyisi vain kokeilemaan toimivuutta Ei sovi kaikkiin projekteihin Saattaa vaikuttaa negatiivisesti ohjelmiston arkkitehtuuriin Mika Katara: Ohjelmistojen testaus, Jatkuva integrointi käytännössä Perustuu artikkeliin Martin Fowler & Matthew Foemmel: Continuous Integration, Jatkuvan integroinnin vaatimukset: Versionhallinnan oltava kunnossa, lähdekoodi yhdessä paikassa, josta sen voi kuka tahansa hakea tarvittaessa Buildin tekeminen automatisoitava niin, että kuka tahansa voi sen tehdä yhdellä komennolla Automatisoidut testitapaukset voidaan samoin ajaa buildille yhdellä komennolla Onnistuneen lopputuloksen voi kuka tahansa hakea käyttöönsä Mika Katara: Ohjelmistojen testaus,

14 Mitä hyötyä jatkuvasta integroinnista on? Oletetaan, että kaksi kehittäjää tekee kumpikin omaa komponenttiansa, joiden olisi tarkoitus toimia toistensa kanssa yhteen Kumpikin testaa oman koodinsa, eikä löydä siitä virheitä Kun komponentit integroidaan, huomataan, etteivät ne toimi yhteen kuten pitäisi Mikäli käytössä on perinteinen prosessi, voi virheen löytäminen olla todella hankalaa, jos koodi on kirjoitettu jo viikkoja aikaisemmin Jatkuvassa integroinnissa virhe on luultavasti tehty samana työpäivänä, tai edellisenä, jolloin sen löytäminen on paljon helpompaa, koska uutta koodia on vähän ja kehittäjä muistaa vielä mitä on tehnyt Mika Katara: Ohjelmistojen testaus, Kuinka usein pitäisi sitten integroida? Automaation ansiosta niin usein kuin halutaan, vähintään kerran päivässä Entä mikä on onnistunut buildi? Buildaus onnistui, jos seuraavat kohdat läpäistään ilman virheilmoituksia tai automaation säätöä: Kaikki viimeisimmät tiedostot saadaan versionhallinnasta ulos Kaikki tiedostot kääntyvät alusta alkaen mikäli kääntäminen kestää kauan, voidaan kääntää vain muutokset, tällöin täydellinen kääntäminen tehdään harvemmin Mika Katara: Ohjelmistojen testaus,

15 Objektitiedostot linkitetään onnistuneesti ajettavaan muotoon esim. Javan class-tiedostot jar-tiedostoiksi Ohjelmisto käynnistetään ja savutestit saadaan suoritettua onnistuneesti Perusedellytyksenä on toimiva konfiguraation- ja versionhallinta Kenen tahansa on voitava kytkeä puhdas kone verkkoon ja yhdellä komennolla saada ladattua kooditiedostot, joilla buildaaminen voidaan tehdä Versionhallintaan pitää laittaa myös muut kuin vain käännöksessä tarvittavat tiedostot, esim. konfiguraatiotiedostot ja skriptit Mika Katara: Ohjelmistojen testaus, Master build Tiimin yhteinen buildi Tehdään keskitetysti palvelimella Järjestelmä tarkkailee versionhallintaa ja huomatessaan uuden koodiversion alkaa buildaamaan Testien jälkeen järjestelmä lähettää meiliä tuloksista niille kehittäjille, joiden uutta koodia buildissa oli kehittäjien oletetaan olevan valmiudessa korjaamaan koodiaan, kunnes ovat saaneet ilmoituksen onnistuneesta buildista Järjestelmä kirjoittaa lokin buildin vaiheista, lokeja voi tarkkailla www-sivun välityksellä, joka kertoo projektin etenemisestä Tämän jälkeen järjestelmä palaa tarkkailemaan versionhallintaa ja odottamaan uutta buildattavaa koodia Mika Katara: Ohjelmistojen testaus,

16 Ennen tehtävän aloittamista kehittäjät hakevat tuoreimmat tiedostot versionhallinnasta Uuden koodin voi integroida paikallisesti kun joko koko tehtävä tai osa siitä on tehty, kunhan vain yksikkötestit on saatu ajettua onnistuneesti Integroinnin aluksi otetaan jälleen versionhallinnasta uusimmat versiot muista tiedostoista Kun paikallinen buildi on tehty ja savutestit ajettu onnistuneesti, kehittäjä laittaa koodinsa versionhallintaan ja jää odottamaan master buildia Kun master build on tehty onnistuneesti, voi siirtyä seuraavaan tehtävään Mika Katara: Ohjelmistojen testaus, Ketterä hyväksyntätestaus: ATDD TDD:ssä matalan tason testit ajavat koodausta eteenpäin ATDD:ssä korkean tason testit ajavat koko prosessia eteenpäin Kuinka Definition of done määritellään asiakkaan tai käyttäjän näkökulmasta? ATDD perustuu siihen, että määritellään suoritettavia korkean tason testejä ennen kuin toteutusta on edes aloitettu Ideaalitapauksessa testit tekee asiakas tai loppukäyttäjä Kun testi läpäistään, on vastaava vaatimus Done ATDD-työkalut tarjoavat helpon tavan määritellä testejä muodossa, jota asiakas ja loppukäyttäjäkin ymmärtävät Department of Software Systems Mika Katara: Ohjelmistojen testaus,

17 ATDD-prosessi (iteratiivinen) muokattu, alkuperäinen Niklas Collin, Kilosoft Customer/ end-user Specify Requirements Project Manager Chief engineer Test automation engineer Implements Derived to Executable tests (backlog) Department of Software Systems Mika Katara: Ohjelmistojen testaus, Edut Vähemmän monikäsitteisyyksiä vaatimuksissa, koska asiakas tai loppukäyttäjä on hyväksynyt testit Kun testi menee läpi, voidaan siirtyä toteuttamaan seuraavaa vaatimusta Testit määrittelevät projektin laajuuden: jos läpäisemättömiä testejä ei ole, ei ole mitään mitä implementoida (kuten asiakas tai loppukäyttäjä on asian hyväksynyt) Etenemisen läpinäkyvyys johdolle ja asiakkaalle Kannattaa kuitenkin muistaa, että ATDD-työkalut eivät välttämättä tue kaikki sovelluskohteita ja kaikki asiakkaan eivät ole valmiit toimimaan näin! Department of Software Systems Mika Katara: Ohjelmistojen testaus,

18 Manuaalista testaus ketterästi Tutkiva (exploratory) testaus Testaajien ammattitaito ja kokemus pääosissa Testaajat oppivat koko ajan uutta testikohteesta, sen riskeistä, tavoista miten se on toiminut väärin edellisissä testeissä jne. Uusia testitapauksia luodaan ja käytetään jatkuvasti ei välttämättä dokumentoida Uudet testitapaukset ovat vanhoja parempia, koska ne perustuvat uuteen tietoon järjestelmästä Päinvastoin kuin kokeilutestauksessa (ad hoc), testaajilla on selkeät tavoitteet ja keskitytään usein johonkin tiettyyn osaalueeseen Mika Katara: Ohjelmistojen testaus, Tutkivaa testausta voidaan valmistellaan esim. tilauksien (charter) avulla tilaus sisältää tiedon siitä mitä testataan, miksi, miten, minkä tyyppisiä ongelmia etsitään ja lisäksi tietoa riskeistä, suosituksia työkaluiksi jne. Normaalin testaussession kesto noin kaksi tuntia Pääasiallisena tuloksena bugiraportit, mutta myös muuta dokumentaatiota, muistiinpanoja jne. tarpeen mukaan Session jälkeen raportointi sovitulla tavalla Mika Katara: Ohjelmistojen testaus,

19 Ongelmia Kuinka Tiedetään mitä testejä tehtiin? Toistaa ne? Varmistaa tilivelvollisuus? Kouluttaa uusia tutkivia testaajia? Yhdistää tutkiva testaus muun tyyliseen testaukseen? Saada tarkkaa, luotettavaa ja tasapuolista tietoa lähestymistavasta? Allokoida työ tiimin sisällä niin, ettei tehdä turhaan samaa työtä? Mika Katara: Ohjelmistojen testaus, Tutkivan testauksen tyylilajit Freestyle Sessiopohjainen Turisti Sissi Käyttöskenaarioihin / käyttötapauksiin / käyttäjien tarinoihin perustuva Mika Katara: Ohjelmistojen testaus,

20 Muutamia esimerkkejä ketterän testauksen työkaluista TDD Agile acceptance testing Tutkiva testaus Järjestelmätestaus FIT, FitNesse Robot Framework toimistotyökalut Integrointitestaus Yksikkötestaus Jatkuvan integroinnin työkalut xunit ( + erilaisista pienistä apuohjelmista on usein hyötyä kaikilla testauksen tasoilla Mika Katara: Ohjelmistojen testaus, Automaatio ja työkalut Tässä kohdassa tutustutaan testiautomaatioon sekä testaamista helpottaviin työkaluihin. Työkalujen suuren määrän vuoksi tarkoituksena on antaa lähinnä yleiskuva, jonka avulla voi sitten helposti hankkia lisätietoja. Yksi työkalu sopii yhteen hommaan ja toinen toiseen. Mika Katara: Ohjelmistojen testaus,

21 Alkupään kalvot perustuvat Mika Maunumaan kokoamaan materiaaliin Eri näkökulmat Ohjelmistosuunnittelu kuvaa, miten asiat ovat Testaus kysyy ovatko asiat oikeasti niin Testaus on perinteisesti ollut käsityötä Testausautomaation kultainen lupaus on poistaa käsityö ja ratkaista testausongelmat Kun ohjelma testaa ohjelmaa, säästetään aikaa ja rahaa Ohjelma jaksaa testata virheettömästi, nopeammin ja pidempään Kaikkea ei voida testata käsin stressi- ja suorituskykytestaus jne. Mika Katara: Ohjelmistojen testaus, Testiautomaatio kokonaisuutena Testiautomaatio on manuaalisen testauksen täydentäjä, ei sen korvaaja Testit on suunniteltava etukäteen Automatisoidaan vain parhaat testit Käsityön rooli muuttuu, mutta ei poistu Ohjelmisto, jonka tarkoitus on ajaa toista ohjelmaa Molemmat ovat syntyneet (osittain) samoista vaatimuksista Näkökulmassa ja tavoitteissa on suuri ero Testaus ja testien automatisointi vaativat erilaisia taitoja Testiautomaatio ei ole testauksen hopealuoti Mika Katara: Ohjelmistojen testaus,

22 Testiautomaation lupauksia Regressiotestaus helpottuu, enemmän testejä useammin Voidaan suorittaa manuaaliselle testaukselle mahdottomia testejä Esim. verkkosovellusten kuormitustestaus Testauksessa tehdyt virheet vähenevät, kone on ihmistä tarkempi Toisaalta myös uudenlaiset virheet tulevat mahdollisiksi Resurssien tehokkaampi käyttö Testien eheys ja toistettavuus Testit voidaan suorittaa eri laite- tai ohjelmistoalustoilla Testien uudelleenkäyttö testikohteen pysyessä samana Luottamus toimivuuteen kasvaa, markkinoille pääsy nopeutuu Mika Katara: Ohjelmistojen testaus, Testiautomaation yleiset ongelmat Epärealistiset odotukset Työkalut ratkaisevat kaikki pulmat Huonot testaustavat Automating chaos just gives faster chaos Odotetaan automaation löytävän paljon uusia virheitä Virheellinen turvallisuuden tunne Koska automaatio ei löytänyt virheitä, niitä ei olekaan Automatisoitujen testien ylläpito Tekniset ongelmat Buginen testaussofta, yhteensopivuus Organisaation ongelmat Johdon tuen puute, organisaation kulttuuri, koulutus Mika Katara: Ohjelmistojen testaus,

23 Automaation rajoitukset (1/2) Ei poista manuaalisen testauksen tarvetta Kaikkea ei kannata automatisoida harvoin ajettavat testit testattava ohjelmisto on liikkuva maali testin tulokset on helposti ihmisen tulkittavissa, mutta erittäin vaikea koneelle (esim. äänen tai kuvan laatu) fyysistä toimintaa vaativat testit Kaikkea ei tarvitse automatisoida vain parhaat ja usein toistuvat testit Testikohteen testattavuus nousee tärkeään asemaan, sen puute voi johtaa automatisoinnin epäonnistumiseen Mika Katara: Ohjelmistojen testaus, Automaation rajoitukset (2/2) Manuaaliset testit löytävät enemmän virheitä Virhe löytyy yleensä ensin manuaalisella testillä, joka sitten automatisoidaan regressiotestausta varten James Bach raportoi kokemuksistaan Borlandilla: automaatio löysi vain alle 20 % kaikista projektin aikana löydetyistä virheistä vaikka automaatioon oli satsattu jo useita vuosia (James Bach, Test Automation Snake Oil, 1999) Uudet ominaisuudet pitävät sisällään enemmän virheitä kuin vanhat Manuaalinen testaaja voi nopeasti löytää paljon virheitä samalla kun automaatiota vasta laajennetaan uusille alueille Mika Katara: Ohjelmistojen testaus,

24 Testausautomaatio saattaa rajoittaa ohjelmistokehitystä Testit ovat herkkiä vähäisillekin muutoksille ohjelmistossa automaattisen testin alustus on raskaampi operaatio kuin manuaalisen testin ylläpito vaatii työtä Työkaluilla ei ole mielikuvitusta Työkalut tekevät vain sen, mitä niiltä on pyydetty ihminen voi varioida testin suoritusta ja toimia älykkäänä tarkkailijana Automaatio ei lisää tehokkuutta Ajon hinta ja ajoaika vs. suunnittelun ja ylläpidon hinta Mika Katara: Ohjelmistojen testaus, Automaation toimialueet Perinteisesti API- ja protokollapohjaisissa järjestelmissä Tavoitteet yksikäsitteisiä Rajapinta on usein selkeä ohjelmointirajapinta GUI-testaus lisääntynyt graafisten käyttöliittymien yleistyessä Uusia haasteita tiedon syöttö vasteen tulkinta vasteen kaivaminen ohjelman syövereistä Mika Katara: Ohjelmistojen testaus,

25 Käyttöliittymän läpi testattaessa tulee eteen kysymys siitä, mistä vertailuissa tarvittava data saadaan Pahimmassa tapauksessa täytyy vertailla kuvaruudulta kaapattuja bittikarttoja yhden pikselin värin muuttuminen voi saada aikaa väärän hälytyksen testiajossa jos automaatio ei toivu virheistä, voi seurauksena voi olla paljon hukattua aikaa Tekstintunnistus (Optical Character Recognition, OCR) voi auttaa tekstikenttien vertailussa tekniikka on kuitenkin hidas ja virhealtis Parhaassa tapauksessa käytetään suoraan käyttöliittymäkirjaston resursseja ikkuna tuntee sen sisällä olevat tekstikentät, joiden arvot saadaan suoraan merkkijonoina yleensä Windows-maailman GUI-työkalut perustuvat tähän Mika Katara: Ohjelmistojen testaus, Testiautomaatio erilaista ohjelmistosuunnittelua Testausautomaation toteutus on ohjelmistonkehitysprojekti; skriptit vaativat Ohjelmointi- ja suunnittelutaitoja Testaustaitoja Dokumentointitaitoja Ylläpitotaitoja Kuka testaa testiohjelmiston? Mika Katara: Ohjelmistojen testaus,

26 Automatisointiprojekti Aloitetaan yleensä suurin lupauksin Työkalu ratkaisee testauksen ongelmat Automatisoidut testit ovat halpoja Kun käyttöliittymän läpi testaava automaatio vilistää ruudulla, tulee helposti euforinen olo siitä, että tuotteen laatu paranee silmissä jos ei ymmärrä mitä todellisuudessa tapahtuu Kaatuu monesti illuusion särkymiseen Huonojen käytäntöjen automatisointi ei parantanut tilannetta automatisoitiin vääriä, huonoja tai virheellisiä testejä Valittiin väärä tai epäyhteensopiva (ja kallis) työkalu Ylläpitoon ei oltu varauduttu skriptien muuttaminen työlästä testien riippuvuutta ohjelmistoversiosta ei huomioitu Mika Katara: Ohjelmistojen testaus, Automatisoidaan kaikki testit yms. epärealistiset tavoitteet Automatisoijat ovat usein kalliimpia kuin manuaaliset testaajat, samalla rahalla olisi saavutettu paljon aikaan manuaalisessa testauksessa Automaatio ei toivu virheistä Kannattaa aloittaa kevyesti Kannattaa kokeilla useampia eri työkaluja Pilottiprojekti Aloitetaan esim. savutestien automatisoinnista Otetaan selvää, onko joku muu projekti/organisaatio käyttänyt vastaavaa välinettä vastaavassa projektissa Testausstrategia ja ihmisten sitoutuminen kuntoon automaatio ei vähennä testauksen suunnittelun tarvetta Mika Katara: Ohjelmistojen testaus,

27 Kuinka työkalun voi valita? Päämäärät Hankintasuunnitelma Ensimmäiset kokeilut Haastattelut useita vaihtoehtoja vertailu yksi vaihtoehto Vaihtoehtojen karsiminen Hankinta ja kokeilu Kokeiluprojekti Käyttöönotto Automatisoinnin kehittäminen Kuvan lähde: Jussi Niutanen. Symbian-sovellusten testauksen automatisointityökalut. Diplomityö, TTY, Sähkötekniikan osasto, Mika Katara: Ohjelmistojen testaus, Testiautomaatio prosessin eri vaiheissa Yksikkötestaus: Kehittäjien pitäisi huolehtia yksikkötestauksesta Kehittäjät eivät ole useinkaan kiinnostuneita testaamaan omaa koodiaan manuaalisesti manuaalinen testaaminen voidaan kokea tylsäksi tavaksi hukata paljon aikaa Tarvitaan apuvälineitä, jotka automatisoivat yksikkötestauksen mahdollisimman pitkälle mieluiten näiden apuvälineiden tulisi integroitua saumattomasti kehittäjien käyttämiin kehitysvälineisiin editorit, kääntäjät, IDE:t (Integrated Development Environment) Mika Katara: Ohjelmistojen testaus,

28 Useita kaupallisia ja ilmaisia työkaluja on saatavilla Yksi esimerkki ovat xunit-kehykset Niiden taka-ajatuksena on sälyttää kehittäjien harteille niin testien suunnittelu ja koodaaminen kuin ajaminen ja tulosten analysointikin Automaattiset regressiotestit saadaan kaupan päälle Mika Katara: Ohjelmistojen testaus, Integrointitestaus: Joitakin yksikkötestaustyökaluja voidaan hyödyntää myös integrointitestauksessa Ajurien ja/tai tynkien automaattinen generointi Ennen varsinaista integrointitestiä kannattaa testattavalle kokonaisuudelle tehdä savutesti, jolla selvitetään onko se kelvollinen etenemään integrointitestaukseen vrt. preintegraatio tämän savutestin automatisoinnilla voidaan säästää paljon turhaa työtä integrointitestauksessa Mika Katara: Ohjelmistojen testaus,

29 Automaation sukupolvet Erityisesti käyttöliittymän kautta testaavasta automaatiosta voidaan havaita eri sukupolvia Helppokäyttöisyys, ylläpidettävyys ja kyky löytää virheitä kehittyvät Seuraavassa testiautomaatio jaetaan viiteen sukupolveen Nauhoita ja toista Komentojonot Dataohjattu Avain- ja toimisanat (keywords, action words) Mallipohjainen Mika Katara: Ohjelmistojen testaus, (Järjestelmätestaustason) automaation lyhyt historia Structured Test Scripts Data-Driven Scripts Keywords, Action words Capture Replay, Spaghetti Scripts Ks. esim. Software Test Automation: Effective use of test execution tools By Mark Fewster and Dorothy Graham, Addison Wesley, Mika Katara: Ohjelmistojen testaus,

30 ja tulevaisuus? Model-based testing Automated test execution Manual testing Mika Katara: Ohjelmistojen testaus,