. Järjestelmätestaus (B, ) Järjestelmätestaus (system testing) tehdään integrointitestauksen jälkeen. Siinä järjestelmää testataan kokonaisuutena, johon kuuluvat ohjelmiston lisäksi laitteisto ja järjestelmän kanssa yhteistyössä toimivat ulkoiset ohjelmat. Ennen järjestelmätestausta kaikki järjestelmään kuuluvat ohjelmistot on verifioitu ja validoitu erikseen. Järjestelmätestauksen vaatimukset Järjestelmätestauksessa vaaditaan, että seuraavat asiat ovat kunnossa: Järjestelmästä on saatavilla todellisuutta vastaava testattava systeemitason kuvaus. Toiminnalliset vaatimukset (järjestelmältä vaaditut toiminnot) on dokumentoitu yhtenevästi. Eitoiminnalliset vaatimukset (järjestelmän laatuvaatimukset ja reunaehdot) on dokumentoitu yhtenevästi. Järjestelmän käyttötapaukset tai vähintään käyttäjävaatimukset on dokumentoitu yhtenevästi. Järjestelmätestauksen korkean tason testausstrategia Järjestelmätestaus on vastuupohjaista. Järjestelmä testataan käyttöliittymiensä kautta. Toteutustapa, kuten oliopohjaisuus, ei ole enää näkyvissä. Toki toteutuspohjaisia testejä voidaan ajaa myös järjestelmätasolla. Järjestelmät ovat kuitenkin yleensä niin suuria, että saatujen kattavuuksien tulkinta ei ole suoraviivaista. Lisäksi integrointitestauksessa on jo täydennetty vastuupohjaisia testejä toteutuspohjaisilla testeillä. Integrointitestauksessa on jo testattu koko Järjestelmätestaus ja vaatimukset Järjestelmätestaukseen vaaditaan täydelliset, yhtenäiset ja testattavat vaatimusten kuvaukset. Myers totesi jo 7 näin: If you do not have written objectives for your product, or if your objectives are unmeasurable, then you cannot perform system test Toisin sanottuna Myers sanoo, että sekä testausstrategian että lopetusehdon kehittäminen ilman kunnollista dokumentaatiota ei onnistu. ohjelmisto. Järjestelmätason suunnittelumallit Extended Use Case Test Binder listaa kolme järjestelmätason testauksen suunnittelumallia: Extended Use Case Test Käyttötapauksesta johdettavien testitapausten suunnittelu. Covert in CRUD Järjestelmän perustoiminnot kattavien testitapausten suunnittelu. Allocate Test by Profile Budjetin sovittaminen sellaiseksi, että käyttötapauksen esiintymistiheys ratkaisee sille varatut testausresurssit. Extended Use Case Test (EUCT) on käyttökelpoinen, kun suuri osa järjestelmän vaatimuksista on kuvattu käyttötapauksina. Tavalliset käyttötapaukset kuvaavat järjestelmän ja sidosryhmien välistä toimintaa, mutta eivät ota kantaa kaikkiin testauksen kannalta oleellisiin asioihin. Tämän johdosta EUCT käyttää niin sanottuja laajennettuja käyttötapauksia (extended use cases). " #$! %
Laajennetut käyttötapaukset Tavalliset käyttötapaukset määrittelevät käyttötapauksen skenaariot (toimintatavat), osallistuvat sidosryhmät ja käyttötapaukseen vaikuttavat syöte ja tulostiedot. Laajennetut kuvaukset määrittelevät lisäksi: käyttötapaukseen liittyvät muuttujat arvoalueineen, käyttötapauksen syöte ja tulostietojen suhteet, käyttötapauksen esiintymistiheyden suhteessa muihin käyttötapauksiin ja käyttötapausten keskinäisen suoritusjärjestyksen. 7 Tavallisista käyttötapauksista laajennettuihin Tavalliset käyttötapaukset saa muunnettua laajennetuiksi käyttötapauksiksi seuraavasti:. Lajitellaan käyttötapaukset riippuvuusjärjestykseen. Jos käyttötapaus A on tehtävä ennen käyttötapaus B:ta, niin silloin B riippuu A:sta.. Katsotaan käyttötapauksittain, mitä tietoja kukin käyttötapauksen sidosryhmä antaa syötteenä ja saa tuloksena. Selvitetään tietojen arvoalueet.. Katsotaan kullekin käyttötapauksen syötteelle, miten syötteestä saadaan tulos. 8 Käyttötapausten päätöstaulu Päätöstauluesimerkki Yksi laajennettu käyttötapaus määrittelee joukon skenaarioita. Jokainen skenaario kertoo, miten järjestelmä toimii tietyillä syötteillä, eli mitä tuloksia se palauttaa. Syötteiden ja tulosten yhdistelmistä rakennetaan päätöstaulu (decision table). Jokainen päätöstaulun rivi kertoo yhden toimintatavan syötteet ja tulokset. Jokainen sarake kertoo käyttötapauksen yhden syötteen tai tuloksen nimen ja tyypin. N:o 7 Kortin Virheellinen Lopetettu Lopetettu Syötetty Väärä Pankin kuittaus Ei yhteyttä Ei yhteyttä Tilin tila Vastausviesti Suljettu Avoin Syötä pankkikortti Ota yhteyttä pankkiin Valitse toiminta Yhteys poikki Syötä uudestaan Kortti lopetettu Kortissa vikaa Automaatin toiminta kortille Syö kortin 9 0 Päätöstaulu ja skenaariot Päätöstaulu ja testitapaukset Päätöstaulun rivit ovat yleensä skenaarioita, mutta on myös mahdollista, että skenaariosta tulee useita rivejä. Skenaarion toiminta voi esimerkiksi vaihdella kellonajan mukaan, jolloin yksi päätöstaulun sarake olisi kellonaika. Tämä ei kuitenkaan todennäköisesti näy itse skenaarion kuvauksessa muuten kuin sisäisenä haarautumisena. Jos skenaariot suunnitellaan huolellisesti, tällaista moniselitteisyyttä ei synny. Tällöin päätöstaulun rivit vastaavat skenaarioita. Pienin käyttötapauksen kattava testipaketti sisältää yhden true ja yhden falsetestin jokaiselle päätöstaulun riville. Truetestissä kaikki ehdot ovat tosia. Falsetestissä ainakin yksi ehdoista on epätosi. Falsetestit saadaan yleensä päätöstaulun jonkin muun rivin testitapauksista. Kattavammassa testauksessa syötteiden arvoalueet ositetaan osaarvoalueiksi ja valitaan kustakin osaarvoaluekombinaatiosta joukko testitapauksia. " #$! &
N:o Kortin #!djfa Päätöstauluesimerkin minimitestitapaukset Syötetty 0 Pankin kuittaus Timeout Tilin tila Vastausviesti CLSD OPEN Syötä pankkikortti Ota yhteyttä pankkiin Valitse toiminta Yhteys poikki Syötä uudestaan Kortti lopetettu Automaatin toiminta kortille Syö kortin EUCT aloitus ja lopetusehdot Aloitusehdot: Käyttötapauksista on johdettu laajennetut käyttötapaukset. Integrointitestaus on saatu päätökseen. Jos käyttötapaukset kuvaavat toiminnalliset vaatimukset, jokaisen toteutetun toiminnan täytyy sisältyä ainakin yhteen käyttötapaukseen. Lopetusehdot: Kaikista käyttötapauksista on päätöstaulut. Jokaisen päätöstaulun jokaiselle riville on tehty 7 Timeout Kortissa vikaa (*),+,.+0/,..+,+,+0, 7 8/ 7, /./$. 9,/: ;,9 /, ),.< 7,+0/,..+ / = 7 +0/ >),7,8 /7, / 7,.?,.+ vähintään true ja falsetestit. Covered in CRUD CRUD:n käyttö Covered in CRUD täydentää EUCT:n testitapauksia sellaisissa tilanteissa, missä EUCT:n käyttötapaukset eivät kata kaikkia testattavan järjestelmän syöte ja tulosolioiden (problem domain class) perusoperaatioita. Syöte ja tulosoliot kuvaavat järjestelmän kannalta ulkoisten olioiden käyttäytymistä järjestelmässä. Esimerkiksi asiakas, tilaus ja tuote ovat syöte ja tulosolioita. LinkitettyLista ei ole. Perusoperaatiot ovat luonti (C), luku (R), päivitys CRUDia käytetään näin: Kerätään järjestelmän käyttötapaukset Tunnistetaan syöte ja tulosoliot Tehdään taulukko, missä vaakarivillä ovat käyttötapaukset ja pystyrivillä syöte ja tulosoliot. Merkitään jokaista syöte ja tulosoliota kohti, missä käyttötapauksissa olioon kohdistetaan jokin perusoperaatioista. Jos jonkin syöte tai tulosolion perusoperaatio ei toteudu missään käyttötapauksessa, niin testipakettia täydennetään perusoperaation toteuttavalla testitapauksella. (U) ja poisto (D). Näistä tulee CRUD. Allocate Tests by Profile Periaatteessa järjestelmätestaus pitäisi tehdä sellaisella tasolla, että kaikki järjestelmän ominaisuudet on testattu kattavasti. Käytännössä täysin kattava testaus, esimerkiksi käyttötapausten ja CRUDtestien avulla, johtaa liian laajaan testipakettiin. Allocate Tests by Profile (ATbP) auttaa karsimaan testipaketin kokoa asettamalla kullekin käyttötapaukselle resursseja sen mukaan, miten tiheään käyttötapaus esiintyy. Tilastollinen testaus ATbP on eräs muoto tilastollisesta testauksesta (statistical testing). Siinä testaukselle varatut resurssit päätetään sen mukaan, miten paljon virheitä kussakin järjestelmän osassa oletetaan olevan. ATbP:n vikamallissa virheitä on tasaisesti yhtä paljon kaikkialla, jolloin todennäköisimmin loppukäyttäjät törmäävät virheisiin niissä käyttötapauksissa, joita järjestelmässä käytetään eniten. 7 8 " #$! '
ATbP:n resurssit ATbP:n resurssit määritellään seuraavasti:. Kullekin käyttötapaukselle lasketaan todennäköisyys, jolla käyttötapaus toteutuu: p Todennäköisyys saadan arvioitua jakamalla tietyllä aikavälillä kyseisen käyttötapauksen toteuttaneiden tapahtumien lukumäärä kaikkien ajanjaksolla toteutuneiden käyttötapausten lukumäärällä.. Lasketaan, kuinka monta testitapausta testaukseen varatuilla resursseilla on mahdollista suorittaa: T. Varataan kullekin käyttötapaukselle testitapauksia suhteessa sen Eitoiminnallisten vaatimusten testaus Käyttötapaukset tarjoavat toiminnallisista vaatimuksista toteutusriippumattoman mallin järjestelmän ominaisuuksiin. Tämän johdosta käyttötapauksissa ei usein oteta kantaa eitoiminnallisiin vaatimuksiin. Eitoiminnalliset vaatimukset ovat järjestelmän laatuvaatimuksia. Kattavassa testauksessa ne on testattu erityisen huolellisesti. Eitoiminnalliset vaatimukset testataan toiminnallisten vaatimusten jälkeen. esiintymätodennäköisyyteen: F = p*t. 9 0 Eitoiminnallisten vaatimusten luokkia Seuraavat eitoiminnalliset vaatimukset tulee ainakin testata: Yhteensopivuusvaatimukset Järjestelmä toimii saumattomasti sille tarkoitetuissa ympäristöissä. Suorituskykyvaatimukset Järjestelmän vasteajat ovat halutuissa rajoissa. Eheys ja vikasietoisuusvaatimukset Järjestelmän saatavuus on riittävän korkea. Käytettävyysvaatimukset Järjestelmän sidosryhmien kannalta järjestelmän käyttö on miellyttävää. Yhteensopivuusvaatimukset Yhteensopivuusvaatimukset (configuration and compatibility) kertovat, minkä tyyppisissä ympäristöissä järjestelmän tulee toimia. Yhteensopivuusvaatimuksia voidaan testata seuraavasti: Selvitetään järjestelmään vaikuttavat ulkoiset tekijät. Ulkoisia tekijöitä ovat esimerkiksi käytettävissä oleva muisti, levytila, prosessoriteho, ulkoiset laitteet, muut yhteistyössä olevat järjestelmät jne. Selvitetään kunkin ulkoisen tekijän arvoalue. Yhteensopivuusvaatimukset II Ositetaan arvoalueet osaarvoalueiksi Valitaan kustakin osaarvoalueesta joukko arvoja Katsotaan erilaiset osaarvoalueiden arvojen kombinaatiot. Valitaan kombinaatioista sopiva osajoukko, jota käytetään yhteensopivuustestauksessa. Yhteensopivuustestauksen ongelma on, että testitapauksia tulee paljon. Testitapauksia voidaan priorisoida esimerkiksi kombinaatioiden yleisyyden perusteella. Suorituskykyvaatimukset Suorituskykyvaatimukset (Performance) kertovat, missä ajassa järjestelmän on saavutettava jotain. Suorituskykyvaatimuksia varten voidaan määrittää kolme testausvaihetta: Kuormitustauksessa (load testing) järjestelmää kuormitetaan simuloimalla saapuvia palvelupyyntöjä aikayksikköä kohden. Kuorma valitaan sellaiseksi, että se vastaa joko tavallista käyttöä tai vaatimuksien maksimikäyttöä. " #$! @
Suorituskykyvaatimukset II Paljoustestauksessa (volume testing) testataan, miten järjestelmä säilyttää suorituskykynsä suuria tietomääriä käsiteltäessä. Rasitustestauksessa (stress testing) järjestelmää testaan vaihtelevilla kuormilla. Rasitustestaus aloitetaan pienellä kuormalla, ja sen jälkeen kuormaa kasvatetaan vähitellen. Tuloksena saadaan relaatio kuorman ja vasteajan välille. Binder listaa rasitustestauksen eheys ja vikasietoisuusvaatimusten testaukseen, mutta se on myös suorituskykyvaatimusten työkalu. Kuormitus ja rasitustestaukset voidaan yhdistää. Eheys ja vikasietoisuusvaatimukset Eheys ja vikasietoisuusvaatimukset (integrity and fault tolerance) kertovat, miten luotettava järjestelmä on ja miten hyvin se toipuu poikkeustilanteista. Eheys ja vikasietoisuusvaatimuksille voidaan määritellä kaksi testausvaihetta: Rasitustestaus vikasietoisuuden kannalta testaa, mitä järjestelmälle tapahtuu, kun kuorma kasvaa hallitsemattomiin kokoihin. Toipumistestaus (restart/recovery testing) testaa, miten hyvin järjestelmä toipuu poikkeustilanteista. Käytettävyysvaatimukset Käytettävyysvaatimukset II Käytettävyysvaatimukset (humancomputer interaction) kertovat, miten hyväksi loppukäyttäjä kokee järjestelmän. Käytettävyysvaatimuksille voidaan tehdä seuraavia testivaiheita: Käytettävyystestaus (usability testing) testaa, onko järjestelmän käyttöliittymä riittävän miellyttävä. Testaus tehdään tarkkailemalla testihenkilöiden toimimista järjestelmässä ja mittaamalla sekä heidän antamansa syötteet että fysiologiset ja psykologiset palautteet. 7 Käyttöturvallisuuden testaus (safety testing, Binderillä security testing) testaa, miten hyvin järjestelmä selviää sekä organisaation sisäisistä että ulkoisista murtautumisyrityksistä. Paikallisuustestaus (localization testing) testaa, miten hyvin järjestelmän käyttöliittymä on muokattavissa uudelle kielelle tai uuteen kulttuuriin. Asennustestaus (installation testing) testaa, miten helposti järjestelmä on asennettavissa ja otettavissa käyttöön uuteen ympäristöön. 8 Hyväksymistestaus Hyväksymistestaus II Hyväksymistestaus suoritetaan sen jälkeen, kun järjestelmätestaus on saatu loppuun. Siihen kuuluvat seuraavat testausvaiheet: Alfatestaus (alpha testing) Riippumaton testiryhmä simuloi järjestelmän todellista käyttöä laboratorioolosuhteissa. Tarkoituksena on varmistaa, että järjestelmä on sellaisessa kunnossa, että sen voi antaa testattavaksi asiakkaille. Betatestaus (beta testing) Joukko asiakkaan edustajia testaa järjestelmää lopullisessa käyttöympäristössä ja raportoi löydetyistä puutteista ja virheistä projektiryhmälle. 9 Validointitestaus (validation testing, Binderillä acceptance testing) Asiakkaan edustajat varmistavat, että järjestelmä täyttää sekä sopimukseen kirjatut eksplisiittiset toiminnalliset ja eitoiminnalliset vaatimukset että kirjaamattomat implisiittiset eitoiminnalliset vaatimukset. Validointitestauksen läpimeno on usein vaatimuksena projektin päättymiselle (ja asiakkaalle laskun maksamiselle). Standarditestaus (compliance testing) Standarditestauksessa varmistetaan, että ohjelmisto täyttää sen toimialaan liittyvät lait, asetukset ja standardit. Tätä testausvaihetta tarvitaan esimerkiksi tehtäessä ohjelmistoja sotilaskäyttöön. 0 " #$! A