CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen Kevät 2015

Transkriptio

1 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen Kevät 2015

2 NOPEA KERTAUS

3 TESTAUS HYVIN LYHYESTI Miten normaali testaajan arki ohjelmistoprojektissa sitten rullaa? Käytännössä testauksessa on aina kolme tahoa: Testauksesta vastaava esimies (projektipäällikkö, testipäällikkö tjs.) Testaaja Kehittäjät Lisäksi testauksessa on aina kolme asiakokonaisuutta: Testaussuunnitelma (miten testataan) Testitapaukset (asiat joita pitää kokeilla) Testiraportti (yhteenveto siitä miten asiat sujui sekä siitä mitä tehtiin.)

4 TESTAUS HYVIN LYHYESTI 1. Testipäällikkö, kehittäjät ja testaajat luovat testaussuunnitelman ja ensimmäiset testitapaukset teknisten suunnitelmien pohjalta jotta työt päästään aloittamaan. 2. Kehittäjät toteuttavat järjestelmään komponentteja, sekä tekevät niiden yksikkötestauksen. 3. Testaajat ja kehittäjät suunnittelevat järjestelmään täydentäviä testitapauksia sen pohjalta miten tuote lähtee toteutumaan. 4. Testaajat kokeilevat komponentteja tehdyillä testitapauksilla, ja jos jokin ei toimi, kirjoittavat niistä ilmoituksen kehittäjille. 5. Kehittäjät ottavat saadut ilmoitukset työn alle ja korjaavat viat kriittisimmistä ja riskialttiimmista aloittaen. 6. Kehittäjät tuottavat samaan aikaan lisää uusia komponentteja. 7. Sitä mukaa kun komponentteja valmistuu, niitä liitetään projektiin samalla integrointitestausta tehden. Jos jokin ei toimi, siitä tehdään uusi testitapaus.

5 TESTAUS HYVIN LYHYESTI 8. Kun kaikki komponentit on tehty ja integroitu, siirrytään testaamaan järjestelmää kokonaisuutena. Jos vikoja löytyy, siitä tehdään testitapauksia jatkoa varten. 9. Kun kaikki merkittävät viat on korjattu, siirrytään hyväksymistestaukseen. 10. Jos hyväksymistestauksessa löytyy ongelmia, niistä tehdään testitapaukset ja ne korjataan. 11. Kun asiakas, hyväksyjä tai vastaanottaja on tyytyväinen järjestelmään, se on valmistunut. 12. Laaditaan loppuraportti; dokumentit, lähdekoodi ja muut osat talletetaan ylläpitoa, korjauksia sekä jatkoprojekteja varten. 13. Jos tuotteeseen tehdään päivityksiä, lisäyksiä tai korjauksia, tapahtuu samat asiat mutta pienemmässä mittakaavassa; alkuperäiset testitapaukset säilytetään osana regressiotestejä.

6 TESTAUKSEN V-MALLI

7 TESTAUSTASOT CT60A4150 Ohjelmistotestauksen perusteet

8 TESTAUKSEN TASOT Testauksen tasoiksi sanotaan normaalisti V- mallin mukaisia eri kokoluokan testausvaiheita. Yksikkötestaus(, Moduulitestaus, Komponenttitestaus ) Integrointitestaus Järjestelmätestaus Hyväksymistestaus Eri tasoilla testataan erilaisia asioita: perusrakenteita, yhdenmukaisuutta, osien yhdessä toimimista, järjestelmän toimintaa testialustalla, toimintaa oikeassa käyttöympäristössä.

9 MODUULITESTAUS moduulitestaus = komponenttitestaus = yksikkötestaus Ohjelmistokomponentti on koodirivistä koostuva ohjelman erillinen osa, esim. matemaattinen funktio. Testaajalla on oltava käytössään ohjelman lähdekoodi ja kyseisen komponentin määrittelyt. Testauksen tarkoitus on verrata komponentin toimintaa komponentin toiminnallisiin määrittelyihin ja komponentin rajapintojen spesifikaatioihin. Useimmissa tapauksissa testattavan yksikön oikea ympäristö ohjelmistossa ei vielä ole valmis. Myöskään komponenttiin liittyvät muut komponentit eivät välttämättä ole valmiita liitettäväksi testattavaan komponenttiin, tai niiden toiminta on vielä testaamatta. Testiympäristö (myös nimellä testipeti) koostuu ohjelmakomponentin ympäristöä jäljittelevistä testiajureista ja testityngistä, jotka kutsuvat komponentin funktioita, palauttavat komponentille arvoja ja mahdollistavat saatavien tulosteiden tarkastelun.

10 YKSIKKÖTESTAUS

11 YKSIKKÖTESTAUS, MODUULITESTAUS Yksikkötestaus on maailman tavallisin testauksen muoto. Käytännössä kaikki ohjelmisto testataan jossain vaiheessa yksikkötasolla kaikki organisaatiot tekevät yksikkötestausta. Yksikkötestauksessa keskitytään yhden moduulin tai komponentin tarkastamiseen ja kokeilemiseen. Monesti yksikkötestauksen tekee itse ohjelmoija, kehitys/muutostyön yhteydessä tai vähintäänkin heti työn valmistumisen jälkeen. Viimeistään silloin, kun uusi moduulin versio lisätään projektin kehitysversioon, tehdään yksikkötestaus.

12 YKSIKKÖTESTAUS (UNIT TESTING) Tavallisesti Musta Laatikko- tai Lasilaatikko-testausta johtuen siitä, että tällä tasolla yksityiskohtien määrä on vielä jollain tapaa rajallinen virheet havaittavissa yksityiskohdista. Testiajurit, -tyngät, mockupit (Mock objects, studs) korvaamassa oikeita komponentteja ja lähettelemässä sekä vastaanottamassa syötteitä.

13 YKSIKKÖTESTAAJAN MUISTILISTA Mitkä asiat pitäisi uudesta moduulista tarkastaa? Syötteiden tyypit, raja-arvot Erilaiset käyttäjän antamat syötteet Toiston ohjaus (off-by-one-virheet) Muistivuodot (kasvaako rakenteiden koot oikein toimenpiteiden myötä?) Valintarakenteiden testauksen koodikattavuus/haarakattavuus/päätöskattavuus sekä parametrilogiikka Vääränmuotoiset, väärässä järjestyksessä tulevat, välistä puuttuvat viestit (protokollassa) Muuttujien ja sisäisten metodien näkyvyys Koodin luettavuus, kommentit, ohjelmointikäytännöt (coding conventions) Erikoismerkkien käsittely, muut erikoistapaukset (mikäli aiheellista)

14 YKSIKKÖTESTAUS VS. AD-HOC-TESTAUS Ad-hoc-testaus, ad-hoc-testailu, tarkoittaa sitä, että vähän kokeiltiin, kyllä sitä jossain vaiheessa testattiin jne. Organisoimatonta toimintaa ja vähän kokeilemista kaikilla testauksen tasoilla. Ei siis mitään tekemistä varsinaisesti yksikkötestauksen kanssa.

15 INTEGROINTITESTAUS

16 INTEGROINTITESTAUS Yksikkötestauksen jälkeen, ja yleisesti ohjelmaa rakentaessa, yksiköt integroidaan isommiksi kokonaisuuksiksi. Integrointitestauksessa testataan yksiköiden rajapintoja ja niiden yhteistoimintaa. Kannattaa hyödyntää mahdollisuuksien mukaan testiautomaatiota kuten automatisoituja savutestejä.

17 INTEGROINTITESTAUS 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ä 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, muutostöitä, optimointia ja muuta vastaavaa. Mahdollisia epäsuoria riippuvuuksia yksiköiden välillä: Yksikkö välittää dataa toiselle, joka paketoi datan kolmannelle. Yksiköt eivät tiedä toisistaan, mutta kolmas yksikkö käyttää niitä molempia. Koheesio (cohesion), liittymät (coupling), kapselointi (encapsulation) Olio-ohjelmoinnin perusajatukset!

18 INTEGROINTITESTAUS Kolme tapaa integroida: Kertarysäys, aka. Big Bang-integrointi Virrat päälle-savutesti Inkrementaaliset menetelmät Ylhäältä alaspäin (Top-down) Alhaalta ylöspäin (Bottom-up)

19 BIG BANG, KERTARYSÄYS-INTEGROINTI Ajatuksena yksikkötestata jokainen komponentti erikseen, ja laittaa kaikki kerralla kiinni toisiinsa. Voi toimia pienissä ohjelmissa, mutta Rajapinnat pitäisi testata yksikkövaiheessa, paljon työtä ja ylimääräisiä tynkiä. Vian oikea syy voi olla vaikea löytää koska ei tiedetä yksittäisten moduulien välisistä ongelmista tai toimivuudesta. Kun yksi asia korjataan, kaikki pitää testata uusiksi koska ei voida tietää mitä muuta voi olla korjauksen takia vialla.

20 BIG BANG, KERTARYSÄYS-INTEGROINTI Yksikkötestattu komponentti Testattava osa ohjelmasta

21 INKREMENTAALISET MALLIT Inkrementaaliset, eli lisäävät, mallit perustuvat ajatukseen jossa moduuleja lisätään yksi kerrallaan. Yksi kerrallaan lisätään osia tai palveluja, kunnes koko järjestelmä koottu. Ajatuksena se, että kun vikoja löytyy, on vian aiheuttajasta ja paikasta hyvä varmuus. Kokonaisuutta ajatellen kaikkea ei tarvitse aina testata kokonaan uudelleen.

22 YLHÄÄLTÄ ALAS, TOP-DOWN Ylhäältä alas-mallissa ajatus on että ensin testataan kontrolliyksikkö (käyttöliittymä, keskusmooduli jne.) joka ohjaa kaikkea muuta. Tuodaan taso tasolta lisää osia sen mukana, mitä osia testattava komponentti kutsuu. Aloittamalla keskusyksiköstä kokoajan toimiva ohjelma, josta vain puuttuu toiminnallisuuksia joita ei vielä ole saatu lisättyä mukaan. Käytännössä kuitenkin tynkien tekeminen voi olla kallista tai työlästä.

23 YLHÄÄLTÄ ALAS, TOP-DOWN Yksikkötestattu komponentti Testattava osa ohjelmasta Integroitava komponentti Tynkä, ajuri, simuloiva osa

24 ALHAALTA YLÖS, BOTTOM-UP Periaatteessa edellisen mallin vastakohta. Aloitetaan yksikkötestaus alimman tason moduuleista. Eli niistä jotka ovat lähimpänä rautaa tai jotka suorittavat toimintoja. Laskukirjastot, tietokantayhteydet, tietoverkkoyhteys, antureiden lukeminen jne Osia lisätään aina edellisen setin päälle, muodostaen osakokonaisuuksia jotka myöhemmin liitetään yhteen. Tarvitsee ajureita, eli ohjelmia, jotka simuloivat ylempien komponenttien toimintaa. Toimiva ohjelma vasta lopussa, mutta ei tarvetta erillisille tyngille. Toisaalta eri klusterit on helppo jakaa tiimien kesken testattavaksi

25 ALHAALTA YLÖS, BOTTOM-UP Yksikkötestattu komponentti Testattava osa ohjelmasta Integroitava komponentti Tynkä, ajuri, simuloiva osa

26 INTEGROINTITESTAUKSESTA Tietysti nämä ovat vain yleisiä malleja, esimerkiksi sandwich -malli joka alkaa molemmista päistä rikkoo esitettyä mallia. Samoin ylhäältä-alas-malli jossa asiat tehdään osakokonaisuus kerrallaan eikä tasoissa. Aina ei päästä vaikuttamaan siihen missä järjestyksessä osia valmistuu. Pessimisti: Integroidaan mitä voidaan-malli. Optimisti: Aloitetaan riskialttiimmasta osasta -malli Yksikkötestaukseen tarvitaan joka tapauksessa tynkiä ja ajureita ei välttämättä niin iso menoerä. Ylimääräisen työmäärän minimointi kuitenkin hyvä idea.

27 JÄRJESTELMÄTESTAUS

28 JÄRJESTELMÄTESTAUS Järjestelmätestaus on vaihe, joka alkaa kun kaikki osat on toteutettu, yksikkötestattu ja integroitu. Järjestelmätestauksessa tavoitteena on todentaa järjestelmän teoreettinen toimintavalmius. Kaikki toiminnot oikeasti olemassa, ei kuitenkaan välttämättä lopullisessa olomuodossaan. Alpha/Betatestaus-analogia peleistä; tämä on alphatestaus. Testaus tehdään testiympäristössä, oikeaa ympäristöä (kohtuullisella tarkkuudella) simuloiden. Oikeat sensorit, oikea palvelin, oikeasti tapahtuvat toiminnot Voi kuitenkin olla mm. generoitua dataa, simuloituja käyttäjiä Sisäinen hyväksymistestaus Lisäksi työvaihe, jossa tehdään mm. käytettävyystestausta, kuormitustestausta, hyökkäystestausta jne. Yhteensopivuus muiden järjestelmien ja osajärjestelmien kanssa.

29 HYVÄKSYMISTESTAUS Hyväksymistestaus

30 HYVÄKSYMISTESTAUS Testaus, tai oikeammin tarkastus, oikeassa käyttöympäristössä. Mielellään myös oikeilla käyttäjillä. Ja oikealla datalla. Ei enää oleteta merkittäviä muutoksia, tarkastetaan että kaikki toimii kuten oli tarkoitus ja osoitetaan että tuote on valmis. Tietysti löytyvät viat korjataan. Jatkokehitystarpeet omaksi uudeksi projektiksi, koska tässä vaiheessa muutokset on sietämättömän kalliita. Sisältää myös ei-teknisten osien tarkastukset: ohjekirjat, dokumentaatiot, koulutusmateriaalit, tukitoiminnot jne. Periaateessa viimeinen tarkastus sille, onko tuote valmis käyttöönotettavaksi (tai myyntiin laitettavaksi). Vrt. Beta-vaihe peleissä

31 TESTAUKSEN ERILAISIA OSA-ALUEITA Edellisissä kalvoissa mainittiin erilaisia testausmenetelmiä. Erilaisilla menetelmillä testataan järjestelmää erilaisten vikojen havaitsemista, tunnistamista ja poistamista varten. Testausmenetelmät ovat erilaisia tapoja testata asioita, kun tasot taas tarkoittavat testauksen kokoluokkaa. Samaa menetelmää voi käyttää eri tasoilla: esimerkiksi rasitustestin voi tehdä yhdelle moduulille, yhdelle osalle tai koko järjestelmälle. Näistä puhutaan ensi kerralla.

32 TESTAUKSEN PERIAATTEITA ISTQ-B:N MUKAAN Ja sitten lopuksi vielä jotain ihan muuta:

33 PERIAATE 1: TESTAUS OSOITTAA VIKOJEN OLEMASSAOLON Testauksen tehtävänä on näyttää että testatussa ohjelmistossa on vikoja, sekä pienentää todennäköisyyttä sille, että ohjelmasta löytyy edelleen vikoja. Se, että testaus ei löydä yhtäkään vikaa ei kuitenkaan takaa, että tuotteessa ei ole vikoja.

34 PERIAATE 2: TÄYDELLINEN TESTAUS ON MAHDOTONTA Kuten aiempi esimerkki osoitti, ei täydellinen testaus ole mahdollista kuin triviaaleissa tapauksissa. Kaikkialla muualla testauksen pitäisi perustua riskien kartoittamiseen sekä tehtävän testaustyön priorisointiin.

35 PERIAATE 3: AIKAINEN TESTAUS Testaus pitää aloittaa mahdollisimman aikaisin, jo esituotantovaiheessa. Testauksen tulee kattaa myös vaatimusmäärittelyt ja projektia varten tehdyt suunnitelmat.

36 PERIAATE 4: VIKOJEN KASAANTUMINEN Testauksen painopisteet tulisi sijoittaa niihin moduuleihin ja osiin, joissa tiedetään tai odotetaan olevan eniten vikoja. Tavallisesti viat kertyvät suhteutetusti pieneen osaan komponentteja, joten ne tulee tunnistaa ja niihin tulee keskittyä. 20% osista sisältää 80% vioista.

37 PERIAATE 5: HYÖNTEISMYRKKYPARADOKSI Jos testitapauksia ei missään vaiheessa uusita tai tarkasteta, päädytään tilanteeseen jossa ainoastaan kyseisten testien huomioimat virheet on poistettu järjestelmästä. Tämän vuoksi testitapauksia tulee päivittää, lisätä ja kehittää projektin edetessä.

38 PERIAATE 6: TESTAUS ON TILANNERIIPPUVAISTA Testausta tehdään eri tavoilla erilaisissa tilanteissa tai eri projekteissa. Tämän vuoksi testauksen hallinnointimallien tai prosessien pitää mahdollistaa riittävästi liikkumavaraa, jotta erilaiset tilanteet saadaan selvitettyä ilman että mallia joudutaan muuttamaan.

39 PERIAATE 7: VIRHEETTÖMYYDEN HARHALUULO Vikojen löytäminen ja korjaaminen ei auta, jos rakennettu järjestelmä on käyttökelvoton. Käytännössä tämä tarkoittaa sitä, että mikään testaaminen, laadunvalvontatyö tai virheiden korjaaminen ei auta jos tuote on suunniteltu väärin tai ei toteuta kaikkia niitä odotuksia, jotka tuotteelle on asetettu. You can t polish a turd.

40 MITÄ TÄSTÄ LUENNOSTA PITÄÄ MUISTAA? Testaustasot Yksikkötestaus Integrointitestaus Järjestelmätestaus Hyväksymistestaus Testauksen periaatteet