testaustekniikat - Porin yksikkÃ¶ - Tampereen teknillinen yliopisto

Tampere University of Technology, Pori 20.9.2007 

Ohjelmiston testaus t 2007 

- testaustekniikat 

Arto Stenberg 

Tampereen teknillinen yliopisto, 

Porin yksikkö, Tietotekniikka 

http://www.pori.tut.fi/ 

20.9.2007 

Ohjelmiston testaus - tekniikat © TTY Pori, Arto Stenberg 1 

The Art of Software Testing (1979) 

• Glenford J. Myers: 

• ”Software testing is a technical task, but it also involves 

some important conciderations of economics and human 

psychology.” 

• Miten erilaiset testaustekniikat pystyvät vastaamaan 

tähän haasteeseen, joka on edelleen ajankohtainen? 

• Tärkein testaustekniikka on testaajan asenne! 

20.9.2007 


Tampereen Teknillinen yliopisto 

Porin yksikkö 

© Arto Stenberg 1


Miksi testaustekniikoita käytetään? 

• Testaustekniikoiden avulla voidaan luoda paljon 

erilaisia testitapauksia ja niiden käyttäminen 

parantaa testitapausten laatua. 

• Erilaiset testaustekniikat löytävät yleensä erilaisia 

virheitä. 

• Testauksen kattavuus paranee, kun käytetään eri 

testaustekniikoita. 

• Testaustekniikat eivät ole järjestelmäsidonnaisia, 

vaan niitä voidaan soveltaa kaikenlaisissa 

järjestelmissä. 

20.9.2007 




Testauksen hallinta 

• Testauksen hallinta tarvitsee omat tekniikkansa: 

• Täydellinen testaaminen on mahdotonta. 

• Kaikki ei aina mene putkeen… 

• Riskipohjainen testaus on oiva apuväline testauksen 

hallinnan apuvälineeksi: 

• Riskeistä keskusteleminen on helpompaa kuin uskotaan. 

• Projektin alussa tehtynä ohjaa tekemistä koko projektin ajan, 

eli pitää myös päivittää säännöllisesti. 

• Hieman eri asia kuin perinteinen riskienhallinta. 

• Yritys- ja järjestelmäkohtaista. 

20.9.2007 




© Arto Stenberg 2


Esimerkki käytöstä 

Riski 

Käytön 

tiheys 

Vaikutus 

Muutos 

Moni- 

mutkaisuus 

Yhteensä 

Painoarvo 

5 10 1 5 

Testauksen 

kohde 

Ominaisuus 

5 

3 

3 

1 

63 

Toiminta 5 

5 

1 

1 

81 

Komponentti 

3 

3 

3 

1 

53 

20.9.2007 




Testaaminen ja testaustekniikat 

• Analysoi testauksen kohde. 

• Määrittele, mitä testaat. 

• Määrittele, millä kattavuudella testaat 

• Määrittele, miten / mihin vertaat testien tuloksia. 

• Määrittele testausympäristö. 

• Aja testitapaus testausympäristössä. 

• Havainnoi, mitä testin aikana tapahtuu. 

• Arvioi tulokset. 

20.9.2007 




© Arto Stenberg 3


Testaustekniikka käytännössä 

Lähde- 

dokumentti 

Valitse sopiva 

testaustekniikka 

Testauksen 

kohde 

Luo testitapaukset, 

poista epäoleelliset 

ja priorisoi. 

Suorita testit 

ja arvioi tulokset 

sekä kattavuus. 

20.9.2007 




Missä järjestyksessä testataan? 

1. Aloitetaan helpommilla testeillä, joissa ei pitäisi 

olla ongelmia. 

2. Tutkitaan testauksen kohteen toiminnallisuutta ja 

koetetaan ymmärtää sen toimintaa ja merkitystä. 

3. Testataan kohdetta ensin yleisesti ja mennään 

vasta myöhemmin yksityiskohtiin. 

4. Lisää testien vaikeusastetta, käytä erilaisia 

testaustekniikoita. 

5. Ajattele testausta erilaisista lähtökohdista ja keksi 

jotain uutta testattavaa. 

20.9.2007 




© Arto Stenberg 4


Testitapauksen tuloksen arviointi 

• Testitapaus meni läpi: 

• täyttääkö testauksen kohde kaikki sille asetetut vaatimukset 

• täyttikö vain jotkut vaatimukset osittain 

• Testitapaus ei mennyt läpi: 

• löytyikö ongelma / virhe 

• kuinka vakava se on 

• onko ensivaikutelmaa vakavampi 

• onko huomattavasti yleisempi 

20.9.2007 




Ei speksejä, mihin vertaillaan? 

• Toimii järjestelmän tarkoituksen mukaisesti. 

• Toimii samalla tavalla kuin aikaisempi järjestelmän 

versio. 

• Toimii samalla tavalla kuin muutkin vastaavat 

järjestelmät. 

• Toimii yhtäläisesti tuotteesta annettujen lupausten 

kanssa (mainokset + standardit + muut lupaukset). 

• Täyttää käyttäjien odotukset (tai ainakin ne 

odotukset, jotka tiedämme tai arvaamme). 

• Täyttää yrityskuvan vaatimukset (millainen kuva 

yrityksestä syntyy tämän tuotteen kautta). 

20.9.2007 




© Arto Stenberg 5


Testitapausten priorisointi 

• Prioriteetti 1: 

• nämä testit on mentävä läpi ennen julkaisua 

• löydetyt t virheet pitää olla korjattuna ja testattunat tt 


• nämä testit pitää olla suoritettuna ennen julkaisua 

• löydetyt virheet korjataan ja testataan vikaluokittelun mukaisesti 


• jos aikaa riittää, niin nämä testit suoritetaan 



• nämä testit testataan julkaisun jälkeen tai myöhemmin 


20.9.2007 




Eri testaustekniikoiden jakoja 

• Staattiset – dynaamiset: 

• kohdistuuko testaus vaihetuotteisiin, vai onko suoritettavaa 

koodia 

• White box – black box: 

• mitataanko testauksen koodikattavuutta 

• Systemaattiset – ei-systemaattiset: 

• johdetaanko testitapaukset suoraan järjestelmän kehityksen 

aikana luodusta dokumentaatiosta vai saako testaaja 

käyttää ”luovuuttaan” 

• Toiminnalliset – ei-toiminnalliset: 

• testataanko pelkästään järjestelmän toiminnallisuutta vai 

myös muita järjestelmän laatuominaisuuksia (testilajit) 

20.9.2007 




© Arto Stenberg 6


Staattiset testaustekniikat 

• Katselmukset ja tarkastukset: 

• kohdistuvat vaihetuotteisiin, eli kaikenlaiseen 

ohjelmistokehityksessä syntyneeseen dokumentaatioon 

• löytävät virheitä tehokkaammin oikein suoritettuna kuin 

dynaaminen testaus 

• parannetaan vaihetuotteiden laatua, jolloin lopullisen tuotteen laatu 

paranee 

• löydetään virheet aikaisemmin ja estetään niiden kertaantuminen 

(turha työ vähenee) 

• projektin yleinen tuottavuus nousee ja projekti nopeutuu, koska 

aikaa pitäisi säästyä testausvaiheessa 

• prosessin parantaminen löydettyjen vikojen analysoinnin ansiosta 

20.9.2007 




Staattiset testaustekniikat 

• Koodin staattinen analysointi: 

• koodi on mennyt kääntäjästä läpi ja kääntäjän löytämät 

virheet on korjattu 

• käytetään yleensä työkalua (staattinen analysaattori) 

• tutkitaan metriikkaa: koodin kompleksisuus (McCabe:n luku) 

• lint-tyyppiset työkalut: erilaiset koodausvirheet 

• koodaustyylin tarkastajat 

• löytävät mm. alustamattomia muuttujia, muistivirheitä, 

kuollutta koodia 

20.9.2007 




© Arto Stenberg 7


Tutkimustuloksia 

• Virheiden määrän väheneminen kymmenesosaan 

testauksen alkaessa, testauksen kustannukset 

pienenivät i 50-80%. 

• Aikataulu nopeutui 25%, joka vaiheessa poistettiin 

80-95% virheistä, ylläpitokustannukset vähenivät 28- 

kertaisesti. 

• IBM: jokainen tarkastuksiin käytetty tunti säästi 20 

tuntia testauksesta ja 82 tuntia lisätyötä verrattuna 

siihen, jos vikaa ei olisi löydetty tarkastuksessa. 

astu sessa 

• Kahdeksan vuotta kehitetty systeemi, josta tehtiin 

viisi julkaisua; tarkastuksissa löydettiin 3512 vikaa, 

testauksessa 90 ja asiakkaan toimesta 35. 

20.9.2007 




Vaihtoehtoja 

Tyyppi 

Tarkastus 

Katselmointi 

Suunnittelu Valmistelu Kokous Korjaus Valvonta 

Kyllä Kyllä Kyllä Kyllä Kyllä 

Kyllä Kyllä Kyllä Kyllä Ei 

Läpikäynti 

Kyllä Ei 

Kyllä Kyllä 

Ei 

Pariohjelmointi 

Kyllä Ei Jatkuvaa 

Kyllä 

Kyllä 

Paritarkastus 

Ei 

Ei 

Ehkä 

Kyllä 

Ei 

Ad hoc Ei Ei Ehkä Kyllä Ei 

20.9.2007 




© Arto Stenberg 8


Staattisen testauksen suunnittelu 

• Miksi katselmoidaan / tarkastetaan: 

• tärkeintä on johdon ja henkilöstön sitoutuminen 

• Mitä tarkastetaan / katselmoidaan: 

• mitä dokumentteja projektin aikana tuotetaan 

• mitkä dokumentit ovat tärkeitä 

• mitkä osat dokumentista ovat tärkeitä 

• Osallistujien valinta eri tilaisuuksiin: 

• asiantuntemus, roolit ja osallistujien kuormitus 

• Projektin ajasta kuluu tarkastuksiin ja 

katselmointeihin (arvio): 

• 5 – 15% työajasta (10% on puoli työpäivää viikossa) 

20.9.2007 




Materiaalin kypsyys 

Dokumentin 

runko 

Raaka- 

versio 

Valmis 

dokumentti 

Ad hoc Paritarkastus Läpikäynti Katselmus Tarkastus Läpikäynti 

Mitä dokumentteja projektin aikana tuotetaan? 

Mitkä dokumentit ovat tärkeitä? 

Mitkä osat dokumentista ovat tärkeitä? 

20.9.2007 




© Arto Stenberg 9


Dokumentin tarkastaminen 

• Yhden tarkastuspalaverin (2h) aikana tarkastetaan 

huolellisesti: 

• dokumentti: 1 – 10 sivua 

• koodi: 100 – 500 riviä 

• Ison dokumentin tarkastaminen: 

• kerralla kokonaan vai osittain (monta palaveria)? 

• jokaiselle oma osuus tarkastettavaksi? 

• tarkastetaan vain tärkeimmät osat dokumentista? 

• Muut tarkastuksen aikana huomioitavat dokumentit: 

• lähdedokumentit, ohjeet, tarkastus- ja vikalistat 

20.9.2007 




Tarkastus- tai vikalistat 

• Auttavat löytämään vikoja ja levittävät ns. best 

practice – käytäntöjä. 

• Mielellään yhden sivun mittaisia: 

• noin 25 kysymystä, eli ei kaikkia mahdollisia kysymyksiä, 

vaan tärkeimmät 

• Yleensä kysymysmuodossa: 

• yksiselitteinen kysymys, negatiivinen vastaus tarkoittaa 

mahdollista virhettä 

• eivät saa olla ristiriidassa ohjeiden kanssa 

• voi käyttää vakavuusluokittelua 

• Vikalista on lista jonkin vaiheen eniten tehdyistä 

virheistä. 

20.9.2007 




© Arto Stenberg 10


Tarkastuksen ja katselmuksen erot 

• Suomessa nämä termit ovat sekoittuneet: 

• tarkastuksella tarkoitetaan yleensä yhteen vaihetuotteeseen 

(dokumenttiin) kohdistuvaa laadun tarkastelua 

• katselmuksella tarkoitetaan yleensä projektin jonkun 

vaiheen päättymisen toteaminen, jolloin tarkastetaan onko 

kaikki siinä vaiheessa suunnitellut työn tehty 

• termien merkitys voi vaihdella yrityksestä toiseen 

• Kansainvälisesti määriteltynä tarkastukset ovat 

formaaleja tapahtumia, katselmukset ovat 

vapaampia, mutta molemmat kohdistuvat yhteen 

dokumenttiin. 

20.9.2007 




Katselmus (review) 

• Arviointi (audit): 

• arvioinnin kohteesta yrityksestä riippumattoman tahon 

(esim. ISO 9000 sertifikaatin antaja) suorittama yrityksen 

prosessin tai projektin arviointi, jossa tarkastetaan, että 

toiminta on laatujärjestelmän mukaista 

• sisäinen arviointi on yrityksen itsensä tekemä 

• Johdon katselmus (management review): 

• yrityksen johto arvioi yrityksensä toimintaa 

• joskus tarkoitetaan samaa asiaa kuin sisäisessä arvioinnista 

20.9.2007 




© Arto Stenberg 11



• Projektikatselmus: 

• projektin ohjaus- tai johtoryhmän suorittama menettely, 

jossa todetaan vaiheen päättyminen 

• on etukäteen ilmoitettu projektisuunnitelmassa 

• tehdään tärkeimmissä etapeissa ja kattaa kaikki sen 

vaiheen vaihetuotteet 

• dokumentit tuotettu, ohjeistuksen vaatimat asiat suoritettu, 

asetetut kriteerit täytetty 

• tarkoituksena on tehdä projektin eteneminen ulospäin 

näkyväksi => runsaasti osanottajia, myös ulkopuolisia 

20.9.2007 





• Epäformaali katselmus: 

• informal review, buddy review 

• esim. työkaveri katsoo dokumentin läpi ja kertoo 

mielipiteensä 

• Tekninen katselmus tai vertaiskatselmus: 

• technical / peer review 

• pohditaan teknisiä asioita ja ratkaisun oikeellisuutta 

• Läpikäynti: 

• walkthrough 

• tekijä esittelee oman dokumenttinsa ja vastaa kysymyksiin 

• hyvä koulutustilaisuus 

20.9.2007 




© Arto Stenberg 12


Tarkastus (inspection) 

• Tarkastetaan, että dokumentti: 

• on lähteidensä kanssa mahdollisimman virheetön 

• täyttää ttää sääntöjen, ohjeiden, prosessin yms. vaatimukset 

t 

• Varsinainen tarkastustilaisuus pidetään, jos kaikki ovat 

tarkastukseen osallistuvat ovat valmistautuneet huolella. 

• Etsitään virheitä, eli pyritään välttämään turhaa keskustelua. 

• Kerätään metriikkaa: 

• löydetyt virheet + ajankäyttö 

• voidaan osoittaa tarkastusten tehokkuus 

• tietoja voidaan käyttää prosessin parantamiseen, jolloin estetään 

ennalta virheiden syntyminen 

20.9.2007 




Johtaja / moderaattori 

• Tuntee hyvin tarkastusprosessin ja vastaa sen 

noudattamisesta: 

• vastaa entry ja exit kriteerien i valvomisesta 

• seuraa dokumentin korjausta tarkastuspalaverin jälkeen 

• huolehtii metriikan keräämisestä 

• Auttaa, motivoi, neuvoo eli toimii mentorina: 

• voi suunnitella tarkastuksen yhdessä tekijän kanssa 

• huolehtii ilmapiiristä, luo kulttuuria ja on diplomaattinen 

• Johtaa tarkastuspalaveria: 

• huolehtii tehokkuudesta, pitää kiinni aikarajoista 

• lopettaa turhan keskustelun 

• huolehtii ja aktivoi osallistujia niin, että jokainen tarkastaja kertoo 

kaikki löydöksensä 

20.9.2007 




© Arto Stenberg 13


Sihteeri ja esittelijä 

• On yleensä dokumentin tekijä. 

• Esittelijä esittelee kohteena dokumentin. 

• Sihteeri kirjaa löydetyt virheet, puutteet ja muut 

kommentit pöytäkirjaan: 

• kysyy tarkentavia kysymyksiä, mutta ei kirjaa mitään 

ylimääräistä 

• diplomaattisesti voidaan virheiden sijaan puhua löydöksistä 

20.9.2007 




Tarkastaja 

• Asiantuntija, jolla on omaa näkemystä. 

• Voi olla myös noviisi, koska hän kyseenalaistaa luultavasti 

toisenlaisia asioita. 

• Uhraa riittävästi aikaa valmistautumiseen. 

• Projektissa mukana olevia henkilöitä dokumentista riippuen: 

• projektipäällikkö, laatupäällikkö, testauspäällikkö 

• edellisestä / seuraavasta ohjelmistotuotannon vaiheesta 

• tarpeen mukaan dokumentista riippuen voivat olla projektin 

ulkopuolisia henkilöitä: markkinointi, laki, koulutus, dokumentointi, 

tuki, asiakas 

• Kertoo kaikki löydöksensä tarkastuspalaverissa: 

• löydetyt virheet ja muut parannusehdotukset 

• Etsii palaverin aikana uusia virheitä. 

20.9.2007 




© Arto Stenberg 14


Muistilista 

• Johtaja: 

• huolehdi tehokkuudesta 

• lopeta turha keskustelu nopeasti 

• pakota kaikki tarkastajat osallistumaan 

• Tarkastaja: 

• valmistaudu huolellisesti 

• etsi virheitä, älä ratkaisua 

• muista hienotunteisuus tekijää kohtaan 

• Tekijä: 

• älä tuo keskeneräistä työtä tarkastettavaksi 

• älä ota löydöksiä henkilökohtaisesti 

20.9.2007 




Tarkastusprosessi 

Tarkastus- ja katselmointisuunnitelma 

Ohjelmistotuotannon vaihe 

Muutosehdotukset 

Prosessin 

parantaminen 

Suunnittelu 

Alustuspalaveri 

Valmistautuminen 

Tarkastuspalaveri 

Dokumentin 

korjaus 

Ohjelmistotuotannon vaihe 

20.9.2007 




© Arto Stenberg 15


Ajankäyttö tarkastusprosessissa 

• Suunnittelu ja alustuspalaveri


Aloituspalaveri 

• Ei ole pakollinen. 

• Kaikki tarkastukseen osallistuvat ovat paikalla. 

• Kaikki tarpeelliset dokumentit esitellään ja jaetaan 

osallistujille. 

• Tarkastusryhmän jäsenille annetaan mm. lukuohjeet 

ja -roolit: 

• lukuroolit: loppukäyttäjä, testaaja, suunnittelija, huolto jne. 

• lisäinfoa mm. tarkastusten yleisestä metriikasta, 

valmistautumisen kestosta jne. 

• Keskustellaan, jos on jotain epäselvää. 

• Sovitaan lopullisesti varsinaisen tarkastuspalaverin 

aika ja paikka. 

20.9.2007 




Valmistautuminen 

• Tarkastuksen tärkein vaihe, koska tässä vaiheessa 

löydetään jopa 70 - 95% kaikista tarkastuksessa 

löytyvistä tä vioista. 

i • Tehokas dokumentin tarkastusvauhti on yleensä 

hitaampi kuin normaali lukemisvauhti. 

• Perehtyminen tarkastettavaan dokumentin osaan 

sovitun roolin puitteissa: 

• oheisdokumentaation hyväksikäyttö 

• virheiden, puutteiden, ongelmien yms. etsiminen, niiden 

kirjaaminen / merkitseminen ja mahdollisesti luokitteleminen 

• Tarkastajat ottavat yhteyttä tarkastuksen johtajaan, 

jos ilmenee ongelmia esim. ajankäytön suhteen. 

20.9.2007 




© Arto Stenberg 17


Tarkastuspalaveri 

• Yhden palaverin kestoksi suositellaan kahta tuntia. 

• Ei pidetä, jos enemmän kuin yksi tarkastaja ei ole tehnyt 

valmistautumista riittävän huolellisesti. 

• Tarkastettavan dokumentin systemaattinen läpikäynti (esim. 

kappale tai sivu kerrallaan). 

• Tarkastajat kertovat havaitut virheet ja sihteeri kirjaa ne 

pöytäkirjaan: 

• jokainen löytämättä jäänyt vika voi aiheuttaa myöhemmin monta 

tuntia ylimääräistä työtä 

• tarkastajilta kannattaa pyytää antamaan kokouksen alussa 

valmistautumisen aikana löydetyt virheet kirjallisena 

• keskustellaan virheestä, koska virheitä voi löytyä lisää esim. 

lähdedokumenteista 

• ei ylimääräistä keskustelua, väittelyä, väheksymistä tai kritiikin 

antamista –> tehokkuus ajankäytössä 

20.9.2007 




Tarkastuspalaverin pöytäkirja 

• Valmistautumiseen käytetty aika kirjataan 

pöytäkirjaan palaverin alussa. 

• Pöytäkirja luetaan läpi. 

• Kirjatut virheet luokitellaan ja päätetään, mitkä niistä 

korjataan. 

• Palaveriin käytetty aika kirjataan pöytäkirjaan. 

• Kirjataan päätös pöytäkirjaan: 

• hyväksytty 

• hyväksytty korjauksin 

k • hylätty / uusintatarkastus 

• Sovitaan seurantatoimenpiteet. 

20.9.2007 




© Arto Stenberg 18


Exit-kriteerit 

• Dokumentti on tarkastettu yhdessä tai useammassa 

palaverissa. 

• Tekijä on korjannut kaikki dokumentista löytyneet 

virheet, mutta korjausten oikeellisuutta ei yleensä 

tarkasteta. 

• Lähdedokumenteista löydetyistä virheistä on tehty 

muutospyyntö. 

• Prosessin parantamisideat on lähetetty eteenpäin. 

• Pöytäkirjaan lisätään käytetty aika ja 

hyväksymismerkintä. 

20.9.2007 




Tarkastuksen metriikka 

• Käytetty aika / tarkastettu dokumentti: 

• suunnittelu, alkupalaveri, valmistautuminen, 

tarkastuspalaveri, dokumentin korjaus ja seuranta 

• Tarkastettuja sivuja / tunti. 

• Koodirivejä / tunti. 

• Löydettyjen virheiden määrä ja niiden luokitus. 

• Tehokkuus: 

• tarkastusten aikana löydetyt virheet / tarkastusten aikana 

löydetyt virheet + testauksen aikana löydetyt virheet 

• löydetyt virheet / tarkastuksiin käytetty aika 

20.9.2007 




© Arto Stenberg 19


Perinteisiä ongelmia 

• Osallistujat eivät ymmärrä tarkastusten merkitystä. 

• Väärät osallistujat, ei asiantuntemusta 

• Tarkastajien valmistautumattomuus. 

• Perehtymisen vaatima suuri työmäärä. 

• Motivaatio ja asenteet. 

• Rönsyily tarkastustilaisuuksissa (ideointi ja korjailu). 

• Puheenjohtajan kyvyttömyys johtaa tilaisuutta. 

• Työmäärää ei ole otettu huomioon 

projektiaikataulussa (muiden projektien tarkastukset). 

• Liikaa tarkastettavaa materiaalia aikaan verrattuna. 

• Keskitytään tyylin, eikä sisällön tarkastamiseen. 

20.9.2007 




RaPiD7 

• Roope Kylmäkosken kehittämä RaPiD7. 

• Rapid Production of Documentation, 7 steps. 

• Menetelmän tarkoituksena on: 

• laadukkaiden dokumenttien tuottamisen tiimityöskentelyn ja 

workshoppien avulla 

• informaation jakamisen parantaminen ja sitoutuminen päätöksiin 

• Katselmointi on rakennettu menetelmän sisälle: 

• mukana ne ihmiset, jotka olisivat myös katselmoimassa 

• Yhden dokumentin luomiseen voidaan järjestää useita 

workshoppeja: 

• yleensä 1-4 kpl, kestoltaan 3-5 tuntia 

• dokumenttia ei kuitenkaan pystytä luomaan pelkästään 

workshoppien avulla 

20.9.2007 




© Arto Stenberg 20


RaPiD7 

1. Valmistautumista 

2. Kick-off 

Seuraava 

workshop 

3. Ideoiden kerääminen 

4. Ideoiden analysointi 

5. Yksityiskohtien lisääminen 

Yhden 

workshopin 

aikana 

6. Päätöksien teko 

7. Lopetus 

Valmis 

dokumentti 

20.9.2007 




Kompleksisuusmittarit 

• Käytetään yleensä kriittisessä ohjelmistossa 

arvioitaessa jonkun moduulin tai funktion 

monimutkaisuutta. 

• Monimutkainen koodi: 

• vaatii enemmän testausta ja parempilaatuisia testitapauksia 

• vaikeampi koodin ylläpito 

• onko siinä enemmän virheitä... 

• Voidaan käyttää: 

• koodikatselmusten tarkentamiseen, testauksen 

kohdistamiseen, testitapausten määrän arviointiin, 

virhemäärän ennustamiseen 

20.9.2007 




© Arto Stenberg 21


McCaben kompleksisuusluku 

• Esiteltiin 1976 ja perustuu graafiteoriaan. 

• McCaben syklomaattinen numero 

(kontrollikompleksisuus): 

• v(G) = e–n+2p: 

• e = nuolten määrä 

• n = solmujen määrä 

• p = funktioiden määrä 

• yksittäiselle funktiolle v(G) = c+1, missä 

c= kontrolliverkon haarautumiskohtien lukumäärä 

• v(G) ilmaisee testitapausten minimimäärän, jos halutaan 

käydä läpi kaikki haarautumat 

• ohjearvoja; moduulille 1 – 100, funktiolle 1 - 20 

20.9.2007 




McCabe esimerkki 

20.9.2007 




© Arto Stenberg 22


Koodin analysointi 

• Data flow analysis 

• Etsitään koodista muuttujat ja niiden käyttö: 

• koska muuttuja määritellään 

• mikä on muuttujan alkuarvo 

• koska muuttujaan asetetaan arvo 

• koska muuttujaa käytetään 

• Control flow analysis 

• Käydään läpi koodin kontrollirakenne, joka voidaan 

mallintaa 

• process block, decision point, junction point 

• Yritetään löytää esim. kuollut koodi ja päättymättömät luupit. 

20.9.2007 




Koodin mallintaminen 

F 

T 

F 

T 

Sekvenssi Ehto Luuppi 

20.9.2007 




© Arto Stenberg 23


Dynaamiset 

Yksikkötestaus Integrointitestaus Järjestelmätestaus 

White-box 

Grey-box 

Black-box 

Toiminnallisuus 

Rakenne 

20.9.2007 




Standardi DO-178B 

• Software Considerations in Airborne Systems and 

Equipment Certification 

• White-box: 

• A: moniehtokattavuus + alemmat 

• B: päätöskattavuus + alemmat 

• C: lausekattavuus 

• D: ei vaatimuksia 

• Black-box: 

• A, B ja C: korkean ja matalan tason testausvaatimukset 

• D: korkean tason testausvaatimukset 

• käytettävät tekniikat: ekvivalenssiluokat, raja-arvot, 

tilapohjainen testaaminen 

20.9.2007 




© Arto Stenberg 24


White-box testaustekniikat 

• Vaatii erityisen työkaluohjelman käyttämistä, koska 

koodi instrumentoidaan ja siitä mitataan testauksen 

koodikattavuus. 

• On olemassa erilaisia kattavuusmääreitä, joille pitää 

käytännössä antaa joku kohdearvo (lopetuskriteeri, 

esim. 80%). 

• Testitapauksien suunnittelussa käytetään avuksi 

tietoa koodin rakenteesta. 

• Testien suorituksen yhteydessä tarkastetaan tulokset 

ja kattavuus. 

• Jos riittävää kattavuutta ei ole saavutettu, tehdään 

lisää testitapauksia. 

20.9.2007 




Ongelmia 

• Joku 100% kattavuus ei tarkoita sitä, että järjestelmä 

olisi 100% testattu. 

• Käyttöönotossa voidaan kohdata mm. seuraavia 

vaikeuksia: 

• teettää yleensä lisätyötä 

• on lahjomaton 

• vaatii tarkempaa lähestymistapaa yksikkötestaukseen 

• voi vaatia isoa panostusta työkaluihin 

• Voi olla pakko ottaa käyttöön: 

• esim. erilaiset standardit vaativat koodikattavuuden 

mittaamista 

20.9.2007 




© Arto Stenberg 25


Lausekattavuus 

• Yksinkertaisin kattavuusmääre. 

• Tarkoituksena on kattaa mahdollisimman monta 

ohjelmointikielen operaatioita sisältävää lausetta: 

• voi oikeastaan verrata vaikka tekstirivien lukemiseen 

• Helpoimmin saavutettavissa: 

• yksikkötestauksen 100% lausekattavuuden vaatimus on 

käytössä monissa yrityksissä 

• TDD (test driven development) menetelmässä testit ovat 

pieniä ja niitä on paljon 

• Tyypillinen testaus saavuttaa maksimissaan 60-75% 

kattavuuden. 

20.9.2007 




Päätöskattavuus 

• Puhutaan myös haarakattavuudesta. 

• Testauksella koetaan saavuttaa kaikki koodin 

päätöksistä lähtevät haarautumat: 

• IF (x>100) OR (Y


Ehtokattavuus 

• Jokaisen päätöksen jokainen ehto saa molemmat 

arvot: 

• IF (x>100) OR (Y100) OR (Y80 

6 print counter, line 

7 end if 

8 read line 

9 end while 

10print tend-of-file 

do e 

1. rivit 1-3, hyppäys riville 10 







8. rivi 10, loppu 

• Tyypillinen testaus saavuttaa 30-40% LCSAJ 

kattavuuden. 

20.9.2007 




© Arto Stenberg 27


Black-box testaustekniikat 

• Testauksessa ei välttämättä olla kiinnostuneita 

testauksen kohteen sisäisestä rakenteesta tai sen 

toteutuksesta. 

• Koskaan ei voi olla täysin varma testauksen 

kattavuudesta. 

• Voidaan käyttää jokaisella testaustasolla 

(yksikkötestauksesta hyväksymistestaukseen). 

• Testaajan on tärkeitä havainnoida testaustapauksen 

suorituksessa myös muita tapahtumia. 

20.9.2007 




Vikasietoinen rajapinta 

• Pitäisi kestää seuraavia ongelmatilanteita. 

• Syöte on oikeaa tyyppiä, mutta arvoalueen 

ulkopuolella. 

• Syöte on väärää tyyppiä. 

• Syöte on väärässä formaatissa. 

20.9.2007 




© Arto Stenberg 28


Ekvivalenssiluokat 

Jaa syötteet (tai tulokset) alueisiin, 

joissa niiden arvot kuuluvat samaan joukkoon. 

Oletus: jos yksi alueen arvoista toimii, muutkin toimivat. 

Testitapaukset: vähintään yksi testitapaus / alue. 

20.9.2007 




Luokkien tunnistaminen 

• Syöte on joltakin tietyltä arvoväliltä: 

• esim. 1-100 

• luokat ovat luvut, jotka ovat 100 

• Syötteessä on jokin lukumäärärajoitus: 

• esim. syötteessä saa olla luvut 1-3 

• esim. syötteessä saa olla eri lukuja 1-3 kpl 

• luokat ovat seuraavat: 3 

• Syöte on joku joukko arvoja: 

• esim. värit = {vihreä, keltainen, punainen} 

• luokat ovat joukon jäsen ja joku muu esim. sininen 

• Syöte on boolean-arvo: 

• kaksi luokkaa eli tosi ja epätosi 

20.9.2007 




© Arto Stenberg 29


Luokkien tunnistaminen 

• Jos syöte on määrätty: 

• syötteen pitää olla esim. kirjain 

• luokat ovat kirjain ja ei-kirjain (luku, erikoismerkki, tyhjä) 

• syötteen pitää olla esim. numero 

• luokat ovat numero, reaaliluku, kokonaisluku, muu merkki 

kuin numero 

• Syötteessä voi olla ns. avoin raja: 

• esim. veron pidätysprosentti 

•


Esimerkkejä raja-arvoista 

• Syöte on joltakin tietyltä arvoväliltä: 

• esim. 1-100 

• raja-arvot ovat luvut: 0, 1, 2, 99, 100, 101 

• Syötteessä on jokin lukumäärärajoitus: 

• esim. syötteessä saa olla luvut 1-3 

• esim. syötteessä saa olla eri lukuja 1-3 kpl 

• raja-arvot ovat seuraavat: 0, 1, 3 ja 4 

• Syöte on joku joukko arvoja: 

• esim. värit = {vihreä, keltainen, punainen} 

• luokat ovat joukon jäsen ja joku muu esim. sininen 

• Syöte on boolean-arvo: 

• kaksi luokkaa eli tosi ja epätosi 

20.9.2007 




Esimerkkejä raja-arvoista 

• Jos syöte on määrätty: 

• syötteen pitää olla esim. kirjain 

• raja-arvona voidaan pitää kirjaimia / ei-kirjaimia 

• syötteen pitää olla esim. numero 

• raja-arvona voidaan pitää numeroavaruuden rajoja (integer) 

• Syötteessä voi olla ns. avoin raja: 

• esim. veron pidätysprosentti 

•


Miksi kannattaa käyttää molempia? 

• Ensin pitää määritellä ekvivalenssiluokat. 

• Raja-arvoilla löytää virheitä, mutta ne eivät 

välttämättä testaa normaaleita käyttöarvoja. 

• Perinteisesti on ensin testattu ekvivalenssiluokat ja 

sen jälkeen raja-arvot. 

• Testitapaukset voidaan tehdä raja-arvojen pohjalta, 

koska ne kattavat myös ekvivalenssiluokat. 

• Laadi taulukko ja sen pohjalta testitapaukset. 

• Muista testata vain yhtä muutosta kerrallaan, eli yksi 

virheellinen syöte kerrallaan. 

20.9.2007 




Lisää esimerkkejä 

• Kuinka monta yhtäaikaista käyttäjää? 

• Kuinka monta kertaa peräkkäin voit suorittaa jonkun toiminnon? 

• Data-elementtien lukumäärä (tietokanta tai erilaiset listat). 

• Luvun tai merkkijonon koko. 

• Dokumentin, tiedoston tai tietueen koko? 

• Kuinka monta laitetta voidaan järjestelmään kytkeä? 

• Järjestelmän keskusmuistin määrä. 

• Mahdolliset käyttöjärjestelmät, muut ohjelmat ja niiden versiot. 

• Erilaiset graafiset määrittelyt (näytön koko, ikkunan koko, värien 

määrä) 

• Erilaiset ajatukseen liittyvät toiminnat. 

• Erilaiset tulosteet. 

• Päiväys ja aika. 

20.9.2007 




© Arto Stenberg 32


Mies 

Esimerkki 

YHTEYSTIEDOT 

Anna yhteystietosi. 

Täytä vähintään lihavoidut kohdat. 

Käyttäjätunnus: 

(3-10 merkkiä) 

Salasana: 

(8-10 merkkiä) 

Sukupuoli: 

valikko 

(2 vaihtoehtoa) 

Syntymäaika: 

(2+2+4 numeroa) 

Sähköpostiosoite: 

(32 merkkiä) 

Matkapuhelinnumero: 

(3+9 numeroa) 

20.9.2007 




Useampi syöte tai muuttuja 

• Usein ei ole mahdollisuutta tai aikaa testata jokaisen 

syötteen jokaista mahdollista ekvivalenssiluokkaa tai 

raja-arvoa. 

• Syötteillä ja muuttujilla on kuitenkin usein sidoksia 

toisiinsa, jolloin on myös yhteisiä rajoitteita. 

• Käytetään seuraavia termejä: 

• Rajalla (on) on arvo, joka on sama kuin raja-arvo. 

• Lähellä (off) on arvo, joka on rajan tuntumassa. 

• Sisällä (in) on arvo, joka on raja-arvon normaalilla puolella. 

• Ulkona (out) on arvo, joka on raja-arvon virheellisellä 

puolella. 

20.9.2007 




© Arto Stenberg 33


Esimerkki 

rajalla 

rajalla 

ulkona 

lähellä 

sisällä 

ulkona 

lähellä 

sisällä 

X => 5 X > 5 

Suljetussa rajassa (=>, ): 

rajalla = raja-arvo, mutta 

ei normaali arvo 

lähellä = raja-arvon 

normaalilla puolella 

20.9.2007 




Domain analysis testing 

• Jokaiselle relaatioehdolle (=>, >,


Cause-effect 

NOT 

Identity 

a b a b 

”jos a=1 niin b=1” 

a 

a 

b 

d 

c 

c 

OR 

b 

AND 

20.9.2007 




Cause-effect rajoitteet 

”vain toinen voi olla 1” 

a 

I 

E 

”ainakin yhden pitää olla aina 1” 

a 

b 

b 

c 

O 

a 

R 

a 

Jos a=1 niin 

b=1 

a 

M 

”vain toisen pitää olla 1” 

b 

b 

b 

Jos a=1 niin 

b=0 

20.9.2007 Ohjelmiston testaus - tekniikat © TTY Pori, Arto Stenberg 70 



© Arto Stenberg 35


Cause-effect 

• Syy-seuraus suhde, eli logiikkaa. 

• Tarkoittaa testauksessa input output tai input 

järjestelmän tilasiirtymä. 

• Mallinnetaan ja tehdään päätöstaulu. 

• Päätöstaulusta muokataan testitapaukset. 

• Ehkä liiankin vaikeaa speksata järjestelmän 

toimintaa toiseen kertaan… 

20.9.2007 




Päätöstaulut 

• Käytetään erilaisten testitapauksien 

muodostamiseen. 

• Käydään läpi syötteiden eri yhdistelmät ja tilat, jotta 

huomataan, ettei mitään tärkeää yhdistelmää ole 

unohdettu testata. 

• Syöteyhdistelmät merkitään ensin boolean muotoon 

(tosi/epätosi). 

• Lisäksi voidaan listata mahdolliset ohjelman 

tapahtumat ja odotetut tulokset. 

20.9.2007 




© Arto Stenberg 36


Päätöstaulut 

Testitapaus 

1 2 3 4 5 6 7 

Syöte 

A B C D E F G 

Ehto 

A B C D E F G 

Tapahtuma 

A B C D E F G 

Odotettu 

tulos 

20.9.2007 




Päätöstaulut (esimerkki) 

• Henkivakuutuksen maksuerän suuruuden 

laskeminen. 

• Maksu kuoleman sattuessa: 

• 100000, 200000 tai 500000 € 

• Ikä: 

• alle 20, 20-30, 31-40, 41-50, 51-60, 61-70, yli 70 

• Tupakointi (kyllä/ei) 

• Vakavia sairauksia (kyllä/ei) 

• Vaarallisia harrastuksia (kyllä/ei) 

20.9.2007 




© Arto Stenberg 37


Päätöstaulut (esimerkki) 

Testitapaus 

1 2 3 4 5 6 7 

Maksu 

100000 200000 500000 100000 200000 500000 100000 

Ikä 

70 20-30 31-40 61-70 

Tupakointi 

ei kyllä kyllä ei ei ei kyllä 

Sairaus 

kyllä ei kyllä ei ei kyllä kyllä 

Harrastus ei kyllä ei ei kyllä 

Odotettu 

tulos 

kyllä 

ei 

20.9.2007 




Puurakenne 

Vakionopeudensäädin 

Todellisen ja halutun nopeuden ero 

Todellinen nopeus 

Auto edessä 

< 0 0 - 30 > 30 0-50 50-80 80-120 On Ei 

Nopeusero 

Etäisyys 

< 0 0 - 30 > 30 < 25m > 25m 

20.9.2007 




© Arto Stenberg 38


Tilapohjainen testaaminen 

• Ohjelmistolla on yleensä erilaisia tiloja, joihin voi 

mennä eri siirtymien kautta. 

• Yleensä vaikeutena on jo suunnitteluvaiheessa 

mallintaa oikeat tilat ja siirtymät. 

• Soveltuu hyvin testaukseen ja kannattaa tehdä, 

koska testaajalla on aina jonkinlainen malli 

testattavasta järjestelmästä tai sen osasta. 

• Tarkoituksena on löytää: 

• laiton / puuttuva / korruptoitunut tila 

• laiton / puuttuva / väärä siirtymä 

• puuttuva / väärä johonkin tilaan liittyvä toiminnallisuus 

• sanomien oikea / väärä käsittely 

20.9.2007 




Odottaa 

korttia 

Esimerkki: pankkiautomaatti 

Kortti syötetty 

Odottaa 

PIN-koodia 

Väärä 

PIN-koodi 

Oikea PIN-koodi 

Valinta tehty 

Pankki 

vai 

luotto 

Saldo 

vai 

Otto 

Kolme väärää 

Keskeytys 

20.9.2007 




© Arto Stenberg 39


Tilapohjainen testaaminen 

• Tilat: 

• annetut syötteet vaikuttavat järjestelmän käyttäytymiseen 

• Ehdot: 

• väittämän evaluointi siirtymän yhteydessä 

• Siirtymät: 

• liikutaan tilasta toiseen jonkun tapahtuman seurauksena 

• Tapahtumat: 

• järjestelmän tietyssä tilassa tapahtuva toiminnallisuus 

• Testataan kaikki tilasiirtymäparit ja niihin liittyvät ehdot. 

• Nämä parit kannattaa taulukoida: 

• nykyinen tila, siirtymä, ehto, tapahtuma, seuraava tila 

20.9.2007 




Esimerkki 

Vaihtoraha 

loppu 

Juoman 

anto 

Rahan 

syöttö 

Rahan 

käsittely 

Juoman 

valinta 

Keskeytys 

Juoma 

loppu 

Rahan 

palautus 

20.9.2007 




© Arto Stenberg 40


Esimerkki 

Alkutila 

Siirtymä 

Ehto 

Lopputila 

Rahan syöttö Käsitellään rahan arvo Raha syötetty 

Rahan käsittely 


Hylätään raha 

Raha ei kelpaa 

Rahan palautus 


Keskeytys 

Tapahtuma keskeytyy 

Keskeytys-nappia painettu 

Palautetaan rahat Syötettyjä rahoja > 0 

Keskeytys 

Rahan palautus 


Valitaan juoma 

Saldo riittävä 

Juoman valinta 

20.9.2007 




Datan ja tiedostojen testaus 

• Create, Read, Update, Delete: 

• datan käsittelyä: esim. luo, lue, päivitä, lue, tuhoa, lue 

• Listataan järjestelmän tai toiminnallisuuden päädatat 

ja niitä käsittelevät funktiot. 

• Testataan CRUD ja funktioiden yhteistoimintaa. 

Data 

toimittaja asiakas henkilö 

Funktio A 

R C,R,U,D R,U 

Funktio B 

C,R,U,D R R,U 

20.9.2007 




© Arto Stenberg 41


Data combination test 

• Ensin selvitetään testauksen pääkohde: 

• esimerkiksi lasku, tilaus ym. paljon dataa sisältävä kohde 

• Sitten selvitetään kohteen sisältämä data: 

• esimerkiksi maksajan tiedot, tilauksen tiedot jne. 

• Seuraavaksi datan ”normaalit” arvot. 

• Muodostetaan testitapaukset niin, että erilaiset 

kombinaatiot käydään läpi. 

20.9.2007 




Datan ja tiedostojen testaus 

• Tallennusmedia on täynnä tai epäkuntoinen (erityisesti 

sulautetuissa järjestelmissä). 

• Epämääräiset ää äi tiedostojen t nimet. 

• Tiedostojen oikeuksien muuttaminen. 

• Korruptoitunut data; väärä data tai tiedostoformaatti. 

• Tietokannan konversio; muutokset järjestelmän eri versioiden 

välillä tai eri järjestelmien välillä. 

• Kilpailutilanteet; useampi yhtäaikainen käyttäjä tai funktio 

haluaa muuttaa samaa dataa / tiedostoa. 

• Erilaisten käyttäjien oikeudet. 

• Tietokannan operaatioiden suorituskyky ja resurssien käyttö. 

• Ja tietenkin myös varmuuskopiointi ja palautus. 

20.9.2007 




© Arto Stenberg 42


Vaatimusten testaaminen 

• Vähimmäistestaus sisältää vaatimusten testaamisen. 

• Jokaiselle vaatimukselle tehdään vähintään kaksi 

testitapausta: 

• yksi, jolla todennetaan, että vaatimus on toteutettu 

• toinen, jolla yritetään todistaa, että vaatimusta ei ole 

toteutettu halutulla tavalla 

• Vaatimusmäärittelyn yhteydessä kannattaa tarkistaa 

vaatimusten testattavuus: 

• tee testitapauksen aikaisin, niin saat virheet kiinni 

• jos vaatimusta ei voi testata, niin miten sen voi toteuttaa 

20.9.2007 




Vaatimusten testattavuus 

• Järjestelmän jokaisesta vaatimuksesta voidaan 

myös tehdä taulukko (esim. ei-toiminnallinen 

vaatimus): 

• ei-toiminnallisen vaatimus / laatukriteerin nimi 

• mitä mitataan 

• miten mitataan 

• mikä on alin läpäisyraja 

• mikä on ylin vaatimusraja 

• mikä on järjestelmän nykytilanne 

• mikä on muiden vastaavien järjestelmien keskimääräinen / 

paras arvo 

20.9.2007 




© Arto Stenberg 43


(esi)merkillisiä vaatimuksia 

• Järjestelmä sallii tilanteeseen sopimattomien 

ominaisuuksien poiskytkemisen, joten esim. 

varmistusta ei ole pakko käyttää. 

• Järjestelmän perustoimintoja (pois lukien ylläpito) 

pystyy käyttämään ilman koulutusta suoraan tai 

lyhyen ohjeiden lukemisen jälkeen. 

• Järjestelmän ylläpito ei vaadi sihteeriltä/toimittajalta 

kuin kohtuullisen ajan viikossa normaalikäytössä. 

20.9.2007 




Kattavuustaulu 

Testitapaus 

1 2 3 4 5 6 7 

Vaatimus 

1 

kyllä 

kyllä 

Vaatimus 

2 

kyllä 

kyllä 

Ominaisuus 

A 

ei 

ei 

kyllä ei ei ei kyllä 

Ominaisuus 

i 

B 

ei ei ei kyllä ei kyllä kyllä 

Muistinkäyttö ei ei ei ei kyllä 

kyllä 

ei 

20.9.2007 




© Arto Stenberg 44


Järjestelmän käyttö 

• Tehokas tapa testata on yrittää matkia 

mahdollisimman hyvin järjestelmän lopullista käyttöä. 

• Tarkoituksena on luoda erilaisia skenaarioita, jotka 

kuvaavat jonkun tietyn tavan käyttää järjestelmää. 

• Skenaarioita voi luoda käyttötapauksien pohjalta tai 

sitten kehitellä niitä yhdessä järjestelmän 

loppukäyttäjien kanssa. 

• Samalla testaaja oppii tuntemaan järjestelmän ja sen 

loppukäyttäjät entistä paremmin. 

20.9.2007 




Skenaario 

• Kunnollisella skenaariolla on useita tavoitteita: 

• se pohjautuu loppukäyttäjien luonnolliseen tapaan käyttää 

järjestelmää 

• skenaarion pitää olla uskottava, se voi toteutua myös 

tosielämässä 

• skenaariot sisältävät järjestelmän realistista käyttöä 

monipuolisella datalla uskottavassa 

järjestelmäkonfiguraatiossa 

• testien tulokset pitää olla helposti arvioitavissa ja 

testauksessa havaitut virheet on korjattava viipymättä 

20.9.2007 




© Arto Stenberg 45


Skenaarioiden luonti 

1. Tunnista järjestelmän kaikki loppukäyttäjät. 

2. Analysoi sekä tarkkaile, miten he käyttävät järjestelmän eri 

toimintoja. 

3. Kirjaa loppukäyttäjien erilaisten tehtävien ja järjestelmän 

toimintojen suoritusjärjestys. 

4. Tunnista järjestelmän erilaiset dataobjektit ja määrittele niihin 

kohdistuvat toiminnat (esim. luonti, käyttö, muokkaus, 

yhteydet, tuhoaminen). 

5. Tunnista järjestelmän end-to-end toiminnallisuudet. 

6. Testaa kaikki mahdolliset raportit ja muut tulokset, joita saat 

end-to-end toiminnallisuuksista. 

7. Tunnista järjestelmän erilaiset tapahtumat ja virheilmoitukset. 

8. Kartoita vanhoissa järjestelmissä koetut ongelmatilanteet 

yhdessä käyttäjien kanssa. 

20.9.2007 




Käyttötapauksesta testejä 

• Käyttötapauksissa testauksen kannalta tärkeintä on sen 

kirjallinen kuvaus (joka vaihtelee eri yrityksissä ja alan 

kirjallisuudessa). 

• Käyttötapauksen luokitus: 

• must have, could have, should have (yhteys vaatimuksiin) 

• kriittisyys asiakkaalle 

• Esiehdot: 

• missä tilassa järjestelmän pitää olla, ennen kuin käyttötapaus 

voidaan suorittaa 

• hyvää tietoa testitapauksien laadintaan 

• Varsinainen käyttötapauksen kuvaus: 

• perustestitapaus 

• Mahdolliset variaatiot: 

• lisää erilaisia testitapauksia 

20.9.2007 




© Arto Stenberg 46



• Poikkeustilanteet: 

• mahdolliset poikkeustilanteet, jotka kaikki ovat hyviä testitapauksia 

• Alikäyttötapaukset: 

• yleensä tarkempi kuvaus 

• taas uusia testitapauksia 

• Lopputila: 

• missä tilassa järjestelmän pitäisi olla käyttötapauksen jälkeen 

• hyvää tietoa testitapauksien laadintaan 

• Vasteaika: 

• kuinka nopeasti järjestelmän j pitää vastata sen käyttäjälle 

• voi olla summittainen aikamääre 

• Esiintymistiheys: 

• kuinka usein käyttötapaus tapahtuu 

• kerran tunnissa / päivässä / viikossa 

20.9.2007 




Esimerkki priorisoinnista 

Käyttötapauksen 

tunniste 

Vasteaika 

Kriittisyys 

Esiintymistiheys 

Testausprioriteetti 

Kuukausiraportointi 

Matala 

Kerran 

kuukaudessa 

Korkea 

Korkea 

Järjestelmään 

kirjautuminen 

Nopea 

Kerran 

päivässä 

Korkea 

Korkea 

Lokien 

tyhjentäminen 

Matala 

Kerran 

viikossa 

Normaali 

Normaali 

Uuden lomakepohjan 

teko 

Normaali 

Kerran 

vuodessa 

Matala 

Matala 

20.9.2007 




© Arto Stenberg 47



Vaatimukset 

Käyttötapaus 

Alempi 

käyttötapaus 

Alempi 

käyttötapaus 

Skenaario 

Skenaario 

Skenaario 

Testitapaus 

Testitapaus 

Testitapaus 

20.9.2007 





• Tunnistetaan käyttötapauksen muuttujat: 

• ne vaikuttavat käyttötapauksen toteutumiseen ja vaihtelevat 

skenaariosta toiseen 

• ovat käyttötapauksen syötteitä (tai tuloksia) 

• osa voi olla järjestelmän sisäisiä 

• osa muuttujista voi olla ympäristötekijöitä, jotka vaikuttavat 

aktorin toimintaan 

• osan voi löytää järjestelmän tiloista, jos ne vaikuttavat 

käyttötapaukseen 

20.9.2007 




© Arto Stenberg 48



• Selvitetään jokaisen muuttujan arvoalueet. 

• Tehdään kaikista muuttujista ja niiden arvoista 

päätöstaulu. 

• Luodaan testitapaukset: 

• karsitaan pois turhat testitapaukset 

• luomisessa voidaan käyttää apuna muita tekniikoita 

(ekvivalenssiluokat, raja-arvoanalyysi) 

20.9.2007 




Esimerkki: pankkiautomaatti 

• Käyttötapaus: nosta pankkiautomaatista rahaa 

• Tunnista muuttujat: 

• Kortti, pin-koodi, nostettava rahamäärä, automaatin 

rahatilanne, yhteys pankkiin, tilin rahatilanne 

• Määritä arvoalueet: 

• Kortti: sirukortti / ”vanha” pankkikortti / luottokortti / ei luottoa 

/ joku muu kortti 

• Pin: oikea / väärä 

• jne 

• Tee skenaarioita: 

20.9.2007 




© Arto Stenberg 49


Esimerkki 

• Käyttötapaus: Web-kaupasta tilaaminen 

• Esiehdot: 

• Asiakkaan täytyy olla rekisteröitynyt käyttäjä ja hänen pitää 

olla kirjautunut sisään järjestelmään. 

• Jälkiehdot: 

• Asiakas on valinnut ja tilannut haluamansa tuotteet. 

Järjestelmä on kirjannut tilauksen tietokantaan ja päivittänyt 

kanta-asiakas tietoja. Järjestelmä on lähettänyt asiakkaan 

sähköpostiin tilausvahvistuksen. 

20.9.2007 




Esimerkki 

• Kuvaus: 

• Asiakas päättää tilata ostoskoriin kerätyt tuotteet ja valitsee 

ostoskorista vaihtoehdon ”Tilaa tuotteet”. Järjestelmä 

näyttää asiakastiedot, ostoskorin sisällön (tuote- ja 

hintatiedot), tilauksen loppusumman ja kysyy tilaukseen 

liittyviä lisätietoja, kuten maksu- ja toimitustavan (nouto 

suoraan myymälästä, postiennakko, verkkopankkimaksu tai 

mahdollisesti laskutus). Järjestelmä kysyy vielä asiakkaalta 

tilauksen lopullisen varmistuksen. Asiakkaan vahvistaessa 

tilauksen se kirjautuu lopullisesti järjestelmään ja asiakkaan 

sähköpostiin lähetetään tilausvahvistus. 

20.9.2007 




© Arto Stenberg 50


Esimerkki 

• Poikkeukset: 

• Järjestelmään kirjautuminen ei jostain syystä onnistu. Jos 

ostoskori on tyhjä, niin ”Tilaa tuotteet”- toimintoon ei pääse. 

Jos asiakas on kanta-asiakas ja hän on tilannut tuotteita yli 

1000 euron arvosta, hän saa 10% alennuksen tilauksen 

loppusummasta. Vain valituille asiakkaille voidaan tavaraa 

toimittaa laskua vastaan. Tilaustiedoissa on jokin tyhjä 

kenttä (esim. toimitustapa). Asiakas ei vahvista tilausta. 

Tilausvahvistus ei tule jostain syystä perille asiakkaalle. 

20.9.2007 




Käyttöprofiili 

• Software Reliability Engineering 

• Käyttöprofiilin tarkoituksena on ohjata tekemään 

testausta järjestelmän eniten käytetyille 

ominaisuuksille: 

• matemaattinen lähestymistapa 

• priorisoidaan testausresurssien käyttö 

• periaate: häiriöt, joita ilmaantuu eniten, johtuvat viallisista 

toiminnallisuuksista, joita käytetään eniten 

• käyttäjät huomaavat nämä kaikkein helpoimmin 

• Käyttötapauksia voidaan hyödyntää testauksessa: 

• vaatii lisäinformaatiota, eli käyttötapauksen toistumisen 

tiheyttä 

20.9.2007 




© Arto Stenberg 51


SRE prosessi 

Määritellään 

tarpeellinen 

luotettavuus 

Kehitetään 

toiminnalliset 

profiilit 

Testaukseen 

valmistautuminen 

Käytetään vikatietoja 

päätöksenteon tukena 

Ajetaan testit 

Vaatimukset 

ja 

arkkitehtuuri 

20.9.2007 

Suunnittelu 

ja 

toteutus 

Testaus 




Luotettavuuden tasot 

Luotettavuuden taso Häiriöt / 1000 tuntia Strategia 

Huippuluotettava 

< 0.1 

Järjestelmän vikasietoisuus 

korkea. 

Vaihetuotteiden katselmointiin 

panostettu. 

Korkea 

luotettavuus 

0.1 - 10 

Jonkin asteinen vikasietoisuus. 

Vaihetuotteita katselmoidaan 

Kaupallinen 

10 - 2000 

Vaihetuotteiden katselmointia 

ohjaavat toiminnalliset profiilit 

ja kriittisyys. 

Prototyyppi 

> 2000 Kokeillaan toimivuutta 

20.9.2007 




© Arto Stenberg 52


Luotettavuus ajan suhteen 

Luotettavuus 1 tunnin 

suorituksen aikana 

Häiriön 

esiintymisen 

todennäköisyys 

0.368 1 häiriö tunnissa 

0.959 1 häiriö päivässä 

0.994 1 häiriö viikossa 

0.9986 1 häiriö kuukaudessa 

0.99989 

1 häiriö vuodessa 

20.9.2007 




Käyttöprofiili esimerkki 

• Jos järjestelmässä on neljä käyttötapausta: 

• haku: tehdään joka toinen minuutti 

• lisäys: tehdään kerran viidessä minuutissa 

• poisto: tehdään kerran kymmenessä minuutissa 

• päivitys: tehdään kerran kymmenessä minuutissa 

• Lasketaan esiintymistiheydet suhteessa aikaan: 

• haku: 30/60, lisäys: 12/60, poisto ja päivitys: 6/60 

• yhteensä: 54/60 

• jaetaan käyttötapaus / 54, eli esim. haku 30/54 

• esiintymisen todennäköisyydet tunnin aikana: 

• haku: 0.56, lisäys: 0.22, poisto ja päivitys: 0.11 eli yhteensä 1 

20.9.2007 




© Arto Stenberg 53



• Jos projektissa käytetään testaukseen kaksi viikkoa, eli 80 

tuntia, niin kuinka kauan aikaa varataan jokaisen em. 

käyttötapauksen testaamiseen: 

• haku: 0.56 * 80 = 44 tuntia 

• lisäys: 0.22 * 80 = 17 tuntia 

• poisto: 0.11 * 80 = 8 tuntia 

• päivitys: 0.11 * 80 = 8 tuntia 

• Jos projektissa päätetään tehdä 80 testitapausta, niin testit 

jakaantuvat samalla periaatteella: 

• haku: 0.56 * 80 = 44 testitapaustatit t 

• lisäys: 0.22 * 80 = 17 testitapausta 

• poisto: 0.11 * 80 = 8 testitapausta 

• päivitys: 0.11 * 80 = 8 testitapausta 

20.9.2007 





• Mittaustietoa voidaan käyttää hyväksi: 

• yhden testitapauksen suunnittelu, toteuttaminen ja suoritus 

kestää yhteensä 3 tuntia 

• 7% testitapauksista löytää vian, jonka korjaus kestää 

keskimäärin 8 tuntia 

• Testausvaiheen aika on rajattu 80 tuntiin, montako 

testitapausta ehditään ajamaan (pyöristettynä): 

• (3T+(0.07*8T) = 80)=>(3.56T = 80)=>T=22 

• haku: 0.56 * 22 = 12 testitapausta 

• lisäys: 0.22 * 22 = 5 testitapausta 

• poisto: 0.11 * 22 = 2 testitapausta 

• päivitys: 0.11 * 22 = 2 testitapausta 

20.9.2007 




© Arto Stenberg 54


Käyttäjäprofiili 

• Käyttäjä: 

• ikä, käyttökokemus, asiantuntemuksen taso 

• mitä käyttäjä järjestelmältä vaatii ja mitä toimintoja hän 

käyttää ja missä suhteessa 

• Yhdistelmä eri käyttötapauksista: 

• käytetään hyväksi aikaisempia tekniikoita 

• muodostetaan erilaisia skenaariota 

• yritetään kuvata ja testata järjestelmän oikeaa käyttöä 

20.9.2007 




GUI:n testaus 

• Käyttöliittymän tilamallin luominen. 

• Miten päästään eri sovelluksiin? 

• Miten jokaisessa sovelluksessa toimitaan? 

• Miten palataan sovelluksesta päävalikkoon? 

• Voidaanko siirtyä sovelluksesta toiseen ilman 

päävalikkoa? 

20.9.2007 




© Arto Stenberg 55


GUI:n testaus 

• Menu-läpikäynti: 

• jokainen käyttöliittymän valikko ja dialogi käydään läpi 

• Pakota esille kaikki virheilmoitukset. 

• Anna arvoja kaikille kysytyille syötteille. 

• Kokeile kaikenlaisia sallittuja ja ei-sallittuja syötteitä (luvut, 

merkit, merkkijonot). 

• Anna liikaa / liian vähän syötearvoja. 

• Kartoita eri syötteiden kombinaatiot ja niiden väliset 

riippuvuudet. 

• Muista toisto. 

• Koeta saada erilainen tulos jokaisella syötteellä. 

• Koeta saada aikaan vikatuloksia. 

• Koeta muuttaa tuloksen ominaisuuksia. 

• Muista painaa F5 (refresh). 

20.9.2007 




Tutkiva testaaminen 

• Exploratory testing 

• Samanaikaisesti tapahtuvaa järjestelmän 

testaamista; testauksen suunnittelua ja toteuttamista: 

• ”kokeile ja katso toimiiko se ja etsi samalla virheitä” 

• ”mitä kannattaa testata, mitä tapahtuu jo teen näin...” 

• testaaja saa käyttää asiantuntemustaan ja luovuuttaan 

• testaaja luo oman mallinsa järjestelmän toiminnallisuudesta 

• järjestelmästä tai sen toiminnallisuuksista opitaan koko ajan 

enemmän 

• edellisen testin tulos vaikuttaa seuraavan testin 

suunnitteluun 

• ”mikä on paras testi, jonka voin tehdä juuri nyt” 

20.9.2007 




© Arto Stenberg 56


Kokeileva testaaminen 

• Kohdistetaan järjestelmän riskialttiimpiin kohtiin (ei 

ole testattu aikaisemmin, ei tunneta tai 

toiminnallisuus i ei ole luotettava) 

tt • Voidaan käyttää, jos ei ole dokumentaatiota 

testauksen tueksi tai aikaa testaamiseen on liian 

vähän. 

• Parityöskentelyä (”ajaja + kartturi”), jossa on selvä 

aihe ja jonka kesto on korkeintaan pari tuntia. 

• Ero ad hoc-testaukseen on siinä, että tutkivassa 

testauksessa pitäisi pystyä jäljittämään, mitä on 

tehty, eli kokeilevassa testauksessa pidetään 

muistiota (mitä tehtiin, mitä tapahtui). 

20.9.2007 




Tilastolliset menetelmät 

• Periaatteena on vähentää testitapausten määrä 

mahdollisimman pieneksi niin, että testien kattavuus 

pysyy korkeana. 

• Työväline (esim. Allpairs) saatavana ilmaiseksi 

webistä: 

• http://www.opensourcetesting.org/ 

• Tarkastelee kombinaatioiden parikattavuutta 

(orthogonal arrays). 

• Eri syötteiden väliset riippuvuudet voivat olla esteenä 

menetelmän käyttämiselle. 

20.9.2007 




© Arto Stenberg 57


Esimerkki 

• Henkivakuutuksen maksuerän suuruuden 

laskeminen: 

• Maksu kuoleman sattuessa: 100000, 200000 tai 500000 € 

• Ikä: alle 20, 20-30, 31-40, 41-50, 51-60, 61-70, yli 70 

• Tupakointi (kyllä/ei) 

• Vakavia sairauksia (kyllä/ei) 

• Vaarallisia harrastuksia (kyllä/ei) 

• Eli yhteensä 3*7*2*2*2 = 168 kombinaatiota. 

20.9.2007 




Esimerkki: Allpairs testitapaukset 

20.9.2007 

TEST CASES 

case Maksu Ikä Tupakka Sairaus Harrastus pairings 

1 100000 alle 20 kyllä kyllä kyllä 10 

2 200000 alle 20 ei ei ei 10 

3 100000 20-30 ei kyllä ei 8 

4 200000 20-30 kyllä ei kyllä 8 

5 500000 31-40 kyllä kyllä ei 8 

6 500000 31-40 ei ei kyllä 7 

7 100000 41-50 kyllä ei ei 5 

8 200000 41-50 ei kyllä kyllä 5 

9 100000 51-60 ei ei kyllä 4 

10 200000 51-60 kyllä kyllä ei 4 

11 500000 61-70 kyllä ei kyllä 4 

12 100000 61-70 ei kyllä ei 4 

13 500000 yli 70 ei kyllä ei 4 

14 100000 yli 70 kyllä ei kyllä 4 

15 500000 alle 20 ~kyllä ~kyllä ~kyllä 1 

16 500000 20-30 ~ei ~ei ~ei 1 

17 200000 31-40 ~kyllä ~kyllä ~kyllä 1 

18 100000 31-40 ~ei ~ei ~ei 1 

19 500000 41-50 ~kyllä ~ei ~ei 1 

20 500000 51-60 ~ei ~kyllä ~kyllä 1 

21 200000 61-70 ~ei ~ei ~ei 1 

22 200000 yli 70 ~kyllä ~kyllä ~ei 1 




© Arto Stenberg 58

testaustekniikat - Porin yksikkÃ¶ - Tampereen teknillinen yliopisto

Create successful ePaper yourself

Delete template?

Save as template?