5. Bugiraportoinnista Bugiraportointi on käytännössä tärkein kommunikaation muoto testaajien ja kehittäjien välillä. Vaikka tavoitteet ovat yleensä selkeitä, ei toimivaa raportointia ole kuitenkaan helppo toteuttaa. Monesti on jälleen kysymys asenteista. Mika Katara: Ohjelmistojen testaus, 2011 209 Mukailtu lähteestä Cem Kaner, Bug Advocacy, Quality Week 2002. Massamarkkinoille suunnattujen ohjelmistojen tapauksessa suurin osa käyttäjien löytämistä virheistä on itse asiassa jo löydetty varsinaisessa testauksessa miksi niitä ei ole korjattu? Bugiraportti on väline, jolla testaajan on tarkoitus saada organisaatio vakuuttuneeksi siitä, että löytyneen bugin korjaamiseen kannattaa käyttää aikaa ja rahaa Mika Katara: Ohjelmistojen testaus, 2011 210
Jos testauksen tarkoitus on löytää virheitä, silloin bugiraportit ovat testaajan ensisijainen tuotos Ne ovat tuloksia, jotka testauksesta näkyvät ulkopuolelle ja joiden perusteella testaajat muistetaan Paras testaaja ei ole se, joka löytää eniten virheitä, vaan se, joka saa eniten virheitä korjatuksi Koska aikaa ei ikinä ole tarpeeksi, testaajan täytyy myydä bugi kehittäjälle, jotta tämä käyttäisi aikaansa sen korjaamiseen Myyminen perustuu kahteen tavoitteeseen Kehittäjä täytyy saada haluamaan korjata bugi Kehittäjän vastalauseet ja selitykset, miksi bugia ei tarvitse korjata, täytyy pystyä kumoamaan Mika Katara: Ohjelmistojen testaus, 2011 211 Mitkä seikat saavat kehittäjän haluamaan korjata bugin? Se näyttää tosi pahalta Se näyttää mielenkiintoiselta ongelmalta Se vaikuttaa moniin ihmisiin Sen toistaminen on triviaalia Se saattaa meidät noloon tilanteeseen, tai vastaava bugi on saattanut kilpailijan noloon tilanteeseen Johto haluaa, että bugi korjataan Ohjelmoija haluaa tehdä testaajalle palveluksen yms. henkilökohtaiset syyt Vetoaminen ammattitaitoon tms. Mika Katara: Ohjelmistojen testaus, 2011 212
Mikä saa kehittäjän vastustelemaan bugin korjaamista? Kehittäjä ei saa bugia toistettua Bugin toistaminen vaatii erikoista temppuilua Toistaminen ei ole mahdollista näillä tiedoilla ja lisätietojen kaivaminen vaatii paljon työtä Kehittäjä ei ymmärrä bugiraporttia Epärealistinen bugi Korjaaminen vaatii paljon työtä Korjaaminen on riskialtista Ei nähtävissä olevaa vaikutusta käyttäjille Ei tärkeä; kukaan ei välitä, jos tämä ei toimi Mika Katara: Ohjelmistojen testaus, 2011 213 Kyseessä ei ole bugi vaan ominaisuus Johto ei välitä tämän kaltaisista bugeista Kehittäjä ei pidä testaajasta tai ei luota häneen tms. henkilökohtaiset syyt Mika Katara: Ohjelmistojen testaus, 2011 214
Kuinka motivoida bugin korjaamiseen? Kun testaaja huomaa häiriön, on kyseessä oire, itse virhe on vielä paljastamatta Ehkäpä tämä häiriö ei ole paras mahdollinen esimerkki ko. virheen aiheuttamista häiriöistä Siksi täytyy tehdä lisää töitä ennen bugiraportin kirjoittamista sen osoittamiseksi, että virhe on vakavampi ja yleisempi kuin mitä ensisilmäyksellä näyttää Mika Katara: Ohjelmistojen testaus, 2011 215 Vakavuuden selvittäminen Kun testaaja on löytänyt häiriön, on ohjelmisto saatu haavoittuvaan tilaan Jatkamalla testausta tässä tilassa, voidaan selvittää vian todellinen vakavuus vaihtelemalla kontrollia (ensin A, sitten B tai toisin päin) vaihtelemalla optioiden ja asetusten arvoja vaihtelemalla ohjelmisto- ja laitteistokonfiguraatiota Mika Katara: Ohjelmistojen testaus, 2011 216
Onko kyseessä uusi vai vanha bugi? Jos kyseessä on vanha bugi, sen korjaamiseen ei olla motivoituneita, ellei se ole aiheuttanut valituksia asiakkailta Uusiin bugeihin suhtaudutaan vakavammin Jos kyseessä on vanha bugi, voi yrittää löytää uusia tapoja, joilla häiriö esiintyy ohjelmiston uudessa versiossa kyse on tällöin uudesta ongelmasta Em. kohdat korostuvat erityisesti ohjelmiston ylläpitovaiheessa, kun uuden version tarkoituksena on vain korjata kriittisimpiä virheitä Jos bugitietokantaa siivotaan aika ajoin, voi tärkeää tietoa kadota Mika Katara: Ohjelmistojen testaus, 2011 217 Yleisyyden selvittäminen Etsi riippuvuuksia konfiguraatioista jos häiriötä ei saada toistetuksi kehittäjän ympäristössä, on motivointi bugin korjaamiseksi hankalaa bugiraportin täytyy kertoa ne ympäristöt, joissa häiriö ilmenee Yritä yleistää ääritapaukset raja-arvoanalyysi auttaa häiriön etsimisessä Negatiivinen testaus, raja-rovot, virheelliset syötteet Kun bugi on löytynyt, ei tarvitse enää tyytyä raja-arvoihin Mika Katara: Ohjelmistojen testaus, 2011 218
Testaajan pitäisi raportoida myös sellaiset bugit, joita ei saa toistetuksi Jos raportti on riittävän tarkka, ohjelmoija voi sen perusteella selvittää virheen olinpaikan Kun huomaat, että et saa bugia toistetuksi, kirjoita ylös heti kaikki mitä siitä muistat jos olet epävarma siitä mitä teit, sano se bugiraportissa Kannattaa kirjata myös se, mitä teit ennen kuin huomasit häiriön Tarkasta bugitietokannasta, löytyisikö sieltä jotain vastaavaa Yritä muuttaa ohjelman ajoitusta hitaammaksi ja nopeammaksi Juttele ohjelmoijan kanssa ja/tai lue koodia Bugi, jota ei saada toistetuksi on testaajan virhe, kannattaa yrittää ottaa opikseen Mika Katara: Ohjelmistojen testaus, 2011 219 Hyvän bugiraportin resepti Selkeä, kuvaava otsikko auttaa löytämään raportin bugikannasta Selosta kuinka häiriön saa toistettua, sisällytä kaikki askeleet Kuvaile, mitkä askeleet ovat ja mitkä eivät ole tärkeitä bugin kannalta, ja miten tulokset vaihtelivat eri testiajoissa Analysoi ongelmaa ja kerro, miten se voidaan toistaa pienimmällä määrällä askelia Raportin pitää olla helposti ymmärrettävä Sävyn pitää olla neutraali Vain yksi bugi per raportti Jos toistamiseen tarvitaan tiedosto, liitä se raporttiin tai kerro mistä se löytyy Mika Katara: Ohjelmistojen testaus, 2011 220
Bugiraporttipohja Ongelman kuvaus yhdellä rivillä bugiraportin tärkein kenttä johto lukee tämän kun haluaa tietää mitkä bugit ovat vielä korjaamatta Raportin yksilöivä numero Kuka raportoi Raportin luontipäivä Ohjelman tai komponentin nimi Julkistuksen ja version numero Testikonfiguraatio(t) Mika Katara: Ohjelmistojen testaus, 2011 221 Raportin tyyppi ohjelmointivirhe, suunnitteluvirhe, dokumentoinnin vastaamattomuus, ehdotus, kysymys Voiko toistaa kyllä, ei, joskus, en tiedä: jos testaaja väittää, että bugi voidaan toistaa ja ohjelmoija on toista mieltä, testaaja joutuu toistamaan bugin ohjelmoijan silmien edessä Vakavuus Prioriteetti ohjelmoija/projektipäällikkö täyttää Vaikutus asiakkaisiin esim. tekninen tuki täyttää Mika Katara: Ohjelmistojen testaus, 2011 222
Avainsanat Ongelman kuvaus ja toistaminen askel askeleelta Suositeltu korjaus Kuka selvittää projektipäällikkö täyttää Status testaaja täyttää: avoin, suljettu, roskis Päätös projektipäällikkö omistaa tämän kentän odottaa, korjattu, ei voida toistaa, lykätty korjausta, toimii kuten suunniteltu, tarvitaan lisää tietoa, duplikaatti, vedetty pois tms. Mika Katara: Ohjelmistojen testaus, 2011 223 Päätöstä vastaavan buildin versionumero Päätöksen tekijä ohjelmoija, projektipäällikkö, error manager, testaaja Päätöksen testaaja jos testaaja löytää bugin, hän myös testaa korjauksen Bugiraportin versiohistoria Vapaamuotoiset kommentit muista neutraali sävy Mika Katara: Ohjelmistojen testaus, 2011 224
6. Ohjelmistojen mittaaminen Ohjelmistoprojekteissa mikään ei ole pysyvää paitsi muutos. Mittausten avulla voidaan tehdä sivistyneitä arvauksia projektin nykytilasta sekä siitä, mitä pitäisi muuttaa ja mihin suuntaan. Toisaalta tuotemetriikat voivat auttaa kohdistamaan testausta virheherkimpiin osiin. Mika Katara: Ohjelmistojen testaus, 2011 225 Metriikat Pääasiallinen lähde [Haikala&Märijärvi 06] Mitä halutaan mitata, minkälaista tietoa kaivataan? Tarvitaanko tuotemetriikoita, projektimetriikoita, vai molempia? Vai halutaanko mitata jotain muuta? Mitä enemmän sen parempi? Joitain suureita ei voida mitata tarkasti, kuten jäljellä olevien bugien määrää, mutta arvioita voidaan antaa Jos jäljellä olevien bugien määrä voitaisiin laskea, ne olisi luultavasti helppo myös poistaa Toiset arviot ovat parempia kuin toiset Mika Katara: Ohjelmistojen testaus, 2011 226
Mittauksessa törmätään yleensä asenneongelmiin Ohjelmistoprojekteissa on aina vaarana, että mittaaminen kohdistuu suoraan henkilöön ja tämän suoritukseen Mittaustulosten hyödyntämistapa pitäisi tehdä kaikille selväksi Mittaamista on perinteisesti hyödynnetty testauksessa varsin laajasti Testikattavuus Testien kohdistaminen virheherkimpiin osiin ohjelmisto Koodi, joka on monimutkaista on yleensä myös virheherkkää Mika Katara: Ohjelmistojen testaus, 2011 227 Aloita yksinkertaisilla mittareilla Aloita testauksen mittaaminen yksinkertaisilla metriikoilla, jotka vaikuttavat luotettavilta, ja kokoa ne mittarijoukoksi Jos on esimerkiksi mahdollista mitata vaatimusten kattavuutta, se voi olla hyvä alkupiste Kokoelma toisiaan täydentäviä vaatimuksiin ja spesifikaatioihin sekä kooditason kattavuuteen pohjautuvia mittareita voi olla hyödyllinen Sen sijaan, että tuijotettaisiin pieniin muutoksiin mitatuissa arvoissa, kiinnostavampia ovat suuret muutokset ja trendit (tulemmeko paremmiksi vai huonommiksi) Hopealuotia ei ole mittauksessakaan Muuta mittarijoukkoa pienin askelin, yritä pysyä perillä muutosten vaikutuksista Mika Katara: Ohjelmistojen testaus, 2011 228
Metriikat vs. Riskit Onko mittarijoukolla ja tuotteen tai projektin riskeillä jokin yhteys? Testaa mittarijoukkoa keksimällä skenaarioita, joissa jokin tärkeä riski realisoituu tuotteessa tai projektissa nähdäksesi havaitsevatko mittarit sen selvästi Jos ei, voisiko mittarijoukkoa parantaa huomaamaan tällaisia ongelmia? Älä luota mittareihin, jotka ovat olleet usein väärässä: mitä onnistuneiden ja epäonnistuneiden testien suhde oikeastaan kertoo? Voisiko tätä tietoa täydentää esimerkiksi jollakin vaatimuksiin/spesifikaatioihin/koodikattavuuteen liittyvällä metriikalla? Mika Katara: Ohjelmistojen testaus, 2011 229 Mittaamisen huolellinen suunnittelu Isoissa projekteissa/organisaatioissa tarvitaan usein mittaussuunnitelmaa: miksi mitaan mitä mitataan ketkä osallistuvat mittaamiseen mitä osia järjestelmästä mitataan koska mitataan kuinka tiedot kerätään ja analysoidaan Mika Katara: Ohjelmistojen testaus, 2011 230
Vaatimuksia mittareille Mittaamisen tulosten merkitys liiketoiminnalle Peruste mittaamiselle Yhteinen käsitys siitä, miksi tietoa kerätään ja miten sitä voidaan hyödyntää ja tullaan hyödyntämään Käyttöönoton helppous Tarvitaanko käyttöönottoprojekti Ymmärrettävyys Syyt muuttuville arvoille Selektiivisyys Tulokset kohdennettavissa mittauksen kohteeseen Jos mittarin arvo muuttuu, tiedetään mikä muuttuu mittauksen kohteessa Mika Katara: Ohjelmistojen testaus, 2011 231 Objektiivisuus Tulokset eivät riipu mittaajasta tai mittaustilanteesta Luotettavuus Tarkkuus, toistettavuus, mittaria ei käytetä vahingossa väärin Taloudellisuus Mittauksen kustannukset suhteessa saavutetuun hyötyyn Uudelleenkäytettävyys Mika Katara: Ohjelmistojen testaus, 2011 232
S-käyrä Esimerkki järjestelmätestauksen virhekäyrästä [Haikala&Märijärvi 06]: Siirrytään hyväksymistestaukseen kun virhekäyrä tasaantuu Tasaantumisen saavuttamiseen tarvittavia resursseja on valitettavasti vaikea arvioida etukäteen Mika Katara: Ohjelmistojen testaus, 2011 233 testatut vaatimukset Olisiko näistä metriikoista edistymisen seurantaan? Ajetut testit, arvio Läpäistyt testit, arvio Ajetut, toteutunut Läpäistyt, toteutunut aika Mika Katara: Ohjelmistojen testaus, 2011 234
Ei-toiminnallinen ja negatiivinen testaus Kuinka mitata ei-toiminnallista testausta? Entä kuinka mitata negatiivista testausta? Niin kauan kuin voidaan puhua testitapauksista, ei mittaamisen pitäisi olla erilaista Valitettavasti on kuitenkin erittäin helppo unohtaa eitoiminnallinen ja negatiivinen testaus, jos keskitytään puhtaasti toiminnallisuuden testaukseen Joitakin testaustyyppejä on hankala mitata testitapausten avulla Käytettävyys, suorituskyky, turvallisuus Mika Katara: Ohjelmistojen testaus, 2011 235 Suorat ja johdetut mittarit Perusmittarit: suoritetut testit, löytyneet virheet, kattavuus suhteessa vaatimuksiin/spesifikaatioihin, koodikattavuus, koko, mutkikkuus, käytetty työmäärä, jne. Johdetut mittarit: virhetiheys, onnistuneiden ja epäonnistuneiden virhekorjausten suhde, löydettyjen virheiden määrän suhde niiden virheiden määrään, jotka olisi voitu löytää, jne. Prosessi-sidonnaiset mittarit: testien suoritusnopeus, automatisointiaste, virheiden elinaika päivissä, testaukseen suunnitteluun kulunut työmäärä, laatuvelka ketterässä projektissa, jne. Yleisesti ottaen ongelma ei ole mittareiden keksiminen, koska niitä on jo tarpeeksi; ongelma on valita sopivat mittarit Mika Katara: Ohjelmistojen testaus, 2011 236
Goal-Question-Metric-menetelmä (Basili) 1. Develop a set of corporate, division and project business goals and associated measurement goals for productivity and quality 2. Generate questions that define those goals as completely as possible in a quantifiable way 3. Specify the measures needed to be collected to answer those questions and track process and product conformance to the goals 4. Develop mechanisms for data collection 5. Collect, validate and analyze the data in real time to provide feedback to projects for corrective action 6. Analyze the data in a postmortem fashion to assess conformance to the goals and to make recommendations for future improvements Source: http://goldpractice.thedacs.com/practices/gqm/index.php Basili, Victor R., Using Measurement to Build Core Competencies in Software, Seminar sponsored by Data and Analysis Center for Software, 2005 Mika Katara: Ohjelmistojen testaus, 2011 237 Sitä saa mitä mittaa! Kuinka mittareita huijataan? Johto saa sitä mitä mittaa 100% koodikattavuuden saavuttaa helpommin kun jättää testien tulokset huomioimatta Automatisoinnin astetta voi kasvattaa hankkiutumalla eroon manuaalisesta testauksesta Tehokkaaksi testaajaksi pääsee kunhan käy muuttamassa itse lähdekoodia ja löytämällä itse tekemänsä virheet seuraavana päivänä Jos mittareihin on yhdistetty palkitsemista, kiusaus niiden huijaamiseen voi nousta ongelmaksi Mika Katara: Ohjelmistojen testaus, 2011 238
Esimerkkejä mittareista Kuva: Timo Malm, VTT. Data origin: Capers Jones. Software quality in 2008: A survey of the state of the art. Mika Katara: Ohjelmistojen testaus, 2011 239 Järjestelmätason kattavuusmitat Perinteiset mittarit: Vaatimusten kattaminen kuinka hyvin eri vaatimukset on saatu katettua Kattavuus suhteessa vaatimusten tärkeyteen Toiminnallinen kattavuus Liitetään testit ohjelman toimintoihin, jopa käyttöliittymän toimintoihin Kattavuus eri yksiköiden suhteen Komponentit, moduulit, yms. Mika Katara: Ohjelmistojen testaus, 2011 240
Muita vaihtoehtoja Riskikattavuus Kuinka tuotteen riskit on testauksessa otettu huomioon, erityisesti isojen riskien osalta Riskikattavuus suhteessa vaatimuksiin/toimintoihin Kattavuus sen suhteen mikä on tärkeää eri käyttäjäryhmille 70 % yrityskäyttäjille tärkeistä vaatimuksista on katettu, 83 % kotikäyttäjille tärkeistä Käyttöskenaario- / käyttötapaus- / tarinakattavuus Tällä tasolla käytettävät kattavuusmittarit riippuvat käytettävästä prosessista V-malli vai ketterä prosessi Mika Katara: Ohjelmistojen testaus, 2011 241 6.1 Koodin kattavuusmitat Koodikattavuuden avulla voidaan päätellä, että vielä ei olla testattu riittävästi Sen päätteleminen, että on testattu tarpeeksi, on sitten toinen asia On hyvä muistaa, että puuttuvaa koodia ei pystytä testaamaan Vaikka järjestelmätason testaajien ei tarvitse huolehtia kooditason kattavuudesta, on hyvä tietää mitä hyviä ja huonoja puolia kehittäjien käyttämissä mittareissa on Mika Katara: Ohjelmistojen testaus, 2011 242
Hyvää yksikkötestausta täytyy vaatia ohjelmointitiimeiltä ja alihankkijoilta Testien laatuun panostaminen on parempi strategia kuin vain mittareiden tuijottaminen Lisäksi testit on vain yksi laadunvarmistuksen keino: koodikatselmoinnit, staattinen analyysi, jne. ovat myös tärkeitä Yksikkötason metriikat saadaan automaattisesti työkaluilta, jotka on integroitu yksikkötestaukseen ja/tai matalan tason integrointitestaukseen Näitä on helppo käyttää vaatimuksina seuraavaan vaiheeseen siirtymiselle (laatuportit) Mika Katara: Ohjelmistojen testaus, 2011 243 laske tulokset alustukset Havainnollistetaan erilaisia kattavuusmittoja esittämällä testattava ohjelma oheisen kulkukaavion mukaisella notaatiolla Testauksessa ollaan kiinnostuneita ohjelman käyttäytymisistä, joita vastaavat eri suorituspolut Suorituspolku kuvaa ohjelman kontrollin kulkua testikohteen alusta sen loppuun ohjelmaa suoritettaessa ei opiskelijoita jäljellä kyllä hae seuraavan opiskelijan tiedot mukana tentissä kyllä määrää arvosana ei laske arvosanajakauma loppu päivitä opiskelijan tiedot Esimerkki lähteestä [Haikala&Märijärvi 06] Mika Katara: Ohjelmistojen testaus, 2011 244
Polkukattavuus Path coverage Koska tavoitteena pitäisi olla mahdollisimman kattava testaus, olisi luonnollista vaatia, että kaikki mahdolliset suorituspolut tulee käytyä läpi Ongelma I: silmukat tekevät polkujen määrän liian suureksi monet ohjelmat on tarkoitettu pyörimään ikuisessa silmukassa valmiina vastaanottamaan ulkopuolisia ärsykkeitä => ääretön määrä suorituspolkuja voidaan saavuttaa vain esim. yhden funktion sisällä Ongelma II: kaikki ohjelmakoodia tutkimalla löydetyt polut eivät ole välttämättä suorituksessa mahdollisia esim. jonkin polun suorittaminen funktion läpi edellyttää tiettyä parametrin arvoa, jolla ko. funktiota ei ikinä kutsuta Mika Katara: Ohjelmistojen testaus, 2011 245 laske tulokset Kuinka monta eri suorituspolkua oheisella ohjelmalla on? Toisin sanoen, kuinka monta erilaista tapaa on päästä alkusolmusta loppusolmuun? Jos opiskelijoita on n kappaletta, ja jokaisen kohdalla on kaksi mahdollisuutta sen mukaan onko osallistunut tenttiin vai ei: 2 n Jos kyseessä olisi 100:n opiskelijan kurssi (OHJ-3060), olisi suorituspolkuja 2 100 Jos silmukasta voisi hypätä pois kesken kaiken, olisi polkuja vielä paljon enemmän: 2 n +2 n-1 +2 n-2 + +2 1 +2 0 ei alustukset opiskelijoita jäljellä kyllä hae seuraavan opiskelijan tiedot mukana tentissä kyllä määrää arvosana päivitä opiskelijan tiedot ei laske arvosanajakauma loppu Mika Katara: Ohjelmistojen testaus, 2011 246
Polkukattava testaus on siis käytännössä saavuttamaton tavoite Vaikka se saavutettaisiinkin, ei se takaisi kuitenkaan virheettömyyttä: Ehkä on toteutettu jotain muuta kuin mitä asiakas haluaa Ehkä on jätetty toteuttamatta joitakin haluttuja polkuja Vaikka kaikki mahdolliset polut käytäisiinkin läpi, voidaan funktion parametrien arvot valita huonosti siten, etteivät virheet paljastu esim. if(5/x + 5 < 10) polkukattavuuteen riittää, että testataan arvoilla 0<x 1 ja x>1, mutta arvolla x=0 ei välttämättä testata eikä virhettä huomata Mika Katara: Ohjelmistojen testaus, 2011 247 Lausekattavuus Mikäli jokaista ohjelman lausetta kohden löytyy joukosta suorituspolkuja (eli joukosta testitapauksia) vähintään yksi polku, joka suorittaa ko. lauseen sanotaan joukon testaavan ohjelman lausekattavasti Toisin sanoen, joukko testitapauksia suorittaa jokaisen lauseen ainakin kerran ei laske tulokset alustukset opiskelijoita jäljellä kyllä hae seuraavan opiskelijan tiedot mukana tentissä kyllä ei laske arvosanajakauma loppu määrää arvosana päivitä opiskelijan tiedot Mika Katara: Ohjelmistojen testaus, 2011 248
Mikäli ohjelmassa on 100 lausetta, joista testitapaukset suorittavat 63, sanotaan lausekattavuuden olevan 63 % 100 % polkukattavuudesta seuraisi luonnollisesti 100 % lausekattavuus Mika Katara: Ohjelmistojen testaus, 2011 249 Päätöskattavuus Branch/decision coverage Kuten jo edellä huomattiin, kontrollin haarautumiskohdat ovat avainasemassa testikattavuutta määriteltäessä Päätöskattavuus vaatii, että jokainen päätös saa testattaessa molemmat arvonsa Päätöskattavuus tarkoittaa, että kulkukaaviossa jokainen kaari täytyy käydä läpi a==0 && b>0 kyllä ei Mika Katara: Ohjelmistojen testaus, 2011 250
Päätöskattavuus on vahvempi vaatimus kuin lausekattavuus: if(a==0 && b>0) { a++; } Lausekattavaan testaukseen riittää nyt yksi testitapaus esim. (a=0, b=1), mutta päätöskattavuuteen tarvitaan vähintään kaksi esim. (a=0, b=1) ja (a=1, b=1) foo alustukset a==0 && b>0 kyllä a++ loppu ei Mika Katara: Ohjelmistojen testaus, 2011 251 Mikäli testitapausten ajon seurauksena esim. 100:sta mahdollisesta päätöksestä on tehty 54, sanotaan testien päätöskattavuuden olevan 54 % 100 % päätöskattavuudesta seuraa 100 % lausekattavuus tietyin oletuksin: Koodissa on vähintään yksi päätös Suoritus alkaa aina koodin alusta (ei goto-käskyjä tms.) Lisäksi poikkeusten laukeaminen saattaa aiheuttaa sen, että vaikka kaikki päätökset saataisiinkin katettu, ei kaikkia lauseita saada katettua Mika Katara: Ohjelmistojen testaus, 2011 252
Ehtokattavuus Condition coverage Edellä saavutettiin päätöskattavuus kahdella testitapauksella, joiden avulla päätös sai molemmat mahdolliset arvonsa Päätös kuitenkin koostui kahdesta totuusarvoisesta ehdosta (a==0) ja (b>0), joista toinen sai esimerkissä vain toisen arvonsa Totuusarvoiset ehdot eroavat päätöksistä siinä, että ne eivät sisällä loogisia operaattoreita kuten AND tai OR Ehtokattavuus: jokainen ehto evaluoituu todeksi ja epätodeksi Huom! Ehtokattavuudesta ei välttämättä seuraa päätöskattavuutta: esimerkin tilanteessa testitapaukset (a=0, b=0) ja (a=1, b=1) tyydyttävät ehtokattavuuden, mutta eivät päätöskattavuutta Mikäli vaaditaan sekä päätös- että ehtokattavuus vastaavaa mittaria kutsutaan päätös/ehtokattavuudeksi Mika Katara: Ohjelmistojen testaus, 2011 253 Moniehtokattavuus Multiple condition coverage Moniehtokattavuus vaatii, että päätöksen kaikkien ehtojen molempien arvojen kaikki mahdolliset kombinaatiot tulee käytyä läpi Mikäli päätös koostuu n:stä ehdosta, tarvitaan korkeintaan 2 n kpl testitapauksia, jotta moniehtokattavuus saavutettaisiin ko. päätöksen osalta Edellisessä esimerkissä moniehtokattavuus saadaan tyydytettyä esim. testitapauksilla (a=0, b=0), (a=1, b=0), (a=0, b=1) ja (a=1, b=1) Mika Katara: Ohjelmistojen testaus, 2011 254
100 % moniehtokattavuudesta seuraa 100 % päätöskattavuus 100 % ehtokattavuus 100 % päätös/ehtokattavuus Mikäli päätös muodostuu toisensa poissulkevista ehdoista esim. (a<0 a>4), silloin kombinaatio, jossa molemmat ehdot täyttyvät, ei luonnollisestikaan ole mahdollinen Siksi määritelmämme pitäytyy mahdollisissa kombinaatioissa Huom! Monissa ohjelmointikielisissä käytössä oleva oikosulkuevaluointi vähentää myös mahdollisten kombinaatioiden määrää Mika Katara: Ohjelmistojen testaus, 2011 255 Moniehtokattavuuden voi määritellä sitenkin, että yhden päätöksen kaikkien ehtojen kombinaatioiden sijasta pitääkin kattaa kaikkien ohjelman/funktion ehtojen kaikki kombinaatiot Näin päästään vieläkin kattavampaan testaukseen Testikattavuustyökaluista esim. CTC++ pitäytyy aluksi esitetyssä määritelmässä Mika Katara: Ohjelmistojen testaus, 2011 256
6.2 Mutkikkuusmitat Complexity measure Idea: kohdistetaan testausta monimutkaisimpiin osiin koodia Käyttökelpoinen lähinnä yksikkötestauksessa Mitataan yksikön mutkikkuutta ja testataan sitä tarpeen mukaan enemmän tai vähemmän Perustuu yleensä koodin rakenteen staattiseen analysointiin Mika Katara: Ohjelmistojen testaus, 2011 257 LOC Lines of Code Käytetään yleisesti mittaamaan paitsi koodin pituutta myös esim. ohjelmoijien tuottavuutta (LOC/henkilötyökuukausi) Voisiko koodirivien määrää käyttää mutkikkuuden mittana? Mitä pidempi funktio, sen mutkikkaampi? Oletetaan, että LOC on hyvä monimutkaisuuden mittari Otetaan kielellä X toteutettu ohjelma P, jonka pituus on 1000 LOC Portataan ohjelma kielelle Y Mika Katara: Ohjelmistojen testaus, 2011 258
Uuden toteutuksen pituus on 500 LOC Vähenikö ohjelman monimutkaisuus puoleen vai onko kieli Y vain ilmaisuvoimaisempi kuin X? Johtopäätös I: LOC on varmastikin hyvä koodin pituuden mittari, mutta huono mutkikkuusmittari (ainakin yksinään) Johtopäätös II: hyvä mutkikkuusmittari ei ole herkkä käytettävälle ohjelmointikielelle Edellä olisi tietysti voitu laskea mittarin arvolle skaalausvakio siirryttäessä kielestä toiseen Mika Katara: Ohjelmistojen testaus, 2011 259 Halsteadin mittarit 1970-luvun puolen välin tienoilla Maurice Halstead esitteli Software Science -teorian (Elements of Software Science, New York, Elsevier North-Holland, 1977) ja siitä johdetun joukon mittareita Ohjelman määritellään olevan kokoelma merkkejä (token), jotka jaetaan operaattoreihin ja operandeihin Operaattoreita ovat mm. varatut sanat, matemaattiset operaattorit jne. Perusmittarit ovat: u 1 = uniikkien operaattorien lukumäärä u 2 = uniikkien operandien lukumäärä N 1 = operaattorien kokonaismäärä N 2 = operandien kokonaismäärä Mika Katara: Ohjelmistojen testaus, 2011 260
Esim. C++-kielen lause a == b koostuu yhdestä operaattorista (==) ja kahdesta operandista (a ja b) Perusmittareiden avulla voidaan määritellä monimutkaisempia mittareita Ohjelman P Pituus (length) on N = N 1 + N 2 Sanasto (vocabulary) on u = u 1 + u 2 Volyymi (volume) on V = N x log 2 u Mika Katara: Ohjelmistojen testaus, 2011 261 Taso (program level) on L = V* / V, missä V* on pienimmän mahdollisen toteutuksen volyymi Tason käänteisluku on vaikeus (difficulty) D = 1 / L Tekemiseen (ymmärtämiseen) tarvittavan ponnistuksen arvio on E = (u 1 x N 2 x N x log 2 u) / (2 x u 2 ) Tekemiseen tarvittava aika T = E / 18 sekuntia Mika Katara: Ohjelmistojen testaus, 2011 262
Joissain tutkimuksissa on löydetty yhteys N:n arvon ja moduulin sisältämien virheiden määrän väliltä Software Science teoria on kuitenkin toistuvasti kyseenalaistettu Mittareiden määritelmissä on myös mittausteoreettisia ongelmia Toisaalta esim. SEI:n ylläpidettävyysindeksin laskennassa tarvitaan Halsteadin volyymin V arvoa Mika Katara: Ohjelmistojen testaus, 2011 263 McCaben syklomaattinen numero Perustuu lähteeseen Thomas J. McCabe, A Complexity Measure, IEEE Transactions on Software Engineering, SE- 2(4), Dec. 1976 Graafiteoreettinen pohja ohjelmien monimutkaisuuden ja testaustarpeen arvioinnille Syklomaattinen numero v(g) graafille G, jossa n solmua, e kaarta ja p kytkettyä komponenttia on v(g) = e n + p Vahvasti kytketyssä graafissa G (eli jokaisesta solmusta pääsee jotain polkua pitkin jokaiseen solmuun), syklomaattinen numero vastaa lineaarisesti riippumattomien piirien maksimimäärää Piiri on polku, jonka alkusolmu on sama kuin loppusolmu Mika Katara: Ohjelmistojen testaus, 2011 264
McCabe soveltaa tätä tietoa seuraavasti Esitetään ohjelman rakenne suunnattuna kontrolligraafina, jossa on yksikäsitteiset alku- ja loppusolmut Solmut vastaavat peräkkäisiä ohjelman lauseita ja kaaret kontrollin kulkua Oletetaan, että alkusolmusta on olemassa polku kaikkiin solmuihin kaikista solmuista on olemassa polku loppusolmuun Mika Katara: Ohjelmistojen testaus, 2011 265 Jos kuvitellaan ylimääräinen kaari loppusolmusta alkusolmuun, kontrolligraafi on vahvasti kytketty: 9 1 a 2 3 5 b 4 c 7 d 10 e 6 8 f Mika Katara: Ohjelmistojen testaus, 2011 266
Yleensä tutkitaan yhtä funktiota kerrallaan, joten p=1 Toisaalta, ylimääräinen kaari loppusolmusta voidaan unohtaa, jos se otetaan vakiona laskuissa huomioon Piirien sijaan voidaan nyt puhua poluista alkusolmusta loppusolmuun, joten kaava pelkistyy muotoon v(g) = e - n + 2 Jos kaikki päätökset ovat binäärisiä, eli jokaisesta solmusta lähtee korkeintaan kaksi kaarta, yksinkertaistuu kaava (todistus sivuutetaan) entisestään muotoon v(g) = h + 1, jossa h on päätösten lukumäärä Mika Katara: Ohjelmistojen testaus, 2011 267 Tässä oletetaan, että AND:llä kytketyt ehdot erotetaan omiksi päätöksikseen esim. IF c1 AND c2 THEN IF c1 THEN IF c2 THEN Mikäli päätökset eivät ole binäärisiä, kuten CASE-lauseen tapauksessa, voidaan tilannetta simuloida käyttämällä useampaa IF-lausetta Mika Katara: Ohjelmistojen testaus, 2011 268
v(g):n ominaisuuksia v(g) 1 G:ssä on vain yksi polku jos ja vain jos v(g) = 1 v(g) on lineaarisesti riippumattomien G:n polkujen maksimimäärä eli peruspolkujen lukumäärä Peräkkäisten lauseiden lisäämisellä ei ole vaikutusta v(g):hen Uuden haarauman lisääminen kasvattaa v(g):tä yhdellä v(g) riippuu vain G:n päätösten rakenteesta ja lukumäärästä Tutkimuksissa on löydetty korrelaatio virheiden määrän ja v(g):n arvon väliltä Mika Katara: Ohjelmistojen testaus, 2011 269 Suositus on, että jokaisen funktion v(g) 10 Tätä mutkikkaammat funktio ovat luultavasti vaikeita ylläpitää ja testata Tarvittaessa funktio pitäisi hajottaa kahteen tai useampaan yksinkertaisempaan funktioon McCaben mukaan funktio pitäisi testata ainakin sellaisilla testitapauksille, jotka kattavat peruspolut Peruspolkujen joukko ei tosin ole yksikäsitteinen Näiden peruspolkujen määrä on helppo laskea (v(g)), mutta niiden keksiminen ei ole yksinkertaista ainakaan ilman työkaluja Mika Katara: Ohjelmistojen testaus, 2011 270