CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET. Jussi Kasurinen Kevät 2015

Transkriptio

1 CT60A4150 OHJELMISTOTESTAUKSEN PERUSTEET Jussi Kasurinen Kevät 2015

2 NOPEA KERTAUS VIIME KERROISTA

3 TESTAUSTASOT Testauksen tasot: Yksikkötestaus Integrointitestaus Järjestelmätestaus Hyväksymistestaus

4 OHJELMISTOTUOTANTO JA OHJELMISTOTESTAUS Ohjelmistotuotannon prosessi Suunnittelu Määrittely Toteutus Tarkastus Käyttöönotto Ohjelmistotestauksen prosessi Esitestaus Testauksen suunnittelu, testattavuuden arviointi Testaus eri tasoissa, regressiotestaus Käyttöönotto / hyväksymistestaus / Betatestaus Hotfixien, laajennusten testaus

5 TESTAUKSEN MENETELMÄT CT60A4150 Ohjelmistotestauksen perusteet

6 ESIMERKKI JAOTTELUSTA: SWEBOK SOFTWARE ENGINEERING BOOK OF KNOWLEDGE SWEBOK on eräänlainen ohjelmistoalan perusasioiden yhteenveto. Amerikkalainen näkökulma; Testaus on mekaaninen työ laadun mittaamiseksi ja parantamiseksi. SWEBOK määrittelee 81 erilaista testaukseen liittyvää tekniikka, joiden ymmärtäminen ja kyky soveltaa käytännössä määrittelevät IEEE:n mukaan testausinsinöörin, ammattimaiseen testaukseen kykenevän henkilön.

7

8 SWEBOK Malli on kattava, mutta se ei ota kantaa siihen, että testaustoiminta voidaan aloittaa jo ennen varsinaista mekaanista testausta. Esimerkki: vilkaistaan sisällysluetteloa! Oikealla arkkitehtuurisuunnittelulla pystytään ennaltaehkäisemään ja poistamaan varmasti vähintään saman verran virheitä kuin mitä erittäin hyvin toimivalla testauksella saadaan kiinni. Yrityksissä tehdyn tutkimuksen mukaan tärkein laadun lähde on suunnittelu- ja kehitysvaihe, ei testaus. Hyvin suunnitellusta ja ammattimaisesti rakennetusta ohjelmasta pystyy aina tekemään heikkolaatuisen testaamalla sen huonosti; Ilman kunnon suunnittelua tehdystä ei useimmiten saa korkealaatuista vaikka sitä miten jälkikäteen testaisi ja paikkailisi.

9 OHJELMISTON KRIITTISYYS Ohjelmiston kriittisyys tarkoittaa pahinta vikaa, joka ohjelmiston toimiessa virheellisesti voi sattua. Ei standardoitua asteikkoa, mutta yleisesti käytetyt asteikot seuraavanlaisia: 0: Käyttäjää ärsyttävä vika. 1: Mitätön tai pieni taloudellinen menetys 2: Merkittävä taloudellinen menetys 3: Sietämätön taloudellinen menetys, tai operaattorin tai järjestelmästä riippuvan henkilön vammautuminen. 4: Operaattorin tai järjestelmästä riippuvan henkilön kuolema.

10 SEMANTTINEN VS. SYNTAKSINEN VIRHE Syntaksiset virheet, joissa ohjelma kaatuu koska koodissa on virhe, on kohtuullisen helppo löytää yksinkertaisesti testaamalla että kaikki komponentit kääntyvät ja toteuttavat perusominaisuutensa ilman ongelmia. Täsä tekstisssä o vihreita. Semanttiset virheet, eli ongelmat jotka johtuvat siitä että koodi on oikein kirjoitettua mutta tekee vääriä asioita on taas vaikea löytää. Jos ohjelmassa on useita komponentteja ja paljon osia, voi virheiden löytäminen olla todella työlästä. Musta konsepti valaisee synergisesti keltaisia haaveilevaa laulavaa kiveä.

11 YLEISESTI KÄYTETTYJÄ MENETELMIÄ

12 PROTOTYYPEILLÄ TESTAAMINEN Ohjelmistoprojektien esituotantovaiheessa on varsin normaalia, että toteutettavan ohjelmiston käyttöliittymän suunnitteluun kiinnitetään erityisesti huomiota. Yksi syy tähän on tietysti siinä, että käyttöliittymässä tulisi olla ratkaisu kaikkien ohjelmaan suunniteltujen ominaisuuksien käyttämiseen. Monessa ohjelmassa tai laitteessa itse käyttöliittymän helppokäyttöisyys tai tapa, millä järjestelmä toimii, ovat tuotteen imagolle tärkeitä ominaisuuksia. Tämän vuoksi on varsin tavallista, että esituotantovaiheessa päädytään tekemään ohjelman prototyyppiversioita.

13 PROTOTYYPEILLÄ TESTAAMINEN Prototyyppiversiot eivät välttämättä koskaan kehity eteenpäin, niiden tarkoitus on mahdollistaa järkevämpi käyttöliittymäsuunnitelma sekä testata jo ennen kehitystyön alkamista, että ohjelman kehitys lähtee etenemään oikeaan suuntaan. Ihmiset parempia kuvailemaan toivomiaan muutoksia kuin kertomaan mistä pitäisivät. Lisäksi esimerkiksi pelialalla esituotantoprototyyppejä voidaan käyttää testaamaan pelin keskeisiä ominaisuuksia. Varmistetaan, että toteutettavassa ideassa on jotain järkeä muutenkin kuin paperilla: Proof-of-conceptprototyyppi! Osa ideoista toimii paperilla mutta ei softana; Osa ohjelmista toimii softana mutta vaikuttaa tyhmältä paperilla.

14 MUSTA LAATIKKO -TESTAUS Musta laatikko-testaus (black box testing) on testausmenetelmistä perinteisin testausmuoto ja samalla arvatenkin testaustapa, joka useimmille tulee mieleen kun puhutaan testauksesta. Musta laatikko-testauksessa ohjelmaa testataan siten, että sille annetaan syötteitä, ja katsotaan mitä ohjelma tekee, tarkastelematta sen tarkemmin sitä mitä ohjelman sisällä tapahtuu. Menetelmä on todella yksinkertainen, ja sitä voidaan käyttää oikeastaan missä tahansa testauksen työvaiheessa, missä testausta varten on käytettävissä laite, joka suorittaa jotain toiminnollisuutta.

15 MUSTA LAATIKKO-TESTAUS Musta laatikko: Syöte menee sisään, vastaus tulee ulos. Testaaja tarkastaa, onko vastaus se mitä syötteellä piti tulla. Sisäistä toimintaa ei nähdä, tai siitä ei välitetä.

16 MUSTA LAATIKKO-TESTAUS Musta laatikko-testeillä voidaan kokeillaan erilaisia käyttötapauksia, kuten esimerkiksi tiedostojen tallentamista ja avaamista, lomakkeiden syöttämistä, painikkeista tapahtuvia toimintoja Lisäksi musta laatikko-testeillä voidaan helposti tarkastaa esimerkiksi järjestelmän tapa reagoida virheellisiin tai haitallisiin syötteisiin. Testaaja ei näe mitä laitteen sisällä tapahtuu: hänen tehtäväksi jääkin lähinnä varmistaa, että annetut syötteet ovat oikein ja tarkastaa että syntyvä lopputulos vastaa toivottua lopputulosta. Testaajan ei tarvitse ymmärtää miten laite toimii, tai mitä se tekee. Työn mekaanisesta luonteesta johtuen hyvin tavallinen testausautomaation kohde.

17 LASILAATIKKOTESTAUS Lasilaatikkotestaus (tavallisimpia käännöksiä white box testing, glass box testing, clear box testing) on testauksen lähestymistapa, jossa järjestelmää testataan tarkastelemalla sen sisäistä toimintaa testauksen aikana. Menetelmä on periaatteessa yksityiskohtaisempi versio musta laatikkotestauksesta. Ohjelmalle annetaan syötteitä ja tarkastellaan tuloksia, sekä katsotaan miten järjestelmä reagoi.

18 LASILAATIKKOTESTAUS Lasilaatikkotestauksessa testaaja näkee mitä ohjelman sisällä tapahtuu ja tietää esimerkiksi sen miten annettua viestiä käsitellään järjestelmän sisällä. Testaaja pystyy lähdekooditasolle asti jäljittämään sen, mistä virhe aiheutui. Järjestelmä voidaan tarkastaa lähdekooditasolle asti, ja olla varmoja että virheettömyys ei ollut sattuma. Testaajan tosin pitää silloin myös ymmärtää, miten ja miksi laite toimii. Tapa tuottaa vastaus tarkastetaan

19 HARMAA LAATIKKO-TESTAUS Yllättäen mustan ja valkoisen laatikon menetelmiä yhdistävä testausmenetelmä on nimeltään harmaa laatikko-testaus. Musta laatikko-testauksen menetelmä läpikäydä vaatimusmäärittelystä tehtyjä testitapauksia Hyödyntäen lasilaatikkotestien kykyä tarkastella järjestelmää myös sen sisäpuolelta. Käytännössä puhutaan menetelmästä, joka pyrkii yhtäaikaisesti testaamaan mallikattavuuden että kaikki vaatimukset täytetään koodikattavuuden että kaikki lähdekoodi on varmasti tarkastettu.

20 HARMAA LAATIKKO Harmaa laatikko-testaus sopii hyvin esimerkiksi tapauksiin, jossa järjestelmää ei voida kokonaisvaltaisesti testata lasilaatikkotestien tasolla. Esimerkiksi useimmat verkkopalvelut voidaan luokitella näin; Oma järjestelmä tunnetaan ja sitä voidaan tarkastella lasilaatikkona. Järjestelmän alla toimiva palvelinratkaisu tai pilvirajapinta ovat saatavilla ainoastaan musta laatikko-palveluna jonka sisuksiin ei voida vaikuttaa tai oikeammin edes nähdä.

21 RAJA-ARVO-ANALYYSI (JA MUUT KATTAVUUSMENETELMÄT) Raja-arvo-analyysi ja esimerkiksi ekvivalenssiryhmiin jako ovat erilaisia menetelmiä määritellä testitapauksia laatikko-testeille. à Viime viikon tehtävät! Tutkitaan viereisiä arvoja, kriittisiä arvoja, sekä erilaisia kombinaatioita. Tarkoituksena normaalisti maksimoida kattavuus ja minimoida casejen määrä. Esimerkki (ISO/IEC , sivu 7)

22 REGRESSIOTESTAUS Regressiotestaaminen ei varsinaisesti ole oma, erillinen testauksen muotonsa vaan yleistermi joka kutakuinkin tarkoittaa uudelleentestaamista. Regressiotestauksesta puhutaan, kun mitä tahansa toimivan järjestelmän osaa muutetaan, ja muutoksen jälkeen halutaan varmentaa että järjestelmä toimii edelleen oikein. Regressiotestauksesta voidaan puhua myös silloin, kun kehitettävästä järjestelmästä ollaan saavutettu osatavoite (milestone), ja kyseisestä kehitysversiosta halutaan varmentaa kaikkien toimintojen oikeellisuus.

23 Ideana se, että suurin osa virheistä on uusimmassa komponentissa, tai sen aiheuttamia, tai sen esiin tuomia. Järjestelmä muuttuu à uusia virheitä tulee esiin. REGRESSIOTESTAUS

24 REGRESSIOTESTAUS Regressiotestauksen tärkein ominaisuus on todentaa, että jo kertaalleen korjatut ongelmat eivät esiinny moduuliin tehtyjen muutosten jälkeen, ja että mitään uutta ei ole mennyt rikki. Regressiotestaus ei siis ole mikään yksittäinen testauksen työvaihe kuten yksikkötestaus tai integraatiotestaus eikä menetelmä kuten tutkiva testaaminen tai musta laatikko-testaus, vaan yleisnimi kaikelle testaustyölle jolla varmistetaan että uusi versio toimii oikein.

25 AD HOC-TESTAUS, SAVUTESTAUS Ad hoc-testaus on yleisnimi testaukselle, jossa ei varsinaisesti tehdä muuta systemaattista työtä kuin että järjestelmää kokeillaan. Voidaan luonnehtia jonkinlaiseksi yleistestaukseksi, mutta ei varsinaisesti tuottavaa työtä. Ei suunniteltua, ei dokumentoitua, useimmiten yhtä hyvin voisi olla ei tehtyä. Savutestaus taas on yleisnimi big bang-tyyliselle intergointi- ja käyttöönottotestaukselle. Kaikkiin osiin samalla kertaa virta päälle, katsotaan karkaako sähkön henki koneesta. Savutesti minimitason perustesti jolla voidaan todeta onko järjestelmä valmis kokonaisuutena testaamisen aloittamiselle.

26 TAPAUSKOHTAISEMPIA TESTAUSMENETELMIÄ

27 TUTKIVA TESTAAMINEN Tutkiva testaaminen (explorative testing) on testaamisen muoto, joka ei perustu järjestelmän tarkkaan mallin mukaiseen tarkastamiseen, vaan mahdollisten vikatilojen etsimiseen ja löytämiseen. Tutkiva testaaminen on menetelmä, jossa pyritään hyödyntämään testausta tekevien ihmisten ammattitaitoa ja ymmärrystä siitä, missä virheet normaalisti ovat, miten ne syntyvät ja miten ne pystytään löytämään. Ero testailuun on siinä että työskentely systemaattista: Selailkaa katalogia, ja koittakaa saada tilausjärjestelmä hyväksymään tilaus jossa on jotain pielessä. Myös eräs käyttöliittymätestauksen muoto, ja tapa saada tyhmät virheet kiinni.

28 MALLIPOHJAINEN TESTAUS Mallipohjainen testaus (model-based testing) on yleisnimi testaukselle, jolla tarkastetaan että ohjelma toimii kuten malli määrittelee. Ohjelman malli (esim. UML-piirrustukset) hyvä lähtökohta testitapausten määrittelylle. Ajatuksena: jos malli on suunniteltu oikein ja ohjelma toimii kuten malli määrittelee, niin ohjelma on virheetön jos malli on virheetön. Kuka huomaa tässä ongelman? Malli kuitenkin hyvä lähtökohta aloittaa virheiden etsiminen ja ymmärtää miten järjestelmän pitäisi toimia.

29 KÄYTETTÄVYYSTESTAUS Käytettävyystestaus on testausvaihe, jossa painopiste on rakennetun järjestelmän käyttöliittymän toimivuudessa ja intuitiivisuudessa. Käytettävyystestaus ei varsinaisesti ole sidottu työvaiheeseen, missä suurin osa järjestelmästä on jo toteutettu ja toimii: itse asiassa iso osa käyttöliittymän suunnittelusta tehdään jo suunniteluvaiheessa. Näitä suunnitelmia voidaan hyvinkin testata vaikkapa rakentamalla yksinkertaistettuja prototyyppejä joissa ei ole muuta toiminnallisuutta kuin käyttöliittymän luonnos. Mockupit, konseptit

30 KÄYTETTÄVYYSTESTAUS Käytettävyystestaus pääsääntöisesti tarkoittaa kuitenkin testaustyötä, jolla tarkastetaan että tehdyn järjestelmän käyttöliittymä on suunniteltu oikein. Käytettävyyttä voidaan myös testata useilla erilaisilla menetelmillä. Käyttökokeilut ja niistä seuraavat haastattelututkimukset Asiantuntijatestit Kohdekäyttäjäryhmällä tutkivan testauksen tekeminen Käytettävyystestaukseen on olemassa omia työkalujaan: Katseenseurantamonitori, jonka avulla nähdään mihin käyttäjä katsoo ja kuinka pitkään. Toiminnannauhoitussovellukset jotka tallentavat kaikki käyttäjän eleet ja syötteet Taustavalvontaohjelmat, joilla voidaan huomaamattomasti valvoa tai seurata sitä mitä käyttäjä tekee Lisäksi käyttäjätestauksessa saatetaan myös nauhoittaa itse koekäyttäjää kasvojen tahattomat ilmeet ja eleet voivat kertoa paljon enemmän kuin mitä haastatellut muistavat tai haluavat kertoa.

31 MITÄ TÄSTÄ LUENNOSTA PITÄÄ MUISTAA? Erilaisia menetelmiä on useita. Eivät kuitenkaan tarkoita mitään tiettyä asiaa, vaan erilaisten vikojen löytämiseen tarkoitettuja tapoja testata. Erilaisia termejä ja nimiä on paljon, ja ne voivat tarkoittaa samantyylisiä asioita. Tavat miten testataan valitaan monesti tuotteen käyttötarkoituksen, ei pelkästään kriittisyyden pohjalta. Yksityisasiakkaan verkkopankki versus pankkienvälinen maksuliikenne.

32 RE: OHJELMISTOTUOTANTO JA OHJELMISTOTESTAUS Ohjelmistotuotannon prosessi Suunnittelu Määrittely Toteutus Tarkastus Käyttöönotto Ohjelmistotestauksen prosessi Esitestaus Testauksen suunnittelu, testattavuuden arviointi Testaus eri tasoissa, regressiotestaus Käyttöönotto / hyväksymistestaus / Betatestaus Hotfixien, laajennusten testaus

33 1. HARJOITUSTYÖ: TUTKIVA TESTAAMINEN Tällä viikolla esitellään kurssin 1. harjoitustyö. Tehtävänanto verkossa, tarkemmat ohjeet 3. harjoituskerran alustuksessa. Huomatkaa, että keskiviikon harjoitusryhmä lopetetaan tämän viikon jälkeen! Syynä vähäinen kävijämäärä. Muistakaa myös kurssin Facebook-ryhmä: