02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 1

SYS48D Tietojärjestelmän kehittäminen (12 ov)

Testaus

Jukka Juslin, Tapio Köppä

Opettaja, HELIA

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 2

Opettaja

• Jukka Juslin (DI)

• Huone R2 1019

• Puhelin 09 – 1489 0264

• Vastaanottoaika: maanantaisin klo 8 – 9 @ R2 1019

• Sähköposti: Jukka.Juslin@helia.fi

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 3

Testaus osana kokonaisuutta (RUP)

  Työvaiheiden (Unified Process) tyypillinen kuormitus (Unified Process - kirja, sivu 335):

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 4

Testauksen sisäiset vaiheet

• Edellisessä kuvassa näimme mihin testaus yleensä sijoittuu ohjelmistoprojektissa

• Tämän lisäksi on tärkeää ymmärtää testauksen sisällä olevat vaiheet ja riippuvuus muista ohjelmistoprojektin osista– Siitä seuraavassa kalvossa...

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 5

Testauksen V-malli

Haikala, Märijärvi. Ohjelmistotuotanto 1996, 3. painos. Sivu 234.Ohjelmointi

Moduuli-suunnittelu

Moduuli-testaus

ja tulostenverifiointi

Testauksensuunnittelu

Arkkitehtuuri-suunnittelu

(Vaatimus)Määrittely

Integrointi-testaus

Järjestelmä-testaus

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 6

RUP ja testaus

• RUP korostaa testausta yhtenä työvirtana (work flow), Perry sivu 295 -

• RUP:in idea testauksen(kin) suhteen on skaalautuvuus ja iteraatioittan edistyvä testaus – V-mallin mukaan tapahtuvia testaus V-tilanteita olisi N-kappaletta, eikä vain yhtä (kuten vesiputousmallissa)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 7

Testaus osana tietojärjestelmän kehittämistä

• Testaus on osa tietojärjestelmän kehittämistä riippumatta siitä mitä kehitysprosessia käytetään (esim. RUP)

• Testit jaetaan aina ns. ”test caseihin” testattaviin käyttötapauksiin (testitapauksiin)

• Testitapaukset pitää dokumentoida konsistentisti ja tapaukset on valittava huolella kaikkien mahdollisten tapauksien joukosta

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 8

Testaus kehittämisen eri vaiheissa

• Käyttöliittymän testaus: voidaan suorittaa joko manuaalisesti testaajan toimesta (myös kehittäjä voi olla testaaja) tai automaattisella ”testirobotilla” – esimerkiksi Rationalin ”robot”

• Käyttöönoton yhteydessä tehdään koko järjestelmän käyttöönottotestaus

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 9

Testaussuunnitelma

Jukka Juslin & Tapio Köppä

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 10

Yleistä

• Kuvataan yleisesti testauksen toteuttaminen: suunnittelukatselmus, loppukatselmus, modulitestaus, integrointitestaus ja järjestelmätestaus

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 11

Suunnittelukatselmus

• Tarkastetaan suunnittelukuvasto ja mahdollinen sijoittelumalli

• Kohteet: jäljitettävyys, ulkoinen ja sisäinen johdonmukaisuus (ristiriidattomuus), testattavuus, seuraavan työvaiheen mahdollistaminen, järjestelmän käytön ja ylläpidon mahdollistaminen sekä toimivuus

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 12

Suunnittelukatselmus – jatkuu

• Iterointi– Hyväksymiskriteerit– Virheiden jaottelu: ennen jatkoa / korjataan

seuraavassa vaiheessa– Mitä jatkotoimenpiteitä (virheiden korjaus

seuraavassa vaiheessa)

• Miten dokumentoidaan ja raportoidaan• Ketkä, milloin, miten toteutetaan?

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 13

Loppukatselmus

• Tarkastetaan toteutettu järjestelmä ja sen dokumentaatio:– Edellisten katselmusten (dokumentaatio ja)

raportointi– Modulitestausten (dokumentaatio ja) raportointi– Integrointitestausten (dokumentaatio ja)

raportointi– Järjestelmätestauksen (dokumentaatio ja)

raportointi

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 14

Loppukatselmus – jatkuu

• Kohteet:– Määritysten mukaisuus (validointi) sekä atk-

järjestelmän osalta että muiltakin osin (vaatimukset, manuaalitoiminnot, koulutus, …)

– Jäljitettävyys, ulkoinen ja sisäinen johdonmukaisuus (ristiriidattomuus), käyttöönoton ja hyväksymistestauksen mahdollistaminen sekä järjestelmän käytön ja ylläpidon mahdollistaminen

– Toimivuus ja virheettömyys

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 15

Loppukatselmus – jatkuu

• Iterointi:– Hyväksymiskriteerit– Virheiden jaottelu: käytön estävät / ei käyttöä

estävät– Mitä jatkotoimenpiteitä (virheiden korjaus

ylläpitona)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 16

Loppukatselmus – jatkuu

• Miten dokumentoidaan ja raportoidaan

• Ketkä

• Milloin

• Miten toteutetaan

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 17

Testitapausten tekosuunnitelma

• Järjestelmä-, integrointi- ja mahdollisesti modulitestauksia varten

• Miten dokumentoidaan• Ketkä• Milloin (ja missä yhteydessä)• Miten toteutetaan (ja miten testitapaukset tehdään)• Testitapausten käyttö moduli-, integrointi- ja

järjestelmätestauksissa

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 18

Modulitestaus

• Kohde: yksittäisten moduulien toimivuus ja virheettömyys (modulin toiminta ja määritysten mukaisuus)

• Miten dokumentoidaan ja raportoidaan

• Ketkä

• Milloin

• Miten toteutetaan

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 19

Modulitestaus - jatkuu

• Iterointi:– Hyväksymiskriteerit

– Virheiden jaottelu: käytön estävät / ei käyttöä estävät

– Uusintatestit

– Mitä jatkotoimenpiteitä (jäljelle jäävien virheiden korjaus)

• Testitapausten teko:– Musta-/lasilaatikko

– Toistettavuus (regressiomalli?)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 20

Integrointitestaus

• Kohde: yksittäisistä moduleista muodostettujen kokonaisuuksien toimivuus ja virheettömyys (kokonaisuuden, esim. build, toiminta, modulien yhteistoiminta sekä määritysten mukaisuus)

• Miten dokumentoidaan ja raportoidaan

• Ketkä

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 21

Integrointitestaus - jatkuu

• Milloin• Miten toteutetaan• Iterointi

– Hyväksymiskriteerit

– Virheiden jaottelu: käytön estävät / ei käyttöä estävät

– Uusintatestit

• Mitä jatkotoimenpiteitä (jäljelle jäävien virheiden korjaus)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 22

Integrointi

• Testitapausten teko

- Mustalaatikko

- Toistettavuus (regressiomalli?)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 23

Järjestelmätestaus

• Kohde: toteutetun atk-järjestelmän toimivuus ja virheettömyys (määritysten mukaisuus)

• Miten dokumentoidaan ja raportoidaan

• Ketkä

• Milloin

• Miten toteutetaan

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 24

Järjestelmätestaus – jatkuu

• Iterointi– Hyväksymiskriteerit– Virheiden jaottelu: käytön estävät / ei käyttöä

estävät– Uusintatestit– Mitä jatkotoimenpiteitä (jäljelle jäävien

virheiden korjaus)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 25

Järjestelmätestaus

• Testitapausten teko– Mustalaatikko– Toistettavuus (regressiomalli?)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 26

Kehittämisprosessit

Lähde:Valsta

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 27

Ohjelmistolaadun tekniset ulottuvuudet

Jukka Juslin (DI)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 28

Ohjelmistolaadun tekniset ulottuvuudet...

• Sopeutuvuus uusiin ympäristöihin– Siirrettävyys– Uudelleenkäytettävyys– Yhteensopivuus

• Muuntautumiskyky– Ylläpidettävyys– Muunneltavuus– Testattavuus

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 29

...Ohjelmistolaadun tekniset ulottuvuudet

• Toiminnalliset ominaisuudet– Virheettömyys– Luotettavuus– Tehokkuus– Tietoturvallisuus– Käytettävyys

• Mittaaminen ?!• Testattavia ?!

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 30

Laadunvarmistuksen menetelmiä

• Ohjelmistotekniset menetelmät ja työkalut• Tekniset katselmukset ja tarkastukset• Testaus• Standardien noudattaminen• Dokumentointi• Muutosten hallinta• Kattava mittaaminen• Prosessin seuranta ja raportointi

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 31

Käsitteitä

• Virhe (defect)– poikkeama määrityksistä (puute, väärä, ylimäärä)– mikä tahansa käyttäjän tyytymättömyys– virhe (error): ohjelmiston kehittäjän (ihmisen) tekemä

virhe, aiheuttaa vian ohjelmakoodiin– vika (defect, fault, bug): väärin toimiva ohjelmiston

osa, saattaa aiheuttaa häiriön– häiriö (failure): ulkoisesti havaittavissa oleva

poikkeama toiminnassa verrattuna sen vaatimuksiin ja spesifikaatioon, tietojenkäsittelyn virheellinen tulos

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 32

Käsitteitä, jatkuu...

• Tarkastus/Katselmus/Esitestaus (Static testing)– määrämuotoinen, menetelmällinen katselmus

on tilaisuus, jossa etsitään virheitä yhden tai useamman kirjallisesti tai suullisesti esitetyn raportin pohjalta (tarkistuslista)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 33

Käsitteitä, jatkuu...

• Testaus (Dynamic testing)– järjestelmän tai sen osan tarkastus, jossa käytetään

syöttötietoja ja jossa voidaan etukäteen määritysten perusteella päättää, mitä tulostietoja pitäisi saada

– osan toimittua voidaan todellisia tuloksia verrata oikeiksi tiedettyihin tuloksiin

– useimmiten toiminta tapahtuu tietokoneessa, mutta toimintaa voidaan myös matkia manuaalisesti

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 34

Käsitteitä, jatkuu...

• Testattavuus (Testability): missä määrin objektiivisella ja sopivalla testillä voidaan määrittää, onko jokin vaatimus toteutunut

• Jäljitettävyys (Auditability): missä määrin jokin ulkopuolinen voi jälkikäteen selvittää, miten jokin asia on tehty

• Todentaminen (Verification): lopputulosten arviointi virheettömyyden ja yhtäpitävyyden suhteen verrattuina alkutilanteeseen ja sovellettaviin standardeihin

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 35

Käsitteitä, jatkuu...

• Vahvistus (Validation): toteutusvaiheen lopputulosten vertailu määrittelyissä kuvattuihin järjestelmän vaatimuksiin

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 36

Testauksen konkretisointi

Jukka Juslin ja John-Erik Wigström

SYS48D

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 37

Olennaiset materiaalit testien konkretisoinnissa

• http://myy.helia.fi/~sys48d/Testaus/varasto_testaussuunnitelma.doc

• http://myy.helia.fi/~sys48d/Testaus/Testauslomake.doc

• http://myy.helia.fi/~sys48d/Testaus/TsArvio.htm

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 38

Testaustietokanta

• Talletettu tietämys mitä testejä on ajettu, milloin, kenen toimesta, milloin testin sisältöä on muutettu (missä tarkka testin kuvaus näkyy), mitä ohjelmistoversiota ja mitä ohjelmistoa vasten testin on ajettu ja mikä oli testin tulos (PASSED, FAILED)

• Voi olla yksinkertaisesti esimerkiksi MS Excel Sheet

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 39

Integrointitestaus

• Kohde: yksittäisistä moduleista muodostettujen kokonaisuuksien toimivuus ja virheettömyys (kokonaisuuden, esim. build, toiminta, modulien yhteistoiminta sekä määritysten mukaisuus)

• Miten dokumentoidaan ja raportoidaan?• Ketkä?• Milloin?• Miten toteutetaan?• Iterointi• Hyväksymiskriteerit?• Virheiden jaottelu: käytön estävät / ei käyttöä estävät• Uusintatestit?• Mitä jatkotoimenpiteitä (jäljelle jäävien virheiden korjaus)• Testitapausten teko• Mustalaatikko• Toistettavuus (regressiomalli?)

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 40

Ylemmän tason testit

• Järjestelmän hyväksymistestaus

• Järjestelmätestaus

• Käyttöliittymän Use Case-testaus

• Luovutusvaiheessa tehtävä testaus

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 41

Modulitestaus käytännössä

• Voidaan suorittaa esimerkiksi JUnit:a hyväksikäyttäen

• JUnit on Javan de facto modulitestausstandardi

• Seuraavassa esittelemme JUnitin käyttöä käytännön testaukseen

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 42

Tarvittavat kirjastot

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 43

JUnit - aloitus

• Määrittele aliluokka junit.framework.TestCase:lle

• Määrittele yksi tai useampia public testXXX() metodeja

• Määrittele assertXXX() metodeja– Testi epäonnistuu kun assertXXX() lauseke

epäonnistuu

02/02/2004 Jukka Juslin ja Tapio Köppä – SYS48D, sivu 44

Simple Testcasepackage demo;import junit.framework.TestCase;public class VectorTest extends TestCase {

private java.util.Vector testVector = null;protected void setUp() { // setup the fixture

testVector = new java.util.Vector();}protected void tearDown(){

testVector = null;}public void testIsEmpty() {

assertTrue("Vector is not empty", testVector.isEmpty());}public void testAddElement() {

testVector.add(new Object());assertEquals("Wrong size!", 1, testVector.size());

}public static void main(String[] args){

junit.textui.TestRunner.run(VectorTest.class);}

}