Ohjelmistotekniikka - Luento 10

Ohjelmistotekniikka - Luento 10 Luku 17: Testausstrategiat V-malli ja vaiheet yksikkö- ja integrointitestaus validointitestaus järjestelmätestaus debuggaus Luku 18: Perinteisten sovellusten testaus testattavuus valkealaatikko- ja mustalaatikkotestaus mallipohjainen testaus (testivetoisen ohjelmistokehityksen ominaisuudet) Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila

Soveltuvat lait ja pohdiskelun aiheita 1. Testauksella voidaan esittää virheiden olemassaolo, mutta ei todistaa virheettömyyttä / no 22, Dijkstra 1970 2. Noin 80 % virheistä tulee 20 % moduuleista / no 24, Pareto 1897, Fenton 2000 Mitkä ominaisuudet tekevät ohjelmistosta helpommin testattavan? Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 2

Ohjelmiston testaus Testing is the process of exercising a program with the specific intent of finding errors prior to delivery to the end user. Testauksessa pyritään etsimään ohjelmasta (ohjelmaa suorittamalla) virheitä ennen sen toimittamista asiakkaalle. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 3

Testauksella saadaan esille virheet vaatimusten noudattaminen suorituskyky tuntuma laatuun Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 4

Millä tekniikoilla ohjelmiston laatua parannetaan? Käyttäjän tarpeet Ohjelmisto käytössä Vaatimusmäärittely Yksikkötestaus Käytettävyystestaus Tarkastus (formaali tekninen katselmointi) eri vaiheissa Toiminnallinen suunnittelu - käyttöliittymän suunnittelu - käyttötapausanalyysi Puhdastila (Cleanroom) Testisuunnitelmat Toiminnallinen testaus Regressiotestaus Koodaus Ohjelmistosuunnittelu Integrointitestaus Järjestelmätestaus Hyväksymistestaus Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 5

Verification vs. validation Verification (todentaminen) V-mallin vasen puoli (tarkastus) are we building the product right Validation (osoittaminen kelvolliseksi) V-mallin oikea puoli (testaus) are we building the right product Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 6

Kuka testaa? kehittäjä Understands the system but, will test "gently" and, is driven by "delivery" riippumaton testaaja Must learn about the system, but, will attempt to break it and, is driven by quality Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 7

Testausstrategiat yksikkötesti validointitesti järjestelmätesti integrointitesti Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 8

Testausstrategia Aloita testing-in-the-small ja siirry kohti testing-in-thelarge Perinteiselle ohjelmistolle aluksi kohteena moduulit sitten integrointi Olio-ohjelmistolle aluksi kohteena luokka, joka kapseloi attribuutit ja operaatiot sitten siirrytään luokkien väliseen kommunikointiin ja yhteistyöhön Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 9

Strategiset tehtävät Aseta selvät tavoitteet. Ymmärrä, keitä ovat ohjelmiston käyttäjät ja kehitä jokaiselle käytäjäluokalle oma profiili. Kehitä testisuunnitelma, joka korostaa rapid cycle testing. Rakenna kestävä ohjelmisto, joka testaa itse itseään. Käytä tehokasta katselmointia (formal technical reviews) jo ennen tastausvaiheita. Kohdista katselmointia myös testausstrategiaan ja testitapauksiin. Paranna testausprosessia jatkuvasti. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 10

Yksikkötestaus testattava moduuli tulokset ohjelmisto suunnittelija testitapaukset Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 11

testattava moduuli rajapinnat paikalliset tietorakenteet raja-arvot riippumattomat polut virheiden käsittelypolut testitapaukset Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 12

Yksikkötestauksen ympäristö (driver) Moduuli ajuri rajapinnat paikalliset tietorakenteet raja-arvot riippumattomat polut virheiden käsittelypolut (stub) tynkä tynkä testitapaukset Tulokset Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila

Top Down Integrointi A moduulia testataan tynkien kanssa B F G C tyngät korvataan yksi kerrallaan (depth first) D E kun uusia moduuleita integroidaan osa testeistä ajetaan uudelleen Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 14

Bottom-Up Integrointi A B F G C Ajurimoduulit korvataan yksi kerrallaan depth first ryväs D E moduulit on ryhmitelty buildeiksi ja integroitu Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 15

Sandwich Testaus A B F G Moduulit testataan tynkien kanssa C D E moduulit on ryhmitelty buildeiksi ja integroitu ryväs Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 16

Regressiotestaus Integrointitestauksen tärkeä osa. Kun tehdään suurempia muutoksia tai lisätään uusi moduuli, varmistetaan ettei muutos/lisäys aiheuta ongelmia aikaisemmin virheettömissä osissa (sivuvaikutusten poistaminen). Regressiotestit koostuvat kolmenlaisista testeistä edustava otos testeistä, jotka testaavat kaikkia toimintoja lisätestejä, jotka kohdistuvat toimintoihin, joihin muutos todennäköisimmin vaikuttaa testejä, jotka kohdistuvat muutettuihin ohjelmistokomponentteihin Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 17

Savutestaus (Smoke Testing) Integrointitestaukseen kuuluva testi. Käytetään ohjelmistotuotteen päivittäisten lisäysten testaamiseen - perustuu testattavien koosteiden ( buildien ) luontiin Savutestauksen vaiheet: Ohjelmistokomponentit, jotka on käännetty koodiksi, integroidaan testattavaksi koosteeksi (buildiksi) Tämä osa sisältää kaikki tarvittavat datatiedostot, kirjastot, uudelleenkäytettävät moduulit ja rakennetut komponentit, joita tarvitaan yhden tai useamman tuotteen toiminnon toteutukseen Suunnitellaan joukko testejä, joilla löydetään vakavat virheet, jotka estävät testattavaa osaa toimimasta määrittelyjen mukaisesti Tarkoituksena on paljastaa show stopper virheet, eli virheet jotka todennäköisesti viivästyttäisivät projektia. Osa integroidaan muiden osien kanssa ja koko tuote (sen hetkisessä muodossa) testataan päivittäin Integrointi voi tapahtua top down tai bottom up. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 18

OOT Strategia luokkatestaus vastaa yksikkötestausta luokan operaatiot testataan luokan tilakäyttäytyminen testataan integrointitestauksessa kolme strategiaa säieperustainen testaus - integroidaan luokat, joita tarvitaan käsittelemään jonkin syöte tai tapahtuma käyttöpohjainen testaus - integroidaan luokat, joita tarvitaan jokin käyttötapauksen mukaiseen toimintaan ryväspohjainen testaus - integroidaan luokat, joita tarvitaan toteuttamaan haluttu yhteistyö Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 19

Olioperustainen testaus aloitetaan arvioimalla OOA ja OOD mallien oikeellisuutta ja yhdenmukaisuutta muutokset testausstrategiassa yksikkö-käsite laajenee kapseloinnin tuloksena integrointi kohdistuu luokkiin ja niiden suoritukseen säikeessä tai käyttöskenaarion rajaamana ryvästestausta (cluster) käytetään testaamaan yhteistyössä toimivien luokkien toimintaa Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 20

Olioperustaisen koodin tarkastus ja testaus Koodin ymmärtämisen ja siten myös tarkastuksen ja testauksen ongelmana on toiminnallisuuden hajautuminen pienen palan ymmärtäminen vaatii monien muiden metodien ja luokkahierarkioiden läpikäyntiä Dunsmore et al. IEEE Software July/August 2003 private void purge() { GregorianCalendar today = new GregorianCalendar(); today.roll(calendar.date, false); for (int i=0; i < reservations.size(); i++) { if (today.after(((reservation)reservations.elementat(i)).getdate())) { reservations.removeelementat(i); date = 0; } } } Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 21

Toiminnallisuuden hajautuminen (delocalization) Luokat Java luokkakirjastossa Calendar Muut systeemiluokat Reservation GregorianCalendar Video purge() Vector purge operaation dokumentointi Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 22

Validointitestaus Validointitestaus / hyväksymistestaus testataan, että vaatimuksissa asetetut tavoitteet toteutuvat testisuunnitelma voidaan tehdä jo vaatimusten määrittelyvaiheessa Alpha/Beta testaus järjestelmään testataan asiakkaan toimesta alphatestaus suoritetaan kehittäjän tiloissa kontrolloidussa testitilanteessa ja myös kehittäjä osallistuu testitilaisuuteen betatestaus suoritetaan valittujen asiakkaiden omissa tiloissa, asiakkaat kirjaavat ongelmat ja raportoivat kehittäjälle Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 23

Järjestelmätestaus Järjestelmätestaus on joukko testejä, joiden tarkoituksena on testata, että järjestelmän integrointi on onnistunut ja että järjestelmä toteuttaa sille määritellyt toiminnot Elpymistestaus (Recovery testing) aiheutetaan järjestelmän kaatuminen ja testataan, että elpyminen (esim. tietokanta) toimii Turvallisuustestaus (Security testing) varmistetaan, että rakennetut turvatoimet suojaavat järjestelmää luvattomalta käytöltä, väärinkäytöltä ja hyökkäyksiltä Kuormitustestaus (Stress testing) testataan järjestelmän sietoa epätavallisen suurella käyttäjämäärällä, syöttötiedolla ja toimintaa muistin ylärajoilla Suorituskykytestaus (Performance testing) testataan integroidun järjestelmän suorituskykyä (pysyy asetetuissa rajoissa) Toimituksen testaus (Deployment testing) ohjelmiston täytyy toimia useilla alustoilla (platform), eli tarkoittaa samaa kuin konfiguraatiotestaus (tärkeä erityisesti Web-sovelluksissa) Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 24

Aikaisemmin esitelty esimerkki: VirtualShowRoom Autonvalmistaja haluaa web-pohjaisen autojen myyntijärjestelmän (VirtualShowRoom, VSR). Tätä ohjelmistoa tarjotaan käyttöön kaikille asiakkaille maailmanlaajuisesti. Auton ostosta kiinnostunut asiakas voi sen avulla määritellä haluamansa auton ominaisuudet (malli, tyyppi, väri, lisävarusteet, jne.). Kun asiakas on tehnyt ostopäätöksen, hän voi vahvistaa tilauksen, valita sopivan maksutavan ja maksaa tilauksen. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 25

Vaatimuksista johdetut testitapaukset (hinnan laskenta VSR järjestelmässä) R 100: Käyttäjä voi valita automallin mallilistasta R 101: Valittuun automalliin saatavat lisävarusteet esitellään. Käyttäjä voi valita halutut lisävarusteet listasta. R 102: Kokonaishinta valitulle konfiguraatiolle lasketaan jokaisen valinnan jälkeen ja näytetään välittömästi käyttäjälle. Testitapaukset, joita voi käyttää järjestelmätestauksessa ja hyväksymistestauksessa. T 102.1: Automalli on valittu, esitteen mukainen auton perushinta näytetään käyttäjälle T 102.2: Lisävaruste on valittu, auton hintaan on lisätty lisävarusteen hinta ja se näytetään käyttäjälle T 102.3: Lisävaruste on poistettu, auton hinnasta on vähennetty lisävarusteen hinta ja se näytetään käyttäjälle T 102.4: Kolme lisävarustetta on valittu, tällöin tulee mukaan alennusprosentti, joka on määritelty dokumentissa XX. Testataan, että alennusprosenttia käytetään määrittelyn mukaisesti. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 26

Lisähuomioita Muutetaan testattavaa koodia testien suoritusten jälkeen, lisäämällä ei-toimivaa (mutta kääntyvää) koodia Jos testit menevät läpi, testit eivät testaa oikeita asioita Elpymistestaus ylläolevan kanssa Keskellä asetusten tms. kirjoitusprosessia tiedostoon, aiheutetaan tarkoituksella ohjelman kaatuminen (esim. lisäämällä poikkeuksen heittäminen ko. kohtaan) Käynnistetään ohjelma ja katsotaan miten se pystyy käsittelemään korruptoituneen asetustiedoston lukemisen Mietitään miten estetään asetustiedoston korruptointi kesken sinne kirjoittamisen Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 27

Debuggaus: diagnosointi Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 28

Debuggausprosessi testitapaukset regressio testit uudet testitapaukset epäillyt syyt tulokset korjaukset tunnistetut syyt Debuggaus Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila

Mihin aika kuluu debuggauksessa? korjataan virheet ja suoritetaan regressiotestaus diagnosoidaan oireet ja syyt Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 30

Oireet & syyt oire ja sen syy voivat olla sijaita eri paikoissa oire voi hävitä, kun korjataan jotain toista ongelma syynä voi olla virheettömien osien yhdistelmä syynä voi olla järjestelmä- tai kääntäjävirhe oire syy/ aiheuttaja syynä voi olla oletukset, joihin kaikki uskovat oireet voivat olla ajoittaisia Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila

Virheiden vaikutukset damage infectious catastrophic extreme serious disturbing annoying mild Bug Type Bug Categories: function-related bugs, system-related bugs, data bugs, coding bugs, design bugs, documentation bugs, standards violations, etc. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 32

Häiriö (failure) = järjestelmä ei käyttäydy käyttäjän tai asiakkaan toivomalla tavalla Jos puutteellisuutta ei löydetä kehitysvaiheessa, ohjelmaan jää vika (fault), joka aiheuttaa joko säännöllisiä tai satunnaisia häiriöitä Ohjelmistosuunnittelija tai ohjelmoija tekee virheen (mistake), joka aiheuttaa puutteellisuuden (defect, bug) ohjelmistosuunnitelmaan tai koodiin Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 33

Luku 18: Perinteisten sovellusten testaus - testattavuus - valkealaatikko- ja mustalaatikkotestaus - mallipohjainen testaus - (testivetoisen ohjelmistokehityksen ominaisuudet) - (seitsemän periaatetta ohjelmistojen testaukseen) Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila

Testaustaktiikat: Testattavuus/ Bach 2003 Testattavuus = kuinka helposti ohjelma voidaan testata Ohjattavuus (Controllability) The better we can control it, the more the testing can be automated and optimized Havainnollisuus (Observability) What you see is what can be tested Saatavuus (Availability) To test it, we have to get at it Yksinkertaisuus (Simplicity) The simpler it is, the less there is to test Vakaus (Stability) The fewer the changes, the fewer the disruptions to testing Informaatio (Information) The more information we have, the smarter we will test Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 35

Testitapauksen suunnittelu "Bugs lurk in corners and congregate at boundaries..." Boris Beizer OBJECTIVE CRITERIA CONSTRAINT paljastaa virheet täydellisesti minimityöpanoksella ja ajalla Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 36

Perusteellinen testaus loop < 20 X Jos on esim. 100 rivin ohjelma, jossa on kaksi sisäkkäistä silmukkaa, jotka suoritetaan 1-20 kertaa. Jos vielä sisemmässä silmukassa on neljä if-then-else rakennetta, niin ohjelmassa on arviolta 10 14 mahdollista testattavaa polkua. Jos yhden testitapauksen suoritukseen menee millisekunti, perusteellinen testaus vie 3170 vuotta!! Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila

Valikoiva testaus Selected path Testikattavuutta voidaan arvioida - lausekattavuudella - päätöskattavuudella - ehtokattavuudella - polkukattavuudella Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 38

Ohjelmiston testaustekniikat white-box methods black-box methods Methods Strategies Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 39

Käyttäjän tarpeet Ohjelmisto käytössä Vaatimusmäärittely Yksikkötestaus Käytettävyystestaus Tarkastus eri vaiheissa Toiminnallinen suunnittelu - käyttöliittymän suunnittelu - käyttötapaus-analyysi Puhdastila (Cleanroom) Testisuunnitelmat Toiminnallinen testaus Ohjelmistosuunnittelu Integrointitestaus Järjestelmätestaus Regressiotestaus Musta laatikko Koodaus Hyväksymistestaus Valkea laatikko Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 40

Valkea laatikko testaus... varmistetaan, että jokainen lause ja ehto on suoritettu ainakin kerran Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 41

Polkutestaus Syklomaattinen kompleksisuus yksinkertaisten päätösten määrä + 1 tai rajattujen alueiden määrä + 1 Tässä V(G) = 4 Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 42

Syklomaattinen kompleksisuus Tutkimusten mukaan voidaan päätellä, että mitä korkeampi moduulin V(G) arvo, sitä suurempi todennäköisyys virheille nämä moduulit ovat virheherkimpiä V(G) 1-10 yksinkertainen, pieni riski 11-20 mutkikkaampi, keskinkertainen riski 21-50 mutkikas, korkea riski > 50 ei testattava, erittäin korkea riski Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 43

Polkutestaus 1 Koska V(G) = 4, on neljä riippumatonta polkua 2 4 3 5 6 Path 1: 1,2,3,6,7,8 Path 2: 1,2,3,5,7,8 Path 3: 1,2,4,7,8 Path 4: 1,2,4,7,2,4,...7,8 7 8 Sitten täytyy kehittää testitapaukset, joilla polut testataan Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 44

Mustalaatikkotestaus vaatimukset tulosteet syötteet tapahtumat Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 45

Mustalaatikkotestaus Mustalaatikkotesteissä keskitytään esim. näihin kysymyksiin Miten toiminnallinen oikeellisuus testataan? Miten järjestelmän käyttäytymistä ja suorituskykyä testataan? Mistä syöttötiedoista (luokista) saadaan hyviä testitapauksia? Onko järjestelmä erityisen herkkä tietyille syötteille? Millaisia tietomääriä järjestelmä kestää? Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 46

Ekvivalenssiositus Ekvivalenssiositus & rajaarvoanalyysi päätellään ensin ekvivalenssiluokat ja sitten määritellään luokkia edustava testiaineisto syötteiden perusteella saadaan käypien arvojen arvoalue, käypien arvojen lukumäärä, käypien arvojen joukko käypien (sopivien) arvojen alueelta määritellään yksi testiarvo ja ei-käypien (sopimattomien) alueelta kaksi testiarvoa Raja-arvoanalyysi keskitytään testaamaan ekvivalenssiosituksen raja-arvokohtia Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 47

Esimerkki ekvivalenssiosituksesta ja raja-arvoanalyysistä Ohjelmassa tutkitaan 1930 ja 1960 välillä syntyneitä henkilöitä testataan henkilöillä, jotka ovat syntyneet 1930-1960 välillä ja ennen 1930 sekä jälkeen 1960 testataan henkilöillä, jotka ovat syntyneet 1920, 1950, 1970, (1929), (1930), (1931), (1959), (1960), (1961) 1930 1960 sopimaton alue sopiva arvoalue sopimaton alue Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 48

VSR järjestelmä: calculate_price funktion testaus Funktio määritellään seuraavasti Auton perusmallin hinta on perushinta (baseprice), josta on vähennetty alennus (discount). Auton myyjä määrittelee alennuksen. Ostaja voi ostaa myös erikoismallin ja erikseen lisävarusteita. Lisävarusteiden alennusprosentti (addon_discount) on 10%, jos lisävarusteita (extras) on enemmän kuin 3 ja 15%, jos lisävarusteita on enemmän kuin 5. Auton hinta muodostuu siten perushinnasta, mahdollisesta erikoismallin hinnasta (specialprice) ja mahdollisten lisävarusteiden hinnasta (extraprice). Jos myyjän antama alennusprosentti on suurempi kuin lisävarusteiden, käytetään myyjän antamaa alennusprosenttia. Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 49

VSR järjestelmä: calculate_price funktion testaus double calculate_price(double baseprice, double specialprice, double extraprice, int extras, double discount) { double addon_discount; double result; if (extras >= 5) addon_discount = 15; else if (extras >= 3) addon_discount = 10; else addon_discount = 0; if (discount > addon_discount) addon_discount = discount; } result = baseprice/100.0*(100-discount) + specialprice + extraprice/ 100.0*(100-addon_discount); return result; Huom: funktiossa ei kaikkea syötteiden tarkistusta, tehdään ennen kutsua Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 50

Parametri Ekvivalenssiluokka Testiaineisto baseprice vec 11 : [0,..., MAX_DOUBLE] 20000.00 iec 11 : [MIN_DOUBLE,..., 0 [ iec 12 : ei numero -1.00 abc specialprice vec 21 : [0,..., MAX_DOUBLE] 3450.00 iec 21 : [MIN_DOUBLE,..., 0 [ iec 22 : ei numero -1.00 abc extraprice vec 31 : [0,..., MAX_DOUBLE] 6000.00 extras iec 31 : [MIN_DOUBLE,..., 0 [ iec 32 : ei numero vec 41 : [0,...,2] vec 41 : [3, 4] vec 41 : [5,...,MAX_INT] iec 41 : [MIN_INT,..., 0 [ iec 42 : ei numero -1.00 abc 1 3 20-1.00 abc discount vec 51 : [0,..., 100] 10.00 iec 51 : [MIN_DOUBLE,..., 0 [ iec 52 : iec 53 : ei numero -1.00 101.00 abc Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 51

testitapaus baseprice specialprice extraprice extras discount result 1 20000.00 3450.00 6000.00 1 10.00 26850.00 2 20000.00 3450.00 6000.00 3 10.00 26850.00 3 20000.00 3450.00 6000.00 20 10.00 26550.00 4-1.00 3450.00 6000.00 1 10.00 NOT_VALID 5 abc 3450.00 6000.00 1 10.00 NOT_VALID 6 20000.00-1.00 6000.00 1 10.00 NOT_VALID 7 20000.00 abc 6000.00 1 10.00 NOT_VALID 8 20000.00 3450.00-1.00 1 10.00 NOT_VALID 9 20000.00 3450.00 abc 1 10.00 NOT_VALID 10 20000.00 3450.00 6000.00-1.00 10.00 NOT_VALID 11 20000.00 3450.00 6000.00 abc 10.00 NOT_VALID 12 20000.00 3450.00 6000.00 1-1.00 NOT_VALID 13 20000.00 3450.00 6000.00 1 101.00 NOT_VALID 14 20000.00 3450.00 6000.00 1 abc NOT_VALID Testitapauksia tarvitaan 3 käypää (1*1*1*3*1) ja 11 ei-käypää (2+2+2+2+3) Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 52

VSR järjestelmä: calculate_price funktion testaus testiajuri bool test_calculate_price() { double price; bool test_ok = TRUE; //testitapaus 1 price = calculate_price(20000.00, 3450.00, 6000.00, 1, 10); test_ok = test_ok && (abs(price-26850.00) < 0.01); //testitapaus 2 price = calculate_price(20000.00, 3450.00, 6000.00, 3, 10); test_ok = test_ok && (abs(price-26850.00) < 0.01); } return test_ok; Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 53

Testivetoisen ohjelmistokehityksen ominaisuudet testit kirjoitetaan ennen ohjelmakoodia sama henkilö kirjoittaa testitapauksen ja koodin koodi ei mene tuotantoon ilman testitapausta testi ohjaa koodin toimintaa testi määrittelee koodin toiminnan testit ovat eristettyjä ja automatisoituja testit voidaan toistaa joka kerta samalla tavalla Astels 2003 Test-driven development Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 54

Testivetoisen ohjelmistokehityksen vaiheet Lisää testi Onnistui Testien mennessä onnistuneesti läpi voidaan ohjelmakoodi refaktoroida Kirjoita koodi Aja testit Tee korjaus koodiin Epäonnistui Epäonnistui Aja testit Kehitys jatkuu Kehitys loppui Ambler 2003 Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 55

Soveltuvat lait ja pohdiskelun aiheita 1. Testauksella voidaan esittää virheiden olemassaolo, mutta ei todistaa virheettömyyttä / no 22, Dijkstra 1970 perusteellinen testaus ei ole mahdollista 2. Noin 80 % virheistä tulee 20 % moduuleista / no 24, Pareto 1897, Fenton 2000 myös muita 20 % virheitä aiheuttaa 80 % korjaustyöstä 20 % moduuleista sisälsi 60 % virheistä 10 % virheistä aiheutti 90 % järjestelmän katkoista Jouni Lappalainen, Ilkka Tervonen, additions & editions by Antti Juustila 56

Whittaker J.A., What Is Software Testing? And Why It Is So Hard?, IEEE Software, vol 17, no 1, 2000, pp. 70-79 Jeffries R., Melnik G., TDD: The Art of Fearless Programming, IEEE Software, vol 24, no 3, 2007, pp. 24-30 Martin R., Professionalism and Test-Driven Development, IEEE Software, vol 24, no 3, 2007, pp. 32-36 57