3. Testaus osana ohjelmistoprosessia › ~tie21201 › s2011 › luennot › OHJ-3060... · • Nykyään hyvin suorittu jatkuva integrointi pitää sisällään myös keskitetyn

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.


• 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


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


• 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


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


• 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


• 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


• 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


• 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


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


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


• 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


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?


• 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


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


• Aina kun on mahdollista, kannattaa käyttää valmiita, hyvin testattuja tietorakenteita – Esim. C++:n Standard Template Library (STL)


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


• 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


• Toisistaan riippuvien silmukoiden testaamiseen voidaan käyttää soveltaen sisäkkäisten silmukoiden testaukseen kehitettyjä heuristiikkoja

• Riippumattomien silmukoiden testaus palautuu yksinkertaisten silmukoiden testaamiseen


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)


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


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


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;

}


• 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


• 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


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


• 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


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


• 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


• JUnitin arkkitehtuuri:

TestCase

name

run(TestResult)runTest() setUp() tearDown()

TestSuite

run(TestResult) addTest(Test)

TestResult

«interface»Test

run(TestResult)


• 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


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)


• 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


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


– 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…


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


yksikkötestattu yksikkö

riippuvuus

integrointitestattava kokonaisuus


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


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


testattu yksikkö

riippuvuus


testattava yksikkö

tynkä


• Etuna se, että käytettävissä on koko ajan ajettava ohjelma• Haittana tarvittavat tyngät, joiden toteuttaminen voi olla

työlästä


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


• 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


testattu yksikkö

riippuvuus


testattava yksikkö

ajuri


• 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


• 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


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


– 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


• 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


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


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ä


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


• 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


– 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


• 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


• 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


• 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


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ä


• 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


– 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

Documents

3. Testaus osana ohjelmistoprosessia › ~tie21201 › s2011 › luennot › OHJ-3060... · • Nykyään hyvin suorittu jatkuva integrointi pitää sisällään myös keskitetyn