Testaus elinkaaressa Testaus kehittämisen tukena Yksikkötestaus Integrointitestaus Testaustasot ja vaiheet Testaustaso = tietyn testauksen kohteen ja tavoitteen mukainen testaus joka jatkuu koko ajan tai toistuu usein projektissa esimerkiksi integrointitestaus aina kehitys-baselinen yhteydessä Testausvaihe = projektissa tehtävä kertaluonteinen projektin etenemiseen liittyvä testausaktiviteetti voi olla yhtä tai useaa testaustasoa esim. beta-testaus, hyväksyntätestaus, käytettävyystestaus.. Testaustaso ja vaihe usein mielletään samaksi, ero kuitenkin merkittävä 1
Testauksen kytkeytyminen ohjelmistokehitykseen ns. testauksen V-malli on syntynyt nivomalla eri tasoiset testauksen vaiheet vastaaviin kehitysvaiheisiin perinteisessä vesiputous-elinkaarimallissa V-mallissa oleellista Eri työvaiheiden vastaavuudet Testauksen suunnittelu alkaa heti projektin alussa Erottelee testaustasoja Kritiikkiä Yksinkertaisena ja jäykkänä mallina ei vastaa modernia ohjelmistokehitystä Ei kykene mukautumaan muutokseen Johtaa tehottomiin ruohnjuuritason testauskäytäntöihin Testauksen V-malli Black-box Testaajat Staattinen Dynaaminen White-box Kehittäjät 2
V-malli käytännössä V-malli ei ole kehityksen elinkaarimalli, vaan käsitteellinen malli Iteratiivisessa kehityksessä V-mallia sovelletaan jokaisen iteraation sisällä Tasoja voi olla useita, eivätkä moduulitestaus ja integrointitestaus ole aina helposti eroteltavissa Oleellista on ymmärtää mikä on kulloinkin SUT Joka tasolla laaditaan testaussuunnitelma Suunnitelman tekoa kannattaa joskus viivyttää mahdollisten muutosten vuoksi Suunnitelma ei tarkoita dokumentin tuottamista! Testaus toteutetaan niin aikaisin kuin mahdollista Eri tasojen spesifikaatioita voidaan validoida staattisella testauksella ja rakentuvan järjestelmän asiakastestaukella V-malli käytännössä Testaustekniikat riippuvat siitä millä tasolla ollaan Yleinen periaate: Matalilla testauksen tasoilla testauksen tehokas kohdistaminen (kattavuus, tehokas virheiden löytyminen) vaatii ohjelmiston rakenteen hyödyntämistä white-box tekniikat Matalilla tasoilla testaaminen vaatii usein järjestelmän modulien teknistä tuntemusta, lisäksi tarve saada löytyvät virheet saman tien korjattua kehittäjät/ohjelmoijat testaavat Korkeammilla tasoilla järjestelmän tai osajärjestelmän testauksessa testataan toimintoja ja asiakasvaatimuksia black-box tekniikat Asiakasnäkökulma, ei-toiminnalliset ominaisuudet, testauksen kohdentaminen riskiperustaisesti erilliset testaajat Käytännössä mm. rakennettava ohjelmisto, kehitysprosessi ja yrityksen organisaatio vaikuttavat oleellisesti tekniikoiden valintaan 3
YKSIKKÖTESTAUS (unit testing) Itse ohjelmointityössä tapahtuvien virheiden välittömäksi poistamiseksi tehtävä tekninen testaus Yksikkö joka testataan voi olla... Komponentti, moduuli Luokka Luokan metodi Toiminnallisuus jonka kehittäjä on toimeksiantona totetuttanut Koko ja periaate jolla yksikkö määritetään vaihtelee siis suuresti Usein käytännössä kaksi yksikkötestauksen tasoa Yksittäisten koodaustehtävien testaus sitä mukaan kun ne tehdään Moduli/komponenttitestaus jollekin ohjelmiston osalle ennen integrointia YKSIKKÖTESTAUS Testattava moduli Testitulokset Testitapaukset Varmistaa että moduuli toimii irrallisena kokonaisuutena Modernissa ohjelmistokehityksessä yksikkötason testaus nähdään suoraan osana toteutuksen tekoa, kehittäjän vastuulla 4
Yksikkötestausympäristö Ajuri Moduli Tynkä Tynkä rajapinta lokaalit tietorakenteet rajatapaukset suorituspolut virheelliset syötteet Testitapaukset Testin tulos Yksikkötestausympäristö Modulit on suunniteltu toimimaan osana järjestelmää Jos ympäröiviä moduleja ei tehty, testauksessa apukoodia Ajuri (test driver) Syöttää testitapausten datan SUT:lle Kerää SUT:n tulokset (analysointi yleensä erillinen) Käyttää SUT:ia kuten aikanaan valmistuva ohjelmisto Voidaan usein testata modulia monipuolisemmin kuin integroituna ohjelmistoon Tynkämoduli (mock up, stub) Korvaa modulin jota SUT kutsuu ja tarvitsee Toteuttaa vaadittavat rajapinnat Kerää tiedon siitä että sitä on kutsuttu (sekä kutsun parametrit) Palauttaa kontrollin testattavaan yksikköön Tynkä usein hyödyllinen korvaaman vaikeasti generoitavaa todellista dataa (esim. jokin mittausinstrumentti) 5
Yksikkötestauksen kohdentaminen Modulin rajapintojen testaus Funktioiden parametrit ja paluuarvot tiedonvälittäjinä Kääntäjä huomaa suurimman osan virheistä Staattisen testauksen tekniikat käyttökelpoisia Lokaalit tietorakenteet Virheiden estäminen: käytä valmiita luotettavia tietorakenteita (kielen kirjastot, esim. C++:n STL) Valmiiden tietorakenteiden käyttäminen testattava Monimutkaisten tietorakenteiden kattava dynaaminen testaus erittäin vaikeaa koodin staattinen testaus Yleensäkin virhealttiita Yksikkötestauksen kohdentaminen Suortuspolku, silmukat Mahdollisia suorituspolkuja (koodissa) käytetään testien kohdentamiseen ja kattavuuden arvointiin Valitse testitapaukset siten että kaikki oleelliset suorituspolut tulevat testatuksi Jo muutama silmukka tekee riittävän kattavuuden saavuttamisen mahdottomaksi (ainakin manuaalisella testauksella) staattinen testaus, black-box testaus täydentämään Ääriarvot Ohjelmointivirheet liittyvät usein sallittujen arvojen rajoihin Parametrit, paluuarvot Silmukoiden pyörimiskerrat (0, 1, n, max kertaa) Tietorakenteet, esim. dynaamisesti kasvavan rakenteen täyttyminen (ja taas pieneminen) 6
Yksikkötestauksen kohdentaminen Virhetilanteiden testaus Hallitusti hoidetut virhetilanteet ovat osa ojelman toimintaa Nostetut poikkeukset (ja muut virheilmoitukset) ovat osa modulin rajapintaa Virhekäyttäytyminen yleensä huonosti huomioitu ja määritelty, siksi virhealtis alue ja toisaalta vaikea testata Matalalla tasolla poikkeuksia sekä palautettuja virhekoodeja, korkealla tasolla käyttäjälle näkyviä virheilmoituksia ja toipumismenettelyjä Testattavaa: Syntyykö virheilmoitus oikein? Sisältääkö virheilmoitus riittävän tiedon sen ymmärtämiseksi? Kykeneekö käyttäjä paikallistamaan virheen syyn ja toipumaan tilanteesta? Ovatko virhekäytännöt yhtenevät? INTEGEROINTITESTAUS Virheiden estäminen Integrointitestaus Integrointitestauksen strategioita Sopimuspohjainen ohjelmointi Integrointitestauksen toteutus 7
Virheiden estäminen Virheen estäminen on aina fiksumpaa kuin sen löytäminen testauksella, näin myös integrointivaiheessa Moduulien tehtävä oltava selkeä, korkea koheesio (tekee vain yhtä asiaa) Rajapinnat Pieniä Eksplisiittisiä (ei piilotettuja tai vaikeasti havaittavia mekanismeja) Ymmärrettäviä ja selkeitä, hyvin dokumentoituja Modulien väliset kytkennät löyhiä Asiakaskoodin riippuvuus rajapinnasta, ei toteutuksesta Luotettavien hyvin testattujen moduulien käyttö Valmiit kirjastot ja komponentit Uudellenkäytön usein unohdettu hyöty! Integrointitestaus Integrointitestauksesta on kyse aina kun kaksi erillään suunniteltua ja toteutettua yksikköä yhdistetään Voi olla sama ohjelmoija, toteutukset ajallisesti erillään Testaus kohdennetaan yksiköiden yhteistoimintaan eli rajapintojen oikeellisuuteen ja niiden oikeaan käyttöön Oletus: yksikkötestaus suoritettu, koodi laadukasta Integrointia ja siten myös integrointitestausta tehdään monella eri tasolla Yhden pienen lisäominaisuuden integrointi, ns. jatkuvan integroinnin periaate (esim. ketterät toimintatavat) Jokapäiväinen rutiini kehittämisessä Suurehkojen erillään kehitettyjen modulien (osajärjestelmien) integrointi Vaatii erilliset testaajat ja mahdollisesti monimutkaisia testijärjestelyjä Modulin integrointi johonkin ohjelmistoalustaan tai valmiiseen ohjelmistokomponenttiin 8
Integrointitestaus Tekniikat yleensä white-box painottuneita Testausvastuu vaihtelee kehittäjien ja erillisten testaajien välillä Jatkuvassa integroinnissa testausvastuu kehittäjillä Osajärjestelmien integroinnissa vastuu erillisillä testaajilla Testauksen kohdentaminen Modulien väliset liittymät Toimiiko tiedonvälitys rajapinnoissa Toimiiko kytkentä (esim. ajoitukset realiaikajärjestelmissä, jaetut laiteresurssit) Kokonaisuus - toimivatko syntyvät toiminnot oikein? Onko väärinymmärryksiä tai vääriä tulkintoja? Esim. Nasan luotain menetettiin cm - in tulkintaeron vuoksi Integrointitestauksen strategiat Big Bang Big Bang integrointi: yksikkötestataan (jollain tasolla) kaikki yksiköt erikseen ja integroidaan ne kertarysäyksellä yhteen Ei ole yleensä hyvä idea vähänkään suuremmissa ohjelmissa! Ongelmia Virheiden paikantaminen hankalaa, ei tiedetä onko vika tietyn kahden modulin välisessä toiminnassa vai aiheutuuko se sivuvaikutuksena kauempaa vian ilmenemiskohdasta Virheitä tulee paljon kerralla, virheet peittävät toisiaan, oleellisia virheitä eit saada helposti esille Virheiden korjaus voi aiheuttaa sivuvaikutuksia muihin moduuleihin, joudutaan tekemään useita testaa-korjaa syklejä Yksikkötestaus on työläs sillä valmiita moduuleja ei päästä käyttämään hyväksi vaan kaikille on kirjoitettava apukoodit (tynkämoduulit, ajurit) Vesiputousmallin mukaisen ohjelmistokehityksen ja myös puritanistisen V-mallin tulkinnan mukainen tilanne 9
Integrointitestaksen strategiat Inkrementaalinen integrointi: Top-Down SUT 1) 2) A Ylin moduli testataan tynkien avulla 3) B F G 4) Tynkämodulit korvataan oikeilla yksi kerrallaan C D E Lisättäessä uusia moduleita, Aikaisemmat testit ajetaan uudelleen (ainakin osa) Integrointitestaksen strategiat Inkrementaalinen integrointi: Bottom-Up A SUT B F G C Testiajurit korvataan testatuilla klustereilla Yksi kerrallaan Moduleista kootaan klustereita D E Klusteri Bottom-up on eri asia kuin big bang, matalan tason moduuleja ei integroida kerralla vaan klustereittain 10
Integrointitestaksen strategiat Virheen paikantaminen Testi näyttää virhettä, mutta mistä se johtuu? Jos paikallistetaan virhe kahden modulin yhteistoimintaan, kummassa virhe on? Onko virhe rajapinnan toteutuksessa, onko se väärin ymmärretty rajapinnan spesifikaatioista, onko se moduulin toteutuksen virhe jota ei löydetty yksikkötestauksessa? Onko virhe peräisin jostain aivan muualta, sivuvaikutus? Uuden modulin integrointi voi rikkoa jo testattuja osia Lokalisointia helpottaa oleellisesti pienet inkrementit integroinnissa Rajapintavirheen korjaus vaatii usein koko järjestelmän uudelleen testauksen Integrointitestaksen strategiat Sopimuspohjainen ohjelmointi Sopimuspohjainen ohjelmointi Miinoitetaan koodia integraatiotesteillä, valvotaan ajonaikaisesti esi- ja jälkiehtojen toteutumista Jos esiehto ei voimassa, virhe kutsujassa Jos jälkiehto ei voimassa, virhe palvelun toteuttajassa Hyötyjä Rajapinnan integrointitestaus (tai ainakin osa siitä) on aina automaattisesti käytettävissä, riippumatta siitä mihin moduuli integroidaan Vähentää virheiden syntymistä koska rajapinnat paremmin määriteltyjä Ei poista erillisen integrointitestauksen tarvetta, täydentää sitä 11
Integrointitestaksen strategiat Sopimiuspohjainen ohjelmointi /** Palauttaa x:n neliöjuuren. * @.pre x >= 0 * @.post Math.abs(RESULT * RESULT - x) * < 1.0e-10.0 & RESULT >= 0.0 */ public static double neliöjuuri(double x) //-- Alkuehto assert x >= 0.0 : "Alkuehtorikkomus"; //-- Totetus double tulos; // Lasketaan neliöjuuren arvo muuttujaan tulos... //-- Loppuehto assert tulos >= 0.0 : "Loppuehtorikkomus"; assert Math.abs(tulos * tulos - x) < 1.0e-10.0 : "Loppuehtorikkomus"; //-- Paluuarvo return tulos; } Integrointitestaksen strategiat Vertailua Arkkitehtuurin testaus ja arkkitehtuuritason virheet Top-down löytää todennäköisemmin virheitä arkkitehtuurista aikaisessa vaiheessa Bottom-up testing ei vaadi arkkitehtuurin kiinnittämistä ketterä ohjelmistoprosessi mahdollinen Järjestelmän toiminta Top-down antaa toimivan järjestelmän heti alussa demonstraatio, protoilu, motivaattori, varhainen järjestelmätestaus Bottom-up antaa myös toimivia kokonaisuuksia nopeasti mikäli toteutus suunnitellaan tämän tavoitteen mukaisesti toiminnalliset klusterit 12
Integrointitestaksen strategiat Vertailua Testien toteuttaminen Top-down vaatii tynkämodulien toteuttamisen, mikä on usein työlästä Bottom-up vaatii ajurien toteutuksen, usein helpompaa Tulosten kerääminen Top-down rakentamisessa yleensä ylimmät (kontrolli-) tasot eivät tuota mitään näkyvää tulostetta pitää toteuttaa tynkiin ylimääräisiä toimintoja raportoimaan mitä järjestelmässä tapahtuu Varhaisessa järjestelmätestauksessa usein tavoitteena ongelman ja ohjelman parempi ymmärrys asiakaspalautteen kautta Bottom-up vaatii usein ajureihin testattavien modulien toimintaa tarkkailevia ja tuloksia kerääviä osia. Käytännössä käytetään melkein aina yhdistelmää molemmista strategioista Bottom-up painottuu olio- ja komponenttipohjaisissa järjestelmissä Integrointitestaksen strategiat Realistinen, yhdistelmä Käytännössä molempia integrointisuuntia sovelletaan tilanteen mukaan Ohjelman rakentamisessa on etupäässä muista kuin testauksesta johtuvia syitä joiden perusteella integrointistrategia laaditaan Asiakkaan palautteen varhainen saanti Kriittisten tai erityisen vaikeiden osien varhainen toteutus teknisten riskien minimoimiseksi Monitiimisen kehityksen hallinta ja kustannuslogiikka Testauksen usein mukauduttava Pidettävä mielessä testauksen tavoitteet Oleellisten virheiden varhainen löytyminen Kehittämisen aikaisen laatuinformaation tuottaminen Testauksen kustannusten optimointi (ei minimointi joka tapahtuisi siten ettei testata :-) V-mallin testaustasojen väliset synergiat 13
Integrointitestauksen toteuttaminen Testauksen tavoitteisiin pyrittäessä ei ole olemassa mitään ehdottomia sääntöjä Tilanteenmukainen ja luova toiminta Kehittämisen aikainen kehittämistä tukeva arkkitehtuuri Järjestelmän arkkitehtuurissa on usein hierarkinen moduulirakenne Perusteluna mm. rinnakkainen kehittäminen, komponettiperustaisuus Integrointistrategia laaditaan tämän koostumiseen perustuvan arkkitehtuurin perusteella Testauksen kannalta kuitenkin moduulien riippuvuudet ovat paljon tärkeämpiä Riippuvuudet SUT:sta määrittävät onko kyseessä top-down vai bottom-up tilanne Yksikkötestien hyödynnettävyys integraatiotestauksessa Top-down integroinnissa suoraan hyödynnettävissä, joskaan eivät riittävät Bottom-up integroinnissa eivät testaa integroinnin SUT:ia, silti jätetään osaksi testikantaa mahdollisia tulevia muutoksia ja tulevia tynkien korvauksia varten Modernisoitu V-malli Testauksen synergiat 14
Yksikkötestien käyttö integrointitestauksessa SUT SUT Yksikkötestien käyttö integrointitestauksessa SUT 15
Tynkämoduleista Tynkämodulien käytölle on monia muitakin syitä kuin se että vastaava moduli on vielä toteuttamatta Ei haluta testata moduulia todellista moduulia vastaan Käyttö raskasta tai monimutkaista (esim. konfigurointi) Testiympäristön luonti työlästä tai mahdotonta Kontrollointi vaikeata Laitteistoja emuloidaan tynkämoduleilla yleisesti Laite ei saatavilla ohjelmistonkehitysympäristössä Laite ei stabiili Useita laiteympäristöjä, emuloinnilla testauksen automatisointi Testataan äärikäyttäytymistä, todellinen laite ei generoi ääriarvoja Testataan vikasietoisuutta eikä haluta oikeasti rikkoa laitetta Tynkämodulit ovat olennainen tekniikka käytännön testauksesa Esimerkki - Varhainen virheiden löytäminen SUT SUT hajautunut eri arkkitehtuurin yksiköihin Testausjärjestely C:n ja A:n varhaiseen integrointitestaukseen 16
Esimerkki - Testauksen kapselointi kehityksen aikana SUT Esimerkki - Testauksen kapselointi kehityksen aikana PalkanlaskuTest on samanaikaisesti sekä ajuri että tynkätietokanta Ajaa testitapauksia Kaappaa tietokantakutsut ja antaa niille tynkätoteutuksen Erittäin suuri kontrolli testaukseen Voidaan esimerkiksi tehdä testitapaus jonka pitäisi generoida virhe tietokantahaussa, palauttaa tuo virhe tynkätietokannasta ja testata miten SUT sen käsittelee Testitapausten suunnittelu yhdenmukaistuu, toteutus yhteen paikkaan Jotta yksikkötason (SUT = Palkanlasku) testitapaukset olisivat uudelleenkäytettävissä seuraavan vaiheen testauksessa (SUT = Palkanlasku + Tietokanta), on PalkanlaskuTest toteutettava niin että ajurin ja tyngän roolit on erotettavissa toisistaan Tynkä korvataan Tietokannan toteutuksella, ajuri ja testitapaukset uudelleenkäytettävissä 17
Esimerkki - Testauksen kapselointi kehityksen aikana Koko testaus on kapseloitu PalkanlaskuTest moduliin siten että järjestemä ei ole siitä lainkaan tietoinen 18