3. testaus osana ohjelmistoprosessia › ~tie21201 › s2011 › luennot › ohj-3060... · •...
TRANSCRIPT
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 50
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.
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 51
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 52
• 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ä
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 53
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 54
3.1 Testauksen V-malli
Toiminnallinen määrittely
Arkkitehtuurisuunnittelu
Moduulisuunnittelu Yksikkötestaus
Integrointitestaus
Järjestelmätestaus
Vaatimus-määrittely
Hyväksymis-testaus
testauksen suunnittelutulosten verifiointi
Toteutus
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 55
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 56
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 57
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 58
• Testauksen tasot vs. vaiheet– Esimerkkinä sulautettujen järjestelmien kehitykseen soveltuva
Multiple V –malli [Broekman&Notenboom 02]:
Simulaatio-malli Prototyyppi
Esituotanto
ytit
jt
ytit
jt
yt
it
jt
Testauksen vaiheet
Testauksentasot
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 59
Verifiointi ja validointi V-mallin avulla [Pezzè&Young 07]
System Specification
Subsystem Design/Specs
Unit/Component Specs
Delivered Package
System Integration
Subsystem
Units/Components
Actual Needs andConstraints
Review
User Acceptance (alpha, beta test)
System Test
Integration Test
Module Test
Analysis/Review
Analysis/Review
User review of external behavior as it is determined or becomes visible
Validation
Verification
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 60
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 61
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 62
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?
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 63
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 64
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 65
• Aina kun on mahdollista, kannattaa käyttää valmiita, hyvin testattuja tietorakenteita – Esim. C++:n Standard Template Library (STL)
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 66
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 67
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 68
• Toisistaan riippuvien silmukoiden testaamiseen voidaan käyttää soveltaen sisäkkäisten silmukoiden testaukseen kehitettyjä heuristiikkoja
• Riippumattomien silmukoiden testaus palautuu yksinkertaisten silmukoiden testaamiseen
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 69
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)
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 70
• 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?
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 71
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 72
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-lauseon parempi vaihtoehto
– Testikehyksen määrittelemät ”älykkäät” assertiot
double square_root(long x) {assert(x >= 0); // esiehtodouble result = sqrt(x);assert((result * result) == x); // jälkiehto, toimiiko tämä aina? return result;
}
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 73
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 74
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 75
• 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ä
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 76
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 77
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 78
• 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. fixtuurinrunTest(); // ajaa testitapauksen ja tarkastaa tuloksettearDown(); // purkaa fixtuurin}
• Fixture eli vakiokalusto, useille eri testitapauksille yhteiset järjestelmän alustukset
• Testijoukkoja mallintava TestSuite-luokka tallettaa joukon TestCase- ja TestSuite-luokan olioita
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 79
• JUnitin arkkitehtuuri:
TestCase
name
run(TestResult)runTest() setUp() tearDown()
TestSuite
run(TestResult) addTest(Test)
TestResult
«interface»Test
run(TestResult)
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 80
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 81
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)
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 82
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 83
• 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ä
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 84
– 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…
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 85
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 86
yksikkötestattu yksikkö
riippuvuus
integrointitestattava kokonaisuus
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 87
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 88
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 89
testattu yksikkö
riippuvuus
integrointitestattava kokonaisuus
testattava yksikkö
tynkä
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 90
• Etuna se, että käytettävissä on koko ajan ajettava ohjelma• Haittana tarvittavat tyngät, joiden toteuttaminen voi olla
työlästä
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 91
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 92
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 93
testattu yksikkö
riippuvuus
integrointitestattava kokonaisuus
testattava yksikkö
ajuri
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 94
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 95
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 96
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 97
– 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 98
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 99
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 100
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ä
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 101
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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 102
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 103
– 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 104
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 105
• 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
vaatimustestitapaus
V1 V2 V3 V4
TT1 TBD
TT2 OK OK
TT3 FAIL
TT4 OK OK
to be determined, ei vielä ajettu
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 106
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 107
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ä
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 108
• 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
OhjelmistotekniikkaMika Katara: Ohjelmistojen testaus, 2011 109
– 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