Järjestelmätestaus (1/20)

1. 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ä.''

2. Järjestelmätestaus(2/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.

3. Järjestelmätestaus(3/20) 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.

4. Järjestelmätestaus(4/20) Oliokeskeisiä testausstrategioita (testausmalleja) Binder (2000) esittelee kolme mallia (test patterns), jotka eivät ole toisensa 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.

5. 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. Järjestelmätestaus(5/20)

6. Järjestelmätestaus(6/20) Esimerkki (Binder): pankkiautomaatin KT ''aloita istunto''. • 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.

7. Järjestelmätestaus(7/20) 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ä.

8. Järjestelmätestaus(8/20) 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.

9. Järjestelmätestaus(9/20) 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.

10. Pankkiautomaattiesimerkki (Binder) • On laskettu, että budjetti riittää 834 testitapaukseen. Järjestelmätestaus(10/20) Myös eri KT:ten testitapausten järjestys (lomitus) on tärkeä. • Satunnaistettu • Suunnitellut KT-sekvenssit (todellisen käytön mukaan) • Entä rinnakkainen suoritus?

11. Järjestelmätestaus(11/20) 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.

12. Järjestelmätestaus(12/20) 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.

13. Järjestelmätestaus(13/20) 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ä.

14. Järjestelmätestaus(14/20) 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.

15. Järjestelmätestaus(15/20) 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ö.

16. Järjestelmätestaus(16/20) 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)

17. Järjestelmätestaus(17/20) 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).

18. Järjestelmätestaus(18/20) 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ä.

19. Järjestelmätestaus(19/20) 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.

20. Järjestelmätestaus(20/20) 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.