3. Testaus osana ohjelmistoprosessia Ohjelmistotuotanto on paljon muutakin kuin testaamista. Mutta miten testaus liitetään ohjelmistoprosessiin? Tässä kohdassa esitellään ns. testauksen V-malli ja siihen liittyen käydään läpi neljä tärkeää työvaihetta: yksikkö-, integrointi-, järjestelmä- ja hyväksymistestaus. Kuten perinteisessä ohjelmistotuotannossa yleensä, suurin osa testaukseen liittyvästä työstä on usein sen dokumentointia, mitä pitäisi tehdä ja mitä on tullut tehdyksi. Mika Katara: Ohjelmistojen testaus, 2011 50 Kuten edellä on jo todettu, testaus on oleellinen osa ohjelmistojen tuottamista Testausta ei yleensä voi eikä kannata eristää muusta ohjelmistoprosessista Nyrkkisäännön mukaan 20% koodista sisältää 80% virheistä, eli testauksen suunnitteluun ja resurssien kohdentamiseen kannattaa satsata Virheiden kasautuminen ei ole satunnaista, vaan yleensä ne piileskelevät uudessa ja muuttuneessa koodissa sekä kaikista monimutkaisemmissa komponenteissa Jokainen itseään kunnioittava ohjelmistotuotantoprosessi ottaa kantaa siihen, missä vaiheessa ja mitä testataan Mika Katara: Ohjelmistojen testaus, 2011 51
Koska jopa yli puolet ohjelmistoprojektin resursseista voi kulua testaukseen, virheiden paikallistamiseen ja korjaukseen, voidaan prosessia parantamalla saavuttaa suuria säästöjä Kuten myös parantamalla testauksessa käytettäviä menetelmiä, työkaluja yms. Motto: mitä aikaisemmin virheet korjataan, sen parempi Testata kannattaa heti, kun on jotain testattavaa, esim. kirjoittamalla hyväksymistestaussuunnitelma heti, kun vaatimukset on valmiina Näin vaatimusmäärittelydokumentti tulee testattua Yksityiskohdat kannattaa kiinnittää vasta sitten, kun ne tiedetään riittävän varmasti, näin vältytään turhalta työltä Mika Katara: Ohjelmistojen testaus, 2011 52 Testaamalla aikaisin saadaan myös parempi käsitys siitä, mihin suuntaan projekti on menossa Ensiarvoisen tärkeää tietoa projektin johdolle Toisaalta, jos testitapaukset suunnitellaan aikaisin, kasvaa sen riski, että ne joudutaan suunnittelemaan vielä uudestaan ennen kuin niitä päästään ajamaan Jos maali liikkuu, joudutaan tähtäämään uudestaan Vielä parempi olisi tietenkin jättää virheet tekemättä Parannetaan ohjelmistoprosessia vähentämään virheitä Kaikkein tunnetuin testausprosessi liittyy ns. testauksen V- malliin Mika Katara: Ohjelmistojen testaus, 2011 53
3.1 Testauksen V-malli Toiminnallinen määrittely Vaatimusmäärittely Hyväksymistestaus Järjestelmätestaus Arkkitehtuurisuunnittelu Integrointitestaus Moduulisuunnittelu Yksikkötestaus Toteutus testauksen suunnittelu tulosten verifiointi Mika Katara: Ohjelmistojen testaus, 2011 54 Perinteiseen, vesiputousmallia noudattavaan ohjelmistoprosessiin testaus liitetään V-mallin mukaisesti V-mallin vasen sivu kuvaa vesiputousmallia, jossa edetään ylhäältä alas ensin vaatimusmäärittelystä toiminnalliseen määrittelyyn ja siitä arkkitehtuurisuunnitteluun ja lopulta moduulisuunnitteluun ja toteutukseen Jokaisessa vaiheessa laaditaan testaussuunnitelmat vastaaville testausvaiheille (oikea sivu) Kun testattavissa olevaa toteutusta alkaa olla olemassa, aletaan sitä testata Edetään V-mallin oikeaa sivua alhaalta ylös toimien em. testaussuunnitelmien mukaan Testaus verifioi kullakin tasolla, vastaako toteutus määrittelyä/suunnittelua Mika Katara: Ohjelmistojen testaus, 2011 55
Käytettävät tekniikat vaihtelevat riippuen siitä, missä vaiheessa ollaan menossa Esim. testaus on alemmilla tasoilla yleensä enemmän lasi- kuin mustalaatikkotyyppistä ja ylemmillä tasoilla taas toisin päin Jäljitettävyys eri vaiheiden välillä helpottaa virheiden alkuperän selvittämistä Kun virhe on paikallistettu, voidaan testausprosessia yrittää parantaa siten, että ko. tyypin virheet havaitaan aikaisemmin Mika Katara: Ohjelmistojen testaus, 2011 56 V-malli on monesti turhan jäykkä nykyaikaiseen ohjelmistotuotantoon Idea on kuitenkin helppo sisäistää Voidaan myös olettaa, että kaikki testaajat tuntevat V-mallin Lisäksi uudemmat prosessimallit voidaan usein tajuta helposti vertaamalla niitä V-malliin Mika Katara: Ohjelmistojen testaus, 2011 57
Testauksen tasot vs. vaiheet Esimerkkinä sulautettujen järjestelmien kehitykseen soveltuva Multiple V malli [Broekman&Notenboom 02]: jt jt it jt it yt it yt Testauksen yt tasot Simulaatiomalli Prototyyppi Esituotanto Testauksen vaiheet Mika Katara: Ohjelmistojen testaus, 2011 58 Verifiointi ja validointi V-mallin avulla [Pezzè&Young 07] Actual Needs and Constraints Review User Acceptance (alpha, beta test) Delivered Package Validation Verification System Specification Subsystem Design/Specs Analysis/ Review Analysis/ Review System Test Integration Test Subsystem System Integration Unit/ Component Specs Module Test Units/ Components User review of external behavior as it is determined or becomes visible Mika Katara: Ohjelmistojen testaus, 2011 59
3.2 Yksikkötestaus Unit testing, module testing Testataan jokainen ohjelman yksikkö erikseen Yksikkö voi olla moduuli, luokka, prosessi tms. Yksikkötestaus on yleensä osa yksikön toteutusvaihetta Yksikön koodaaja tarkistaa 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 Mika Katara: Ohjelmistojen testaus, 2011 60 Yksikkötestaus on yleensä lasilaatikko-testausta, mutta myös jotkin mustalaatikko-testauksen tekniikoista ovat käyttökelpoisia Yksikkötestauksen osa-alueet: Rajapinnat Yksikön käyttämät tietorakenteet Suorituspolut ja silmukat Virhetilanteiden käsittely Raja-arvot Mika Katara: Ohjelmistojen testaus, 2011 61
Rajapintojen testaaminen Rajapinta koostuu yleensä funktioista, joiden parametreja ja paluuarvoja käytetään tiedonvälitykseen Rajapintojen toimivuus on yleensä syytä testata ensimmäiseksi Jos rajapinnat eivät toimi, voi muiden testien suorittaminen olla hankalaa ellei jopa mahdotonta 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? Mika Katara: Ohjelmistojen testaus, 2011 62 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 Mika Katara: Ohjelmistojen testaus, 2011 63
Tietorakenteiden testaaminen 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 Mika Katara: Ohjelmistojen testaus, 2011 64 Aina kun on mahdollista, kannattaa käyttää valmiita, hyvin testattuja tietorakenteita Esim. C++:n Standard Template Library (STL) Mika Katara: Ohjelmistojen testaus, 2011 65
Suorituspolku- ja silmukkatestaus Koodin haarautumiskohdat ovat virheherkkiä Ehtolauseet, silmukat, hypyt Testitapauksia kannattaa valita sen mukaan, että mahdollisimman monta kriittistä suorituspolkua yksikön läpi tulee testattua 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 Mika Katara: Ohjelmistojen testaus, 2011 66 Nämä tekniikat yleistyvät myös sisäkkäisiin silmukoihin Ongelma on tarvittavien testitapausten määrän nopea kasvu sisäkkäisyyden kasvaessa Sisäkkäisten silmukoiden testaukseen on kehitetty strategioita, joilla pyritään pitämään testitapausten määrä kohtuullisena esim. testataan sisäkkäisin silmukka ensin täydellisesti pitäen ulompien silmukoiden silmukkamuuttujat minimiarvoissaan, sitten toiseksi sisäkkäisin jne. Peräkkäiset silmukat voivat olla joko riippumattomia tai riippuvaisia toisistaan Riippuvuus syntyy esim. tilanteesta, jossa jälkimmäisen silmukkamuuttujan arvo alustetaan käyttäen ensimmäisen silmukkamuuttujan arvoa Mika Katara: Ohjelmistojen testaus, 2011 67
Toisistaan riippuvien silmukoiden testaamiseen voidaan käyttää soveltaen sisäkkäisten silmukoiden testaukseen kehitettyjä heuristiikkoja Riippumattomien silmukoiden testaus palautuu yksinkertaisten silmukoiden testaamiseen Mika Katara: Ohjelmistojen testaus, 2011 68 Virhetilanteiden testaaminen 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ä Tämän seurauksena 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) Mika Katara: Ohjelmistojen testaus, 2011 69
Virhetilanteiden testauksen muistilista: 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ä? Onko virheenkäsittely tehty siten, että käsittelyyn ylipäänsä päästään vai kaatuuko ohjelma jo ennen sitä? Onko virheenkäsittely ylipäänsä tehty oikein? Onko virheestä toipuminen mahdollista? jos ei, kaadetaanko ohjelma käyttäjäystävällisesti? Mika Katara: Ohjelmistojen testaus, 2011 70 Raja-arvojen testaaminen Viimeinen vaihe yksikkötestauksessa 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 Mika Katara: Ohjelmistojen testaus, 2011 71
Yksikkötestauksen toteuttaminen Design by Contract: metodien esi- ja jälkiehdot Jos kutsuja täyttää metodin esiehdon, kutsuttava täyttää sen jälkiehdon Koodin miinoittaminen assertioilla järkevästi Jos suorituksen halutaan jatkuvan virhetilanteen jälkeen, if-lause on parempi vaihtoehto Testikehyksen määrittelemät älykkäät assertiot double square_root(long x) { assert(x >= 0); // esiehto double result = sqrt(x); assert((result * result) == x); // jälkiehto, toimiiko tämä aina? return result; } Mika Katara: Ohjelmistojen testaus, 2011 72 Koska yksiköt eivät yleensä voi toimia itsenäisesti, vaatii niiden testaaminen apukoodin kirjoittamista, jota käytetään vain testauksessa 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 Mika Katara: Ohjelmistojen testaus, 2011 73
Tärkeitä yksikkötestauksen toteuttamiseen liittyviä käsitteitä ovat ajuri ja tynkä (testikehyksen ohella) Ajuri (driver, test bed) on ohjelma, joka ottaa syötteenään testitapaukseen liittyvää dataa ja syöttää datan testattavalle yksikölle Ajuri myös huolehtii yksikön tuottamien tulosten keräämisestä ja niiden välittämisestä edelleen analysoitavaksi Ajuri kannattaa suunnitella siten, että sitä voidaan käyttää usean eri yksikön testaamiseen Ajuri kannattaa suunnitella rinnan testattavan yksikön kanssa Ongelmat ajurin suunnittelussa voivat paljastaa virheitä testattavan yksikön suunnittelussa Mika Katara: Ohjelmistojen testaus, 2011 74 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 Tulostaa tiedon lokiin siitä, että sitä on kutsuttu Palauttaa kontrollin testattavaan yksikköön Käsittelee mahdollisimman vähän saamiaan syötteitä Mika Katara: Ohjelmistojen testaus, 2011 75
Tynkä tulisi suunnitella siten, että se olisi mahdollisimman helppo toteuttaa Tynkien merkitys korostuu erityisesti virhetilanteita testattaessa Virhetilanteiden generoiminen on työlästä Niiden systemaattinen etsiminen on erittäin vaikeaa Tarkoitusta varten suunnitellun tyngän avulla haluttu virhetilanne saadaan aikaan helposti Mika Katara: Ohjelmistojen testaus, 2011 76 xunit-testauskehykset Junit: Erich Gamman ja Kent Beckin kehittämä testikehys Java-ohjelmien yksikkötestaukseen Avointa lähdekoodia Valmiita toimintoja testitapausten ajamiseen ja niiden tuloksista raportointiin Määrämuotoiset testitapaukset helpottavat testien ylläpitoa Lähtökohta: jos jotakin ohjelman ominaisuutta varten ei ole automatisoituja testejä, oletettavasti ko. ominaisuus ei toimi Useita suunnittelumalleja (design patterns) hyödyntämällä tehty testikehys, jossa testejä kuvataan olioilla Testitapausten strukturointi ja työkalut niiden ajamiseen Mika Katara: Ohjelmistojen testaus, 2011 77
Käyttää reflektiota tms., mikä tuo joustavuutta kehyksen käyttöön Abstrakti kantaluokka TestCase, joka määrittelee mm. testitapauksen nimen ja run-metodin: public void run() { setup(); // alustaa testitapauksen luomalla ns. fixtuurin runtest(); // ajaa testitapauksen ja tarkastaa tulokset teardown(); // purkaa fixtuurin } Fixture eli vakiokalusto, useille eri testitapauksille yhteiset järjestelmän alustukset Testijoukkoja mallintava TestSuite-luokka tallettaa joukon TestCase- ja TestSuite-luokan olioita Mika Katara: Ohjelmistojen testaus, 2011 78 JUnitin arkkitehtuuri: «interface» Test run(testresult) TestResult name TestCase run(testresult) runtest() setup() teardown() TestSuite run(testresult) addtest(test) Mika Katara: Ohjelmistojen testaus, 2011 79
Voidaan käyttää myös integrointitestauksen apuna Käytännössä auttaa lähinnä ajurien rakentamisessa, ei niinkään tynkien Useita laajennuksia: J2EE, testikattavuuden mittaus jne. xunit perheeseen kuuluu useita hieman erilaisia kehyksiä eri ohjelmointikielille jne. Lisätietoja: junit.org Mika Katara: Ohjelmistojen testaus, 2011 80 3.3 Integrointitestaus Yksikkötestauksen jälkeen yksiköt integroidaan isommiksi kokonaisuuksiksi Integrointitestauksessa testataan yksiköiden rajapintoja ja niiden yhteistoimintaa Kannattaa hyödyntää mahdollisuuksien mukaan testiautomaatiota kuten automatisoituja savutestejä (esitellään myöhemmin) Mika Katara: Ohjelmistojen testaus, 2011 81
Integrointitestaus voidaan ajatellaan implisiittiseksi osaksi yksikkötestausta, varsinkin, jos ohjelmisto on kooltaan pienehkö, ja yksiköt integroidaan inkrementaalisesti Lisätään yksi yksikkö kerrallaan testattavaan kokonaisuuteen Yleensä kehittäjät vastaavat tällöin yksikkötestauksen lisäksi suurelta osin myös integrointitestauksesta Integrointitestit suoritetaan yksikkötestien tapaan yleensä kehitysympäristössä Nykyään hyvin suorittu jatkuva integrointi pitää sisällään myös keskitetyn integroinnin, joka tapahtuu palvelimella, mutta tämän voidaan katsoa kuuluvan kehitysympäristöön Mika Katara: Ohjelmistojen testaus, 2011 82 Hyvässä ohjelmistoarkkitehtuurissa jokainen yksikkö hoitaa oman rajatun tehtävänsä mahdollisimman itsenäisesti Ylimääräiset riippuvuudet yksiköiden välillä hankaloittavat ylläpitoa yms. Mahdollisia riippuvuuksia yksiköiden välillä: Yksikkö välittää dataa toiselle parametrien välityksellä parametrin tyyppi saattaa olla tietorakenne, josta kutsuttava yksikkö hyödyntää vain pientä osaa kontrolliparametri voi välittää tiedon siitä, mikä mahdollisista suorituspoluista on valittava Yksiköt eivät tiedä toisistaan, mutta kolmas yksikkö käyttää niitä molempia esim. toinen yksikkö kirjoittaa tiedostoon ja toinen lukee sieltä Mika Katara: Ohjelmistojen testaus, 2011 83
Yksiköt käyttävät yhteisiä globaaleja muuttujia tiedonkätkentä ei aina käytännössä toteudu Spagettikoodissa yksiköt voivat päästä kurkkimaan rajapintojen ohi tai kontrolli voi muuttua yksiköstä toiseen kesken kaiken nykyaikainen versio: C++:n friend-mekanismi ystävät kannattaa valita huolella Mika Katara: Ohjelmistojen testaus, 2011 84 Kertarysäysintegrointi Big bang: Alussa ei ollut mitään ja sitten kaikki räjähti Idea: Ensin yksikkötestataan kaikki yksiköt erikseen ja sitten integroidaan ne kerralla toimivaksi kokonaisuudeksi Yleistä pienissä ohjelmissa Ongelma 1: yksikkötestausvaiheessa on kaikille yksiköille kirjoitettava tarvittavat ajurit ja tyngät Ongelma 2: kun vika ilmenee integroitua järjestelmää testattaessa, on sen aiheuttaneen virheen etsiminen hankalaa isosta joukosta yksiköitä Ongelma 3: virheen korjaamisen jälkeen täytyy monia testejä ajaa uudelleen, sen varmistamiseksi, ettei korjaus ole rikkonut mitään muuta Mika Katara: Ohjelmistojen testaus, 2011 85
integrointitestattava kokonaisuus yksikkötestattu yksikkö riippuvuus Mika Katara: Ohjelmistojen testaus, 2011 86 Inkrementaalinen integrointi Aloitetaan testaaminen yhdestä yksiköstä Lisätään toinen yksikkö, sitten kolmas jne. Etu 1: säästytään ajurin/tyngän tekemiseltä, jos sen sijasta voidaan käyttää yksikkötestattua yksikköä Etu 2: vika helpompi löytää pienestä määrästä yksiköitä Etu 3: virheen korjaamisen jälkeen ei kaikkia siihen asti ajettuja testejä välttämättä tarvitse ajaa uudestaan Mika Katara: Ohjelmistojen testaus, 2011 87
Jäsentävä inkrementaalinen integrointi Top-down Idea: yksikkötestataan ensin ylimmän tason kontrolliyksikkö, joka sitten integroidaan niiden yksiköiden kanssa, joita se kutsuu Kutsuttavat yksiköt testataan seuraavaksi niiden kutsumat yksiköt korvataan jälleen tyngillä ylimmän tason yksikkö poistaa ajureiden tarpeen Kun integrointi on saatu testattua, korvataan jälleen tyngät niitä vastaavilla yksiköillä, jne. Näin edetään, kunnes kaikki yksiköt on integroitu yhdeksi kokonaisuudeksi Mika Katara: Ohjelmistojen testaus, 2011 88 testattava yksikkö integrointitestattava kokonaisuus testattu yksikkö riippuvuus tynkä Mika Katara: Ohjelmistojen testaus, 2011 89
Etuna se, että käytettävissä on koko ajan ajettava ohjelma Haittana tarvittavat tyngät, joiden toteuttaminen voi olla työlästä Mika Katara: Ohjelmistojen testaus, 2011 90 Kokoava inkrementaalinen integrointi Bottom-up Toinen inkrementaalinen lähestymistapa Edetään päinvastoin kuin jäsentävässä integroinnissa Aloitetaan yksikkötestaus alimman tason yksiköistä, joille kirjoitetaan tarvittavat ajurit Seuraavassa vaiheessa korvataan nämä ajurit vastaavilla yksiköillä Testataan seuraavaksi nämä yksiköt Kirjoitetaan jälleen tarvittavat ajurit Alimman tason yksiköt poistavat tynkien tarpeen Mika Katara: Ohjelmistojen testaus, 2011 91
Näin syntyy vähitellen klustereita, joista periaatteessa jokainen huolehtii jostain hyvin määritellystä toiminnallisesta kokonaisuudesta Kun kaikki klustereiden yksiköt on testattu, ajurit korvataan jälleen seuraavan tason yksiköillä Tuloksena syntyy hieman isompia klustereita Tätä jatketaan, kunnes kaikki klusterit on integroitu yhdeksi kokonaiseksi ohjelmaksi Mika Katara: Ohjelmistojen testaus, 2011 92 testattava yksikkö integrointitestattava kokonaisuus testattu yksikkö riippuvuus ajuri Mika Katara: Ohjelmistojen testaus, 2011 93
Kokoava lähestymistapa korostaa toiminnallisuuden testausta ohjelman logiikan testauksen kustannuksella Ohjelman logiikassa olevat virheet voivat paljastua vasta integrointitestauksen viime metreillä Toisin kuin jäsentävässä integroinnissa, järjestelmän prototyyppi ei ole käytettävissä ennen kuin vasta aivan integrointitestauksen lopussa Mika Katara: Ohjelmistojen testaus, 2011 94 Ehdottomasti paras puoli kokoavassa lähestymistavassa on se, että tynkiä ei tarvita laisinkaan Tynkien tekeminen on yleensä työläämpää kuin ajurien Lisää etuja: Kokoavassa integroinnissa voidaan klustereiden testausta jakaa helposti useammalle tiimille Matalan tason yksiköiden suunnittelussa ja toteutuksessa tehdyt virheet voidaan löytää nopeasti esim. niissä piilevät suorituskykyongelmat voidaan havaita tehokkaasti Mika Katara: Ohjelmistojen testaus, 2011 95
Muita tapoja integrointitestata Edellä oletettiin, että inkrementaalinen integrointitestaus on implisiittinen osa yksikkötestausta, ja että samoja tynkiä ja ajureita voidaan hyödyntää molemmissa vaiheissa Vaiheita ei välttämättä kannata erottaa toisistaan Käyttäen inkrementaalista integrointistrategiaa voidaan välttyä (lähes) kokonaan joko tynkien tai ajureiden kirjoittamiselta Integrointitestauksessa tarvittavat tyngät ja ajurit voivat kuitenkin erota merkittävästi yksikkötestauksessa tarvituista Esim. virhekäsittelyn testaus ilman tätä tarkoitusta varten suunniteltuja tynkiä voi osoittautua hankalaksi Mika Katara: Ohjelmistojen testaus, 2011 96 Jossain tilanteissa vaiheet saattaa kannattaa erottaa toisistaan, eli yksikkötestauksen voi ajatella integrointitestauksesta riippumattomaksi vaiheeksi yksikkötestauksessa kaikille yksiköille kirjoitetaan tarvittavat tyngät ja ajurit integrointitestauksessa ajurit ja tyngät kirjoitetaan tarpeen mukaan erikseen Testaajat eivät välttämättä pääse vaikuttamaan siihen, missä järjestyksessä integrointia testataan Testausjärjestys voi riippua siitä, missä järjestyksessä yksiköitä integroidaan toisiinsa Tämä on luonnollista eritoten silloin, kun integrointia testaavat kehittäjät Mika Katara: Ohjelmistojen testaus, 2011 97
Joskus kannattaa integroida ensin ne yksiköt, joihin liittyy suurin riski tai jotka muuten vaan sattuvat olemaan kriittisellä polulla Mitä suurempi riski, sen aikaisemmassa vaiheessa pitää testata Kriittinen polku saattaa liittyä esim. ominaisuuteen, joka halutaan saada toimimaan mahdollisimman nopeasti tai tekniikkaan, jonka käyttökelpoisuus halutaan selvittää mahdollisimman nopeasti Jatkuvan integroinnin prosessi esitellään myöhemmin Mika Katara: Ohjelmistojen testaus, 2011 98 Integrointitestauksen nyrkkisääntöjä Tarvittavan apukoodin määrä tulisi minimoida Kerralla kannattaa integroida vain pieni määrä yksiköitä Vain yksi kerrallaan, jos kyseessä on kriittinen tai virheherkkä yksikkö Toisaalta yksinkertaisia, toisistaan riippuvia yksiköitä ei välttämättä kannata testata erillisinä yksiköinä vältytään turhien ajurien/tynkien kirjoittamiselta Mika Katara: Ohjelmistojen testaus, 2011 99
Järjestelmäintegrointitestaus Isojen tietojärjestelmäprojektien yhteydessä suureksi kysymykseksi nousee yleensä yhteensopivuus muiden järjestelmien kanssa Koska kokonaisjärjestelmän osat tulevat yleensä eri toimittajilta, on syytä kiinnittää erityistä huomiota siihen, että osajärjestelmät juttelevat toistensa kanssa saumattomasti Järjestelmäintegrointitestaus on luonteeltaan teknistä, toiminnallisuus ja suorituskyky jne. varmistetaan vasta kun homma toimii pellin alla Kannattaa aloittaa mahdollisimman aikaisin, myöhäinen aloitus johtaa ongelmiin projektin lopussa Ajureita ja tynkiä joudutaan käyttämään korvattaessa keskeneräisiä ja puuttuvia osajärjestelmiä Mika Katara: Ohjelmistojen testaus, 2011 100 3.4 Järjestelmätestaus Testataan kokonaisjärjestelmän toimintaa Voi olla erillisen testaustiimin tehtävä Löydettyjen virheiden korjaus kallista Ajallisesti yleensä pitkäkestoisin kaikista testausvaiheista Kaikkien testitapausten ajaminen voi kuluttaa hyvinkin paljon resursseja Luontevaa aloittaa jälleen savutestillä Jos järjestelmätestaus aloitetaan vasta projektin lopussa, ajaudutaan helposti ongelmiin Ketterässä prosessissa pyritään testaamaan koko ajan myös järjestelmätasolla Mika Katara: Ohjelmistojen testaus, 2011 101
Järjestelmätestausvaiheessa käytettävissä on koko järjestelmä, mikä tekee mielekkääksi mm. seuraavien asioiden testaamisen: Asiakkaan vaatimukset Suunnittelun ominaispiirteet Järjestelmän tilat Kapasiteetti Rinnakkaisuus Ohjelmiston ja laitteiston konfiguraatiot Rajapinnat ja toiminta muiden järjestelmien kanssa (vrt. järjestelmäintegrointitestaus) Installointi Lokalisointi Mika Katara: Ohjelmistojen testaus, 2011 102 Suorituskyky Toipuminen virhetilanteista Luotettavuus Resurssien käyttö Skaalautuvuus Järjestelmätestaus vaatii huomattavasti enemmän luovuutta kuin alemman tason testaus Yleispäteviä toimintamalleja mahdotonta määritellä tarkasti Mika Katara: Ohjelmistojen testaus, 2011 103
Järjestelmätestauksen vaiheet (mukailtu Kit: Software Testing in the Real World, 1995): Vaatimusten analysointi ja paloittelu hallittaviin osiin Jokaiselle osalle yksityiskohtaisten vaatimusten listaus Jokaista merkityksellistä vaatimusta vastaavien syötteiden ja tulosten määrittely Vaatimuskattavuusmatriisin määrittely Testitapausten ajaminen ja vaatimuskattavuuden mittaaminen Uusien testitapausten määrittely ja ajaminen tavoitellun vaatimuskattavuuden saavuttamiseksi Mika Katara: Ohjelmistojen testaus, 2011 104 to be determined, ei vielä ajettu Vaatimuskattavuusmatriisi Taulukko, jossa kerrotaan yhteydet (eri tyyppisten) testitapausten ja vaatimusten välillä Mikäli mahdollista, yhdellä (laillisella) testitapauksella kannattaa testata montaa vaatimusta Matriisista näkee helposti sen, mitä ei (vielä) testata vaatimus testitapaus TT1 V1 V2 V3 V4 TBD TT2 OK OK TT3 FAIL TT4 OK OK Mika Katara: Ohjelmistojen testaus, 2011 105
Järjestelmätestausvaiheessa pitäisi huolehtia siitä, että kehittäjät saavat vikaraportit nopeasti Ei niin itsestään selvää kuin alemmissa vaiheissa mahdolliset organisaatiorajat hidastavat Projektin johdon kautta kierrättäminen ei välttämättä ole hyvä idea Nopea raportointi voi estää virheen leviämisen muihin paikkoihin Mika Katara: Ohjelmistojen testaus, 2011 106 Muutosten hallinnasta Koska järjestelmätestien suorittajat eivät yleensä itse korjaa löydettyjä virheitä, on erittäin tärkeää huolehtia muutosten hallinnasta Mikäli jokainen virhe korjataan heti siten, että testattava versio vaihtuu jatkuvasti, ei järjestelmätestaus pääse etenemään Toisaalta joidenkin virheiden pikainen korjaaminen voi olla ensisijaista toisten virheiden nopealle löytymiselle Yleensä virheiden korjaamisen priorisoinnista ja aikatauluista päättää erillinen taho (Change/Configuration Control Board) Tähän voi kuulua testaajien ja kehittäjien lisäksi myös tuotteenhallintapäällikkö, projektipäällikkö, laatupäällikkö, tietokantojen ylläpitäjä, asiakkaita/loppukäyttäjiä, asiakastukihenkilöitä ja markkinointi-ihmisiä Mika Katara: Ohjelmistojen testaus, 2011 107
Pahimmassa tapauksessa kehittäjät määräävät mitä versiota testataan ja testaajat keskittyvät vain muutosten hallintaan testiympäristössä Esim. testiautomaatio voi tarvita säätöä aina testiympäristön muuttuessa Esim. virheidenkorjausstrategiasta [Craig&Jaskiel 02]: Järjestelmätestauksen ensimmäisen kahden viikon aikana kaikki muutosehdotukset toteutetaan ja raportoidut virheet korjataan päivittäisissä buildeissä, jotka alkavat klo 17.30 Mika Katara: Ohjelmistojen testaus, 2011 108 Seuraavan kahden viikon aikana testaus- ja kehitystiimien johtajat, käyttäjien edustaja ja tuotteenhallinnasta vastaava henkilö tapaavat klo 10.00 joka tiistai ja torstai priorisoimaan kaikki muutosehdotukset ja raportoitujen virheiden korjaukset samalla päätetään siitä, mitkä muutoksista päivitetään testiympäristöön Viimeisen kahden viikon aikana ainoastaan fataalien virheiden korjaukset päivitetään testiympäristöön Mika Katara: Ohjelmistojen testaus, 2011 109