Ohjelmistojen testaus Mika Katara, Matti Vuori ja Antti Jääskeläinen Tampereen teknillinen yliopisto, Tietotekniikan laitos 25.8.2014 Ohjelmistojen testaus, 2014 1(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) Ohjelmistojen testaus, 2014 15(507)
Tavoitteena virheiden löytäminen 1/3 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 Ohjelmistojen testaus, 2014 16(507)
Tavoitteena virheiden löytäminen 2/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 Ohjelmistojen testaus, 2014 17(507)
Tavoitteena virheiden löytäminen 3/3 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. Ohjelmistojen testaus, 2014 18(507)
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. Ohjelmistojen testaus, 2014 29(507)
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 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 Ohjelmistojen testaus, 2014 36(507)
Kaikkea ei voida testata 2/3 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% Tested Ohjelmistojen testaus, 2014 37(507)
Kaikkea ei voida testata 3/3 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 Ohjelmistojen testaus, 2014 38(507)
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 Ohjelmistojen testaus, 2014 51(507)
Keskeisiä termejä 2/6 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 Ohjelmistojen testaus, 2014 52(507)
Keskeisiä termejä 3/6 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 Ohjelmistojen testaus, 2014 53(507)
Keskeisiä termejä 6/6 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 Ohjelmistojen testaus, 2014 56(507)
Testitapaus pähkinänkuoressa 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 Ohjelmistojen testaus, 2014 58(507)
Testitapausten pitää olla haastavia 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) Ohjelmistojen testaus, 2014 60(507)
Testitapauksen rakenne ja sisältö 1/3 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 Ohjelmistojen testaus, 2014 63(507)
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 Ohjelmistojen testaus, 2014 76(507)
Osa-alueita 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. Ohjelmistojen testaus, 2014 77(507)
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? Ohjelmistojen testaus, 2014 78(507)
Rajapintojen testaaminen 2/2 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 Martin engineering team used English units of measurement while the agency's team used the more conventional metric system for a key spacecraft operation, according to a review finding released Thursday. Metric mishap caused loss of NASA orbiter, CNN, September 30, 1999 Ohjelmistojen testaus, 2014 79(507)
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 Ohjelmistojen testaus, 2014 80(507)
Tietorakenteiden testaaminen 2/2 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 Ohjelmistojen testaus, 2014 81(507)
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 Ohjelmistojen testaus, 2014 82(507)
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) Ohjelmistojen testaus, 2014 85(507)
Virhetilanteiden testaaminen 2/2 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ä? Ohjelmistojen testaus, 2014 86(507)
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 Ohjelmistojen testaus, 2014 87(507)
Yksikkötestauksen toteuttaminen 1/4 Lyhyitä selkeitä testifunktioita ja niissä yksinkertaisia tarkistuksia Testikehyksen määrittelemät älykkäät assertiot (xunittyö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 pseudokoodia TEST_TYPE test_square_root() { double result = my_sqrt(x); ASSERT_TRUE((result * result) == x); // Huom. Pieni bugi testikoodissa (mikä?) yksinkertaistuksen vuoksi } Ohjelmistojen testaus, 2014 88(507)
Yksikkötestauksen toteuttaminen 2/4 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()) Ohjelmistojen testaus, 2014 89(507)
Yksikkötestauksen toteuttaminen 3/4 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 Ohjelmistojen testaus, 2014 90(507)
Yksikkötestauksen toteuttaminen 4/4 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 Ohjelmistojen testaus, 2014 91(507)
Huomioita olio-ohjelmien yksikkötestauksesta 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 Ohjelmistojen testaus, 2014 92(507)
Top 8 pointit yksikkötestaukseen 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ä Ohjelmistojen testaus, 2014 93(507)
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. Ohjelmistojen testaus, 2014 101(507)
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. Ohjelmistojen testaus, 2014 102(507)
Ekvivalenssiositus-menetelmä 1/5 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 Ohjelmistojen testaus, 2014 264(507)
Ekvivalenssiositus-menetelmä 2/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 Ohjelmistojen testaus, 2014 265(507)
Ekvivalenssiositus-menetelmä 3/5 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 Ohjelmistojen testaus, 2014 266(507)
Ekvivalenssiositus-menetelmä 4/5 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 Ohjelmistojen testaus, 2014 267(507)
Ekvivalenssiositus-menetelmä 5/5 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 Ohjelmistojen testaus, 2014 268(507)
Raja-arvoanalyysi 1/3 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ä Ohjelmistojen testaus, 2014 269(507)
Raja-arvoanalyysi 2/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. Ohjelmistojen testaus, 2014 270(507)
Raja-arvoanalyysi 3/3 Esim. totuusarvoiselle tai loogista arvoa kuvaavalle parametrille ei yleensä voi eikä kannata tehdä rajaarvoanalyysiä 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 Ohjelmistojen testaus, 2014 271(507)
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. Ohjelmistojen testaus, 2014 460(507)
Minkä tyyppisiä virheitä voidaan löytää? 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 Ohjelmistojen testaus, 2014 462(507)