4.2 tekniikat – kuka testaa? - tunitie21201/s2011/luennot/ohj-3060_2011_171-208.pdf · •...

OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 171

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


• 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


• 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 30.5. ja 31.6., mutta kokeilutestit sen sijaan voisivat testata erityisesti karkauspäivän toteutusta syötteillä 28.2. ja 29.2.

– Vrt. tutkiva testaus


4.3 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


• 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


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


• 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


– 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


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


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


• 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


• 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


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


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


– 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


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


• 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 5n 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: 7n

testitapausta…


• 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ä 1..100 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


• 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


• 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


• 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


• 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


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


• 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


• 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: www.pairwise.org


4.4 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


• 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


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


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?


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


• 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


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


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


– 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


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ö


• 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


• 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


Toiminnallinen vs. ei-toiminnallinen testaus

• Vaatimukset voidaan jakaa karkeasti toiminnallisiin ja ei-toiminnallisiin– 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

4.2 tekniikat – kuka testaa? - tunitie21201/s2011/luennot/ohj-3060_2011_171-208.pdf · •...

Documents