järjestelmätestaus (1/20)

Tässä käsitellään myös muuta kokonaiseen järjestelmään kohdistuvaa testausta kuin järjestelmätestausta ahtaassa mielessä:● Hyväksymistestaus (katsotaan tavallisesti eri testaustasoksi).● Alfatestaus: riippumattoman testiryhmän ja/tai asiakkaan suorittama yleensä kehittäjän tiloissa.● Beetatestaus: asiakkaan tai potentiaalisten käyttäjien itsenäisesti suorittama, josta raportoidaan kehittäjälle.

Beizerin (1990) määritelmä:''Järjestelmätestaus pyrkii paljastamaan virheitä, joiden ei voida katsoa olevan komponenteissa sellaisinaan, komponenttien välisessä yhteensopimattomuudessa eikä komponenttien ja muiden olioiden välisissä suunnitelluissa vuorovaikutuksissa; järjestelmätestaus koskee sellaisia seikkoja ja sellaista käyttäytymistä, jotka voivat paljastua vain testaamalla koko integroitua järjestelmää tai huomattavaa osaa siitä.''

Järjestelmätestaus (1/20)

Ei ole nykyään yleensä yhtenäinen, viimeinen testausvaihe.● Hyödyllistä päästä aloittamaan mahdollisimman varhain.● Inkrementaalisessa kehityksessä jokaisen inkrementin jälkeen.

Tapahtuu mahdollisimman aidossa ympäristössä.● Ei kuitenkaan asiakkaan tuotantoympäristössä.● Miten ympäristö saadaan mahdollisimman samanlaiseksi (laitteistot, verkko, muut ohjelmistot)?● Joidenkin ohjelmistojen pitää toimia hyvin monenlaisissa ympäristöissä.

●Vain jokin otanta voidaan ottaa testaukseen.● Ympäristön raja on sumea: kaukaisetkin asiat voivat vaikuttaa.● Miten ympäristöä voitaisiin testata?

● Ohjelmiston tekemät oletukset ympäristön palveluista ja käyttäytymisestä.● Ei yleensä käsitellä kirjallisuudessa.


Perustuu yleensä vaatimuksiin.● Voidaan pitää joko järjestelmän todentamisena (verification) tai kelpuutuksena (validation).● Usein kriteerinä myös asiakkaan tai käyttäjän tyytyväisyys (selvästi kelpuutusta).● Tosiasiallisia vaatimuksia on etsittävä muualtakin kuin virallisesta vaatimusmäärittelystä.

● Ks. kalvosarja 2:n (Testaus ohjelmistokehityksen osana) loppua.● Esim. prototyypit yms. mallit, dokumentointi, opastustiedostot, esitemateriaali, kilpailevat tuotteet.


Oliokeskeisiä testausstrategioita (testausmalleja)

Binder (2000) esittelee kolme mallia (test patterns), jotka eivät oletoisensa poissulkevia vaihtoehtoja.

Laajennettuihin käyttötapauksiin perustuva testi

Käyttötapaukset (KT) ovat keskeinen käsite UML:ssä ja myös joissakin muissa oliokeskeisissä mallinnuskielissä ja menetelmissä.● Käyttötapauskaaviot sisältävät hyvin vähän informaatiota.● Usein suositellaan KT:n logiikan ja toiminnan kuvaamiseen sekvenssi- tai yhteistoimintakaaviota.● Luonnollisemmalta tuntuu aktiviteettikaavio.

● Vastaa vuokaaviota korkeammalla abstraktiotasolla.● Kaaviot eivät sinänsä erottele mustalaatikko- ja lasilaatikkonäkökulmaa.


● Binderin laajennettuihin käyttötapauksiin (LKT) sisältyy seuraavia tietoja, joiden perusteella testitapauksia voidaan suunnitella:● Käyttötapauksen kaikkien operaatiomuuttujien (operational variable) arvoalueet.● Operaatiomuuttujien vaaditut syöte-tulostesuhteet.● Kunkin KT:n suhteellinen yleisyys.● Eri KT:ien väliset peräkkäisyysriippuvuudet.Operaatiomuuttujiksi on katsottava sellaiset syötteet, tulosteet ja ympäristöehdot, jotka● aiheuttavat merkittävää eroa toimijoiden käyttäytymiseen,● abstrahoivat testattavan järjestelmän tilaa tai● aiheuttavat merkittävästi erilaisen järjestelmän vasteen.

Kutakin KT:ta koskevista vaatimuksista johdetaan operaatiomuuttujien välinen operaatiorelaatio (operational relation)● Päätöstaulu, jossa ehtoina ovat muuttujien arvojen ekvivalenssiluokat.


Esimerkki (Binder): pankkiautomaatin KT ''aloita istunto''.


Variantti Kortin PIN Syötetty PIN Pankin vastaus Tilin tila Ilmoitus Käsittely

1 Kelvoton Syötä pankkikortti Poista

2 Kelvollinen Oikea Tunnistaa Suljettu Ota yhteys pankkiin Poista

3 Kelvollinen Oikea Tunnistaa Aktiivinen Valitse toiminto Ei mitään

4 Kelvollinen Oikea Ei tunnista Yritä uudestaan myöhemmin Poista

5 Kelvollinen Väärä Anna oikea PIN Ei mitään

6 Peruutettu Tunnistaa Kortti ei kelpaa Nielaise

7 Peruutettu Ei tunnista Kortti ei kelpaa Poista

● 4 operaatiomuuttujaa (OM), 2 toimintosaraketta.● Kullakin OM:lla vain 2 tai 3 ekvivalenssiluokkaa (peruutettu PIN ?).● Tyhjä ruutu: muuttujan arvolla ei ole vaikutusta.● Virheellisen PIN:in käsittely liiaksi yksinkertaistettu.● Kaikki variantit ovat toisensa poissulkevia.


Yleisessä tapauksessa vaadittavat testitapaukset:● Vähintään yksi tosi ja yksi epätosi tapaus kullekin variantille.

● Jälkimmäinen toteutuu automaattisesti, jos variantit ovat toisensa poissulkevia.

● Tarvittaessa useita tosia tapauksia samasta variantista.● Ekvivalenssiluokittelu ja raja-arvoanalyysi, kuten yksikkötestauksen yhteydessä esitettiin.● Mahdollisesti OATS tms. otanta, jos kombinaatioita tulisi liikaa.

Jo laajennettujen käyttötapausten määritteleminenkin voi paljastaa puutteita ja virheitä alkuperäisissä vaatimuksissa ja määrittelyissä.

Kata perusoperaatiot (Covered in CRUD)

Pyritään kattamaan kaikkien sovellusalueluokkien kaikki perusoperaatiot.● Sovellusalueluokka tarvitaan mallinnukseen riippumatta toteutuksesta.

● Esim. tilaustenkäsittelyjärjestelmässä Asiakas, Tilaus ja Tuote, mutta ei Linkitetty_lista.

● Perusoperaatiot ovat luonti, lukeminen, päivitys ja tuhoaminen (Create, Read, Update, Delete -> CRUD).● Oliokeskeisessä ohjelmistossa tuntuisi paremmalta tavoitteelta kattaa kaikkien ao. luokkien kaikki julkiset operaatiot kuin vain lukeminen ja päivitys.

Menettelytapa:● Tutkitaan, mitkä perusoperaatiot tulevat kullekin luokalle tehdyiksi KT:iin perustuvilla testitapauksilla.● Suunnitellaan lisää testitapauksia puuttuvien operaatioiden testaamiseksi.


Testauksen jakaminen profiilin perusteella (Allocate Tests by Profile)

Käyttöprofiili (operational profile) on varsinkin luotettavuuden testaamisessa tärkeä käsite.● Tiedetty tai arvattu eri toimintojen (tässä käyttötapausten) jakautuma ohjelmiston todellisessa käytössä.

Usein ei voida ajaa niin monta testitapausta, kuin edelliset testistrategiat vaatisivat.● Jaetaan testit eri KT:ille ensi sijassa niiden suhteellisen yleisyyden mukaan.● Jokin harvoin tapahtuva KT voi kuitenkin olla hyvin kriittinen tai muuten tärkeä.

● Esim. tietokanta avataan kerran, ja sen jälkeen siihen voidaan kohdistaa hyvin monia toimintoja.

● Harvinaisessa KT:ssa voi olla suuri virheriski, koska sen toiminta ja toteutus on monimutkainen.● Yleinen KT voi olla hyvin yksinkertainen.


Pankkiautomaattiesimerkki (Binder)● On laskettu, että budjetti riittää 834 testitapaukseen.


Käyttötapaus Todennäköisyys Testitapauksia

Aloita istunto 0,37 308

Nosta käteistä 0,18 150

Pane säästötilille 0,15 125

Pane shekkitilille 0,12 100

Tilisiirto 0,08 67

Saldon kysely 0,06 50

Setelitäydennys 0,02 17

Setelien poisto 0,02 17

Yhteensä 1 834

Myös eri KT:ten testitapausten järjestys (lomitus) on tärkeä.● Satunnaistettu● Suunnitellut KT-sekvenssit (todellisen käytön mukaan)● Entä rinnakkainen suoritus?

Transaktiovuon testaus (Beizer, 1990): transaction flow

Transaktio tarkoittaa tässä suunnilleen samaa kuin käyttötapaus (KT:n ilmentymä).● Toimintokokonaisuus (unit of work) järjestelmän käyttäjän näkökulmasta.● Käsittää yleensä sekä järjestelmän, käyttäjän että mahdollisesti ympäristön toimenpiteitä.● Eri asia kuin tapahtuma (transaktio) tietokannassa.

Transaktiovuoverkko muistuttaa vuokaaviota, mutta siinä on tärkeitä eroja:● Solmu tarkoittaa usein kokonaisen ohjelman tai ison ohjelmanosan suoritusta.● Transaktio voi haarautua useiksi rinnakkaisiksi transaktioiksi.● Erilliset transaktiot voivat yhtyä.● Käynnissä olevan transaktion mukana kulkee myös dataa.

● Eräänlainen olio, joka liikkuu verkossa.


Verkon haarautumissolmu voi tarkoittaa kolmea asiaa:● Vaihtoehdot kuten tavallisessa vuokaaviossa (predikaattisolmu). ● Entinen transaktio jatkuu, ja aloitetaan uusi transaktio toiseen haaraan (Beizer: bioosi).● Entinen transaktio loppuu, ja aloitetaan uusi transaktio kumpaankin haaraan (Beizer: mitoosi).

Myös haarojen yhtyminen voi tarkoittaa kolmea asiaa:● Vaihtoehtojen yhtyminen kuten tavallisessa vuokaaviossa.● Toinen transaktio jatkuu, toinen loppuu (Beizer: absorptio).● Molemmat entiset transaktiot loppuvat, ja aloitetaan uusi (Beizer: konjugaatio).

Verkon topologia:● Ei välttämättä ole eikä tarvitsekaan olla rakenteinen.● Silmukoita on yleensä vähän.● Normaalitoiminnan polut ovat yleensä suhteellisen yksinkertaisia.● Poikkeus- ja virhetilanteiden polut voivat olla mutkikkaita.

● Kaikkia ei ehkä kannata kuvatakaan verkossa.


Transaktiovuoverkkoon perustuva testaus:● Tavoitteena vähintään haarakattavuus.● Tärkeimmät polut ovat yleensä hyvin helppoja herkistää.● Harvinaisten poikkeustilanteiden polkujen saaminen toteutetuksi voi olla hyvin vaikeaa.● Instrumentointia tarvitaan.

● Lisärasite paljon pienempi kuin yksikkötestauksessa, koska jäljitettävät kokonaisuudet ovat isompia.

● Monissa tapahtumankäsittelyjärjestelmissä transaktioiden seuranta on valmiiksi olemassa.

● Kuhunkin aktiiviseen transaktioon liittyy oma kontrollilohko.

● Automaatio välttämätön isoissa järjestelmässä:● Erilaisia transaktioita voi olla tuhansia.● Regressiotestausta tarvitaan tiuhaan.

Beizer: Suuri osa järjestelmätestauksessa paljastuvista virheistä on transaktiovuovirheitä.● Varsinkin jos transaktioita ei ole suunniteltu perusteellisesti.● Ainakin jos yksikkö- ja integrointitestaus ovat riittäviä.


Ei-toiminnalliset ominaisuudet● Voidaan testata useimmiten vasta järjestelmätasolla.● Yleensä testeissä ei samalla tarkisteta tulosten oikeellisuutta (oraakkelia ei tarvita).

Suorituskyky (performance)

Eriluonteisille järjestelmille käytetään erilaisia tyypillisiä kriteerejä.● Eräajojärjestelmä: eri töiden pisimmät hyväksyttävät läpimenoajat; kokonaissuorite tiettynä ajanjaksona.● Tosiaikajärjestelmä: kyky reagoida tapahtumiin (signaaleihin).

● Peräkkäisten tapahtumien välinen aika vähintään S.● Hyväksyttävä vasteaika enintään I.

● Vuorovaikutteiset järjestelmät: pisin hyväksyttävä vasteaika (käyttäjän odotusaika).● Kaikissa saatetaan määritellä erikseen keskimääräinen ja huonoimman tilanteen suorituskyky.


Vaaditut resurssit ● Ohjelmiston vaatima keskusyksikköaika, muistitila, tiedosto- ja tietokantatila, verkkoliikenne yms.● Ei useinkaan mainita erikseen.

Kuormitustestaus (capacity / load / volume testing): Suorituskykyä haittaavia tekijöiden tasoa nostetaan, esim.:● syötetiedon määrä● palvelupyyntöjen taajuus● saman järjestelmäntoiminnan tai -palvelun samanaikaisten pyyntöjen määrä● samanaikaisten käyttäjien määrä● saman käyttäjän rinnakkaisten toimintojen määrä● ulkoiset tekijät, esim. keskusyksikön käyttö.


Luotettavuus (reliability) ja virhesietoisuus (fault tolerance)

Yleisiä luotettavuuden mittoja:● Pyynnön häiriötodennäköisyys (probability of failure on demand, POFOD): epäonnistumisten osuus palvelupyyntöjen kokonaismäärästä.● Keskimääräinen häiriöväli (mean time to/between failure, MTTF / MTBF)● Häiriötaajuus (rate of failure occurrence, ROCOF)● Käytettävyys (vanhassa merkityksessä: availability)

● Tärkeä ominaisuus monille järjestelmille.● Testaamisesta ei yleensä puhuta paljon.● Tavallisin määritelmä: kuinka suuri osa tarkoitetusta käyttöajasta järjestelmän pitää olla toiminnassa (käytettävissä).

● Joskus myös keskimääräinen korjausaika (mean time to repair, MTTR)


Rinnakkaisuustestaus (concurrency testing)● Ajetaan rinnakkain mahdollisimman monia sellaisia toimintoja, joiden välillä voisi sattua lukkiutumia, kilpailutilanteita tms. ongelmia.● Häiriöiden huomaaminen savutestin tasolla (Binder, 2000).

Rasitustestaus (stress testing)● Kuormitusta lisätään, niin ettei normaali toiminta ole mahdollista.● Järjestelmän pitää käyttäytyä järkevästi, esim.

● Osa palvelupyynnöistä jätetään toteuttamatta.● Annetaan virheilmoituksia.● Järjestelmä kaatuu hallitusti.

Uudelleenaloitus- ja toipumistestaus (restart/recovery testing)● Järjestelmän osia (esim. yksittäisiä koneita, verkkoyhteyksiä) poistetaan äkillisesti käytöstä erilaisilla mahdollisilla tavoilla (esim. virran katkaisu).


Sekalaisia

Turvallisuustestaus (security testing)● Ks. kalvosarja tästä aiheesta

Konfiguroinnin ja yhteensopivuuden testaus● Erilaiset ympäristöt ja alustat

Järjestelmätestauksen lopetuskriteerejä

● Toinen ääripää: pelkästään tulosten perusteella.● Erilaiset kattavuuskriteerit.● Jäljellä olevien virheiden määrä (arvioitu).

● Toinen ääripää: pelkästään käytettävien resurssien (rahan ja ajan) perusteella.

● Esim. testauksen jakaminen profiilin perusteella.● Useimmiten otetaan huomioon molemmat tekijät.

● Esim. lopetetaan, kun testauspäivää kohti löydetään jotakin raja-arvoa pienempi määrä uusia virheitä.


Lopetuspäätös on kriittisempi kuin alemmilla testaustasoilla.● Jos esim. yksikkötestaus on vaillinainen, virheitä voidaan löytää vielä myöhemmissä vaiheissa.● Järjestelmätestauksen (hyväksymistestauksen) jälkeen ohjelmisto luovutetaan käyttöön jäännösvirheineen.

Testauksen keskeytys- ja jatkamispäätökset:● Kun on löydetty liian paljon tai liian pahoja virheitä, ne on korjattava ennen testauksen jatkamista.● Myös alemmilla testaustasoilla.

Luotettavuuden paraneminen (Software Reliability Growth, SRG):● Oikeastaan virheiden väheneminen.● Matemaattisia malleja, jotka kuvaavat virheiden kokonaismäärän, käytetyn testausajan ja havaittujen virheiden määrän yhteyttä.● Jäännösvirheiden määrä estimoidaan tilastollisesti. ● Virheiden vakavuuseroja ei oteta huomioon.


IBM:ssä usein käytetyt kriteerit:● Kaikki havaitut 1. ja 2. vakavuusasteen (neljästä) ongelmat on korjattu.● Analyysi osoittaa, että testaus on ollut tarpeeksi tehokasta ja monipuolista.● Analyysi osoittaa, että järjestelmä on saavuttanut riittävän stabiiliuden sekä toiminnallisuuden että luotettavuuden osalta.

Näiden arviointiin tarvitaan testauksesta kerättyä tilastollista tietoa.


järjestelmätestaus (1/20)

Documents