Testaus osana ohjelmistojen elinkaarta Luento 2 Antti-Pekka Tuovinen www.cs.helsinki.fi 19 March 2018 1
Oppimistavoitteet Ohjelmistokehityksen V-malli Testauksen tasot (test level) Inkrementaalinen (ketterä) kehitys ja testaus Testityyppejä (test type) testauksen kohteena olevien ominaisuuksien ja tarkoituksen mukaan jaoteltuna www.cs.helsinki.fi 19 March 2018 2
Ohjelmistokehityksen V-malli www.cs.helsinki.fi 19 March 2018 3
Ohjelmistokehitysprosessit www.cs.helsinki.fi 19 March 2018 4
Ohjelmistokehityksen V-malli Andreas Spillner, Tilo Linz, Hans Schaefer: Software testing foundations - a study guide for the certified tester exam : foundation level, ISTQB compliant, 4th Edition. Santa Barbara, CA : Rocky Nook, Inc., 2014. www.cs.helsinki.fi 19 March 2018 5
Ohjelmistokehityksen V-malli Nostaa testauksen muitten kehitysaktiviteettien rinnalle tärkeydessä Korostaa testauksen suunnitelmallisuutta V:n vasen haara edustaa ohjelmiston ja sen osien kehitysprosessia ja oikea haara integrointia ja testauksen suoritusta Malli tunnistaa ohjelmiston eri rakennetasot, jotka vaativat omanlaisensa testauksen Tavoitteet, tekniikat, osaaminen Testauksen suunnittelu ja valmistelu etenee rinnan vastaavan kehitystason työn aikana www.cs.helsinki.fi 19 March 2018 6
V-mallin Veet Validointi soveltuuko ohjelma ajateltuun käyttöönsä? Verifiointi onko ohjelman osa toteutettu määrittelynsä mukaisesti? Validoinnin rooli korostuu V-mallin ylemmillä testaustasoilla www.cs.helsinki.fi 19 March 2018 7
Testaustasot Test level www.cs.helsinki.fi 19 March 2018 8
Testaustasot - Komponenttitestaus A.k.a Yksikkötestaus Ohjelman pienimpien toiminnallisten rakenneosien testausta Luokka, moduuli, funktio, skripti, www.cs.helsinki.fi 19 March 2018 9
Komponenttitestauksen lähtökohdat Komponentit testataan yksitellen ja erillään muista komponenteista Löydetyt häiriöt johtuvat testattavassa komponentissa olevista vioista Testataan komponentin sisäistä toimintaa ja käyttäytymistä White-box testauksen rooli korostuu www.cs.helsinki.fi 19 March 2018 10
Komponenttitestauksen ympäristö Testaus täytyy tehdä läheisessä yhteistyössä kehittäjien kanssa - usein kehittäjät tekevät yksikkötestauksen itse Tarvitaan testiajuri (test driver), joka Alustaa testitapausten suorituksen Kutsuu komponentin palveluja/toimintoja Vastaanottaa kutsujen tuottamat tulokset ja vertaa niitä odotettuihin arvoihin Kirjaa testien suorituksen ja tulokset (pass/fail) www.cs.helsinki.fi 19 March 2018 11
Komponenttitestauksen ympäristö Yksikkötestauskehikot (test framework, test fixture) testiajurien toteuttamiseen xunit arkkitehtuuri JUnit Javalle (www.junit.org) Esimerkki JUnit:n käytöstä Eclipse kehitystyökalussa: https://www.youtube.com/watch?v=i8xxfgf9gs c www.cs.helsinki.fi 19 March 2018 12
Komponenttitestauksen yleiset tavoitteet Toiminnallisuuden verifiointi Varmistetaan oikea toiminta valituilla testitapauksilla eli syöte/tulos kombinaatioilla Vikasietoisuuden (robustness) testaus Testataan toimintaa virheellisillä (ja määrittelemättömillä) syötteillä Testataan toimintaa muissa poikkeustilanteissa Engl. negative tests www.cs.helsinki.fi 19 March 2018 13
Komponenttitestauksen erityiset tavoitteet muut laatupiirteet Nämä ovat esimerkkejä komponenttikohtaisista testeistä (vaihtelevat komponenteittain) Tehokkuus Laskentaresurssien käyttö, suoritusnopeus Vain kriittisille komponenteille (sulautetut ohjelmistot, tiukat aikavaatimukset) Ylläpidettävyys Käytetään staattista analyysiä (työkaluja, katselmointia), ei ohjelman suorittamista (dyn. testausta) Koodin rakenne, modulaarisuus, kommentointi, koodauskonventioiden noudattaminen, ymmärrettävyys jne. www.cs.helsinki.fi 19 March 2018 14
Komponenttitestauksen strategia Testitapausten suunnittelu on yleensä komponentin ohjelmoijan tehtävät Hänellä on tarvittava tieto toteutuksen yksityiskohdista White-box suunnittelumenetelmien pääasiallinen käyttökohde Tavoitteena usein saavuttaa riittävä kooditason kattavuus testitapauksilla (tähän palataan myöhemmin) Käytännössä testien suunnittelussa käytetään usein black-box menetelmiä (koska white-box menetelmiä voi olla vaikea käyttää oikein?) www.cs.helsinki.fi 19 March 2018 15
Komponenttitestauksen strategia Testilähtöinen kehitys Test Driven Development (TDD) Suosittu iteratiivisessa ja ketterässä kehityksessä Koodattavan moduulin/luokan yksikkötestit kirjoitetaan ensin Aluksi testi epäonnistuu, koska implementaatiota ei vielä ole Koodausta jatketaan, ja kun kaikki testit lopulta menevät läpi, implementaatio on valmis Testit automatisoidaan ja ne ajetaan koodin muuttuessa www.cs.helsinki.fi 19 March 2018 16
Testaustasot - Integrointitestaus Integrointi = komponenttien/yksiköiden koostaminen suuremmiksi rakenneyksiköiksi (alijärjestelmiksi) Integroitavat komponentit on jo testattu Tavoitteena on löytää vikoja yhdistettyjen komponenttien Rajapinnoista (interface) Vuorovaikutuksesta (interaction) www.cs.helsinki.fi 19 March 2018 17
Testaustasot - Integrointitestaus Eri tiimien toteuttamien komponenttien vuorovaikutus/yhteistoiminta on altis puutteellisen määrittelyn, väärinymmärrysten ja heikon kommunikaation aiheuttamille vioille Eri tahtiin etenevä kehitystyö asettaa haasteensa komponenttien yhteistoiminnan toteutttamiselle Erityisen hankalia ovat tapaukset, joissa vieraat komponentit käyttävät sisäisiksi (ei-julkiksi) tarkoitettuja rajapintoja (tai muita elementtejä), jotka voivat muuttua odottamatta www.cs.helsinki.fi 19 March 2018 18
Integrointitestauksen lähtökohdat Testitapausten pohjana käytetään arkkitehtuurisuunnittelua Arkkitehtuuri / järjestelmäarkkitehtuuri Käyttötapaukset Työnkulkujen kuvaukset (workflow) Valmisohjelmistojen/komponenttien (COTS) vuorovaikutus itse kehitettyjen komponenttien kanssa kuuluu integraatiotestauksen piiriin www.cs.helsinki.fi 19 March 2018 19
Integrointitestauksen ympäristö Pyritään käyttämään hyväksi komponenttitestauksen testiajureita Komponentit tarjoavat palvelunsa rajapintojen kautta, joita komponenttitestauksenkin ajurit käyttävät Integroitujen komponenttien yhteistoiminnan seurantaa varten tarvitaan monitoreita (monitor) Komponenttien välisen dataliikenteen ym. lukeminen ja kirjaaminen lokiin www.cs.helsinki.fi 19 March 2018 20
Integrointitestauksen tavoitteet Integroitavien komponenttien yhteistoiminnan vikojen ja ristiriitojen löytäminen Käännösaikaiset (staattiset) rajapintamäärittelyjen ristiriidat löytyvät usein koostamisen (build) aikana Dynaamiset ohjelmointikielet vaativat testausta staattisesti tyypitettyjä enemmän Suoritusaikaiset (protokolla-) viat löytyvät vain testaamalla www.cs.helsinki.fi 19 March 2018 21
Integrointitestauksen tavoitteet Tyypillisiä kommunikaatioon liittyviä vikoja Syntaktisesti vääränmuotoisen datan lähettäminen tai datan lähettämättä jättäminen aiheuttaa poikkeuksen vastaanottavassa komponentissa Datan välitys toimii, mutta komponentit tulkitsevat datan merkityksen eri tavoin Tiedonsiirrossa on ajoitusongelmia Väärään aikaan, liian myöhään, liian tiheään www.cs.helsinki.fi 19 March 2018 22
Integrointitestauksen tavoitteet K: Voisiko komponenttitestauksen jättää pois, ja ajaa kaikki testit vasta integroinnin jälkeen? V: Ei ole järkevää Häiriön aiheuttavan vian paikallistaminen hankalaa, kun on monta osallistuvaa komponenttia Yksittäisten komponenttien toimintaa on vaikea tai mahdotonta ohjata ja valvoa Integrointitestausympäristössä voi olla vaikeaa saada aikaan tilannetta, joka laukaisee tietyn poikkeustilanteen käsittelyn komponentissa www.cs.helsinki.fi 19 March 2018 23
Integrointistrategioista Komponentit valmistuvat usein eri tahtiin, jolloin voi olla vaikea etukäteen tietää, milloin integraatiotestausta päästään tekemään Testauspäällikön (test manager) on tehtävä integrointitestausta varten suunnitelma, joka ottaa huomioon ohjelmiston testausstrategian, arkkitehtuurin ja projektisuunnitelman Parhaassa tapauksessa testaustarpeet otetaan jo huomioon projektisuunnitelmassa ja komponenttien implementointijärjestyksessä www.cs.helsinki.fi 19 March 2018 24
Yleisiä integrointistrategioita Top-down Bottom-up Ad hoc Backbone / skeleton ja tietysti viimeiseen asti vältettävä, eiinkrementaalinen Big Bang Lähinnä seurausta integrointistrategian puuttumisesta! www.cs.helsinki.fi 19 March 2018 25
Testaustasot Järjestelmätestaus Tuo mukaan asiakkaan ja käyttäjän näkökulman teknisten vaatimusten rinnalle Ohjelmiston tarjoamia palveluja koetellaan todellisessa käytössä Monien toimintojen suorittaminen ja järjestelmän piirteiden havainnointi vaativat kaikkien komponenttien yhteistoimintaa Niitä voidaan testata vain järjestelmätasolla www.cs.helsinki.fi 19 March 2018 26
Järjestelmätestauksen lähtökohdat Järjestelmä- ja ohjelmistovaatimukset, määrittelyt, käyttöoppaat, asennusohjeet, ylläpito-ohjeet jne. Testit suoritetaan mahdollisimman samanlaisessa laitteisto- ja ohjelmistoympäristössä kuin lopullinen käyttöympäristö Ohjelmiston eri konfiguraatiot ja suorituskyky eri tilanteissa on myös testattava www.cs.helsinki.fi 19 March 2018 27
Järjestelmätestauksen lähtökohdat Datan laatu on entistä tärkeämpää nykyisissä ohjelmistoissa Järjestelmän käyttämän datan eheys, täydellisyys ja ajantasaisuus on varmistettava! www.cs.helsinki.fi 19 March 2018 28
Järjestelmätestauksen lähtökohdat Järjestelmätestaus on syytä tehdä erillisessä testausympäristössä ei asiakkaan tuotantoympäristössä Vältetään testattavan ohjelmiston vioista tuotantoympäristöön aiheutuvat vahingot Testausolosuhteita (test condition) voi olla vaikeaa hallita tuotantoympäristössä Testien toistettavuus on parempi www.cs.helsinki.fi 19 March 2018 29
Järjestelmätestauksen tavoitteet Vaatimusten väärästä, epätäydellisestä tai epäyhtenäisestä implementoinnista johtuvien vikojen löytäminen Puuttuvien tai unohdettujen vaatimusten huomaaminen ja tunnistaminen www.cs.helsinki.fi 19 March 2018 30
Järjestelmätestauksen ongelmia Jos vaatimuksia ei ole kirjattu ylös, järjestelmätestien suunnittelijoiden vaikeana tehtävänä on haalia tarvittava informaatio hajallaan olevista lähteistä Tässä tilanteessa paljastuu yleensä myös erilaisia tulkintoja samoista vaatimuksista, jolloin testaajien täytyy ottaa aloite yhteisen näkemyksen muodostamiseksi (testitapausten tuottamiseksi) Näissä olosuhteissa voi olla parasta turvautua tutkivaan testaukseen (exploratory testing) Käsitellään myöhemmin kurssilla www.cs.helsinki.fi 19 March 2018 31
Testaustasot - Hyväksyntätestaus Edellä kuvatut testit tekee ohjelmiston toimittaja Ennen ohjelmiston ottamista käyttöön asiakkaankin on osallistuttava validointiin Asiakkaan/käyttäjän näkökulma ja evaluointi Erityisen tärkeää räätälöidyille ohjelmistoille Vakiintuneen valmisohjelmiston (COTS) hankinnan yhteydessä tehtävät hyväksyntätestaus voi olla kevyempi www.cs.helsinki.fi 19 March 2018 32
Hyväksyntätestauksen lähtökohdat Mikä tahansa järjestelmää käyttäjän/asiakkaan näkökulmasta kuvaava dokumentaatio Käyttötapaukset, liiketoimintaprosessit, lait ja säännökset, tietohallinnon ja ylläpidon säännöt ja prosessit www.cs.helsinki.fi 19 March 2018 33
Hyväksyntätestauksen lähtökohdat Hyväksyntätestejä voidaan tehdä osana muittenkin tasojen testausta Valmisohjelmistojen käyttöä voidaan testata jo integroinnin aikana Käyttöliittymään liittyvien komponenttien käytettävyyttä voidaan testata komponenttitestauksen yhteydessä Prototyyppejä voidaan käyttää uuden toiminnallisuuden testaamiseen jo ennen järjestelmätestausta Asiakkaan ja käyttäjän näkökulman saaminen mukaan projektin alkuvaiheessa on tavoiteltava asia Ketterien menetelmien yksi kulmakivi www.cs.helsinki.fi 19 March 2018 34
Hyväksyntätestauksen muodot 1. Sopimukseen kirjattujen hyväksymisehtojen täyttymisen testaus 2. Loppukäyttäjän hyväksyntätestaus 3. Tuotannon/operoinnin hyväksyntätestaus 4. Kenttätestaus www.cs.helsinki.fi 19 March 2018 35
Hyväksymisehtojen testaus Asiakas varmistaa, että ohjelmistossa ei ole (merkittäviä) puutteita ja että ohjelmisto muuten on tilaussopimuksen mukainen Toimittajan ja asiakkaan välisessä sopimuksessa on usein kirjattu erikseen hyväksymisehdot (acceptance criteria) Toimittajan pitäisi olla testannut ehtojen täyttyminen jo omissa järjestelmätesteissään Yleensä riittää hyväksynnän kannalta riittävien testien toistaminen yhdessä asiakkaan kanssa www.cs.helsinki.fi 19 March 2018 36
Hyväksymisehtojen testaus On tärkeää, että asiakas on itse määritellyt hyväksymistestauksen testitapaukset tai ainakin ne huolellisesti katselmoinut Toisin kuin järjestelmätestaus, hyväksyntätestaus tehdään nyt asiakkaan (tuotanto-)ympäristössä Myös ohjelmiston jakelu ja asennus testataan asiakkaan ympäristössä www.cs.helsinki.fi 19 March 2018 37
Loppukäyttäjän hyväksyntätestaus Asiakas ja loppukäyttäjät voivat olla eri henkilöitä Eri käyttäjäryhmillä on erilaisia tarpeita ja odotuksia Ohjelmistoa päivittäin työssään käyttävät Satunnaiset käyttäjät Ylläpidon ja tuotannon työntekijät, jotka vastaavat ohjelmiston saatavuudesta Johto, jolla on omia seuranta- ja raportointitarpeitaan Asiakkaan tehtävänä on usein valita testitapaukset kullekin käyttäjäryhmälle www.cs.helsinki.fi 19 March 2018 38
Loppukäyttäjän hyväksyntätestaus Tässä vaiheessa havaittujen merkittävien ongelmien ja vikojen korjaaminen voi olla hyvin kallista Siksi on syytä esimerkiksi prototyyppien ja käytettävyystestien kautta varmistua jo projektin aikaisessa vaiheessa, että kehitettävä ohjelmisto tulee täyttämään käyttäjäryhmien tarpeet Yleisimpien käyttäjän tehtävien pitää onnistua helposti ja intuitiivisesti; harvemmin tarvittavien toimintojen käyttämiseen voidaan edellyttää käyttöoppaiden lukemista www.cs.helsinki.fi 19 March 2018 39
Tuotannon/operoinnin hyväksyntätestaus Validoidaan ohjelmiston ominaisuudet ylläpidon (system administration) näkökulmasta Varmistukset Toipuminen vakavista häiriöistä (disaster recovery) Käyttäjien hallinta Turvaominaisuudet Jne. www.cs.helsinki.fi 19 March 2018 40
Kenttätestaus Ohjelmistoa voidaan käyttää hyvin monenlaisissa ympäristöissä Kenttätesteillä (field test) tavoitteena on tunnistaa eri käyttöympäristöjen mukanaan tuomat vaikutukset, joita on vaikea ennakoida Tärkeää erityisesti COTS ohjelmille Valituille käyttäjille toimitetaan esiversioita ohjelmistosta, jotka antavat siitä palautetta toimittajalle Alpha-, Beta-testaus www.cs.helsinki.fi 19 March 2018 41
Inkrementaalinen ohjelmistokehitys www.cs.helsinki.fi 19 March 2018 42
Inkrementaalinen ohjelmistokehitys Inkrementaalisen kehityksen idea on tuottaa ohjelmisto sarjana pienempiä peräkkäisiä kehitysaskeleita sen sijaan, että ohjelmisto rakennetaan kerralla valmiiksi Jokainen kehitysaskel eli inkrementti lisää uutta toiminnallisuutta järjestelmään kasvattaen ohjelmistoa siivu siivulta Asiakkaalta mahdollista saada nopeasti palautetta, jonka perusteella voidaan tehdä muutoksia ja korjauksia ketterästi Ohjelmistolla on varhaisesta vaiheesta lähtien jonkinlainen perusrunko tai luuranko (skeleton), johon inkrementtien tuotokset integroidaan www.cs.helsinki.fi 19 March 2018 43
Inkrementaalinen ohjelmistokehitys by Man vyi wikimedia.org www.cs.helsinki.fi 19 March 2018 44
Inkrementaalinen ohjelmistokehitys Inkrementaalinen kehitysprosessi tekee mahdolliseksi asiakkaan osallistumisen jo varhaisessa vaiheessa toimintojen testaukseen Hyväksyntätestausta ja käytettävyystestausta voidaan tehdä koko kehitysprojektin ajan Kunkin iteraation (sprintin) alussa sovitaan toteutettavat piirteet (käyttäjätarinat) ja hyväksyntätestit, joilla toteutuksen toimivuus verifioidaan Asiakkaan osallistuminen testien suunnitteluun on tärkeää validointinäkökulman kannalta www.cs.helsinki.fi 19 March 2018 45
Inkrementaalinen ohjelmistokehitys Muukin testaus on mukautettava jatkuvaan muutokseen Yksikkötestien läpimeno edellytys koodin viennille versionhallintaan Jatkuva integrointitestaus (frequent integration, continuous integration) Jatkuva regressiotestaus Testitapausten uudelleenkäytettävyys inkrementistä toiseen tärkeää (vaatii myös testien ylläpitoa) www.cs.helsinki.fi 19 March 2018 46
Inkrementtien testaus 1. julkaisu 2. julkaisu 3. julkaisu www.cs.helsinki.fi 19 March 2018 47
Ketterä testaaja ISTQB:n oppisisältö ketterän testaajan koetta varten: http://www.istqb.org/downloads/syllabi/agile-testerextension-syllabus.html www.cs.helsinki.fi 19 March 2018 48
Ketterä testaaja Test automation pyramid https://martinfowler.com/bliki/testpyramid.html www.cs.helsinki.fi 19 March 2018 49
Agile Testing Quadrants Crispin, L., Gregory, J.: Agile Testing - A Practical Guide for Testers and Agile Teams. Addison-Wesley, 2009. Figure 6-1 www.cs.helsinki.fi 19 March 2018 50
Testityyppejä Test types www.cs.helsinki.fi 19 March 2018 51
Testityyppejä On olemassa perustestityyppejä, joita voidaan käyttää useilla eri testaustasoilla Testin kohteena oleva ohjelmiston ominaisuus on testityypin määrittävä tekijä ei kehitysprojektin vaihe tai rakennetaso www.cs.helsinki.fi 19 March 2018 52
Toiminnallinen testaus (functional testing) Toiminnallinen testaus verifioi ohjelmiston tuottamat tulokset ja käyttäytymisen ohjelmiston syötteillä (input-output behavior) Ohjelmistoa tarkastellaan mustana laatikkona (black box) eli tarkastellaan vain sen ulkoisesti havaittavaa käyttäytymistä, ei sen sisäistä tilaa Testien lähtökohtana ovat ohjelmiston toiminnalliset vaatimukset, jotka määritelevät mitä ohjelmisto tekee Tämä testaustyyppi sopii parhaiten järjestelmäja hyväksyntätestaukseen www.cs.helsinki.fi 19 March 2018 53
Kirjattuihin vaatimuksiin perustuva t:nen testaus Jos toimintoja koskevat vaatimukset on kirjattu ylös, testitapaukset suunnitellaan niiden perusteella Jokaista vaatimusta kohden tehdään vähintään yksi testitapaus Usein vaatimukseen sisältyy (eksplisiittisesti tai implisiittisesti) useita mahdollisia tapoja tehdä vaadittu asia (ja poikkeustilanteita), joten testitapauksia tarvitaan yleensä useita www.cs.helsinki.fi 19 March 2018 54
Kirjattuihin vaatimuksiin perustuva t:nen testaus Toiminnallisista vaatimuksista johdetaan usein käyttötapauksia (use case), jotka toimivat käyttöliittymä- ja myös ohjelmistosuunnittelun lähtökohtina Käyttötapaus kuvaa täydellisen vuorovaikutusjakson (skenaarion) ohjelmiston ja ulkoisen aktorin välillä siten, että jokin aktorin tavoite (syy ohjelmiston käytölle) tulee täytetyksi skenaarion aikana Käyttötapaukset ovat hyvä pohja testitapausten suunnittelulle www.cs.helsinki.fi 19 March 2018 55
Liiketoimintaprosesseihin perustuva t:nen testaus Yksittäisiä käyttötapauksia laajempia kuvauksia ovat liiketoimintaprosessien (business process) ja -tapahtumien kuvaukset Liiketoimintatapahtuma kokoaa yhteen useita käyttötapauksia loogiseksi toimintojen ketjuksi, joka täyttää jonkin asiakkaan liiketoiminnan tavoitteen Tapahtuman testaus vaatii oman testiskenaarionsa www.cs.helsinki.fi 19 March 2018 56
Liiketoimintaprosesseihin perustuva t:nen testaus Esim auton myynti liiketoimintatapahtuma koostuu käyttötapauksista 1. autotarjonnan selaus, 2. auton ja lisävarusteiden valinta, 3. [ rahoitustarjouksen pyyntö ], 4. [ vakuutustarjouksen pyyntö ], 5. hankintasopimuksen teko ja tallennus 6. auton ja lisävarusteiden tilauksen toimitus maahantuojalle www.cs.helsinki.fi 19 March 2018 57
Laatuominaisuuksien testaus (non-functional testing) Laatuominaisuuksilla tarkoitetaan järjestelmän toimintaa tai sitä kokonaisuutena määrittäviä laatupiirteitä Laatumalli määrittelee joukon laatupiirteitä (characteristics, quality attributes) joiden suhteen laatua mitataan Esimerkiksi ISO/IEC 25010 laatumalli: Viisi laatupiirrettä käytön aikaisen laadun määrittelyyn Kahdeksan laatupiirrettä tuotelaadun määrittelyyn 15 laatupiirrettä datan laatua varten (ISO 25012) www.cs.helsinki.fi 19 March 2018 58
Konkreettisia testauskohteita Käytös kuormituksen (load test) alla Suorituskyky tärkeissä käyttötapauksissa ja kuorman alla Suurten datamäärien käsittely (volume test) Ylikuormitustilanteet (stress test) Turvauhkien käsittely ja torjunta (security) Vakaus ja luotettavuus jatkuvassa käytössä (stability) Käytös virhetilanteissa (robustness) Yhteensopivuus, datamuunnokset (compatibility) Eri laitteisto- ja ohjelmistokonfiguraatiot Käytettävyys Dokumentointi www.cs.helsinki.fi 19 March 2018 59
Laatuominaisuuksien testauksen haasteita Laatua koskevat vaatimukset ovat usein niin epämääräisesti muotoiltu, että konkreettisia testitapauksia ei voi määritellä Ohjelmiston pitää olla helppokäyttöinen Järjestelmän pitää olla nopea Myös laatuvaatimusten pitää olla ilmaistu testattavassa muodossa! www.cs.helsinki.fi 19 March 2018 60
Laatuominaisuuksien testitapaukset?? Valitaan toiminnallisista testeistä skenaario, joka edustaa poikkileikkausta koko järjestelmän toiminnasta (esim. käyttöliittymästä tietokantapalvelimeen asti) Testattavan ei-toiminnallisen ominaisuuden tulee olla havainnoitavissa ja mitattavissa skenaarion suorituksen aikana Jos mittauksen tulos on sallituissa rajoissa tavoitearvoon verrattuna, testin tulos on pass ja muuten fail www.cs.helsinki.fi 19 March 2018 61
Ohjelmiston rakenteen testaus Testitapausten suunnittelussa käytetään hyväksi tietoa ohjelmiston arkkitehtuurista ja sisäisistä tiloista (esim. mallien avulla) Tarkoitus on suunnitella ja ajaa riittävästi testitapauksia kaikkien rakenteiden testaamiseksi www.cs.helsinki.fi 19 March 2018 62
Ohjelmiston muutosten testaus ja regressiotestaus Uudelleentestaus (retesting) muutosten jälkeen Toistetaan aikaisemmat testit sen osoittamiseksi, että korjatut viat ovat todella hävinneet Regressiotestaus muutosten jälkeen Tarkoituksena on osoittaa, että muutokset eivät ole aiheuttaneet uusia vikoja (tai vanhojen vikojen uusiutumista) ohjelmistoon regressio: palautuminen, taantuminen, takautuminen. Kielitoimiston sanakirja www.cs.helsinki.fi 19 March 2018 63
Ohjelmiston muutosten testaus ja regressiotestaus Regressiotestaukseen valitut testitapaukset suoritetaan usein, joten ne on dokumentoitava hyvin Testit kannattaa mahdollisuuksien mukaan automatisoida www.cs.helsinki.fi 19 March 2018 64
Regressiotestauksen laajuus Tärkeää on päättää regressiotestauksen laajuus Suoritetaan uudestaan kaikki testit, jotka löysivät jonkin nyt korjatuista vioista Testataan kokonaan uudelleen kaikki ne ohjelman osta joita on nyt muutettu Testataan kaikki vastikään integroidut ohjelmiston osat Testataan uudelleen koko ohjelmisto www.cs.helsinki.fi 19 March 2018 65
Regressiotestauksen laajuus Ohjelmistomuutoksilla voi olla arvaamattomia sivuvaikutuksia myös niissä ohjelman osissa, joihin ei ole koskettu Osien välillä voi olla suuri määrä suoria ja epäsuoria riippuvuuksia niitä on helppo saada aikaan mutta työlästä poistaa Syynä usein huonosti suunniteltu tai muuten sopimaton arkkitehtuuri ja piittaamattomuus riippuvuuksia koskevista säännöistä Periaatteessa vain koko ohjelmiston täydellinen uudelleentestaus on riittävän laaja regression havaitsemiseen www.cs.helsinki.fi 19 March 2018 66
Regressiotestauksen laajuus Käytännössä koko ohjelmiston uudelleentestaus on kuitenkin liian kallista ja hidasta On siis valittava huomattavasti suppeampi joukko testitapauksia, joitten suoritus tuottaa riittävän varmuuden regression poissaolosta On yritettävä päätellä, mihin ohjelmiston osiin sivuvaikutuksia voisi tulla On muutenkin pyrittävä rajoittamaan ajettavien testitapausten määrä minimiin www.cs.helsinki.fi 19 March 2018 67
Regressiotestauksen laajuus Regressiotestitapausten valintakriteereitä Vain testisuunnitelman korkeimman prioriteetin testit ajetaan Toiminnallisten testien tietyt variantit voidaan jättää pois Rajoitetaan testaus vain tiettyihin tuotekonfiguraatioihin (vain yksi kieliversio ja yksi käyttöjärjestelmä) Testataan vain tietyt alijärjestelmät tai vain tietyt testitasot www.cs.helsinki.fi 19 March 2018 68