7. Verifiointi ja validointi Verifiointi ja validointi (V&V) on ohjelmistotuotannon työvaihe, missä varmistetaan, että ohjelmisto täyttää sille asetetut implisiittiset ja eksplisiittiset vaatimukset ja ohjelmisto täyttää sen tilanneen asiakkaan ohjelmistolle asettamat tarpeet. V&V:ta tehdään koko ohjelmistoprosessin elinkaaren ajan. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 1 Verifioinnin ja validoinnin ero Verifioinnissa varmistetaan, että ohjelmisto vastaa määrityksiään: Verification: Are we building the product right? Validoinnissa varmistetaan, että ohjelmisto täyttää asiakkaan sille asettamat odotukset: Validation: Are building the right product? Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 2 Verifiointi- ja validointitekniikat V&V:ssa käytetään enimmäkseen kahta tekniikkaa: tarkastuksia ja testausta. Tarkastukset (software inspections). Tarkastuksissa joukko ihmisiä analysoi ja tarkastaa järjestelmäkuvauksia, kuten vaatimusdokumentaatiota, suunnittelukaavioita ja ohjelmakoodia. Tarkastukset ovat staattinen tekniikka. Ne eivät vaadi suorituskelpoista ohjelmaa. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 3 Verifiointi- ja validointitekniikat II V&V-tekniikat jatkuvat: Testaus (software testing). Testauksessa ohjelmistoa tai sen osaa suoritetaan tietyillä testitiedoilla ja tuloksia analysoimalla ja ohjelmiston suoritusta seuraamalla selvitetään, että toiminta on odotettua. Testaus on dynaaminen tekniikka, sillä siihen tarvitaan suorituskelpoinen ohjelma. Sekä tarkastuksia että testausta tarvitaan ohjelmistotuotannossa. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 4 Verifioinnin ja validoinnin tavoite V&V:n tavoitteena on varmistaa, että ohjelmisto täyttää sille asetetut tavoitteet. Ohjelmiston ei tarvitse olla virheetön, eikä se myöskään yleensä ole sitä. Ohjelmiston on sen sijaan oltava tarkoitettuun käyttöön riittävän hyvä. Tavoitetaso riippuu sovellusalueesta. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 5 Virheiden korjaus Löytyneet virheet on korjattava. Tarkastuksissa löydetyt virheet korjataan muuttamalla dokumentaatiota. Testauksessa löydetyt virheet paikallistetaan virheenjäljityksellä (debugging), minkä jälkeen virhe korjataan. Korjauksen jälkeen on tehtävä uusi tarkastus tai suoritettava regressiotestaus. Näin varmistetaan, että korjaus ei rikkonut aiemmin toimineita osia. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 6 Verkamo, Taina 1
Verifioinnin ja validoinnin hallinta V&V:n hallinnan V-malli V&V on kallis työvaihe. Se voi viedä pahimmillaan puolet ohjelmistotuotantoprosessin budjetista. Ilman huolellista suunnittelua V&V:n hyödyt jäävät kasvaneita kustannuksia pienemmiksi. V&V:n suunnittelu alkaa prosessin alkuvaiheessa. Suunnitelmaa päivitetään prosessin elinkaaren ajan. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 7 Requirements specification Service Acceptance test plan specification Acceptance test integration test plan design integration test Sub-system integration test plan Detailed design Sub-system integration test Module and unit code and tess V-malli kuvaa V&V-työvaiheen suhteen muihin prosessin työvaiheisiin. Tarkastuksia voidaan pitää missä tahansa työvaiheessa tai niiden välillä. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 8 7.1. Tarkastukset Tarkastukset - II Tarkastus (inspection) on kokous, jossa tarkastetaan jonkin työvaiheen tuotos, tai osa siitä, ja yritetään löytää siitä puutteita ja virheitä. Puute = vajaa määritys tai puuttuva toiminta Virhe = väärin tehty määritys tai ei-toivottu toiminta Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 9 Tarkastuksia tehdään kaikissa projektin työvaiheissa. Aina kun projektissa on saatu jokin tuotos valmiiksi, se kannattaa käydä läpi muodollisesti tarkastuksissa. Tarkastukset parantavat tuotteen laatua, sillä aikaisessa vaiheessa löydetty puute tai virhe on helpompi korjata kuin myöhemmin löydettynä. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 10 Tarkastusten luonne Tarkastus on muodollinen tilaisuus, johon osallistuu 3-6 henkilöä. Tilaisuudella on tarkka aikataulu. Henkilöt edustavat eri sidosryhmiä asiakkaasta projektiryhmän jäseniin. Tarkastuksessa kootaan löydetyt puutteet ja virheet. Tarkastukseen valmistaudutaan etukäteen. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 11 Tarkastukseen osallistujat Osallistujien roolit ovat: puheenjohtaja (moderator), sihteeri (scribe), alustaja (reader): esittelee tuotoksen, kirjoittaja (author/owner): edustaa tuotoksesta vastuussa olevaa ryhmää ja vastaa korjauksista ja tarkastaja (inspector): etsii puutteita ja virheitä (kaikkien rooli). Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 12 Verkamo, Taina 2
Ennen tarkastusta Ennen tarkastustapahtumaa: kaikki tarkastuksessa tarvittavat dokumentit ovat saatavilla, osallistujilla on ollut aikaa tutustua dokumentteihin, käytössä on tarkistuslistat yleisimmistä puutteista ja tarkastettava dokumentti on sellaisella tasolla, että siinä ei ole ilmeisiä virheitä. Tarkastustapahtuma Tarkastustapahtuma saa kestää korkeintaan kaksi tuntia. Siinä keskitytään yksinomaan löytämään puutteita ja virheitä. Tarkastukseen osallistujat eivät keskustele löydetyistä puutteista. Kun puute on havaittu, sihteeri kirjaa sen ylös ja siirrytään eteenpäin. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 13 Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 14 Tarkastuksen päätös Tarkastusten kultaiset säännöt Tarkastuksen lopuksi ryhmä äänestää tuotoksen hyväksymisestä: Hyväksytään sellaisenaan: ei muutoksia. Hyväksytään muutoksin: löydetyt puutteet ja virheet on korjattava, mutta tuotoksesta ei tarvita enää uutta tarkastusta. Hylätään: löydetyt puutteet ja virheet on korjattava. Korjauksen jälkeen tuotoksesta käydään läpi uusi tarkastus. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 15 1.Arvioidaan tuotetta, ei tekijää. 2.Suunnitellaan aikataulu ja pidetään siitä kiinni. 3.Rajoitetaan väittelyä. 4.Ei yritetä ratkoa löydettyjä ongelmia. 5.Rajoitetaan osallistujien määrä 3-6 henkeen. 6.Valmistaudutaan huolellisesti tarkastukseen. 7.Käytetään tarkistuslistoja sekä valmistautuessa että tarkastuksessa. 8.Varataan riittävästi aikaa ja resursseja. 9.Koulutetaan osallistujat. 10.Arvioidaan myös tarkastusprosessia. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 16 7.2. Testaus Täydellinen testaus mahdotonta Testauksen (Sommervillella defect testing) tavoittena on löytää suoritettavasta ohjelmasta puutteita ja virheitä (defects) ennen ohjelman toimittamista loppukäyttöön. Hyvä testitapaus on sellainen, joka löytää ennestään tuntemattoman puutteen tai virheen. (Jatkossa puute/virhe = virhe) Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 17 Täydellinen testaus, missä ohjelma testataan kaikilla mahdollisilla syötteillä, syötekombinaatioilla ja ajoituksilla, ei ole käytännössä mahdollista. Jo hyvin yksinkertaisilla ohjelmilla kaikkien testitapausten suoritus veisi vuosia. Tämän johdosta testauksessa valitaan osajoukko kaikista mahdollisista testitapauksista. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 18 Verkamo, Taina 3
Testauksen oleellinen kysymys Miten valitaan sellainen testitapausten osajoukko, että sen suorittaminen on mahdollista järkevässä ajassa ja että sen avulla ohjelma tai sen osa saadaan testattua riittävän hyvin? Sommerville suosittelee vastaukseksi yrityskohtaista testauspolitiikkaa, jonka mukaan testitapaukset valitaan. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 19 Mustalaatikkotestaus Mustalaatikkotestauksessa (black-box testing) testitapaukset valitaan ohjelman tai komponentin spesifikaation avulla. Itse ohjelma on musta laatikko, jonka toiminnan määrittelevät sen saamat syötteet ja sen antamat tulosteet. Koska testaus perustuu spesifikaatioon, testauksen suunnittelu voidaan aloittaa heti määrittelyjen valmistuttua. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 20 Mustalaatiikotestauksen anatomia Mustalaatikkotestauksen tavoitteet Input test data Output test results I e O e Inputs causing anomalous behaviour Outputs which reveal the presence of defects Mustalaatikkotestauksessa pyritään löytämään virheellisiä tai puuttuvia toimintoja, sisäisiin, ulkoisiin tai käyttöliittymään liittyviä virheitä, virheitä yleisissä tietorakenteissa, suorituskykypuutteita ja alustus- ja lopetustoimintojen virheitä. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 21 Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 22 Ekvivalenssiluokat Testitapausten valinta Mustalaatiikotestauksessa syöteavaruus ositetaan ekvivalenssiluokiksi. Yksi luokka kuvaa toiminnallisuuden osajoukkoa, jolle voidaan tehdä yhteisiä testejä. Ekvivalenssiluokat voidaan johtaa esimerkiksi ohjelmiston kuvauksista, arkkitehtuurista, käyttäjän vaatimuksista tai järjestelmävaatimuksista. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 23 Jokaisesta ekvivalenssiluokasta valitaan muutama testitapaus. Valitut testitapaukset edustavat koko ekvivalenssiluokkaa. Onnistuneessa jaottelussa mikä tahansa luokan jäsen kelpaa testitapaukseksi. Käytännössä suositaan luokan rajoilla olevia arvoja, sillä ne ovat parhaimpia havaitsemaan jaottelun puutteita ja virheitä. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 24 Verkamo, Taina 4
Ekvivalenssiluokkaesimerkki Olkoon meillä metodi boolean alkuluku(int n). Tällöin ekvivalenssiluokat voidaan valita vaikka seuraavasti. n < 0 n = 0 n > 0 ja alkuluku n > 0 ja ei ole alkuluku n on jotain muuta kuin integer Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 25 Rakenteellinen testaus Rakenteellisessa testauksessa - tai lasilaatikkotestauksessa - testitapaukset valitaan ohjelman rakenteen perusteella. Rakenteellista testausta tehdään yleensä aika pienille ohjelman osille, kuten metodeille ja luokille. Testauksessa koodia käytetään hyväksi testitapausten luonnissa. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 26 Polkutestaus Binäärihaun siirtymäverkko Polkutestaus on yleisin rakenteellisen testauksen menetelmä. Siinä lähtökohtana on koodista tehty siirtymäverkko (flow graph): Jokaisesta lauseesta tulee solmu. Jokaisesta siirtymästä lauseesta toiseen tulee suunnatun verkon särmä. Verkossa on yksi lähtösolmu ja mahdollisesti monta maalisolmua. bottom > top 8 9 1 2 3 while bottom <= top if (elemarray [mid] == key 4 (if (elemarray [mid]< key 5 6 7 Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 27 Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 28 Siirtymäverkon polku Yksi siirtymäverkon polku on reitti lähtösolmusta johonkin maalisolmuun. Testauksessa tavoitteena on löytää sellainen testitapaus, joka kulkee halutun polun läpi. Aina tällaista testitapausta ei löydy, sillä metodissa saattaa olla kuollutta koodia. Täydellinen testaus kävisi läpi kaikki mahdolliset polut. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 29 Testattavat polut Yleensä kaikkien polkujen testaus ei ole mahdollista. Esimerkiksi ehdot ja silmukat yhdessä kasvattavat nopeasti kaikkien mahdollisten polkujen määrää. Tämän johdosta valitaan osajoukko: Kaikissa solmuissa on käytävä. Kaikissa särmissä on käytävä. Kaikki riippumattomat polut on käytävä. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 30 Verkamo, Taina 5
Riippumattomat polut Riippumattomien polkujen määrä Riippumaton polku on sellainen, joka alkaa lähtösolmusta ja päättyy johonkin maalisolmuun, on mahdollisimman lyhyt ja sitä ei saada yhdistelemällä muista riippumattomista poluista. Riippumattomat polut vähentävät testattavien polkujen määrää latistamalla silmukat yhdeksi läpikuluksi. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 31 Riippumattomien polkujen määrä saadaan seuraavasta kaavasta: CC(G) = särmät - solmut + 2. CC(G) on ns. syklomaattinen kompleksisuus, joka kertoo verkon monimutkaisuuden. Polkujen tunnistamisen jälkeen suunnitellaan testitapaukset, jotka käyvät löydetyt polut läpi. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 32 Integrointitestaus Yksittäisten ohjelman osien testauksen jälkeen osat kootaan yhteen ja testataan yhdessä. Tätä kutsutaan integrointitestaukseksi. Integrointia voidaan tehdä ylhäältä alaspäin: aloitetaan korkean tason komponenteista ja edetään alaspäin kohti toimintakomponentteja. Integrointitestaus II Integrointia voidaan myös tehdä alhaalta ylöspäin: aloitetaan toimintakomponenteista ja edetään kohti korkean tason komponentteja. Käytännössä tehdään ns. voileipätestausta, missä integrointitestataan sekä alhaalta ylöspäin että ylhäältä alaspäin. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 33 Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 34 Rajapintatestaus Integrointitestauksen oleellinen osa on rajapintatestaus. Siinä etsitään virheitä, jotka johtuvat rajapintojen virheistä tai vääristä rajapintojen oletuksista. Rajapintatestaus on ehkä tärkein oliopohjaisen integrointitestauksen työvaihe, sillä yleensä oliot ja komponentit on jo testattu kohtuullisen huolellisesti. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 35 Rajapinnat Rajapintoja: Parametrien välitysrajapinnat. Jaetun resurssin rajapinnat: muisti ym. Proseduraaliset rajapinnat. Viestinvälitysrajapinnat. Havaittavia virheitä: Rajapintaa käytetään väärin. Rajapinnan toimintaa ei ymmärretä. Rajapinnan käytön ajoitus on väärä. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 36 Verkamo, Taina 6
Rajapintatestauksen testejä Parametrien välitysrajapinnoille sellaiset arvot, jotka ovat parametrin arvoalueen äärirajoilla. Jos rajapinnalle annetaan parametrina osoitin, testi null-osoittimella. Proseduraaliselle rajapinnalle sellaiset testit, joista rajapinnan toteuttavan komponentin ei pitäisi toipua. Rajapintatestauksen testejä II Viestinvälitysrajapinnoille rasitustestaus. Jaetun resurssin rajapinnalle testit, jotka vaihtelevat resurssin luku- ja kirjoitusprosessien suoritusjärjestystä. Tavalliset mustalaatikkotestauksen tekniikat, kuten ekvivalenssiluokkiin ositus, kuuluvat aina rajapintatestaukseen. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 37 Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 38 Rasitustestaus Integrointitestauksen jälkeen järjestelmän kriittisiä ominaisuuksia voidaan testata: suorituskykyä, luotettavuutta ja vikasietoisuutta, turvallisuutta. Rasitustestauksessa ohjelma viedään äärirajoille ja mielellään vielä niiden yli. Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 39 Testaustyökalut Testaus on kallista puuhaa. Siksi sitä on pyritty automatisoimaan mahdollisimman pitkälle. Tällä hetkellä testaukseen on saatavilla paljon työkaluja, jotka helpottavat testausprosessia ja siten vähentävät testauksen kustannuksia. Testaustyökaluja voidaan integroida työkalupakeiksi (testing workbenches). Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 40 Testaustyökaluja Työkalupakki Testaustyökaluja: Testinhallitsin (test manager) Testisyötteiden generoija (test data generator) Oraakkeli (oracle) Tulosten vertaaja (file comparator) Raporttigeneraattori (report generator) Profiloija (dynamic analyser) Simulaattori (simulator) Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 41 Source code Dynamic analyser Execution report Test manager Program being tested Simulator Test data generator Test data Test results File comparator Report generator Specification Oracle Test predictions Test results report Syksy 2004 Ohjelmistotuotanto / Verkamo, Taina 42 Verkamo, Taina 7