6.3 Virheiden kylväminen - TUNI › ~tie21201 › s2011 › luennot › OHJ-3060... · Jatkuva integrointi käytännössä • Perustuu artikkeliin Martin Fowler & Matthew Foemmel:

OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 271

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 Vo:lla oikeiden ja Vk:lla kylvettyjen virheiden

kokonaismäärää sekä Vol:lla ja Vkl:lla löydettyjen oikeiden ja kylvettyjen virheiden määrää

• Oletetaan lisäksi, että Vo/Vol = Vk/Vkl

• Jäljellä olevien virheiden määrän arvioksi saadaan (Vol x (Vk/Vkl)) - Vol


• 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


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!


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ä


• Osaa myös lisätä ja poistaa continue- ja break-lauseitasilmukan 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 40 000 mutanttia, joista riitti jokaiselle harjoitustyöryhmälle omansa


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


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


• 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


• 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


Ohjelmointikielille tyypillisiä virheitä: C-kielen esimerkkejä

• Kommentin loppumerkki unohtunut:a=b; /* kommentti alkaac=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


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;

}


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


7. Ketterä testaus

Elämää on V-mallin ulkopuolella – eräs selvimpiä trendejä testauksessa on siirtyminen ketterämpiin ja vähemmän suunnitelmaohjattuihin prosesseihin.


• 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


– 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


• 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


Yksikkötestausta ketterästi: Test-DrivenDevelopment

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


• Menetelmä lyhyesti:– kirjoita testi– koodaa toteutus– siisti toteutus (refaktorointi)

• Entä muut mallinnus-, suunnittelu-, dokumentointi-, toteutus-ja testausmenetelmät?– niitä käytetään tarpeen mukaan, jos ne auttavat toimivan

ohjelmiston saavuttamisessa


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


– 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


– 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


• Testit– Tavoitteet:

• luottamuksen saavuttaminen toimivuuteen, toiminnan dokumentointi, suunnittelu…

– Sykli: • kirjoita testi, käännä, aja testit• kirjoita koodi, käännä, aja testit• siisti toteutus, käännä, aja testit, integroi, käännä, aja testit,

tsekkaa sisään versionhallintaan, kirjoita testi, ...

testit punaisella

testit vihreällä

Testauksen liikennevalot:


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


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


• 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


Jatkuva integrointi käytännössä

• Perustuu artikkeliin Martin Fowler & Matthew Foemmel: Continuous Integration, www.martinfowler.com

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


• 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


• 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


– 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


• 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


• 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

Department of Software Systems

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

Mika Katara: Ohjelmistojen testaus, 2011 302


ATDD-prosessi (iteratiivinen)muokattu, alkuperäinen Niklas Collin, Kilosoft


Project Manager

Customer/end-user

Test automation engineer

Chief engineer

Requirements

Executable tests (backlog)

Specify

Derived to

Implements


• 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!



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 osa-alueeseen


– 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

Ohjelmistotekniikka

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


Ohjelmistotekniikka

Tutkivan testauksen tyylilajit

• Freestyle• Sessiopohjainen• Turisti• Sissi• Käyttöskenaarioihin / käyttötapauksiin / käyttäjien tarinoihin

perustuva



Muutamia esimerkkejä ketterän testauksen työkaluista


TDD Agile acceptance testing

Tutkiva testaus

Järjestelmätestaus FIT, FitNesse

Robot Framework

toimistotyökalut

Integrointitestaus Jatkuvan integroinnin työkalut

Yksikkötestaus xUnit

(www.junit.org)

+ erilaisista pienistä apuohjelmista on usein hyötyä kaikillatestauksen tasoilla


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


• 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.


8.1 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


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


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


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


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


• 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


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ä


• 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


Testiautomaatio – erilaista ohjelmistosuunnittelua

• Testausautomaation toteutus on ohjelmistonkehitysprojekti; skriptit vaativat– Ohjelmointi- ja suunnittelutaitoja– Testaustaitoja– Dokumentointitaitoja– Ylläpitotaitoja

• Kuka testaa testiohjelmiston?


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


– ”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


vertailu

useita vaihtoehtoja

Kokeiluprojekti

Käyttöönotto

Automatisoinnin kehittäminen

Vaihtoehtojen karsiminen

Hankinta ja kokeilu

Hankintasuunnitelma

Haastattelut

Päämäärät

Ensimmäiset kokeilut

yksi vaihtoehto

Kuvan lähde: Jussi Niutanen. Symbian-sovellusten testauksen automatisointityökalut. Diplomityö, TTY, Sähkötekniikan osasto, 2005.

Kuinka työkalun voi valita?


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)


• 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”


• 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


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


Capture Replay,Spaghetti Scripts

Structured Test Scripts

Data-Driven Scripts

Keywords,Action words

(Järjestelmätestaustason) automaation lyhyt historia

Ks. esim. Software Test Automation: Effective use of test execution toolsBy Mark Fewster and Dorothy Graham,Addison Wesley, 1999.


Manualtesting

Automatedtest execution

Model-based testing

…ja tulevaisuus?

Documents

6.3 Virheiden kylväminen - TUNI › ~tie21201 › s2011 › luennot › OHJ-3060... · Jatkuva integrointi käytännössä • Perustuu artikkeliin Martin Fowler & Matthew Foemmel: