CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen (etu.suku@lut.fi) Kevät 2015
JATKUU VIIME KERRASTA
OHJELMISTOTUOTANTO JA OHJELMISTOTESTAUS Ohjelmistotuotannon prosessi Suunnittelu Määrittely Toteutus Tarkastus Käyttöönotto Ohjelmistotestauksen prosessi Esitestaus Testauksen suunnittelu, testattavuuden arviointi Testaus eri tasoissa, regressiotestaus Käyttöönotto / hyväksymistestaus / Betatestaus Hotfixien, laajennusten testaus
MENETELMIÄ Musta laatikko Valkea laatikko Harmaa laatikko Regressio Automaatio Rasitus (kuormitus) Prototyypit Käytettävyystestaus A/B Raja-arvoanalyysit Tutkiva testaaminen Ad Hoc, Savutestit Mallipohjainen testaus Suorituskyky
A/B-TESTAUS Käytettävyystestauksen muoto, jossa kaksi tai useampi verrokkiryhmä testattavana. Kumpi on parempi, A vai B? Tavoitteena löytää paras toteutus käyttöliittymälle tutkimalla asiakkaiden käyttäytymistä eri varianttien kanssa. Esimerkiksi painikkeiden sijoittelu, erilaiset sivustolayoutit jne 1000 käyttäjää, 500 käyttää A:ta ja 500 käyttää B:tä viikon, katsotaan kumpi asiakasryhmä on tyytyväisempi.
KUORMITUSTESTAUS Kuormitustestaus (load testing, myös stress testing) on testaustoiminnan muoto, jossa ohjelma laitetaan toimimaan suunnitellulla käyttäjämäärällä ja tarkastetaan että kaikki toimii edelleen oikein. Esimerkiksi verkkokauppa, joka on suunniteltu palvelemaan 250 yhtäaikaista käyttäjää. 250 automatisoitua virtuaalikäyttäjää, jotka laitetaan tekemään normaaleja verkkokaupan toimintoja 50 selailemaan tuotekatalogia 50 ostamaan ja tilaamaan tuotteita 50 tekemään muutoksia jo tehtyihin tilauksiin 50 muuttamaan henkilötietojaan 50 toistuvasti avaamaan ja sulkemaan verkkosivun, simuloiden satunnaista kävijävirtaa.
KUORMITUSTESTAUS Kuormitustestauksella on kolme keskeistä tehtävää Tunnistaa järjestelmän pullonkaulat Selvittää millaiseen maksimikapasiteettiin järjestelmä pystyy Tarkastella sitä, miten testattava laite selviytyy normaaleista käyttöolosuhteista. Pullonkauloilla taas tarkoitetaan mahdollisesti ongelmia aiheuttavia kohtia Palvelimien välisten yhteyksien kykyä selvitä raskaasta ja jatkuvasta liikenteestä Tapahtumien vasteaikoja suorittimen ja muistin ollessa kuormitettuna Levyjen luku- ja kirjoitusnopeuksien riittävyyttä. Tarkastellaan ja todennetaan palvelunlaatuvaatimuksia (Quality of Service, QOS). Tapa löytää deadlockit ja muistivuodot sekä ongelmat, joita ei tyhjäkäynnillä ilmene.
RASITUSTESTAUS Jos kuormitustestaus viedään vielä pidemmälle, voidaan puhua rasitustestauksesta (stress testing). Tässä tapauksessa kuormitustestaus viedään astetta pidemmälle, laittaen järjestelmä palvelemaan suurempaa käyttäjämäärää tai raskaampaa kuormitusta kuin mihin se on normaaleissa olosuhteissa suunniteltu. Tässä tapauksessa tavoitteena on löytää ehdoton yläraja normaalin toiminnan jatkumiselle. Esimerkiksi testataan miten palvelinverkko osaa suojautua palvelunestohyökkäyksiltä.
SUORITUSKYKY TESTAUS Suorituskykytestaus (performance testing) on rasitustestauksen kevennetty muoto. Testauksen tavoitteena on osoittaa, että järjestelmä suoriutuu sille annetuista tehtävissä määrittelyjen mukaisesti. Käytännössä tämä voi tarkoittaa esimerkiksi Järjestelmän vasteajat Maksimikäyttäjämäärät Käsittelykapasiteetti on vähintään sitä luokkaa, mitä vaatimusmäärittelyssä on määritelty.
VIRHEIDEN KYLVÄMINEN Virheiden kylväminen (fault seeding, bebugging) tarkoittaa tarkoituksellista virheiden lisäämistä lähdekoodiin. Virheiden kylvämisellä on kaksi keskeistä käyttötarkoitusta; Testata sitä miten hyvin käytössä oleva testaussuunnitelma ja tapaukset löytää virheitä Tilastollisesti arvioida ohjelmassa vielä olevien virheiden määrää.
VIRHEIDEN KYLVÄMINEN V o tarkoittaa koodissa olevien oikeiden virheiden määrää. V k koodiin tarkoituksella lisättyjen, eli kylvettyjen, virheiden määrää. Testien jälkeen merkitään löydettyjen kylvettyjen virheiden määrää arvolla V kl Löydettyjen oikeiden virheiden määrää arvolla V ol. Jos oletetaan, että testien löytämien kylvettyjen virheiden ja oikeiden virheiden suhde on sama, silloin V o / V ol = V k / V kl Koska yllä olevasta kaavasta tiedetään kaikki muut arvot paitsi V o, voidaan se laskea.
VIRHEIDEN KYLVÄMINEN Esimerkiksi jos kylvämme koodiin sata virhettä joista löydämme 65, ja samalla löydämme 125 muuta virhettä, saadaan kokonaisvirheiden määräksi V o / 125 = 100 / 65 V o = ( 100 / 65 ) * 125 V o = 192 koska 125 virhettä löydetty (V ol ), on testatussa koodissa arviolta vielä ~70 virhettä. Ongelma: Saatiinko kaikki kylvetyt virheet otettua pois korjatusta koodista? Mitkä olivat kylvetyn virheen aiheuttamia eikylvettyjä vikoja?
MUTAATIOTESTAUS Virheiden kylvämiseen perustuva malli, jossa luodaan erilaisia satunnaisesti viallisia versioita moduulista. Mahdollistaa testitapausten laadukkuuden arvioinnin: kuinka monta mutanttia otettiin kiinni? Myös vakaustestausta, kyky toipua virheistä, mahdollisuus havainnoida miten ohjelma käyttäytyy vikatiloissa.
TESTAUSAUTOMAATIO
TESTAUSAUTOMAATIO Testausautomaatio tarkoittaa testaustoiminnan muotoa, jossa ohjelman testaamista varten rakennetaan automaattityövälineitä testien tekemistä varten. Testausautomaation tavoitteena on ottaa joukko toistuvasti tehtäviä testitapauksia, ja rakentaa niiden nopeaa tarkastamista varten erillinen laite. Pohjimmaisena ajatuksena testausautomaation rakentamisessa on vapauttaa testaajat muihin tehtäviin etsimään vikoja uusista osista; testaajien ajankäytön kannalta ole järkevää käyttää joka päivä tuntia samojen perustestien tekemiseen. Toisaalta taas automaattitestit voivat olla tarkastuksia, jotka tietokone jätetään yön aikana tekemään, ja kehittäjät voivat aloittaa työpäivänsä läpikäymällä tarkastuksen tulokset ja korjaamalla moduulit joissa havaittiin ongelmia
TESTAUSAUTOMAATIO Ohjaamatonta, täysin satunnaisuuteen perustuvaa testausautomaatiota kutsutaan apinatestaukseksi. Työkalu antaa satunnaisia syötteitä käytössä olevalle järjestelmälle ja mikäli järjestelmä kaatuu, tallentaa virheen aiheuttaneen syötesarjan. Testausautomaatiolle kaikille otollisimpia kohteita ovat esimerkiksi moduulien rajapinnat tai verkkoprotokollan tarkastukset. Näissä tapauksissa testausautomaatti voidaan rakentaa lähettämään esimerkiksi joukko kutsuja moduuliin ja tarkastaa, että testattavan moduulin uusi versio reagoi käskyihin oikein. Toinen perinteinen käyttökohde testausautomaatiolle on ollut käyttöliittymä.
ORAAKKELIONGELMA Miten tietokoneohjelmalle opetetaan, että ohjelma jota se tarkastelee toimii väärin? Entä miten se tehdään kustannustehokkaasti? Ihminenkin on erehtyväinen; näyttää toimivan oikein!= toimii oikein Yleisesti: mitä kaikkea voidaan automatisoida siten, että ihmistä ei tarvita tarkastamaan tuloksia?
TESTAUSAUTOMAATIO Ensimmäisen sukupolven ja samalla pohjatason laitteet ovat nauhoittamiseen ja toistamiseen perustuvia laitteita, joissa tapahtuma tallennetaan skriptiksi. Joskus skripti tukee yksinkertaista virhetilanteiden havainnointia ja hallintaa. Toisen sukupolven toisen tason testausautomaatiossa testaus toteutetaan skripteinä, jotka reagoivat syötteidensä tuottamiin tuloksiin. Tasoina ajateltuna skriptien tärkein ero on uudelleenkäytettävyydessä ja kehittyneisyydessä. Sama testitapahtuma voidaan siirtää uudelle alustalle tai muokata toteuttamaan useita eri testejä.
TESTAUSAUTOMAATIO Kolmannen sukupolven automaatiotyökalut mahdollistavat korkeamman abstraktiotason toiminnan. Automaationhallintatyökalut eivät enää ole sovellusriippuvaisia. Testiskenaarioita, jotka osaavat itsenäisesti käyttää testattavan laiteen käyttöliittymää. Tällä tasolla voidaan eriyttää testisuunnittelut ja automaatiotestauksen toteutus toisistaan. Neljäs testaussukupolvi on mallipohjainen ympäristö. Tämä laajentaa kolmannen sukupolven konseptia luomalla pelkän ohjelman käytön ympärille kokonaisen ympäristömallin, jonka avulla voidaan testata järjestelmän ulkoista käyttäytymistä. High-end -testaustutkimuksen osa-alue.
KÄYTÄNNÖN ASIOITA TESTAUSAUTOMAATIOSTA Käyttöönotetaan testausautomaatio organisaatiossa, joka ei ole riittävän järjestäytynyt pystyäkseen tukemaan sitä. Laajennetaan automaatiota liian nopeasti, jolloin kaikkia ongelmia ei ehditä korjaamaan. Luodaan automaatiota huonoilla tai väärin perustein valituilla työkaluilla. Yritetään laajentaa automaatiota liian useaan käyttökohteeseen. Iteratiivinen kehitysmalli tekee liian suuria hyppyjä versioiden välillä, automaation rakentaminen ei onnistu. Testaustyökalujen käyttämiseen ei anneta riittävästi resursseja tai niiden käyttörajapintoja ei implementoida riittävällä tarkkuudella. Käyttäjille ei anneta tarpeeksi opetusta työkalujen käyttöön.
MILLOIN AUTOMATISOIDAAN? Yleinen ohje: silloin kun toistettavia testitapauksia on paljon ja testien ylläpitotarpeet vähäisiä. Käsin aina sama työmäärä. Automaatti on kallis rakentaa, toistot halpoja.
TESTAUSAUTOMAATIOSTA Kustannukset huomioidaan mutta säästöt työmäärässä tai erityisesti testauskattavuuden kasvussa jätetään huomioimatta. Automaatiotestauksen tuloksia ja sen löytämiä virheitä verrataan käsin suoritettavaan testaukseen. Testausta ei priorisoida, jolloin automaatiotestaukseen sidotut testitapaukset joutuvat epäreiluun vertailuun. Testausautomaation rakentamiseen projektin ympärille ei anneta riittävää budjettia. Ylimääräisiä kustannuksia kuten ylläpitoa ei huomioida kustannuksissa. Automatisoidulla testauksella ei etsitä uusia virheitä, vaan estetään vanhojen virheiden uudelleenesiintyminen!