TIE-21200 Ohjelmistojen testausotekn/nykyinen/materiaali/testauskalvot-otekn.pdf · – Ehtolauseet, silmukat, hypyt • Testitapauksia kannattaa valita sen mukaan, että mahdollisimman

Ohjelmistotekniikka1(507)

Ohjelmistojen testaus

Mika Katara, Matti Vuori ja Antti Jääskeläinen

Tampereen teknillinen yliopisto, Tietotekniikan laitos

25.8.2014

Ohjelmistojen testaus, 2014

OhjelmistotekniikkaOhjelmistojen testaus, 2014 15(507)

Mitä testaus on? Erilaisia näkökulmia

• 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)– Testaus tuottaa tietoa laadusta päätöksentekoa varten

(useat)


• Valitettavasti testaus ei voi osoittaa ohjelmiston virheettömyyttä

• Testaus ei myöskään sinällään paranna ohjelmiston laatua, se vain mittaa sitä ja tuottaa tietoa sen laadusta– Tilanteen seuraamiseksi, päätöksentekoa varten

• 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

Tavoitteena virheiden löytäminen 1/3


• 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



• Löydettyjen virheiden korjaus ohjelmassa on ensiaskel laadun parantamisessa.– Se parantaa heti tuotetta.

• Voidaan myös selvittää, mistä virheet johtuvat ja vaikuttaa niiden "juurisyihin" – oliko kyse esim. määrittelyn, suunnittelun vai toteutuksen ongelmista? Tehdäänkö niissä jotain huonosti?– Tällä selvittelyllä voidaan parantaa toimintaa ja vähentää virheitä

jatkossa.

• Jokainen testauksen tuottama tieto virheestä on mahdollisuus oppia.


Ohjelmistotekniikka29(507)Ohjelmistojen testaus, 2014

Missä vaiheessa projektia viat syntyvät?

Kuva: Timo Malm, VTT. Data origin: Capers Jones. Software quality in 2008: A survey of the state of the art.


Kaikkea ei voida testata 1/3

• 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 216 x 216 = 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


• 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

100%

Test

ed



• 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



Keskeisiä termejä 1/6

• Virhe (error) 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


• Dynaamisessa testauksessa ohjelmaa ajetaan sopivilla syötteillä

• Staattisessa testauksessa ei ohjelmaa suoriteta vaan yritetään löytää virheitä tutkimalla esim. sen lähdekoodia tai dokumentaatiota– 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 kertoo, mitä vaatimuksia ohjelman

pitäisi täyttää, luokan dokumentaatio kertoo, miten luokan pitäisi toimia



• Testattava asia (test condition) kuvaa sen, mitä ollaan tekemässä• Testitapaus (test case) kuvaa syötteet, joilla testikohde pyritään

saattamaan häiriötilaan sekä odotetut tulokset• Testiproseduuri kuvaa ne stepit, joilla testitapaus suoritetaan.

Käytännössä kuvataan osana testitapausta.• Testijoukko, testitapausjakso (test suite) on joukko (loogisesti

yhteenkuuluvia) testitapauksia• Testiympäristö tarkoittaa sitä laitteisto- ja ohjelmistoympäristöä,

jonka 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ä– Tärkeää vastata käyttäjien / tuotantoympäristöä– Useita erilaisia


Ohjelmistotekniikka

• 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

• Kattava ISTQB:n testaussanasto löytyy suomeksi täältä:http://www.fistb.fi/sites/fistb.ttlry.mearra.com/files/istqb_sanasto.pdf

56(507)Ohjelmistojen testaus, 2014


http://www.fistb.fi/sites/fistb.ttlry.mearra.com/files/istqb_sanasto.pdf

http://www.fistb.fi/sites/fistb.ttlry.mearra.com/files/istqb_sanasto.pdf

Ohjelmistotekniikka

• Pieni testi ohjelman käyttäytymiselle– Ajatus asiasta, jota testataan: miten toimii laskimen jakolasku?– Ajatus hyvästä syötteestä: kokeillaan jakolaskua nollalla– Ajatus tuloksesta: virheilmoitus, ei saa kaatua, jotain muuta

• Suoritetaan joko mietityllä tavalla tai annetaan testaajan valita, miten suoritus tehdään

• Voidaan suunnitella systemaattisesti joukko niitä ennen suoritusta

• Tai luoda sellainen "lennossa"• Tai niitä voidaan generoida automaattisesti softan

komponenttien tyypin tai softan toimintaa kuvaavan mallin perusteella

58(507)Ohjelmistojen testaus, 2014

Testitapaus pähkinänkuoressa


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

Testitapausten pitää olla haastavia


• Testitapaukseen suoritus jakaantuu yleensä neljään vaiheeseen:– Alustus: testikohde valmistetaan testitapauksen suorittamiselle

• Allokoidaan resurssit, alustetaan tietokannat yms.– Suorittaminen: suoritetaan yksi testitapaus testikohteella– Tuloksen evaluointi: verrataan järjestelmän ulostuloja

testitapauksen odottamiin tuloksiin ja annetaan tuomio– Puhdistus: vapautetaan alustuksessa varatut resurssit

Testitapauksen rakenne ja sisältö 1/3


3.2 Yksikkötestaus

• Unit testing, module testing – monta nimeä• Testataan jokainen ohjelman yksikkö erikseen

– Yksikkö voi olla moduuli, luokka, prosessi tms.

• Yksikkötestaus on yleensä osa yksikön toteutusvaihetta– Yksikön koodaaja testaa oman toteutuksensa

• Yleensä tieto virheistä jää vain toteuttajalle– Koska virheillä on tapana kasautua, voitaisiin tämän

tiedon avulla kohdistaa testausta paremmin– Toisaalta ohjelmoijat voivat osoittaa testaajille

järjestelmän vaikeat kohdat muutenkin– Mitä pikemmin yksikön toteutus testataan, sen parempi


• Yksikkötestauksen osa-alueet:– Rajapinnat – tärkeintä kaikenlaisille yksiköille– Yksikön käyttämät tietorakenteet (ajattele vaikka API:a, joka

toteuttaa jonkinlaisen puurakenteen)– Suorituspolut ja silmukat – käydäänkö kaikilla poluilla oikein,

loppuuko silmukka oikein– Virhetilanteiden käsittely– Raja-arvot

• Testaus tapahtuu useimmiten lähdekooditasolla – halutaan "varmistaa", että kaikki koodi toimii hyvin

• Yleensä suositaan rajapintoja näkymänä, koska se on stabiilia – ei vaarassa tulla pian refaktoroiduksi toisin kuin toteutuksen detaljien.

Osa-alueita


Rajapintojen testaaminen 1/2

• Rajapinta koostuu yleensä funktioista, joiden parametreja ja paluuarvoja käytetään tiedonvälitykseen

• Rajapintojen toimivuus on yleensä syytä testata ensimmäiseksi– Ne määrittävät yksikön toiminnan ulospäin– Jos rajapinnat eivät toimi, voi muiden testien suorittaminen olla

hankalaa ellei jopa mahdotonta– Kun koodia kehitellään, rajapinta voi pysyä samana, mutta toteutus

muuttuu – rajapintatestejä ei tarvitse muuttaa

• Näihin liittyviä ongelmia:– Parametrien määrä ja järjestys– Parametrien ja paluuarvojen tyypit– Muutetaanko sellaisen parametrin arvoa, jonka arvoa ei saisi muuttaa?– Onko globaali data määritelty yhtenevästi kaikkialla ohjelmassa?


• Käytettävästä ohjelmointikielestä riippuen hyvä kääntäjä huomaa suurimman osan em. virheistä– Valitettavasti nykyään niin suositut dynaamiset skriptikielet ovat

tässä suhteessa huonossa asemassa

• Kääntäjä ei sen sijaan yleensä pysty huomaamaan sitä, tulkitseeko sekä kutsuja että kutsuttava parametrin/paluuarvon samalla tavalla– Esim. toinen luulee arvon tarkoittavan senttejä ja toinen tuumia

(tämän kaltaisen virheen takia NASA on menettänyt yhden avaruusluotaimen)

“NASA lost a $125 million Mars orbiter because a Lockheed Martinengineering team used English units of measurement whilethe agency's team used the more conventional metric systemfor a key spacecraft operation, according to a review finding released Thursday.” – “Metric mishap caused loss of NASA orbiter”, CNN, September 30, 1999

Rajapintojen testaaminen 2/2


Tietorakenteiden testaaminen 1/2

• Yksikön toteuttamat (lokaalit) tietorakenteet ovat virheherkkiä• Myös yksikön käyttämien, jossain muualla toteutettujen

tietorakenteiden vaikutukset, tulisi testata yksikön testauksen yhteydessä– Tyyppivirheet– Oletusarvojen alustukset– Muuttujien nimien oikeinkirjoitus– Tietotyyppejä käytetään yhtenevästi– Yli- ja alivuodot, poikkeukset

• Hyvä kääntäjä huomaa jälleen ainakin osan näistä virheistä• Tietorakenteisiin kannattaa kiinnittää huomiota myös koodin

tarkastuksissa


• Testaus usein rajapintojen testauksen "sivutuotteena":– Funktion testaus jollain syötteellä. Toimiiko se oikein?– Sitten: onko tietorakenteet päivitetty tai purettu kuten pitää.

• Aina kun on mahdollista, kannattaa käyttää valmiita, hyvin testattuja tietorakenteita– Kielten ja ympäristöjen vakiokirjastot turvallisimpia – Esim. C++:n Standard Template Library (STL), see http://

en.wikipedia.org/wiki/Standard_Template_Library

Tietorakenteiden testaaminen 2/2

http://en.wikipedia.org/wiki/Standard_Template_Library

http://en.wikipedia.org/wiki/Standard_Template_Library


Suorituspolku- ja silmukkatestaus 1/3

• Koodin haarautumiskohdat ovat virheherkkiä– Ehtolauseet, silmukat, hypyt

• Testitapauksia kannattaa valita sen mukaan, että mahdollisimman monta kriittistä suorituspolkua yksikön läpi tulee testattua– Valitaan esim. funktion syötteeksi sellaisia arvoja, että silmukoita tulee

kierrettyä eri tavoilla• Testattavien suorituspolkujen joukkoon kannattaa valita erityisesti

niitä, joissa voisi todennäköisesti syntyä virhetilanne (esim. syötteen arvosta riippuen)

• Silmukoita testattaessa kannattaa erottaa toisistaan yksinkertaiset, sisäkkäiset ja peräkkäiset silmukat

• Myöhemmin tutustutaan tekniikoihin, joilla yksinkertaisia silmukoita voidaan testata– Esim. testitapaukset keskittyvät silmukkamuuttujan raja-arvoihin


Virhetilanteiden testaaminen 1/2

• Virhetilanteiden käsittely jää usein vähälle huomiolle ohjelman suunnittelussa

• Valitettavasti myös virhetilanteiden testaaminen on silloin yleensä lapsipuolen asemassa– Vaikka ohjelma muuten olisikin suunniteltu testausystävälliseksi,

virheidenkäsittely ei välttämättä ole sitä

• Tuloksena– Ohjelma, joka ei hallitse pieniäkään häiriöitä– Ohjelman antamat virheilmoitukset voivat olla käyttäjän kannalta täysin

hyödyttömiä tai jopa harhaanjohtavia

• Mitä myöhemmin virhe löytyy, sen enemmän sen korjaaminen maksaa – tämä periaate pätee erityisen hyvin virhetilanteiden tapauksessa

• Huonosti tehty virheenkäsittely voi vaarantaa myös tietoturvan (tähän palataan myöhemmin)


• Virhetilanteiden testauksen muistilista:– Onko virheenkäsittely tehty oikein?

• Onko virheestä toipuminen mahdollista?– jos ei, kaadetaanko ohjelma käyttäjäystävällisesti?

– Onko virheenkäsittely tehty siten, että käsittelyyn ylipäänsä päästään vai kaatuuko ohjelma jo ennen sitä?

– Onko virheilmoitus ymmärrettävä?– Vastaako virheilmoitus tapahtunutta virhettä?– Auttaako virheilmoitus käyttäjää paikallistamaan virheen syyn ja

pääsemään eteenpäin? – Ovatko virheilmoitukset yhtenevät kaikissa yksiköissä?

Virhetilanteiden testaaminen 2/2


Raja-arvojen testaaminen

• Muistilista:– Parametrien ja paluuarvojen raja-arvot– Silmukoiden pyörimiskertojen raja-arvot– Tietorakenteisiin liittyvät raja-arvot

• Esim. kasvaako ja pieneneekö dynaaminen tietorakenne oikein silloin kun muistia todella varataan tai vapautetaan

• Raja-arvo- analyysiä käsitellään myöhemmin tarkemmin


Yksikkötestauksen toteuttaminen 1/4

• Lyhyitä selkeitä testifunktioita ja niissä yksinkertaisia tarkistuksia– Testikehyksen määrittelemät ”älykkäät” assertiot (xUnit-

työkaluissa paljon erilaisia), jotka tuottavat raportoinnin. Kielten omia assertteja ei pidä käyttää testauksessa – usein ne keskeyttäväkin testiajon, mikä ei ole järkevää.

– Assertteja ei laiteta tuotantokoodiin, vaan sitä testaavaan testikoodiin (tuotantokoodissa ne eivät ole testausta, vaan sekaisin menneen ohjelman keskeyttämistä varten)

– … alla pseudokoodiaTEST_TYPE test_square_root() {

double result = my_sqrt(x);ASSERT_TRUE((result * result) == x); // Huom. Pieni bugi testikoodissa (mikä?) – yksinkertaistuksen vuoksi…

}


• Koska yksiköt eivät yleensä voi toimia itsenäisesti, vaatii niiden testaaminen apukoodin kirjoittamista, jota käytetään vain testauksessa– Vaikkapa rutiineja, jotka palauttavat mukamas netistä luetun

tiedoston sisällön

• Testikoodi on koodia siinä missä testattavakin koodi– Se on tehtävä ja dokumentoitava vähintään yhtä huolellisesti – Myös testikoodia on testattava ja ylläpidettävä– Englanninkielinen termi ”scaffolding” eli rakennusteline kuvaa

hyvin testikoodin suhdetta testattavaan koodiin• Testikoodi "ympäröi" tuotantokoodia, heijastellen sen

rakennetta (AddBalance(amount) <> testAddBalance())



• Tärkeitä yksikkötestauksen toteuttamiseen liittyviä käsitteitä ovat ajuri ja tynkä (testikehyksen ohella)

• Ajuri (driver, test bed) – Ohjelma, joka ottaa syötteenään testitapaukseen liittyvää dataa

ja syöttää datan testattavalle yksikölle– Huolehtii yksikön tuottamien tulosten keräämisestä ja niiden

välittämisestä edelleen analysoitavaksi– Kannattaa suunnitella siten, että sitä voidaan käyttää usean eri

yksikön testaamiseen– Kannattaa suunnitella rinnan testattavan yksikön kanssa– Ongelmat ajurin suunnittelussa voivat paljastaa virheitä

testattavan yksikön suunnittelussa



• Tynkä (stub) – Korvaa testattavan yksikön kutsuman toisen yksikön

• Jokaista kutsuttavaa yksikköä varten tarvitaan oma tynkänsä– Tyngän tehtävät:

• Toteuttaa tarvittavat rajapinnat• Palauttaa kontrollin testattavaan yksikköön• Käsittelee mahdollisimman vähän saamiaan syötteitä• Palauttaa vain simuloidun arvon tai vaikka heittää poikkeuksen

– Tulisi suunnitella siten, että se olisi mahdollisimman helppo toteuttaa– Merkitys korostuu erityisesti virhetilanteita testattaessa

• Virhetilanteiden generoiminen on työlästä ja niiden systemaattinen etsiminen on erittäin vaikeaa

• Tarkoitusta varten suunnitellun tyngän avulla haluttu virhetilanne saadaan aikaan helposti



• Melkein kaikki ohjelmat ovat nykyään olio-ohjelmia.• Niiden testaukseen liittyy monia seikkoja, joita on hyvä erityisesti tiedostaa

ja ottaa huomioon. Tällaisia ovat:– Olion käyttäytyminen riippuu sen tilasta– Oliot kätkevät dataa ja kätkettyä dataa on paljastettava testauksessa– Yksityisten metodien erityinen testaaminen voi joissakin kielissä olla haastavaa –

sen kanssa pitää vain elää– On hyvä miettiä luokkien tulevaa käyttöä ja sitä, miltä osin kanta- ja lapsiluokat

kannattaa testata– Ja millaiset testitoteutukset tehdään abstrakteille luokille– Rakentajien ja niiden mahdollisten ongelmien hyvä testaus on erityisen tärkeää

(siksikin, että rakentajissa ei aina voi heittää poikkeuksia)

• Kurssilla näitä asioita ei ole mahdollista tarkastella perusteellisesti, mutta suosittelemme tähän erilliseen kalvosarjaan tutustumista:– Olio-ohjelmien testaamisesta

Huomioita olio-ohjelmien yksikkötestauksesta

Ohjelmistotekniikka

• Mieti, mikä on metodille kaikkein tärkeintä– Miten sitä käytetään (kuka, missä olosuhteissa), millä parametreilla sitä

kutsutaan• Testaa kaikkein yleisimmät tapaukset• Tee metodista robusti

– Testaa yleisimmät virhe- ja poikkeustilanteet– Testaa kaikki raja-arvot– Testaa parametrien kombinaatiot

• Ole luova – niin ovat metodin kutsujatkin• Keskity rajapintaan – se on stabiili, mutta toteutus voi muuttua• Seuraa testikattavuutta, mutta muista, että se ei usein kerro

paljoakaan testauksen todellisesta kattavuudesta• Tee testeistä niin yksinkertaisia kuin mahdollista• Käytä testikehystä, kuten JUnit ja noudata sen käytäntöjä

93(507)

Top 8 pointit yksikkötestaukseen

Ohjelmistojen testaus, 2014


3.4 Matalan tason integrointitestaus• Integrointitestausta voidaan tehdä usealla

tasolla. Tarkastelemme ensin "tavallista" matalan tason integrointitestausta ja myöhemmin järjestelmäintegrointitestausta.

• Yksikkötestauksen jälkeen yksiköt integroidaan isommiksi kokonaisuuksiksi.

• Integrointitestauksessa testataan yksiköiden rajapintoja ja niiden yhteistoimintaa.

• Hyödynnetään mahdollisuuksien mukaan testiautomaatiota.


Suurin osa integroinnista tapahtuu jo kehittäjän työasemassa

• Nykyaikaisessa ohjelmistokehityksessä ohjelmistokehittäjillä on versionhallinnan kautta koko ohjelma käytettävissä.– Siinä tilassa, jossa kaikki muut ovat palauttaneet tuotoksensa

yhteiseksi.

• Omaa koodia kehitetään kokonaisuuden puitteissa.• Kehittäjän tekemä testaus kohdistuu omaan tuotokseen,

mutta samalla tarkistetaan, että koko ohjelma kääntyy ja ainakin käynnistyy.

• Itse siis integroidaan oma uusi koodi kokonaisuuteen ja kokeillaan yksikkötesteillä, että se toimii.


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

• Siis: ohjelman voidaan olettaa toimivan samoilla tietyn alueen syötteillä

• Koko syötedomainin testaamisen sijasta luotetaan siis siihen, että voidaan valita yksi siitä edustaja

Ekvivalenssiositus-menetelmä 1/5


• Ekvivalenssiluokkien tunnistaminen– Valitaan jokin syöteavaruuden ehto, ja jaetaan se kahteen tai

useampaan luokkaan– Lähtökohtana jako sallittuihin ja ei-sallittuhin– Esim., jos kentässä pyydetään positiivista kokonaislukua, on

yksi iso luokka positiiviset kokonaisluvut ja toinen luokka negatiiviset

– Positiivisia voidaan sitten jaotella erikseen useisiin luokkiin



• 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

• Kun testataan montaa muuttujaa, voidaan 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– Testitapausten ohjelmallinen generointi tällöin hyödyllistä (kuvittele

kombinaatioiden taulukko, josta testit tehdään)

• Ekvivalenssiluokkien käyttökelpoisuus ei rajoitu ainoastaan syötteisiin, vaan tekniikkaa voidaan käyttää myös lähtien tulosten arvoalueista



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

Raja-arvoanalyysi 1/3


• Valitaan:– Parametrin laillisen arvoalueen minimiä (min) ja maksimia (max)

vastaavat tapaukset– Hieman pienempi kuin minimi (min-) ja hieman suurempi kuin maksimi

(max+)– Jos parametrilla on useita laillisia arvoalueita (ekvivalenssiluokkia),

valitaan tapaukset niiden kaikkien rajoilta

• 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



10.4 Lähdekoodin staattinen analyysi

• Idea: analysoidaan lähdekoodia automaattisesti ilman sen suorittamista

• Tarkoituksena – Löytää koodista virheitä– Huomata poikkeamia sovituista koodauskäytännöistä

(tyylioppaat)– Generoida koodista dokumentaatiota– Laskea arvoja ohjelman pituutta, monimutkaisuutta yms.

kuvaaville mittareille

• Hyödynnettävät tekniikat perustuvat yleensä tieto- ja kontrollivuoanalyysiin, rajoitusten ratkaisemiseen (constraint solving) yms.


• Esim. – Syntaksivirheet– Samaa koodia useammassa kuin yhdessä paikassa, kuollut

koodi (ei suoriteta ikinä)– Koodin ylläpidettävyys ja siirrettävyysongelmia– Alustamattomat muuttujat– Käyttämättömät paluuarvot– Virheellinen osoitinten käyttö– Puskurin ylivuodot yms. tietoturvaongelmat

Minkä tyyppisiä virheitä voidaan löytää?

Documents

TIE-21200 Ohjelmistojen testausotekn/nykyinen/materiaali/testauskalvot-otekn.pdf · – Ehtolauseet, silmukat, hypyt • Testitapauksia kannattaa valita sen mukaan, että mahdollisimman