4.2 Tekniikat Kuka testaa?

Transkriptio

1 4.2 Tekniikat Kuka testaa? People-based Käyttäjätestit: ohjelmistoa testaa sen käyttäjä, joskus mukana myös toimittajan testaustiimin jäsen Alfa-testaus: käyttäjätesti järjestelmän toimittajan tiloissa Beta-testaus: käyttäjätesti asiakkaan tiloissa Sisällöllinen asiantuntijatestaus (subject-matter expert testing): ohjelmisto annetaan sellaisen henkilön testattavaksi (ei välttämättä käyttäjä), joka tuntee jonkin ohjelmiston toteuttaman osa-alueen kuin omat taskunsa Tuloksena löytyneitä vikoja, kritiikkiä ja joskus myös kehujakin Mika Katara: Ohjelmistojen testaus, Pariohjelmoinnin (à la extreme Programming) soveltaminen testaukseen: Tapa I: kaksi testaajaa testaavat yhdessä yhden tietokoneen ääressä ja vaihtavat koneenkäyttäjää aina välillä Tapa II: kehittäjä A luo testitapaukset kehittäjän B speksistä ennen kuin B toteuttaa speksin, ja toisin päin Bugi-kekkerit (bug bashes): toimittajan tiloissa hieman ennen ohjelmiston julkistusta järjestettävä esim. puoli päivää kestävä tilaisuus, johon kaikki työntekijät (myös ohjelmoijat, myyntimiehet, sihteerit ) voivat osallistua Onnistuminen riippuu varmasti paljon organisaatiosta Mika Katara: Ohjelmistojen testaus,

2 Eat your own dogfood: toimittaja ottaa omassa organisaatiossaan hyötykäyttöön ohjelmiston esiversion Vasta kun ohjelmisto on havaittu omassa käytössä tarpeeksi luotettavaksi, se toimitetaan asiakkaalle Ad hoc testaus (kokeilutestaus) Edellä kuvatut menetelmät eivät korvaa kokemusta ja intuitiota Kokenut testaaja tietää, mitkä ovat ohjelmoijille hankalia kohtia testaaja voi oppia tuntemaan yksittäisen ohjelmoijan heikkoudet Esim. mikäli tarkoituksena on testata päivämääräohjelmaa, voisivat järjestelmälliset testausmenetelmät pommittaa päivämääriä muotoa ja 31.6., mutta kokeilutestit sen sijaan voisivat testata erityisesti karkauspäivän toteutusta syötteillä ja Vrt. tutkiva testaus Mika Katara: Ohjelmistojen testaus, Tekniikat Mitä ohjelman osaa testataan? Coverage-based Funktiotestaus: testataan funktiot yksi kerralla Testataan jokainen funktio niin hyvin, että voidaan sanoa sen toimivan kuten pitäisi Kannattaa tehdä ennen monimutkaisempia testejä, joissa testitapaukset kattavat useampia funktioita Ominaisuustestaus (feature testing): testataan ominaisuuksia, jotka tyypillisesti on toteutettu usean eri funktion yhteistoimintana Menutestaus (menu tour): graafisen käyttöliittymän menut ja dialogit käydään läpi ja testataan kaikki valinnat Mika Katara: Ohjelmistojen testaus,

3 Logiikkatestaus: testaan ohjelman muuttujien välisiä riippuvuuksia Esim. mikäli muuttujan Ikä arvo on suurempi kuin 50 ja muuttujan Tupakoi arvo on True, muuttujan TarjoaHenkivakuutusta arvo tulee olla False Tavoitteena on testata jokainen looginen suhde ohjelman muuttujien välillä (mikä on usein kuitenkin mahdotonta) Tilapohjainen testaus: käydään läpi suuri määrä ohjelman mahdollisia tilamuutoksia ja tarkastetaan, että jokaisessa tilassa ohjelma hyväksyy vain oikeat syötteet ja siirtyy niiden seurauksena oikeaan tilaan Konfiguraatiokattavuustestaus: testataan ohjelmiston erilaisia konfiguraatioita (esim. laitteisto, muu ympäristö) ja mitataan kuinka suuri osa kaikista mahdollisuuksista on katettu Mika Katara: Ohjelmistojen testaus, Vaatimustestaus: testataan vaatimusmäärittelyssä mainitut vaatimukset yksitellen yrittäen näyttää, että ne joko on täytetty tai sitten ei Vaatimuskattavuusmatriisia voidaan hyödyntää testauksen kattavuutta mitattaessa Spesifikaatio-pohjainen testaus: testataan ohjelmiston spesifikaatioissa esitettyjä sellaisia vaatimuksia, joiden toteutumiseen voidaan vastata joko kyllä tai ei Spesifikaatioiksi voidaan laskea myös käyttöohjeet, mainokset yms. Mika Katara: Ohjelmistojen testaus,

4 Ekvivalenssiluokat Minimoidaan tarvittavien testitapausten määrää osittamalla ohjelman syöteavaruus ekvivalenssiluokkiin, joille pätee että kun jokin luokan edustaja aiheuttaa häiriön, myös mikä tahansa muu ko. luokan edustaja aiheuttaa saman häiriön kun jokin luokan edustaja ei aiheuta häiriötä, ei mikään muukaan ko. luokan edustaja aiheuta häiriötä Koko luokan testaamisen sijasta luotetaan siis siihen, että voidaan valita yksi edustaja Mika Katara: Ohjelmistojen testaus, Esim. kuuluisan kolmioesimerkin testauksessa voidaan ekvivalenssiluokaksi valita tasasivuiset kolmiot, joissa sivujen pituus > 0 luokasta voidaan valita edustajaksi esim. kolmio, jonka sivujen pituus on 5 ja oletetaan, että muita luokan tapauksia kuten sivun pituus 7 ei tarvitse testata koska jokaisesta luokasta tarvitsee testata vain yhtä edustaa, voidaan keskittyä luokkien etsimiseen ja itse testaukseen valittujen edustajien avulla Mika Katara: Ohjelmistojen testaus,

5 Ekvivalenssiluokkien identifiointi Valitaan jokin syöteavaruuden ehto, ja jaetaan se kahteen tai useampaan luokkaan Jokaista ehtoa kohden synnytetään kahdenlaisia luokkia, niitä joiden edustajat ovat laillisia syötteen arvoja ja niitä, joiden edustajat ovat laillisten syötearvojen ulkopuolella Muutamia suuntaviivoja ekvivalenssiluokkien valintaan: jos syöteavaruuden ehto määrittelee välin laillisia arvoja tyyliin kappalemäärä on väliltä 1-999, synnytetään kolme ekvivalenssiluokkaa: (1 kpl 999), (kpl < 1) ja (999 < kpl) Mika Katara: Ohjelmistojen testaus, jos ehto määrittelee arvojen lukumäärän tyyliin ajoneuvolla voi olla yhdestä kuuteen omistajaa, synnytetään yksi luokka vastaamaan laillisia arvoja ja kaksi luokkaa vastaamaan laittomia arvoja ei omistajaa ja enemmän kuin kuusi omistajaa mikäli ehto määrittelee joukon arvoja, joiden käsittelyn voi olettaa olevan erilainen, synnytetään jokaista arvoa kohti oma luokkansa sekä yksi luokka vastaamaan laitonta arvoa esim. ajoneuvo voi olla joka linja-auto, rekka, henkilöauto tai moottoripyörä synnyttää neljä laillisia arvoja vastaavaa luokkaa sekä luokan, joka vastaa laittomia arvoja esim. perävaunu tai muut ajoneuvot Mika Katara: Ohjelmistojen testaus,

6 mikäli kyseessä on ehdoton vaatimus tyyliin ensimmäisen kirjaimen pitää olla iso kirjain, luodaan kaksi luokkaa, toinen vastaamaan laillista arvoa iso alkukirjain ja toinen laitonta arvoa pieni alkukirjain mikäli on syytä epäillä, että kaikkia ekvivalenssiluokan edustajia ei käsitellä ohjelmassa samalla tavalla, pitää luokka jakaa edelleen niin moneen pienempää luokkaan kuin tarpeellista Kun jako luokkiin on tehty, luokkien edustajista luodaan testitapauksia laittomien testitapausten pitäisi testata vain yhtä laitonta ekvivalenssiluokkaa kerrallaan Mika Katara: Ohjelmistojen testaus, toisaalta, laillisia arvoja vastaavien uusien testitapausten pitäisi kattaa mahdollisimman monta laillista, mutta vielä kattamatonta ekvivalenssiluokkaa eräs vaihtoehto on luoda kaikkien ekvivalenssiluokkien, sekä laillisten että laittomien, kaikkia kombinaatioita vastaavat testitapaukset tuloksena kattavampi testaus, mutta hintana paljon suurempi määrä testitapauksia, joiden ajamiseen voi kulua liikaa aikaa Ekvivalenssiluokkien käyttökelpoisuus ei rajoitu ainoastaan syötteisiin, vaan tekniikkaa voidaan käyttää myös lähtien tulosten arvoalueista Mika Katara: Ohjelmistojen testaus,

7 Raja-arvoanalyysi Kokemus on osoittanut, että ohjelmoijat tekevät helposti virheitä muuttujien ja parametrien arvoalueiden (esim. ekvivalenssiluokkien) rajoilla esim. käytetään operaattorin sijasta operaattoria < tai silmukkamuuttujan alkuarvo on off by one silmukassa saatetaan pyöriä yksi kerta liian vähän Joukosta parametreja valitaan tyypillisesti kerralla yksi, jonka raja-arvoja testataan, muiden parametrien arvojen ollessa normaaleja (nominal) eli tiukasti arvoalueen (esim. ekvivalenssiluokan) sisällä Mika Katara: Ohjelmistojen testaus, Valitaan arvo-alueen minimiä (min) ja maksimia (max) sekä arvoja hieman suurempi kuin minimi (min+) ja hieman pienempi kuin maksimi (max-) vastaavat tapaukset Näin saadaan aikaiseksi 4n+1 testitapausta, jossa n on parametrien määrä (jälkimmäinen termi vastaa tapausta, jossa kaikki arvot ovat normaaleja) Raja-arvoanalyysi toimii parhaiten silloin, kun tarkasteltavana on joukko parametreja, joilla ei ole keskinäisiä riippuvuussuhteita ja jotka kuvaavat esim. lukumääriä tai fyysisiä suureita kuten lämpötilaa, painetta, nopeutta, painoa jne. Mika Katara: Ohjelmistojen testaus,

8 Esim. totuusarvoiselle tai loogista arvoa kuvaavalle parametrille ei yleensä voi eikä kannata tehdä raja-arvoanalyysiä Esimerkki fyysisten suureiden tärkeydestä: kesäkuussa 1992 Phoenixin kansainvälinen lentokenttä jouduttiin sulkemaan kun lentäjät eivät voineet tehdä tiettyjä säätötoimenpiteitä; instrumentit hyväksyivät korkeimmaksi mahdolliseksi ilman lämpötilaksi 120 F lämpötilan ollessa 122 F ( 50 C) Myös oletus riippumattomuudesta on tärkeä; mikäli näin ei voida olettaa, voivat tulokset jäädä laihoiksi Mika Katara: Ohjelmistojen testaus, Robustisuustestaus Yksinkertainen raja-arvoanalyysin laajennus Otetaan testitapauksiin mukaan myös arvot min- ja max+ eli arvot hieman alle alarajan ja hieman yli ylärajan Testitapauksia yhteensä 6n+1 Mitä ohjelma tekee, jos se saa syötteenä päivämäärän 32. toukokuuta? Entä mitä hissi tekee, jos sen suurin sallittu kuorma ylitetään? Robustisuustesteillä voidaan löytää virheitä esim. poikkeustenkäsittelystä Mika Katara: Ohjelmistojen testaus,

9 Worst case -testaus Mikäli luovutaan oletuksesta, että häiriöt eivät synny useiden samanaikaisten virheiden sattuessa, pitää pahimmassa tapauksessa kaikki mahdolliset kombinaatiot raja-arvoista testata Kun kaikkien parametrien raja-arvoista (min, min+, nominal, max-, max) arvoista otetaan karteesinen tulo, saadaan aikaiseksi 5 n testitapausta Raja-arvoanalyysin perusversion tuottamat 4n+1 testitapausta ovat luonnollisesti tämän osajoukko Testitapausten suuresta määrästä johtuen worst case -testaus kannattaa yleensä vain mikäli vaaditaan korkeaa luotettavuutta tai miten olisi robusti versio worst case testauksesta: 7 n testitapausta Mika Katara: Ohjelmistojen testaus, Tulosten ja muuttujien arvoalueiden hyödyntäminen Kuten jo edellä mainittiin, näitä menetelmiä ei kannata käyttää pelkästään syötelähtöisesti Virheitä löydetään myös käyttämällä niitä tulosten ja ohjelman käyttämien muuttujien arvoalueiden kanssa Esim. mikäli tiedetään, että tuloksen arvo on väliltä niin testataan syötteillä, jotka tuottavat tulokset 1, 2, 99 ja 100 Esim. mikäli silmukka voi pyöriä ympäri nollasta kymmeneen kertaan, testataan syötteillä, jotka saavat sen pyörimään 0, 1, 9 ja 10 kertaa Esim. testataan syötteillä joiden pitäisi tuottaa virheilmoituksia Mika Katara: Ohjelmistojen testaus,

10 Kombinatorinen lähestymistapa Edellä huomattiin, että mikäli halutaan testata kaikki mahdolliset ekvivalenssiluokkien kombinaatiot, kasvaa testitapausten määrä helposti liian suureksi toinen vaihtoehto olisi testata siten, että jokainen luokka tulee testattua vain vähintään kerran valitettavasti tämä ei ole kovin tehokasta virheiden löytymisen kannalta näiden kahden ääripään väliin jää käyttökelpoinen vaihtoehto: sen sijaan, että pyrittäisiin kattamaan kaikki mahdolliset kombinaatiot, katetaankin kaikki luokista muodostuvat parit tai kolmikot Mika Katara: Ohjelmistojen testaus, Esimerkki (mukailtu lähteestä [Pezzè&Young 07]): tarkoituksena testata kuvitteellista www-sivustoa erilaisissa ympäristöissä: Kieli Väri Näyttömoodi Fontti Näytön koko suomi monochrome grafiikka mini PDA englanti värikartta teksti standardi läppäri ranska 16-bit rajoitettu kaistanleveys dokumenttiriippuvainen täysikokoinen espanja True-color Mika Katara: Ohjelmistojen testaus,

11 Jos halutaan kattaa kaikki mahdolliset kombinaatiot, tarvitaan 432 testitapausta Mikäli esim. tekstin luettavuutta ruudulla arvioimaan tarvitaan ihminen, on 432 testitapausta useimmiten liian paljon Mikäli tyydytään kokeilemaan vain jokaista vaihtoehtoa kerran, tarvitaan vain neljä testitapausta Vaikka testitapaukset valittaisiinkin hyvin, jää testaus kovin ylimalkaiseksi Mikäli järjestelmään lisättäisiin uusia parametreja, esim. kaistanleveys, jälkimmäisessä tapauksessa voitaisiin selvitä lisäämättä uusia testitapauksia, mutta ensimmäisessä tapauksessa testitapausten määrä kasvaisi eksponentiaalisesti Mika Katara: Ohjelmistojen testaus, Kultainen keskitie: katetaan kaikki mahdolliset parit (parikattavuus) Kaikkien kombinaatioiden testauksessa tarvitaan jokaista kombinaatiota kohti oma testitapauksensa Nyt esim. testitapaus {ranska, 16-bit, teksti, standardi, PDA} kattaa useamman kuin yhden parin: (ranska, 16-bit), (teksti, standardi) jne. Kaikki parit pystytään esimerkkitapauksessa kattamaan 16 testitapauksella, jotka on listattu seuraavalla sivulla merkintä - tarkoittaa, että valinnalla ei ole parikattavuuden kannalta väliä esitetty ratkaisu on minimaalinen, ts. pienemmällä testitapausten joukolla ei ole mahdollista saavuttaa 100% parikattavuutta Mika Katara: Ohjelmistojen testaus,

12 suomi monochrome grafiikka mini PDA suomi värikartta teksti standardi täysikokoinen suomi 16-bit raj. kaistaleveys - täysikokoinen suomi True-color teksti dok. riippuvainen läppäri englanti monochrome raj. kaistaleveys standardi läppäri englanti värikartta grafiikka dok. riippuvainen täysikokoinen englanti 16-bit teksti mini - englanti True-color raj. kaistanleveys standardi PDA ranska monochrome - dok. riippuvainen täysikokoinen ranska värikartta raj. kaistanleveys mini PDA ranska 16-bit grafiikka standardi läppäri ranska True-color teksti - PDA espanja monochrome teksti standardi - espanja värikartta - mini läppäri espanja 16-bit raj. kaistanleveys dok. riippuvainen PDA espanja True-color grafiikka mini täysikokoinen Mika Katara: Ohjelmistojen testaus, Kattamalla parien sijaan kaikki mahdolliset kolmikot saadaan kattavampi testaus, mutta testitapausten määrä pysyy silti useimmiten kohtuullisena Koska parien tai kolmikkojen generointi voi olla kovin työlästä, on niiden etsimiseen kehitetty joukko algoritmeja ja työkaluja Ennen käyttöä kannattaa selvittää mahdolliset patenttikiemurat Mika Katara: Ohjelmistojen testaus,

13 Mikäli jokin tärkeä kombinaatio puuttuu 100 % parikattavasta testitapausten joukosta, kannattaa se siihen lisätä, vaikka se ei enää lisäisikään parikattavuutta Toisaalta, mikäli kombinaatioille on rajoituksia, tyyliin värivaihtoehto monochrome on laillinen vain kun näytön koko on PDA, voidaan ensin tuottaa kaikki parit ja poistaa sitten laittomat vaihtoehdot Koska poistettu vaihtoehto saattoi edustaa laillisiakin pareja, täytyy mahdollisesti lisätä uusia testitapauksia kattamaan tällaiset parit Lisätietoja: Mika Katara: Ohjelmistojen testaus, Tekniikat Minkä tyyppisiä ongelmia etsitään? Problem-based Riskiperustainen testaus: käytetään riskianalyysiä sen selvittämiseen mitä testataan seuraavaksi Testaus priorisoidaan sen perusteella, millä todennäköisyydellä jokin ohjelman ominaisuus ei toimi ja toimimattomuuden mahdollisilla seuraamuksilla Mitä suurempi riski johonkin ominaisuuteen liittyy, sen aikaisemmin ja täydellisemmin se pitää testata Mika Katara: Ohjelmistojen testaus,

14 Riskiperustaisen testauksen lisäksi pitää testata myös sellaisia alueita, joihin ei riskianalyysin perusteella pitäisi keskittyä Ikinä ei voi olla varma siitä, kuinka hyvin analyysi on tehty on olemassa riski siitä, että riskianalyysi on väärässä Mikäli jokin riski on jäänyt analyysissä huomaamatta, tulee toteutusta testattua tältä osin edes hieman Esim. kannattaa testata ajoitus- ja rinnakkaisuusriippuvaisia ominaisuuksia vaikka niihin ei riskianalyysissä olisikaan kiinnitetty huomiota Esim. mikäli tapahtuma A tapahtuu yleensä ennen tapahtumaa B, yritetään etsiä tilanteita, joissa B tapahtuukin ennen A:ta Mika Katara: Ohjelmistojen testaus, Saippuaoopperatestaus: laaditaan ryhmätyönä käyttötapaus, mutta liioitellaan yksityiskohtia muuten testaamatta jäävien kohtien kattamiseksi Ahto S. vuokraa auton työmatkalle kolmeksi päiväksi. Vuokrauksen seurauksena hänestä tulee autovuokraamon kanta-asiakas. Seuraavana päivänä hän pidentää vuokra-aikaa viikolla. Seitsemän päivää myöhemmin hän ilmoittaa, että auto on varastettu. Hän vaatii nyt kanta-asiakkaille kuuluvana etuna, että toinen auto toimitetaan hänelle paikan päälle, vaikka hän ei ollutkaan kanta-asiakas ennen vuokra-ajan alkamista. Toinen auto toimitetaan hänelle. Kahta päivää myöhemmin hän ilmoittaa, että varastettu auto on löytynyt; itse asiassa hän oli vain unohtanut mihin oli sen pysäköinyt. Hän haluaa nyt, että toinen auto tullaan noutamaan pois ja siihen liittyvä laskutus katkaistaan. Sitten vielä yksi juttu: Asiakas löysi varastetun auton kun peruutti sen kylkeen vara-autolla. Molemmat ovat siis nyt siis korjauksen tarpeessa. (Brian Marickia mukaillen) Mika Katara: Ohjelmistojen testaus,

15 4.5 Tekniikat Mitä pitää tehdä? Activity-based Skenaariotestaus: testataan testitapauksilla, jotka on johdettu käyttötapauksista (use case) Installaatiotestaus: asenna ohjelmisto eri tavoilla ja eri ympäristöihin Tarkasta mitkä tiedostot lisätään ja mitkä muuttuvat levyllä Toimiiko installoitu ohjelma? Mitä tapahtuu kun poistat asennuksen? Mika Katara: Ohjelmistojen testaus, Kuormitustestaus: kuormitetaan ohjelmistoa siten, että se tarvitsee paljon resursseja (paljon työtä, vähän aikaa) Tämä johtaa luultavasti häiriöön, jonka syiden penkominen saattaa johtaa sellaisten heikkouksien tunnistamiseen, jotka ovat relevantteja myös normaalikäytössä Stressitestaus: lisätään kuormaa vähitellen, kunnes ilmenee häiriö (esim. vasteajat kasvavat sallittua pidemmiksi) Luotettavuustestaus: pitkäkestoinen testi, jonka tarkoituksena on paljastaa vikoja, jotka jäävät nopeissa testeissä helposti huomaamatta Esim. karanneet osoittimet, muistivuodot, pinon ylivuodot yms. Mika Katara: Ohjelmistojen testaus,

16 Suorituskykytestaus: testataan kuinka nopeasti ohjelma toimii, jotta voidaan tarvittaessa optimoida Vikoja voi löytää, jos vertailee keskenään saman testiajon käyttämää aikaa eri kertoina Mikäli suorituskyky yllättäen huononee, on syytä epäillä virhettä virhe voi tällöin löytyä myös kolmannen osapuolen koodista esim. jos kyseessä on Java-ohjelma, voi äkillinen suorituskyvyn heikkeneminen kertoa myös virtuaalikoneen uuden version ongelmista Mika Katara: Ohjelmistojen testaus, Regressiotestaus: uudelleenkäytetään testitapauksia ja testataan niitä käyttäen muutosten jälkeen uudelleen Englanniksi regress = taantua Käytännössä eräs tärkeimmistä ja käytetyimmistä tekniikoista Muutamia käyttötapoja: virheen korjaamisen jälkeen pyritään etsimään tilanne, jossa korjaus ei toimi (bug fix regression) muutoksen jälkeen pyritään osoittamaan, että jokin vanha korjaus ei enää toimi (old bugs regression) muutoksen jälkeen testataan huomattava osa ohjelmistoa sen osoittamiseksi, että jokin osa mikä on ennen toiminut ei enää toimi (side-effect/stability regression) Mika Katara: Ohjelmistojen testaus,

17 Savutesti (smoke testing): regressiotestauksen erikoistapaus, jonka tarkoituksena on osoittaa, että ohjelmiston uusi versio (esim. uusi buildi) ei ole kelvollinen testattavaksi Useimmiten automatisoitu ja standardoitu testi, jolla testataan perustoiminnallisuutta, jonka voi olettaa toimivan keskitytään laajuuteen eikä syvyyteen Esim. mikäli buildiin on linkitetty väärä tiedosto, voi virheen löytää savutestin avulla nopeasti Tarkoituksena ei siis varsinaisesti ole virheiden löytyminen Kannattaa suunnitella yhteistyössä kehittäjien kanssa Testitapaukset yleensä osajoukko regressiotestauksessa käytetyistä Mika Katara: Ohjelmistojen testaus, Savutestin voi tehdä joko kehittäjä tai testaaja tärkeää on tehdä se samassa ympäristössä kuin missä sen jälkeiset testit ajetaan Mikäli vain mahdollista, savutestit kannattaa automatisoida, koska ne joudutaan yleensä toistamaan usein Mika Katara: Ohjelmistojen testaus,

18 4.6 Tekniikat Mistä tiedetään onnistuiko testiajo vai ei? Evaluation-based Vertaaminen spesifikaatioon tai muuhun auktoriteettiin Mikäli eroja löytyy, kyseessä on luultavasti häiriö Vertaaminen talletettujen tulosten kanssa Verrataan esim. regressiotestauksessa tuloksia edellisen ajokerran tuloksiin Jos edelliset olivat oikeita, ja nyt saatiin eri tulos, saattaa kyseessä olla häiriö Mika Katara: Ohjelmistojen testaus, Heuristinen johdonmukaisuus: Ohjelman pitäisi toimia samoin kuin ennenkin kuten muiden ohjelmien vastaavassa tilanteessa kuten ihmiset sanovat sen toimivan (ohjelman pitäisi toimia kuten me luulemme käyttäjien haluavan sen toimivan) sisäisesti johdonmukaisesti, esim. virheenkäsittely on toteutettu samantyyppisissä funktioissa samalla tavalla kuten sen ilmeinen tarkoitus vaatii Mikäli jossakin em. kohdassa havaitaan epäjohdonmukaisuutta, voi kyseessä olla häiriö tai sitten tietoinen suunnittelupäätös Mika Katara: Ohjelmistojen testaus,

19 Oraakkelitestaus Jotta testitapauksen dokumentoinnista olisi jotain hyötyä, pitää sen sisältää odotettavissa olevat tulokset Miten testitapaukseen voidaan liittää tieto siitä, mitä ohjelman pitäisi tehdä annetuilla syötteillä? kaikkea ei ole kuitenkaan speksattu Käytetään oletusta, jonka mukaan ns. testioraakkeli antaa aina oikean tuloksen Testitapauksessa määritellyillä syötteillä oraakkeli tuottaa odotettavissa olevat tulokset Käytännössä oraakkeli voi olla esim. järjestelmän aikaisempi ja luotettavaksi havaittu versio tai asiantunteva käyttäjä ihminen ei yleensä voi toimia oraakkelina kovinkaan monimutkaisissa tapauksissa Mika Katara: Ohjelmistojen testaus, Toiminnallinen vs. ei-toiminnallinen testaus Vaatimukset voidaan jakaa karkeasti toiminnallisiin ja eitoiminnallisiin Esimerkkejä ei-toiminnallisista vaatimustyypeistä: suorituskyky, tietoturva, käytettävyys jne. Yleensä testauksessa käytettävät tekniikat riippuvat voimakkaasti siitä, minkä tyyppisiä vaatimuksia on tarkoitus testata Testiautomaation soveltuvuus täytyy miettiä tapauskohtaisesti Esim. kuormitus- vs. käytettävyystestaus Mika Katara: Ohjelmistojen testaus,