Testaus. Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta.

Esitys aiheesta: "Testaus. Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta."— Esityksen transkriptio:

1 Testaus

2 Yleistä Testaus on suunnitelmallista virheiden etsimistä Tuotantoprosessissa ohjelmaan jää aina virheitä, käytettävistä menetelmistä huolimatta Hyvät menetelmät, kuten katselmoinnit pienentävät testauksen tarvetta Testaus pystyy todistamaan ainoastaan ohjelman virheellisyyden, ei virheettömyyttä Testi on onnistunut, kun tulos on oikea ja ohjelman (tai testattavan osan) sisäinen tila on muuttunut oikein

3 Kontrollipolkujen määrä 5 solmua – 120 permutaatiota 10 solmua – 3 628 800 permutaatiota 20 solmua – 2,4 x 10 18 permutaatiota -> 1 mrd suoritusta sekunnissa = 77 vuotta

4 Testaukseen riittävästi resursseja! VaiheKustannusosuus 1Vaatimukset3 % 2Määrittely5 % 3Suunnittelu7 % 4Koodaus6 % 5Moduulitestaus7 % 6Integrointi6 % 7Ylläpito67 %

5 Testausprosessi Suunnittelu Testidatan valmistelu Suoritetaan testi Verrataan tuloksia suunnitelmiin Virheen jäljitys Virheen jäljitys Testi- tapaukset Testidata Testi- tulokset Testi- raportit

6 Testauksen V-malli Päävaatimusten määrittely Järjestelmän spesifikaatio Arkkitehtuuri- suunnittelu Komponentti- suunnittelu Komponenttien koodaus / testaus Komponenttien testaus Integrointi- testaus Järjestelmän testaus Hyväksymis- testaus Päävaatimusten speksit Järjestelmän speksit Arkkitehtuurin speksit Moduulien speksit

7 Yleisiä suosituksia Toimintojen testaus on komponenttitestausta tärkeämpää Muutoksen jälkeen on tärkeämpää testata vanhat kuin uudet toiminnot On tärkeämpää testata tavanomaiset tapaukset kuin ääritapaukset Testiohjelmatkin on suunniteltava huolellisesti Virheet pyrkivät kasautumaan Testauksen täytyy olla suunnitelmallista Testaaja eri henkilö kuin tekijä

8 Lähestymistapa integroinnissa Top-down –Testataan ensin ylimmän tason moduulit niin, että korvataanalemman tason moduulit ”tynkämoduuleilla” Bottom-up –Testataan ensin alemman tason moduulit ja ylempi taso korvataan testiajureilla Käytännössä toteutetaan molempia??

9 Kaksi päätapaa testauksessa Sisäinen testaus (white-box testing) –Algoritmien virheettömyys –Otetaan huomioon komponentin rakenne ja tunnistetaan riskikohdat –Testiaineisto suunnitellaan niin, että mahdollisimman suuri osa koodista tulee toteutetuksi Ulkoinen testaus (black-box testing) –Keskitytään ulospäin näkyvään toimintaan toiminnallisuuksiin –Verrataan testattavan kokonaisuuden vastaavuutta vaatimusmäärittelyyn –Tutkitaan tulosarvoja (tiloja) suorituksen jälkeen –Voidaan suunnitella määrittelyvaiheessa

10 Käsitteitä Validointitestaus Regressiotestaus – muutoksen jälkeen Alfa-testaus – Toimittajan luona Beta-testaus – Asiakkan luona Julkistustestaus – Uusi versio

11 Sisäinen testaus Kontrollipolkujen läpikäynti –Suunnitellaan testitapaukset niin, että mahdollisimman moni tai ainakin yleisimmät polut tulee läpikäytyä Silmukat –Ohitus kokonaan –Yksi kierros –N-1, N ja N+1 kierrosta (esim. taulukoiden rajat) Oliokielissä voi olla vaikeaa

12 Ulkoinen testaus Puuttuvat tai virheelliset toiminnot Liittymävirheet Virheet tietorakenteissa tai tietokantojen käytössä Alustus- ja lopetusvirheet Suorituskykyongelmat Lukitusongelmat (tieto) syötetulos

13 Testisyötteiden valinta Jaetaan testisyötteet ekvivalenssiluokkiin: –sallittua väliä pienempi –sallitulla välillä –sallittua väliä suurempi –poikkeukset Esim. päivämäärän syöttö –testataan päivät 0, 1, 28-31, 32 –testataan kuukaudet 0, 1, 12, 13 –erikseen karkausvuosi Tilanne, jolloin rajoitettu tietorakenne tulee täyteen –N-1, N, N+1

14 Testisyötteiden valinta Binäärihaku – harmaalaatikkotestaus Valitaan kriittiset pisteet, jotka tiedetään, kun tunnetaan sisäinen toteutus Testataan myös eri kokoisella taulukolla –1 solu, parillinen määrä, pariton määrä 159141820232836

15 Virheenjäljitys on ongelmallista Virhe voi olla kaukana havaitsemispaikasta Virheen syy voi olla käyttäjässä Virheellistä toimintaa voi olla vaikea toistaa – syy voi olla pitkän toimintosarjan yhteensattumissa Virhe voi johtua esim. kääntäjän tai laitteiston erityispiirteistä (reaalilukujen yhtäsuuruus)

16 Mietittävä ennen korjausta 1.Voiko samanlaisia virheitä olla muuallakin ohjelmassa? Kannattaa tutkia, jos on aihetta epäilyyn. 2.Voiko korjaus aiheuttaa uusia virheitä? Tarkistetaan riippuvuudet huolellisesti. 3.Olisiko virhe voitu välttää tuotantoprosessissa. Otetaan oppia tulevaisuuteen (virhekanta).

17 Riittävä testaus Tarvittavan testauksen määrää on vaikea arvioida etukäteen Voidaan jatkaa ”kunnes rahat loppuvat” Varsinkin massatuotteissa tehdään kompromissi, jotta saadaan tuote ajoissa markkinoille Voidaan päättää testauksen lopettamisesta, kun virhekäyrä tasaantuu