”Pieni haaste” (Myers 1979, mukailtu) Olkoon testattavana aliohjelma (tai metodi), joka on määritelty seuraavasti: ● Parametreinä annetaan kolme kokonaislukua, jotka ilmoittavat kolmion sivujen pituudet. ● Tuloksena aliohjelma ilmoittaa, onko kolmio tasasivuinen, tasakylkinen (kaksi yhtä pitkää sivua) vai erisivuinen. Yritä miettiä sellainen valikoima testitapauksia (todellisten parametrien yhdelmiä), jolla aliohjelman toiminnan oikeellisuus saataisiin mielestäsi hyvin testatuksi.Olisiko niillä jotain prioriteettijärjestystä, jos aika ei riittäisi kaikkien testitapausten ajamiseen? (Binderin kirjan (1999) alussa lainataan tätä esimerkkiä ja esitetään vähän laajempi Java-esimerkki.) Jos tämä tuntuu liian helpolta, niin vaaditaan aliohjelman ilmoittavan myös, onko kolmio suora-, tylppä- vai teräväkulmainen.

Haasteen ratkaisu (1/8) Oletetaan ensin, että aliohjelman saamat parametrit aina todella kelpaavat kolmion sivujen pituuksiksi, siis ovat positiivisia ja jokainen niistä on pienempi kuin kahden muun summa (kolmioepäyhtälö). Jos tämän katsotaan olevan kutsujan vastuulla, aliohjelmalla on oikeus palauttaa mikä tulos hyvänsä silloin, kun tämä ehto ei toteudu. Joissakin kielissä (ainakin Eiffelissä) voidaan todella määritellä tällainen esiehto, niin että järjestelmä tarkistaa sen automaattisesti jokaisen kutsuyrityksen yhteydessä ja aiheuttaa poikkeukseen, ellei ehto toteudu. Toisin sanoen aliohjelma ei tällöin voi saadakaan kelvottomia kutsuja.

Haasteen ratkaisu (2/8) On selvää, että tarvitaan vähintään yksi testitapaus kustakin vaihtoehdosta. Yksi tasasivuinen tapaus tuntuu riittävältä: on vaikea kuvitella sellaista ohjelmointivirhettä, että tulos riippuisi sivun pituudesta. Tasakylkisiä testitapauksia voisi olla 6: eripituinen sivu voi toisaalta olla joko pitempi tai lyhempi kuin muut ja toisaalta esiintyä joko ensimmäisenä, toisena tai kolmantena parametrinä. Myös erisivuisia testitapauksia voisi olla 6: suuruusjärjestyksen kaikki mahdolliset permutaatiot. Tarkat parametrien arvot eri testitapauksiin voidaan valita satunnaislukugeneraattorilla väliltä [1, MAXINT] siltä varalta, että aliohjelma sittenkin toimisi virheellisesti vain joillakin sivunpituuksilla.

Haasteen ratkaisu (3/8) Seuraavaksi oletetaan, että aliohjelman pitääkin itse tarkastaa, toteuttavatko parametrit kolmioepäyhtälön. Silloin tarvitaan myös virheellisiä testitapauksia. Tasasivuinen tapaus ei tietenkään voi olla virheellinen. Erisivuisia virheellisiä testitapauksia voisi olla 6 kuten kelvollisiakin: erona on vain se, että pisin sivu on liian pitkä. Tasakylkisiä virheellisiä testitapauksia riittäisi 3, koska eripituinen sivu ei voi olla liian lyhyt.

Haasteen ratkaisu (4/8) On mahdollista, että aliohjelma toimii virheellisesti jo kolmioepäyhtälön tarkastuksessa! Mikäli siihen tarvittavaa laskentaa ei ole suunniteltu huolellisesti, siinä voi tapahtua ylivuoto, jos kahden parametrin summa on suurempi kuin MAXINT. Siksi tarvitaan tällaisia, sekä kelvollisia että virheellisiä testitapauksia. Eiffelin esiehdon kirjoittamisessa voi tulla virheitä aivan samoin kuin aliohjelman sisällä olevassa tarkastuksessa. Siksi tällaiset testitapaukset ovat tarpeen myös siinä lähestymistavassa. Silloin kuitenkin nähdään automaattisesti, onko mahdollinen virhe esiehdossa vai aliohjelmassa.

Haasteen ratkaisu (5/8) Seuraavaksi oletetaan, että aliohjelman pitää itse tarkastaa, onko jokaisen parametrin arvo positiivinen. Silloin tarvitaan vähintään 3 uutta virheellistä testitapausta, joissa kussakin yksi parametri on virheellinen ja toiset kelvollisia. Mielellään kuitenkin kokeiltaisiin virheellisenä arvona sekä nollaa että jotakin negatiivista arvoa (tapauksia 2x). Mahdollisesti voitaisiin myös ottaa huomioon kelvollisten parametrien välinen suuruussuhde (tapauksia 3x) sekä tapaukset, joissa 2 tai 3 parametriä on virheellisiä. Monissa kielissä (esim. Pascalissa ja Adassa) voidaan määritellä tietotyyppi jonkin toisen tyypin osa-arvoalueeksi. Jos jokaisen parametrin tyypiksi määritellään [1.. MAXINT], tuollaiset virheelliset parametrit hylätään jo käännösvaiheessa --- testejä ei siis tarvita.

Haasteen ratkaisu (6/8) Jos käytetään staattisesti tyypittämätöntä ohjelmointikieltä (esim. Lispiä tai Smalltalkia), parametri voi olla virheellinen myös sillä tavoin, että se ei olekaan kokonaislukutyyppinen. Tällaisia virheellisiä testitapauksia on lisättävä edellisiin. Toisaalta Smalltalkissa ei voi tapahtua kokonaislukujen ylivuotoa, koska siinä kokonaislukujen esitys ei ole sidottu kiinteään pituuteen. Staattisesti mutta heikosti tyypitetyissä kielissä, esim. C:ssä ja C++:ssa, voidaan tyypinmuunnoksen kautta jonkin tyyppistä (esim. merkkijono) arvoa tai muuttujaa käsitellä, ikään kuin se olisi jotain muuta tyyppiä (tässä tapauksessa kokonaisluku). Tällaista tilannetta parametrin suhteen aliohjelma ei voi mitenkään todeta, joten sellaisilla virheellisillä testitapauksilla ei ole merkitystä. Jos parametri olisi liukulukutyyppiä, olisi syytä testata myös sellaisella parametrin arvolla, joka ei ole kelvollinen liukulukuarvo.

Haasteen ratkaisu (7/8) Priorisoinnissa ensimmäiset testitapaukset voisivat olla esimerkiksi seuraavat: ● yksi kelvollinen esimerkki kutakin 3 lajia ● yksi esimerkki, jossa kolmioepäyhtälö ei toteudu ● yksi esimerkki, jossa yksi parametri on 0 ● yksi esimerkki, jossa yksi parametri on negatiivinen ● yksi esimerkki, jossa kahden pienimmän parametrin summa on > MAXINT (edellisissä tapauksissa olkoon kahden suurimmankin parametrin summa < MAXINT) Näiden jälkeen voitaisiin testata seuraavilla: ● edellisistä tapauksista parametrien järjestyksen muut permutaatiot (ja tasakylkisen kolmion pituusvaihtoehdot) ● esimerkkejä, joissa kaksi tai kolme parametriä on virheellisiä ● kaksi lisätapausta, joissa ylivuoto voisi sattua Viimeiseksi voitaisiin testata kaikista em. tilanteista tapauksia, joissa on muita parametrien arvoja (satunnaisesti).

Haasteen ratkaisu (8/8) Entä jos vaaditaan aliohjelman ilmoittavan myös, onko kolmio suora-, tylppä- vai teräväkulmainen? Tällöin ensi näkemältä kelvollisten testitapausten määrä lähes kolminkertaistuisi --- ei ihan, koska tasasivuinen kolmio on välttämättä teräväkulmainen. Virheellisiä tapauksia ei tarvita lisää. Tarkemmin ajatellen tässä tilanteessa tulee myös lisää virheriskejä. Tulos voidaan nimittäin saada laskemalla, onko pisimmän sivun neliö yhtä suuri, suurempi vai pienempi kuin toisten sivujen neliöiden summa (Pythagoras). Jos tämä tehdään liian yksioikoisesti, ylivuoto voi sattua jo silloin, kun ainakin yksi parametri on √MAXINT tai suurempi. Jos taas laskenta tehdään liukuluvuilla, on mahdollista, että lähellä MAXINT:iä olevia kokonaislukuja ei voida esittää tarkasti. Tällöin hyvin vähän suorakulmaisesta poikkeava kolmio voidaan ilmoittaa suorakulmaiseksi. Kumpaakin virheriskiä voi pitää melko suurena, joten niiden testitapaukset saisivat korkean prioriteetin.

Huomio haasteesta Tässä on oletettu, että testattavan aliohjelman lähdekoodi ei ole käytettävissä, niin että mustalaatikkotestaus on ainoa mahdollisuus. Jos lähdekoodi on käytettävissä, niin ainakin tässä yksinkertaisessa tapauksessa on ilmeistä, että katselmointi olisi tehokkaampi menetelmä kuin normaali testaus. ● Sillä voitaisiin löytää ainakin suurin osa sellaisista virheistä, joiden paljastamiseen testitapaukset suunniteltiin. ● Toisaalta testitapauksillakin löydettäisiin mahdollisesti kaikki virheet. Entä jos aliohjelma on kirjoitettu tarkoituksellisen kierosti virheelliseksi? ● Virheiden löytäminen testitapauksilla voi olla hyvin vaikeaa tai lähes mahdotonta. ● Katselmoinnissa koodi voidaan helposti todeta ainakin epäilyttäväksi.