Ohjelmistojen testaus tekniikat, työkalut ja prosessit Mika Katara Ohjelmistotekniikan laitos Tampereen teknillinen yliopisto mika.katara@tut.fi Vaatimukset? Riskit Testaus Mika Katara: Ohjelmistojen testaus, 2011 1 Alkusanat Nämä luentokalvot ovat syntyneet vuosien 2003 2011 aikana, jolloin Ohjelmistojen testaus -kurssi on järjestetty TTY:llä uudistetussa muodossaan. Lähteinä on pääasiassa käytetty tämän kalvosarjan lopussa listattuja kirjoja, Maaret Pyhäjärven ja Erkki Pöyhösen koulutusmateriaaleja sekä Helsingin yliopiston vastaavan kurssin luentomateriaalia. Muihin lähteisiin viitataan kalvoissa tarpeen mukaan. Haluan kiittää niitä lukuisia ihmisiä, mukaan lukien kurssin henkilökunta ja opiskelijat, jotka ovat tätä materiaalia valmistellessani antaneet rakentavaa palautetta. Lisää palautetta otetaan ilomielin vastaan. Tampereella 30.8.2011 Mika Katara, Kol. 2:2-3 Mika Katara: Ohjelmistojen testaus, 2011 2
Kurssin tavoitteet Kurssin tavoitteena on oppia perusasiat ohjelmistojen testaamisesta ja luoda hyvä pohja lisätietojen hankkimiselle Edistyneempiä aiheita käydä läpi tarpeen mukaan Luentojen avulla pyritään luomaan laajaa kuvaa testauksesta, johon kuuluu paljon muutakin kuin vain testien suunnittelua ja niiden ajamista Harjoitustyössä tarkoitus on oppia käytännön tekemisen kautta Kurssin näkökulma pyrkii myös olemaan siinä mielessä avara, että eri sidosryhmien tarpeisiin kiinnitetään huomiota unohtamatta esim. testaustiimin johtajaa ja tuotteen loppukäyttäjää Mika Katara: Ohjelmistojen testaus, 2011 3 Vaikka valmis DI ei itse tekisikään testausta, tulee asia vastaan kaikenlaisissa ohjelmistokehitykseen liittyvissä työtehtävissä, sekä myyjän että ostajan roolissa, ja kaikilla organisaation tasoilla Jossain tapauksissa DI voi olla ainoa henkilö koko organisaatiossa, jolla on jotain tietämystä asiasta Hyvässä organisaatiossa löytyy osaajia, jotka osaavat oman alueensa työtehtävät hyvin, mutta ymmärtävät myös mitä muualla tapahtuu Yksikkötestausta tekevät yleensä enemmän teknisesti orientoituneet ihmiset ja järjestelmätestausta taas enemmän loppukäyttäjiä lähellä olevat henkilöt Mika Katara: Ohjelmistojen testaus, 2011 4
Kurssin lähestymistapa testaukseen Lähestymme testausta objektiivisesti ja korostamme erilaisia menetelmiä, työkaluja sekä spesifikaatioita, jotka sanelevat sen, mitä vastaan ohjelmaa testataan Tämä on usein käytännössä testaajan näkökulma testaukseen Tarkastelemme testausta osana ohjelmistotuotantoprosessia, joka määrittelee sen, missä vaiheessa mitäkin testataan Yksinkertaisuuden vuoksi on joitakin todellisuuden rikkaita yksityiskohtia on häivytetty, jotta näkisimme metsän puilta Testaus liittyy läheisesti myös projektinhallintaan, mikä tarkoittaa sitä, että ihmis- ja resurssilähtöinen (aikataulut, raha yms.) ajattelukyky on tärkeää Jälkimmäistä ovat enemmän projektin johdon näkökulmia Mika Katara: Ohjelmistojen testaus, 2011 5 Mitä tällä kurssilla ei kateta? Tiettyjen sovellusalueiden erityispiirteet Sulautetut, turvallisuuskriittiset, SOA, yms. Testauksen hallinnointi laajoissa ja hajautetuissa projekteissa Organisointi, roolit ja tiimien toiminta Yksittäiset projektitoiminnan mallit ja käytännöt Eräät testityypit kuten käytettävyystestaus, lokalisointi, yms. Testityökalujen kirjo Mika Katara: Ohjelmistojen testaus, 2011 6
Sisällys 1. Johdanto 2. Testitapaukset 3. Testaus osana ohjelmistoprosessia 3.1 Testauksen V-malli 3.2 Yksikkötestaus 3.3 Integrointitestaus 3.4 Järjestelmätestaus 3.5 Hyväksymistestaus 3.6 Tarvitaanko kaikkia testausvaiheita? 3.7 Milloin siirtyä vaiheesta toiseen? 3.8 Dokumentoinnista 3.9 Seuranta 4. Dynaamisen testauksen tekniikat 4.1 Tekniikat Hyödynnetäänkö ohjelman koodia vai ei? 4.2 Tekniikat Kuka testaa? 4.3 Tekniikat Mitä ohjelman osaa testataan? 4.4 Tekniikat Minkä tyyppisiä ongelmia etsitään? 4.5 Tekniikat Mitä pitää tehdä? 4.6 Tekniikat Mistä tiedetään onnistuiko testiajo vai ei? 5. Bugiraportoinnista 6. Ohjelmistojen mittaaminen 6.1 Kattavuusmitat Mika Katara: Ohjelmistojen testaus, 2011 7 6.2 Mutkikkuusmitat 6.3 Virheiden kylväminen 7. Ketterä testaus 8. Automaatio ja työkalut 8.1 Testiautomaatio kokonaisuutena 8.2 TTCN-3 8.3 UML ja testaus 8.4 Mallipohjainen testaus 9. Olio-ohjelmien testaaminen 10. Tietoturvan testaaminen 11. Staattisen testauksen tekniikat 11.1 Tarkastus 11.2 Katselmus 11.3 Läpikäynti 11.4 Ohjelman staattinen analyysi 12. Testausprosessin parantaminen 12.1 ISO-sertifiointi 12.2 CMM 12.3 TPI 13. Kurssin loppukaneetti Kirjallisuutta Mika Katara: Ohjelmistojen testaus, 2011 8
Testaus-aiheisia verkkosivuja Erityisesti ns. kontekstiohjattu-koulukunta on kunnostautunut tuottamalla paljon vapaasti käytettävissä olevaa materiaalia verkkoon Googlettaa voi vaikka nimillä Cem Kaner, James Bach ja Bret Pettichord Opetusmateriaalia löytyy myös osoitteesta http://www.testingeducation.org Myös www.stickyminds.com on vierailemisen arvoinen sivusto Suomenkielistä sivuja löytyy ainakin osoitteista http://testausosy.ttlry.fi/ http://www.testauskirja.com Mika Katara: Ohjelmistojen testaus, 2011 9 1. Johdanto Aloitetaan kurssi määrittelemällä, mitä olemme opiskelemassa. Mikäli testaamme osoittaaksemme järjestelmän virheettömyyden, kannattaa suunnitella sellaisia testitapauksia, joiden voi kuvitella toimivan oikein. Näin tekemällä saadaan helposti tuhlattua resursseja saavuttamatta mitään. Mutta miten tavoitteet sitten pitäisi asettaa? Mika Katara: Ohjelmistojen testaus, 2011 10
Eräitä näkökulmia siihen, mitä testaus on: Testaus on prosessi, jossa ohjelmaa suoritetaan tarkoituksena löytää siitä virheitä (Myers) Testaus on ohjelmiston laadun mittaamista (Hetzel) Oleellinen osa testausta on siihen liittyvän dokumentaation, työkalujen yms. (testware) käyttäminen ja ylläpito (Craig&Jaskiel) Testaus on tekninen tutkimus, joka tehdään laatuun liittyvän tiedon paljastamiseksi testauksen kohteena olevasta tuotteesta (Kaner) Testaus on ohjelmien rikkomista (Whittaker) Mika Katara: Ohjelmistojen testaus, 2011 11 Valitettavasti testaus ei voi osoittaa ohjelmiston virheettömyyttä Testaus ei myöskään sinällään paranna ohjelmiston laatua, se vain mittaa sitä Testaus ei ole ensisijaisesti sen varmistamista, että ohjelma toimii niin kuin sen pitäisi Toimivuuden varmistaminen ei ole hyvä lähtökohta testitapausten suunnittelulle, sillä ihminen näkee helposti vain sen mitä haluaa nähdä Parempi lähtökohta on: onnistunut testiajo on sellainen, joka aiheuttaa häiriön ohjelman toiminnassa Mika Katara: Ohjelmistojen testaus, 2011 12
Tällaisen testiajon seurauksena voidaan testattavasta kohteesta löytää virhe, jonka poistaminen vasta parantaa laatua Testaajan oletus: ohjelmassa on aina virheitä, jotka vain odottavat löytymistään Testataan, jotta voidaan osoittaa, että Ohjelma tekee, mitä sen ei pitäisi Ohjelma ei tee, mitä sen pitäisi Ohjelma toimii tavalla, jota määrittely ei mainitse Ehkä sen pitäisi mainita? Ohjelmisto on hankala ymmärtää, vaikeakäyttöinen, hidas tai toimii käyttäjän mielestä väärin Mika Katara: Ohjelmistojen testaus, 2011 13 Testauksessa yritetään yleensä löytää häiriöitä ohjelman toiminnassa Häiriöiden syiden tutkiminen johtaa vikojen löytämiseen ja luokitteluun, sekä virheiden korjaamiseen Tätä kautta ohjelmiston laatu paranee (Perinteiseen) testausprosessiin voidaan katsoa kuuluvan ainakin seuraavat työvaiheet: Testauksen suunnittelu Testitapausten luominen Testitapausten ajaminen Testiajojen tulosten arvioiminen ja raportointi Mika Katara: Ohjelmistojen testaus, 2011 14
Koska aina tulee kiire, tavoitteena on määritellä käytettävä prosessi siten, että sitä ei ruveta kiertämään asetettujen tavoitteiden saavuttamiseksi Usein testauksen työmäärät aliarvioidaan vielä pahemmin kuin muiden vaiheiden Ja kun tulee kiire, kumpi joustaa: koodaus vai testaus? Mika Katara: Ohjelmistojen testaus, 2011 15 Käytännönläheinen esimerkki siitä, miksi kaikkea ei voida testata: long add(int i, int j) { } Jos int-tyyppi vastaisi 16-bittistä kokonaislukua, ja funktio tuottaisi samoilla syötteillä aina saman tuloksen, on mahdollisia testitapauksia jopa 2 16 x 2 16 = 4294967296 kpl Jos ajatellaan yhden testitapauksen ajamiseen kuluvan viitisen sekuntia, kuluisi kyseisen funktion testaukseen noin 680 vuotta 680 testaajaa selviytyisi rinnakkaistetusta tehtävästä yhdessä vuodessa mikäli työskentelisivät kellon ympäri Mika Katara: Ohjelmistojen testaus, 2011 16
Entä auttaisiko automaatio? Mikäli yhden testin ajoaika saataisiin pudotettua esim. yhteen sadastuhannesosaan, kestäisi koko funktion testaus enää vain pari päivää ilman rinnakkaisuuden hyödyntämistä Valitettavasti tosielämän testikohteet ovat monimutkaisempi kuin ko. funktio, joten automaatiollakaan ei pitkälle pötkitä Esim. jokaisen int-tyyppisen parametrin lisääminen kasvattaa funktion testitapausten määrän 65536-kertaiseksi Realistisen ohjelman testitapausten määrä kasvaa hyvin nopeasti liian suureksi Mikäli joku väittää testaavansa kaiken, kannattaa kyseenalaistaa tämä väite Mika Katara: Ohjelmistojen testaus, 2011 17 Jos esimerkiksi 1960-luvulla uuden lentokoneen vaatimuksista 10% koski ohjelmistoa, niin 2000-luvulla luku voi olla 80% Myös vaatimusten kokonaismäärä kasvaa koko ajan Lisäksi ohjelmiston mutkikkuus kasvaa vielä nopeammin kuin sen koko Vaikka historiatietoa testauksen vaatimista työmääristä olisikin käytettävissä, on vaikea arvioida sitä, paljonko ohjelmiston koon kasvaminen niihin vaikuttaa Mika Katara: Ohjelmistojen testaus, 2011 18
Testauksen neljä koulukuntaa (Pettichordin ja Kanerin mukaan) Analyyttinen Tunnusmerkit: tekniset aspektit, täsmälliset menetelmät, mallintaminen Rutiini Tunnusmerkit: edistymisen mittaaminen, kustannukset ja standardit, automaatio, ulkoistaminen Laatu Tunnusmerkit: prosessit, standardit, kehittäjien valvonta ja projektien etenemisen hallinta Kontekstiohjattu Tunnusmerkit: ihmiset, sidosryhmille kaikkien tärkeimpien virheiden löytäminen, tutkiva testaus Mika Katara: Ohjelmistojen testaus, 2011 19 Analyyttinen kuva testauksesta Tehtävänä maksimoida kolmen ympyrän leikkauksen pinta-ala [Jorgensen 02]: Spesifioitu käyttäytyminen Ohjelman toteutettu käyttäytyminen Testaus on ohjelmistotiedettä Testattu käyttäytyminen Mika Katara: Ohjelmistojen testaus, 2011 20
Rutiinikäsitys testaamisesta Ohjelmistokehitys on liukuhihnatyötä ja testaus on liukuhihnan se osa, joka varmistaa, että vaatimukset tulee täytettyä Testaus on hallittu prosessi Mika Katara: Ohjelmistojen testaus, 2011 21 Laatukoulun käsitys testaamisesta Testauksen tehtävä on pitää kehittäjät kurissa; testaus varjelee käyttäjiä huonolta softalta Testaus on laadun varmistamista Mika Katara: Ohjelmistojen testaus, 2011 22
Kontekstiohjatun koulukunnan näkemys asiaan Testaajat ovat älykkäitä ihmisiä, jotka tuottavat tärkeää tietoa tärkeistä asioista Testaus on kehityksen yksi haara Mika Katara: Ohjelmistojen testaus, 2011 23 Miksi testataan? Cem Kaner (What is a Good Test Case? STAR East 2003) luettelee seuraavia syitä: Virheiden löytäminen Löydettyjen virheiden määrän maksimointi tärkeintä määrä, ei virheiden tyyppi tai sijainti Ohjelmiston ennenaikaisen toimituksen estäminen Autetaan johtajia tekemään päätös sen suhteen, onko ohjelmisto valmis toimitettavaksi vai ei Teknisen tuen kustannusten minimointi Arvioidaan, noudattaako toteutus spesifikaatioita Arvioidaan, noudattaako toteutus määräyksiä esim. viranomaisten taholta Mika Katara: Ohjelmistojen testaus, 2011 24
Varmistetaan yhteensopivuus muiden järjestelmien kanssa Varmistetaan oikeellisuus mahdotonta testauksella, mutta esim. jäljellä olevien virheiden määrää voidaan kyllä arvioida Minimoidaan turvallisuuteen liittyvät riskit Yritetään löytää tapoja käyttää ohjelmaa virheistä huolimatta yleensä tavoitteena on näiden käyttötapojen dokumentointi Arvioidaan laatua laatu on luonteeltaan usein moniulotteinen Mika Katara: Ohjelmistojen testaus, 2011 25 Varmistetaan laatua mahdotonta testauksella, mutta testaus voi tuottaa tärkeää tietoa, jonka avulla voidaan kyllä tehdä parempaa laatua luottamus järjestelmää kohtaan toivottavasti kuitenkin kasvaa testauksen ansiosta Mika Katara: Ohjelmistojen testaus, 2011 26
Testauksen kansanperinnettä Kaikissa ohjelmistokehityksen vaiheissa tehdään virheitä Mikäli virheitä halutaan välttää, täytyy välttää ihmisiä Mitä aikaisemmin virheet löydetään, sen parempi Mika Katara: Ohjelmistojen testaus, 2011 27 Pahimmassa tapauksessa viat ilmenevät vasta kun järjestelmä on jo toimitettu: Therac-25-röntgenhoitokone antoi liian suuria säteilyannoksia johtaen kuuden ihmisen kuolemaan ESA:n Ariane 5 raketin epäonnistunut laukaisu aiheutti noin seitsemän miljardin dollarin kustannukset Viallisten Pentium-suorittimien vaihtaminen maksoi Intelille yli 400 miljoonaa dollaria Kolmasosa USA:n puhelinverkosta on mykistynyt kahdesti (AT&T ja DCS) Ohjelmistovirheiden vuotuiset kustannukset USA:ssa arviolta n. 0,6% BKT:sta, eli n. $60 miljardia (The Economic Impacts of Inadequate Infrastructure for Software Testing, 2002) Tilanne tuskin sen parempi Euroopassa Mika Katara: Ohjelmistojen testaus, 2011 28
Huolellisesti tehdyssä ohjelmassa on arviolta noin viisi virhettä jokaista tuhatta koodiriviä kohti Windows XP:ssä oli koodia ilmeisesti n. 45 miljoonaa riviä, jolloin siinä on arviolta ainakin 225 000 virhettä Vistassa oli n. 60 miljoonaa riviä koodia Onneksi Windows osaa päivittää itsensä verkosta automaattisesti! Huom! Microsoftilla on 1:1 suhteessa kehittäjiä ja testaajia Käsi sydämellä: osaisiko joku tehdä saman homman paremmin kuin Microsoft? Mika Katara: Ohjelmistojen testaus, 2011 29 Asenneongelma vai oikeasti koiran virka? Onko koodaaminen kivempaa kuin testaaminen? riippuu keneltä kysyy Jos et osaa kehittää joudut testaamaan? jos et osaa testata joudut koodaamaan? Testaajat tuovat aina vain huonoja uutisia olisiko parempi, että asiakkaat toisivat ne? Ohjelmoijat eivät pidä testaajista koska nämä löytävät virheitä heidän ohjelmistaan entä jos virheet löytää toinen koodari? Mika Katara: Ohjelmistojen testaus, 2011 30
Asiakkaiden reklamaatiot kääntävät katseet testaajiin, mutta kehut suunnataan yleensä kehittäjille? kuka ne virheet alun perin teki? Onko testaajien tehtävä päättää, koska tuote on valmis toimitettavaksi asiakkaalle? julkaisen, enpäs julkaise, julkaisen, enpäs julkaise Mika Katara: Ohjelmistojen testaus, 2011 31 Käytännössä testaajalta vaaditaan enemmän kuin koodaajalta Tarvitaan kokonaiskäsitystä ongelmakentästä ja testikohteen arkkitehtuurista Usein tarvitaan salapoliisin taitoja testien tulosten analysointiin Kuinka testata ohjelmaa, josta ei ole olemassa ainuttakaan dokumenttia tai käyttöohjetta? tämä ei ole niin harvinainen tilanne kuin saattaisi olettaa Testikoodi on usein organisaation kannalta yhtä arvokasta kuin varsinainen sovelluksen koodi (automaattiset) regressiotestit mahdollistavat ohjelmiston ylläpidon ja laajentamisen sekä myös ketterän reagoimisen vaatimusten muuttumiseen Mika Katara: Ohjelmistojen testaus, 2011 32
Kumpi on organisaation kannalta pahempi tilanne: ei vielä valmista tuotetta vai valmis tuote, joka pilaa maineen? Fakta 1: testaaminen yhdessä virheiden etsimisen ja korjaamisen kanssa kuluttavat enemmän ohjelmistoprojektin resursseja kuin koodaus Mistä johtuu testauksen aliarvostus? Fakta 2: virheetön softa on kilpailuetu siinä missä käytettävyys tai suorituskyky Mika Katara: Ohjelmistojen testaus, 2011 33 Liian voimakas rajanveto testaajien ja kehittäjien välillä ei kuitenkaan hyödytä lopulta ketään Ohjelmistokehitys on tiimityötä sanan varsinaisessa merkityksessä Vaikka kaikkien testaajien ei tarvitsikaan osata ohjelmoida, on ohjelmointitaidoista yleensä todellista hyötyä On hyvä tietää millaisiin virheisiin kehittäjät sortuvat Testiautomaation kehittäminen on softankehitystä Toisaalta, vähemmän teknisesti orientoituneet testaajat voivat ymmärtää paremmin loppukäyttäjien tarpeita Mika Katara: Ohjelmistojen testaus, 2011 34
Mitä testaukselta voi vaatia? Ei voi vaatia Kaikkien virheiden löytämistä Laadun varmistusta Julkistamisen ajankohdan päättämistä Voi vaatia Tiedon hankkimista hyödyntää testaajia muuhunkin kuin vain virheiden paljastamiseen Kokonaiskäsitystä kehitettävästä järjestelmästä Toimivaa kommunikaatiota bugien myyminen kehittäjille Mika Katara: Ohjelmistojen testaus, 2011 35 Keskeisiä termejä Virhe (error, mistake) on ohjelmassa oleva poikkeama spesifikaatiosta Vika (fault, defect) voi aiheutua, kun virheellinen kohta suoritetaan tai kun pitäisi suorittaa jotain, mitä ei olekaan toteutettu Häiriö (failure) on järjestelmän ulkoisessa toiminnassa näkyvä tapahtuma, joka johtuu viasta Vika ei välttämättä näy järjestelmän toiminnassa ts. kaikki viat eivät johda häiriöön Bugi (bug) voi tarkoittaa mitä tahansa edellisistä Huom! Näitä termejä käytetään hyvin epäjohdonmukaisesti Mika Katara: Ohjelmistojen testaus, 2011 36
Dynaamisessa testauksessa ohjelmaa ajetaan sopivilla syötteillä Staattisessa testauksessa ei ohjelmaa suoriteta vaan yritetään löytää virheitä tutkimalla esim. sen dokumentaatiota tai lähdekoodia Dokumentaatio on softaa, joten sitä pitää testata Joidenkin mielestä tämä ei ole testausta sanan varsinaisessa merkityksessä Spesifikaatio kertoo, miten jonkin pitäisi tai ei pitäisi toimia Esim. vaatimusmäärittely on spesifikaatio toiminnalliselle määrittelylle, joka taas on spesifikaatio suunnittelulle, joka on spesifikaatio toteutukselle Mika Katara: Ohjelmistojen testaus, 2011 37 Testitapaus kuvaa syötteet, joilla testikohde pyritään saattamaan häiriötilaan Testijoukko, testitapausjakso (test suite) on joukko (loogisesti yhteenkuuluvia) testitapauksia Testiympäristö tarkoittaa sitä laitteisto- ja ohjelmistoympäristöä, minkä kanssa testikohde on tekemisissä, mukaan lukien rajapinnat, tyngät ja ajurit Testiympäristön määrittelyllä pyritään välttämään kyllä se ainakin eilen toimi mun PC:ssä tyyppiset ongelmat virheitä metsästettäessä Mika Katara: Ohjelmistojen testaus, 2011 38
Testwareen kuuluvat kaikki dokumentit ja tuotteet, jotka luodaan testausta varten kuten esim. testitapaukset ja testisuunnitelmat [Craig&Jaskiel 02] Validointi pyrkii varmistamaan, että olemme tekemässä oikeaa tuotetta Verifiointi pyrkii varmistamaan, että olemme tekemässä tuotetta oikein Joidenkin formalistien mielestä vain ns. formaali verifiointi on oikeaa verifiointia, testauksella kun ei voida osoittaa virheettömyyttä Mika Katara: Ohjelmistojen testaus, 2011 39 Testausstrategia on sotasuunnitelma, joka määrittelee testauksen laajuuden ja syvyyden, mitä testikohteen riskejä pyritään kattamaan testausprojektin aikana ja mitä ei Rakkaalla lapsella on monta nimeä: yhdestä ja samasta testausvaiheesta voidaan puhua esim. yksikkö-, moduuli- tai komponenttitestauksena SUT, system under test IUT: implementation under test, DUT: device under test, jne. Termejä funktio ja metodi käytetään tällä kurssilla vaihtelevasti tarkoittamaan samaa asiaa Mikäli tarkoituksena on korostaa oliotestauksen erityispiirteitä, pyritään käyttämään termiä metodi Mika Katara: Ohjelmistojen testaus, 2011 40
Positiivinen testaus yrittää varmistaa sen, että testattava järjestelmä tekee mitä sen pitäisi tehdä suorittamalla happy case -tyyppisiä, usein vaatimuksista johdettuja testitapauksia Negatiivinen testaus testaa niitä asioita, jotka voitaisiin lukea unhappy case -kategoriaan kuuluviksi; tilanteita, joista vaatimukset eivät yleensä sano mitään (tai vain hyvin ylimalkaisesti), virhetilanteita, yms., joilla yritetään rikkoa testikohde Mika Katara: Ohjelmistojen testaus, 2011 41 2. Testitapauksiin pohjautuvat testaus Dynaaminen testaus on testitapausten suunnittelua ja luomista sekä niiden ajamista ja tulosten analysointia. Koska testitapaukset sanelevat sen, mitä virheitä löydetään, kannattaa niiden laatuun panostaa. Mutta mistä hyvin määritelty testitapaus oikeastaan koostuu? Mika Katara: Ohjelmistojen testaus, 2011 42
Ennen testitapausten miettimistä pitää keksiä syy niiden olemassaololle Syyksi ei riitä se, että pomo käski varmistaa, että järjestelmä toimii oikein Tunnistetaan ne tilanteet ja asiat, joista pitäisi hankkia laatuun liittyvää tietoa Näiden miettimisessä vaatimusdokumentista, käyttäjien tarinoista (user story) yms. on paljon hyötyä Täytyy kuitenkin muistaa myös negatiisen testauksen näkökulma Joskus testaajan täytyy tukeutua pelkästään omaan ammattitaitoonsa, jos ei ole käytettävissä mitään kättä pidempää Mika Katara: Ohjelmistojen testaus, 2011 43 Hyvien testitapausten keksiminen on yleensä hankalaa Huonot testitapaukset voivat antaa ohjelmiston laadusta liian ruusuisen kuvan Se, että ohjelma näyttää toimivan niin kuin sen pitäisi, saattaa johtua vain siitä, että testitapaukset on valittu huonosti Liiketoiminnan kannalta hyvät testitapaukset voivat olla jopa arvokkaampia kuin itse testikohteen lähdekoodi Tyypillisesti 20% testitapauksista testaa normaalia toimintaa (positiivinen testaus) ja 80% epänormaalia toimintaa kuten virhetilanteita yms. (negatiivinen testaus) Koska testien ajaminen voi kestää huomattavan kauan, pyritään niiden määrää minimoimaan Mika Katara: Ohjelmistojen testaus, 2011 44
Minimointia voi tehdä suunnittelemalla testitapauksia, jotka kattavat mahdollisimman monta tutkittavaa tilannetta Yksi testitapaus voi siis kattaa useamman kuin yhden tilanteen, mutta tämä voi toisaalta hankaloittaa testitulosten analysointia Testitapaukseen suoritus jakaantuu yleensä neljään vaiheeseen: Alustus: testikohde valmistetaan testitapauksen suorittamiselle Allokoidaan resurssit, alustetaan tietokannat yms. Ajaminen: suoritetaan yksi testitapaus testikohteella Tuloksen evaluointi: verrataan järjestelmän ulostuloja testitapauksen odottamiin tuloksiin ja annetaan tuomio Puhdistus: vapautetaan alustuksessa varatut resurssit Mika Katara: Ohjelmistojen testaus, 2011 45 Tilanteesta riippuen testiajojen kestosta tulee tai ei tule projektin pullonkaula Testitapausten määrän minimointi voi olla ensiarvoisen tärkeää Nopeutusta voi yrittää saavuttaa myös automatisoimalla ainakin osan testiajoista vaikka automatisointiin jouduttaisiin satsaamaan paljon resursseja, kannattaa se yleensä tilanteissa, joissa samoja testitapauksia ajetaan useamman kerran kuten esim. regressiotestauksessa (esitellään myöhemmin) automatisointi voi myös vapauttaa aikaa mm. parempien testitapausten suunnitteluun Mika Katara: Ohjelmistojen testaus, 2011 46
Testitapauksen sisältö: Yksilöivä identiteetti Tyyppi Tarkoitus, esim. vaatimus tai käyttötapaus, johon testitapaus liittyy Esiehdot Syötteet Odotetut tulokset Jälkiehdot Ajohistoria (jos halutaan sisällyttää): aikaleima testin tulos, joka kertoo, vastasivatko tulokset odotuksia versioinformaatio testaaja Mika Katara: Ohjelmistojen testaus, 2011 47 Esimerkki testitapauksesta: Identiteetti: TT0001 Tyyppi: Toiminnallisuustesti Tarkoitus: Testataan pankkiautomaatin saldokysely-toimintoa, vaatimus VT0203 Esiehdot: Kortti on syötetty automaattiin, tilillä on 100 rahaa Syötteet: Painetaan saldokyselynäppäintä Odotettu tulokset: Automaatti näyttää ruudulla summan 100 Jälkiehdot: Automaatti palaa takaisin päävalikkoon 4,5 5,5 s kuluttua Ajohistoria: aikaleima: 22.9.2003 klo 15.55.03 testin tulos: Tulokset olivat odotetut versioinformaatio: Automaatin ohjelmistoversio 1.78 ja laitteistoversio 5.6 testaaja: Mika Katara Mika Katara: Ohjelmistojen testaus, 2011 48
testitapauksen elinkaari (abstraktio): ei määritelty määritelty virhe testitapauksessa, joka korjataan ilmeni häiriö ei ajettu ei häiriötä ajossa Mika Katara: Ohjelmistojen testaus, 2011 49