Luentokalvot - Tieto- ja sähkötekniikka

Transcription

Ohjelmistojen testaus
Mika Katara, Matti Vuori ja Antti Jääskeläinen
Tampereen teknillinen yliopisto, Tietotekniikan laitos
17.8.2015
Ohjelmistotekniikka
Ohjelmistojen testaus, 2015
1(504)
Sisällysluettelo 1/10
Alkusanat
12
1. Kurssin tavoitteet
13
1.1 Kurssin lähestymistapa testaukseen
16
1.2 Mitä tällä kurssilla ei kateta?
17
1.3 Testaus-aiheisia verkkosivuja
18
2. Johdanto
19
2.1 Mitä testaus on? Erilaisia näkökulmia
20
2.2 Aina jokin vertailukohta: Vaatimukset
24
2.3 Virheiden lähteitä
31
2.4 Missä aktiviteetissa virheet syntyvät?
34
2.5 Testityypin käsite
35
2.6 Liiketoiminnan tukeminen
36
2.7 Perinteinen testausprosessi
40
2.8 Kaikkea ei voida testata
41
Ohjelmistotekniikka
2.9 Testauksen koulukuntia
44
2.10 Testauksen kansanperinnettä
50
2.11 Testaus on vaativaa työtä
53
2.12 Testaus on tiimityötä
54
2.13 Mitä testaukselta voi vaatia?
55
2.14 Keskeisiä termejä
56
3. Testitapauksiin pohjautuva testaus
62
3.1 Testitapaus pähkinänkuoressa
63
3.2 Testitapauksen rakenne ja sisältö
71
3.3 Muita huomioita testitapauksista
74
4. Testaus osana ohjelmistoprosessia
75
4.1 Testaustasot – testauksen V-malli
79
4.2 Yksikkötestaus
84
4.3 Test-Driven Development
Ohjelmistotekniikka
104
4.4 Testitapausten suunnittelutekniikoita
108
4.5 Ekvivalenssiositus-menetelmä
109
4.6 Raja-arvoanalyysi
114
4.7 Kombinaatioiden testauksesta
119
4.8 Fuzz-testaus
126
4.9 Matalan tason integrointitestaus
129
4.10 Jatkuva toimitus (Continuous Delivery)
144
4.11 Järjestelmätestaus
147
4.12 Järjestelmäintegrointitestaus
156
4.14 Testaus ketterässä kehittämisessä
170
4.15 Hyväksymistestaus
179
4.16 Ketterä hyväksymistestaus: ATDD
187
4.17 Alfa- ja Beta-testit
190
4.18 Tarvitaanko kaikkia testaustasoja ja vaiheita?
191
Ohjelmistotekniikka
4.19 Milloin siirtyä tasolta toiseen?
5. Tutkiva testaus
195
203
5.1 Tutkiva testaus pähkinänkuoressa
204
5.2 Tutkiva testaus: Esimerkkejä
209
5.3 Tutkiva testaus perustuu strategioihin ja tietoon
211
5.4 Session lähtökohdat
215
5.5 Suorituksen dokumentointi?
219
5.6 Tutkiva testaus arjessa
221
5.7 Uusien toimintojen nopea testisuunnittelu
223
5.8 Ennakkovarautuminen
224
5.9 Ketterä testaus ei-ketterässä projektissa
225
6. Riskianalyysi ja testien priorisointi
237
6.1 Käytön ymmärtäminen lähtökohtana
239
6.2 Riskianalyysin kulku
240
Ohjelmistotekniikka
7. Testauksen dokumentoinnista
253
7.1 Testauksen korkean tason suunnitteludokumentit
254
7.2 Testauksen suunnittelun prosessi
255
7.3 IEEE 829 antaa osviittaa suunnitelmiin
260
7.4 Matala taso: testitapausten dokumentointi
263
7.5 Pienissä projekteissa kevyesti
264
7.6 Testausraportit
265
7.7 Hyvä testausraportti
266
7.8 IEEE 829-2008 – Ketterässä toiminnassa riittää vähäisempi dokumentaatio
271
8. Testauksen seuranta
272
8.1 Testauksenhallintaohjelmisto pähkinänkuoressa
273
8.2 Virhetilanteen seuranta
274
8.3 Testausraportti
275
9. Lisää testauksen menetelmistä ja tekniikoista
Ohjelmistotekniikka
276
9.1 Hyödynnetäänkö ohjelman koodia vai ei?
280
9.2 Kuka testaa?
284
9.5 Mitä ohjelman osaa testataan?
287
9.8 Minkä tyyppisiä ongelmia etsitään?
290
9.11 Mitä ohjelmalla pitää tehdä?
293
9.12 Asennustestaus
294
9.13 Suorituskyky- ja kuormitustestaus
295
9.14 Luotettavuustestaus
302
9.15 Regressiotestaus
303
9.16 Savutestaus
306
9.17 Mistä tiedetään onnistuiko testiajo vai ei?
308
9.18 Heuristinen johdonmukaisuus
309
10. Virheraportoinnista
10.1 Virheraportti jakaa tietoa
Ohjelmistotekniikka
311
312
10.2 Voiko virheen toistaa?
321
10.3 Hyvän virheraportin resepti
322
10.4 Vikatietokannat
327
11. Ohjelmistojen mittaaminen
329
11.1 Mittarit
330
11.2 Ei-toiminnallinen testaus
344
11.3 Sitä saa mitä mittaa! – Kuinka mittareita huijataan
345
11.4 Järjestelmätason kattavuusmitat
346
11.5 Koodin kattavuusmitat
348
11.6 Mutkikkuusmitat
359
11.8 Virheiden kylväminen
361
12. Automaatio ja työkalut
364
12.1 Testiautomaatio kokonaisuutena
366
12.2 Mitä on testiautomaatio
367
Ohjelmistotekniikka
Eri tapoja kohteen ohjaamiseen (yksinkertaistettuna)
368
12.3 Testiautomaation lupauksia
369
12.4 Testiautomaation yleiset ongelmat
370
12.5 Automaation rajoitukset
371
12.6 Ohjelman testattavuus
374
12.7 Testiautomaatio – erilaista ohjelmistosuunnittelua
379
12.8 Automaation lähestymistavat
383
12.9 Automatisoinnin suunnittelu
393
12.10 Tunnettuja työkaluja
397
12.11 Automatisointiprojekti
398
12.12 Työkalun valinta
400
12.13 Mallipohjainen testaus
405
13. Tietoturvan testaaminen
13.1 Mitä kaikkea kuuluu tietoturvallisuuteen?
Ohjelmistotekniikka
426
428
13.2 Tietoturvan testaaminen tärkeää
430
13.3 Tietoturvatestauksen kohteet
432
13.4 Tietoturvatestauksen luonne
433
13.5 Lähtökohtana riskianalyysi
434
13.6 Paljon ohjeita
435
13.7 OWASP – Nettisivustojen tietoturva
436
13.8 OWASP – Mobiiliturvallisuus
439
13.9 PC-sovellusten uhista
440
14. Staattisen testauksen tekniikat
458
14.1 Tarkastus
459
14.2 Katselmointi
468
14.3 Läpikäynti
471
14.4 Lähdekoodin staattinen analyysi
473
15. Testauksen parantaminen
Ohjelmistotekniikka
478
15.1 Jatkuva parantaminen
480
15.2 Parantamisprojekti
481
15.3 Testaustoiminnan avainalueet –esimerkkinä TPI
487
15.4 Parantaminen vastaamaan standardien vaatimuksia
494
15.5 Testaajien sertifiointi – ISTQB
496
16. Kurssin loppukaneetti
498
Kirjallisuutta
502
Ohjelmistotekniikka
Alkusanat
Nämä luentokalvot ovat syntyneet vuosien 2003 – 2015 aikana, jolloin
Ohjelmistojen testaus -kurssi on järjestetty TTY:llä uudistetussa
muodossaan. Lähteinä on alun perin käytetty tämän kalvosarjan
lopussa listattuja kirjoja, Maaret Pyhäjärven ja Erkki Pöyhösen
koulutusmateriaaleja sekä Helsingin yliopiston vastaavan kurssin
luentomateriaalia. Muihin lähteisiin viitataan kalvoissa tarpeen mukaan.
Kalvosarjaa on uudistettu joka vuosi sen pitämiseksi ajan tasalla ottaen
huomioon DI:n lähitulevaisuuden osaamistarpeet.
OTE
Merkki
osassa kalvoja kertoo, että jokin asia on käsitelty
Ohjelmoinnin tekniikat -kurssilla ja käydään läpi joko tiiviimmin tai
täydentäen.
Ohjelmistotekniikka
12(504)
1. Kurssin tavoitteet 1/3
• Kurssin tavoitteena on oppia perusasiat ohjelmistojen
testaamisesta ja luoda hyvä pohja lisätietojen hankkimiselle
– Edistyneempiä aiheita käydään läpi tarpeen mukaan
• Luentojen avulla pyritään luomaan laajaa kuvaa testauksesta,
johon kuuluu paljon muutakin kuin vain testien suunnittelua ja
niiden ajamista
• Harjoitustyössä tarkoitus on oppia käytännön tekemisen
kautta
– Opiskelijat pitäneet sitä yleensä antoisana
• Kurssin näkökulma pyrkii myös olemaan siinä mielessä avara,
että eri sidosryhmien tarpeisiin kiinnitetään huomiota
unohtamatta esim. yritysjohtoa ja tuotteen loppukäyttäjää
Ohjelmistotekniikka
13(504)
Kurssin tavoitteet 2/3
• Vaikka valmis DI ei itse tekisikään testausta, tulee asia vastaan
kaikenlaisissa ohjelmistokehitykseen liittyvissä työtehtävissä, sekä
myyjän että ostajan roolissa, ja kaikilla organisaation tasoilla
• Jossain tapauksissa DI voi olla ainoa henkilö koko organisaatiossa,
jolla on jotain tietämystä asiasta
• Testausosaamista tarvitaan nykyään monenlaisissa
liiketoimintaprosesseissa
• Hyvässä organisaatiossa löytyy osaajia, jotka osaavat oman
alueensa työtehtävät hyvin, mutta ymmärtävät myös mitä muualla
tapahtuu
– Yksikkötestausta tekevät yleensä enemmän teknisesti orientoituneet
ihmiset ja järjestelmätestausta taas enemmän loppukäyttäjiä lähellä
olevat henkilöt
– Liiketoiminnan suunnittelussa voi tehdä monenlaista testausta
Ohjelmistotekniikka
14(504)
Kurssin tavoitteet 3/3
• Emme kuitenkaan ole ammattikoulussa.
– Emme opettele uusimpia ja muodikkaimpia välineitä, vaan
pyrimme oppimaan yleisiä periaatteita.
– DI:n pitää pystyä soveltamaan osaamistaan erilaisissa
tilanteissa ja luomaan tarvittaessa organisaatiolleen
parhaiten sopivia tapoja testata.
• Eri tehtävissä on hyvin erilainen
näkökulma testaukseen. Elämä
organisaatioissa on yhteistyötä.
Siksi niitä näkökulmia pitää
ymmärtää.
Ohjelmistotekniikka
15(504)
1.1 Kurssin lähestymistapa
testaukseen
• Lähestymme testausta objektiivisesti ja korostamme erilaisia
menetelmiä, työkaluja sekä vaatimuksia, jotka sanelevat sen,
mitä vasten ohjelmaa testataan.
• Tarkastelemme testausta osana ohjelmistotuotantoprosessia,
joka määrittelee sen, missä vaiheessa mitäkin testataan
– Yksinkertaisuuden vuoksi on joitakin todellisuuden rikkaita
yksityiskohtia on häivytetty, jotta näkisimme metsän puilta
Ohjelmistotekniikka
16(504)
1.2 Mitä tällä kurssilla ei kateta?
• Testauksen maailma on hyvin laaja ja läheskään kaikki ei
mahdu yhteen kurssiin
• Tiettyjen sovellusalueiden erityispiirteet
– Sulautetut, turvallisuuskriittiset, SOA, yms.
•
•
•
•
Testauksen hallinnointi laajoissa ja hajautetuissa projekteissa
Organisointi, roolit ja tiimien toiminta
Yksittäiset projektitoiminnan mallit ja käytännöt
Eräät testityypit kuten käytettävyystestaus, lokalisointi, A/Btestaus yms.
• Testityökalujen kirjo
Ohjelmistotekniikka
17(504)
1.3 Testaus-aiheisia verkkosivuja
• Testauksesta on paljon asiaa netissä.
• Linkkejä:
– http://mattivuori.net/extra/www_testing_links.htm
– Linkkilistassa on myös viittauksia ilmaisiin testauksen nettilehtiin.
• Wikipedia on hyvä lähde, kun haluaa selvittää mitä jokin
testauksen erikoistermi tarkoittaa.
– Siellä on hyviä esityksiä monista tämän kalvosetin asioista, jotka
joudutaan nyt kuittaamaan hyvin lyhyesti.
• Ja tietysti ihan vain Google.
Ohjelmistotekniikka
18(504)
2. Johdanto
Aloitetaan kurssi määrittelemällä, mitä olemme
opiskelemassa. Mitä testaus on ja mitä yleisiä
haasteita siihen liittyy.
Ohjelmistotekniikka
19(504)
OTE
2.1 Mitä testaus on? Erilaisia näkökulmia
• Eräitä näkökulmia siihen, mitä testaus on:
– Testaus on prosessi, jossa ohjelmaa suoritetaan tarkoituksena
löytää siitä virheitä (Myers)
– Testaus on ohjelmiston laadun mittaamista (Hetzel)
– Oleellinen osa testausta on siihen liittyvän dokumentaation,
työkalujen yms. (testware) käyttäminen ja ylläpito
(Craig&Jaskiel)
– Testaus on tekninen tutkimus, joka tehdään laatuun liittyvän
tiedon paljastamiseksi testauksen kohteena olevasta tuotteesta
(Kaner)
– Testaus on ohjelmien rikkomista (Whittaker)
– Testaus on kokeellista toimintaa, joka tuottaa tietoa
laadusta päätöksentekoa varten (useat)
Ohjelmistotekniikka
20(504)
Tavoitteena virheiden löytäminen 1/3
• Valitettavasti testaus ei voi osoittaa ohjelmiston
virheettömyyttä
• Testaus ei myöskään sinällään paranna ohjelmiston laatua,
se vain mittaa sitä ja tuottaa tietoa sen laadusta
– Tilanteen seuraamiseksi, päätöksentekoa varten
• Testaus ei ole ensisijaisesti sen varmistamista, että ohjelma
toimii niin kuin sen pitäisi
– Toimivuuden varmistaminen ei ole hyvä lähtökohta
testitapausten suunnittelulle, sillä ihminen näkee helposti vain
sen mitä haluaa nähdä
• Parempi lähtökohta on: onnistunut testiajo on sellainen, joka
aiheuttaa häiriön ohjelman toiminnassa
Ohjelmistotekniikka
21(504)
• Tällaisen testiajon seurauksena voidaan
testattavasta kohteesta löytää virhe,
jonka poistaminen vasta parantaa laatua
• Testaajan oletus: ohjelmassa on aina
virheitä, jotka vain odottavat löytymistään
• Testataan, jotta voidaan osoittaa, että
– Ohjelma tekee, mitä sen ei pitäisi
– Ohjelma ei tee, mitä sen pitäisi
– Ohjelma toimii tavalla, jota määrittely ei mainitse
• Ehkä sen pitäisi mainita?
– Ohjelmisto on hankala ymmärtää, vaikeakäyttöinen,
hidas tai toimii käyttäjän mielestä väärin
Ohjelmistotekniikka
22(504)
OTE
• Löydettyjen virheiden korjaus ohjelmassa on ensiaskel laadun
parantamisessa.
– Se parantaa heti tuotetta.
• Voidaan myös selvittää, mistä virheet johtuvat ja vaikuttaa
niiden "juurisyihin" – oliko kyse esim. määrittelyn, suunnittelun
vai toteutuksen ongelmista? Tehdäänkö niissä jotain
huonosti?
– Tällä selvittelyllä voidaan parantaa toimintaa ja vähentää virheitä
jatkossa.
• Jokainen testauksen tuottama tieto virheestä on
mahdollisuus oppia.
• Löydetty virhe on iloinen asia!
Ohjelmistotekniikka
23(504)
2.2 Aina jokin vertailukohta: Vaatimukset 1/3
• Testauksessa verrataan aina havaintoja, siihen mitä
tiedämme systeemiin kohdistuvista odotuksista
– Kuvatut vaatimukset, miten sellaiset systeemit toimivat yleensä,
mitä tiedämme käyttäjien odottavan, jne…
Vaatimus
Vertailu
Havainnot
Mietitty testi
Ohjelman
suoritus
Ohjelmistotekniikka
24(504)
Aina jokin vertailukohta: Vaatimukset 2/3
• Pitää siis selvittää, mitä systeemiltä
odotetaan
–
–
–
–
–
–
Toiminnallisuus?
Millaisia häiriöitä sen pitää sietää?
Suorituskyky?
Käytettävyys?
Tietoturvallisuus?
Jne…
• Osa vaatimuksia voi olla mietitty
tälle tuotteelle, mutta isoa osaa ei –
tarvitaan yleistä tietoa tuotteiden ja
systeemien toiminnasta ja mitä niiltä
odotetaan
Ohjelmistotekniikka
25(504)
Aina jokin vertailukohta: Vaatimukset 3/3
• Käyttäjää ymmärrettävä:
–
–
–
–
–
–
Millaisia käyttäjät ovat?
Mitä he tekevät, mikä on tavoite?
Miten he toimivat, millainen ympäristö?
Millainen laiteympäristö heillä on?
Millaista dataa käytetään?
Mikä on tärkeintä onnistua?
• Tietoja voi löytyä spekseistä, user storyistä, vastaavista
tuotteista, tiimistä, tuoteomistajilta, asiakkailta… mutta
testaajan täytyy etsiä sitä tietoa ja tehdä tulkintoja – ja tehdä
asia itselleen selväksi
Ohjelmistotekniikka
26(504)
Laatumallistandardi ISO 25010 –
tarkistuslistaksi 1/3
ISO/IEC 25010:2011. Systems and software engineering – Systems and software Quality
Requirements and Evaluation (SQuaRE) – System and software quality models. 34 p.
Huom!Vapaa käännös. Standardia ei ole suomennettu.
Piirre
Toiminnallinen soveltuvuus
Suorituskyky
Yhteensopivuus
Ohjelmistotekniikka
Ali-piirteet
Toiminnallinen kattavuus
Toiminnallinen oikeellisuus
Toimintojen oikeanlainen suunnittelu ja
toteutus
Aikakäyttäytyminen
Resurssien käyttö
Kapasiteetti
Yhteiselo toisten järjestelmien kanssa
Yhteentoimivuus
27(504)
Laatumallistandardi – ISO 25010 –
Piirre
Käytettävyys
Ali-piirteet
Tarkoitukseen soveltuvuuden
tunnistaminen
Opittavuus
Operoitavuus (helppokäyttöisyys)
Suojaus käyttäjän virheiltä
Käyttöliittymän esteettisyys
Saavutettavuus
Luotettavuus
Kypsyys
Saatavuus
Vikasietoisuus
Toipumiskyky
Tietoturvallisuus
Ohjelmistotekniikka
Luottamuksellisuus
Eheys
Kiistämättömyys
Tarkastettavuus
Autentikointi
28(504)
Laatumallistandardi – ISO 25010 –
Piirre
Ylläpidettävyys
Siirrettävyys
Ali-piirteet
Modulaarisuus
Uudelleenkäytettävyys
Analysoitavuus
Muunnettavuus
Testattavuus
Sovitettavuus
Asennettavuus
Korvattavuus
• Monia piirteitä voidaan selvittää testaamalla.
• Monia taas ei.
• Jotkut piirteet vaikuttavat siihen, miten hyvin systeemiä
kyetään testaamaan.
Ohjelmistotekniikka
29(504)
Toiminnallinen vs. ei-toiminnallinen testaus
• Vaatimukset jaetaan usein karkeasti toiminnallisiin ja eitoiminnallisiin
– Esimerkkejä ei-toiminnallisista vaatimustyypeistä: suorituskyky,
tietoturva, käytettävyys jne.
• Yleensä testauksessa käytettävät tekniikat riippuvat
voimakkaasti siitä, minkä tyyppisiä vaatimuksia on tarkoitus
testata
• Toiminnallinen testaus on "tavallista" teknistä testausta – eitoiminnallisten asioiden testaamisen lisäämiselle on painetta
– Käytettävyystestausta ja tietoturvatestausta tehdään suhteellisen
vähän
Ohjelmistotekniikka
30(504)
2.3 Virheiden lähteitä 1/3
1. Väärät käsitykset halutusta
toiminnasta
• Väärä tiedonlähde (PO asiakkaan
sijaan)
• Tieto muuttuu matkan varrella
• Erilainen konteksti
• Vanhaa tietoa
• Dokumentit: puuttuvat, väärät,
virheelliset, ei-yksikäsitteiset,
epäselvät, vanhentuneet
2. Ympäristötekijät
• Erilaiset laiteympäristöt
• Käyttöjärjestelmä
• Käyttäjän oikeudet
• Asennustapa
• Muut ohjelmisto / "DLL hell"
• Päivitykset
3. Muutokset muussa
ohjelmistossa
• Emo-ohjelman muutos (selain
rikkoo pluginit)
• Muutoksenhallinta
• Muut moduulit
Virheiden
lähteitä
7. Kääntäjien yms. viat
• Lähdekoodi kunnossa, mutta syntyy
viallista konekoodia
4. Toteutusvirheet
• Epäsopivat algoritmit
• Koodausvirheet
• Konfigurointivirheet
• Resurssien virheet
• Toisen tekemät muutokset
5. Huonolaatuiset moduulit
• Kolmansien osapuolten moduuleissa piileviä
vikoja tai yhteensopimattomuuksia
6. Väärä käännösyksikkö
• Versionhallinta
• Konfiguraationhallinta
Ohjelmistotekniikka
31(504)
Virheiden lähteitä 2/3
2. Ohjelmiston väärinkäyttö
• Väärä tarkoitus
3. Käyttäjän tavat toimia
• Erilaiset käyttäjät
1. Häiriöt
• Nettiyhteys katkeaa
• Levytila täyttyy
• Tiedostoa ei löydy
Varautumattomuus
6. Virhesyötteet
• Kirjoitusvirheet
• Väärinkäsitykset
• Puuttuva data
• Virheet tiedostoissa
Ohjelmistotekniikka
4. Käyttöympäristö
5. Sabotaasi
• Sisäiset hyökkäykset
• Ulkoiset hyökkäykset
• Murtautuminen
• Denial of service
32(504)
Virheiden lähteitä 3/3
• Uudet asiat
–
–
–
–
Uusi teknologia
Uusi toimintaympäristö
Uudet kehittäjät
Uusi tiimi
• Kompleksisuus
– Kompleksinen teknologia
– Kompleksinen kokonaisuus
• Paineet
– Aikapaineet
– Paineet toteuttaa uutta
• Tekijänä ihminen – ihmiset tekevät virheitä!
Ohjelmistotekniikka
33(504)
2.4 Missä aktiviteetissa virheet
syntyvät?
OTE
Kuva: Timo Malm, VTT. Data origin: Capers Jones. Software quality in 2008: A
survey of the state of the art.
Ohjelmistotekniikka
34(504)
2.5 Testityypin käsite
• Systeemin ominaisuuksiin liittyy läheisesti testityypin käsite.
• Se kuvaa tietyn testauksen, jolla selvitetään jonkin ominaisuuden
laatua.
– Toiminnallisuustestaus testaa toimintojen toimintaa – toimiiko kaikki,
kuten pitää. Sitä voidaan tehdä matalalla tasolla yksikkötestauksessa tai
korkealla tasolla "järjestelmätestauksen" tasolla vaikkapa käyttöliittymän
läpi.
– Käytettävyystestaus testaa käytettävyyttä.
– Suorituskykytestaus suorituskykyä jne…
• Ideana on kohdentaa testauksen fokus johonkin asiaan ja käyttää
sitten testaukseen siihen sopivia menetelmiä ja välineitä – ja myös
asian osaavia ammattilaisia.
• Toiminnallisuustestaus on kaikkein yleisintä ja siksi sitä
tarkastellaan jatkossa eniten.
Ohjelmistotekniikka
35(504)
2.6 Liiketoiminnan tukeminen
• Testausta ei tehdä umpiossa, vaan sen avulla tuetaan
esimerkiksi liiketoiminnan tavoitteita. Esimerkiksi:
• Sähköinen kauppa:
– Hyvää toimintaa asiakkaiden kanssa netissä: Hyvä
käyttäjäkokemus, luotettavuus, tietoturvallisuus, kestää
kuormitusta. Systeemiä voidaan uudistaa helposti – luotettava
pohja.
• Tuotekehitys:
– Tuotekehityksen nopeus, uutta arvoa
asiakkaalle nopealla syklillä.
– Oikeat asiat toteutettu laadukkaasti.
– Tuoteriskien hallinta.
Ohjelmistotekniikka
36(504)
Tietotarpeita, joissa testaus auttaa 1/2
• Ohjelmiston toteutus
–
–
–
–
–
–
Toimiiko ohjelma oikein ja hyvin?
Onko siinä ongelmia tai vaaroja?
Täyttääkö se projektissa asetetut vaatimukset?
Toimiiko se yhteen muiden systeemien kanssa?
Mitä käyttäjät pitävät siitä?
Mitä pitäisi parantaa?
Ohjelmistotekniikka
37(504)
Tietotarpeita, joissa testaus auttaa 2/2
• Tuoteliiketoiminta
–
–
–
–
–
–
–
–
Millaisia ratkaisuja asiakkaat suosivat?
Onko järjestelmä riittävän kypsä julkaistavaksi?
Mitä ongelmia siinä on?
Millaisia riskejä liittyy julkaisuun?
Täyttääkö se asiakkaan vaatimukset?
Onko se yhtä hyvä kuin kilpailijat?
Täyttääkö se standardien vaatimukset?
Täyttääkö testaustapa standardien vaatimukset?
• Jne…
Ohjelmistotekniikka
38(504)
Tekninen velka
• Nopeus ja ketteryys edellyttävät sitä, että alusta on hyvässä
kunnossa.
• Ei saa olla liikaa "teknistä velkaa".
• Se ei tarkoita liiallista perfektionismia, vaan esim. sitä, että
tuote on mahdollisimman bugiton koko ajan eikä leviä käsiin,
kun sitä muutetaan.
• Testaaminen ja virheiden nopea korjaus auttavat tässä.
Ohjelmistotekniikka
39(504)
2.7 Perinteinen testausprosessi
• (Perinteiseen) testausprosessiin voidaan katsoa kuuluvan
ainakin seuraavat työvaiheet:
–
–
–
–
Testauksen suunnittelu
Testitapausten luominen
Testitapausten suorittaminen
Testiajojen tulosten arvioiminen ja raportointi
• Koska aina tulee kiire, tavoitteena on määritellä käytettävä
prosessi siten, että sitä ei ruveta kiertämään asetettujen
tavoitteiden saavuttamiseksi
• Usein testauksen työmäärät aliarvioidaan vielä pahemmin
kuin muiden vaiheiden
– Ja kun tulee kiire, kumpi joustaa: koodaus vai testaus?
Ohjelmistotekniikka
40(504)
OTE
2.8 Kaikkea ei voida testata 1/3
• Käytännönläheinen esimerkki siitä, miksi kaikkea ei voida
testata:
long add(int i, int j) {
…
}
• Jos int-tyyppi vastaisi 16-bittistä kokonaislukua, ja funktio
tuottaisi samoilla syötteillä aina saman tuloksen, on
mahdollisia testitapauksia jopa 216 x 216 = 4294967296 kpl
• Jos ajatellaan yhden testitapauksen ajamiseen kuluvan
viitisen sekuntia, kuluisi kyseisen funktion testaukseen noin
680 vuotta
– 680 testaajaa selviytyisi rinnakkaistetusta tehtävästä yhdessä
vuodessa mikäli työskentelisivät kellon ympäri
Ohjelmistotekniikka
41(504)
Kaikkea ei voida testata 2/3
• Auttaisiko automaatio? Mikäli yhden testin ajoaika saataisiin
pudotettua esim. yhteen sadastuhannesosaan, kestäisi koko
funktion testaus enää vain pari päivää ilman rinnakkaisuuden
hyödyntämistä
• Valitettavasti tosielämän testikohteet ovat monimutkaisempi
kuin ko. funktio, joten automaatiollakaan ei pitkälle pötkitä
– Esim. jokaisen int-tyyppisen parametrin lisääminen kasvattaa
funktion testitapausten määrän 65536-kertaiseksi
– Realistisen ohjelman testitapausten määrä kasvaa hyvin
nopeasti liian suureksi
• Mikäli joku väittää testaavansa kaiken, kannattaa
kyseenalaistaa tämä väite
Ohjelmistotekniikka
42(504)
OTE
Kaikkea ei voida testata 3/3
• Jos esimerkiksi 1960-luvulla uuden lentokoneen
vaatimuksista 10% koski ohjelmistoa, niin 2000-luvulla luku
voi olla 80%
• Myös vaatimusten kokonaismäärä kasvaa koko ajan
• Lisäksi ohjelmiston mutkikkuus kasvaa vielä nopeammin kuin
sen koko
• Vaikka historiatietoa testauksen vaatimista työmääristä
olisikin käytettävissä, on vaikea arvioida sitä, paljonko
ohjelmiston koon kasvaminen niihin vaikuttaa
Ohjelmistotekniikka
43(504)
2.9 Testauksen koulukuntia
• Testauksen perusluonteesta on niin erilaisia näkemyksiä, että
voidaan puhua "koulukunnista".
• Niitä on hyvä ymmärtää ja tunnistaa – muuten ei voi toimia
erilaisissa ympäristöissä.
• Aiemmin niitä ovat määritelleet mm. Cem Kaner ja Brett
Pettichord:
– Kaner, Cem. 2006a. Schools of software testing. Available at:
http.//kaner.com/?p=15. [Checked 23.3.2012]
– Pettichord, Bret. 2007. Schools of Software Testing. Slide set. 33 p.
• Seuraavassa on Vuoren käsitys koulukunnista vuonna 2015.
• Ne ovat hieman karikatyyrejä ja reaalimaailmassa yhdistyvät
toisiinsa.
Ohjelmistotekniikka
44(504)
Testauksen koulukuntia 2015 1/5
• Standardointikoulukunta.
– Testauksen pitäisi perustua standardeihin, kuten ISO/IEC 29119 tai
ISTQB:n kuvaukset. Testaustapojen yhteensopivuus näiden kanssa
koetaan ammattimaisuuden osoituksena.
– Testaus on samanlaista kaikissa konteksteissa ja käytäntöjen pitäisi olla
samanlaiset.
• Laadunhallinta ja –varmistuskoulukunta.
– Testaus on osa laadunhallintaa ja laadunvarmistusta.
– Testaus on verifioinnin ja validoinnin (V&V) keino ja sitä tehdään
määritellyissä, toistettavilla tavoilla.
– Testaus on huolellisesti määritetty ohjelmistotuotannon prosesseissa.
– Testauksenhallinnalla ja mittauksella on iso rooli.
– Lähellä standardointikoulukuntaa.
Ohjelmistotekniikka
45(504)
• Automatisointikoulukunta.
– Kaikki testaus pitäisi automatisoida, mitään testausta ei pitäisi tehdä
käsin.
– Bugien luonne on sellainen, että automaatio pystyy löytämään ne.
– Testauksella pitäisi olla lähes täydellinen kattavuus.
– Testaus on luonteeltaan logistinen prosessi.
• Kehittäjäkeskeinen koulukunta.
– Kehittäjien tekemä yksikkö- ja integrointitestaus riittää yleensä.
– Testaus pitää integroida ohjelmiston tuotantoprosesseihin.
– Testiautomaation pitää olla käytännöllistä, nopeaa, yksinkertaista ja
helppoa.
Ohjelmistotekniikka
46(504)
• Laadunvarmistuskeskeinen automaatiokoulukunta.
– Testaus edellyttää haastavaa testiautomaatiota.
– Mikään kompleksisuus ei ole huonoa, jos haasteet ovat kompleksisia.
– Testaus edellyttää taakseen hyvää tiedettä, jotta testisysteemit ja
tulokset voidaan optimoida.
– Hyvä testisysteemin suunnittelu ja analyyttinen lähestymistapa ovat
tärkeitä.
– Tätä tavataan teollisuudessa kompleksisten järjestelmien testauksesta.
• Kontekstilähtöinen koulukunta / tilannetekijälähtöinen koulukunta.
– Riippuu tilanteesta, miten testausta pitäisi tehdä.
– Kontekstin arviointi on tärkeää.
– Ei ole "parhaita käytäntöjä".
Ohjelmistotekniikka
47(504)
• Älykkään testaamisen koulukunta.
– Testaus on älykästä toimintaa, joka edellyttää aina ihmiselle
ominaisia kykyjä.
– Explorointi on oleellista virheiden löytämiselle.
– Jokaisessa testattavassa asiassa on aina läsnä enemmän kuin
mitä ensisilmäyksellä voi päätellä.
– Työkalut auttavat testauksessa, mutta ne eivät "tee" testausta.
– On iso ero yksinkertaisella tarkastamisella ja todellisella
testaamisella, joka paljastaa uutta informaatiota.
Ohjelmistotekniikka
48(504)
• Rutiinikoulukunta.
– Testaus on yksinkertaista työtä, joka ei edellytä erityisiä taitoja.
– Suunnilleen jokainen organisaatiossa pystyy testaamaan.
– Kurinalaisuus ja tarkkuus ja suunnitelmien seuraaminen ovat
tärkeimmät asiat testaajien työssä.
• Holistinen koulukunta.
– Ei ole yhtä ainoaa tapaa tehdä testausta.
– Hyvä testaus soveltaa useita paradigmoja sekoituksena, joka
riippuu kontekstista.
– Kaikki lähestymistavat täydentävät toisiaan.
– Ristiriitaisetkin paradigmat ovat hyväksi testaukselle.
Ohjelmistotekniikka
49(504)
2.10 Testauksen kansanperinnettä 1/3
• Kaikissa ohjelmistokehityksen vaiheissa tehdään virheitä
• Mikäli virheitä halutaan välttää, täytyy välttää ihmisiä
• Mitä aikaisemmin virheet löydetään, sen parempi
Ohjelmistotekniikka
50(504)
Testauksen kansanperinnettä 2/3
• Pahimmassa tapauksessa viat ilmenevät vasta kun
järjestelmä on jo toimitettu:
– Therac-25-röntgenhoitokone antoi liian suuria säteilyannoksia
johtaen kuuden ihmisen kuolemaan
– ESA:n Ariane 5 –raketin epäonnistunut laukaisu aiheutti noin
seitsemän miljardin dollarin kustannukset
– Viallisten Pentium-suorittimien vaihtaminen maksoi Intelille yli
400 miljoonaa dollaria
– Kolmasosa USA:n puhelinverkosta on mykistynyt kahdesti
(AT&T ja DCS)
• Ohjelmistovirheiden vuotuiset kustannukset USA:ssa arviolta
n. 0,6% BKT:sta, eli n. $60 miljardia (The Economic Impacts
of Inadequate Infrastructure for Software Testing, 2002)
– Tilanne tuskin sen parempi Euroopassa
Ohjelmistotekniikka
51(504)
Testauksen kansanperinnettä 3/3
• Huolellisesti tehdyssä ohjelmassa on arviolta noin viisi virhettä
jokaista tuhatta koodiriviä kohti
• Windows XP:ssä oli koodia ilmeisesti n. 45 miljoonaa riviä,
jolloin siinä on arviolta ainakin 225 000 virhettä
– Vistassa oli n. 60 miljoonaa riviä koodia
• Onneksi Windows osaa päivittää itsensä verkosta
automaattisesti!
• Huom! Microsoftilla on 1:1 suhteessa kehittäjiä ja testaajia
• Käsi sydämellä: osaisiko joku tehdä saman homman
paremmin kuin Microsoft?
Ohjelmistotekniikka
52(504)
2.11 Testaus on vaativaa työtä
• Käytännössä testaajalta vaaditaan enemmän kuin koodaajalta
• Tarvitaan kokonaiskäsitystä ongelmakentästä ja testikohteen
arkkitehtuurista
• Usein tarvitaan salapoliisin taitoja testien tulosten
analysointiin
• Kuinka testata ohjelmaa, josta ei ole olemassa ainuttakaan
dokumenttia tai käyttöohjetta?
– Tämä ei ole niin harvinainen tilanne kuin saattaisi olettaa…
• Testikoodi on usein organisaation kannalta yhtä arvokasta
kuin varsinainen sovelluksen koodi
– (Automaattiset) regressiotestit mahdollistavat ohjelmiston
ylläpidon ja laajentamisen sekä myös ketterän reagoimisen
vaatimusten muuttumiseen
Ohjelmistotekniikka
53(504)
2.12 Testaus on tiimityötä
• Liian voimakas rajanveto testaajien ja kehittäjien välillä ei
kuitenkaan hyödytä lopulta ketään
– Ohjelmistokehitys on tiimityötä sanan varsinaisessa
merkityksessä
• Vaikka kaikkien testaajien ei tarvitsikaan osata ohjelmoida, on
ohjelmointitaidoista yleensä todellista hyötyä
– On hyvä tietää millaisiin virheisiin kehittäjät sortuvat
– Testiautomaation kehittäminen on softankehitystä – kaikenlaiset
pienet skriptit, niiden korjailu
• Toisaalta, vähemmän teknisesti orientoituneet testaajat voivat
ymmärtää paremmin loppukäyttäjien tarpeita
• Tiimeissä on tärkeää olla eri tavoilla ajattelevia ihmisiä
Ohjelmistotekniikka
54(504)
2.13 Mitä testaukselta voi vaatia?
• Ei voi vaatia
– Kaikkien virheiden löytämistä
– Laadun varmistusta
– Julkistamisen ajankohdan päättämistä
• Voi vaatia
– Uuden tiedon tuottamista tuotteesta
• Hyödyntää testaajia muuhunkin kuin vain virheiden
paljastamiseen
– Kokonaiskäsitystä kehitettävästä järjestelmästä ja sen laadusta
– Toimivaa kommunikaatiota tuotteen ongelmista
• Virheiden olemassaolon ja niiden korjauksen myyminen
kehittäjille
Ohjelmistotekniikka
55(504)
OTE
2.14 Keskeisiä termejä 1/6
• Virhe (error) on ohjelmassa oleva poikkeama spesifikaatiosta
• Vika (fault, defect) voi aiheutua, kun virheellinen kohta
suoritetaan tai kun pitäisi suorittaa jotain, mitä ei olekaan
toteutettu
• Häiriö (failure) on järjestelmän ulkoisessa toiminnassa
näkyvä tapahtuma, joka johtuu viasta
– Vika ei välttämättä näy järjestelmän toiminnassa ts. kaikki viat
eivät johda häiriöön
• Bugi (bug) voi tarkoittaa mitä tahansa edellisistä
Huom! Näitä termejä käytetään hyvin epäjohdonmukaisesti
Ohjelmistotekniikka
56(504)
Keskeisiä termejä 2/6
• Dynaamisessa testauksessa ohjelmaa ajetaan sopivilla
syötteillä
• Staattisessa testauksessa ei ohjelmaa suoriteta vaan
yritetään löytää virheitä tutkimalla esim. sen lähdekoodia tai
dokumentaatiota
– Dokumentaatio on softaa, joten sitä pitää testata
– Joidenkin mielestä tämä ei ole testausta sanan varsinaisessa
merkityksessä
• Spesifikaatio kertoo, miten jonkin pitäisi tai ei pitäisi toimia
– Esim. vaatimusmäärittely kertoo, mitä vaatimuksia ohjelman
pitäisi täyttää, luokan dokumentaatio kertoo, miten luokan pitäisi
toimia
Ohjelmistotekniikka
57(504)
OTE
• Testattava asia (test condition) kuvaa sen, mitä ollaan tekemässä
• Testitapaus (test case) kuvaa syötteet, joilla testikohde pyritään
saattamaan häiriötilaan sekä odotetut tulokset
• Testiproseduuri kuvaa ne stepit, joilla testitapaus suoritetaan.
Käytännössä kuvataan osana testitapausta.
• Testijoukko, testitapausjakso (test suite) on joukko (loogisesti
yhteenkuuluvia) testitapauksia
• Testiympäristö tarkoittaa sitä laitteisto- ja ohjelmistoympäristöä,
jonka kanssa testikohde on tekemisissä, mukaan lukien rajapinnat,
tyngät ja ajurit
– Testiympäristön määrittelyllä pyritään välttämään ”kyllä se ainakin eilen
toimi mun PC:ssä” –tyyppiset ongelmat virheitä metsästettäessä
– Tärkeää vastata käyttäjien / tuotantoympäristöä
– Useita erilaisia
Ohjelmistotekniikka
58(504)
• Testwareen kuuluvat kaikki dokumentit ja tuotteet, jotka
luodaan testausta varten kuten esim. testitapaukset ja
testisuunnitelmat [Craig&Jaskiel 02]
• Validointi pyrkii varmistamaan, että olemme tekemässä
oikeaa tuotetta
– Onko se oikeasti tarpeita ja odotuksia vastaava
• Verifiointi pyrkii varmistamaan, että olemme tekemässä
tuotetta oikein
– Miten tuote vastaa kirjattuja vaatimuksia
– Joidenkin formalistien mielestä vain ns. formaali verifiointi on
oikeaa verifiointia, testauksella kun ei voida osoittaa
virheettömyyttä
Ohjelmistotekniikka
59(504)
• Testausstrategia on sotasuunnitelma, joka määrittelee
testauksen laajuuden ja syvyyden, mitä testikohteen riskejä
pyritään kattamaan testausprojektin aikana ja mitä ei
• Rakkaalla lapsella on monta nimeä: yhdestä ja samasta
testausvaiheesta voidaan puhua esim. yksikkö-, moduuli- tai
komponenttitestauksena
• SUT, system under test
– IUT: implementation under test, DUT: device under test, jne.
• Ohjelmien termejä ”funktio” ja ”metodi” käytetään tällä
kurssilla vaihtelevasti tarkoittamaan samaa asiaa
– Mikäli tarkoituksena on korostaa oliotestauksen erityispiirteitä,
pyritään käyttämään termiä metodi
Ohjelmistotekniikka
60(504)
OTE
• Positiivinen testaus yrittää varmistaa sen, että testattava
järjestelmä tekee mitä sen pitäisi tehdä suorittamalla ”happy
case” -tyyppisiä, usein vaatimuksista johdettuja testitapauksia
• Negatiivinen testaus testaa niitä asioita, jotka voitaisiin lukea
”unhappy case” -kategoriaan kuuluviksi; tilanteita, joista
vaatimukset eivät yleensä sano mitään (tai vain hyvin
ylimalkaisesti), virhetilanteita, yms., joilla yritetään ”rikkoa”
testikohde
• Kattava ISTQB:n testaussanasto löytyy suomeksi täältä:
http://www.fistb.fi/sites/fistb.ttlry.mearra.com/files/istqb_sanasto.pdf
Ohjelmistotekniikka
61(504)
3. Testitapauksiin pohjautuva testaus
Dynaaminen testaus on
testitapausten miettimistä ja
suorittamista ja havaintojen
analysointia. Koska
testitapaukset sanelevat pitkälti
sen, mitä virheitä löydetään,
kannattaa niiden laatuun
panostaa. Mutta millainen on
hyvä testitapaus?
Ohjelmistotekniikka
62(504)
3.1 Testitapaus pähkinänkuoressa
OTE
• Pieni testi ohjelman käyttäytymiselle
– Ajatus asiasta, jota testataan: miten toimii laskimen jakolasku?
– Ajatus hyvästä syötteestä: kokeillaan jakolaskua nollalla
– Ajatus tuloksesta: virheilmoitus, ei saa kaatua, jotain muuta
• Suoritetaan joko mietityllä tavalla tai annetaan testaajan
valita, miten suoritus tehdään
• Voidaan suunnitella systemaattisesti joukko niitä ennen
suoritusta
• Tai luoda sellainen "lennossa"
• Tai niitä voidaan generoida automaattisesti softan
komponenttien tyypin tai softan toimintaa kuvaavan mallin
perusteella
Ohjelmistotekniikka
63(504)
Esimerkkejä
• Syötetään laskimeen tavallinen yhteenlasku ja tarkistetaan,
että se antaa oikean tuloksen.
• Syötetään tietojärjestelmään päivämäärä, jota ei ole ja
katsotaan, hallitseeko se tilanteen.
• Jätetään lomakkeella pakollinen kenttä tyhjäksi.
• Yritetään lukea ohjelmaan valtavan suuri tiedosto.
• Kokeillaan tekstitiedostolle erilaisia merkistöjä ja katsotaan
osaako se lukea ja tallentaa ne oikein.
• Yritetään avata kuvankäsittelyohjelmaan rikkinäinen tiedosto.
• Suljetaan nettiyhteys, kun ohjelma on lukemassa tietoa
netistä.
Ohjelmistotekniikka
64(504)
Mistä halutaan tietoa?
• Ennen testitapausten miettimistä pitää keksiä syy niiden
olemassaololle
– Syyksi ei riitä se, että pomo käski varmistaa, että järjestelmä
toimii oikein
• Tunnistetaan ne tilanteet ja asiat, joista pitäisi hankkia laatuun
liittyvää tietoa
• Näiden miettimisessä vaatimusdokumentista, käyttäjien
tarinoista (user story) yms. on paljon hyötyä
– Täytyy kuitenkin muistaa myös negatiivisen testauksen
näkökulma
• Joskus testaajan täytyy tukeutua pelkästään omaan
ammattitaitoonsa, jos ei ole käytettävissä mitään ”kättä
pidempää”
Ohjelmistotekniikka
65(504)
OTE
Testitapausten pitää olla haastavia
• Hyvien testitapausten keksiminen on yleensä hankalaa
• Huonot testitapaukset voivat antaa ohjelmiston laadusta liian
ruusuisen kuvan
– Se, että ohjelma näyttää toimivan niin kuin sen pitäisi, saattaa
johtua vain siitä, että testitapaukset on valittu huonosti
• Liiketoiminnan kannalta hyvät testitapaukset voivat olla jopa
arvokkaampia kuin itse testikohteen lähdekoodi
• Tyypillisesti 20% testitapauksista testaa normaalia toimintaa
(positiivinen testaus) ja 80% ”epänormaalia” toimintaa kuten
virhetilanteita yms. (negatiivinen testaus)
Ohjelmistotekniikka
66(504)
Testitapausten lähteitä 1/2
• Syötteet
– Mitä ohjelman pitää osata käsitellä? Millaisia virhesyötteitä sen
pitää sietää?
– Matalalla tasolla funktioissa ja käyttöliittymän tasolla
– Millaista dataa ohjelman pitää osata lukea? Toimiiko se
rikkinäisen datan kanssa?
– Parametrien yhdistelmät
• Tilat
– Mikä kaikki pitää olla mahdollista tilassa? Mikä pitää olla estetty?
Ohjelmistotekniikka
67(504)
Testitapausten lähteitä 2/2
• Käyttötapaukset
–
–
–
–
–
Asiat, joiden pitää onnistua. Häiriöt, jotka pitää hallita.
Käyttäjien normaalisti tekemät asiat
Käyttäjien virheet
Tahallinen väärinkäyttö
Vaarat
• Vuorovaikutus muiden komponenttien ja ohjelmien kanssa
– Normaali vuorovaikutus
– Systeemin häiriöt
• Standardien ym. Määrittämät asiat
• Jne… ylipäätään kaikenlainen käyttäytyminen systeemin eri
tasoilla
Ohjelmistotekniikka
68(504)
Kuluvan ajan minimointi 1/2
• Koska testien ajaminen voi kestää huomattavan kauan,
pyritään niiden määrää minimoimaan
• Minimointia voi tehdä suunnittelemalla testitapauksia, jotka
kattavat mahdollisimman monta tutkittavaa tilannetta
– Yksi testitapaus voi siis kattaa useamman kuin yhden tilanteen,
mutta tämä voi toisaalta hankaloittaa testitulosten analysointia
– Esimerkiksi pitkän netti lomakkeen testaus: täytetään kullakin
kerralla joukko kenttiä tietyllä tavalla – ja sitten, kun tulee virhe,
mietitään, mistä se johtui
• Ekvivalenssiositus-menetelmässä mietitään syötteiden
alueita, joilla systeemi käyttäytyy samalla tavalla – silloin voi
vain yksi testitapaus riittää
Ohjelmistotekniikka
69(504)
Kuluvan ajan minimointi 2/2
• Tilanteesta riippuen testiajojen kestosta tulee tai ei tule
projektin pullonkaula
• Testausta on tehtävä koko ajan, kun ohjelmistoa kehitetään
• Panostettava testitapausten laatuun, ei määrään
• Nopeutusta voi yrittää saavuttaa myös automatisoimalla
ainakin osan testiajoista
– Vaikka automatisointiin jouduttaisiin satsaamaan paljon
resursseja, kannattaa se yleensä tilanteissa, joissa samoja
testitapauksia ajetaan useamman kerran kuten esim.
regressiotestauksessa (esitellään myöhemmin)
– Automatisointi voi myös vapauttaa aikaa mm. parempien
testitapausten suunnitteluun
Ohjelmistotekniikka
70(504)
3.2 Testitapauksen rakenne ja sisältö
OTE
1/3
• Testitapaukseen suoritus jakaantuu yleensä neljään
vaiheeseen:
– Alustus: testikohde valmistetaan testitapauksen suorittamiselle
• Allokoidaan resurssit, alustetaan tietokannat yms.
– Suorittaminen: suoritetaan yksi testitapaus testikohteella
– Tuloksen evaluointi: verrataan järjestelmän ulostuloja
testitapauksen odottamiin tuloksiin ja annetaan tuomio
– Puhdistus: vapautetaan alustuksessa varatut resurssit
Ohjelmistotekniikka
71(504)
Testitapauksen rakenne ja sisältö 2/3
• Testitapauksen sisältö – kaikkia ei kirjata eksplisiittisesti:
– Yksilöivä tunniste (koodi – ei käytetä aina: testikoodissa funktion nimi
riittää)
– Kuvaava nimi / otsikko – tällä tunnistetaan tapaus pitkissä listauksissa ja
testiautomaation testikoodissa
– Tyyppi – toiminnallisuustesti tai muu; positiivinen, negatiivinen jne…
– Tarkoitus, esim. vaatimus tai käyttötapaus, johon testitapaus liittyy
– Formaali jäljitys vaatimukseen tms. tarpeen joskus
– Esiehdot
– Syötteet
– Odotetut tulokset
– Jälkiehdot
Ohjelmistotekniikka
72(504)
Testitapauksen rakenne ja sisältö 3/3
• Esimerkki pankkiautomaatin testitapauksesta:
–
–
–
–
–
–
–
–
Identiteetti: TT0001
Nimi: Saldokyselyn perustapaus
Tyyppi: Toiminnallisuustesti
Tarkoitus: Testataan saldokysely-toimintoa perustilanteessa, vaatimus
VT0203
Esiehdot: Kortti on syötetty automaattiin, tilillä on 100 € rahaa
Syötteet: Painetaan saldokyselynäppäintä
Odotetut tulokset: Automaatti näyttää ruudulla summan 100 €
Jälkiehdot: Automaatti palaa takaisin päävalikkoon 4,5 – 5,5 s kuluttua
Ohjelmistotekniikka
73(504)
3.3 Muita huomioita testitapauksista
• Testitapauksia käytetään lähes kaikenlaisessa testauksessa, pois
lukien esim. käytettävyystestaus, jossa terminologia on erilaista
• Vaikka testitapausta ei kirjoittaisi ylös, sen logiikka on kuitenkin
ohjaamassa testaajaa mm. tutkivassa testauksessa
• Joskus testitapauksia suunnitellaan suuri määrä ohjelman
määrittelyn perusteella, mutta on vaarana, että ne eivät enää ole
valideja, kun toteutus alkaa
– Ketterässä kehittämisessä testitapaukset suunnitellaan lähellä
toteutusta
• Joskus testauksessa vaihteleva data on isommassa roolissa kuin
varsinaiset määritetyt testitapaukset
• Mallipohjaisessa testauksessa [esitellään luennoilla myöhemmin] ei
ole välttämättä "testitapauksia", ainoastaan ohjausta ohjelman
suoritukselle
Ohjelmistotekniikka
74(504)
4. Testaus osana ohjelmistoprosessia
Ohjelmistotuotanto on paljon muutakin kuin
testaamista. Mutta miten testaus liitetään
ohjelmistoprosessiin? Tässä kohdassa käydään
läpi neljä tärkeää testaustasoa: yksikkö-,
integrointi-, järjestelmä- ja hyväksymistestaus.
Ohjelmistotekniikka
75(504)
Testaus on oleellinen osa
tuotantoprosessia
• Kuten edellä on jo todettu, testaus on oleellinen osa
ohjelmistojen tuottamista
• Testausta ei yleensä voi eikä kannata eristää muusta
ohjelmistoprosessista
• Nyrkkisäännön mukaan 20% koodista sisältää 80% virheistä,
eli testauksen suunnitteluun ja resurssien kohdentamiseen
kannattaa satsata
– Virheiden kasautuminen ei ole satunnaista, vaan yleensä ne
piileskelevät uudessa ja muuttuneessa koodissa sekä kaikista
monimutkaisemmissa komponenteissa
• Jokainen itseään kunnioittava ohjelmistotuotantoprosessi
ottaa kantaa siihen, missä vaiheessa ja mitä testataan
Ohjelmistotekniikka
76(504)
Testaus pitää aloittaa nopeasti 1/2
• Koska jopa yli puolet ohjelmistoprojektin resursseista voi kulua
testaukseen, virheiden paikallistamiseen ja korjaukseen, voidaan
prosessia parantamalla saavuttaa suuria säästöjä
– Kuten myös parantamalla testauksessa käytettäviä menetelmiä,
työkaluja yms.
• Motto: mitä aikaisemmin virheet korjataan, sen parempi
• Testata kannattaa heti, kun on jotain testattavaa
– Testaamalla toiminnon toteutusta heti, kun siitä on jonkinlainen versio
– Aloittamalla testaus heti, kun systeemin jotain osaa kyetään
suorittamaan
– Esim. kirjoittamalla alustava järjestelmätestaussuunnitelma heti, kun
järjestelmän vaatimukset ovat kyllin kypsiä
• Yksityiskohdat kannattaa kiinnittää vasta sitten, kun ne tiedetään
riittävän varmasti, näin vältytään turhalta työltä
Ohjelmistotekniikka
77(504)
Testaus pitää aloittaa nopeasti 2/2
• Testaamalla aikaisin saadaan myös parempi käsitys siitä, mihin
suuntaan projekti on menossa
– Ensiarvoisen tärkeää tietoa projektin johdolle
• Toisaalta, jos testitapaukset suunnitellaan aikaisin, kasvaa sen riski,
että ne joudutaan suunnittelemaan vielä uudestaan ennen kuin niitä
päästään ajamaan
– Jos maali liikkuu, joudutaan tähtäämään uudestaan
– Suunnittelu kannattaa tehdä oikeaan aikaan ja oikealla tarkkuustasolla
– Ketterässä kehittämisessä testaustakin rakennetaan vaiheittain
• Vielä parempi olisi tietenkin jättää virheet tekemättä
– Parannetaan ohjelmistoprosessia vähentämään virheitä
Ohjelmistotekniikka
78(504)
4.1 Testaustasot – testauksen V-malli
Vaatimusmäärittely
Hyväksymistestaus
Toiminnallinen
määrittely
Järjestelmätestaus
Arkkitehtuurisuunnittelu
Integrointitestaus
Moduulisuunnittelu
Yksikkötestaus
Toteutus
testauksen suunnittelu
tulosten verifiointi
Ohjelmistotekniikka
79(504)
Perinteinen, edelleen oleellinen
• Perinteiseen, vesiputousmallia noudattavaan
ohjelmistoprosessiin testaus liitetään V-mallin mukaisesti
• Kuvaa testauksen "tasot", jotka ovat edelleen relevantteja
kaikissa kehittämismalleissa
• Vahvassa roolissa "reguloidussa" kehittämisessä,
turvallisuuskriittisten järjestelmien kehittämistä koskevissa
standardeissa
• Kuuluu yleissivistykseen ymmärtää
• Käytännössä usein liian jäykkä sovellettavaksi kirjaimellisesti,
enemmän usein pedagoginen abstraktion
Ohjelmistotekniikka
80(504)
V-mallin logiikka 1/2
• V-mallin vasen sivu kuvaa vesiputousmallia, jossa edetään
ylhäältä alas ensin vaatimusmäärittelystä toiminnalliseen
määrittelyyn ja siitä arkkitehtuurisuunnitteluun ja lopulta
moduulisuunnitteluun ja toteutukseen
• Jokaisessa vaiheessa laaditaan testaussuunnitelmat
vastaaville testausvaiheille (oikea sivu)
• Kun testattavissa olevaa toteutusta alkaa olla olemassa,
aletaan sitä testata
– Edetään V-mallin oikeaa sivua alhaalta ylös toimien em.
testaussuunnitelmien mukaan
– Testaus verifioi kullakin tasolla, vastaako toteutus
määrittelyä/suunnittelua
Ohjelmistotekniikka
81(504)
V-mallin logiikka 2/2
• Käytettävät tekniikat vaihtelevat riippuen siitä, missä
vaiheessa ollaan menossa
– Esim. testaus alemmilla tasoilla on enemmän "konepellin alla"
koodin parissa kuin ylemmillä, jossa enemmän tarkastellaan,
miten ohjelma käyttäytyy, olipa sen toteutus tehty miten tahansa
• Jäljitettävyys eri vaiheiden välillä helpottaa virheiden
alkuperän selvittämistä
• Kun virhe on paikallistettu, voidaan testausprosessia yrittää
parantaa siten, että ko. tyypin virheet havaitaan aikaisemmin
• "Verifiointi ja validointi" ovat tyypillistä turvallisuuskriittisten
järjestelmien kehittämisen sanastoa. Seuraavalla sivulla
esimerkki sen kulttuurin tyypillisestä kaaviosta.
Ohjelmistotekniikka
82(504)
Verifiointi ja validointi V-mallin avulla
[Pezzè&Young 07 mukaellen]
Validointi
Verifiointi
Todelliset tarpeet
Käyttäjien hyväksymistestaus
Toimitettu
kokonaisuus
Katselmointi
Järjestelmätestaus
Vaatimusmäärittely
Järjestelmän
integrointi
Analysointi /
katselmointi
Integration Test
Suunnitteluspeksit
Analysointi /
katselmointi
Alijärjestelmä
Yksikkötestaus
Komponentin
suunnittelu
Komponentin
toteutus
Katselmointi käyttäjien kanssa
Ohjelmistotekniikka
83(504)
4.2 Yksikkötestaus
OTE
• Unit testing, module testing – monta nimeä
• Testataan jokainen ohjelman yksikkö erikseen
– Yksikkö voi olla moduuli, luokka, prosessi tms.
• Yksikkötestaus on yleensä osa yksikön toteutusvaihetta
– Yksikön koodaaja testaa oman toteutuksensa
• Yleensä tieto virheistä jää vain toteuttajalle
– Koska virheillä on tapana kasautua, voitaisiin tämän
tiedon avulla kohdistaa testausta paremmin
– Toisaalta ohjelmoijat voivat osoittaa testaajille
järjestelmän vaikeat kohdat muutenkin
– Mitä pikemmin yksikön toteutus testataan, sen parempi
Ohjelmistotekniikka
84(504)
Osa-alueita
• Yksikkötestauksen osa-alueet:
–
–
–
–
Rajapinnat – tärkeintä kaikenlaisille yksiköille
Raja-arvot – logiikka, muuttujat
Virhetilanteiden käsittely
Tietorakenteet (ajattele vaikka API:a, joka toteuttaa jonkinlaisen
puurakenteen)
– Suorituspolut ja silmukat – käydäänkö kaikilla poluilla oikein,
loppuuko silmukka oikein
• Testaus tapahtuu useimmiten lähdekooditasolla – halutaan
"varmistaa", että kaikki koodi toimii hyvin
• Yleensä suositaan rajapintoja keskeisenä kohteen, koska se
on suhteellisen stabiili ja toimii turvaverkkona toteutusta
refaktoroidessa.
Ohjelmistotekniikka
85(504)
Rajapintojen testaaminen 1/2
• Rajapinta koostuu yleensä funktioista, joiden parametreja ja
paluuarvoja käytetään tiedonvälitykseen
• Rajapintojen toimivuus on yleensä syytä testata ensimmäiseksi
– Ne määrittävät yksikön toiminnan ulospäin
– Jos rajapinnat eivät toimi, voi muiden testien suorittaminen olla
hankalaa ellei jopa mahdotonta
– Kun koodia kehitellään, rajapinta voi pysyä samana, mutta toteutus
muuttuu – rajapintatestejä ei tarvitse muuttaa
• Näihin liittyviä ongelmia:
–
–
–
–
Parametrien määrä ja järjestys
Parametrien ja paluuarvojen tyypit
Muutetaanko sellaisen parametrin arvoa, jonka arvoa ei saisi muuttaa?
Onko globaali data määritelty yhtenevästi kaikkialla ohjelmassa?
Ohjelmistotekniikka
86(504)
Rajapintojen testaaminen 2/2
• Käytettävästä ohjelmointikielestä riippuen hyvä kääntäjä
huomaa suurimman osan em. virheistä
– Valitettavasti nykyään niin suositut dynaamiset skriptikielet ovat
tässä suhteessa huonossa asemassa
• Kääntäjä ei sen sijaan yleensä pysty huomaamaan sitä,
tulkitseeko sekä kutsuja että kutsuttava
parametrin/paluuarvon samalla tavalla
– Esim. toinen luulee arvon tarkoittavan senttejä ja toinen tuumia
(tämän kaltaisen virheen takia NASA on menettänyt yhden
avaruusluotaimen)
“NASA lost a $125 million Mars orbiter because a Lockheed Martin
engineering team used English units of measurement while
the agency's team used the more conventional metric system
for a key spacecraft operation, according to a review finding
released Thursday.”
– “Metric mishap caused loss of NASA orbiter”, CNN, September 30, 1999
Ohjelmistotekniikka
87(504)
Raja-arvojen testaaminen
• Muistilista:
– Parametrien ja paluuarvojen raja-arvot
– Silmukoiden pyörimiskertojen raja-arvot
– Tietorakenteisiin liittyvät raja-arvot
• Esim. kasvaako ja pieneneekö dynaaminen tietorakenne
oikein silloin kun muistia todella varataan tai vapautetaan
• Raja-arvo- analyysiä käsitellään myöhemmin tarkemmin
Ohjelmistotekniikka
88(504)
Virhetilanteiden testaaminen 1/2
•
•
OTE
Virhetilanteiden käsittely jää usein vähälle huomiolle ohjelman
suunnittelussa
Valitettavasti myös virhetilanteiden testaaminen on silloin yleensä
lapsipuolen asemassa
– Vaikka ohjelma muuten olisikin suunniteltu testausystävälliseksi,
virheidenkäsittely ei välttämättä ole sitä
•
Tuloksena
– Ohjelma, joka ei hallitse pieniäkään häiriöitä
– Ohjelman antamat virheilmoitukset voivat olla käyttäjän kannalta täysin
hyödyttömiä tai jopa harhaanjohtavia
•
Huonosti tehty virheenkäsittely voi vaarantaa myös tietoturvan
Ohjelmistotekniikka
89(504)
Virhetilanteiden testaaminen 2/2
• Virhetilanteiden testauksen muistilista:
– Onko virheenkäsittely tehty oikein?
• Onko virheestä toipuminen mahdollista?
– jos ei, kaadetaanko ohjelma käyttäjäystävällisesti?
– Onko virheenkäsittely tehty siten, että käsittelyyn ylipäänsä
päästään vai kaatuuko ohjelma jo ennen sitä?
– Heitetäänkö oikea poikkeus?
– Onko virheilmoitus ymmärrettävä?
– Vastaako virheilmoitus tapahtunutta virhettä?
– Auttaako virheilmoitus käyttäjää paikallistamaan virheen syyn ja
pääsemään eteenpäin?
– Ovatko virheilmoitukset yhtenevät kaikissa yksiköissä?
Ohjelmistotekniikka
90(504)
Tietorakenteiden testaaminen 1/2
• Yksikön toteuttamat (lokaalit) tietorakenteet ovat virheherkkiä
• Myös yksikön käyttämien, jossain muualla toteutettujen
tietorakenteiden vaikutukset, tulisi testata yksikön testauksen
yhteydessä
–
–
–
–
–
Tyyppivirheet
Oletusarvojen alustukset
Muuttujien nimien oikeinkirjoitus
Tietotyyppejä käytetään yhtenevästi
Yli- ja alivuodot, poikkeukset
• Hyvä kääntäjä huomaa jälleen ainakin osan näistä virheistä
• Tietorakenteisiin kannattaa kiinnittää huomiota myös koodin
tarkastuksissa
Ohjelmistotekniikka
91(504)
Tietorakenteiden testaaminen 2/2
• Testaus usein rajapintojen testauksen "sivutuotteena":
– Funktion testaus jollain syötteellä. Toimiiko se oikein?
– Sitten: onko tietorakenteet päivitetty tai purettu kuten pitää.
• Aina kun on mahdollista, kannattaa käyttää valmiita, hyvin
testattuja tietorakenteita
– Kielten ja ympäristöjen vakiokirjastot turvallisimpia
– Esim. C++:n Standard Template Library (STL), see
http://en.wikipedia.org/wiki/Standard_Template_Library
Ohjelmistotekniikka
92(504)
OTE
Suorituspolku- ja silmukkatestaus 1/3
• Koodin haarautumiskohdat ovat virheherkkiä
– Ehtolauseet, silmukat, hypyt
• Testitapauksia kannattaa valita sen mukaan, että mahdollisimman
monta kriittistä suorituspolkua yksikön läpi tulee testattua
– Valitaan esim. funktion syötteeksi sellaisia arvoja, että silmukoita tulee
kierrettyä eri tavoilla
• Testattavien suorituspolkujen joukkoon kannattaa valita erityisesti
niitä, joissa voisi todennäköisesti syntyä virhetilanne (esim. syötteen
arvosta riippuen)
• Silmukoita testattaessa kannattaa erottaa toisistaan yksinkertaiset,
sisäkkäiset ja peräkkäiset silmukat
• Myöhemmin tutustutaan tekniikoihin, joilla yksinkertaisia silmukoita
voidaan testata
– Esim. testitapaukset keskittyvät silmukkamuuttujan raja-arvoihin
Ohjelmistotekniikka
93(504)
• Nämä tekniikat yleistyvät myös sisäkkäisiin silmukoihin
– Ongelma on tarvittavien testitapausten määrän nopea kasvu
sisäkkäisyyden kasvaessa
– Sisäkkäisten silmukoiden testaukseen on kehitetty strategioita,
joilla pyritään pitämään testitapausten määrä kohtuullisena
• Esim. testataan sisäkkäisin silmukka ensin täydellisesti
pitäen ulompien silmukoiden silmukkamuuttujat
minimiarvoissaan, sitten toiseksi sisäkkäisin jne.
• Peräkkäiset silmukat voivat olla joko riippumattomia tai
riippuvaisia toisistaan
– Riippuvuus syntyy esim. tilanteesta, jossa jälkimmäisen
silmukkamuuttujan arvo alustetaan käyttäen ensimmäisen
silmukkamuuttujan arvoa (usein myös ongelmia koodissa…)
Ohjelmistotekniikka
94(504)
• Toisistaan riippuvien silmukoiden testaamiseen voidaan
käyttää soveltaen sisäkkäisten silmukoiden testaukseen
kehitettyjä heuristiikkoja
• Riippumattomien silmukoiden testaus palautuu
yksinkertaisten silmukoiden testaamiseen
Ohjelmistotekniikka
95(504)
Yksikkötestauksen toteuttaminen 1/4
• Lyhyitä selkeitä testifunktioita ja niissä yksinkertaisia
tarkistuksia
– Testikehyksen määrittelemät ”älykkäät” assertiot (xUnittyökaluissa paljon erilaisia), jotka tuottavat raportoinnin. Kielten
omia assertteja ei pidä käyttää testauksessa – usein ne
keskeyttäväkin testiajon, mikä ei ole järkevää.
– Assertteja ei laiteta tuotantokoodiin, vaan sitä testaavaan
testikoodiin (tuotantokoodissa ne eivät ole testausta, vaan
sekaisin menneen ohjelman keskeyttämistä varten)
– … alla pseudokoodia
TEST_TYPE test_square_root() {
double result = my_sqrt(x);
ASSERT_TRUE((result * result) == x); // Huom. Pieni
bugi testikoodissa (mikä?) – yksinkertaistuksen
vuoksi…
}
Ohjelmistotekniikka
96(504)
• Koska yksiköt eivät yleensä voi toimia itsenäisesti, vaatii
niiden testaaminen apukoodin kirjoittamista, jota käytetään
vain testauksessa
– Vaikkapa rutiineja, jotka palauttavat mukamas netistä luetun
tiedoston sisällön
• Testikoodi on koodia siinä missä testattavakin koodi
– Se on tehtävä ja dokumentoitava vähintään yhtä huolellisesti
– Myös testikoodia on testattava ja ylläpidettävä
– Englanninkielinen termi ”scaffolding” eli rakennusteline kuvaa
hyvin testikoodin suhdetta testattavaan koodiin
• Testikoodi "ympäröi" tuotantokoodia, heijastellen sen
rakennetta (AddBalance(amount) <> testAddBalance())
Ohjelmistotekniikka
97(504)
• Tärkeitä yksikkötestauksen toteuttamiseen liittyviä käsitteitä
ovat ajuri ja tynkä (testikehyksen ohella)
• Ajuri (driver, test bed)
– Ohjelma, joka ottaa syötteenään testitapaukseen liittyvää dataa
ja syöttää datan testattavalle yksikölle
– Huolehtii yksikön tuottamien tulosten keräämisestä ja niiden
välittämisestä edelleen analysoitavaksi
– Kannattaa suunnitella siten, että sitä voidaan käyttää usean eri
yksikön testaamiseen
– Kannattaa suunnitella rinnan testattavan yksikön kanssa
– Ongelmat ajurin suunnittelussa voivat paljastaa virheitä
testattavan yksikön suunnittelussa
Ohjelmistotekniikka
98(504)
• Tynkä (stub)
– Korvaa testattavan yksikön kutsuman toisen yksikön
• Jokaista kutsuttavaa yksikköä varten tarvitaan oma tynkänsä
– Tyngän tehtävät:
• Toteuttaa tarvittavat rajapinnat
• Palauttaa kontrollin testattavaan yksikköön
• Käsittelee mahdollisimman vähän saamiaan syötteitä
• Palauttaa vain simuloidun arvon tai vaikka heittää poikkeuksen
– Tulisi suunnitella siten, että se olisi mahdollisimman helppo toteuttaa
– Merkitys korostuu erityisesti virhetilanteita testattaessa
• Virhetilanteiden generoiminen on työlästä ja niiden systemaattinen
etsiminen on erittäin vaikeaa
• Tarkoitusta varten suunnitellun tyngän avulla haluttu virhetilanne
saadaan aikaan helposti
Ohjelmistotekniikka
99(504)
Huomioita olio-ohjelmien
yksikkötestauksesta
•
•
Melkein kaikki ohjelmat ovat nykyään olio-ohjelmia.
Niiden testaukseen liittyy monia seikkoja, joita on hyvä erityisesti tiedostaa
ja ottaa huomioon. Tällaisia ovat:
– Olion käyttäytyminen riippuu sen tilasta
– Oliot kätkevät dataa ja kätkettyä dataa on paljastettava testauksessa
– Yksityisten metodien erityinen testaaminen voi joissakin kielissä olla haastavaa –
sen kanssa pitää vain elää
– On hyvä miettiä luokkien tulevaa käyttöä ja sitä, miltä osin kanta- ja lapsiluokat
kannattaa testata
– Ja millaiset testitoteutukset tehdään abstrakteille luokille
– Rakentajien ja niiden mahdollisten ongelmien hyvä testaus on erityisen tärkeää
(siksikin, että rakentajissa ei aina voi heittää poikkeuksia)
•
Kurssilla näitä asioita ei ole mahdollista tarkastella perusteellisesti, mutta
suosittelemme tähän erilliseen kalvosarjaan tutustumista:
– http://www.cs.tut.fi/~testaus/s2015/luennot/Olio-ohjelmien_testauksesta.pdf
Ohjelmistotekniikka
100(504)
OTE
Top 8 pointit yksikkötestaukseen
• Mieti, mikä on metodille kaikkein tärkeintä
– Miten sitä käytetään (kuka, missä olosuhteissa), millä parametreilla sitä
kutsutaan
• Keskity rajapintaan – se on stabiili, mutta toteutus voi muuttua
• Testaa kaikkein yleisimmät tapaukset
• Tee metodista robusti
– Testaa yleisimmät virhe- ja poikkeustilanteet
– Testaa kaikki raja-arvot
– Testaa parametrien kombinaatiot
• Ole luova – niin ovat metodin kutsujatkin
• Seuraa testikattavuutta, mutta muista, että se ei usein kerro
paljoakaan testauksen todellisesta kattavuudesta
• Tee testeistä niin yksinkertaisia kuin mahdollista
• Käytä testikehystä, kuten JUnit tai QTest ja noudata sen käytäntöjä
Ohjelmistotekniikka
101(504)
xUnit-testauskehykset 1/2
• Yksikkötestauksessa kannattaa käyttää valmiita
testauskehyksiä, koska:
– Ne perustuvat yleisesti käytettyihin (eli monille tuttuihin) hyviin
tapoihin rakentaa testejä.
– Sellaisia löytyy valmiina monille kielille ja usein ilmaisina,
avoimen lähdekoodin ohjelmina.
– "xUnit-perheeseen" kuuluu useita hieman erilaisia kehyksiä eri
ohjelmointikielille jne.
– Lisätietoja xUnit-ohjelmista: http://en.wikipedia.org/wiki/XUnit
– Yksi ensimmäisistä ja suosituimmista on JUnit, testikehys Javaohjelmien yksikkötestaukseen
– Myös Qt:n QTest noudattaa näitä periaatteita
Ohjelmistotekniikka
102(504)
xUnit-testauskehykset 2/2
• Periaate:
– Useita suunnittelumalleja (design patterns) hyödyntämällä tehty
testikehys, jossa testejä tai testijoukkoja kuvataan olioilla
– Testitapausten strukturointi ja työkalut niiden ajamiseen
– Testitapauksilla tietty rakenne – setUp, suoritus, tearDown
– Testitapauksia yhdistetään kokoelmiin, suitet, suoritusta varten
• Edut:
– Valmiita toimintoja testitapausten ajamiseen, tarkistuksiin ja
tuloksista raportointiin
– Määrämuotoiset testitapaukset helpottavat testien ylläpitoa
– Voidaan käyttää myös integrointitestauksen apuna
– Moni työkalu tuottaa esim. JUnit-yhteensopivia testejä tai
raportteja Junit:n tulosformaatissa
Ohjelmistotekniikka
103(504)
4.3 Test-Driven Development
• Perinteinen yksikkötestauksen tapa on ongelmallinen
– Yksikkötestejä tehdään satunnaisesti, jos on aikaa
– Eli käytännössä niitä ei tehdä lainkaan tai vain joillekin luokille ja
metodeille
• TDD:n tapa
– Yksikkötestaus on rutiinia
– Kun uutta metodia suunnitellaan, sille tehdään yksikkötestit jo
ennen metodin toteutusta
– Testien läpäisy kertoo koodauksen edistymisestä
– Tuloksena on tasalaatuinen joukko yksikkötestejä, jotka ovat
turvaverkko koodia kehiteltäessä
Ohjelmistotekniikka
104(504)
TDD pähkinänkuoressa
• Kirjoita testi toiminnallisuudelle perustuen sen rajapintaan ja
parametreihin
• Aja testi ja tarkista, että se failaa – koska toteutusta ei vielä
ole
• Koodaa toteutus
• Aja testi(t) ja tarkista, että ne menevät läpi
• Testit on integroitu kehitysympäristöön ja ajetaan aina
käännettäessä
• Siisti toteutus (refaktorointi)
• Automatisoidut testit ovat nyt turvaverkko toteutuksen
muutoksille
Ohjelmistotekniikka
105(504)
Vaatimukset TDD:n käytölle
• Halukkuus tehdä yksikkötestejä
• Kehitysympäristö, jossa yksikkötestien rungon tekeminen
metodeille on mahdollisimman helppoa (eli nykyaikainen IDEympäristö, jossa työkalut valmiina tai jonkun xUnitin voi
integroida)
• Paikalliseen buildaukseen integroitu testien ajo
• Nopea kehitysympäristö, jossa testien ajo on välitöntä
• Uusi kehitys: "jatkuva kääntäminen" ja jatkuva yksikkötestien
suoritus – viiveet vähenevät, palaute välitöntä
Ohjelmistotekniikka
106(504)
TDD:n vaikutus laadulle
• Plussaa
– Pakottaa tekemään yksikkötestejä
• Ei välttämättä plussaa
– Koetaan kuitenkin enemmän suunnittelu- kuin
testausmenetelmäksi (käyttäytymisen määrittely on pääosassa)
– testaus kaipaa mindsettiä, jossa ei olla suunnittelemassa
– Ei ole näyttöä, että tuottaisi parempaa yksikkötestausta kuin
muut yksikkötestauskäytännöt
– Liiallinen systematisointi ei välttämättä ole hyvä kokonaisuudelle
Ohjelmistotekniikka
107(504)
4.4 Testitapausten
suunnittelutekniikoita
• Testitapausten suunnitteluun on kehitetty erityisiä tekniikoita.
Niitä hyödynnetään kaikilla testaustasolla, mutta eniten
yksikkötestauksessa.
• Käydään siksi nyt läpi tärkeimmät tekniikat.
• Menetelmät tuovat sopivaa systematiikkaa testisuunnitteluun.
• Käytännössä menetelmiä sovelletaan yhdessä ja ne tukevat
testitapauksia suunnittelevan henkilön ajattelua.
• Ne kuvaavatkin oikeastaan ajattelumalleja.
Ohjelmistotekniikka
108(504)
OTE
4.5 Ekvivalenssiositus-menetelmä 1/5
• Minimoidaan tarvittavien testitapausten määrää osittamalla
ohjelman syöteavaruus ekvivalenssiluokkiin, joille pätee että
– Kun jokin luokan edustaja aiheuttaa häiriön, myös mikä tahansa
muu ko. luokan edustaja aiheuttaa saman häiriön
– Kun jokin luokan edustaja ei aiheuta häiriötä, ei mikään
muukaan ko. luokan edustaja aiheuta häiriötä
• Siis: ohjelman voidaan olettaa toimivan samoilla tietyn alueen
syötteillä
• Koko syötedomainin testaamisen sijasta luotetaan siis siihen,
että voidaan valita yksi siitä edustaja
Ohjelmistotekniikka
109(504)
Ekvivalenssiositus-menetelmä 2/5
• Ekvivalenssiluokkien tunnistaminen
– Valitaan jokin syöteavaruuden ehto, ja jaetaan se kahteen tai
useampaan luokkaan
– Lähtökohtana jako sallittuihin ja ei-sallittuhin
– Esim., jos kentässä pyydetään positiivista kokonaislukua, on yksi
iso luokka positiiviset kokonaisluvut ja toinen luokka negatiiviset
– Positiivisia voidaan sitten jaotella erikseen useisiin luokkiin
Ohjelmistotekniikka
110(504)
• Muutamia suuntaviivoja ekvivalenssiluokkien valintaan:
– Jos syöteavaruuden ehto määrittelee välin laillisia arvoja tyyliin
”kappalemäärä on väliltä 1-999”, synnytetään kolme
ekvivalenssiluokkaa: (1 ≤ kpl ≤ 999), (kpl < 1) ja (999 < kpl)
– Jos ehto määrittelee arvojen lukumäärän tyyliin ”ajoneuvolla voi
olla yhdestä kuuteen omistajaa”, synnytetään yksi luokka
vastaamaan laillisia arvoja ja kaksi luokkaa vastaamaan laittomia
arvoja ”ei omistajaa” ja ”enemmän kuin kuusi omistajaa”
Ohjelmistotekniikka
111(504)
– Mikäli ehto määrittelee joukon arvoja, joiden käsittelyn voi olettaa
olevan erilainen, synnytetään jokaista arvoa kohti oma
luokkansa sekä yksi luokka vastaamaan laitonta arvoa
• Esim. ”ajoneuvo voi olla joka linja-auto, rekka, henkilöauto tai
moottoripyörä” synnyttää neljä laillisia arvoja vastaavaa
luokkaa sekä luokan, joka vastaa laittomia arvoja esim.
”perävaunu” tai ”muut ajoneuvot”
– Mikäli kyseessä on ehdoton vaatimus tyyliin ”ensimmäisen
kirjaimen pitää olla iso kirjain”, luodaan kaksi luokkaa, toinen
vastaamaan laillista arvoa ”iso alkukirjain” ja toinen laitonta
arvoa ”pieni alkukirjain”
– Mikäli on syytä epäillä, että kaikkia ekvivalenssiluokan edustajia
ei käsitellä ohjelmassa samalla tavalla, pitää luokka jakaa
edelleen niin moneen pienempää luokkaan kuin tarpeellista
Ohjelmistotekniikka
112(504)
• Kun jako luokkiin on tehty, luokkien edustajista luodaan
testitapauksia
• Laittomien testitapausten pitäisi testata vain yhtä laitonta
ekvivalenssiluokkaa kerrallaan
• Kun testataan montaa muuttujaa, voidaan luoda kaikkien
ekvivalenssiluokkien, sekä laillisten että laittomien, kaikkia
kombinaatioita vastaavat testitapaukset
– Tuloksena kattavampi testaus, mutta hintana paljon suurempi määrä
testitapauksia, joiden ajamiseen voi kulua liikaa aikaa
– Testitapausten ohjelmallinen generointi tällöin hyödyllistä (kuvittele
kombinaatioiden taulukko, josta testit tehdään)
• Ekvivalenssiluokkien käyttökelpoisuus ei rajoitu ainoastaan
syötteisiin, vaan tekniikkaa voidaan käyttää myös lähtien tulosten
arvoalueista
Ohjelmistotekniikka
113(504)
4.6 Raja-arvoanalyysi 1/3
• Kokemus on osoittanut, että ohjelmoijat tekevät helposti
virheitä muuttujien ja parametrien arvoalueiden (esim.
ekvivalenssiluokkien) rajoilla
– Esim. käytetään operaattorin ≤ sijasta operaattoria < tai
silmukkamuuttujan alkuarvo on ”off by one”
• Silmukassa saatetaan pyöriä yksi kerta liian vähän
• Joukosta parametreja valitaan tyypillisesti kerralla yksi, jonka
raja-arvoja testataan, muiden parametrien arvojen ollessa
”normaaleja” (nominal) eli tiukasti arvoalueen (esim.
ekvivalenssiluokan) sisällä
Ohjelmistotekniikka
114(504)
Raja-arvoanalyysi 2/3
• Valitaan:
– Parametrin laillisen arvoalueen minimiä (min) ja maksimia (max)
vastaavat tapaukset
– Hieman pienempi kuin minimi (min-) ja hieman suurempi kuin maksimi
(max+)
– Jos parametrilla on useita laillisia arvoalueita (ekvivalenssiluokkia),
valitaan tapaukset niiden kaikkien rajoilta
• Raja-arvoanalyysi toimii parhaiten silloin, kun tarkasteltavana on
joukko parametreja, joilla ei ole keskinäisiä riippuvuussuhteita ja
jotka kuvaavat esim. lukumääriä tai fyysisiä suureita kuten
lämpötilaa, painetta, nopeutta, painoa jne.
Ohjelmistotekniikka
115(504)
OTE
Raja-arvoanalyysi 3/3
• Esim. totuusarvoiselle tai loogista arvoa kuvaavalle
parametrille ei yleensä voi eikä kannata tehdä rajaarvoanalyysiä
• Esimerkki fyysisten suureiden tärkeydestä:
– Kesäkuussa 1992 Phoenixin kansainvälinen lentokenttä
jouduttiin sulkemaan kun lentäjät eivät voineet tehdä tiettyjä
säätötoimenpiteitä; instrumentit hyväksyivät korkeimmaksi
mahdolliseksi ilman lämpötilaksi 120 °F lämpötilan ollessa 122
°F (≈ 50 °C)
• Myös oletus riippumattomuudesta on tärkeä; mikäli näin ei
voida olettaa, voivat tulokset jäädä laihoiksi
• Muuttujien arvoalueiden reunojen testaaminen ei yleensä ole
järkevää (esim. kokonaislukumuuttujaan mahtuva suurin arvo)
Ohjelmistotekniikka
116(504)
Funktion tulosten ja muuttujien arvoalueiden
hyödyntäminen
• Näitä menetelmiä ei kannata käyttää pelkästään
syötelähtöisesti
• Virheitä löydetään myös käyttämällä niitä tulosten ja ohjelman
käyttämien muuttujien arvoalueiden kanssa
• Esimerkiksi:
– Jos tiedetään, että tuloksen arvo on väliltä 1..100 niin testataan
syötteillä, joiden pitäisi tuottaa tulokset 1 ja 100
– Jos silmukka voi pyöriä ympäri nollasta kymmeneen kertaan,
testataan syötteillä, joiden pitäisi saada se pyörimään 0 ja 10
kertaa
– Testataan syötteillä joiden pitäisi tuottaa virheilmoituksia
Ohjelmistotekniikka
117(504)
Worst case -testaus
• Pitäisikö kaikki mahdolliset kombinaatiot raja-arvoista testata?
• Kun kaikkien parametrien raja-arvoista (min, min-, nominal,
max, max+) arvoista otetaan karteesinen tulo, saadaan
n
aikaiseksi 5 testitapausta
• Raja-arvoanalyysin perusversion tuottamat testitapaukset
ovat luonnollisesti tämän osajoukko
• Testitapausten suuresta määrästä johtuen worst case testaus kannattaa yleensä vain mikäli vaaditaan korkeaa
luotettavuutta
Ohjelmistotekniikka
118(504)
4.7 Kombinaatioiden testauksesta 1/7
• Mikäli halutaan testata kaikki mahdolliset ekvivalenssiluokkien
kombinaatiot, kasvaa testitapausten määrä helposti liian
suureksi
• Toinen vaihtoehto olisi testata siten, että jokainen luokka tulee
testattua vain vähintään kerran
– Valitettavasti tämä ei ole kovin tehokasta virheiden löytymisen
kannalta
• Näiden kahden ääripään väliin jää käyttökelpoinen vaihtoehto:
sen sijaan, että pyrittäisiin kattamaan kaikki mahdolliset
kombinaatiot, katetaankin kaikki luokista muodostuvat parit tai
kolmikot
Ohjelmistotekniikka
119(504)
Kombinaatioiden testauksesta 2/7
• Esimerkki tarkoituksena testata kuvitteellista WWW-sivustoa
erilaisissa ympäristöissä:
–
–
–
–
Kielet: suomi, englanti, ranska, espanja
Selaimet: IE, Firefox, Chrome, Opera
Fonttikoot: small, medium, huge
Näytön koko: small_laptop, family_desktop, huge
• (Detaljit on tässä abstrahoitu, koska ne muuttuvat joka vuosi)
Ohjelmistotekniikka
120(504)
• Jos halutaan kattaa kaikki mahdolliset kombinaatiot, tarvitaan
144 (4 * 4 * 3 * 3) testitapausta
– Mikäli esim. tekstin luettavuutta ruudulla arvioimaan tarvitaan
ihminen, on tämä aivan liian paljon
• Mikäli tyydytään kokeilemaan vain jokaista vaihtoehtoa
kerran, tarvitaan vain neljä testitapausta
– Vaikka testitapaukset valittaisiinkin hyvin, jää testaus kovin
ylimalkaiseksi
• Mikäli järjestelmään lisättäisiin uusia parametreja, esim.
nettiyhteyden nopeus testitapausten määrä kasvaisi
eksponentiaalisesti, jos se haluttaisiin testata eri
kombinaatioilla.
Ohjelmistotekniikka
121(504)
• Kultainen keskitie: katetaan kaikki mahdolliset parit
(parikattavuus)
– Kaikkien kombinaatioiden testauksessa tarvitaan jokaista
kombinaatiota kohti oma testitapauksensa
– Nyt esim. testitapaus {suomi, IE, small_font, small_laptop} kattaa
useamman kuin yhden parin: (suomi, IE), (IE_small_laptop) jne.
– Kaikki parit pystytään esimerkkitapauksessa kattamaan 19
testitapauksella, jotka on listattu seuraavalla sivulla
– Listau tehty AllPairs-ohjelmalla
(http://www.satisfice.com/tools/pairs.zip)
• Merkintä ”~” tarkoittaa, että valinnalla ei ole parikattavuuden
kannalta väliä
• Pienin mahdollinen ratkaisu sisältäisi 16 testitapausta, joten
AllPairs pääsee melko lähelle
Ohjelmistotekniikka
122(504)
Ohjelmistotekniikka
123(504)
• Kattamalla parien sijaan kaikki mahdolliset kolmikot saadaan
kattavampi testaus, mutta testitapausten määrä pysyy silti
useimmiten kohtuullisena
• Koska parien tai kolmikkojen generointi voi olla kovin työlästä,
on niiden etsimiseen kehitetty joukko algoritmeja ja työkaluja
• Aiheesta kertovan Pairwise Testing -sivuston Tools-sivulla on
listattu monia työkalua edellä käytetyn AllPairsin lisäksi.
– http://pairwise.org/tools.asp
Ohjelmistotekniikka
124(504)
• Mikäli jokin tärkeä kombinaatio puuttuu 100 % parikattavasta
testitapausten joukosta, kannattaa se siihen lisätä, vaikka se
ei enää lisäisikään parikattavuutta
• Toisaalta, mikäli kombinaatioille on rajoituksia, tyyliin
värivaihtoehto ”monochrome” on laillinen vain kun näytön
koko on ”PDA”, voidaan ensin tuottaa kaikki parit ja poistaa
sitten laittomat vaihtoehdot
– Koska poistettu vaihtoehto saattoi edustaa laillisiakin pareja,
täytyy mahdollisesti lisätä uusia testitapauksia kattamaan
tällaiset parit
Ohjelmistotekniikka
125(504)
4.8 Fuzz-testaus 1/3
• Tehdään käytettyihin tiedostoihin erilaisia virheitä ja
katsotaan, miten ohjelma selviää tiedostojen kanssa.
– Virheet pitää käsitellä hallitusti, ei saa kaatua.
– Virheitä voidaan tehdä eri tyyleillä – satunnaisesti korruptoiden
("dumb fuzzing") tai vaikka generoimalla erilaisia XML-tiedostoja.
• Mm. Microsoft tekee tätä (Ks. MS:n kirja The Security
Development Lifecycle)
• Tunnettu suomalainen ohjelma Radamsa
(https://www.ee.oulu.fi/research/ouspg/Radamsa)
– Avoin lähdekoodi.
Ohjelmistotekniikka
126(504)
Fuzz-testaus 2/3
• MS:n mukaan dumb fuzzing -tapoja ovat mm.:
–
–
–
–
–
Tehdään tiedostosta normaalia lyhyempi.
Täytetään koko tiedosto satunnaisella datalla.
Täytetään osia tiedostosta tiedosto satunnaisella datalla.
Etsitään 0-tavuja ja korvataan ne ei-nollilla.
Vaihdetaan numerot negatiivisiksi. Asetetaan numeroita nolliksi.
Muutetaan numerot arvoon 2^N +/- 1.
– Vaihdetaan peräkkäisiä tavuja keskenään.
– Asetetaan tai tyhjennetään numeroiden ylimmät bitit. Tehdään
OR/XOR-muunnoksia biteille.
Ohjelmistotekniikka
127(504)
Fuzz-testaus 3/3
• Kuvatiedostoille esim.:
– Virheellinen värisyvyystieto, otsikkotietojen muunnoksia,
leveyden ja korkeuden asetus nollaksi jne…
• Verkkoliikenteelle:
– Viallisia paketteja. Viallisia HTTP-otsikkotietoja. Jne…
– Pakettien muuttaminen lennossa proxyllä.
Ohjelmistotekniikka
128(504)
4.9 Matalan tason integrointitestaus
OTE
• Integrointitestausta voidaan tehdä usealla
tasolla. Tarkastelemme ensin "tavallista"
matalan tason integrointitestausta ja
myöhemmin
järjestelmäintegrointitestausta.
• Yksikkötestauksen jälkeen yksiköt
integroidaan isommiksi kokonaisuuksiksi.
• Integrointitestauksessa testataan
yksiköiden rajapintoja ja niiden
yhteistoimintaa.
• Hyödynnetään mahdollisuuksien mukaan
testiautomaatiota.
Ohjelmistotekniikka
129(504)
Suurin osa integroinnista tapahtuu joOTE
kehittäjän työasemassa
• Nykyaikaisessa ohjelmistokehityksessä ohjelmistokehittäjillä
on versionhallinnan kautta koko ohjelma käytettävissä.
– Siinä tilassa, jossa kaikki muut ovat palauttaneet tuotoksensa
yhteiseksi.
• Omaa koodia kehitetään kokonaisuuden puitteissa.
• Kehittäjän tekemä testaus kohdistuu omaan tuotokseen,
mutta samalla tarkistetaan, että koko ohjelma kääntyy ja
ainakin käynnistyy.
• Itse siis integroidaan oma uusi koodi kokonaisuuteen ja
kokeillaan yksikkötesteillä, että se toimii.
Ohjelmistotekniikka
130(504)
Miksi tarvitaan erityinen
integrointitestaus 1/3
• Kootaan kaikkien luovuttamat, erikseen toimivat koodit ja
rakennetaan yhteinen buildi.
• Ajamalla yksikkötestit ja muutakin saadaan kuva
kokonaisuuden testauksesta ja eri komponenttien
kypsyydestä.
– Voidaan jakaa se tieto intranetissä, webissä tai vaikka tiimin
seinällä "radiaattorissa".
• Kehittäjien pitää saada keskittyä omaan työnsä kohteeseen ja
suorittaa sille nopeita testejä.
• Kokonaisuuden testaamiseen voidaan antaa erityinen
panostus ja rakentaa luovasti uusia testejä.
Ohjelmistotekniikka
131(504)
• Voidaan ajaa monenlaisia testejä
–
–
–
–
Yksikkötestit uudelleen integrointiympäristössä
Voidaan korvata tynkiä ja kirjastoja toisilla.
Voidaan ajaa pidempiä testejä, myös käyttöliittymän läpi.
Ajetaan sellaisia prosessin vaatimia testejä, jotka ovat pakollisia
(savutestit ennen järjestelmätestejä, turvallisuusstandardien
edellyttämät testit)
– Testit, joilta vaaditaan, että ne tekee joku muu kuin kehittäjä.
• Voidaan tehdä muutakin
– Voidaan tehdä aikaa vieviä koodin analyysejä (staattinen
analyysi, arkkitehtuurin tarkastus, kiellettyjen APIen käytön
tarkastus, mutkikkuusmittaukset).
Ohjelmistotekniikka
132(504)
• Integrointitestauksella mitataan projektin edistymistä ja
tuotteen kypsymistä
• Testien tuloksena jokin buildi voidaan todeta niin stabiiliksi,
että sitä voidaan käyttää laajemmin
– Muissa projekteissa, asiakkaan testeissä jne…
Ohjelmistotekniikka
133(504)
Integroinnin rytmi
• Historiallisesti integrointia on tehty vaikkapa kerran viikossa.
Kehittäjät lähettävät tuotoksensa ja joku yrittää laittaa ne
yhteen.
– Jo ennen internet-aikaa… 1990-luvulla.
• Päivittäiseen rytmiin ("nightly build") päästiin 2000-luvun
alussa.
• 2000-luvun alussa ajateltiin, että miksei integrointia voisi
tehdä koko ajan.
–
–
–
–
Pienissä palasissa se on helpointa.
Ongelmat saadaan heti kiinni.
Testejä voidaan pyörittää jatkuvasti.
Alkoi jatkuvan integroinnin aika – CI.
Ohjelmistotekniikka
134(504)
Jatkuva integrointi (CI) 1/2
• Kun kehittäjä saa aikaan pienen palan toimivaa koodia
(yksikkötestattuna), se integroidaan "heti" kokonaisuuteen.
• Se tapahtuu palvelimella, joka huomaa versionhallintaan tulleen
uutta koodia, lataa sen, tekee buildin ja ajaa integrointitestit – ja
kaikki muut testit, mitä halutaan.
• Jokaisella kehittäjällä on versionhallinnan kautta käytössä kaikki
koodit, joten "esi-integrointia" tehdään paljon ja siksi integrointi
palvelimella on helppoa.
• Hyödyt laadulle:
– Pienissä paloissa tehdyt muutokset ovat selkeitä: jos jokin ei toimi, syy
on helppo korjata.
– Ohjelma on koko ajan suurimmalta osin stabiili ja kunnossa.
– Kehittäjät saavat nopeaa palautetta integrointitestauksesta.
– Eri osapuolten tekemiset eivät mene epäsynkroniin.
Ohjelmistotekniikka
135(504)
Jatkuva integrointi (CI) 2/2
• Hyöty testaukselle:
– Jatkuva testaus. Nopea palaute.
– Voidaan ajaa kaikenlaisia automatisoituja testejä.
– Voidaan seurata koko ajan kokonaisuuden kehittymistä – mitkä
komponentit toimivat, missä on vikoja, millainen on testauksen
kattavuus.
• Huomattavaa:
– Koska testauksen on oltava nopeita, pitää olla erilaisia
testisettejä.
– Hitaammat testit ajetaan kenties vain kerran päivässä tai sitäkin
harvemmin.
– Tietenkin voi käyttää useaa palvelinta testien ajamiseen.
– CI on magiaa: integrointi sinänsä ei kerro laadusta mitään. Myös
testien on oltava hyviä. Yksikkötestien toistaminen palvelimella
ei riitä.
Ohjelmistotekniikka
136(504)
Muita integroinnin ja
integrointitestauksen mekanismeja
•
Seuraavassa käsitellään lyhyesti erilaisia integroinnin
mekanismeja.
•
Niissä on arkisesti ottaen kyse siitä, miten ohjelmistoa
kootaan yhteen ja se tapahtuu yleensä "terveen järjen"
perusteella ja erilaisia periaatteita soveltaen.
•
Ketterässä kehittämisessä on aina käytettävä sellaista
integrointityyliä, jonka avulla saadaan nopeasti aikaan toimiva
ja kokeilukelpoinen ohjelma.
•
Vaikka ohjelman kehityksen aikana suositaan jatkuvaa
integrointia, tulee silti tilanteita, joissa, pitää yhdistää joukko
suurempia kokonaisuuksia.
Ohjelmistotekniikka
137(504)
Kertarysäysintegrointi
• Big bang: ”Alussa ei ollut mitään ja sitten kaikki räjähti”
• Idea: Ensin yksikkötestataan kaikki yksiköt erikseen ja sitten
integroidaan ne kerralla toimivaksi kokonaisuudeksi
– Yleistä pienissä ohjelmissa tai kun kootaan ohjelmaa olemassa
olevista komponenteista
– Ongelma 1: Yksikkötestausvaiheessa on kaikille yksiköille
kirjoitettava tarvittavat ajurit ja tyngät
– Ongelma 2: Kun vika ilmenee integroitua järjestelmää
testattaessa, on sen aiheuttaneen virheen etsiminen hankalaa
isosta joukosta yksiköitä
– Ongelma 3: Virheen korjaamisen jälkeen täytyy monia testejä
ajaa uudelleen, sen varmistamiseksi, ettei korjaus ole rikkonut
mitään muuta
Ohjelmistotekniikka
138(504)
Jäsentävä inkrementaalinen integrointi
• Top-down
• Myös strategia ohjelman kehittämiseen
• Tämä on hyvin tyypillinen tapa: Ajatellaan ohjelmistoa, jonka
rakenteen määrittää jokin "framework". Ensin tehdään
perusrunko ("kontrolliyksikkö") ja aletaan sitten kokoamaan
siihen palasia.
– Alkuun puuttuu paljon. Esimerkiksi tulostustoiminto tai haku
korvataan pitkään tyhjällä rutiinilla.
• Edut testaukselle
–
–
–
–
Käytettävissä on koko ajan ajettava ohjelma
Saadaan käyttäjän näkökulma
Voidaan simuloida käyttäjätarinoita ja käyttötapauksia
Kyetään arvioimaan kokonaisuutta – tehdäänkö oikeaa ohjelmaa
Ohjelmistotekniikka
139(504)
Kokoava inkrementaalinen integrointi 1/2
• Bottom-up
• Aloitetaan yksikkötestaus alimman tason yksiköistä, joille
kirjoitetaan testauksessa tarvittavat ajurit
• Seuraavassa vaiheessa korvataan nämä ajurit vastaavilla
yksiköillä, kun ne valmistuvat
• Testataan seuraavaksi nämä yksiköt
– Kirjoitetaan jälleen tarvittavat ajurit
– Alimman tason yksiköt poistavat tynkien tarpeen
• Korostaa matalan tason toiminnallisuutta
• Järjestelmän prototyyppi ei ole käytettävissä ennen kuin vasta
aivan integrointitestauksen lopussa
Ohjelmistotekniikka
140(504)
Kokoava inkrementaalinen integrointi 2/2
• Suuri etu: tynkiä ei tarvita
– Tynkien tekeminen on yleensä työläämpää kuin ajurien
• Lisää etuja:
– Kokoavassa integroinnissa voidaan klustereiden testausta jakaa
helposti useammalle tiimille
– Matalan tason yksiköiden suunnittelussa ja toteutuksessa tehdyt
virheet voidaan löytää nopeasti
• Esim. niissä piilevät suorituskykyongelmat voidaan havaita
tehokkaasti
• Iso haitta: Kokonaisuus ei toimi pitkään aikaan…
Ohjelmistotekniikka
141(504)
Integrointijärjestyksestä
• Testausjärjestys voi riippua siitä, missä järjestyksessä
yksiköitä integroidaan toisiinsa
– Mitä kyetään testaamaan!
• Kannattaa integroida ensin ne yksiköt, joihin liittyy suurin riski
tai jotka muuten vaan sattuvat olemaan kriittisellä polulla
– Mitä suurempi riski, sen aikaisemmassa vaiheessa pitää testata
– Kriittinen polku saattaa liittyä esim. ominaisuuteen, joka halutaan
saada toimimaan mahdollisimman nopeasti tai tekniikkaan, jonka
käyttökelpoisuus halutaan selvittää mahdollisimman nopeasti
• Uusien asioiden testaus kannattaa tehdä (myös) erillisenä
proof of concept-testauksena – kokeillaan projektin
koodikannasta erillään, toimiiko vaikka uusi
tietokantaparadigma.
Ohjelmistotekniikka
142(504)
Integrointitestauksen nyrkkisääntöjä
• Tarvittavan apukoodin määrä tulisi minimoida
• Kerralla kannattaa integroida vain pieni määrä kerrallaan
– Tiedetään, mistä ongelmat johtuvat…
– Siksi jatkuva integrointi on hieno asia
• Integrointi on eri asia kuin integrointitestaus
– On huolehdittava testien laadusta
• Testauksen oltava nopeaa, että palaute kehittäjille on nopeaa
• Voi olla erilaisia testisettejä – pieniä ja nopeita (heti palaute
kehittäjille), isoja ja hitaita pyörimässä vaikka yön yli
Ohjelmistotekniikka
143(504)
4.10 Jatkuva toimitus (Continuous Delivery)
1/3
• Tapa toimittaa ohjelmisto pientenkin muutosten jälkeen
kokonaisvaltaisella työnkululla asiakkaan käyttöympäristöön:
– Tietojärjestelmän tuotantoympäristöön, käyttäjän tietokoneeseen
tai mobiililaitteeseen.
• Vaikka puhutaan "jatkuvasta", rytmi voidaan valita asiakkaan
tarpeiden mukaan ja sen mukaan, mitä päivitetään:
bugikorjauksia vai käyttöön vaikuttavaa uutta
toiminnallisuutta.
• Tärkeää on valmius toimittaa milloin tahansa.
• Suosii Kanban-tyyppistä kehittämisprosessia.
• Erinomainen kirja: Humble & Farley: Continuous Delivery.
• Käsittelemme tässä vain muutamia asioita testauksen
näkökulmasta.
Ohjelmistotekniikka
144(504)
Jatkuva toimitus (Continuous Delivery) 2/3
• Onnistuminen perustuu hyvin toimivaan logistiikkaan (ml.
jatkuvaan integrointiin), konfiguraationhallintaan ja hyvään
testaukseen.
• Logistiikan ja eri alustojen testiympäristöjen oltava hyvin
luotettavia, ettei tule yllätyksiä.
• Yleensä korostetaan testiautomaatiota, mutta
manuaalisellakin testauksella onnistuu.
• Manuaalinen testaus on tärkeää joka tapauksessa.
– Uuden toiminnallisuuden testaus ja (tarvittaessa) käyttäjien
hyväksymistestaus sekä sopivan laaja usein tutkiva
regressiotestaus.
– "Sokkona" ei pidä koskaan toimittaa mitään käyttäjille.
Ohjelmistotekniikka
145(504)
Jatkuva toimitus (Continuous Delivery) 3/3
• Voidaan käyttää taktikoiden testauksen vähentämiseen,
koska huonot muutokset voidaan nopeasti myös vetää
takaisin.
• Auttaa tekemään A/B-testausta, koska mekanismeilla voidaan
nopeasti vaihtaa eri ympäristöissä käytössä olevia
konfiguraatioita.
– A/B-testauksessa tarjotaan eri käyttäjille erilainen versio
systeemistä ja vertaillaan sitten niiden käyttöä. Käytössä mm.
Googlella ja kaikilla isoilla some-palveluilla.
• Laajan käyttäjäkunnan palveluissa voidaan uutta
toiminnallisuutta ensin "markkinatestata" joillain palvelimilla ja
sitten levittää muuallekin.
Ohjelmistotekniikka
146(504)
4.11 Järjestelmätestaus
•
•
•
•
•
•
Testataan kokonaisjärjestelmän toimintaa
Yleensä testaajien työtä
Voi olla erillisen testaustiimin tehtävä
Löydettyjen virheiden korjaus kallista
Ajallisesti yleensä pitkäkestoisin kaikista testausvaiheista
Kaikkien testitapausten suorittaminen voi kuluttaa hyvinkin
paljon resursseja
– Luontevaa aloittaa jälleen savutestillä
• Jos järjestelmätestaus aloitetaan vasta projektin lopussa,
ajaudutaan helposti ongelmiin
– Varsinkin ketterässä prosessissa pyritään testaamaan koko ajan
myös järjestelmätasolla
Ohjelmistotekniikka
147(504)
Monipuolista testausta järjestelmän
tasolla 1/2
• Järjestelmätestausvaiheessa käytettävissä on koko
järjestelmä, mikä tekee mielekkääksi mm. seuraavien
asioiden testaamisen:
–
–
–
–
–
–
–
–
–
Asiakkaan vaatimukset
Käytettävyys
Tietoturva
Suorituskyky
Kuormituksen kesto
Suunnittelun ominaispiirteet
Järjestelmän tilat
Kapasiteetti
Rinnakkaisuus
Ohjelmistotekniikka
148(504)
Monipuolista testausta järjestelmän
tasolla 2/2
– Ohjelmiston ja laitteiston konfiguraatiot
– Rajapinnat ja toiminta muiden järjestelmien kanssa (vrt.
järjestelmäintegrointitestaus) – end to end -käyttötapaukset
– Asennus
– Lokalisointi
– Toipuminen virhetilanteista
– Luotettavuus
– Resurssien käyttö
– Skaalautuvuus
• Järjestelmätestaus vaatii huomattavasti enemmän luovuutta
kuin alemman tason testaus
– Yleispäteviä toimintamalleja mahdotonta määritellä tarkasti
Ohjelmistotekniikka
149(504)
Systemaattisen järjestelmätestauksen
vaiheet
• Järjestelmätestauksen vaiheet (mukailtu Kit: Software Testing in the
Real World, 1995):
–
–
–
–
Huom! Tässä koskien lähinnä toiminnallista testausta
Vaatimusten analysointi ja paloittelu hallittaviin osiin
Jokaiselle osalle yksityiskohtaisten vaatimusten listaus
Jokaista merkityksellistä vaatimusta vastaavien syötteiden ja tulosten
määrittely
– Vaatimuskattavuusmatriisin määrittely
• Mäppää vaatimukset ja testit – onko kaikilla vastaavuus
• Nykyään ohjelmat tekevät automaattisesti
– Testitapausten suorittaminen ja vaatimuskattavuuden mittaaminen
– Uusien testitapausten määrittely ja suorittaminen tavoitellun
vaatimuskattavuuden saavuttamiseksi
Ohjelmistotekniikka
150(504)
Ei vielä ajettu
Vaatimuskattavuus
• Vaatimuskattavuusmatriisi
– Taulukko, jossa kerrotaan
yhteydet (eri tyyppisten)
testitapausten ja vaatimusten
välillä
– Mikäli mahdollista, yhdellä
(laillisella) testitapauksella
kannattaa testata montaa
vaatimusta
– Matriisista näkee helposti sen,
mitä ei (vielä) testata
Vaatimus
V1
V2
V3
TT2
OK
OK
TT3
FAIL
Testitapaus
TT1
TT4
Ohjelmistotekniikka
V4
TBD
OK
OK
151(504)
Nopea vikaraportointi tärkeää
• Järjestelmätestausvaiheessa pitäisi huolehtia siitä, että
kehittäjät saavat vikaraportit nopeasti
– Nopeus ei ole niin itsestään selvää kuin alemmissa vaiheissa
• Mahdolliset organisaatiorajat hidastavat
– Projektin johdon kautta kierrättäminen ei välttämättä ole hyvä
idea
– Nopea raportointi voi estää virheen leviämisen muihin paikkoihin
– Ketterässä kehityksessä testaajat usein tiimeissä – välitön
palaute
Ohjelmistotekniikka
152(504)
Muutostenhallinnasta laajoilla
järjestelmillä 1/2
• Koska järjestelmätestien suorittajat eivät yleensä itse korjaa
löydettyjä virheitä, on erittäin tärkeää huolehtia muutosten
hallinnasta
– Mikäli jokainen virhe korjataan heti siten, että testattava versio
vaihtuu jatkuvasti, ei järjestelmätestaus pääse etenemään
– Toisaalta joidenkin virheiden pikainen korjaaminen voi olla
ensisijaista toisten virheiden nopealle löytymiselle
• Yleensä virheiden korjaamisen priorisoinnista ja aikatauluista
päättää erillinen taho (Change/Configuration Control Board)
– Tähän voi kuulua testaajien ja kehittäjien lisäksi myös
tuotteenhallintapäällikkö, projektipäällikkö, laatupäällikkö,
tietokantojen ylläpitäjä, asiakkaita/loppukäyttäjiä,
asiakastukihenkilöitä ja markkinointi-ihmisiä
Ohjelmistotekniikka
153(504)
Muutostenhallinnasta laajoilla
järjestelmillä 2/2
• Tämä kaikki koskee laajoja järjestelmiä, joiden konfiguraation
on tärkeää pysyä samana koko testikierroksen ajan
• Tärkeä tapaus tässä on hyväksymistestaus, jossa
testauskierroksen avulla päätetään jonkun version
ottamisesta käyttöön tai sen siirtämisestä testausprosessissa
seuraavaan vaiheeseen
Ohjelmistotekniikka
154(504)
Top 7 pointit järjestelmätestaukseen
• Selvitä, miten ohjelmistoa käytetään ja mikä käytössä on tärkeintä
– Kuka käyttää, mihin tarkoitukseen, mikä on sen toiminnan tavoite
• Tunnista kaikki olennaiset ominaisuudet
– Toiminnallisuus, käytettävyys, tietoturva
– Ellet osaa testata niitä itse, teetä testaus toisella
• Tee selväksi toimintojen ja ominaisuuksien tärkeysjärjestys
– Käytön yleisyys, toimintoihin liittyvä riski
• Aloita testaus tärkeimmistä asioista
• Käytä luovasti erilaisia testaustyylejä
– Suunnitelmalähtöisyys ja ketteryys tukevat toisiaan
– Automaatiolla on oma paikkansa
• Tee sellaiset dokumentit, jotka auttavat toisia
• Virheraporttien tarkoitus on "myydä" virhe kehittäjille ja saada se
korjatuksi
Ohjelmistotekniikka
155(504)
4.12 Järjestelmäintegrointitestaus 1/2
• Isojen tietojärjestelmäprojektien
yhteydessä suureksi kysymykseksi
nousee yleensä yhteensopivuus
muiden järjestelmien kanssa
• Koska kokonaisjärjestelmän osat
tulevat usein eri toimittajilta, on
syytä kiinnittää erityistä huomiota
siihen, että osajärjestelmät
”juttelevat” toistensa kanssa
saumattomasti
• Siksi on järkevää panostaa
integrointiin ja tehdä siihen
keskittyvää testausta
Ohjelmistotekniikka
156(504)
4.13 Järjestelmäintegrointitestaus 2/2
• Järjestelmäintegrointitestaus on luonteeltaan teknistä,
toiminnallisuus ja suorituskyky jne. varmistetaan vasta kun
homma toimii ”pellin alla”
• Kannattaa aloittaa mahdollisimman aikaisin, myöhäinen
aloitus johtaa ongelmiin projektin lopussa
– Ajureita ja tynkiä joudutaan käyttämään korvattaessa
keskeneräisiä ja puuttuvia osajärjestelmiä
Ohjelmistotekniikka
157(504)
Yleiskuvaus
•
Tarkoitus
– Varmistaa, että kokonaisjärjestelmä toimii hyvin ja kaikki
osajärjestelmät toimivat yhdessä.
•
Perustuu laadittuun testaussuunnitelmaan.
•
Testiympäristö vastaa järjestelmän tuotantoympäristöä.
•
Testiympäristö usein kokoaa yhteen eri osapuolten tuottamia
järjestelmiä.
•
Tietojärjestelmäprojektien kriittisimpiä testauksia.
– Moni suuri projekti on ongelmissa juuri siksi, että eri osapuolten
tekemät järjestelmät eivät toimi yhdessä.
•
Edellyttää kaikkien osapuolten yhteistyötä.
•
Tekijänä erillinen tiimi.
Ohjelmistotekniikka
158(504)
Lähestymistapa
•
Järjestelmien välisten rajapintojen testaus.
•
Tärkeimpien toimintojen toimivuuden varmistaminen.
– Liiketoimintaprosessit koko järjestelmän läpi.
•
Testityypit:
– Toiminnallisuustestaus.
– Suorituskykytestaus.
•
Mukana myös tarkastusta.
– Tietokannat, siirtotiedostot yms. kannattaa testauksen lisäksi
tarkastaa manuaalisesti.
•
Voi olla osa asiakkaan hyväksymistestausta.
•
Testejä voidaan automatisoida, jos rajapinnat ovat stabiilit.
Ohjelmistotekniikka
159(504)
Tekijät
•
Erillinen integrointitiimi.
•
Voi olla taho, joka ei toteuta yhtään osajärjestelmää.
•
Voi olla taho, joka tekee asiakkaan puolesta.
hyväksymistestauksen.
•
Tukena muutosraati ja virheraati, joka käsittelee integroinnin
kysymyksiä ja ongelmia.
– Minkä osapuolen syy on se, että jokin ei toimi… joskus kaikki
tekevät kaiken oikein, mutta kokonaisuus ei toimi!
Ohjelmistotekniikka
160(504)
Suunnittelu
•
•
•
•
Integrointisuunnitelma projektin alussa
– Linkittyy osajärjestelmien julkaisusuunnitelmiin
– Järjestelmien testattavuuden katselmointi
– Ajoitus oleellista – millä rytmillä tuotetaan uusia versioita
järjestelmistä
– Voi olla myös automatisoitu jatkuvan integroinnin näkökulma
Sovitaan kussakin vaiheessa testattavat päästä päähän skenaariot
– Esimerkiksi tilauksen käsittely alusta loppuun – testataan, miten
se kulkee eri järjestelmien läpi
Vastuiden sopiminen
Resurssien varaus tärkeää
– Ympäristöt
– Testausresurssit
Ohjelmistotekniikka
161(504)
Toteutus
•
Ympäristön pystytys
•
Testidatan / tietokantojen hankinta
•
Järjestelmän konfigurointi eri osajärjestelmille
•
Stubien / simulaattoreiden / mock-olioiden rakentaminen puuttuville
järjestelmille, jotta testaus voidaan tehdä ennen kuin kaikille asioille
on toteutusta
•
Testauksen aloitus heti, kun on integroitavaa
•
Testien automatisointi regressiotestausta varten
•
Testauksen jatkaminen koko projektin ajan
Ohjelmistotekniikka
162(504)
Kokonaisuuden hallinta
•
Projektissa on tärkeää olla integrointinäkökulma
•
Kun löytyy virheitä, on löydettävä niistä vastaava taho
– Kukin järjestelmä voi toimia itsenäisesti "oikein"
– Voi olla vaikeaa…
•
Tarvitaan mielellään virheraati, joka tulkitsee tilannetta
– Mukana eri osapuolten edustajat
•
Testiympäristö tarvitsee ylläpitäjän
•
Järjestelmäintegroinnin tekijä
– Voi olla taho, joka ei toteuta integroitavia järjestelmiä
Ohjelmistotekniikka
163(504)
Mittaus
•
Keskeinen tavoite seurata integroinnin etenemistä
– Liiketoimintaskenaarioiden testauksen kattavuus-%
– Läpäisseet – eli mikä kaikki toimii
•
Virheiden määrä
•
Virheiden määrän trendi
•
Virheet eri järjestelmäpareissa
– Mitkä eivät toimi yhteen
Ohjelmistotekniikka
164(504)
Yleisiä löydettäviä ongelmia 1/2
•
Rajapinnat toteutettu virheellisesti
– Ohjelmistorajapinnat
– Parametrien järjestys väärä
•
Protokollien toteutus vajaa
•
Asynkronisissa prosesseissa tapahtumien järjestys väärä
•
Erilaiset tietotyypit
– Numeroiden esitys
– Tekstidatan merkistöt
•
Tietotyypit virheelliset toteutuksessa
Ohjelmistotekniikka
165(504)
Yleisiä löydettäviä ongelmia 2/2
•
Dokumentaation virheet
•
Dokumentaation puuttuessa tehtävät oletukset ovat
virheelliset
•
Aikakatkaisut
– Yksi järjestelmä ei odota toisen tehtävien valmistumista
Ohjelmistotekniikka
166(504)
Järjestelmäintegrointitestauksen
menestystekijöitä 1/2
•
Kaikilla osapuolilla on yhteinen tavoite
•
Stabiili, realistinen testiympäristö
– Ympäristön hallittavuus ja konfiguroitavuus – porttien avaus
esimerkiksi ei saa kestää kuukautta
•
Osaprojektit tähtäävät integrointiin alusta lähtien
•
Avoimuus rajapintojen toteutuksesta (tämäkään ei ole itsestään
selvää)
•
Avointen standardien käyttö
•
Avoimen lähdekoodin ohjelmistot, jolloin eri osapuolet voivat
paremmin tutustua muiden käyttämiin ratkaisuihin
Ohjelmistotekniikka
167(504)
Järjestelmäintegrointitestauksen
menestystekijöitä 2/2
•
Integrointia mitataan ja se mittaa projektin etenemistä
•
Panostus viestintään
•
Hyvä muutoksenhallinta
•
Integrointi alkaa varhaisessa vaiheessa – se tarvitsee
harjoittelua; ei onnistu kerralla
Ohjelmistotekniikka
168(504)
Järjestelmäintegroinnin sudenkuoppia
•
Jätetään projektin loppuun
– Ei onnistu kerralla
•
Integrointiin ei varata resursseja
•
Muille osapuolille ei toimiteta rajapintojen dokumentaatiota
•
Ympäristöt eivät ole kunnossa
– Konfigurointi
– Porttien avaus
– Oikeudet
Ohjelmistotekniikka
169(504)
4.14 Testaus ketterässä kehittämisessä
Ketterässä kehittämisessä
toteutetaan vastaavia
testaustasoja kuin Vmallissa, mutta hieman
erilaisella rytmillä ja tavalla.
Miten se tapahtuu
pyrähdyspohjaisessa
prosessissa?
Ohjelmistotekniikka
170(504)
Pyrähdysten rytmi
• Ketterä kehitysprosessi perustuu pyrähdyksiin (sprint)
– Tuotetaan joukko uutta toiminnallisuutta
– Toiminnot pyritään testaamaan pyrähdyksen aikana
toimituskelpoiseksi
– Tehdään vähän suunnitelmia
– Testaus kohdistuu aina ensimmäiseksi yhteen toiminnallisuuteen
järjestelmätasollakin
– Testaajat ovat yleensä tiimissä mukana ja ottavat uusia
toiminnallisuuksia testaukseen sitä mukaa, kun koodaajat saavat
niitä testattavaksi
• Kun ne on yksikkötestattu ja integroitu
Ohjelmistotekniikka
171(504)
Periaatteellinen ketterä testausmalli
Pre-game
Yksikkö- ja
integrointitestaus
Ominaisuuksien
testaus
(järjestelmätaso)
Kokonaisuuden
järjestelmätestaus
Ohjelmistotekniikka
Pyrähdys 2…N
Pyrähdys 1
Post-game
Uudet
ominaisuudet
Tiimissä
Tiimissä tai hajautettuna; tilanteista riippuen
172(504)
Yhden uuden toiminnon testaus 1/2
• Pyrähdyksen alussa toteutettavat toiminnot listataan
pyrähdyksen työlistaan (backlog)
• Testaustehtäville tehdään omia tehtäviä – joko toimintoihin
liitettynä tai erikseen
• Niiden testausta voidaan alkaa valmistella, vaikka sen
pohjana ei olisi kuin kevyt käyttäjätarina – kommunikaatio
tiimissä on avain tässä
• Kun toteutus hahmottuu, testauksen toteutus jäsentyy
• Testaus on ainakin aluksi tutkivaa, toteutukseen perustuvaa,
mutta systemaattisia tekniikoita (ketterällä suunnittelulla)
kannattaa käyttää
Ohjelmistotekniikka
173(504)
Yhden uuden toiminnon testaus 2/2
• Yksinkertainen testaus pyritään usein automatisoimaan,
jolloin se voidaan jatkossa toistaa helposti
• Asiakkaan edustaja voi osallistua karkeaan uuden toiminnon
hyväksymistestaukseen
• Toiminto on "done" vasta, kun se on läpäissyt testauksen!
Ohjelmistotekniikka
174(504)
Yhden uuden toiminnon testaus
tarkemmin
Sprintin
backlog
Uusi
ohjelman
versio
Ominaisuus 1
Ominaisuus
2…N
Aikataulu
(järjestys)
Testauksen
suunnittelu
Ohjelmistotekniikka
Kehittäjä
suunnittelee
ja toteuttaa
Yksikkö- ja
integrointitestaus
Testaus
Virheiden
korjaus
Verifiointi
175(504)
Ketterän testauksen nelikenttä 1/2
• Kaiken testauksen on hyvä olla tavoitteellista.
• Ketterässä kehittämisessä tehtävän testauksen erilaisia
tyyppejä ja niiden tavoitteita on jäsentänyt Brian Marick ja
perinpohjaisesti dokumentoineet Crispin & Gregory kirjassa
Agile Testing [Crispin&Cregory 09].
• Agile Testing Quadrants – ketterän testauksen nelikenttä
muistuttaa, että tietty testaus voi:
– Tukea ensisijaisesti kehittämistiimin työtä tai olla suuntautunut
tuotteen kritisoimiseen.
– Olla suuntautunut teknologiaan tai bisnekseen – tuotteen
tarkoitukseen.
• Kaavio on saavuttanut paljon suosiota. Sitä ei pidä uskoa
sellaisenaan, vaan kuhunkin tilanteeseen soveltaen.
Ohjelmistotekniikka
176(504)
Ketterän testauksen nelikenttä 2/2
Liiketoimintaan suuntautuva
Manuaalinen
Q1
Q2
Toiminnalliset testit
Tutkiva testaus
Esimerkit
Skenaariot
Tarinoiden testit
Käytettävyystestaus
Prototyypit
Käyttäjien
hyväksymistestaus
Simulaatiot
Q3
Yksikkötestit
Komponenttitestit
Alpha- / betatestaus
Q4
Suorituskyky- ja
kuormitustestaus
Kritisoi tuotetta
Tukee tiimiä
Automatisoitu
ja
manuaalinen
Tietoturvatestaus
Muu ei-toiminnallinen
testaus
Automatisoitu
Ohjelmistotekniikka
Teknologiaan suuntautuva
Työkalut
177(504)
Onko pyrähdyksissä riittävästi aikaa
testaukseen?
• Ideana on tehdä pyrähdyksissä juuri sellainen määrä uutta
toiminnallisuutta, että aikaa on sen hyvään testaukseen
• Hyvä yksikkö- ja integrointitestaus tukena
• Testaus aloitetaan aina heti, kun tulee uutta testattavaa –
toiminnolle, ei koko uudelle julkistukselle
• Jos on pitkäaikaisia testausvaiheita, niitä voidaan
käytännössä lomittaa seuraavalle sprintille
– Esimerkiksi aikaa vaativat luotettavuus- tai yhteentoimivuustestaukset
– Tuotteen markkinoille julkaisun edellyttämät validointitoimet (joita ei
tarvitse tehdä jokaisessa sprintissä)
Ohjelmistotekniikka
178(504)
4.15 Hyväksymistestaus
• Tässä tarkastellaan hyväksymistestausta lähinnä
tietojärjestelmän hankinnan yhteydessä
• Hyväksymistestauksen perusteella voidaan päätellä onko
tuote sopimusten mukainen ja voidaan ottaa käyttöön
– Perustuu siis asiakkaiden vaatimuksiin
• Testauksesta vastaa asiakas
• V-mallia noudatettaessa ensimmäinen vaihe testien
suunnittelussa, viimeinen vaihe testien suorituksessa
• Huom! Ketterässä kehittämisessä usein käytetty ATDD-tyyli ei
ole läheskään riittävä järjestelmien hyväksymistestaukseen
– Se on lähinnä toimintojen "savutesti" asiakkaan edustajan
kanssa
Ohjelmistotekniikka
179(504)
Kokonaisvaltaista
• Hyväksymistestauksessa testataan kokonaista valmista
tuotetta
– Kannattaa käyttää testaajina tuotteen loppukäyttäjiä
– Testiympäristön pitäisi olla mahdollisimman lähellä todellista
loppukäyttäjän ympäristöä
– Suurilla organisaatioilla voi olla useita testiympäristöjä:
toiminnallisuuden testaus, suorituskykytestaus,
järjestelmäintegraation testaus
Ohjelmistotekniikka
180(504)
Testattavat asiat
• Kaikki ominaisuudet: toiminnallisuus, käytettävyys,
suorituskyky, tietoturva
• Mitä on määritetty, mitä on sovittu
• Reklamaatiot
• Myös asiat, joita ei ole määritetty, mutta joita voidaan odottaa
tuotteessa alan käytäntöjen perusteella
Ohjelmistotekniikka
181(504)
Kiire löytää virheet takuuaikana
• On tärkeää löytää puutteet takuuaikana, jolloin toimittaja
korjaa ne samaan hintaan
• Muuten joudutaan teettämään kalliita korjauksia
• Ilman testausta otetaan käyttöön raakile, johon kukaan ei ole
tyytyväinen, jonka ongelmien kanssa pärjäämiseen menee
kaikki aika ja energia
• Siksi tärkeää tehdä testaus kunnolla
Ohjelmistotekniikka
182(504)
Eikö toimittaja tee testausta?
• Ei, he lupaavat enemmän kuin tekevät
• Ja heiltä puuttuu loppukäyttäjien käytännöllinen näkökulma
• Toimittajalla on syynsä suosia heikkoa hyväksymistestausta:
siinä löytyy paljon korjattavaa, laskutus viivästyy, ongelmia ei
riitä takuuajan jälkeiseen aikaan…
Ohjelmistotekniikka
183(504)
Testausympäristöt
• Kaikki erot testiympäristön ja loppukäyttäjän ympäristön välillä
ovat asioita, joita ei tule testattua
– Käytetäänkö todellisia tietokantoja yms. testattavaan
järjestelmään liittyviä muita järjestelmiä vai simuloidaanko niitä
jotenkin?
– Onko testidata generoitua vai todellista?
– Onko käyttäjän laitteistossa muita ohjelmia?
– Onko laitteiston konfiguraatio realistinen?
• Erilaisia loppukäyttäjän ympäristöjä voi olla vaikka kuinka
paljon
– Profiilien luonti vastaamaan yleisimpiä ympäristöjä voi kannattaa
Ohjelmistotekniikka
184(504)
Organisointi
• Tilaajan oma projekti
– Omat järjestelyt, oma näkökulma, oma vastuu
• Joku vastaa ja vetää testauksen
– Voi olla vuokrattu konsultti
• Kaikki organisaatioyksiköt mukana – liiketoiminta, ICT, hallinto
• Käyttäjiä saatava mukaan testaamaan
• Voidaan käyttää testauspalvelutaloa alihankkijana
– Koko projektissa tai vaikka suorituskykytestauksessa
• Kesto vaihtelee
– Pienillä järjestelmillä lyhyt testaus, että systeemi on käyttöön
sopiva
– Suurilla järjestelmillä voi olla kuukausien mittainen laaja projekti
Ohjelmistotekniikka
185(504)
Käyttäjien osallistuminen tärkeää
• Käyttäjät ymmärtävät
– Vaatimuksia
– Omaan liiketoimintaansa liittyviä riskejä
• Käyttäjät voivat
–
–
–
–
Toimittaa realistista testidataa
Toimittaa käyttötapauksia
Suunnitella testejä ja tehdä testausta
Tarkastaa ja katselmoida
• Testiraportteja
• Muita projektissa syntyneitä dokumentteja
• Mutta eivät osaa tehdä hyvää testausta ilman apua
Ohjelmistotekniikka
186(504)
4.16 Ketterä hyväksymistestaus: ATDD
• ATDD = Acceptance Test Driven Development
• TDD:ssä matalan tason testit ajavat koodausta eteenpäin
• ATDD:ssä korkean tason testit ajavat koko prosessia
eteenpäin
• Kuinka “Definition of done” määritellään asiakkaan tai
käyttäjän näkökulmasta?
• ATDD perustuu siihen, että määritellään suoritettavia korkean
tason testejä ennen kuin toteutusta on edes aloitettu
• Ideaalitapauksessa testit tekee asiakas tai loppukäyttäjä
• Kun testi läpäistään, on vastaava vaatimus ”Done”
• ATDD-työkalut tarjoavat helpon tavan määritellä testejä
muodossa, jota asiakas ja loppukäyttäjäkin ymmärtävät
Ohjelmistotekniikka
187(504)
ATDD-prosessi
• Asiakkaan kanssa sovitaan toiminnon testitapaukset.
• Testaaja tai kehittäjä suunnittelee ne ja niille tehdään yleensä
kevyt testiautomaatio.
• Testit lisätään backlogiin tai toimintojen Kanban-prosessin
vaiheeksi (läpäisy on yksi vaatimus, että toiminto on Done).
– Automatisoidut testit voidaan liittää jatkuvaan integrointiin ja siksi
ne alussa eivät mene läpi.
– Manuaalisia testejä ei toki tehdä ennen toteutusta…
• Toteutuksen ja virheiden korjauksen jälkeen testit menevät
vähitellen läpi.
• Voidaan todeta asioiden olevan tältä osin alustavasti
kunnossa…
Ohjelmistotekniikka
188(504)
ATDD:n piirteitä
• Edut
– Vähemmän monikäsitteisyyksiä vaatimuksissa, koska asiakas tai
loppukäyttäjä on hyväksynyt testit
– Kun testi menee läpi, voidaan siirtyä toteuttamaan seuraavaa
vaatimusta
• Testit määrittelevät projektin laajuuden: jos läpäisemättömiä
testejä ei ole, ei ole mitään mitä implementoida (kuten asiakas
tai loppukäyttäjä on asian hyväksynyt)
• Etenemisen läpinäkyvyys johdolle ja asiakkaalle
• Kannattaa kuitenkin muistaa, että ATDD-työkalut eivät
välttämättä tue kaikki sovelluskohteita
• …ja kaikki asiakkaan eivät ole valmiit toimimaan näin!
Ohjelmistotekniikka
189(504)
4.17 Alfa- ja Beta-testit
• Käyttäjät tekevät testit
• Alfa-testit käyttäjän toimesta toimittajan tiloissa
mahdollisimman realistisessa ympäristössä
– Kehitys- tai testausympäristö ei kelpaa
• Beta-testit käyttäjän toimesta käyttäjän tiloissa ja
ympäristössä
• Sekä alfa- että beta-testauksen tapauksessa täytyy muistaa,
että ad hoc -tyyppinen testaus (kokeileminen) ei korvaa
järjestelmällistä testausta käyttäen suunniteltua testistrategiaa
ja testitapauksia
– Keskeneräisen ohjelmiston jakelu valikoiduille käyttäjille ei siis
yksinään riitä
– Kokeilukin voi joissain tapauksissa olla paikallaan, mutta vasta
sitten kun järjestelmä on hyväksymistestattu järjestelmällisesti
Ohjelmistotekniikka
190(504)
4.18 Tarvitaanko kaikkia testaustasoja ja
vaiheita?
• Testauksen järjestelmällisellä jakamisella eri
abstraktiotasoihin ja vaiheisiin on selviä etuja
suunnittelemattomaan lähestymistapaan verrattuna
• Kuitenkin pienissä projekteissa kaikkien em. testausvaiheiden
läpikäyminen voi aiheuttaa ylimääräistä työtä
• Testauksen tasoja ja vaiheistamista suunniteltaessa
kannattaa ottaa huomioon ainakin
– Kehitettävän järjestelmän monimutkaisuus
– Projektin budjetti
– Testausorganisaatio
Ohjelmistotekniikka
191(504)
Järjen käyttö sallittua
• Tärkeintä ei ole vaiheiden määrän maksimointi vaan oikeiden
vaiheiden valinta kutakin projektia varten
• Vaiheet eivät saa hidastaa toimituksia tarpeettomasti tai
hidastaa vikojen löytämistä
• Huom! Samaa vaihetta voidaan kutsua eri nimillä
– Yksikkötestausta voi olla paitsi moduulitestaus myös
komponenttitestaus, kehittäjätestaus jne.
• Ei kannata antaa termien hämätä
Ohjelmistotekniikka
192(504)
Järjestelmätestejä voidaan ajaa integroinnin
yhteydessä
• Integrointitestauksen yhteydessä pohdittiin sen suhdetta
yksikkötestaukseen: oma vaihe vai osa yksikkötestausta
• Entä voitaisiinko järjestelmätestit yhdistää
integrointitestaukseen?
– Craig ja Jaskiel [Craig&Jaskiel 02] listaavat ominaisuuksia, jotka
ovat yhteisiä heidän asiakasorganisaatioillensa, joissa näiden
vaiheiden yhdistäminen on onnistunut:
• Hyvä tuotteenhallinta
• Suhteellisen paljon automatisoituja testejä
• Kanssakäyminen kehittäjien ja testaajien välillä toimii hyvin
– Automatisoidut järjestelmätestit voidaan ajaa
integrointitestauksen yhteydessä
Ohjelmistotekniikka
193(504)
Hyväksymistestaus järjestelmätestauksen
yhteydessä
• Entä hyväksymistestauksen yhdistäminen
järjestelmätestaukseen?
– Voi olla perusteltua tilanteissa, joissa loppukäyttäjät osallistuvat
järjestelmätestaukseen
– Testaus pitää tehdä tuotantoympäristöä tarkoin vastaavassa
ympäristössä – asiakkaan ympäristössä
Ohjelmistotekniikka
194(504)
4.19 Milloin siirtyä tasolta toiseen?
• Kaksi oleellista kysymystä testausta vaiheistettaessa
– Miten vaiheet liittyvät toisiinsa?
• Selkeät rajat auttavat siirtymisessä vaiheesta seuraavaan
– Mistä tiedetään koska siirrytään vaiheesta seuraavaan?
• Selkeät aloitus- ja lopetusehdot
• Eri testausvaiheiden ei tule olla päällekkäisiä, eikä niiden
välillä saa olla suuria aukkoja
– Ei kannata testata samaa asiaa moneen kertaan samasta
näkökulmasta. Ja kaikkia asioita pitää testata.
– Huom! Olennaisinta silloin, kun testaus tehdään käsin.
Ohjelmistotekniikka
195(504)
Päällekkäisyyden haittoja
• Aiemmin löydettyjä (ja korjattuja) virheitä voidaan löytää
uudestaan ja käsitellä turhaan uudestaan
• Yksikkö- ja integrointivaiheissa löydetyt virheet ovat paljon
halvempia korjata kuin myöhemmissä vaiheissa löydetyt
– Yritetään löytää matalalla tasolla niin paljon kuin mahdollista
• Kun testaus siirtyy kehittäjiltä erillisen testaustiimin harteille,
virheiden hinta kasvaa
– Yritetään löytää matalalla tasolla niin paljon kuin mahdollista
• Kuitenkin:
– Eri tasoilla ympäristö usein vaihtuu ja ohjelmistoon tulee uusia
kerroksia. Oltava siis varovainen, kun miettii, mitä ei testata.
Ohjelmistotekniikka
196(504)
Aloitus- ja lopetusehdot 1/2
• Hyvin määritellyt ja tunnollisesti noudatetut aloitus- ja lopetusehdot
eri testausvaiheille / tasoille luovat yhteiset pelisäännöt projektin
etenemiselle
• Jotkin aloitus- ja lopetusehdoista riippuvat projektista, toiset voivat
olla standardeja organisaation sisällä
• Edellisen vaiheen tekijät ovat kiinnostuneita seuraavasta koska
heidän panoksensa vaikuttaa paitsi oman vaiheen lopetusehdon
myös seuraavan vaiheen aloitusehdon saavuttamiseen
• Ehtojen merkitys riippuu kehityksen elinkaarimallista
– Lineaarinen vai iteroiva, ketterä?
• Laajemmin on kyse tietyn vaiheen hyväksynnästä, joka saavutetaan
iteroiden – vikoja korjaten, kunnes tilanne on riittävän hyvä
Ohjelmistotekniikka
197(504)
Aloitus- ja lopetusehdot 2/2
• Vaiheen aloitusehdon tulisi sisältää ainakin osa edellisen
vaiheen lopetusehdoista
– Lisäksi siihen voidaan sisällyttää ehtoja koskien myös esim.
testiympäristön luomista, testityökaluja ja jopa testaustyövoiman
hankkimista
• Mikäli on vaarana, että aletaan testata versiota, jota ei
käytännössä vielä voi testata, kannattaa aloitusehtoihin kirjata
myös vaatimus savutestin läpäisemisestä
Ohjelmistotekniikka
198(504)
Milloin saa softan siirtää prosessissa
eteenpäin? 1/4
• Yksikkötestauksesta integrointitestaukseen:
– Yksikkötestit menevät läpi
– Tai virheet eivät riko mitään nyt toimivaa asiaa (uusi koodi ei saa
huonontaa ohjelmaa ja aiheuttaa haittaa muille)
– Joskus: Riittävä testikattavuus, koodin katselmointivaatimus,
tarkistus työkaluilla, dokumentointi
• Integroinnista järjestelmätestaukseen:
–
–
–
–
Buildi toimii riittävän luotettavasti – voidaan testata
Testien läpäisyaste on riittävä
Riittävä testikattavuus
Olemassaolevat virheet on dokumentoitu (listaukset tiedossa
olevista vioista)
– Läpäistään järjestelmätestaajien määrittämät savutestit
Ohjelmistotekniikka
199(504)
eteenpäin? 2/4
• Järjestelmätestauksen lopetusehdot – milloin saa siirtää
asiakkaalle hyväksymistestaukseen tai tuotteen paketointiin
– Vaatimuskattavuus on riittävä – kaikkia osa-alueita on katettu
testeillä
– Läpäisseiden testien osuus on riittävä (huom. Tällaisten mittarien
vaarat…)
– Ei ole kriittisiä virheitä
– Muistivuoto-, kuormitus- ja tietoturvatestit menevät läpi valituilla
kriteereillä
– Testaustiimi kokee, että buildin voi kuitata kelvolliseksi!
Ohjelmistotekniikka
200(504)
eteenpäin? 3/4
• Esim. hyväksymistestauksen lopetusehdosta (mukailtu
[Craig&Jaskiel 02]) – milloin ohjelma kelpaa tuotantoon:
– Medium tai sen vakavampia virheitä ei saa olla
– Missään ominaisuudessa ei saa olla kahta virhettä enempää
eikä kaiken kaikkiaan yli 50 virhettä
– Vähintään yksi testitapaus jokaista vaatimusta kohden täytyy
läpäistä (vaarallinen vaatimustyyppi…)
– Testitapaukset TT23, TT25 ja TT38-52 täytyy läpäistä
– Kahdeksan kymmenestä kokeneesta pankkivirkailijasta pystyy
avaamaan tilin korkeintaan kymmenessä minuutissa käyttäen
on-line-ohjeita (käytettävyystestaus)
– Järjestelmä pystyy avaamaan 1000 tiliä tunnissa
(suorituskykytestaus)
Ohjelmistotekniikka
201(504)
eteenpäin? 4/4
– Näytöstä toiseen siirtyminen kestää keskimäärin korkeintaan
sekunnin kun järjestelmää käyttää 100 käyttäjää
(suorituskykytestaus)
– Käyttäjien täytyy hyväksyä allekirjoituksellaan testien tulokset
• Huom!
– Vaikka hyväksymistestaus on "läpäisty" järjestelmässä on vielä
virheitä, jotka toimittajan on korjattava
– Systeemi voidaan kuitenkin jo ottaa käyttöön – korjattu versio
toimitetaan myöhemmin
– Pelkkä numeroiden tuijottaminen ei riitä päätöksentekoon
järjestelmän ottamisesta tuotantoon – käyttäjien on
hyväksyttävä, että systeemi on siihen riittävän hyvä
Ohjelmistotekniikka
202(504)
5. Tutkiva testaus
Tutkiva testaus on tapa tehdä
testausta, jossa testaus etenee
testaajan havaintojen perusteella
asioihin, joissa arvellaan olevan
eniten ongelmia. Testaus ei
hyödynnä tarkkoja
ennakkosuunnitelmia, vaan on avoin
kaikelle, mitä tuotteeseen on
toteutettu.
Ohjelmistotekniikka
203(504)
5.1 Tutkiva testaus pähkinänkuoressa
• Tutkiva testaus = exploratory testing, ET
• Tämä osio on Matti Vuoren kalvosarjasta "Ketterä testaus ja testaus
ketterässä ohjelmistokehityksessä"
http://www.mattivuori.net/julkaisuluettelo/liitteet/kettera_testaus.pdf
• Yleensä järjestelmätestauksen tasolla
• Tutkitaan ohjelmistoa sitä käyttämällä ja tehdään siitä havaintoja,
yritetään oppia ja ymmärtää sitä
• Tunnistetaan riskialttiita ja testaamista edellyttäviä alueita
• Testataan ne saman tien, ilman formaaleja testitapauksia
• Tai suunnitellaan niille tarkemmat testit ja suoritetaan ne
• Tulkitaan tuloksia ja jatketaan iterointia
Ohjelmistotekniikka
204(504)
Varoitus
• Tutkivalle testaukselle ei ole standardeja ja asiantuntijoillakin
voi olla erilaisia lähestymistapoja siihen
– Paradigma on vielä kehittymässä
• Kun alkaa soveltaa tutkivaa testausta pitää analysoida
vaatimukset testaukselle ja tarkastella monia asioita:
– Koko testausprosessi – mitä muunlaista testausta tehdään, mikä
kaikki täydentää ET:tä
– Organisaatiokulttuuri, mukaan lukien termistö
– Dokumentointivaatimukset
– Testaajien osaaminen – tarvitaan taitavia testaajia
Ohjelmistotekniikka
205(504)
Tutkiva testaus: Miksi? 1/2
•
Testaus on hyvä perustaa siihen, mitä toteutus kertoo
– Ollaan täydellisen realisteja. Ei luoteta dokumentteihin, vaan siihen,
mitä on oikeasti saatu aikaan. Mitä toimintoja oikeasti on mukana?
– Määrittelyt ovat aina vajaita ja virheellisiä – ei jäädä puuttuvien
määrittelyjen ansaan
– (Tietenkin on tiedettävä, miten ohjelmiston pitäisi toimia)
•
•
Aikaa ei kulu testauksen suunnitteluun, vaan saadaan nopeammin tuloksia.
–
Nopea testauksen käynnistys
–
Nopea reagointi muutoksiin
–
Saadaan nopeasti palautetta kehittäjille
Tutkiva testaus sopii tilanteisiin, joissa vaatimukset muuttuvat jatkuvasti
–
Suunnitelmat olisivat muuten aina vanhentuneita
Ohjelmistotekniikka
206(504)
Tutkiva testaus: Miksi? 2/2
•
Kun ollaan avoimin silmin liikkeellä, löydetään paremmin virheitä kuin jos
käytetään vain valmiiksi mietittyjä testitapauksia
–
Liiallinen suunnittelu luo ennakko-odotuksia ja sulkee silmiä havainnoilta
•
Osataan tunnistaa sellaisia piirteitä ohjelmistosta, jotka eivät ole
määrittelyvaiheessa nousseet esille
•
Ohjelmistot ovat niin monimutkaisia, että testitapauspohjainen
lähestymistapa ei riitä
–
Kaikkia testitapauksia ei pysty määrittämään; ei ole tarpeeksi aikaa
•
Toimintojen tekninen riskitaso paljastuu vasta, kun toteutus alkaa, tutkimalla
ohjelmistoa
•
Sen avulla opitaan järjestelmästä
•
Se sopii käyttäjien näkökulmaan
•
Testaus on joka kerta erilaista, joten kyetään löytämään uusia virheitä
Ohjelmistotekniikka
207(504)
Tutkiva testaus: Ongelmia
• Testauksen laadun todentaminen on vaikeaa
• Tarvitsee taitoja ja ohjausta – muuten siitä on vähän hyötyä.
– Huonosti tehtynä voi olla hyvin huonoa…
• Testauksen formaali osoittaminen vaikeaa
– Puuttuu speksejä, raportteja
• Käytettävät tekniikat eivät kunnolla dokumentoituja
• Usein onkin hyvä, ettei rajoituta yhteen testaustyyliin –
tutkiva testaus on vain kokonaisuuden osa
Ohjelmistotekniikka
208(504)
5.2 Tutkiva testaus: Esimerkkejä
•
Tuotteen käyttäytymisen tutkiminen
– Miten juuri toteutettu uusi toiminnallisuus toimii?
•
Ketterä savutestaus
•
Kattava ominaisuuksien testaus
–
Järjestelmätestauksessa, hyväksymistestauksessa
•
Ketterä regressiotestaus (täydentämässä systemaattisia
menettelyjä)
•
Oireiden taustalla olevien asioiden analysointi tarkemmalla
tutkimisella
– Esimerkiksi kuormitustestauksen tulosten syiden selvittäminen
tarkemmilla testeillä ja mittaroinnilla
•
Käytettävyystestauksen ensimmäinen vaihe, jossa pyritään ennen
kaikkea ymmärtämään uutta ohjelmistokonseptia
Ohjelmistotekniikka
209(504)
Tutkiva testaus: Sovellusalueita
•
Ketterässä kehittämisessä
•
Systemaattisessa kehittämisessä
•
Asiakkaan hyväksymistestauksessa
– Eräät suomalaiset valtion virastot ovat siirtyneet pääasiassa
ketterään testaukseen
Ohjelmistotekniikka
210(504)
5.3 Tutkiva testaus perustuu
strategioihin ja tietoon
•
Ohjelmiston ymmärtämiseen
•
Havaintoihin – tunnistetaan ongelmien oireita ja alueita
ohjelmistossa, joissa voi piillä virheitä?
•
Strategioihin – millaisella mentaliteetilla virheitä etsitään?
– Esim. ohjelmiston ”rikkominen”
•
Kokemustietoon – millaisia virheitä on aiemmin ollut ja millä
alueilla?
•
Testaus on intellektuaalista, haastavaa työtä
•
Testaaja on etsivä! Ei testitapauksia syöttävä robotti
Ohjelmistotekniikka
211(504)
Ohjelmiston ymmärtäminen kokeilemalla ja
havainnoimalla
•
Silmät avoinna kaikelle
•
Käyttöskenaarioiden kulku viitekehyksenä
•
Ohjelmiston erilaisten elementtien tunnistaminen
•
Tapahtumien tunnistaminen
– Miten ohjelma käyttäytyy, miten se reagoi
•
Tilojen tunnistaminen
•
Muutokset
– Tilasiirtymät
– Muutokset datassa
Ohjelmistotekniikka
212(504)
Havaintojen tekeminen
käyttäytymisestä
•
Mikä on tuttua
•
Mikä on uutta, vierasta?
– Millä logiikalla se toimii?
•
Ohjelman reagointi
– Käyttönopeus
– Erilaiset sekvenssit
– Erilainen data
– Ensimmäinen kerta ja sen jälkeen
•
Perinteiset ongelmat vastaavissa sovelluksissa ja tilanteissa
Ohjelmistotekniikka
213(504)
Mentaliteetti testauksessa
•
Kaikki on sallittua
•
Tiedetään, että virheitä on; ne on vain löydettävä
•
Pyritään "rikkomaan" ohjelmisto
– Ollaan kovakouraisia
– Bittejä saadaan aina lisää – antaa ohjelman kaatua
•
Hyödynnetään kokemusta
•
Hyödynnetään omaa ”vainua”
Ohjelmistotekniikka
214(504)
5.4 Session lähtökohdat 1/2
•
Tavoite
– Oppiminen vai ohjelmiston rikkominen vai jokin muu?
•
Ohjelmiston ymmärtäminen
– Ohjelmiston tarkoitus ja käyttö
– Uusien toimintojen tarkoitus ja käyttö
– Mitkä asiat tässä tilanteessa tuottavat suurimman arvon
asiakkaalle? Miten ne toimivat?
– Siis: Mihin asioihin liittyy suurin riski siitä, että asiat eivät onnistu
tai toimivat väärin?
Ohjelmistotekniikka
215(504)
Session lähtökohdat 2/2
• Ohjelmiston ja käyttäjän yhteistyön ymmärtäminen
– Millaisia käyttöskenaarioita on ja voi olla?
– Mitä tiedetään tyypillisestä käytöstä?
– Millaisia kaikkia poikkeuksia voi kuvitella.
– Entä tahallinen väärinkäyttö?
Ohjelmistotekniikka
216(504)
Mielentila
• Tutkiva testaus on aivotyötä ja edellyttää sopivia olosuhteita
• Ei aikapaineita (vaikka testaukseen voikin olla annettu vain
tietty aika – se on vain raami)
• Realistinen ajatus bugeista ja valmius niiden näkemiseen
missä tahansa
• Suuntautuminen siihen, millä on oleellista
• Valmius käsitysten muuttamiseen uusien havaintojen myötä
Ohjelmistotekniikka
217(504)
Session kulku
•
Käyttöskenaariot, käyttötapaukset hyvä lähtökohta
•
Erityyppisten käyttäjien toimintamallit
•
Ei tarkkaa kuvausten antamaa ohjausta – vain viitekehys
– Tiukka seuraaminen olisi systemaattista testausta…
•
Seurataan havaintoja, annetaan koetun suunnata testauksen
kulkua
Ohjelmistotekniikka
218(504)
5.5 Suorituksen dokumentointi?
•
Testilokeja tarvitaan aina
•
Omien ajatusten ulkoistaminen edes kirjoittamalla tekee
ajattelusta parempaa – ja parantaa testausta
•
Automaattinen logitussovellus taustalla tukee muistiinpanoa
•
Seuraavalla sivulla on yksi esimerkki ketterän testauksen
logista
Ohjelmistotekniikka
219(504)
Esimerkkitestiloki
Ohjelmistotekniikka
220(504)
5.6 Tutkiva testaus arjessa 1/2
•
Ketterän testauksen tavat ovat väistämättä tärkeitä periaatteita
•
Käytännön ohjelmistoteollisuudessa ei voida toimia kirkasotsaisesti
yksien periaatteiden mukaan
•
Tutkiva testaus on jo pitkään nähty tärkeänä osana hyvinkin
suunniteltua testausprojektia
•
Hyvään testaustapaan kuuluu ylipäätään aina se, että testaustapoja
muutetaan, kun saadaan uusia havaintoja tuotteesta ja vanhat tavat
eivät enää paljasta virheitä.
Ohjelmistotekniikka
221(504)
Tutkiva testaus arjessa 2/2
•
Olennaista on se, että tutkiminen myös tuottaa uusia testitapauksia,
jotka otetaan mukaan päivitettyihin testispekseihin
–
–
•
Uusi tieto saadaan jaettua kaikille testaajille
Tämä vähentää riskejä
Termit ovat tärkeitä
–
”Tutkiminen” on helpompi hyväksyä systemaattisessa
ohjelmistokehityksessä kuin minkäänlainen "ad-hoc"-toiminta
•
Ollakseen tehokkainta, tämä testaustapa pitää hyväksyä tärkeänä
testausmenetelmänä ja siihen pitää antaa aikaa osaavimmille
testaajille
•
Mutta hyvä testaus koostuu erilaisista tavoista ja tyyleistä ja yhden
ei ole hyvä antaa dominoida – ainakaan kunnes sen tiedetään
toimivan erinomaisesti
Ohjelmistotekniikka
222(504)
5.7 Uusien toimintojen nopea
testisuunnittelu
•
Interaktion taso:
– Lähtökohtana käyttäjätarina, käyttötapaus
– Toimii suoraan tutkivan testauksen lähtökohtana
•
Logiikan taso:
– Perinteiset testaustekniikat – ekvivalenssiositus, rajaarvoanalyysi, päätöspuut, tilamallipohjainen testaus
•
Fyysinen taso:
– Tapahtumien monitorointi ohjelmallisesti osana tutkivaa testausta
Ohjelmistotekniikka
223(504)
5.8 Ennakkovarautuminen
•
Ketterässä testauksessa on hyvä olla ennakkokäsityksiä
testattavista asioita
– Niiden avulla on heti luotavissa käsitys siitä, mitä kaikkea
uudessa toiminnallisuudessa on hyvä testata
– Luettelo tietynlaisten sovellusten ja toiminnallisuuksien yleisistä
testattavista asioista (esim. lista ”Ohjelmistojen yleiset testattavat
asiat”)
– Kaikki uudetkin systeemit ovat jossain määrin vanhan toistoa
– Listat tyypillisistä virheistä tietynlaisissa toteutuksissa ovat
hyödyllisiä
Ohjelmistotekniikka
224(504)
5.9 Ketterä testaus ei-ketterässä projektissa
1/4
•
Jokainen projekti sisältää aina ketteriä piirteitä
•
Ymmärretään että:
– Projekti ei koskaan tapahdu täysin ennakkosuunnitelmien
mukaan
– Testaus tuottaa uutta tietoa, johon on reagoitava
• Vaikka testausta tehtäisiin hyvin suunnitelmallisesti, projektin
testauksessa on tärkeää olla myös ketterästi tehtyjä osuuksia
Ohjelmistotekniikka
225(504)
Ketterä testaus ei-ketterässä projektissa 2/4
•
•
Testaussuunnittelu
– Testauksen W-malli, jossa testauksen peruspiirteet suunnitellaan
projektin alussa, mutta tarkempi testaus sitten, kun tuote alkaa
valmistua testattavaan kuntoon
Dynaaminen ohjaus
– Vaikka tuotteella on buildaussuunnitelma, testaus sovitetaan
ketterästi siihen, miten ohjelmiston osat valmistuvat
– Testauksen painotuksia eri osa-alueille muutetaan dynaamisesti
sen perusteella, paljonko vikoja löytyy ja mikä on eri osa-alueiden
riskitaso
– Jokaisen testikierroksen testisetti on viime kädessä
tapauskohtainen valinta
– Testisettejä päivitetään asiakkailta ja sidosryhmiltä saatavien
havaintojen perusteella
Ohjelmistotekniikka
226(504)
• Tutkiva testaus
– Testauksessa on aina mukana vapaamuotoinen osuus
– Uuteen versioon tutustuminen tehdään tutkivalla testauksella; se
tuottaa käsityksiä systemaattisen testauksen kohteista ja on
siten myös osa testaussuunnittelua
– Kun systemaattinen testaus ei enää tuota tehokkaasti uusia
vikoja, siirrytään vahvemmin tutkivaan testaukseen
– Havaintojen perusteella päivitetään myös systemaattisen
testauksen testejä
Ohjelmistotekniikka
227(504)
• Kokonaisuus on siis yhdistelmä ennakkosuunnittelua ja
ketterää reagointia
Testauksen
pääsuunnitelma
Dynaaminen
muuttaminen:
testitapaukset ja
painotukset
Tutkiva testaus
Tuottaa
tietoa
Systemaattinen
testaus
Jatkaa ja
täydentää
Ohjelmistotekniikka
Tutkiva testaus
228(504)
Riskialttiiden asioiden nopea verifiointi
• Ketteryydessä on keskeistä kyky tarttua nopeasti riskialttiisiin
asioihin
• Jos esimerkiksi projektissa toteutetaan mm. uudentyyppinen
protokolla, sen toimivuutta ei verifioida pelkästään normaalin
testauksen puitteissa, vaan verifiointi pyritään tekemään välittömästi
erottamalla protokollan toteutus ja testaamalla se niin pian kuin
mahdollista
– Näin saadaan osoitettua, että protokollaa voidaan käyttää
– Siihen liittyvä riski voidaan sulkea
Ohjelmistotekniikka
229(504)
Eräs kaksivaiheinen tutkivan testauksen malli
1. Uusille toiminnallisuuksille ensimmäisillä testauskierroksilla
tehtävä testaus, jolla opitaan tuotteen käyttäytymisestä
2. Myöhempien testauskierrosten ketterä testaus, joka jatkaa
virheiden etsimistä sitten, kun systemaattinen testisuunnittelu
ei enää löydä virheitä tehokkaasti
– Samalla vaihdetaan ”likaisempaan” testiympäristöön
•
Näiden välissä systemaattisempaa testausta.
Ohjelmistotekniikka
230(504)
a) Uuden toiminnallisuuden ensimmäisten
testauskierrosten testaus 1/2
•
Sovellustilanne:
– Uutta buildia ei ole testattu systemaattisesti; ei tiedetä, miten se
toimii ja käyttäytyy
– Se on saattanut läpäistä automaattiset savutestit
•
Tavoitteet
–
–
–
–
–
Opitaan uudet toiminnallisuudet
Tutkitaan ja ymmärretään sovellusta
Tarkkaillaan, miten se käyttäytyy
Havainnoidaan mahdollisia / tunnettuja ongelma-alueita
Löydetään virheitä
Ohjelmistotekniikka
231(504)
a) Uuden toiminnallisuuden ensimmäisten
testauskierrosten testaus 2/2
•
Taktiikka ja menettelyt
–
–
–
–
–
–
–
Suoritetaan täysiä käyttötapauksia "kokeilevassa mielentilassa"
Kokeillaan kaikkea ainakin kerran
Toimitaan puhtaassa testiympäristössä
Tehdään muistiinpanoja häiriöistä, hitaudesta, järjestelmän tilasta jne...
Kokeillaan sovelluksen alueita, joilla on aiemmin ollut virheitä
Tunnistetaan ja raportoidaan virheitä
Tarkistetaan myöhemmin muistiin (paperille ja mieleen) laitettujen
asioiden pohjalta, että testispeksit kattavat kaikki epäilyttävät alueet
Ohjelmistotekniikka
232(504)
b) Myöhäisten testikierrosten tutkiva testaus 1/4
•
Sovellustilanne
– Uusi buildi on testattu systemaattisesti
• Perusidea:
– Testaustapojen vaihtaminen auttaa löytämään uusia virheitä
– Käytetään tutkivaa testausta uusien virheiden löytämiseen
– Sovelletaan tekniikoita, joita ei ole aiemmin käytetty projektissa
Ohjelmistotekniikka
233(504)
•
Taktiikka ja menettelyt
– Käytetään tutkivia tekniikoita virheiden löytämiseen
– Käydään läpi alueita, joilla on ollut paljon virheitä
– Testataan virallisten testitapausten "ympärillä" tavoitteena
ohjelmiston "rikkominen"
– Suoritetaan kokonaisia käyttötapauksia
– Testaus tehdään "likaisessa" testiympäristössä – tämä auttaa
ongelmiin törmäämisessä
– Testausta muutetaan tuotteen käyttäytymisen perusteella;
keskitytään alueisiin, jotka ovat hitaita, joissa on odottamattomia
ilmiöitä jne.
Ohjelmistotekniikka
234(504)
–
–
–
–
–
–
Käytetään mielikuvitusta ohjelmiston monimutkaisilla alueilla
Aseta itsesi noviisin mielentilaan (joka ei ymmärrä mitään) ja expertin
mielentilaan (joka kokeilee kaikkea, koska "siihen on oikeus") tai toimi
kuin lapsi
Tee satunnaisia asioita. Tee samanaikaisia asioita. Keskeytä asioita
(mobiililaitteen tapahtuma, PC:n tapahtuma, kollegan tekemä
keskeytys!) jne.
Tee virheitä!
Raportoi kaikki virheet
Tarkista testispeksit ja ehdota uusia testitapauksia
Ohjelmistotekniikka
235(504)
1. Valitse rooli, jossa toimit (simuloi jotain käyttäjäryhmää käytettävien
toimintojen osalta)
2. Valitse sen pohjalta testiympäristö
3. Valitse käyttötapaukset ja priorisoi ne
4. Tunnista prioriteetit
– Uudet toiminnot, muutokset
– Millä alueilla on ollut virheitä
– Toimintojen prioriteetit (tuotteen ja valitun käyttäjäryhmän kannalta)
5. Suorita kokeileva testikierros
6. Suorita virheitä tekevä testikierros
7. Suorita kuormittava testikierros
8. Sovita toimintasi havaintoihisi ja improvisoi!
Ohjelmistotekniikka
236(504)
6. Riskianalyysi ja testien priorisointi
• Riskianalyysiä tehdään
– Tiedostamatta: jos jätän tenttiin luvun viimeiseen iltaan, millä
todennäköisyydellä reputan ja mitä seurauksia siitä on?
– Tiedostaen: mikäli organisaation avainhenkilöiden täytyy matkustaa
samana päivänä samaan kohteeseen, kannattaako heidät laittaa
samalle lennolle?
• Turvallisuuskriittisten järjestelmien kehittämisessä riskianalyysi on
pakollista, muualla suositeltavaa
– Riskianalyysiin ei ole "yhden koon malleja"
– Jokaisessa organisaatiossa pitäisi olla henkilö, joka osaa suunnitella
projekteille tehokkaan ja yksinkertaisen käytännöt
• Riskianalyysin menettelyt vaihtelevat eri tilanteissa. Tässä
luvussa esitetään vain muutama tapa, joka sopii testauksen
suuntaamiseen. Esim. projektin riskianalyysi olisi hieman
erilainen.
Ohjelmistotekniikka
237(504)
Erilaisia riskejä
• On olemassa kahdenlaisia riskianalyysejä (ja riskejä)
– Projektiriskit. Mikä voisi mennä pieleen projektissa? Aikataulut,
käytettävissä henkilöitä, teknisiä ongelmia...
– Tuoteriskit. Mitkä asiat tuotteessa voisivat aiheuttaa ongelmia
käyttäjälle?
• Kun suunnittelemme testausta, jälkimmäinen on tärkein
– Valitettavasti kaikista mahdollisista testeistä voidaan
dokumentoida ja ajaa vain pieni osa
– Riskianalyysiä käyttämällä voidaan testejä priorisoida: aloitetaan
niillä, jotka testaavat tärkeimpiä asioita ja jatketaan muihin, jos
on aikaa
– Riskianalyysin tuloksilla voidaan myös vakuuttaa projektin johto
siitä, että asiat pitää tehdä tietyllä tavalla
Ohjelmistotekniikka
238(504)
6.1 Käytön ymmärtäminen
lähtökohtana
• Tärkeää ymmärtää tuotteen käyttöä
– Miten tuotetta käytetään?
– Millainen on työprosessi, mikä siinä on tärkeää?
– Mitä tehdään eniten – eli millaisten toimintojen ja ominaisuuksien
on oltava hyvässä kunnossa
– Millaisten asioiden on onnistuttava varmasti – missä ei saa tulla
koskaan ongelmia
• Esimerkiksi tietojärjestelmän käyttäjillä on perustehtäviä, joita
käytetään koko ajan – niiden on toimittava varmasti
• Ja tietoturvallisuuden vuoksi on monien asioiden oltava
pomminvarmoja
• Käyttäjän toiminta & liiketoimintataso on oman riskien
tunnistamien paikka
Ohjelmistotekniikka
239(504)
6.2 Riskianalyysin kulku 1/5
• Käyttäjälähtöisen yksinkertaisen riskianalyysiprosessin kulku:
Kokoa
riskianalyysisessio
Käytä
järjestystä
testien
priorisointiin
Ohjelmistotekniikka
Listaa
järjestelmän
toiminnot (ja
ominaisuudet)
Järjestä omiNaisuudet
riskin
mukaan
Arvioi niiden
käytön
yleisyys
Arvioi tuloksia
ja muuta
tarvittaessa
Arvioi
toimintojen
tärkeys
käyttäjille
Laske
riskipohjeinen
prioriteetti
240(504)
Riskianalyysin kulku 2/5
• Riskianalyysi pitäisi tehdä
mahdollisimman aikaisessa vaiheessa
projektia
• Aivoriihen (brainstorming team)
kokoaminen: mukana esim. käyttäjiä,
kehittäjiä, testaajia sekä henkilöitä
markkinoinnista, asiakaspalvelusta sekä
teknisestä tuesta
– Tavoitteena mahdollisimman laaja
tietämys tuotteesta ja toimialasta
– Muutaman tunnin sessio, jolla
käsikirjoitus ja vetäjä
Ohjelmistotekniikka
241(504)
• Listataan tuotteen toiminnot ja muut ominaisuudet
– Eli kaikki se, mihin testaus tulee kohdistumaan
– Mietitään tärkeimmille käyttäjäryhmille, miten usein
ominaisuuksia käytetään ja miten tärkeä ominaisuus on
käyttäjälle, miten olennaista on toiminnon toimiminen hyvin
– Karkeina numeerisina arvioina 1…5
• Taajuuden asteikko esim. 1-5 (harvoin, silloin tällöin,
päivittäin, monta kertaa päivässä, jatkuvasti)
• Tärkeyden asteikko esim. 1-5 (kosmeettinen haitta, hidastus,
ylimääräistä työtä, vakava vahinko, kuolema)
– Niiden tulo kertoo riskin ja testauksen prioriteettia kuvaavan
luvun
– Arvioidaan mieluummin ylöspäin pyöristäen
Ohjelmistotekniikka
242(504)
• Analyysi listataan yleensä taulukkoon. Esimerkkinä
puhelinsovellus
Ominaisuus
Käytön taajuus
(1-5)
Onnistumisen
kriittisyys (1-5)
Prioriteetti
(tulo)
Puhelun soitto
5
3
15
Hätäpuhelu
1
5
5 (kuitenkin
kriittinen…)
Soittajan nimen 5
näyttö
1
5
Ohjelmistotekniikka
243(504)
• Taulukko ja keskustelu on vain väline yhteisen ymmärryksen
luomiseen
• Tulosten perusteella nähdään, mitkä tuotteen osa-alueet ovat
sellaisia, joihin pitää panostaa testaamalla ja muilla keinoin
– Kun analyysi tehdään ennen systeemin suunnittelua, voidaan
suunnitteluunkin vaikuttaa
• Taustaksi tarvitaan tietoa käyttäjien toiminnasta – ilman sitä ei
hyvä testauskaan ole mahdollista
Ohjelmistotekniikka
244(504)
Riskianalyysi toteutuksen
näkökulmasta
• Edellä katseltiin toimintoja käyttäjän näkökulmasta
• Kun tiedetään tiedetään ohjelman toteutusprosessi, voidaan
ottaa senkin piirteitä huomioon ja miettiä, miten altis projekti
on bugien syntymiselle
• Pohdi tällöin vaikkapa pääkomponenteittain
– Paljonko on uutta koodia – uusi on virhealtista
– Onko toteuttava tiimi uusia – uuden tiimin työtä pitää katsella
tarkemmin
– Onko jokin teknologia uusi ja vasta kypsyvä – pitää testata
tarkemmin
• Riskianalyysi keskittyy usein liikaa tähän näkökulmaan,
ottamatta huomioon eri ominaisuuksien käyttöä
Ohjelmistotekniikka
245(504)
Riskianalyysejä päivitettävä
• Niin kuin muitakin dokumentteja, myös riskianalyysin tuloksia
täytyy pitää yllä
– Esim. vaatimusten muuttuessa
• Kun ryhdytään tekemään järjestelmän uutta versiota, voidaan
yleensä edellisen riskianalyysin tuloksia hyödyntää
– Muutettavien osien kohdalta riskit yleensä kasvavat
– Yleensä häiriöiden todennäköisyydet muuttuvat ennemmin kuin
niiden vaikutukset
Ohjelmistotekniikka
246(504)
Turvallisuuskriittisten järjestelmien
riskianalyysit
• Edellä tarkasteltiin "tavallisia" ohjelmistoja
• Turvallisuuskriittisten järjestelmien riskianalyysit on tehtävä
tarkemmin
• Lähtökohta niissä on systemaattinen turvallisuusanalyysi tai
vaaran arviointi, jossa tarkastellaan esim. käyttötehtävien
kulkua tai systeemin osia ja arvioidaan niistä koituvaa vaaraa
• Tarkempaan sen kulttuurin toimintamallien käsittelyyn ei ole
tässä mahdollisuutta
• Perusperiaate on: Mitä suuremmat riskit, sitä
systemaattisemmin riskianalyysi pitää tehdä ja sitä
enemmän sille on virallisia tai "kulttuurisia" vaatimuksia
Ohjelmistotekniikka
247(504)
MoSCoW-menetelmän priorisointitapa
• Toinen priorisointitapa on MoSCoW-menetelmään, joka
määrittelee seuraavat neljä prioriteettia (alenevassa
tärkeysjärjestyksessä):
–
–
–
–
Must test
Should test
Could test
Won’t test
• Ks. “Successful Test Management: An Integral Approach”, Iris
Pinkster & Bob van de Burgt & Dennis Janssen & Erik van
Veenendaal, Springer, 2004. &
https://en.wikipedia.org/wiki/MoSCoW_Method
Ohjelmistotekniikka
248(504)
Esimerkki MoSCoW-arvioinnista
Kaikki asiakkaat
kärsivät
Must test
Yksi asiakkaista
kärsii
Must test
Kaikki asiakkaat
kärsivät
Must test
Yksi asiakkaista
kärsii
Should test
Me
menetämme
rahaa
Ei kiertotietä
Should test
Kiertotie on
olemassa
Could test
Kukaan
ei menetä
rahaa
Ei kiertotietä
Could test
Kiertotie on
olemassa
Won’t test
Ihmisiä
kuolee
Jos
tämä
vaatimus
ei
toteudu…
Ohjelmistotekniikka
Asiakkaat
menettävät
rahaa
249(504)
Edistymisen seuranta, eräs esimerkki
testatut vaatimukset
toimitus
Could test
arvio
Should test
toteutunut
Must test
aika
Ohjelmistotekniikka
250(504)
Hienojakoinen MoSCow…
• Joissain projekteissa voidaan tarvita vielä hienojakoisempaa
priorisointia
– Testijoukot kootaan testitapauksista, jotka perivät testijoukon
MoSCoW-prioriteetin
• Testijoukko voi vastata esim. yhden vaatimuksen testejä
– Testijoukon sisällä, testitapaukset priorisoidaan vielä asteikolla
High, Medium ja Low
– Nyt voidaan tehdä päätös, että esimerkiksi Should test –
prioriteetin omaavasta joukosta ajetaan vain High-prioriteetin
omaavat testit
– Huom! Eri joukkoihin kuuluvien testien prioriteetit eivät
välttämättä enää ole vertailukelpoisia keskenään
• Onko Should test Low tärkeämpi testitapaus kuin Could test
High?
Ohjelmistotekniikka
251(504)
Testikohteen riskien ja vaatimusten
yhteensovittaminen
• Jos on olemassa riski, mutta ei sitä vastaavaa vaatimusta,
pitää miettiä onko riski turha vai pitääkö sitä vastaava
vaatimus lisätä
• Jos on olemassa vaatimus, mutta ei siihen liittyvää riskiä,
voidaan riski joko lisätä tai sitten vaatimus poistaa turhana
• Riskianalyysi voi siis parantaa myös vaatimusmäärittelyn
laatua
• Analyysiä voidaan käyttää myös taloudelliselta näkökantilta
katsottuna
– Ei arvioidakaan suoraan häiriöiden vaikutusta käyttäjiin, vaan
pikemminkin ohjelmiston tuottamaan rahamäärään
– Esim. mikäli jokin ominaisuus on äärimmäisen tärkeä jollekin
hyvin maksavalle asiakkaalle, voidaan tämä ottaa huomioon
häiriön vaikutusta arvioitaessa
Ohjelmistotekniikka
252(504)
7. Testauksen dokumentoinnista
• Kuten ohjelmistotuotannossa yleensä, dokumentoinnilla on
merkittävä osuus testauksessa
– Dokumentteja (dokumentti-dokumentteja ja tietojärjestelmien
sisältöjä) syntyy usein paljon
– Niiden kirjoittamiseen voi kulua huomattavan paljon aikaa
– Dokumenttien ja varsinaisten testien synkronointi voi muodostua
ongelmaksi
• Dokumentoinnin tarkoituksena on saada tieto suunnittelijoiden
ja testaajien korvien välistä muotoon, jota muutkin voivat
käyttää
– Kun asiat kirjataan ylös, huomataan yleensä puutteita ja
väärinkäsityksiä
– Asiat pitää muistaa myöhemminkin
– Dilemma: miten dokumentoida kaikki tarpeelliset asiat, mutta ei
mitään turhaa
Ohjelmistotekniikka
253(504)
7.1 Testauksen korkean tason
suunnitteludokumentit
• Testauksen suunnittelun tavoitteena on tehdä testien
suorittaminen ja niistä raportointi mahdollisimman helpoiksi
– Projektisuunnitelma:
• Mitä dokumentteja tuotetaan
• Kuka tuottaa
• Milloin
• Testauksen yleissuunnitelmasta (päätestaussuunnitelma) on
hyötyä:
–
–
–
–
Yleinen lähestymistapa testaukseen – mitä, miten, koska
Testien aikataulut
Testausvaiheiden aloitus- ja lopetusehdot
Kuka vastaa ja mistä (mm. testiympäristöjen pystyttäminen jne.)
Ohjelmistotekniikka
254(504)
7.2 Testauksen suunnittelun prosessi
• Testauksen suunnittelu [Haikala&Märijärvi 06] mukaillen:
Kokemus,
tarkistuslistat
Ohjelmiston
vaatimukset
Projektin
elinkaarimalli
Testauksen
ja testien
suunnittelu
Noudatettavat
standardit
(mm. turv. kriitti.)
Yrityksen
toimintaohjeet
Ohjelmiston
määrittelyt
Testien tarkempi
suunnittelu
(oikeaan aikaan)
Aiemmat
projektit
Testitapausten,
skriptien suunnittelu ja
toteutus yms.
Testien
suoritus
Testiraportit
Ohjelmistotekniikka
255(504)
Suunnitteludokumenttien suunnittelusta 1/2
• Suunnitelmia laadittaessa pitää muistaa niiden tarkoitus ja
vaatimukset
– Hyvä dokumentointi auttaa keskittymään oikeisiin asioihin kun se
”mitä” tai ”miten” ollaan testaamassa muuttuu
– Mitä suunnitelmia vaaditaan
– Keiden pitää hyödyntää niitä ja ymmärtää ne
• Esim. hyväksymistestaussuunnitelmaa pitää ymmärtää
ihmisten, jotka eivät tiedä testauksesta paljoakaan
– Alan ja päämiehen kulttuuri ja tottumukset
– Isoihin projekteihin enemmän suunnittelua kuin pieniin
– Suunnitelmilla jaetaan tietoa ja luodaan luottamusta
– Jos asiat eivät sujukaan, suunnitelmat ja niissä todetut
kompromissit ovat tärkeä suoja testaajille
Ohjelmistotekniikka
256(504)
Suunnitteludokumenttien suunnittelusta 2/2
• Suunnitelmia pitää muistaa päivittää
• Suunnitteluprosessi on tärkeämpi kuin suunnitelmat
– Jaetaan näkemyksiä, kokemuksia ja tietoa, opitaan
• Testityökalut saattavat auttaa dokumentoinnissa
– Tietyntyyppisten dokumenttien (osittainen) generointi
Ohjelmistotekniikka
257(504)
Suunnitteludokumentaation
kokonaisuudesta 1/2
• Kuten testauksen vaiheistaminenkin, dokumentointi pitää
suunnitella projektin koon, riskitason ja testattavan
järjestelmän perusteella
• Aina tarvitaan jokin suunnitelma
• Pienellä projektilla riittää yleensä yksi yleinen
testaussuunnitelma, joka kattaa sekä integrointi- että
järjestelmätestauksen
– Suunnitelma tehdään määrittelyn yhteydessä ja sitä
täydennetään myöhemmin
Ohjelmistotekniikka
258(504)
Suunnitteludokumentaation
kokonaisuudesta 2/2
• Suuremmilla projekteilla tehdään päätestaussuunnitelma, joka
kuvaa testauksen kokonaisuuden ja eri testaustasoille ja
testityypeille omat suunnitelmat
• Päätestaussuunnitelma on tärkeä. Sen avulla jaetaan tietoa
siitä, mitä kaikkea testausta on ajateltu tehtävän.
Päätestaussuunnitelma
Järjestelmätestaussuunnitelma
Integrointitestaussuunnitelma
Yksikkötestaussuunnitelma
Ohjelmistotekniikka
259(504)
7.3 IEEE 829 antaa osviittaa suunnitelmiin
• IEEE 829-2008, Standard for Software
and System Test Documentation, on
yksi niitä harvoja standardeja, joita
testauksessa käytetään
• Sen mukaan on tehty paljon
testaussuunnitelmia ja raportteja
• Hyvä uutinen: Standardin uusin versio
ymmärtää, että tilanteet ja tarpeet
vaihtelevat ja silloin saa
dokumentaation laajuus ja sisältökin
vaihdella
Ohjelmistotekniikka
260(504)
1. Introduction
IEEE 829:n esimerkkirunko
päätestaussuunnitelmalle
1.1 Document identifier
1.2 Scope
1.3 References
1.4 System overview and key features
1.5 Test Overview
1.5.1 Organization
1.5.2 Master test schedule
1.5.3 Integrity level schema
1.5.4 Resources summary
1.5.5 Responsibilities
1.5.6 Tools, techniques, methods, and metrics
Ohjelmistotekniikka
2. Details of the master test plan
2.1 Test processes including definition of test levels
2.1.1 Process: management
2.1.2 Process: acquisition
2.1.3 Process: supply
2.1.4 Process: development
2.1.5 Process: operation
2.1.6 Process: maintenance
2.2 Test documentation requirements
2.3 Test administration requirements
2.4 Test reporting requirements
3. General
3.1 Glossary
3.2 Document change procedures and history
261(504)
IEEE 829:n esimerkkirunko yhden
testaustason suunnitelmalle
3. Test management
1. Introduction
1.1 Document identifier
1.2 Scope
1.3 References
1.4 Level in the overall sequence
1.5 Test classes and overall test conditions
2. Details for this level of test plan
2.1 Test items and their identifiers
2.2 Test traceability matrix
2.3 Features to be tested
2.4 Features not to be tested
2.5 Approach
2.6 Item pass/fail criteria
2.7 Suspension criteria and resumption requirements
2.8 Test deliverables
Ohjelmistotekniikka
3.1 Planned activities and tasks; test progression
3.2 Environment / infrastructure
3.3 Responsibilities and authority
3.4 Interfaces among the parties involved
3.5 Resources and their allocation
3.6 Training
3.7 Schedules, estimates, and costs
3.8 Risk(s) and contingency(s)
4. General
4.1 Quality assurance procedures
4.2 Metrics
4.3 Test coverage
4.4 Glossary
4.5 Document change procedures and history
262(504)
7.4 Matala taso: testitapausten
dokumentointi
• Testitapauksia ei yleensä suositella kuvattavaksi
suunnitelmadokumenteissa, vaan
–
–
–
–
Testauksenhallintajärjestelmässä
Erillisessä dokumentissa, vaikkapa Excel-taulukossa
Tai jossain muualla, missä niiden ylläpito on helppoa
Yksikkötestauksen testitapaukset dokumentoidaan niiden
testikoodissa (josta voi tuottaa listauksia)
• Testitapausten ei pidä olla jotain, mikä jäädytetään, vaan
jatkuvasti kehittyvää testauksen "raaka-ainetta", joten niiden
käsittelyn on oltava helppoa ja tapahduttava yhdessä
paikassa
Ohjelmistotekniikka
263(504)
7.5 Pienissä projekteissa kevyesti
• Pienissä projekteissa testaussuunnitelmat voidaan sisällyttää
muihin suunnitelmiin
– Tavoite: dokumenttien ja niiden sivujen määrän minimointi
– Järjestelmätestaussuunnitelma voidaan sisällyttää
projektisuunnitelmadokumenttiin
– Integrointitestaussuunnitelma voidaan sisällyttää
suunnitteludokumenttiin
– Kunkin moduulin suunnittelun yhteyteen voidaan liittää sitä
vastaavan testiympäristön ja testitapausten määrittely
Ohjelmistotekniikka
264(504)
7.6 Testausraportit
•
Erityisiä testausraportteja tehdään yleensä
järjestelmätestaustasolla tietyn buildin testaukselle
–
•
Niitä tukee reaaliaikainen näkymä testauksen edistymiseen
testauksenhallintajärjestelmässä
Testausraportin runko-esimerkki:
–
–
–
–
–
–
–
Johdanto
Ristiriidat ja poikkeamat
Kattavuustarkastelu
Tulokset
Arviointi
Toiminta
Hyväksyminen
Ohjelmistotekniikka
265(504)
7.7 Hyvä testausraportti
•
•
•
•
Hyvä raportti tarjoaa juuri sitä sisältöä, mitä tarvitaan
raportointihetkellä.
Se on tehty niiden ihmisten luettavaksi, jotka tietoa tarvitsevat
(esitystavat, detaljit, asioiden järjestys).
Lyhyys ja kompaktius on etu.
Raporttien kirjoittaminen tai odottaminen ei saa aiheuttaa
viiveitä toimintaan.
–
•
Raportoitava data on hyvä saada tuotettua automaattisesti, ei
käsin syöttöä.
Raportointi tukee testauksen dokumentointia mm. pakollisten
standardien tarpeisiin (esim. turvallisuuskriittiset järjestelmät)
ja auttaa toiminnan kehittämisessä.
Ohjelmistotekniikka
266(504)
IEEE 829-2008:n dokumentaation rakenne 1/2
Huom: Testitasot
voivat olla muitakin
kuin tässä olevat
esimerkit
Master test plan
(MTP)
Acceptance test
plan
System test plan
Component
integration test plan
Component test
plan
System test design
System test
procedures
System test cases
Test execution
Ohjelmistotekniikka
267(504)
IEEE 829-2008:n dokumentaation rakenne 2/2
Level interim test
status report(s)
Test execution
Test level logs
Acceptance test
report
Test level
anomaly reports
System test
report
Component
integration test
report
Component test
report
Master test
report
Ohjelmistotekniikka
268(504)
IEEE 829-2008:n suosittelemat dokumentit
riskitason mukaan
• Vertailu kriittisille ja triviaaleille projekteille (erimerkki, ei
tarkka)
Ohjelmistotekniikka
269(504)
Esimerkkejä IEEE 829-2008:n mukaisista
dokumenttipohjista
• Kurssin projektin sivulle on koottu dokumenttipohjia, jotka on
tehty standardin esimerkkien perusteella.
Ohjelmistotekniikka
270(504)
7.8 IEEE 829-2008 – Ketterässä toiminnassa
riittää vähäisempi dokumentaatio
"6.2 Eliminate content topics covered by the process
Some organizations are using agile methods and exploratory
testing techniques that may de-emphasize written
documentation. For testing software with agile methods, they
can choose as little as a general approach test plan, and then
no detailed documentation of anything except the Anomaly
Reports. Some organizations use a blended approach combining
agile testing with parts of the test documentation detailed in this
standard. It is up to the individual organization to ensure that
there is adequate documentation to meet the identified integrity
level."
Ohjelmistotekniikka
271(504)
8. Testauksen seuranta
• Testauksen edistyminen yksikkö- ja integrointitestauksessa
– Suositaan automaattisesti tehtäviä listauksia suoritetuista,
läpäisseistä ja läpäisemättömistä testeistä
– Testaustyökalut tekevät niitä "luonnostaan"
– Seurataan testikattavuutta tuotteen osa-alueilla
• Testauksen edistyminen järjestelmätestaustasolla
– Suoritetut testit kirjataan testauksenhallintajärjestelmään (Quality
Center, TestLink, Excel-taulukko) tai työtehtäväjärjestelmässä
(kuten JIRA)
– Testilokeja pidetään varsinkin tutkivassa testauksessa
– Seurataan eri toimintojen testausta ja vaatimuskattavuutta
– Verrataan haluttuun testauksen edistymiseen
Ohjelmistotekniikka
272(504)
8.1 Testauksenhallintaohjelmisto
pähkinänkuoressa
•
•
•
•
•
•
i
Luo ja hallitse testitapauksia
Organisoi testitapaukset testisuunnitelmiin
Suorita testitapauksia ja kirjaa läpäisy buildeittain
Seuraa tuloksia
Laadi raportteja
Testitapaukset voidaan linkittää vaatimuksiin
– Vaatimuskattavuuden seuranta
• Linkitys vikatietokantoihin, kuten Bugzilla, Mantis, JIRA
• Esimerkki sellaisesta avoimen lähdekoodin TestLink
http://www.teamst.org/
Ohjelmistotekniikka
273(504)
8.2 Virhetilanteen seuranta
• Tärkeä näkökulma projektin etenemiseen
• Löydetyt virheet kirjataan vikaraportteihin (raportti per virhe) –
tästä lisää myöhemmin
• Virheiden luokittelu (esim. mild, moderate, serious,
catastrophic)
– Liian monta tasoa hankaloittaa luokittelua
• Yksikkö- ja integrointitestaustasolla virheitä ei yleensä listata
• Järjestelmätestaustasolla virheet viedään vikatietokantaan
(Bugzilla, Mantis tms.) – virheraportoinnista lisää myöhemmin
• Seurataan testauksen kattavuusmittareita
• Seurataan tilannetta tuotteen osa-alueittain ja säädetään
tarpeen mukaan testaustapoja
Ohjelmistotekniikka
274(504)
8.3 Testausraportti
• Erityisten testausvaiheiden jälkeen tehdään usein
testausraportti
– Esimerkiksi jonkin buildin järjestelmä- tai hyväksymistestaus
– Erityistestaukset, kuten käytettävyys- tai suorituskykytestaus
• Tutkivan testauksen testilogit ovat osa raportin aineistoa
• Testipäiväkirjan pitämisestä saattaa myös olla hyötyä
– Testaajat pitävät usein omaa päiväkirjaa
Ohjelmistotekniikka
275(504)
9. Lisää testauksen menetelmistä ja
tekniikoista
• Tässä luvussa käsitellään dynaamiseen
testaukseen liittyviä menetelmiä ja täydennetään
näkemystä rikkaasta testauksen
kokonaisuudesta.
Ohjelmistotekniikka
276(504)
Tarjolla suuri määrä menetelmiä
• Erilaisia tekniikoita on kehitetty valtava määrä
– Käytettävä tekniikka täytyy valita tapauskohtaisesti
– Yleisesti ottaen testauksessa on hyvin hankala löytää Best
Practise™-tyyppisiä toimintatapoja – kaikki riippuu tilanteesta
• Sopivan tekniikan valintaan kussakin tilanteessa voidaan
antaa kuitenkin joitain nyrkkisääntöjä
• Tekniikat yleensä täydentävät toisiaan ja niitä käytetään
yhdessä, joustavasti soveltaen
• Tekniikat voidaan myös luokitella usealla eri tavalla
Ohjelmistotekniikka
277(504)
Valinnan peruskysymyksiä
• Tekniikoiden valinnan pohjaksi pitää miettiä monia
kysymyksiä:
–
–
–
–
–
–
–
Hyödynnetäänkö testattavan ohjelman koodia vai ei?
Kuka testaa?
Millaisia asioita testataan?
Minkä tyyppisiä ongelmia etsitään?
Mitä pitää tehdä?
Mistä tiedetään onnistuiko testiajo vai ei?
Missä ohjelmistokehityksen vaiheessa ollaan? (Tehdäänkö
koodia vai arvioidaanko soveltuvuutta käyttöön)
• Tällaisia asioita tarkastellaan seuraavaksi.
Ohjelmistotekniikka
278(504)
Menetelmien kuvailua tyypeittäin
• Seuraava luokittelu jakaa tekniikat sen perusteella mihin em.
kysymykseen ne pääsääntöisesti yrittävät vastata
– Luokittelu ja kuvaukset perustuvat suurelta osin lähteeseen
[Kaner et al. 02]
• Eri tekniikoita pitää sopivasti yhdistellä aina tarpeen mukaan
• Tekniikat muodostavat eräänlaisen työkalupakin
– Ruuvimeisselillä ja vasaralla pääsee jo pitkälle, mutta joskus
tarvitaan sahaakin
Ohjelmistotekniikka
279(504)
9.1 Hyödynnetäänkö ohjelman koodia vai
ei? 1/4
• Lasilaatikkotestauksessa testitapaukset valitaan järjestelmän
toteutukseen, kuten lähdekoodiin, tutustumalla
(glass/white/clear box testing)
• Lasilaatikkotestaus keskittyy usein vain toteutettujen
toimintojen testaukseen
– Yksikkötestaus on tällaista
– TDD:ssä tehdään vielä toteuttamattomille asioille (metodit,
funktiot) testitapauksia, jotka epäonnistuu, kunnes toteutus on
tehty (ja toimii). Näin pidetään samalla kirjaa toteutuksen
edistymisestä.
Ohjelmistotekniikka
280(504)
Hyödynnetäänkö ohjelman koodia vai ei?
2/4
• Mustalaatikkotestauksessa testattava ohjelma nähdään
mustana laatikkona eli sen toteutuksesta ei välitetä (black box
testing)
• Kun yksiköitä yhdistetään ja abstraktiotaso kasvaa, siirrytään
lasilaatikkotestauksesta mustalaatikkotestaukseen
– Yksikkötestaus usein lasilaatikkotestausta, järjestelmätestaus
mustalaatikkotestausta
• Mutta alimmalla tasolla lasilaatikkotestaus jatkuu
Ohjelmistotekniikka
281(504)
3/4
• Testitapaukset valitaan spesifikaation tai toteutuksen
perusteella
• Testit voidaan suunnitella vaikka toteutusta ei vielä olisikaan
– Määrittelyt, käyttötapaukset tai käyttäjätarinat pohjana
• Testitapaukset säilyttävät käyttökelpoisuutensa myös
toteutuksen muuttuessa, jos määrittely säilyy samana
• Menetelmä toimii myös muulle kuin ajettavalle ohjelmalle, eli
ideat yleistyvät
Ohjelmistotekniikka
282(504)
4/4
• Tekniikat täydentävät toisiaan: siinä missä lasilaatikkotestit
löytävät matalan tason virheitä (lähellä koodia),
mustalaatikkotestit löytävät korkeamman tason virheitä
(lähellä vaatimuksia ja käyttäjiä)
– Spesifikaatiot korkeammalla abstraktiotasolla kuin toteutus,
jossa metsä hukkuu helposti puiden sekaan
• Mikäli testauksessa käytetään hyväksi tietoa ohjelman
toteutusperiaatteista, mutta ei tehdä puhdasta lasi- tai
mustalaatikkotestausta, voidaan tätä kutsua
harmaalaatikkotestaukseksi
Ohjelmistotekniikka
283(504)
9.2 Kuka testaa? 1/3
• Kehittäjä:
– Yksikkötestaus, integrointitestaus
• Testaaja:
– Integrointitestaus, järjestelmätestaus
– Tilaajan puolella hyväksymistestaus
• Käyttäjätestit:
– Ohjelmistoa testaa sen käyttäjä, joskus mukana myös toimittajan
testaustiimin jäsen; hyväksymistestaus
• Alfa-testaus:
– Käyttäjätesti järjestelmän toimittajan tiloissa, testiversiot eivät julkisia
• Beta-testaus:
– Käyttäjätesti asiakkaan tiloissa, julkisesti jaettavat testiversiot
Ohjelmistotekniikka
284(504)
• Crowd testing:
– Laajat käyttäjämäärät tavoitteellisessa testauksessa
• Sisällöllinen asiantuntijatestaus (subject-matter expert testing):
– Ohjelmisto annetaan sellaisen henkilön testattavaksi (ei välttämättä
käyttäjä), joka tuntee jonkin ohjelmiston toteuttaman osa-alueen kuin
omat taskunsa
– Tuloksena löytyneitä vikoja, kritiikkiä ja joskus myös kehujakin
• Paritestaus:
– Kaksi testaajaa testaavat yhdessä yhden tietokoneen ääressä ja
vaihtavat koneenkäyttäjää aina välillä
Ohjelmistotekniikka
285(504)
• Bugi-kekkerit (bug bashes):
– Toimittajan tiloissa hieman ennen ohjelmiston julkistusta järjestettävä
esim. puoli päivää kestävä tilaisuus, johon kaikki työntekijät (myös
ohjelmoijat, myyntimiehet, sihteerit…) voivat osallistua
– Onnistuminen riippuu paljon organisaatiosta
• Eat your own dogfood:
– Toimittaja ottaa omassa organisaatiossaan hyötykäyttöön ohjelmiston
esiversion
– Vasta kun ohjelmisto on havaittu omassa käytössä tarpeeksi
luotettavaksi, se toimitetaan asiakkaalle
Ohjelmistotekniikka
286(504)
9.5 Mitä ohjelman osaa testataan? 1/3
• Funktiotestaus: testataan funktiot yksi kerralla
– Testataan jokainen funktio niin hyvin, että voidaan sanoa sen
toimivan kuten pitäisi
– Kannattaa tehdä ennen monimutkaisempia testejä, joissa
testitapaukset kattavat useampia funktioita
• Ominaisuustestaus (feature testing): testataan ominaisuuksia,
jotka tyypillisesti on toteutettu usean eri funktion
yhteistoimintana
• Menutestaus (menu tour): graafisen käyttöliittymän menut ja
dialogit käydään läpi ja testataan kaikki valinnat
Ohjelmistotekniikka
287(504)
• Logiikkatestaus: testaan ohjelman muuttujien välisiä
riippuvuuksia
– Esim. mikäli muuttujan Ikä arvo on suurempi kuin 50 ja
muuttujan Tupakoi arvo on True, muuttujan
TarjoaHenkivakuutusta arvo tulee olla False
– Tavoitteena on testata jokainen looginen suhde ohjelman
muuttujien välillä (mikä on usein kuitenkin mahdotonta)
• Tilapohjainen testaus: käydään läpi suuri määrä ohjelman
mahdollisia tilamuutoksia ja tarkastetaan, että jokaisessa
tilassa ohjelma hyväksyy vain oikeat syötteet ja siirtyy niiden
seurauksena oikeaan tilaan
• Konfiguraatiokattavuustestaus: testataan ohjelmiston erilaisia
konfiguraatioita (esim. laitteisto, muu ympäristö) ja mitataan
kuinka suuri osa kaikista mahdollisuuksista on katettu
Ohjelmistotekniikka
288(504)
• Vaatimustestaus: testataan vaatimusmäärittelyssä mainitut
vaatimukset yksitellen yrittäen näyttää, että ne joko on täytetty
tai sitten ei
– Vaatimuskattavuusmatriisia voidaan hyödyntää testauksen
kattavuutta mitattaessa
• Spesifikaatiopohjainen testaus: testataan ohjelmiston
spesifikaatioissa esitettyjä sellaisia vaatimuksia, joiden
toteutumiseen voidaan vastata joko kyllä tai ei
– Spesifikaatioiksi voidaan laskea myös käyttöohjeet, mainokset
yms.
• Syötteiden testaus
– Klassiset menetelmät ekvivalenssiositus ja raja-arvoanalyysi.
Ohjelmistotekniikka
289(504)
9.8 Minkä tyyppisiä ongelmia etsitään? 1/3
• Riskiperustainen testaus: käytetään riskianalyysiä sen
selvittämiseen mitä testataan seuraavaksi
– Testaus priorisoidaan sen perusteella, millä todennäköisyydellä
jokin ohjelman ominaisuus ei toimi ja toimimattomuuden
mahdollisilla seuraamuksilla
– Mitä suurempi riski johonkin ominaisuuteen liittyy, sen
aikaisemmin ja täydellisemmin se pitää testata
Ohjelmistotekniikka
290(504)
• Riskiperustaisen testauksen lisäksi pitää testata myös
sellaisia alueita, joihin ei riskianalyysin perusteella pitäisi
keskittyä
– Koskaan ei voi olla varma siitä, kuinka hyvin analyysi on tehty
• On olemassa riski siitä, että riskianalyysi on väärässä
– Mikäli jokin riski on jäänyt analyysissä huomaamatta, tulee
toteutusta testattua tältä osin edes hieman
• Esim. kannattaa testata ajoitus- ja rinnakkaisuusriippuvaisia
ominaisuuksia vaikka niihin ei riskianalyysissä olisikaan
kiinnitetty huomiota
– Esim. mikäli tapahtuma A tapahtuu yleensä ennen tapahtumaa
B, yritetään etsiä tilanteita, joissa B tapahtuukin ennen A:ta
Ohjelmistotekniikka
291(504)
• Ominaisuuksien luonteen perusteella:
–
–
–
–
Käytettävyystestaus etsii käytettävyysongelmia.
Suorituskykytestaus suorituskykyongelmia.
Tietoturvatestaus tietoturvaongelmia.
Jne…
Ohjelmistotekniikka
292(504)
9.11 Mitä ohjelmalla pitää tehdä?
• Skenaariotestaus: testataan testitapauksilla, jotka on johdettu
käyttötapauksista (use case) tai käyttäjätarinoista
• Liiketoimintaprosessin testaus. Testataan
liiketoimintaprosessia mielellään päästä päähän (end to end testaus)
• Käytettävyystestauksessa voidaan suorittaa suoraan käyttöön
liittyviä toiminnallisia skenaarioita (testitapauksia laajempia)
• Olennaista on testata koko ohjelman elinkaari
–
–
–
–
Asennus
Käyttö – normaali käyttö, ylläpito, varmuuskopiointi
Päivitys
Käytöstä poisto
Ohjelmistotekniikka
293(504)
9.12 Asennustestaus
• Asennus on ollut perinteinen ongelma-alue
– Nykyisin se tulee vastaan myös päivitysten ja jatkuvan
tuotantoonsiirron kautta
• Asenna ohjelmisto eri tavoilla ja eri ympäristöihin
i
– Tarkasta mitkä tiedostot lisätään ja mitkä muuttuvat levyllä
– Toimiiko installoitu ohjelma?
– Mitä tapahtuu kun poistat asennuksen?
• Yleisiä ongelmia
– Onnistuminen erilaisilla käyttäjien oikeuksilla – moni ohjelma
edellyttää ihan turhaan admin-oikeuksia asennuksessa
– Jotkut Linux-peräiset ohjelmat eivät pidä, jos
asennushakemiston nimessä on välilyöntejä
– Joskus silläkin on väliä, mille levyasemalle ohjelman asentaa
Ohjelmistotekniikka
294(504)
9.13 Suorituskyky- ja kuormitustestaus
1/3
• Suorituskykytestaus: testataan
– Täyttääkö systeemi suorituskykyvaatimuksensa
– Kuinka nopeasti ohjelma toimii, jotta voidaan tarvittaessa
optimoida
– Ongelmia voi löytää, jos vertailee keskenään saman testiajon
käyttämää aikaa eri kertoina
– Mikäli suorituskyky yllättäen huononee, on syytä epäillä virhettä
• Virhe voi tällöin löytyä myös kolmannen osapuolen koodista
• Esim. jos kyseessä on Java-ohjelma, voi äkillinen
suorituskyvyn heikkeneminen kertoa myös virtuaalikoneen
uuden version ongelmista
• Nettipalveluille tehdään yhdessä kuormitustestauksen kanssa.
Ohjelmistotekniikka
295(504)
Suorituskyky- ja kuormitustestaus 2/3
• Kuormitustestaus: kuormitetaan
ohjelmistoa siten, että se tarvitsee
paljon resursseja (paljon työtä,
vähän aikaa)
– Tämä johtaa luultavasti häiriöön, jonka
syiden penkominen saattaa johtaa
sellaisten heikkouksien tunnistamiseen,
jotka ovat relevantteja myös
normaalikäytössä
Sovelluspalvelin 2
Sovelluspalvelin 1
Tietoliikenn
e-yhteys
• Stressitestaus: lisätään kuormaa
vähitellen, kunnes ilmenee häiriö
(esim. vasteajat kasvavat sallittua
pidemmiksi) – milloin palvelu ei
enää toimi?
Ohjelmistotekniikka
Tietokanta
-palvelin 1
Käyttäjät
ja clientit
296(504)
• Testaukset tärkeää aloittaa hyvissä ajoin, jotta voidaan parantaa
suorituskykyä systeemin suunnittelulla – tai varautua
palvelinhankintoihin
• Nettipalvelujen testaus tehdään kuormitustestausohjelmilla, kuten
JMeter, joilla luodaan yhteen tai useampaan tietokoneeseen joukko
virtuaalisia käyttäjiä tekemään tyypillisiä asioita
• Ei etsitä toiminnallisia virheitä ja sellaiset eivät saa keskeyttää tätä
testausta
– Käytetään siis yksinkertaisia skriptejä, jotka on testattu toimiviksi ja jotka
eivät mene koko ajan rikki järjestelmän kehittyessä
• Lisätietoa ks. Vuoren kalvosarja osoitteessa
http://www.mattivuori.net/julkaisuluettelo/liitteet/suorituskykytestaus.
pdf
Ohjelmistotekniikka
297(504)
• Nettipalvelun testausprosessi pähkinänkuoressa:
• Valmistaudu, mallinna ja suunnittele
– Perusta pieni tiimi miettimään, miten testaus tehdään.
– Palkkaa expertti tekemään ensimmäinen testaus – ja opi, miten se
tehdään.
– Selvitä suorituskykyvaatimukset: montako yhtäaikaista käyttäjää,
vasteajat, jne… Analysoi miten realistisia vaatimukset ovat. Millainen
olisi pahin tilanne?
– Mallinna käyttäjien toimintaa (käyttöprofiili). Tunnista hetket, jolloin
palvelulla on paljon käyttäjiä (esim. perjantain viimeinen työtunti jollain
sovelluksilla).
– Tunnista kriittiset / edustavimmat käyttötapaukset – jokin kokonainen
tehtävä, vaikkapa tilauksen tekeminen.
– Tee testauksessa käytettävistä komponenteista luotettavia – testaus ei
saa keskeytyä toiminnallisiin virheisiin.
Ohjelmistotekniikka
298(504)
•
Rakenna testijärjestelmä
– Rakenna testijärjestelmä, joka vastaa tuotantoa "täysin".
– Jos et voi tehdä täysin vastaavaa, käytä matematiikkaa selvittämään vastaavuus
(esim. palvelinten määrä ja nopeus). Mieti muista eroja ja niiden vaikutuksia
suorituskykyyn. Voit muunnella järjestelmän konfiguraatiota "suorituskykymallin"
luomiseksi.
– Valitse hyvä suorituskykytestaustyökalu, jolla luot kylliksi virtuaalisia käyttäjiä ja
ajat testejä useasta työasemasta (jopa vain yksi työasema voi joskus simuloida
muutamaa sataa käyttäjää).
– Jos käyttöliittymäkerros on tarpeen ohittaa testeissä, analysoi ja testaa mikä on
sen vaikutus.
– Automatisoi ympäristön luontia, jotta voit jatkossa vain nappia painamalla ajaa
testejä silloin tällöin – uusille buildeille, jos palvelimet vaihtuvat jne…
– Aja ensimmäiset testi niin varhain kehityksessä kuin mahdollista, jotta ehdit
muuttaa niiden perusteella arkkitehtuuria, jos on tarvetta.
Ohjelmistotekniikka
299(504)
•
Asenna testiympäristö:
–
–
–
–
•
Käynnistä monitorointi palvelimilla, jotta voit tarkkailla mitä kuormitettaessa tapahtuu.
Käytä realistista dataa ja realistisen suuria tietokantjoa – mutta älä tuotantodataa.
Tarkista toisen kerran, että testiympäristö ei liity tuotantojärjestelmiin ja niiden dataan, joka
voisi vaarantua testeissä.
Aja testipalvelimilla samat muut prosessit ja muu kuorma kuin tuotantoympäristössä.
Aja testit
–
–
–
–
–
–
–
Käynnistä testit ja lisää kuormaa vähitellen ja tarkkaile, miten järjestelmä käyttäytyy.
Seuraa mittareita. Esim. prosessorin käyttöaste ei yleensä saa nousta yli 60%
Käytä järjestelmää samaan aikaan manuaalisesti.
Selvitä suorituskykyvaatimusten täyttyminen.
Lisää kuormaa, jotta näet miten järjestelmä toimii tosisuurella kuormalla. Se ei saa kaatua.
Simuloi palvelunestohyökkäystä.
Toista testit muutaman kerran.
Ohjelmistotekniikka
300(504)
•
Analysoi
– Analysoi testissä kerättyä informaatiota tiimin kanssa.
– Mieti, missä pullonkaulat todella ovat ja mitä niille voi tehdä.
– Jos datassa näkyy outoja asioita, yritä eristää ilmiö ja tutki sitä erityisillä testeillä
tarkemmin.
Ohjelmistotekniikka
301(504)
9.14 Luotettavuustestaus
• Luotettavuustestaus: pitkäkestoinen testi, jonka tarkoituksena
on paljastaa vikoja, jotka jäävät nopeissa testeissä helposti
huomaamatta
– Esim. karanneet osoittimet, muistivuodot, pinon ylivuodot yms.
– Ajetaan testiä jopa useita päiviä
• Yleensä kehittelyn loppuvaiheessa systeemiä kypsytettäessä
• Tärkeää erilaisille alustoille, joilla laaja käyttäjäkunta
– Esim. puhelimen käyttöjärjestelmä ja perussovellukset
• Mallipohjainen testaus soveltuu hyvin ohjaamaan tällaista
testausta, koska se tuo ajoon koko ajan vaihtelua
(mallipohjaisesta testauksesta kerrotaan myöhemmin…)
Ohjelmistotekniikka
302(504)
9.15 Regressiotestaus 1/3
• Regressiotestaus: uudelleenkäytetään testitapauksia ja
testataan niitä käyttäen muutosten jälkeen uudelleen
– Kun jotain muutetaan, kaikenlaista voi hajota
– "Kun yhden asian korjaa, kaksi muuta menee rikki"
• Englanniksi ”regress” = taantua
• Käytännössä eräs tärkeimmistä ja käytetyimmistä
menettelyistä
• Tehdään kaikilla testaustasoilla
• Voidaan tehdä manuaalisesti tai testiautomaatiolla tai
molemmilla
• Perinteisin testiautomaation sovellus
Ohjelmistotekniikka
303(504)
Regressiotestaus 2/3
• Mitä testataan?
– Mihin kaikkeen muutos voi vaikuttaa? Analysoidaan koodia.
Ollaan realisteja: muutos voi usein vaikuttaa minne tahansa…
– Joskus on käytössä vakio regressiotestisetti, jota sitten
tapauskohtaisesti täydennetään, myös tutkivalla testauksella
– Kaksi strategiaa: 1) mahdollisimman samalla tavalla aina (eli
testitapauksilla, jotka ovat menneet ennen läpi monta kertaa) tai
2) miksei vähän eri testitapauksilla, niin voidaan saada kiinni
uusia bugeja 3) kompromissi: jotkut asiat, jotka on "pakko
tarkistaa", ajetaan perussetillä, mutta sen päälle mietitään testit
tapauskohtaisesti
Ohjelmistotekniikka
304(504)
Regressiotestaus 3/3
• Muutamia tapoja
– Integrointitestauksessa automaattiset testit tarkistavat jonkin
komponentin muutoksen jälkeen, että muut komponentit toimivat
ok. Testit on kehitetty toteutuksen aikaisessa testauksessa.
– Tietojärjestelmän muutosten jälkeen ajetaan automatisoituja
käyttöliittymätestejä useimmille toiminnoille. Testit on erityisesti
koodattu tätä varten, kun järjestelmä on stabiloitunut.
– Muutosten jälkeen tehdään regressiotestaus manuaalisesti
tutkivalla testauksella.
• Ongelmia
– Manuaalisesti tehtynä voi olla tylsää työtä
– Automaattitesteillä on aina ylläpito-ongelma
Ohjelmistotekniikka
305(504)
9.16 Savutestaus 1/2
• Savutestaus (smoke testing): tarkoituksena on testata, onko
ohjelmiston uusi versio (esim. uusi buildi) riittävän toimiva
testattavaksi kunnolla
– Jos se kaatuu koko ajan, ei testaamisesta tule mitään
• Useimmiten automatisoitu ja standardoitu testi, jolla testataan
perustoiminnallisuutta, jonka voi olettaa toimivan
• Keskitytään laajuuteen eikä syvyyteen
– Esim. mikäli buildiin on linkitetty väärä tiedosto, voi virheen
löytää savutestin avulla nopeasti
• Tarkoituksena ei siis varsinaisesti ole virheiden löytyminen
• Kannattaa suunnitella yhteistyössä kehittäjien kanssa
Ohjelmistotekniikka
306(504)
Savutestaus 2/2
• Testitapaukset yleensä osajoukko regressiotestauksessa
käytetyistä
• Savutestin voi tehdä joko kehittäjä tai testaaja
• Tärkeää on tehdä se samanlaisessa ympäristössä kuin missä
sen jälkeiset testit ajetaan
• Mikäli vain mahdollista, savutestit kannattaa automatisoida,
koska ne joudutaan yleensä toistamaan usein
– Se on realistista, koska kyse on yksinkertaisista perustesteistä
Ohjelmistotekniikka
307(504)
9.17 Mistä tiedetään onnistuiko testiajo
vai ei?
• Evaluation-based
• Vertaaminen spesifikaatioon tai muuhun auktoriteettiin
– Mikäli eroja löytyy, kyseessä on luultavasti häiriö
• Vertaaminen talletettujen tulosten kanssa
– Verrataan esim. regressiotestauksessa tuloksia edellisen
ajokerran tuloksiin
– Jos edelliset olivat oikeita, ja nyt saatiin eri tulos, saattaa
kyseessä olla häiriö
Ohjelmistotekniikka
308(504)
9.18 Heuristinen johdonmukaisuus
• Ohjelman pitäisi toimia…
– Samoin kuin ennenkin
– Kuten muiden ohjelmien vastaavassa tilanteessa
– Kuten ihmiset sanovat sen toimivan (ohjelman pitäisi toimia
kuten me luulemme käyttäjien haluavan sen toimivan)
– Sisäisesti johdonmukaisesti, esim. virheenkäsittely on toteutettu
samantyyppisissä funktioissa samalla tavalla
– Kuten sen ilmeinen tarkoitus vaatii
• Mikäli jossakin em. kohdassa havaitaan
epäjohdonmukaisuutta, voi kyseessä olla häiriö tai sitten
tietoinen suunnittelupäätös
Ohjelmistotekniikka
309(504)
Oraakkelin käsite
i
• Oraakkeli on termi mekanismille, jolla todetaan, onko testi
läpäisty vai ei – eli se tapa, jolla saadaan selville oliko testissä
havaittu käyttäytyminen ok vai ei
– Termi tulee Delfoin oraakkelista
http://fi.wikipedia.org/wiki/Delfoin_oraakkeli
• Käytännössä oraakkeli voi olla esim.
–
–
–
–
Järjestelmän aikaisempi ja luotettavaksi havaittu versio
Toinen algoritmi
Toinen ohjelma tai vaikka pilvipalvelu
Asiantunteva käyttäjä (joka tuntee bisnessäännöt)
• Mikään oraakkeli ei ole täydellinen…
Ohjelmistotekniikka
310(504)
10. Virheraportoinnista
Virheraportointi (tai
vikaraportointi) on käytännössä
tärkein kommunikaation muoto
testaajien ja kehittäjien välillä.
Vaikka tavoitteet ovat yleensä
selkeitä, ei toimivaa raportointia
ole kuitenkaan helppo toteuttaa.
Ohjelmistotekniikka
311(504)
10.1 Virheraportti jakaa tietoa
• Mukailtu lähteestä Cem Kaner, ”Bug Advocacy”, Quality Week
2002.
• Massamarkkinoille suunnattujen ohjelmistojen tapauksessa
suurin osa käyttäjien löytämistä virheistä on itse asiassa jo
löydetty varsinaisessa testauksessa – miksi niitä ei ole
korjattu?
• Virheraportti on väline, jolla testaajan on tarkoitus saada
organisaatio vakuuttuneeksi siitä, että löytyneen vian
korjaamiseen kannattaa käyttää aikaa ja rahaa
Ohjelmistotekniikka
312(504)
Ongelma täytyy "myydä" kehittäjille
• Jos testauksen tarkoitus on löytää virheitä, silloin virheraportit
ovat testaajan ensisijainen tuotos
– Ne ovat tuloksia, jotka testauksesta näkyvät ulkopuolelle ja
joiden perusteella testaajat muistetaan
– Paras testaaja ei ole se, joka löytää eniten virheitä, vaan se, joka
saa eniten virheitä korjatuksi
• Koska aikaa ei ikinä ole tarpeeksi, testaajan täytyy ”myydä”
ongelma kehittäjälle, jotta tämä käyttäisi aikaansa sen
korjaamiseen
• Myyminen perustuu kahteen tavoitteeseen
– Kehittäjä täytyy saada haluamaan korjata vika
– Kehittäjän vastalauseet ja selitykset, miksi vikaa ei tarvitse
korjata, täytyy pystyä kumoamaan
Ohjelmistotekniikka
313(504)
Mitkä seikat saavat kehittäjän
haluamaan korjata vian?
•
•
•
•
•
Vian aiheuttama virhe / ongelma näyttää tosi pahalta
Vika näyttää mielenkiintoiselta ongelmalta
Se vaikuttaa moniin ihmisiin
Sen toistaminen on triviaalia
Se saattaa meidät noloon tilanteeseen, tai vastaava bugi on
saattanut kilpailijan noloon tilanteeseen
• Johto haluaa, että vika korjataan
• Ohjelmoija haluaa tehdä testaajalle palveluksen yms.
henkilökohtaiset syyt
• Vetoaminen ammattitaitoon tms.
Ohjelmistotekniikka
314(504)
Mikä saa kehittäjän vastustelemaan
vian korjaamista? 1/2
• Kehittäjä ei saa virhettä toistettua
• Bugin toistaminen vaatii erikoista temppuilua
• Toistaminen ei ole mahdollista näillä tiedoilla ja lisätietojen
kaivaminen vaatii paljon työtä
• Kehittäjä ei ymmärrä virheraporttia
• Epärealistinen bugi
• Korjaaminen vaatii paljon työtä
• Korjaaminen on riskialtista
• Ei nähtävissä olevaa vaikutusta käyttäjille
• Ei tärkeä; kukaan ei välitä, jos tämä ei toimi
Ohjelmistotekniikka
315(504)
Mikä saa kehittäjän vastustelemaan
vian korjaamista? 2/2
• Kyseessä ei ole vika vaan ominaisuus
• Johto ei välitä tämän kaltaisista ongelmista
• Kehittäjä ei pidä testaajasta tai ei luota häneen tms.
henkilökohtaiset syyt
Ohjelmistotekniikka
316(504)
Kuinka motivoida vian korjaamiseen?
• Kun testaaja huomaa häiriön, on kyseessä oire, itse virhe on
vielä paljastamatta
• Kenties havaittu häiriö ei ole paras mahdollinen esimerkki ko.
virheen aiheuttamista häiriöistä
• Siksi täytyy tehdä lisää töitä ennen virheraportin kirjoittamista
sen osoittamiseksi, että virhe on vakavampi ja yleisempi kuin
miltä ensisilmäyksellä näyttää
Ohjelmistotekniikka
317(504)
Vakavuuden selvittäminen
• Kun testaaja on löytänyt häiriön, on ohjelmisto saatu
haavoittuvaan tilaan
• Jatkamalla testausta tässä tilassa, voidaan selvittää vian
todellinen vakavuus
– Vaihtelemalla kontrollia (ensin A, sitten B tai toisin päin)
– Vaihtelemalla optioiden ja asetusten arvoja
– Vaihtelemalla ohjelmistoja laitteistokonfiguraatiota
Ohjelmistotekniikka
318(504)
Onko kyseessä uusi vai vanha vika?
• Jos kyseessä on vanha vika, sen korjaamiseen ei olla
motivoituneita, ellei se ole aiheuttanut valituksia asiakkailta
• Uusiin vikoihin suhtaudutaan vakavammin
• Jos kyseessä on vanha vika, voi yrittää löytää uusia tapoja,
joilla häiriö esiintyy ohjelmiston uudessa versiossa
– Kyse on tällöin uudesta ongelmasta
• Em. kohdat korostuvat erityisesti ohjelmiston
ylläpitovaiheessa, kun uuden version tarkoituksena on vain
korjata kriittisimpiä virheitä
• Jos vikatietokantaa ”siivotaan” aika ajoin, voi tärkeää tietoa
kadota
Ohjelmistotekniikka
319(504)
Yleisyyden selvittäminen
• Etsi riippuvuuksia konfiguraatioista
– Jos häiriötä ei saada toistetuksi kehittäjän ympäristössä, on
motivointi vian korjaamiseksi hankalaa
– Virheraportin täytyy kertoa ne ympäristöt, joissa häiriö ilmenee
• Yritä yleistää ääritapaukset
– Raja-arvoanalyysi auttaa häiriön etsimisessä
– Negatiivinen testaus, virheelliset syötteet
– Kun vika on löytynyt, ei tarvitse enää tyytyä raja-arvoihin
Ohjelmistotekniikka
320(504)
10.2 Voiko virheen toistaa?
• Testaajan pitäisi raportoida myös sellaiset virheet, joita ei saa
toistetuksi
– Jos raportti on riittävän tarkka, ohjelmoija voi sen perusteella
selvittää virheen olinpaikan
– Kun huomaat, että et saa virhettä toistetuksi, kirjoita ylös heti
kaikki mitä siitä muistat
• Jos olet epävarma siitä mitä teit, sano se virheraportissa
– Kannattaa kirjata myös se, mitä teit ennen kuin huomasit häiriön
– Tarkasta vikatietokannasta, löytyisikö sieltä jotain vastaavaa
– Yritä muuttaa ohjelman ajoitusta hitaammaksi ja nopeammaksi
– Juttele ohjelmoijan kanssa ja/tai lue koodia
– Virhe, jota ei saada toistetuksi on testaajan virhe, kannattaa
yrittää ottaa opikseen
Ohjelmistotekniikka
321(504)
10.3 Hyvän virheraportin resepti
• Selkeä, kuvaava otsikko auttaa löytämään raportin bugikannasta
• Selosta kuinka häiriön saa toistettua, sisällytä kaikki askeleet
• Kuvaile, mitkä askeleet ovat ja mitkä eivät ole tärkeitä ongelman
kannalta, ja miten tulokset vaihtelivat eri testiajoissa
• Analysoi ongelmaa ja kerro, miten se voidaan toistaa pienimmällä
määrällä askelia
• Raportin pitää olla helposti ymmärrettävä
• Sävyn pitää olla neutraali
• Vain yksi virhe per raportti
• Jos toistamiseen tarvitaan tiedosto, liitä se raporttiin tai kerro mistä
se löytyy
– Nykyään suositaan kuvaruutukaappauksia, koska levytila on halpaa
Ohjelmistotekniikka
322(504)
Virheraporttipohja 1/4
Tyypillisiä
raporttilomakkeissa olevia
asioita – mutta nämä
vaihtelevat
• ID, raportin yksilöivä numero
• Otsikko
– Kuvaa ongelman yhdellä rivillä
– Virheraportin tärkein kenttä
• Johto lukee tämän kun haluaa tietää mitkä ongelmat ovat vielä
korjaamatta
• Ongelman kuvaus
– Pidempi kuvaus (kuvia liitteeksi)
•
•
•
•
•
Kuka raportoi
Raportin luontipäivä
Ohjelman tai komponentin nimi
Julkistuksen ja version numero
Testikonfiguraatio(t)
Ohjelmistotekniikka
323(504)
• Raportin tyyppi
– Ohjelmointivirhe, suunnitteluvirhe, dokumentoinnin
vastaamattomuus, ehdotus, kysymys
• Voiko toistaa
– kyllä, ei, joskus, en tiedä: jos testaaja väittää, että virhe voidaan
toistaa ja ohjelmoija on toista mieltä, testaaja joutuu toistamaan
virheen ohjelmoijan silmien edessä
• Vakavuus
– Miten paljon haittaa käyttöä
• Prioriteetti (korjaamiselle)
– Projektipäällikkö / error manager tms. täyttää
• Vaikutus asiakkaisiin
– Esim. tekninen tuki täyttää
Ohjelmistotekniikka
324(504)
• Avainsanat
• Ongelman kuvaus ja toistaminen
– Askel askeleelta
• Suositeltu korjaus
• Kuka selvittää
– Projektipäällikkö täyttää
• Status
– Testaaja täyttää: avoin, suljettu, roskis
• Päätös
– Projektipäällikkö omistaa tämän kentän
– Odottaa, korjattu, ei voida toistaa, lykätty korjausta, toimii kuten
suunniteltu, tarvitaan lisää tietoa, duplikaatti, vedetty pois tms.
Ohjelmistotekniikka
325(504)
• Päätöstä vastaavan buildin versionumero
• Päätöksen tekijä
– Ohjelmoija, projektipäällikkö, error manager, testaaja
• Päätöksen testaaja
– Jos testaaja löytää virheen, hän myös testaa korjauksen
• Virheraportin versiohistoria
• Vapaamuotoiset kommentit
– Muista neutraali sävy
Ohjelmistotekniikka
326(504)
10.4 Vikatietokannat
• Viat raportoidaan yleensä reaaliaikaiseen vikatietokantaan
• Siellä ne voidaan osoittaa jollekin kehittäjälle tai tiimille
• Tilannetta päivitetään, kun vikaa käsitellään ja korjataan ja
lopulta vika voidaan "sulkea"
• Tunnettuja systeemejä ovat mm.
– Bugzilla
– Mantis
– Jira
• Virhetilannetta seurataan koko ajan ja tilastoidaan
– Ohjelmissa on hyvät raportointitoiminnot
Ohjelmistotekniikka
327(504)
Esimerkki Mantisin lomakkeesta
Ohjelmistotekniikka
328(504)
11. Ohjelmistojen mittaaminen
Ohjelmistoprojekteissa mikään ei ole pysyvää
paitsi muutos. Mittausten avulla voidaan tehdä
sivistyneitä arvauksia projektin nykytilasta sekä
siitä, mitä pitäisi muuttaa ja mihin suuntaan.
Toisaalta tuotemittarit voivat auttaa
kohdistamaan testausta virheherkimpiin osiin.
Ohjelmistotekniikka
329(504)
11.1 Mittarit 1/2
• Pääasiallinen lähde [Haikala&Märijärvi 06]
• Mitä halutaan mitata, minkälaista tietoa kaivataan?
• Tarvitaanko tuotemittareita, projektimittareita, vai molempia?
Vai halutaanko mitata jotain muuta?
– Mitä enemmän sen parempi?
• Joitain suureita ei voida mitata tarkasti, kuten jäljellä olevien
vikojen määrää, mutta arvioita voidaan antaa
– Jos jäljellä olevien vikojen määrä voitaisiin laskea, ne olisi
luultavasti helppo myös poistaa
– Toiset arviot ovat parempia kuin toiset
Ohjelmistotekniikka
330(504)
Mittarit 2/2
• Mittauksessa törmätään yleensä asenneongelmiin
– Ohjelmistoprojekteissa on aina vaarana, että mittaaminen
kohdistuu suoraan henkilöön ja tämän suoritukseen
– Mittaustulosten hyödyntämistapa pitäisi tehdä kaikille selväksi
• Mittaamista on perinteisesti hyödynnetty testauksessa varsin
laajasti
– Testikattavuus
– Testien kohdistaminen virheherkimpiin osiin ohjelmistoa
• Koodi, joka on monimutkaista on yleensä myös virheherkkää
– Osat, joiden luotettavuusvaatimukset ovat korkeat
Ohjelmistotekniikka
331(504)
Aloita yksinkertaisilla mittareilla
• Aloita testauksen mittaaminen yksinkertaisilla mittareilla, jotka
vaikuttavat luotettavilta, ja kokoa ne mittarijoukoksi
– Jos on esimerkiksi mahdollista mitata vaatimusten kattavuutta,
se voi olla hyvä alkupiste
– Kokoelma toisiaan täydentäviä vaatimuksiin ja spesifikaatioihin
sekä kooditason kattavuuteen pohjautuvia mittareita voi olla
hyödyllinen
– Sen sijaan, että tuijotettaisiin pieniin muutoksiin mitatuissa
arvoissa, kiinnostavampia ovat suuret muutokset ja trendit
(tulemmeko paremmiksi vai huonommiksi)
– Hopealuotia ei ole mittauksessakaan
– Muuta mittarijoukkoa pienin askelin, yritä pysyä perillä
muutosten vaikutuksista
Ohjelmistotekniikka
332(504)
Mittarit vs. riskit
• Onko mittarijoukolla ja tuotteen tai projektin riskeillä jokin
yhteys?
– Testaa mittarijoukkoa keksimällä skenaarioita, joissa jokin tärkeä
riski realisoituu tuotteessa tai projektissa nähdäksesi
havaitsevatko mittarit sen selvästi
– Jos ei, voisiko mittarijoukkoa parantaa huomaamaan tällaisia
ongelmia?
• Älä luota mittareihin, jotka ovat olleet usein väärässä: mitä
onnistuneiden ja epäonnistuneiden testien suhde oikeastaan
kertoo?
• Voisiko tätä tietoa täydentää esimerkiksi jollakin
vaatimuksiin/spesifikaatioihin/koodikattavuuteen liittyvillä
mittareilla?
Ohjelmistotekniikka
333(504)
Mittaamisen huolellinen suunnittelu
• Isoissa projekteissa/organisaatioissa tarvitaan usein
mittaussuunnitelmaa:
–
–
–
–
–
–
Miksi mitaan
Mitä mitataan
Ketkä osallistuvat mittaamiseen
Mitä osia järjestelmästä mitataan
Koska mitataan
Kuinka tiedot kerätään ja analysoidaan
Ohjelmistotekniikka
334(504)
Vaatimuksia mittareille 1/2
• Mittaamisen tulosten merkitys liiketoiminnalle
– Peruste mittaamiselle
– Yhteinen käsitys siitä, miksi tietoa kerätään ja miten sitä voidaan
hyödyntää ja tullaan hyödyntämään
• Käyttöönoton helppous
– Tarvitaanko käyttöönottoprojekti
• Ymmärrettävyys
– Syyt muuttuville arvoille
• Selektiivisyys
– Tulokset kohdennettavissa mittauksen kohteeseen
• Jos mittarin arvo muuttuu, tiedetään mikä muuttuu mittauksen
kohteessa
Ohjelmistotekniikka
335(504)
Vaatimuksia mittareille 2/2
• Objektiivisuus
– Tulokset eivät riipu mittaajasta tai mittaustilanteesta
• Luotettavuus
– Tarkkuus, toistettavuus, mittaria ei käytetä vahingossa väärin
• Taloudellisuus
– Mittauksen kustannukset suhteessa saavutettuun hyötyyn
• Uudelleenkäytettävyys
Ohjelmistotekniikka
336(504)
Laadun mittareita – aluksi lyhyt lista
esimerkkejä
• Avointen vikojen määrä
– Kaikki viat
– Vakavien vikojen määrä – estävät tai erityisesti haittaavat
• Koekäyttäjien tyytyväisyys
• Laadullinen mittari
• Parannus edelliseen versioon
• Vertailu kilpailijaan
• Kehitystiimin tyytyväisyys
• Laadullinen mittari
• Testaajien tyytyväisyys
– Laadullinen mittari
Ohjelmistotekniikka
337(504)
Testitapausten määrä mittarina
• Oikeasti testitapausten määrä ei kerro mitään.
• Ja siten ei myöskään niiden läpäisy – "läpäisty 5000
testitapausta"
• Syy: olennaista on testien laatu ja kun tarkastellaan liikaa
määriä, on vaara, että suuri osa testitapauksista on aivan
triviaaleja.
• Parempi on katsella ohjelmassa olevien virheiden määriä ja
luonnetta.
– Eri vakavuusasteet.
• Testitapausten suoritusten määrä on enemmän työprosessiin
liittyvä asia: miten sovittu ja odotettu testaustyö etenee
• Tutkivassa testauksessa ei edes ole "testitapauksia"
Ohjelmistotekniikka
338(504)
Perinteinen testauksen eteneminen
• Isoissa projekteissa, joissa pitkä järjestelmätestausvaihe
[Rothman 07]
Ohjelmistotekniikka
339(504)
S-käyrä kertoo kypsymisestä
• Virheiden seuranta
alusta asti on tärkeää
• Esimerkki
järjestelmätestauksen
virhekäyrästä
[Haikala&Märijärvi 06]:
• Aletaan miettiä
julkistusta, kun käyrä
tasaantuu
• Tasaantumisen
saavuttamiseen
tarvittavia resursseja on
valitettavasti vaikea
arvioida etukäteen
Ohjelmistotekniikka
340(504)
Toinen käyrä samasta asiasta – kumpi viestii
positiivisemmin?
• Toinen tapa kuvata asiaa – viesti kenties selkeämpi [Rothman
07]
Ohjelmistotekniikka
341(504)
Kypsyyden mittareista lisää
• Edellä oli S-käyrä esimerkkinä kypsymisen seuraamisesta
• Käyrä antaa implisiittisen vihjeen, että virheitä pitäisi alkaa
löytymään vähemmän
• Miksi seurata löydettyjen ja korjattujen absoluuttista määrää?
• Miksei seurata avoinna olevien virheiden määrää?
• Entä virheiden löytymisen tahti (montako per päivä)?
• Vaihtoehtoja mittareiksi on monia, eikä pidä koskaan
hyväksyä ensimmäistä tarjottua
• Testaajien fiilis on tärkeä ja joskus paras mittari: miltä softa
tuntuu, onko se kypsynyt ja alkaako se olla julkaisukunnossa
Ohjelmistotekniikka
342(504)
Suorat ja johdetut mittarit
• Perusmittarit: suoritetut testit, löytyneet virheet, kattavuus
suhteessa vaatimuksiin/spesifikaatioihin, koodikattavuus,
koko, mutkikkuus, käytetty työmäärä, jne.
• Johdetut mittarit: virhetiheys, onnistuneiden ja
epäonnistuneiden virhekorjausten suhde, löydettyjen
virheiden määrän suhde niiden virheiden määrään, jotka olisi
voitu löytää, jne.
• Prosessisidonnaiset mittarit: testien suoritusnopeus,
automatisointiaste, virheiden elinaika päivissä, testaukseen
suunnitteluun kulunut työmäärä, laatuvelka ketterässä
projektissa, jne.
• Yleisesti ottaen ongelma ei ole mittareiden keksiminen, koska
niitä on jo tarpeeksi; ongelma on valita sopivat mittarit
Ohjelmistotekniikka
343(504)
11.2 Ei-toiminnallinen testaus
• Kuinka mitata ei-toiminnallista testausta?
• Suorituskykytestauksessa mittaus voi olla on/off – jos
vaatimukset täyttyvät, tilanne on ok, eikä muutu, ellei softaa
kehitettäessä saada sitä hidastumaan.
• Käytettävyystestauksessa vähän eri tavalla – kypsyminen on
sitä, että katsotaan, miten työlistalla olevat parannukset
saadaan tehtyä ja onko vielä julkaisemista estäviä puutteita.
– Pienet kosmeettiset asiat eivät haittaa.
– Mitataan kenties puutteiden sijaan testihenkilöiden tyytyväisyyttä
eri testauskierroksilla.
• Jne…
Ohjelmistotekniikka
344(504)
11.3 Sitä saa mitä mittaa! – Kuinka
mittareita huijataan
• Johto saa sitä mitä mittaa
– 100% koodikattavuuden saavuttaa helpommin kun jättää testien
tulokset huomioimatta
– Automatisoinnin astetta voi kasvattaa hankkiutumalla eroon
manuaalisesta testauksesta
– Tehokkaaksi testaajaksi pääsee kunhan käy muuttamassa itse
lähdekoodia ja löytämällä itse tekemänsä virheet seuraavana
päivänä
– Jos on painetta löytää virheitä, ei panosteta niiden
ennaltaehkäisyyn
– Jos ei haluta löytää virheitä, niitä löydetään vähemmän
• Jos mittareihin on yhdistetty palkitsemista, kiusaus niiden
huijaamiseen voi nousta ongelmaksi
Ohjelmistotekniikka
345(504)
11.4 Järjestelmätason kattavuusmitat
1/2
• Perinteiset mittarit:
– Vaatimuskattavuus – kuinka hyvin eri vaatimukset on saatu
katettua
• Mille prosenttiosuudelle vaatimuksista on testejä?
• Kattavuus suhteessa vaatimusten tärkeyteen
– Toiminnallinen kattavuus
• Liitetään testit ohjelman toimintoihin, jopa käyttöliittymän
toimintoihin
– Kattavuus eri yksiköiden suhteen
• Komponentit, moduulit, yms.
Ohjelmistotekniikka
346(504)
Järjestelmätason kattavuusmitat 2/2
• Muita vaihtoehtoja
– Riskikattavuus
• Kuinka tuotteen riskit on testauksessa otettu huomioon,
erityisesti isojen riskien osalta
– Riskikattavuus suhteessa vaatimuksiin/toimintoihin
– Kattavuus sen suhteen mikä on tärkeää eri käyttäjäryhmille
• 70 % yrityskäyttäjille tärkeistä vaatimuksista on katettu, 83 %
kotikäyttäjille tärkeistä
– Käyttöskenaario- / käyttötapaus- / tarinakattavuus
• Tällä tasolla käytettävät kattavuusmittarit riippuvat
käytettävästä prosessista – V-malli vai ketterä prosessi
Ohjelmistotekniikka
347(504)
11.5 Koodin kattavuusmitat
• Koodikattavuuden avulla voidaan päätellä, että vielä ei olla
testattu riittävästi
– Sen päätteleminen, että on testattu tarpeeksi, on sitten toinen
asia
– 100 % koodikattavuus ei yleensä takaa vielä yhtään mitään
• Koodikattavuutta seurataan yleensä yksikkötestauksessa
• Kattavuusmittaus vaatii ohjelman instrumentointia, hidastaa
sitä ja voi piilottaa koodin vikoja
• Vaikka järjestelmätason testaajien ei tarvitse huolehtia
kooditason kattavuudesta, on hyvä tietää mitä hyviä ja
huonoja puolia kehittäjien käyttämissä mittareissa on
Ohjelmistotekniikka
348(504)
Yleistä koodin kattavuusmitoista
• Hyvää yksikkötestausta täytyy vaatia ohjelmointitiimeiltä ja
alihankkijoilta
– Testien laatuun panostaminen on parempi strategia kuin vain
mittareiden tuijottaminen
• Lisäksi testit ovat vain yksi laadunvarmistuksen keino:
koodikatselmoinnit, staattinen analyysi, jne. ovat myös
tärkeitä
• Yksikkötason mittaustiedot saadaan automaattisesti
työkaluilta, jotka on integroitu yksikkötestaukseen ja/tai
matalan tason integrointitestaukseen
– Näitä on helppo käyttää vaatimuksina seuraavaan vaiheeseen
siirtymiselle (laatuportit)
Ohjelmistotekniikka
349(504)
Miksi liiallinen koodikattavuuteen
keskittyminen on vaarallista 1/2
• Kun omaa koodia kehitetään järkevästi, sen määrä
minimoidaan ja suurin työ tehdään kirjastoissa.
• Silloin oma kattavuusmittaus ei kerro mitään:
sometype MyFunction(optional String myString) {
return LibraryFunction(myString);
}
• Kun testi käy return-rivillä, kaikki mahdollinen on selvästi
testattu. Vai onko? Miten käyttäytyy LibraryFunction() kaikilla
mahdollisilla syötteillä?
Ohjelmistotekniikka
350(504)
Miksi liiallinen koodikattavuuteen
keskittyminen on vaarallista 2/2
• Kattavuusnumeroiden sijaan pitää ensimmäisenä ajatella
hyvien testien tekemistä ja katsella numeroita vain
avustavana infona.
• Erityisesti pitää varoa, että kattavuusmittoja ei pidetä
keskeisinä testausvaatimuksina ja alihankkijan työn
arviointikriteerinä.
• Kannattaa myös muistaa, että joitakin asioita voi testata
paremmin järjestelmätasolla
– Se ratkaisee!
– Silloin ei koodikattavuusmittausta yleensä ole päällä kuin silloin
tällöin.
Ohjelmistotekniikka
351(504)
laske
tulokset
Esimerkin asetelma
alustukset
• Havainnollistetaan erilaisia
kattavuusmittoja esittämällä testattava
ohjelma oheisen kulkukaavion
mukaisella notaatiolla
• Testauksessa ollaan kiinnostuneita
ohjelman käyttäytymisistä, joita
vastaavat eri suorituspolut
• Suorituspolku kuvaa ohjelman kontrollin
kulkua testikohteen alusta sen loppuun
ohjelmaa suoritettaessa
opiskelijoita
jäljellä
laske
arvosanajakauma
kyllä
loppu
hae seuraavan
opiskelijan
tiedot
ei
mukana
tentissä
kyllä
määrää
arvosana
päivitä
opiskelijan
tiedot
Ohjelmistotekniikka
ei
Esimerkki lähteestä
[Haikala&Märijärvi 06]
352(504)
Lausekattavuus
laske
tulokset
• Miten suuri osa lauseista katetaan
testeillä?
• Jos jokainen lause suoritetaan
testiajossa ainakin kerran, on
lausekattavuus 100 %
• Mikäli ohjelmassa on 100 lausetta,
joista testitapaukset suorittavat 63,
sanotaan lausekattavuuden olevan 63
%
alustukset
opiskelijoita
jäljellä
ei
laske
arvosanajakauma
kyllä
loppu
hae seuraavan
opiskelijan
tiedot
ei
mukana
tentissä
kyllä
määrää
arvosana
Ohjelmistotekniikka
päivitä
opiskelijan
tiedot
353(504)
Päätöskattavuus
• Decision coverage / brach coverage
• Kontrollin haarautumiskohdat ovat
avainasemassa testikattavuutta
määriteltäessä
• Päätöskattavuus vaatii, että jokainen päätös
saa testattaessa molemmat arvonsa
• Eli tarkistetaan mm. if-lausekkeet ja
katsotaan, että testitapauksilla käydään
molemmat polut
Ohjelmistotekniikka
a==0 &&
b>0
ei
kyllä
354(504)
Ehtokattavuus
• Condition coverage
• Jatkoa päätöskattavuudelle, mutta nyt
tarkastellaan, miten "osaehtojen" kaikki
mahdolliset totuusarvot käsitellään
testauksessa
• Eli testataanko tilanteet, joissa
–
–
–
–
a==0 &&
b>0
ei
kyllä
a == 0
a != 0
b>0
b <= 0
Ohjelmistotekniikka
355(504)
Moniehtokattavuus
• Multiple condition coverage
• Moniehtokattavuus vaatii, että päätöksen kaikkien ehtojen
molempien arvojen kaikki mahdolliset kombinaatiot tulee
käytyä läpi
• Ei siis riitä, että lausekkeen ehdot testataan, vaan testataan
myös kaikki niiden kombinaatiot, esim. testitapaukset, joissa
–
–
–
–
(a=0, b=0),
(a=1, b=0),
(a=0, b=1) ja
(a=1, b=1)
Ohjelmistotekniikka
356(504)
Polkukattavuus 1/2
•
•
•
•
Path coverage
Miten hyvin testataan kaikki mahdolliset suorituspolut?
Vähemmän käytetty kattavuusmitta
Täysin polkukattava testaus on käytännössä saavuttamaton
tavoite
– Ongelma I: silmukat tekevät polkujen määrän liian suureksi
• Monet ohjelmat on tarkoitettu pyörimään ikuisessa
silmukassa valmiina vastaanottamaan ulkopuolisia ärsykkeitä
=> ääretön määrä suorituspolkuja
• Voidaan saavuttaa vain esim. yhden funktion sisällä
– Ongelma II: kaikki ohjelmakoodia tutkimalla löydetyt polut eivät
ole välttämättä suorituksessa mahdollisia
• Esim. jonkin polun suorittaminen funktion läpi edellyttää
tiettyä parametrin arvoa, jolla ko. funktiota ei ikinä kutsuta
Ohjelmistotekniikka
357(504)
Polkukattavuus 2/2
laske
tulokset
alustukset
• Kuinka monta eri suorituspolkua oheisella
ohjelmalla on?
opiskelijoita
jäljellä
– Toisin sanoen, kuinka monta erilaista tapaa
on päästä alkusolmusta loppusolmuun?
• Jos opiskelijoita on n kappaletta, ja jokaisen
kohdalla on kaksi mahdollisuutta sen
n
mukaan onko osallistunut tenttiin vai ei: 2
• Jos kyseessä olisi 100:n opiskelijan kurssi,
olisi suorituspolkuja 2100
• Jos silmukasta voisi hypätä pois kesken
kaiken, olisi polkuja vielä paljon enemmän:
n
n-1
n-2
1
0
2 +2 +2 +…+2 +2
Ohjelmistotekniikka
ei
laske
arvosanajakauma
kyllä
loppu
hae seuraavan
opiskelijan
tiedot
ei
mukana
tentissä
kyllä
määrää
arvosana
päivitä
opiskelijan
tiedot
358(504)
11.6 Mutkikkuusmitat 1/2
i
• Complexity measure.
• Kertoo koodin laadusta.
– Ylläpidettävyys. Hyvä tarkistaa, kun esimerkiksi ottaa ylläpitoon toisen
yrityksen tuottamaa koodia.
– Herkkyys mennä rikki muutettaessa, lähes itsestään… tai kun käytetään
erilaisia syötteitä ja niiden yhdistelmiä.
– Todennäköisyys, että koodissa on virheitä.
– Siis vahva "haju"…
– Perustuu yleensä koodin rakenteen staattiseen analysointiin työkaluilla.
• Käytännön arjessa ei kiinteä rooli testauksessa, vaan
yleisemmin koodin laadun varmistuksessa eikä sielläkään
kovin laajasti – paitsi kriittisten järjestelmien kehityksessä.
Ohjelmistotekniikka
359(504)
11.7 Mutkikkuusmitat 2/2
i
• Testauksessa idea: kohdistetaan testausta monimutkaisimpiin osiin
koodia, monimutkaisiin komponentteihin – varsinkin alussa, kun ne
tulevat testauksen piiriin.
• Periaatteessa mittoja voisi käyttää tarvittavien testitapausten
määrän selvittämiseen.
• Tyypillisiä: Halsteadin mittarit, McCaben syklomaattinen numero.
Rivimäärä taas ei kerro mutkikkuudesta mitään.
• Kehitysympäristöistä joko löytyy mittaustyökalu valmiina tai sellainen
on helppo asentaa.
• Lisätietoa
– http://en.wikipedia.org/wiki/Cyclomatic_complexity
– http://en.wikipedia.org/wiki/Halstead_complexity_measures
Ohjelmistotekniikka
360(504)
11.8 Virheiden kylväminen 1/2
• Error seeding
• Lisätään tietoisesti virheitä ohjelmakoodiin, jotta
– Voidaan yrittää arvioida jäljellä olevien ”oikeiden” virheiden
määrää testauksen avulla löytyneiden kylvettyjen virheiden
määrästä
– Näin voidaan myös arvioida testauksen kykyä löytää virheitä
• Merkitään Vo:lla oikeiden ja Vk:lla kylvettyjen virheiden
kokonaismäärää sekä Vol:lla ja Vkl:lla löydettyjen oikeiden ja
kylvettyjen virheiden määrää
• Oletetaan lisäksi, että Vo/Vol = Vk/Vkl
• Jäljellä olevien virheiden määrän arvioksi saadaan
(Vol x (Vk/Vkl)) - Vol
Ohjelmistotekniikka
361(504)
11.9 Virheiden kylväminen 2/2
• Kylvämisen ongelmia:
–
–
–
–
Minkälaisia virheitä pitäisi kylvää?
Onko kaikki kylvetyt virheet muistettu poistaa?
Paljonko menetelmästä aiheutuu ylimääräistä työtä?
Kylvösten poisto muuttaa ohjelmaa ja se pitää testata kokonaan
uudelleen – kuluu aikaa, rahaa
– Eettinen ongelma: on demoralisoivaa laittaa ohjelmaan
tahallisesti vikoja
• Eräs muoto on laittaa järjestelmän muihin osiin virheitä (miten
testattava komponentti selviää niistä?), mutta niitä kannattaa
mieluummin kutsua testitapauksiksi.
Ohjelmistotekniikka
362(504)
Mutaatiotestaus
• Virheiden kylvämistekniikan erikoistapaus
• Tuotetaan ohjelmasta versioita, joissa kaikissa on kylvettynä
eri virhe
• Voidaan käyttää
– Testauksen tehokkuuden arviointiin (kuinka monta mutanttia
löydettiin)
– Sen testaukseen, kuinka hyvin ohjelma kykenee toipumaan
virheistä
• Aikaisemmin mutaatioiden tuottamista on käytetty myös
testauskurssin harjoitustöiden generointiin!
Ohjelmistotekniikka
363(504)
12. Automaatio ja työkalut
Tässä kohdassa tutustutaan
testiautomaatioon sekä
testaamista helpottaviin
työkaluihin. Työkalujen suuren
määrän vuoksi tarkoituksena on
antaa lähinnä yleiskuva, jonka
avulla voi sitten helposti hankkia
lisätietoja. Yksi työkalu sopii
yhteen hommaan ja toinen
toiseen.
Ohjelmistotekniikka
364(504)
Orientaatioksi
• Alkupään kalvot perustuvat Mika Maunumaan kokoamaan
materiaaliin
• Eri näkökulmat
– Ohjelmistosuunnittelu kuvaa, miten asiat ovat
– Testaus kysyy ovatko asiat oikeasti niin
• Testaus on perinteisesti ollut käsityötä
• Testausautomaation kultainen lupaus on poistaa käsityö ja
ratkaista testausongelmat
– Kun ohjelma testaa ohjelmaa, säästetään aikaa ja rahaa
– Ohjelma jaksaa testata virheettömästi, nopeammin ja pidempään
– Kaikkea ei voida testata käsin
• Stressi- ja suorituskykytestaus jne.
Ohjelmistotekniikka
365(504)
12.1 Testiautomaatio kokonaisuutena
• Testiautomaatio on manuaalisen testauksen täydentäjä, ei
sen korvaaja
– Testit on suunniteltava etukäteen
– Automatisoidaan vain parhaat testit
– Käsityön rooli muuttuu, mutta ei poistu
• Ohjelmisto, jonka tarkoitus on ”ajaa” toista ohjelmaa
– Molemmat ovat syntyneet (osittain) samoista vaatimuksista
– Näkökulmassa ja tavoitteissa on suuri ero
• Testaus ja testien automatisointi vaativat erilaisia taitoja
• Testiautomaatio ei ole testauksen hopealuoti
Ohjelmistotekniikka
366(504)
12.2 Mitä on testiautomaatio
• Perustapauksessa testausohjelma ajaa testit testattavalle
kohteelle.
– Testitapauksia ei suoriteta käsin.
• Testit kuitenkin suunnitellaan ja toteutetaan testausohjelmalle
yleensä käsin.
– Tehdään testitapauksille pieniä ohjelmanpätkiä.
• Käytetään kaikilla testaustasoilla
– Yksikkötestien suorittaminen vaikkapa JUnitilla tai QTestillä on
testiautomaatiota.
– Testien ajaminen integrointipalvelimella.
– Käyttöliittymätestien automatisointi.
– Kuormitustestien ajaminen.
– Jne…
Ohjelmistotekniikka
367(504)
Eri tapoja kohteen ohjaamiseen
(yksinkertaistettuna)
• Testipenkki:
– Testiajuri kutsuu testattavan ohjelman funktioita tai muita
rajapintoja. Yksikkötestaus on tätä.
• Instrumentoitu:
– Kohteessa tai käyttöjärjestelmässä on jokin ajuri, jota
testiohjelma pyytää esim. etsimään näytöltä painonapin ja
klikkaamaan sitä. Voidaan kutsua napin API:a tai vaikka
emuloida hiiren klikkausta.
• Testausrobotti:
– Fyysinen robotti tunnistaa näytöllä olevat kohteet ja sormellaan
käyttää ohjelmaa.
…Kaikilla näillä on omat sovelluskohteensa ja hyvät ja huonot
puolensa
Ohjelmistotekniikka
368(504)
12.3 Testiautomaation lupauksia
• Regressiotestaus helpottuu, enemmän testejä useammin
• Voidaan suorittaa manuaaliselle testaukselle mahdottomia
testejä
– Esim. verkkosovellusten kuormitustestaus
• Testauksessa tehdyt virheet vähenevät, kone on ihmistä
tarkempi
– Toisaalta myös uudenlaiset virheet tulevat mahdollisiksi
•
•
•
•
•
Resurssien tehokkaampi käyttö
Testien eheys ja toistettavuus
Testit voidaan suorittaa eri laite- tai ohjelmistoalustoilla
Testien uudelleenkäyttö testikohteen pysyessä samana
Luottamus toimivuuteen kasvaa, markkinoille pääsy nopeutuu
Ohjelmistotekniikka
369(504)
12.4 Testiautomaation yleiset ongelmat
• Epärealistiset odotukset
– Työkalut ratkaisevat kaikki pulmat
• Huonot testaustavat
– ”Automating chaos just gives faster chaos”
• Odotetaan automaation löytävän paljon uusia virheitä
• Virheellinen turvallisuuden tunne
– Koska automaatio ei löytänyt virheitä, niitä ei olekaan
• Automatisoitujen testien ylläpito
• Tekniset ongelmat
– Buginen testaussofta, yhteensopivuus
• Organisaation ongelmat
– Johdon tuen puute, organisaation kulttuuri, koulutus
Ohjelmistotekniikka
370(504)
12.5 Automaation rajoitukset 1/3
• Ei poista manuaalisen testauksen tarvetta
– Kaikkea ei kannata automatisoida
• Harvoin ajettavat testit
• Testattava ohjelmisto on ”liikkuva maali”
• Testin tulokset on helposti ihmisen tulkittavissa, mutta erittäin
vaikea koneelle (esim. äänen tai kuvan laatu)
• Fyysistä toimintaa vaativat testit
– Kaikkea ei tarvitse automatisoida
• Vain parhaat ja usein toistuvat testit
• Testikohteen testattavuus nousee tärkeään asemaan, sen
puute voi johtaa automatisoinnin epäonnistumiseen
Ohjelmistotekniikka
371(504)
Automaation rajoitukset 2/3
• Manuaaliset testit löytävät enemmän virheitä
– Virhe löytyy yleensä ensin manuaalisella testillä, joka sitten
automatisoidaan regressiotestausta varten
– James Bach raportoi kokemuksistaan Borlandilla: automaatio
löysi vain alle 20 % kaikista projektin aikana löydetyistä virheistä
vaikka automaatioon oli satsattu jo useita vuosia (James Bach,
Test Automation Snake Oil, 1999)
• Uudet ominaisuudet pitävät sisällään enemmän virheitä kuin
vanhat
• Manuaalinen testaaja voi nopeasti löytää paljon virheitä
samalla kun automaatiota vasta laajennetaan uusille alueille
Ohjelmistotekniikka
372(504)
Automaation rajoitukset 3/3
• Testausautomaatio saattaa rajoittaa ohjelmistokehitystä
– Testit ovat herkkiä vähäisillekin muutoksille ohjelmistossa
• Automaattisen testin alustus on raskaampi operaatio kuin
manuaalisen testin
• Ylläpito vaatii työtä
• Työkaluilla ei ole mielikuvitusta
– Työkalut tekevät vain sen, mitä niiltä on pyydetty – ihminen voi
varioida testin suoritusta ja toimia älykkäänä tarkkailijana
• Automaatio ei lisää tehokkuutta
– Ajon hinta ja ajoaika vs. suunnittelun ja ylläpidon hinta
Ohjelmistotekniikka
373(504)
12.6 Ohjelman testattavuus
• Ohjelma pitää suunnitella siten, että testiautomaatio pystyy
– Ohjaamaan sitä, suorittamaan toimintoja
– Selvittämään ohjelman kulloisenkin tilan
– Hakemaan dataa käyttöliittymästä ja tietovarastoista selvittääkseen,
mitä testien johdosta tapahtui
• Tämä haaste on tiedostettu jo pitkään
– Silti mm. uusissa käyttöjärjestelmissä on asia yleensä unohdettu
• Monet testattavuutta edistävät piirteet helpottavat myös
ylläpidettävyyttä
Ohjelmistotekniikka
374(504)
Testattavuudelle tärkeitä piirteitä 1/4
• Yleinen yksinkertaisuus ja selkeys
– Testiautomaatiota ei voi tehdä sekavalle ja mutkikkaalle
ohjelmalle
• Arkkitehtuuri:
– Arkkitehtuuri, jossa käyttöliittymä voidaan ohittaa logiikan
testausta varten
– Modulaarisuus, jolloin komponentteja voi testata erikseen
• API:t
– API, johon voidaan tarttua ulkopuolisesta ohjelmasta
(yksikkötestauksen lisäksi myös järjestelmätesteissä)
– Standardoidut, tutut tiedonsiirtoprotokollat ja dataformaatit, joita
on helppo käsitellä
– Testausrajapinta (ei saa muodostaa takaporttia hakkereille)
Ohjelmistotekniikka
375(504)
• Tietokannat
– Standardimuotoiset tietokannat, joista on helppo hakea dataa
– Testidatan luonti mahdollista ilman sovellusohjelmaa
• Käyttöliittymät
– Käyttöliittymäteknologia, jossa käyttöliittymän elementit voidaan
tunnistaa ohjelmallisesti
– Käyttöliittymäelementteihin voidaan syöttää dataa ja sopivan
API:n avulla ja simuloiden näppäimistöä, eleitä
– Elementeistä voidaan lukea dataa API:n avulla. Jos se ei
onnistu, pitää ottaa ruutukaappauksia ja tunnistaa niistä OCR:n
avulla kenttien tekstit, tai vertailla bittikarttoja
– Sudenkuoppia: Dynaamisesti generoidut ikkunoiden luokat,
usealla objektilla sama tunniste, muokattavat kontrollit, kontrollien
vaihtelevat sijainnit.
Ohjelmistotekniikka
376(504)
• Logit
– Suorituksen logitus on tärkeää pitkissä testiajoissa ja
selvittämiseksi, mitä tapahtuu konepellin alla
– Mahdollisuus säilyttää väliaikaistiedostoja niiden
tarkastelemiseksi testiohjelmalla
• Ajoympäristön konfigurointi
– Konfigurointi yksinkertaisissa konfigurointitiedostoissa, joita
voidaan generoida testejä varten
• Koodaustapa
– Selkeä, rakenteinen, modulaarinen koodi, jota on helppo
ymmärtää ja tunnistaa testattavat kokonaisuudet
– Selkeät nimeämiskäytännöt
– Ei kovakoodattuja resurssitietoja, vaan kuvaus tiedostoissa,
jolloin ne voidaan korvataOhjelmistojen
testiversioilla
testaus, 2015
377(504)
Ohjelmistotekniikka
• Ei-intrusiivinen testaus
– Esim. turvallisuuskriittisen järjestelmän testauksessa ei ole hyvä,
jos ohjelmaa instrumentoidaan sen testausta varten. Tietyn
konfiguraation ohjelmaa pitää voida testata vain "käyttämällä",
koskematta sen komponentteihin.
– Tällöin on tärkeää, että esim. käyttöliittymää voidaan testata
ilman API:a, vain simuloimalla käyttäjää, esim. fyysisellä
robotilla.
– Ja ohjelman tila täytyy voida selvittää ilman ylimääräistä logitusta
yms.
Ohjelmistotekniikka
378(504)
12.7 Testiautomaatio – erilaista
ohjelmistosuunnittelua
• Testausautomaation toteutus on ohjelmistonkehitysprojekti;
skriptit vaativat
–
–
–
–
Ohjelmointi- ja suunnittelutaitoja
Testaustaitoja
Dokumentointitaitoja
Ylläpitotaitoja
• Kuka testaa testiohjelmiston?
Ohjelmistotekniikka
379(504)
Testiautomaatio ohjelmistoprosessin eri
vaiheissa 1/3
• Yksikkötestaus:
– Kehittäjien pitäisi huolehtia yksikkötestauksesta
– Kehittäjät eivät ole useinkaan kiinnostuneita testaamaan omaa
koodiaan manuaalisesti
• Manuaalinen testaaminen voidaan kokea tylsäksi tavaksi
hukata paljon aikaa
– Tarvitaan apuvälineitä, jotka automatisoivat yksikkötestauksen
mahdollisimman pitkälle
• Mieluiten näiden apuvälineiden tulisi integroitua
saumattomasti kehittäjien käyttämiin kehitysvälineisiin
– Editorit, kääntäjät, IDE:t (Integrated Development
Environment)
Ohjelmistotekniikka
380(504)
vaiheissa 2/3
• Useita kaupallisia ja ilmaisia työkaluja on saatavilla
• Yksi esimerkki ovat xUnit-kehykset
– Niiden taka-ajatuksena on sälyttää kehittäjien harteille niin
testien suunnittelu ja koodaaminen kuin ajaminen ja tulosten
analysointikin
– Automaattiset regressiotestit saadaan ”kaupan päälle”
Ohjelmistotekniikka
381(504)
vaiheissa 3/3
• Integrointitestaus:
– Yksikkötestaustyökaluja voidaan hyödyntää myös
integrointitestauksessa
– Ajurien ja/tai tynkien automaattinen generointi
– Ennen varsinaista integrointitestiä kannattaa testattavalle
kokonaisuudelle tehdä savutesti, jolla selvitetään onko se kelvollinen
etenemään integrointitestaukseen
– Erityisesti jatkuvan integraation maailmassa tehdään normaalin työn
osana integrointi omassa työasemassa ja sitten varsinainen integrointi
palvelimella
• Integroinnin onnistumisen todennäköisyys kasvaa merkittävästi
• Yhtä olennaista kuin testaustyökalu, on testausta pyörittävä
automatiikka
• Järjestelmätestaus – siitä jatkossa lisää
Ohjelmistotekniikka
382(504)
12.8 Automaation lähestymistavat
• Erityisesti käyttöliittymän kautta testaavasta automaatiosta
voidaan havaita erilaisia näkökulmia
– Helppokäyttöisyys, ylläpidettävyys ja kyky löytää virheitä eri
tilanteissa vaihtelevat
• Seuraavassa testiautomaatio jaetaan viiteen
lähestymistapaan
–
–
–
–
–
Nauhoita ja toista
Komentojonot
Dataohjattu
Avain- ja toimisanat (keywords, action words)
Mallipohjainen
Ohjelmistotekniikka
383(504)
Nauhoitus ja toisto 1/2
• Alkeellisin (ja pahamaineisin) muoto
– Nauhoitetaan käyttöliittymästä tietty sekvenssi tietyllä syötteellä
ja toistetaan samaa kerrasta toiseen
– Muutos kohteessa vaatii yleensä uuden nauhoituksen
– Yleensä virhe löytyy nauhoitettaessa
• Toisto ei löydä uusia virheitä
• Testin tarkoitus on ajaa tietty sekvenssi läpi ja katsoa tuliko
oikea tulos (jos tarkastukset on implementoitu)
Ohjelmistotekniikka
384(504)
Nauhoitus ja toisto 2/2
• Syntyvät skriptit ovat lähes poikkeuksetta
–
–
–
–
Huonosti strukturoituja
Huonosti dokumentoituja
Lähes mahdottomia ylläpitää
Lineaarisia
• Eivät välttämättä vaadi ohjelmointiosaamista
– Kynnys kokeilla on alhainen
• Soveltuvat ohjelmiston ominaisuuksien esittelyyn
– Valmis testikohde, jonka rajapinta ei ole muutosaltis
• Nauhoitusta voi kuitenkin käyttää luomaan runko, josta
rakennetaan yleiskäyttöisiä hyviä testejä
– Muokataan nauhoitettua esim. Python-koodia
Ohjelmistotekniikka
385(504)
Komentojonot eli skriptit 1/2
• Koodataan skripti suorittamaan tietty sekvenssi
–
–
–
–
–
Jokainen testitapaus on siis pieni ohjelma tai funktio
Muutos sekvenssiin vaatii pienen muutoksen osaan skriptiä
Syöte- ja tulostiedot ovat osa skriptiä
Skriptit ovat hyvin strukturoituja ja dokumentoituja
Tyypillinen tapa yksikkötestauksessa
• Skriptien varautuminen virhetilanteisiin hallitaan hyvin
• Vaatii osaamista ohjelmistosuunnittelusta
– Samanlaista kurinalaisuutta
– Samoja taitoja
Ohjelmistotekniikka
386(504)
Komentojonot eli skriptit 2/2
• Myös käyttö voi vaatia ohjelmointitaitoja
• Skriptejä on kahdenlaisia
– Lineaarisia
• Skripti, joka vain syöttää dataa (tms.) ja tarkistaa, mitä
tapahtui
– Rakenteellisia
• Kuin lineaariset skriptit, mutta kontrolli yms. koodattu käsin
Ohjelmistotekniikka
387(504)
Dataohjattu testaus
• Eriytetään testitapausten sisältö ja suorituskoodi
• Taitovaatimukset, roolien jako
– Skriptin koodaaminen vaatii ohjelmointitaitoja
– Testijoukkojen luominen vaatii testaustaitoja
1) Testien kuvaus testidatamassalla (yleisin merkitys)
– Esimerkiksi suunnitellaan huolella iso lista tietueita tietokantaan, joista
sen pitäisi selvitä kunnialla
– Ajetaan skriptillä, joka syöttää kunkin tietueen ja tarkistaa, mitä tapahtui
– Mitä vs. miten
2) Testitapaukset kirjoitetaan dataksi
– Tyypillisesti sarja matalan tason komentoja
– Käytettävissä olevat komennot riippuvat skriptistä
– Skripti suorittaa annetun testitapauksen tai testijoukon
• Sisältää toteutuksen yksinkertaiselle navigoinnille tyyliin "paina
nappulaa X"
Ohjelmistotekniikka
388(504)
Avain- ja toimisanat
(keywords, action words) 1/2
• Lähes kaikki tietojenkäsittelyyn liittyvät ongelmat voidaan
ratkaista lisäämällä uusi rajapinta tai nostamalla
abstraktiotasoa
• Avainsana (keyword) kuvaa joitakin käyttöliittymän toimintoa
– kwSelectMenu ”File”, kwPressButton btOK
– Myös vertailuja: kwCompareText ”foo.txt”
– Matalan tason toiminnot
• Toimisanat (action words) kuvaavat korkeammalla tasolla
käyttäjän toimia
– awSendEmail on sama toiminto eri alustoilla
– Voi koostua useasta avainsanasta
– Toimisanat edustavat ongelmakentän sanastoa
Ohjelmistotekniikka
389(504)
Avain- ja toimisanat
(keywords, action words) 2/2
• Testitapaukset määritellään toimisanojen avulla
– Kuvaus toimisanoista avainsanoiksi määritellään erillisessä
datassa
– Avainsanat toteutettu skriptissä (esim. pieni Python-funktio)
• Toimisanoilla saavutetaan korkea siirrettävyys
– Jos toimisanaa vastaavan toiminnon toteutus käyttöliittymässä
muuttuu, niin korjataan toimisanan määrittelyä avainsanoilla – ei
välttämättä tarvetta koskea testeihin
• Tuoteperheen eri jäsenille sama testi
– Tarvittaessa joka jäsenelle oma avain- ja mahdollisesti
toimisanatoteutus
Ohjelmistotekniikka
390(504)
Mallipohjainen 1/2
• Mallipohjainen testaus perustuu järjestelmään käyttäytymistä
kuvaavaan malliin
– Kuvataan mm. tilakoneilla
– Alunperin käytetty lähinnä protokolla- ja API-testauksesta
– Nykyään yhä enemmän myös sulautettujen järjestelmien ja GUItestauksessa
• Yksikertaisimmillaan kuvaa joukon sekvenssejä esim.
käyttöliittymän läpi
• Vahvuus
–
–
–
–
Käyttötapojen variointi
Syötteiden variointi
Rinnakkaisuuden hallinta
Mallit voivat sisältää myös odotetut tulokset
• Smart monkey vs. dumb monkey testing
Ohjelmistotekniikka
391(504)
Mallipohjainen 2/2
• Heikkoudet?
– Työkalujen käyttö vaatii uutta osaamista
– Organisaatioon kohdistuvat muutospaineet, jos testitapauksia ei enää
tarvitse erikseen suunnitella
– Vaatii uuden tavan ajatella testausta
• Testimalli ei kuvaa testitapausta, vaan se on lähempänä
testijoukkoa
– Oikea taso mallille
• Mallinnetaanko käyttöliittymän elementtejä ja niihin kohdistuvia
syötteitä
– nopea apinatestaus
• … vai mallinnetaanko käyttäjän toimia
– avain- ja toimisanat tilasiirtymien niminä
– Mallintaminen vaatii eniten osaamista (mallien laatu vs. testien laatu)
Ohjelmistotekniikka
392(504)
12.9 Automatisoinnin suunnittelu 1/2
• Tunnista testitilanteet
– Mitä voidaan testata
– Priorisoi
– Raja-arvoanalyysi, ekvivalenssiluokat
• Suunnittele testitapaukset
– Miten valittu asia voidaan testata
– Testin tarkoitus, oletettu tulos
Ohjelmistotekniikka
393(504)
Automatisoinnin suunnittelu 2/2
• Luo testitapaukset (mallipohjaisessa testauksessa testimallit)
– Skriptit, datat, tulokset jne.
– Asetus- ja puhdistusoperaatiot
– Esi- ja jälkiehdot
• Suorita testit
• Vertaile saatuja tuloksia oletettuihin tuloksiin
– Oletus: jos molemmat ovat samat, niin testi OK
– Huomaa muuttuvat asiat kuten kellonaika ja päiväys
• Säännölliset lausekkeet
Ohjelmistotekniikka
394(504)
Konfiguraationhallinta
• Testimateriaali ajan tasalla
– Skriptit
– Testidata
• Ohjelmiston versio
– Testware liittyy olennaisesti tiettyyn versioon testattavasta
ohjelmistosta
Ohjelmistotekniikka
395(504)
Esi- ja jälkikäsittely
• Automaation vaatiman datan määrä on yleensä suuri
– Tiedon läpikäynti käsin on aikaa vievää ja virhealtista
• Esikäsittelyllä valmistetaan dataa
– Tekstistä binääriseen muotoon
– Tietokannan taulut
– Tietoelementtien kombinointi
• Jälkikäsittely tarkastaa ja muokkaa tuloksen
– Vertailuja loki-tiedostoon (säännöllisillä lauseilla)
– Tietokannan muutokset
– Binäärisestä (ihmisen tulkittavaan) tekstimuotoon
Ohjelmistotekniikka
396(504)
12.10 Tunnettuja työkaluja
• Toiminnalliseen testaukseen
– HP QuickTestPro, IBM Rational Functional Tester, Robot Framework, jne.
• Suorituskykytestaukseen
– HP LoadRunner, IBM Rational Performance Tester, JMeter, jne.
• Testauksen hallinta
– HP Quality Center, TestLink, jne.
• Testauksen skriptauskielet
– Perl, Python, Ruby, Visual Basic, Java, C++
• Testauskehykset
– xUnit, Fit(Nesse), QTest
• Jatkuvan integroinnin moottorit
– Jenkins, Hudson
• Vertailu-, haku- ja käsittelytyökalut
– diff, grep, awk
Ohjelmistotekniikka
397(504)
12.11 Automatisointiprojekti 1/2
• Aloitetaan yleensä suurin lupauksin
– Työkalu ratkaisee testauksen ongelmat
– Automatisoidut testit ovat halpoja
– Kun käyttöliittymän läpi testaava automaatio vilistää ruudulla,
tulee helposti euforinen olo siitä, että tuotteen laatu paranee
silmissä – jos ei ymmärrä mitä todellisuudessa tapahtuu
• Kaatuu monesti illuusion särkymiseen
– Huonojen käytäntöjen automatisointi ei parantanut tilannetta
• Automatisoitiin vääriä, huonoja tai virheellisiä testejä
– Valittiin väärä tai epäyhteensopiva (ja kallis) työkalu
– Ylläpitoon ei oltu varauduttu
• Skriptien muuttaminen työlästä
• Testien riippuvuutta ohjelmistoversiosta ei huomioitu
Ohjelmistotekniikka
398(504)
Automatisointiprojekti 2/2
– ”Automatisoidaan kaikki testit” yms. epärealistiset tavoitteet
– Automatisoijat ovat usein kalliimpia kuin manuaaliset testaajat,
samalla rahalla olisi saavutettu paljon aikaan manuaalisessa
testauksessa
– Automaatio ei toivu virheistä
• Kannattaa aloittaa kevyesti
–
–
–
–
Kannattaa kokeilla useampia eri työkaluja
Pilottiprojekti
Aloitetaan esim. savutestien automatisoinnista
Otetaan selvää, onko joku muu projekti/organisaatio käyttänyt
vastaavaa välinettä vastaavassa projektissa
– Testausstrategia ja ihmisten sitoutuminen kuntoon
• Automaatio ei vähennä testauksen suunnittelun tarvetta
Ohjelmistotekniikka
399(504)
12.12 Työkalun valinta
Päämäärät
Hankintasuunnitelma
Ensimmäiset kokeilut
Haastattelut
vertailu
useita vaihtoehtoja
Vaihtoehtojen karsiminen
yksi
vaihtoehto
Hankinta ja kokeilu
Kokeiluprojekti
Käyttöönotto
Kuvan lähde: Jussi Niutanen. Symbian-sovellusten
testauksen automatisointityökalut. Diplomityö,
TTY, Sähkötekniikan osasto, 2005.
Automatisoinnin kehittäminen
Ohjelmistotekniikka
400(504)
Testaustyökalun ostajan muistilista 1/3
• Mukailtu lähteestä: Dustin, Rashka, Paul: Automated
Software Testing, Addison Wesley, 1999.
• Arvioi miten työkalu tulee parantamaan nykytilannetta
• Miten valita oikea työkalu
• Miten paljon rahaa työkaluun ollaan valmiita sijoittamaan
• Paljonko työkalun käyttöönotto vaati ylimääräistä aikaa
• Kuinka paljon työkalun käyttö vaatii asiantuntemusta
– Tarvitaanko uutta työvoimaa?
• Paljonko käyttäjien kouluttaminen tulee maksamaan
Ohjelmistotekniikka
401(504)
• Kuinka työkalun käyttökelpoisuutta voidaan arvioida ennen
hankintapäätöstä
– Tärkeää evaluoida omista tarpeista käsin
– Pilotointi
• Kuinka työkalun käyttöönotto toteutetaan
• Muutamia nyrkkisääntöjä
– Hyväkään testiautomaatio ei korvaa ammattitaitoisia testaajia ja
hyvää testausstrategiaa
• Se voi kyllä täydentää niitä
– Ei kannata olettaa, että testityökalut olisivat sen laadukkaampaa
softaa kuin muut ohjelmistokehityksen apuvälineet
– Mikäli testataan graafista käyttöliittymää, kannattaa olettaa, että
se muuttuu usein
Ohjelmistotekniikka
402(504)
– Testiautomaatioskripti on tyhmä, testitapaukset vaativat hyvää
suunnittelua
• Manuaalista testiä suunnitellessa voi aina olettaa, että
testaaja on ajatteleva ihminen
– Mikäli mahdollista, testiskriptit pitäisi kirjoittaa yleiskäyttöisellä
skriptauskielellä
• Oppimiskynnys, valmiiden kirjastojen puute, testaajien ja
kehittäjien yhteistyö
• Vaatimus työkaluspesifisen kielen käyttämiseen voi olla hyvä
syy ko. työkalun hylkäämiseen
• Lukittuminen tiettyyn toimittajaan
Ohjelmistotekniikka
403(504)
Yhteenveto
• Testiautomaatio ei poista manuaalista testausta, vaan
täydentää sitä
• Automaation tekeminen on kalliimpaa kuin manuaalinen
testaus
– Testien toisto on halvempaa
• Automaatio vaatii ohjelmistoteknistä osaamista
– Testwaren suunnittelu ja toteutus
– Konfiguraationhallinta
• Uusia virheitä löydetään paremmilla testeillä – ei vanhojen
automatisoinnilla
Ohjelmistotekniikka
404(504)
12.13 Mallipohjainen testaus
• Mukailtu lähteistä Ibrahim K. El-Far, James A. Whittaker:
Model-based Software Testing ja [Broekman&Notenboom 02]
• Testaajilla on usein mielessään jonkinlainen implisiittinen malli
testikohteen käyttäytymisestä
– Tyyliin: jos teen toiminnon A, voin sen jälkeen valita tehtäväksi
joko toiminnon B tai C
• Mallipohjaisen testauksen ideana on yksinkertaisesti kirjata
tämä testimalli ylös ja käyttää sitä eksplisiittisesti testauksen
apuna
• Mikäli malli on tarpeeksi tarkka, voidaan sitä
– Jakaa useamman testaajan kesken
– Uudelleenkäyttää
Ohjelmistotekniikka
405(504)
Mallinnus 1/2
• Mallin testikohteesta tekee ideaalitapauksessa se, joka
ymmärtää parhaiten kuinka testikohteen pitäisi käyttäytyä
• Malli pitäisi tehdä jo kehitysvaiheessa, mutta mikäli se on
jäänyt tekemättä, kannattaa sen tekeminen joissain
tapauksissa myös pelkästään testausta varten
– Mallin tekemisen kannattavuus riippuu mm. siitä kuinka kauan
kohteen testauksen oletetaan kestävän
– Mikäli kehitysvaiheessa tehdystä mallista on generoitu toteutus
automaattisesti, ei testausta yleensä kannata perustaa yksin
tähän malliin, koska silloin testattaisiin vain koodingeneroinnin
oikeellisuutta
• Mikäli malli paisuisi muuten liian mutkikkaaksi, voidaan sen
kokoa rajoittaa keskittymällä vain testauksen kannalta
mielenkiintoisiin (riskialttiimpiin) osiin
Ohjelmistotekniikka
406(504)
Mallinnus 2/2
• Monesti testauksen kannalta hyödyllisin tapa mallintaa
testikohteen käyttäytymistä on tilakone
• Formaalisti äärellinen tilakone (FSM eli Finite State Machine)
voidaan esittää viisikkona (S, T, A, F, L), jossa
–
–
–
–
S on järjestelmän mahdollisten syötteiden joukko
T on järjestelmän tilojen joukko
A on järjestelmän alkutila
F on tilasiirtymäfunktio S x T → T
• kertoo mihin tilaan siirrytään kun nykyisessä tilassa saadaan
uusi syöte
– L on järjestelmän lopputilojen joukko
• Tilakone on kullakin hetkellä vain yhdessä tilassa kerrallaan
Ohjelmistotekniikka
407(504)
Esimerkkimalli 1/2
• Esimerkkinä yksinkertainen jonkin mediasoittimen toimintaa
kuvaavaa tilakonemalli, jossa
–
–
–
–
S = {Play, Rec, FF, Rwd, Stop}
T = {Valmius, Toisto, Nauhoitus, Kelaus eteen, Kelaus taakse}
A = Valmius, L = {Valmius}
F määritellään taulukon avulla siten, että ylin vaakarivi kertoo
painettavan näppäimen nimen ja vasemmanpuoleisin pystyrivi sen tilan
missä ollaan, risteyksestä löytyy tila, johon siirrytään:
Play
Rec
FF
Rwd
Stop
Valmius
Toisto
Nauhoitus
Kelaus eteen
Kelaus taakse
Valmius
Toisto
Toisto
Toisto
Toisto
Toisto
Valmius
Nauhoitus
Nauhoitus
Nauhoitus
Nauhoitus
Nauhoitus
Valmius
Kelaus eteen
Toisto
Kelaus eteen
Kelaus eteen
Kelaus eteen
Valmius
Kelaus Ohjelmistotekniikka
taakse Toisto
Ohjelmistojen
testaus,
2015 Kelaus taakse
Kelaus taakse
Kelaus
taakse
408(504)
Valmius
Esimerkkimalli 2/2
• Äärellinen tilakone voidaan piirtää suunnattuna graafina:
Toisto
Kelaus eteen
Play
FF, Rwd,
Rec, Play
Stop
Stop
Stop
Play
FF, Rec, Rwd
Valmius
Play
FF
Rec
Stop
Rwd
Kelaus taakse
Stop
Nauhoitus
Play, FF, Rec, Rwd
Rwd, Rec, FF
Ohjelmistotekniikka
409(504)
Erityisiä mallityyppejä 1/2
• UML:n tilakoneet ovat äärellisen tilakoneen laajennus, joissa
sallitaan lisäksi mm.
– Tilojen alitilat, eli käytännössä tila voi sisältää toisen tilakoneen
– Rinnakkaiset tilat, eli tilakone voi olla useassa tilassa yhtä aikaa
• Myös Markov-ketjut, joilla voidaan mallintaa stokastisia
järjestelmiä, voidaan nähdä eräänlaisina tilakoneiden
laajennuksena
– Käyttökelpoisia esim. silloin kun halutaan kerätä tietoa virheiden
todennäköisyyksistä järjestelmän luotettavuutta arvioitaessa
– Ns. operationaaliset profiilit, jotka pyrkivät mallintamaan
käyttäjien toimintaa, ovat eräs tapa hyödyntää tilastotietoa
testauksessa
• Esim. mikäli videonauha on lopussa, on todennäköisempää,
että käyttäjä kelaa nauhaa taaksepäin kuin eteenpäin
Ohjelmistotekniikka
410(504)
Erityisiä mallityyppejä 2/2
• Aktiomallit perustuvat muuttujiin ja aktioihin
– Järjestelmän tila tallennetaan muuttujiin
– Kullakin aktiolla on esiehto (vahti), joka kertoo millaisissa tiloissa
se voidaan suorittaa, ja jälkiehto, joka kertoo millaisia vaikutuksia
tilaan sen suorituksella on
• Esimerkiksi tapahtuma Pienennä, joka voidaan suorittaa kun
x > 0, ja jonka suorituksen seurauksena x ← x – 1
– Aktiomallissa tapahtumien logiikka nousee selkeämmin esiin
kuin tilakoneessa, mutta järjestelmän täsmällinen tila ja sen
muutokset ovat vaikeampia hahmottaa
Ohjelmistotekniikka
411(504)
Testien generointi 1/3
• Kun käyttäytyminen on mallinnettu äärellisen tilakoneen
avulla, on testitapausten suunnittelu helppoa
– Testitapauksia voidaan generoida automaattisesti
• Jokainen testitapaus vastaa jotakin polkua suunnatussa
graafissa
– Jotta testitapaukset olisivat riippumattomia toisistaan, kannattaa
niiden aina alkaa tilakoneen alkutilasta (tai jostain muusta
tunnetusta tilasta)
Ohjelmistotekniikka
412(504)
• Esimerkki testitapauksesta, jossa ensin nauhoitetaan, sitten
kelataan taaksepäin ja sitten toistetaan:
Toisto
FF, Rwd,
Rec, Play
5
Kelaus eteen
Play
Stop
Stop
Stop
Play
FF, Rec, Rwd
FF
Valmius
Play
3
Stop
Rwd
4
Kelaus taakse
1
Rec
Stop
2
Nauhoitus
Play, FF, Rec, Rwd
Rwd, Rec, FF
Ohjelmistotekniikka
413(504)
• Testitapaus voidaan ajaa manuaalisesti seuraamalla polkua
tilakoneessa
• Vaihtoehtoisesti polku voidaan koodata esim. testiskriptiksi,
joka kutsuu vastaavaa toiminnallisuutta polun kaarien
osoittamassa järjestyksessä
• Mikä parasta, testien tuottaminen on helppo automatisoida
Ohjelmistotekniikka
414(504)
Mallin suorituksen seuranta 1/2
• Yleisesti ottaen, malli ei sinällään helpota testien tulosten
keräämistä
• Testikohde on kuitenkin mahdollista instrumentoida siten, että
sen käyttäytymistä voidaan tarkastella tilakoneesta käsin
– Laiton käyttäytyminen on helppo todeta esim. tilanteessa, jossa
testikohde yrittää siirtää tilakoneen tilasta toiseen sellaisella
syötteellä, jonka pitäisi pitää tila samana
Ohjelmistotekniikka
415(504)
Mallin suorituksen seuranta 2/2
• Tilakoneesta voidaan kätevästi nähdä paitsi ne testitapaukset
jotka on suoritettu, myös ne joita ei vielä ole suoritettu
• Testikattavuus voidaan tilakoneessa määritellä annettujen
syötteiden, saavutettujen tilojen tai läpikäytyjen kaarien avulla
– Voidaan vaatia, että testeissä esim. kaikki mahdolliset syötteet
on annettu, kaikki tilat on täytynyt saavuttaa ja puolet kaarista
käydä läpi
– Huom! Kattavuus mallin elementtien suhteen voi käytännössä
tarkoittaa hyvin eri asiaa kuin kattavuus testikohteen koodissa
Ohjelmistotekniikka
416(504)
Epädeterminismi ja
reaaliaikajärjestelmät
• Epädeterminismi
– Mikäli tilasta voidaan siirtyä samalla syötteellä kahteen tai
useampaan eri tilaan, on kyseessä epädeterministinen tilakone
– Tämä on eräs tapa mallintaa mm. laitteen ympäristössä
tapahtuvia ilmiöitä kuten esimerkiksi tietoliikenneverkon häiriöitä
• Reaaliajan mallintamista varten on olemassa erilaisia
tilakoneiden laajennuksia
– Ominaisuudet tyyliin: tilassa A ei saa viipyä yhtäjaksoisesti
kauempaa kuin 3 ms
Ohjelmistotekniikka
417(504)
Tilaräjähdys 1/2
• Valitettavasti tilakoneet kärsivät ns. tilaräjähdysongelmasta
(state space explosion)
• Tilaräjähdys tarkoittaa sitä, että ei-triviaalin järjestelmän
käyttäytymistä kuvaava malli kasvaa niin suureksi (paljon
tiloja ja tilasiirtymiä), että sitä ei pystytä enää käsittelemään
nykyisillä algoritmeilla tehokkaasti
• Eräs ratkaisu: pienennetään tilakonetta joko
– Jättämällä jotain mallintamatta
– Abstrahoimalla käyttäytymistä
• Esim. monimutkainen syöte testikohteelle mallinnetaan vain
kahdella vaihtoehdolla: laillinen syöte ja laiton syöte
Ohjelmistotekniikka
418(504)
Tilaräjähdys 2/2
– Yleisessä tapauksessa tilakoneen pienentäminen on hankala ja
tarkkuutta vaativa tehtävä
• On helppo saada aikaiseksi pienempi tilakone, joka ei enää
vastaakaan testikohteen oletettua käyttäytymistä
– Toinen yleisesti käytetty tekniikka on tila-avaruuden generointi
lennossa vain siltä osin kuin se on sen hetkisen tilanteen
kannalta tarpeellista
Ohjelmistotekniikka
419(504)
Tilakonetestauksen havaitsemia
virheitä 1/2
• Tilakonetestauksen havaitsemia virheitä (aina kaikki näiden
virheiden havaitsemiseen tarvittava tieto ei ole saatavilla):
– Tilakoneen tilat, joilla ei ole sisään tulevia tilasiirtymiä
• Malli on puutteellinen, ehkä myös toteutus
• Esim. videonauhurin tapauksessa Pause-tila, johon ei pääse
millään syötteellä mistään muusta tilasta
– Jokin tila puuttuu tilakoneesta
• On ehkä toteutettu jotain, mitä ei ole spesifioitu
• Videonauhuriin on toteutettu Pause-tila, mutta sitä ei on
tilakoneessa
Ohjelmistotekniikka
420(504)
Tilakonetestauksen havaitsemia
virheitä 2/2
– Tilakoneessa on ylimääräinen tila
• Jotain on ehkä jäänyt toteuttamatta
• Tilakoneessa on Pause-tila, mutta sitä ei ole toteutettu
– Tilasiirtymä vie väärään tilaan
• Mallissa on virhe, ehkä myös toteutuksessa
• Syötteellä Play tilakone siirtyy Toista-tilasta Valmius-tilaan
– Tilasiirtymä puuttuu
• Malli on puutteellinen, ehkä myös toteutus
• Toista-tilasta ei pääse Valmius-tilaan Stop-napilla
Ohjelmistotekniikka
421(504)
Off-line- vs. online-testaus 1/2
Test
Behaviour
Generate
Test Suite
Execute
Test Suite
Evaluate
Test Results
Report
Results
No
Yes
Online?
Yes
Test
Objectives
Select Next
Test Step
No
Execute Step on
Model& SUT
Evaluate
Result
Objectives
Achieved
?
Adapted from: Alan Hartman, Mika Katara, and Sergey Olvovsky. Choosing a Test Modeling Language:
a Survey. In Proceedings of the Haifa Verification Conference 2006, IBM Haifa Labs, Haifa, Israel,
October 2006. Number 4383 in Lecture Notes in Computer Science, pages 204-218. Springer 2007.
Ohjelmistotekniikka
422(504)
Off-line- vs. online-testaus 2/2
• Off-line-testauksessa generoidaan ensin testitapaukset ja
sitten ne suoritetaan kuten perinteisessä automatisoinnissa
• Online-testauksessa testien generointi ja suoritus etenevät
yhtäaikaisesti testiaskel kerrallaan
– Testitapauksia ei sinänsä ole, vain pitkiä testiajoja
• Off-line on yhteensopivampi olemassa olevien
testausprosessien kanssa, eli helpompi ottaa käyttöön
• Online mahdollistaa pitkäkestoisten testien tekemisen ja sopii
paremmin epädeterminististen järjestelmien testaukseen
– Epädeterministinen testikohde voi vastata monella tapaa oikein
tietyssä tilanteessa
Ohjelmistotekniikka
423(504)
Työkalut? 1/2
• Kaupallisia työkaluja mallipohjaiseen testaukseen on
olemassa, mm.
– Conformiq Designer
http://www.conformiq.com/products/conformiq-designer/
• Javalla höystetyt UML:n tilakoneet testimalleina
• Testigeneraattori esim. TTCN-3-kielisten testien tekemiseen
– Smartesting CertifyIt
http://www.smartesting.com/index.php/cms/en/product/certify-it
– ALL4TEC MaTeLo http://www.all4tec.net/index.php/en/modelbased-testing/20-markov-test-logic-matelo
Ohjelmistotekniikka
424(504)
Työkalut? 2/2
• Ilmaisia avoimen lähdekoodin työkaluja
– TTY/OHJ:ssa kehitetty TEMA-työkalukokoelma
http://tema.cs.tut.fi/
– VTT:n OSMO Tester http://code.google.com/p/osmo/
– Intel:n fMBT https://01.org/projects/fmbt
– ModelJUnit http://www.cs.waikato.ac.nz/~marku/mbt/modeljunit/
– Jne… työkaluvalikoima kasvaa koko ajan
• Luultavasti isompi ongelma kuin löytää oikeat työkalut on
saada testaajat tekemään testimalleja
Ohjelmistotekniikka
425(504)
13. Tietoturvan testaaminen
Vielä pari vuotta sitten
tietoturva oli aika pienen piirin
mielenkiinnon kohteena.
Valitettavasti nykypäivänä
kaikkien on oltava siitä
kiinnostuneita. Miten sitten
tietoturvaan liittyviä seikkoja
pitäisi testata?
Ohjelmistotekniikka
426(504)
Tietoturvatestauksen iso haaste
• Testauksen täytyy löytää kaikki ohjelmistossa olevat
tietoturva-aukot, vastustajalle riittää yksi
• Tietoturvaan liittyvät häiriöt ovat yleensä paljon
huomaamattomampia kuin esim. toiminnallisuus- tai
suorituskykyhäiriöt
• Toiminnallisten ongelmien kanssa voidaan ”elää”, mutta
yksikin haavoittuvuus voi olla tuhoisa
Ohjelmistotekniikka
427(504)
13.1 Mitä kaikkea kuuluu
tietoturvallisuuteen? 1/2
• Ks. Wikipedian artikkeli http://fi.wikipedia.org/wiki/Tietoturva
• Perusasiat:
– Saatavuus tai käytettävyys (engl. availability): tieto on saatavilla,
kun sitä tarvitaan.
– Luottamuksellisuus (engl. confidentiality): tietoa voivat käsitellä
vain sellaiset henkilöt, joilla on siihen oikeus.
– Eheys (engl. integrity): tieto ei saa muuttua tahatta tai
hyökkäyksessä, tai muutos pitää ainakin havaita; toisinaan
eheys määritellään myös tietojen loogisuudeksi (ns. sisäinen
eheys) ja paikkansapitävyydeksi (ns. ulkoinen eheys).
Ohjelmistotekniikka
428(504)
Mitä kaikkea kuuluu
tietoturvallisuuteen? 2/2
• Näitä täydentäviä:
– Kiistämättömyys: Henkilö ei voi menestyksellisesti kiistää tekoa,
jonka hän on tehnyt. Kiistämättömyys riippuu viime kädessä
siitä, mitä oikeudessa hyväksytään näytöksi.
– Tunnistus: Henkilö (tietojärjestelmän käyttäjä) voidaan
tarvittaessa liittää käyttäjätunnukseen (joka voi olla anonyymi) ja
voidaan kenties luotettavasti tunnistaa luonnolliseksi tai
oikeushenkilöksi.
• Tietoturvan osa-alueita ovat työasemien tietoturva, palvelinten
tietoturva, tietokoneverkon tietoturva. ympäristöturvallisuus ja
sovellusten turvallisuus.
– Tällä kurssilla meitä kiinnostaa lähinnä sovellusten turvallisuus
Ohjelmistotekniikka
429(504)
13.2 Tietoturvan testaaminen tärkeää
• Tietokoneita (PC, tabletti, kännykkä jne.) käytetään yleisesti
luottamuksellisten ja salaisten tietojen säilyttämiseen
• Tietoja siirretään pilveen ja takaisin
• Tietojärjestelmät ovat täynnä ihmisille ja yrityksille kriittisiä
tietoja
• Kaikki digitaaliset laitteet ovat pian kiinni verkossa
• Mikäli jätät tietoturvan testauksen tekemättä, murtautujat
tekevät sen puolestasi!
Ohjelmistotekniikka
430(504)
… mutta unohtuu usein
• Ohjelmisto voi toimia muuten täysin oikein, mutta se voi silti
sisältää virheitä, jotka voivat vaarantaa tietoturvan
• Tietoturvaan liittyviä vaatimuksia ei vielä nykyään ymmärretä
kovin laajasti
– Verkko on täynnä softaa, jonka tekemisessä ei ole kiinnitetty
yhtään huomiota tietoturvaan
– Esim. käyttöjärjestelmiä joudutaan jatkuvasti paikkaamaan
tietoturvapäivityksillä
Ohjelmistotekniikka
431(504)
13.3 Tietoturvatestauksen kohteet
•
•
•
•
•
•
Verkkoliikenne.
Palvelinympäristöt.
Käyttäjän tietokoneympäristöt.
Mobiililaitteet.
Digitaaliset laitteet.
Sovellukset.
• Tässä kalvosarjassa katsellaan lähinnä sovellustasoa.
Ohjelmistotekniikka
432(504)
13.4 Tietoturvatestauksen luonne
• Testaus on laajempi kokonaisuus, jossa
– Arvioidaan kohteen tietoriskejä – tärkeät tiedot, miten ne
houkuttelevat, mitä pitää erityisesti suojata.
– Tarkastetaan suunnitelmia ja toteutusta – onko käytetty
asianmukaisia suojauksia ja suunnitteluratkaisuja, onko toteutus
asianmukainen.
– Testataan, että kaikki suojausmekanismit toimivat.
• Tehdään toiminnallista testausta.
• Kokeillaan erityisiä hyökkäyksiä.
– Asiaan liittyy myös käytettävyyden arviointi ja testaus: ihmisen
käyttövirheet ovat olennainen tapa altistaa tieto ulkopuolisille.
– Samoin kuormitustestauksella tarkistetaan, että sovellus kestää
palvelunestohyökkäykset asianmukaisesti.
Ohjelmistotekniikka
433(504)
13.5 Lähtökohtana riskianalyysi
• Tietoturvatestauksen tarpeita voi selvittää
riskianalyysin avulla, jolla saadaan
selville tietojen ja liiketoiminnan
suojauksen kannalta tärkeimmät seikat
• Mitä tietoa käsitellään?
• Millaisia riskejä tietoon liittyy?
• Mitkä tiedot pitää suojella kaikkein
varmimmin?
• Riskianalyysin jälkeen tiedetään, minkä
asioiden testaamiseen kannattaa
panostaa
Ohjelmistotekniikka
434(504)
13.6 Paljon ohjeita
• Tietoturvaa voidaan varmistaa ja täytyy varmistaa monella
tasolla, esim. serverin fyysinen sijoittelu vs. palomuurit vs.
käyttäjien autentikointi
• Julkishallinto on ohjeistanut tietoturvakysymyksissä
tietojärjestelmien käyttäjiä ja toimittajia:
http://www.2014.vm.fi/vm/fi/16_ict_toiminta/009_Tietoturvallisuus
/02_tietoturvaohjeet_ja_maaraykset/index.jsp
• Uuden järjestelmän kehittämisessä pitää ensin katselmoida,
että oikeat suojausmekanismit ovat periaatteessa olemassa ja
sitten testata, että kaikki on muistettu käytännössäkin ja että
kaikki toimii turvallisesti.
Ohjelmistotekniikka
435(504)
13.7 OWASP – Nettisivustojen
tietoturva
• https://www.owasp.org, The Open
Web Application Security Project
• Organisaatio nettisivustojen
turvallisuuden parantamiseen
• Kuuluisa uhkien Top 10 –listastaan,
jota monet organisaatiot käyttävät
tietoturvatestauksensa perustana
• Monet työkalutkin keskittyvät juuri
niiden uhkien testaamiseen
• Suomessa: OWASP Helsinki
– https://www.owasp.org/index.php/Helsinki
– Sivulla paljon hyödyllistä materiaalia
Ohjelmistotekniikka
436(504)
OWASP – Nettisivustojen
haavoittuvuudet
• Esimerkkinä OWASP Top 10 – 2015
(http://owasptop10.googlecode.com/files/OWASP%20Top%2
010%20-%202015.pdf)
–
–
–
–
–
–
–
–
–
–
A1 Injection
A2 Broken Authentication and Session Management
A3 Cross-Site Scripting (XSS)
A4 Insecure Direct Object References
A5 Security Misconfiguration
A6 Sensitive Data Exposure
A7 Missing Function Level Access Control
A8 Cross-Site Request Forgery (CSRF)
A9 Using Components with Known Vulnerabilities
A10 Unvalidated Redirects and Forwards
• Näitä ei nyt ole mahdollisuuksia käydä tarkemmin läpi, mutta
kiinnostuneiden kannattaa perehtyä.
Ohjelmistotekniikka
437(504)
OWASP Testing guide
• Kattava opas tietoturvatestaukseen:
• https://www.owasp.org/index.php/OWASP_Testing_Guide_v4
_Table_of_Contents
• Huomattava, että opas käsittelee vain tietoturvallisuuden ja
haavoittuvuuksien ”teknistä testausta” – tietoriskianalyysi on
aina asia, jolla kokonaisvaltainen testausprosessi on syytä
aloittaa.
Ohjelmistotekniikka
438(504)
13.8 OWASP – Mobiiliturvallisuus
• Mobiiliturvallisuusprojektin sivut:
• https://www.owasp.org/index.php/OWASP_Mobile_Security_
Project#tab=Home
• Edelleen (kevät 2015) ”work in progress”.
Ohjelmistotekniikka
439(504)
13.9 PC-sovellusten uhista
• Toisin kuin perinteisessä testauksessa, tietoturvan
testauksessa on vähemmän hyötyä spesifikaatioista
• Sen sijaan, että testattaisiin täyttääkö ohjelmisto
spesifikaationsa, kannattaa erityisesti tutkia
– Mitä sivuvaikutuksia toteutus sallii
• Puskurin ylivuodon seurauksena voidaan suorittaa vierasta
koodia
– Miten ohjelmisto käyttäytyy ympäristönsä kanssa
• Käyttöjärjestelmäkutsut, verkkoliikenne yms.
Ohjelmistotekniikka
440(504)
Käyttöliittymän kautta tulevat uhat 1/2
• Käyttöliittymän suojaus luvattomilta käyttäjiltä esim. salasanan
avulla
– Toimiiko käyttäjän tunnistaminen oikein?
– Hyväksytäänkö heikkoja salasanoja?
• Kelpaako esim. käyttäjätunnus salasanaksi?
– Mikäli käyttäjä saa päästä käsiksi vain osaan tiedoista (esim.
kotihakemisto monen käyttäjän käyttöjärjestelmässä) toimivatko
rajoitukset oikein?
Ohjelmistotekniikka
441(504)
Käyttöliittymän kautta tulevat uhat 2/2
• Voidaanko käyttöliittymän kenttiin syöttää laittomia syötteitä
kuten liian pitkiä merkkijonoja?
– Seurauksena voi olla esim. puskurin ylivuoto, jonka seurauksena
taas voi vierasta koodia päästä suoritukseen
– Järjestelmä voi myös kaatua, mikä voi tarkoittaa palvelunestoa
eli järjestelmän tarjoamia palveluja ei voida käyttää (denial of
service)
Ohjelmistotekniikka
442(504)
Tiedostojärjestelmän kautta tulevat
uhat
• Ohjelmistojen liitynnät tiedostojärjestelmään jäävät usein
huonolle testaukselle
• Tiedostoihin kuitenkin tallennetaan salaisuuksia kuten
salasanoja, lisenssiavaimia yms.
• Windows-maailmassa registry on erityisen huono paikka
tallentaa salaisuuksia
– Unix-maailmassa sama pätee tietysti ohjelmien omiin
konfiguraatiotiedostoihin (.emacs tms.)
• Tiedostoformaattien perusteella voidaan tehdä fuzz-testausta,
joka tarkistaa kuinka robustisti tiedosto-operaatiot on
toteutettu
Ohjelmistotekniikka
443(504)
Käyttöjärjestelmän kautta tulevat uhat
• Mikäli ohjelma säilyttää muistissaan kryptattuna salaista
tietoa, on tämä yleensä turvassa; ongelmia syntyy silloin kun
tietoa käsitellään kryptaamattomana
– Esim. salasanojen hallintaohjelmat dekryptaavat vain täsmälleen
sen verran kerrallaan kuin tarvitaan
• Mikäli käyttöjärjestelmän tarjoamat resurssit vähenevät, kuten
käytettävissä olevan muistin määrä, seurauksena saattaa olla
esim.
– Palvelunesto
– Ohjelman kontrolloimaton kaatuminen
• Voidaanko salaiset tiedot dumpata levylle selväkielisinä?
Ohjelmistotekniikka
444(504)
Toisten ohjelmien kautta tulevat uhat
• Yhä suuremmassa määrin ohjelmat käyttävät muita ohjelmia
erilaisten rajapintojen kautta
• Mitä tapahtuu, jos jokin toinen ohjelma joutuu hyökkäyksen
uhriksi tai kaatuu?
• Testaajan täytyy selvittää kytkennät muihin ohjelmiin ja
selvittää tilanteet, joissa nämä saattavat aiheuttaa uhan
tietoturvalle
• Esimerkiksi kommunikoitaessa verkon kautta on syytä
varmistaa, että ohjelmisto toimii oikein laittomien pakettien,
liian lyhyiden ja liian pitkien pakettikehysten yms. kanssa
– Fuzz-testaus on tässä jälleen paikallaan
– Vastaavia huolen aiheita liittyy myös tavallisiin rajapintoihin
Ohjelmistotekniikka
445(504)
Ohjelmiston itsensä suojaaminen
• Joskus ohjelma sisältää algoritmeja yms., jotka antavat edun
kilpailijoihin nähden
• Tällöin on järkevää suojautua takaisinmallintajia vastaan,
jotka voivat yrittävät selvittää koodin sisältöä esim.
disassembleria käyttäen
Ohjelmistotekniikka
446(504)
Muita uhkia
• Monesti hyökkäykset saattavat tulla monelta rintamalta yhtä
aikaa
– Esim. blokataan sovelluksen pääsy johonkin kirjastoon ja
annetaan käyttöliittymän kautta laiton syöte samanaikaisesti
• Joskus myös ohjelmistoon sisäänrakennetut ”ominaisuudet”
saattavat tarjota turvallisuusreikiä
– Binääriin on esimerkiksi saattanut jäädä mukaan instrumentoitua
testikoodia, joka tarjoaa valmiita koukkuja testitapausten
suorittamista varten
• Yksittäisen komponentin kehittäjä on saattanut olla tietämätön
kokonaisuudesta, johon komponentti kuuluu
– Mikäli esim. parametrina välitettävä tieto on salaista, sitä ei saa
kirjoittaa edes väliaikaisesti selväkielisenä levylle
Ohjelmistotekniikka
447(504)
Avoimuuden haaste
• Testausrajapinnat voivat tarjota myös suojaukset ohittavia
reittejä sovellukseen.
• Ohjelman repositoryissä tarjolla olevat testitapausten skriptit
voivat paljastaa reittejä suojausten ohittamiseen.
– Avoimen lähdekoodin sovellusten erityinen haaste – koodi on
tarjolla kräkkereille tutustuttavaksi – yhteisön pitää huolehtia,
että aukkoja ei ole.
– Toisaalta avoimuus tekee aukkojen löytämisen ja korjaamisen
paljon todennäköisemmäksi; tietoturvaekspertit yleensä suosivat
avoimuutta.
• Joskus ohjelman koodeista löytyy tietoa testaustunnuksista,
joita hyökkääjä voi käyttää.
Ohjelmistotekniikka
448(504)
Esimerkkihyökkäyksiä sovelluksille 1/7
• Blokkaa sovelluksen kutsut (dynaamisiin) kirjastoihin
– Käytetään työkalua, jonka avulla voidaan tarkkailla mitä kirjastoja
sovellus kutsuu missäkin tilanteessa ja blokataan kutsut johonkin
tiettyyn kirjastoon
 Testataan, että sovellus ei vaaranna tietoturvaa vaikka kirjastoa
ei olisikaan saatavilla
– Mikäli yritetään kutsua kirjastofunktiota, johon pääsy on blokattu,
seurauksena on yleensä poikkeuskäsittelyn käynnistyminen
• Usein poikkeustenkäsittelijöitä ei ole testattu niin hyvin kuin
muuta koodia
• Seurauksen voi olla sovelluksen kaatuminen ja salaisten
tietojen dumppaaminen näytölle tai levylle
Ohjelmistotekniikka
449(504)
– Sovellus voi myös näyttää jatkavan toimintaa normaalin tapaan,
vaikka kirjastofunktion tarjoamaan palvelua ei olisikaan
käytettävissä
• Tämä voi olla merkki esimerkiksi siitä, että sovelluksessa ei
tarkasteta jotain paluuarvoa vaikka pitäisi
• Seurauksena voi olla jopa väärien oikeuksien myöntäminen
käyttäjälle
Ohjelmistotekniikka
450(504)
• Etsi epäilyttäviä optioita ja niiden yhdistelmiä
– Sekä komentoriviltä, että graafisen käyttöliittymän kautta
annettavien optioiden testaus on vaikeaa mahdollisten
kombinaatioiden suuren määrän vuoksi
– Mikäli testauksessa keskitytään vain käyttäjän kannalta
oleellisimpiin vaihtoehtoihin, on hyvinkin mahdollista, että
joidenkin optioiden valinnan seurauksena sovellus suorittaa
testaamatonta koodia
– Kannattaa yrittää etsiä sellaisia optioiden kombinaatioita, joiden
yhteisvaikutuksesta tietoturva voi vaarantua
– Mikäli kyseessä on vanhan ohjelman uusi versio, kannattaa
tutustua myös edelliseen versioon ja sen dokumentaatioon
Ohjelmistotekniikka
451(504)
– Mikäli jokin optio on kadonnut uuden version dokumentaatiosta,
kannattaa kokeilla vieläkö toteutus tukee sitä ja jos tukee,
toimiiko se turvallisesti
• Käyttäjältä tulevan syötteen tarkastaminen voi olla toteutettu
vain osalle optioista
– Jos sovellus kysyy esimerkiksi osoitetta, ja maa voidaan valita
ennalta määrätystä joukosta valikkoa käyttäen, voi
postinumerokentän tarkastaminen riippua siitä mikä maa valitaan
• Sovellus voi sallia ylipitkän ja kontrollimerkkejä sisältävän
postinumeron syöttämisen…
– Olisiko mahdollista syöttää SQL-lauseita ja suorittaa
niitä?
• …vai koodataan postinumerontarkastusalgoritmi myös
ulkomaisille osoitteille?
Ohjelmistotekniikka
452(504)
• Porttiskannaus
– Verkkoa hyödyntävien sovellusten on suojauduttava
porttiskannaajia vastaan
– Käytetään testauksen apuna porttiskanneria
– Testataan erityisesti sovellusspesifisten porttien käyttö (numerot
1024-65535)
– Mikäli sovellus yrittää salata avoinna olevan portin antamalla
virheilmoituksen kytkeytymisyrityksestä, täytyy virheilmoituksen
olla standardimuotoa, ettei se herättäisi epäilyksiä
Ohjelmistotekniikka
453(504)
• Etsi vaihtoehtoisia tapoja tehdä sama asia
– Kuinka monella eri tavalla voit Windowsissa avata Wordasiakirjan?
– Ovatko kaikki tavat varmasti testattu olevan turvallisia?
– How to break software security -kirjan kirjoittajat löysivät
tietoturva-aukon Windows XP:stä seuraavasti:
Ohjelmistotekniikka
454(504)
• Koska Windows Exploreria voi käyttää moneen samaan
tarkoitukseen kuin Internet Exploreria, luetaan MS Exchange
Serverin Outlook Web Access –rajapintaa käyttäen ensin
sähköpostit IE:llä siten, että käynnistetään IE WE:n kautta
• Session jälkeen suljetaan sekä WE- että IE-ikkunat
• Seuraavaksi otetaan yhteyttä WE:llä sähköpostipalvelimeen ja kas
kummaa, päästään sisään ilman salasanan kyselyä!
• Kun yritetään lukea yksittäisiä posteja erillisestä ikkunasta,
salasanaa kysytään, mutta käyttämällä Outlookin esikatselua
salasanaa ei kysyä
• Opetus: tietoturva saatiin murrettua kun käytettiin vaihtoehtoista
tapaa tehdä sama asia:
– Korvattiin Internet Explorer Windows Explorerilla
– Korvattiin Outlookin posti-ikkuna esikatselulla
• Huom! Tämä vika on sittemmin korjattu
Ohjelmistotekniikka
455(504)
Top 8 käytännöt tietoturvatestaukseen 1/2
1.
Käytä apuna asiantuntijaa konsultoimaan tai/ja tekemään. Tämä on
vaativa aihealue.
– Neuvoja projektin alussa, vaativaa testausta myöhemmin.
2. Selvitä riskit – mitä tietoja pitää suojella luotettavasti.
– Tietoturvapanostukset valitaan riskitason mukaan.
– Muista olla sopivan vainoharhainen.
– Riskianalyysi on yhteistyötä.
3. Analysoi tuotteen tekniikkaa – mitä kaikkia keinoja hyökkääjillä on
päästä käsiksi tietoihin.
– Selvitä käytettyjen teknologioiden sudenkuopat.
– Kirjastot, protokollat, ohjelmointikielet, käyttöjärjestelmien
heikkoudet…
4. Tutki ja testaa, miten suunnittelussa on varauduttu niihin.
– Toiminnallisen testauksen tekniikat.
Ohjelmistotekniikka
456(504)
Top 8 käytännöt tietoturvatestaukseen 2/2
5.
Katselmoi ja tarkasta arkkitehtuuria, suunnittelua, toteutusta,
turvamekanismeja.
– Tietovarastot, komponentit, tietoliikenne, kryptauksen käyttö.
6. Testaa kaikki suojausmekanismit hyvin (salasanat, oikeustasot,
kryptaus…).
7. Testaa, että systeemi on robusti eikä sitä saa esim. viallisilla
tiedostoilla kaadettua palvelunestohyökkäystä tai murtautumista
varten.
– Fuzz-testaus on siihen yksi keino.
– Vahva negatiivinen testaus.
8. Tutki käyttäjän toimintaa – inhimilliset virheet, tunnusten käsittelyn
realismi.
Ohjelmistotekniikka
457(504)
14. Staattisen testauksen tekniikat
Laadunvarmistajan ja testaajan työkalupakkiin
kuuluu toisiaan täydentäviä tekniikoita.
Seuraavassa tutustutaan hyväksi havaittuihin
ryhmätyötekniikoihin sekä hieman myös
automaattiseen koodin analysointiin.
Ohjelmistotekniikka
458(504)
14.1 Tarkastus
• Koostettu mukaillen lähteestä: Ahtee, Haikala, Märijärvi:
Tarkastukset (koulutusmateriaali)
• Inspection – IEEE 610.12-1990 (Standard Glossary of
Software Engineering Terminology):
– A static analysis technique that relies on visual examination of
development products to detect errors, violations of development
standards, and other problems. Types include code inspection;
design inspection.
• Projektin sisäinen, 3-6 osallistujaa
• Hyvin muodollinen verrattuna muihin ryhmätyötekniikoihin
• Aikataulutus joustavaa, useita tarkastuksia projektin vaiheen
aikana
• Tarkastetaan kerralla pieniä kokonaisuuksia
Ohjelmistotekniikka
459(504)
Tausta ja tarkoitus
• Tekniikan kehitti Fagan IBM:llä 1970-luvulla
• Tarkastuksia pidetään tehokkaimpana tunnettuna
laadunvarmistuskeinona
• Tukee prosessia ja projektia mm.
– Pyrkimällä poistamaan virheet mahdollisimman varhaisessa
vaiheessa
– Tekemällä projektin etenemisen näkyväksi
• hyväksytty tarkastus vastaa yhden etapin saavuttamista
– Jakamalla tietoa useammalle henkilölle
Ohjelmistotekniikka
460(504)
Tarkastuksen kulku
• Tarkastustilaisuus kestää n. 2 tuntia, jonka aikana voidaan
tarkastaa enintään
– 50 sivua dokumenttia tai
– 500 riviä koodia
•
•
•
•
Löydetään noin 50-80 % virheistä
Tarkastukset kuluttavat noin 5-15 % työajasta
Erittäin kustannustehokasta!
Vaikka menettely ei lisääkään työmäärää kovin paljon, johdon
sitoutuminen tarvitaan
Ohjelmistotekniikka
461(504)
Tarkastukset ohjelmistoprosessissa
Kerrasta oikein?
Spesifikaatio
(Vaihetuote n-1)
Ohjelmistotekniikka
Tee
Luonnos
OK
Tarkasta
Vaihetuote n
Työstä
462(504)
Mitä kaikkea voidaan tarkastaa?
• Tarkastaa voidaan mm.
–
–
–
–
–
–
–
Tarjous, sopimus
Määrittelydokumentti
Projektisuunnitelma
Suunnitteludokumentti
Testaussuunnitelma
Koodi
Käyttäjälle menevä
dokumentaatio
– Koulutusmateriaali
Ohjelmistotekniikka
463(504)
Tarkastustilaisuuden roolijako
•
•
•
•
•
Puheenjohtaja
Tarkastettavan vaihetuotteen tekijä
Sihteeri = usein tekijä
Tarkastaja = kaikki
Esittelijä
– Voi olla tekijä
– Vain kooditarkastuksissa
• Sovellusalueen tms. asiantuntija, kieliasun tarkastaja,
käyttäjänäkökulman edustaja, testausasiantuntija jne.
– Joku voi keskittyä muistinhallinnan tarkastamiseen, toinen
silmukoihin, kolmas algoritmeihin, neljäs rajapintoihin jne.
Ohjelmistotekniikka
464(504)
Nyrkkisääntöjä
• Mikäli ei voida tarkastaa kaikkea, keskitytään tärkeimpiin osiin
• Huolellinen valmistautuminen on erittäin tärkeää
– Tarkastettava materiaali jakoon vähintään 3 vrk etukäteen
– Tarkastustilaisuus kannattaa peruuttaa, jos sen onnistumiselle ei
ole riittäviä edellytyksiä
• Esim. liian keskeneräinen vaihetuote
• Arvioidaan aina tuotetta, ei tekijää
• Tavoitteena ongelmien löytäminen eikä niiden ratkaiseminen
• Korjaukset kosmeettisiin virheisiin voi toimittaa sihteerille
jälkikäteen
Ohjelmistotekniikka
465(504)
Muuta
• Kannattaa pohtia etukäteen sääntöjä, jotka helpottavat
kohteen tarkastamista
– Esim. “ottaako vaatimus huomioon asiakkaan todellisen tarpeen”
• Säännöt kannattaa valita huolella kohteen, organisaation,
prosessin, riskien yms. mukaan
– Jo muutamalla säännöllä päästään hyviin tuloksiin (Marko
Komssi, EuroSTAR 2004)
– Sääntöjen tarkkuutta voidaan kasvattaa prosessin edetessä
• Tarkastuksista on kehitetty IBM:llä myös sellainen versio, joka
ei edellytä etukäteisvalmistelua:
E. Farchi, S. Ur: “Selective Homeworkless Reviews”, Proceedings of the 2008
International Conference on Software Testing, Verification, and Validation IEEE
Computer Society Washington, DC, USA
Ohjelmistotekniikka
466(504)
Tarkastusten kypsyystasot
•
•
•
•
•
Tarkastuksia pidetään
Tarkastuksista on jotakin hyötyä
Tarkastukset ovat tehokkaita
Tarkastuksista kerätään tilastotietoja
Virheanalyysejä ja tarkastuslistoja tehdään
kokemusten perusteella
• Kerättyjä tietoja käytetään tarkastus- ja
ohjelmistoprosessin parantamiseen
Ohjelmistotekniikka
Hyödyllinen
projektille
Hyödyllinen
organisaatiolle
467(504)
14.2 Katselmointi
• Review, technical review
• IEEE 610.12-1990:
– A process or meeting during which a work product, or set of work
products, is presented to project personnel, managers, users,
customers, or other interested parties for comment or approval.
Types include code review, design review, formal qualification
review, requirements review, test readiness review.
• Käytetään vaiheen päättymisen toteamiseen
– Esim. määrittely- ja suunnitteluvaihe
• Katsotaan formaalisti, että kaikki vaiheen lopetusehdon
vaatimukset on täytetty
• Tavoitteena tehdä projektin eteneminen näkyväksi
– Halutaan saavuttaa konsensus, ei niinkään löytää virheitä
Ohjelmistotekniikka
468(504)
Projektin katselmukset ja tarkastukset
• [Haikala&Märijärvi 06]:
esitutkimus&
sopimus
määrittely
suunnittelu
tarkastus
katselmointi, toimittajan
ohjelmointi ja
moduulitestaus
integrointi
katselmointi, asiakas mukana
järjestelmätestaus
aika
Ohjelmistotekniikka
469(504)
Mistä kulloinkin puhutaan?
• Huom! Termejä katselmointi ja tarkastaminen käytetään
vaihtelevilla tavoilla. Usein puhutaan esim.
koodikatselmoinnista, vaikka sen luonne on tarkastaminen
• Koska kyse on kuitenkin tavoitteiltaan erilaisista tekniikoista,
on syytä selvittää etukäteen, onko tarkoitus todella
katselmoida vai tarkastaa
• Yleinen periaate: On selvitettävä, mitä organisaatiossa
tarkoitetaan erilaisilla termeillä, ettei tule väärinkäsityksiä.
Ohjelmistotekniikka
470(504)
14.3 Läpikäynti
• Walkthrough
• IEEE 610.12-1990:
– A static analysis technique in which a designer or programmer
leads members of the development team and other interested
parties through a segment of documentation or code, and the
participants ask questions and make comments about possible
errors, violation of development standards, and other problems.
• Tehdään yleensä vain koodille, tavoitteena virheiden
löytäminen
• Tekijä selittää mitä ohjelma hänen mielestään tekee
Ohjelmistotekniikka
471(504)
Läpikäynti vs. tarkastus
• Tarkastukseen verrattuna läpikäynti
–
–
–
–
–
Korostaa tekijän roolia tilaisuudessa
On epämuodollisempi
Vaatii vähemmän koulutusta
Löytää vähemmän virheitä
Ei yleensä ole yhtä kustannustehokas
Ohjelmistotekniikka
472(504)
OTE
14.4 Lähdekoodin staattinen analyysi
• Idea: analysoidaan lähdekoodia automaattisesti ilman sen
suorittamista
• Tarkoituksena
– Löytää koodista virheitä
– Huomata poikkeamia sovituista koodauskäytännöistä
(tyylioppaat)
– Generoida koodista dokumentaatiota
– Laskea arvoja ohjelman pituutta, monimutkaisuutta yms.
kuvaaville mittareille
• Hyödynnettävät tekniikat perustuvat yleensä tietoja
kontrollivuoanalyysiin, rajoitusten ratkaisemiseen (constraint
solving) yms.
Ohjelmistotekniikka
473(504)
Lint
• Ensimmäinen suuren yleisön käyttöön tarkoitettu staattinen
koodianalysaattori oli Unixin mukana levinnyt Lint
• Lintin tarkoituksena oli löytää tiettyjä C-kielelle tyypillisiä
virheitä, joita senaikaiset kääntäjän eivät havainneet
• Tunnettu kaupallinen tuote C++:lle ja C:lle PC-Lint / Flexelint
http://www.gimpel.com/html/products.htm
– Edelleen löytää paljon ongelmia, joita kääntäjä ei huomaa
Ohjelmistotekniikka
474(504)
Minkä tyyppisiä virheitä voidaan
löytää?
OTE
• Esim.
– Syntaksivirheet
– Samaa koodia useammassa kuin yhdessä paikassa, kuollut
koodi (ei suoriteta ikinä)
– Koodin ylläpidettävyys ja siirrettävyysongelmia
– Alustamattomat muuttujat
– Käyttämättömät paluuarvot
– Virheellinen osoitinten käyttö
– Puskurin ylivuodot yms. tietoturvaongelmat
Ohjelmistotekniikka
475(504)
Eräitä työkaluja
• PC-Lint, Coverity, PolySpace, KlocWork, FindBugs
• Kaupalliset työkalut tyypillisesti kalliita, mutta myös joitakin
ilmaisia avoimen lähdekoodin työkaluja löytyy
• Skaalautuvuus voi osoittautua ongelmaksi
• Väärien hälytysten määrä voi nousta suureksi
• Potentiaalisesti maksavat itsensä takaisin hyvinkin nopeasti
löytämällä arvokkaita virheitä turvallisuuskriittisestä koodista
Ohjelmistotekniikka
476(504)
Mitä apua dokumentointiin?
• Esim:
– Javadoc-tyyppinen API-dokumentaatio
– Doxygen-tyyppinen graafinen malli (UML) ohjelmistosta
• www.doxygen.org
– Kutsuhierarkia
bar1()
foo()
bar2()
Ohjelmistotekniikka
477(504)
15. Testauksen parantaminen
Seuraavaksi käsitellään testauksen
parantamista. Kaiken toiminnan jatkuva
parantaminen on tärkeää, koska muuten se
rapautuu. Ja joskus herätään tarpeeseen
kokonaisvaltaisesti arvioida ja parantaa
toimintaa kertaluonteisella kehittämisprojektilla.
Ohjelmistotekniikka
478(504)
Yleistä
• Testaustoimintaa yrityksessä pitää aktiivisesti parantaa.
– Jokainen yritys oppii vähitellen tekemään asioitaan paremmin.
– Liiketoiminnan, tuotteiden laajuuden ja yrityksen koon kasvaessa pitää
testausta pystyä tekemään paremmin ja tehokkaammin.
– On aina vaarana jumittua tekemään asioita niin kuin ennenkin.
– Siksi tarvitaan kehittämistä.
• Kolmenlaista kehittämistä:
1.
2.
3.
Jatkuva parantaminen – kun huomataan, että jokin asia ei toimi hyvin,
parannetaan sitä. Esimerkiksi testien suorittaminen on pullonkaula
projekteissa -> tehdään asialle jotain.
Parantamisprojekti, jossa tarkastellaan koko testaustoimintaa ja
mietitään sen kokonaisvaltaista kehittämistä.
Kehittäminen vastaamaan pakollisia vaatimuksia, esim. alan
standardeja.
Ohjelmistotekniikka
479(504)
15.1 Jatkuva parantaminen
• Projektien kokouksissa, katselmoinneissa ja jokapäiväisessä
työssä tunnistetaan parantamisen mahdollisuuksia.
• Jutellaan niistä kollegoiden ja päälliköiden kanssa ja
suunnitellaan, miten asia voidaan parantaa.
• Siirretään parannukset sitten muihinkin projekteihin ja
muihinkin tiimeihin.
Ohjelmistotekniikka
480(504)
15.2 Parantamisprojekti
• Tehdään toiminnan arviointi, tunnistetaan vahvuudet ja heikkoudet,
valitaan parannuskohteet ja käynnistetään parannuksia.
• Joko:
– Konsultti tekee arvioinnin ja parannustoimet jyvitetään omalle
henkilöstölle. Kootaan työryhmä ja esim. laatupäällikkö seuraa niiden
toteutusta.
– Kootaan sisäinen työryhmä ja siinä arvioidaan tilannetta ja aloitetaan
parannukset.
• Toimintatapoina yleensä eri ammattiryhmien haastattelut ja yhteiset
keskustelut.
Ohjelmistotekniikka
481(504)
Parantamisen motiivi
• Organisaatio ryhtyy parantamisprojektiin jostain syystä:
–
–
–
–
–
–
–
–
Organisaatio kasvaa.
Tuoteliiketoiminta laajenee.
Huomataan, että tuotteiden laatu ei ole riittävää.
Testaus on pullonkaula.
Tuntuu, että testaus ei ole riittävän hyvää.
Päämies vaatii parantamista.
Laatujärjestelmän auditoinnissa nousee esille puutteita testauksessa.
Jne…
• Olennaista onkin, että on yhteinen vahva tunne, että toimintaa pitää
parantaa ja johdon tuki muutoksille. Silloin saadaan muutoksia
aikaan.
Ohjelmistotekniikka
482(504)
Lähtökohtana tärkeimpien
kipupisteiden paljastaminen
• Ei ole olemassa ”parhaita käytäntöjä”, joten on hyvä
selvittää, kyseisen yrityksen tilanne ja pohtia, millaiset
parannukset todella auttavat eteenpäin. Ks. esimerkki
tällaisesta menettelystä (sisältää myös paljon
täydentävää tietoa):
• http://www.mattivuori.net/julkaisuluettelo/liitteet/testaustoi
minnan_arvioinnista.pdf
• Joskus analyysin pohjana on kuitenkin jonkin
kypsyysmallin tms. antama rakenne.
– TPI tai TMMi ovat tunnettuja tällaisia.
– TPI:n aihealueista on myöhemmin listaus esimerkkinä.
Ohjelmistotekniikka
483(504)
Ammattilaiset tuntevat ongelmat
• Kehittämisessä kannattaa yleensä luottaa organisaation
ammattilaisiin:
– He tietävät todelliset ongelmat.
– Heillä on käsitys parantamisen mahdollisuuksista.
– Heitä pitää kuunnella ja tukea, jotta parannuksia voidaan
toteuttaa.
• Miksi he eivät kehitä asioita, jos tietävät ratkaisuja?
– Olo kiinni arjessa – osana kulttuuria, joka ”sitoo kädet”.
– Puutteet kertyvät vähitellen (sammakko vesikattilassa…).
– Tarvitaan joku, joka osaa kehittämistä katalysaattoriksi ja
experttinä, jota johto kuuntelee.
Ohjelmistotekniikka
484(504)
Parantamisprojektin vaiheet 1/2
• Selvitä testausprosessin (koko prosessi tai jokin osa-alue)
tämän hetkinen taso
• Aseta tavoitteet
• Selvitä vaatimukset tavoitteiden saavuttamiseksi
– Vaatimusten pitäisi olla realistisia, täsmällisiä ja mitattavia
– Priorisoi vaatimukset
• Aloita prosessinparannusprojekti samoin kuin mikä tahansa
ohjelmistokehitysprojekti
– Tavoitteena on riittävien resurssien varmistaminen
• Laadi suunnitelma, jossa kuvataan askeleet tavoitteiden
saavuttamiseksi
– Suunnitelmaan kuuluu aikataulu, budjetti, riskit yms.
Ohjelmistotekniikka
485(504)
Parantamisprojektin vaiheet 2/2
• Toteuta muutokset vähitellen
– Resursseja ei tarvita kerralla niin paljon
– Tulosten analysointi helpompaa
– Käytä pilotointia
• Mittaa tulokset
– Vertaa mittaustuloksia suunnitelmaan
• Mikäli tarpeen, aloita jälleen ensimmäisestä askeleesta
• Mikäli prosessia aiotaan kehittää, on syytä huolehtia siitä, että
tarvittaville toimenpiteille saadaan kaikkien osapuolten
hyväksyntä
– Hyväksyntä voidaan saavuttaa esim. mittareiden avulla,
palautetta keräämällä ja hyödyntämällä, koulutuksella sekä
organisaation sisäisillä ”sponsoreilla”
Ohjelmistotekniikka
486(504)
15.3 Testaustoiminnan avainalueet –
esimerkkinä TPI
• TPI, Test Process Improvement on yksi testauksen
kehittämismalli.
• Emme käy sitä menetelmänä läpi, mutta esitämme tässä sen
jäsennyksen testaustoiminnalle.
– Se toimii runkona ja tarkistuslistana sille, mitä kaikkia osa-alueita
kannattaa tarkastella.
– Onko niille toimintatavat kunnossa ja sopivasti vakiintuneet,
riittääkö ihmisten osaaminen, ovatko välineet hyvät?
Ohjelmistotekniikka
487(504)
Avainalueiden luettelo 1/6
• Avainalueet (20 kpl)
– Testausstrategia
• Strategian täytyy keskittyä löytämään tärkeimmät virheet
mahdollisimman aikaisin ja halvalla
• Määrittelee mitkä testit kattavat vaatimukset ja laaturiskit
• Kokonaisstrategian laatuun vaikuttaa eri testaustasojen
strategioiden laatu ja yhteensopivuus
– Testausprosessin elinkaarimalli
• Suunnittelu, valmistelu, määrittely, suoritus ja viimeistely
• Parantaa ennustettavuutta
• Mahdollistaa testausprosessin säätämisen
Ohjelmistotekniikka
488(504)
– Testauksen aikainen mukaantulo ohjelmistokehitykseen
• Vaikka testit ajettaisiin vasta kehitysvaiheen lopulla,
testausprosessin täytyy alkaa jo paljon aikaisemmin
– Estimointi ja suunnittelu
• Mitä pitää tehdä, koska ja millä resursseilla (ihmiset)
• Perusta resurssien allokoinnille
– Testien spesifiointitekniikat
• Testitapausten laadun ja ”syvyyden” arviointi
• Testitapausten uudelleenkäytettävyys
– Staattisen testauksen tekniikat
• Esim. tarkistuslistojen käyttö
Ohjelmistotekniikka
489(504)
– Mittarit
• Testausprosessin kannalta tärkeät mittarit kuvaavat
prosessin etenemistä ja testikohteen laatua
• Kun prosessia parannetaan, mittareita käytetään arvioimaan
toimenpiteiden vaikutusta
– Testaustyökalut
• Mm. parempi motivaatio testaajilla vs. manuaalinen testaus
– Testiympäristö
– Testaajien työympäristö
• Motivaatio, kommunikaatio, työn tehokkuus
– Sitoutuminen ja motivaatio
• Sekä johto- että suoritusporras (resurssien allokointi yms.)
Ohjelmistotekniikka
490(504)
– Tietotaito ja koulutus
• Testaustiimin koostuminen ihmisistä joiden tiedot ja taidot
täydentävät toisiaan, esim. sovellusalueen ja organisaation
tuntemus, ohjelmointi- ja sosiaaliset taidot
• Kouluttaminen paikkaa puutteita
– Menetelmien laajuus
• Käytettyjen menetelmien pitäisi olla toisaalta riittävän laajoja
kattamaan kaikki käyttötarpeet ja toisaalta tarpeeksi
yksityiskohtaisia ettei samoja asioita joudu miettimään aina
kun menetelmää sovelletaan
– Kommunikaatio
• Sekä testiryhmän sisällä, että sidosryhmiin sen ulkopuolella
kuten kehittäjät, asiakkaat, käyttäjät
• Mm. edistymisestä ja laadusta tiedottaminen
Ohjelmistotekniikka
491(504)
– Raportointi
• Testaus on laadun mittaamista ja tietoa laadusta täytyy
välittää eteenpäin
– Virheiden hallinnointi
• Johdolle pitää tarjoa keinot virheen elinkaaren selvittämiseen
• Laatutrendien selvittäminen ja analysointi, jonka avulla
voidaan antaa perusteltuja neuvoja laadun parantamiseksi
– Testwaren hallinnointi
• Ylläpidettävyyden ja uudelleenkäytettävyyden varmistaminen
vaativat hallinnointia
• Testwaren versionhallinta
– Testausprosessin johtaminen
Ohjelmistotekniikka
492(504)
– Arviointi (katselmoinnit yms.)
• Arvioidaan kaikkia vaihetuotteita kuten vaatimuksia ja
toiminnallista suunnittelua
• Tarkoituksena löytää virheet ennen varsinaista testausta
– Matalan tason testaus (yksikkö- ja integrointitestaus)
• Tavoitteena virheiden löytäminen mahdollisimman aikaisin
• Virheen tekee, löytää ja korjaa yleensä sama ihminen
– tehokasta, koska kommunikointia ei tarvita paljon
Ohjelmistotekniikka
493(504)
15.4 Parantaminen vastaamaan standardien
vaatimuksia
• Varsinkin turvallisuuskriittisten järjestelmien kehittämisessä on
markkinoilla toimimisen edellytys se, että tuotekehitys ja siinä
testaus noudattaa tiettyjä turvallisuusstandardeja.
• Standardit vaihtelevat toimialoittain ja maittain.
• Sovellettavan standardin valinnassa on joskus valinnanvaraa,
eli kannattaa tarkkaan harkita, mihin sitoutuu.
• Yksi hyvä esimerkki sellaisesta standardista on IEC 61508-3
• Functional safety of electrical/electronic/programmable
electronic safety-related systems - Part 3: Software
requirements
Ohjelmistotekniikka
494(504)
IEC 61508-3:n vaatimuksia testaukselle
• Se asettaa vaatimuksia mm. seuraaville alueille:
–
–
–
–
–
–
Vikaantumisten mallintaminen.
Testaustekniikat.
Testikattavuus.
Mallipohjaisen testauksen käyttö kriittisimmissä järjestelmissä.
Suorituskykytestaus.
Staattinen analyysi, katselmoinnit.
• Ks. ”Testing of safety-critical software – some principles”
• https://noppa.oulu.fi/noppa/kurssi/811601s/luennot/811601S_l
ecture_11__vuori.pdf
Ohjelmistotekniikka
495(504)
15.5 Testaajien sertifiointi – ISTQB
• Ks. www.istqb.org, Suomessa http://www.fistb.fi/
• Henkilökohtainen sertifikaatti, jolla "todistetaan" tietty
osaaminen
– Kolme tasoa: perustaso (foundation), advanced, expert
•
Korvaa aiemman ISEB-sertifikaatin
•
Perustason sertifikaatti hankitaan usein monivalintakokeella kolmen
päivän kurssin jälkeen
•
Osaamissisällöt (syllabus) julkisia, pyrkivät kuvaamaan globaalin
konsensuksen hyvästä testauksesta
•
ISTQB julkaissut myös laajan testaussanaston
Ohjelmistotekniikka
496(504)
Saanut kritiikkiä
•
Edistääkö parasta osaamista?
•
Ei ota erilaisia konteksteja huomioon
•
Sopiiko ketterään toimintaan?
•
Vaikka pitäisi olla voittoa tavoittelematon, onko se kuitenkin
lähinnä rahantekokone koulutusyrityksille
•
Mitä monivalintakokeesta selviytyminen todistaa?
Ohjelmistotekniikka
497(504)
16. Kurssin loppukaneetti 1/3
• Testauksen maailma on monimuotoinen ja laaja.
• Tällaisella kurssilla ehditään tarkastella siitä vain tiettyä osaa.
• Tämä kurssi on vain alkulaukaus ja mahdollistaa
syvällisemmän perehtymisen testaukseen ja ainakin sen
ymmärtämisen, miksi ja miten sitä tehdään ja millaisia asioita
sen tekemiseen liittyy.
• Monet löytävät testaamisen parista itselleen ammatin, jossa
pääsevät toteuttamaan pyrkimyksiään motivoituneina
•
Ks. seuraavan sivun mindmappi.
Ohjelmistotekniikka
498(504)
Kurssin loppukaneetti 2/3
1. Tekniikan, laitteiden ja järjestelmien
ymmärtäminen
• Uteliaisuus, miten asiat toimivat ja mitä
kaikkea ne sietävät
• Laadun ymmärtäminen kokeellisesti, omin
käsin ja aivoin
• Kaikenlaisiin tuotteisiin tutustuminen
• Intellektuaalinen harrastus, leikki
• Suunnittelijan haastaminen – ja voittaminen
6. Menestymis- ja onnistumishalu
• Olla hyvä jossain hyvä, paras,
erottua muista
• Rahan tekeminen
• Liiketoiminnan parantaminen
• Tuotteiden menestyminen
• Liittyminen menestyvään
tuotekehitykseen
• Positiivisen jäljen jättäminen
(vaikkei sitä huomaisikaan)
Ohjelmistotekniikka
2. Maailman parantaminen
• Parempia tuotteita ihmisille
• Työturvallisuus ja tuoteturvallisuus
(tietynlaisilla tuolleilla)
• (Testavista asioista ja testauksen kohteista
riippuvat erityisasiat)
Testaus
intohimona
5. Laadun estetiikka
• Virheettömyyden estetiikka
• Teknologian täydellistyminen
• Tahto "maailman toimimiseen"
• Oman maailman kontrollitahto
3. Edistystahto
• Uuden teknologian turvallisuus
(ydinvoima)
• Missioiden onnistuminen
(avaruuden valloitus; ilmaherruus)
• Kompleksin teknologian hallinta
• Teknologian edistäminen
4. Ammattimainen identiteetti
• Vastuuntunto
• Työn tekeminen, jolla on
positiivisia vaikutuksia
• Ohjelmistokehittäjien auttaminen
• Asiakkaiden auttaminen
• Loppukäyttäjien puolestapuhuja
• Onnistuminen tiiminä, yhdessä
• Perfektionismi (tekniikan)
499(504)
Kurssin loppukaneetti 3/3
• Voisiko vain käyttää "parhaita käytäntöjä"?
• Oikeasti ei ole olemassa "parhaita käytäntöjä", on olemassa
vain yleisiä käytäntöjä. Ja jossain kohtaa alan paras tapa
muuttuu aina vanhanaikaiseksi.
• DI:n pitääkin pystyä arvioimaan, millaisia keinoja voisi käyttää
jossain ympäristössä ja tilanteissa, jotta testaus täyttäisi
tavoitteensa: tuottaisi oikeaan aikaan mahdollisimman hyvin
sellaista tietoa, jota tarvitaan liiketoiminnassa, tuotteiden ja
järjestelmien kehittämisessä, hankinnoissa jne...
Ohjelmistotekniikka
500(504)
Top 10 pointit
1. Testaus pitää ottaa vakavasti, mutta siitä pitää iloita
2. Testaus on normaali osa kypsän softakehityksen arkista
toimintaa
3. Aloita testaus aikaisin ja tee sitä jatkuvasti
4. Testaukseen pitää olla aikaa – vasta testattu on "done"
5. Ymmärrä käyttöä ja tuotteen riskejä
6. Priorisoi testausta ja panosta tärkeimpien asioiden
testaukseen
7. Kehittäjän ja käyttäjän ajattelumallit ovat aina erilaiset –
hyväksymistestaus on asiakkaan asia ja haaste
8. Testauksessa ei ole hopealuoteja
9. Hyvä testaus on monimuotoista
10. Testaustavat pitää sovittaa kontekstiin, projektin
kriittisyyteen ja tuotteen vaatimuksiin
Ohjelmistotekniikka
501(504)
Kirjallisuutta 1/3
• Testauksesta kertovien kirjojen määrä on erittäin suuri. Tässä
listassa on muutamia, kalvosarjassa viitattuja yleiskäyttöisiä
perusteoksia. Kaikenkattavia kirjoja ei ole, varsinkaan
suomeksi.
• [Broekman&Notenboom 02] B. Broekman, E. Notenboom: Testing
Embedded Software (2002) – yksi näkökulma sulautettujen
järjestelmien testaukseen, Multiple V -malli
• [Craig&Jaskiel 02] R. Craig, S. Jaskiel: Systematic Software Testing
(2002) – mukavasti kirjoitettu systemaatisen testauksen kirja
• [Crispin&Cregory 09] Crispin, Lisa & Gregory, Janet. 2009. Agile
Testing. A Practical Guide For Testers and Agile Teams. AddisonWesley. 554 p. – ketterän testauksen arvostettu teos
• [Fewster&Graham 99] M. Fewster, D. Graham: Software Test
Automation (1999) – testiautomaation perusteos
Ohjelmistotekniikka
502(504)
Kirjallisuutta 2/3
• [Haikala&Märijärvi 06] I. Haikala, J. Märijärvi: Ohjelmistotuotanto,
11. painos (2006) – vielä toistaiseksi ainoa suomenkielinen
ohjelmistojen testausta käsittelevä kirja, jossa testaukselle on
omistettu yksi luku
• [Jorgensen 02] P.C. Jorgensen: Software Testing: A Craftsman’s
Approach (second edition, 2002) – analyyttisen koulukunnan
näkemys testaukseen
• [Kaner et al. 02] C. Kaner, J. Bach, B. Pettichord: Lessons Learned
in Software Testing: A Context-Driven Approach (2002) –
kontekstiohjatun koulukunnan 293 pientä oppituntia kaikesta mikä
liittyy testaukseen, korostaa tutkivaa testausta, ei kannata lukea
ensimmäiseksi
• [Myers et al. 04] G.J. Myers, T. Badgett , T.M. Thomas, C. Sandler:
The Art of Software Testing (2004) – klassikon uudistettu painos
Ohjelmistotekniikka
503(504)
Kirjallisuutta 3/3
• [Pezzè&Young 07] M. Pezzè, M. Young: Software Testing and
Analysis: Process, Principles, and Techniques – yhdistää
testauksen kansanperinnettä ja formaalimpia lähestymistapoja
• [Rothman 07] J. Rothman. 2007. Manage It! Your Guide to Modern,
Pragmatic Project Management – hieno kirja ohjelmistoprojektien
hallinnasta
• [Utting&Legeard 07] M. Utting, B. Legeard: Practical Model-Based
Testing – A Tools Approach (2007) – ensimmäinen mallipohjaisen
testauksen käytännönläheinen oppikirja
• [Whittaker&Thompson 03] J. Whittaker, H. Thompson: How to Break
Software Security (2003) – ”avaimet käteen” -paketti
tietoturvatestauksen aloittamiseksi
Ohjelmistotekniikka
504(504)

Luentokalvot - Tieto- ja sähkötekniikka

Transcription

Similar documents

tulostettavaksi

Toimitusehdot - Elisa Omaguru

Testauksen suunnittelu ja dokumentointi Suunnittelun merkitys

Henkilöarvioinnin työvälineet

Helpson-tukipalveluehdot yritysasiakkaille

Tekniikkakartta

Ohjelmistoala - Toimialaraportit

johdanto_testaukseen..

Erik Piispa