testauksen suunnittelu - helsinki

www.cs.helsinki.fi

Testauksen suunnittelu

30 April 2018Faculty of ScienceDepartment of Computer Science 21

www.cs.helsinki.fi 30 April 2018 22Faculty of ScienceDepartment of Computer Science


§ Testaus on (usein tärkein tai jopa ainoa)osa laadunvarmistusta (quality assurance)§ Testauksella saadaan analyyttistä, konkreettista

dataa ohjelmiston laadusta ja laadun kehittymisestäprojektin aikana

§ Testaussuunnitelma on osalaatusuunnitelmaa (QA plan)



§ Suunnitteluun sisältyy seuraavia toimia§ Testaussuunnitelman tekeminen§ Testien priorisointi§ Testin aloitus- ja lopetusehtojen määrittely§ Miljoonan taalan kysymys: milloin on testattu

tarpeeksi?


Testaussuunnitelma

§ IEEE 829-1998 –standardi antaa mallintestisuunnitelman sisällölle§ Kurssikirjassa liite A§ Standardi ISO/IEC/IEEE 29119 korvaa tämän§ Testauksen yleissuunnittelu

§ Testausstandardeja on kritisoitu paljonkaavamaisuudesta ja yleisestä raskaudesta§ Ne ovat toisaalta suosituksia, eivät pakollisia

käyttää


Testien priorisointi

§ Kävi projektin aikataulun ja rahoituksenkanssa miten kävi, testit on priorisoitavaniin, että tärkeimmät testit tulevat ainasuoritetuksi

§ Priorisointiperusteita§ Toimintojen odotettu käyttötiheys ja virheiden

todennäköisyys käytön aikana§ Vikariski = vian vakavuus x todennäköisyys§ Vikojen näkyvyys käyttäjälle



§ Priorisointiperusteita (jatkuu)§ Laatuvaatimusten painotukset ja tärkeys asiakkaalle§ Toiminnon/ominaisuuden arvo käyttäjälle ja/tai

liiketoiminnalle§ Implementaation kannalta kriittiset komponentit ja

toiminnot§ Ohjelman osien kompleksisuus§ Ohjelman osat, joihin liittyy suuri projektiriski

§ Epäselvät vaatimukset, alihankkijan kyky toimittaa,kehitysorganisaation kyvyt, uusien teknologioiden käyttö,käytettävien ulkoisten ohjelmistokomponenttien jaohjelmistokehysten laatu jne. jne.



§ Priorisointia on oltava valmis muuttamaanprojektin kuluessa§ Vioilla on tapana kasaantua§ Paljon vikoja sisältäneiden testikohteiden

testitapausten prioriteettia on syytä nostaa


Testien aloitus- ja lopetusehdot

§ Tiettyjen edellytysten on yleensä oltavavoimassa, ennen kuin testausta voidaanaloittaa§ Testausympäristö on olemassa ja valmiina käyttöön§ Testaustyökalut ovat käyttövalmiina

testausympäristössä§ Testin kohde on asennettu ja valmiina§ Testin tarvitsema data on saatavilla

§ Ehdot pitää kirjata testisuunnitelmaan


Testien aloitus- ja lopetusehdot

§ Testauksen lopetusehtojen eksplisiittinenmäärittely auttaa torjumaan seuraavia riskejä§ Ilman selkeitä kriteereitä testauksen lopettamisesta

päätetään epäjohdonmukaisin ja satunnaisinperustein

§ Vältetään liika testaaminen, joka johtuu siitä, etteitiedetä, mitä testauksella tavoitellaan


Yleisiä lopetuskriteereitä

§ Testikattavuus§ Kuinka monta testitapausta on suoritettu onnistuneesti,

kuinka monta vaatimusta on testattu, mikäkoodikattavuus on saavutettu

§ Tuotteen laatu§ Löydettyjen vikojen määrä, vikojen kriittisyys, vikojen

löytymistahti, luotettavuus jne.§ Jäännösriski§ Suorittamattomien testien määrä, korjaamattomat viat,

epätäydellinen kattavuus§ Taloudelliset rajoitteet§ Kulut, projektiriski, toimitusaikataulu, markkinatilanteen

muutokset

www.cs.helsinki.fi

Kustannukset,Testausstrategia,Testausaktivteetit



Testauksen kustannukset

§ Testaus voi viedä suuren osanohjelmistoprojektin budjetista (jopa ~50%)

§ Jotta testauksen käytetyt resurssit ja aikaosataan asettaa oikealle tasolle, onymmärrettävä mitä kustannuksia testauksessalöytymättä jääneet viat voivat aiheuttaa


Vikojen aiheuttamatkustannukset

§ Suorat kustannukset§ Asiakkaan liiketoimintaprosessille välittömästi

aiheutuvat kulut ja tappiot virhetoiminnoista(taloudelliset tappiot ja suoranaiset vahingot laitteilleja henkilöstölle); menetetty liikevaihto

§ Uusien, korjattujen ohjelmistoversioidenasennuksesta, käyttöönotosta jauudelleenkoulutuksesta aiheutuvat menot


Vikojen aiheuttamatkustannukset

§ Epäsuorat kustannukset (asiakkaannäkökulmasta)§ Ohjelmiston toimittajalle aiheutuvat suorat kulut

(sopimussakot, hinnan alennukset, käyttäjätuenkysynnän kasvu)

§ Vahingot liiketoiminnalle; asiakkaiden ja maineenmenetys, oikeudelliset kulut ja seuraamukset

§ Vikojen korjaamisen kustannukset§ Toimittajan tekemän lisätyön hinta (vikojen jäljitys ja

korjaus, testaus, uusien versioiden jakelu ja asennus)§ Resurssien (usein parhaiden) sitoutuminen

korjaustyöhön uuden kehittämisen sijaan


Testauksen kulut

§ Moni tekijä vaikuttaa testauksen hintaan§ Kehitysprosessin kypsyys (organisaation vakaus,

tekemisen ennustettavuus)§ Ohjelmiston laatu ja testattavuus§ Testausinfrastruktuuri§ Henkilöstön osaaminen§ Laatuvaatimukset§ Testausstrategia§ Testauspäällikkö ei juuri voi vaikuttaa kuin

testausstrategiaan ja jossain määrininfrastruktuuriin ja henkilövalintoihin


Testauksen työmäärän jakustannusten arviointi

§ Kustannuksia voi yleisesti arvioida kahdellatavalla§ Jakamalla koko testaustyö erillisiin tehtäviin ja

pyytämällä tehtävien vastuuhenkilöitä ja/taiasiantuntijoita arvioimaan työmäärää ja muitakustannuksia

§ Käyttämällä aiemmista projekteista kertynyttä dataatyömääristä ja kuluista arvioinnin pohjana

§ Jälkimmäinen tapa tuottaa yleensä parempiaarvioita, koska testauksen vaatima työmääräyleensä aliarvioidaan!


Testausstrategia ja kustannukset

§ Testausstrategian tavoitteena on§ Optimoida testauksen kustannukset suhteessa

löytymättömien virheiden aiheuttamiin kustannuksiin§ Minimoida riskit

§ Käytännössä laskelmien tekeminen voi ollavaikeaa puuttuvan kokemusperäisen datantakia

§ Strategiapäätökset tehdään usein pikemminkinintuition kuin rationaalisen tiedon varassa


Testausstrategia

§ Ennaltaehkäisevä vs. reaktiivinen§ Ennaltaehkäisevässä lähestymistavassa testaajat ovat

mukana projektin alusta alkaen, jolloin testauksensuunnittelussa voidaan antaa riittävästi painoaaikaisessa vaiheissa tehtäville katselmoinneille jaanalyyseille

§ Reaktiivisessa toimintatavassa testauksen suunnittelutulee mukaan vasta ohjelman toteutuksen ollessa jopitkällä; tässä tapauksessa tutkiva testaus voi olla parasja ainoa toimiva strategia

§ Ennaltaehkäisevä toiminta on kuitenkinkustannustehokkainta koko ohjelmiston elinkaartaajatellen


Testausstrategia

§ Analyyttinen vs. heuristinen menetelmä§ Analyyttinen testauksen suunnittelu yrittää kvantifoida

kustannukset ja kulut sekä niiden väliset riippuvuudetja tuottaa optimoidun strategian laskelmien avulla

§ Heuristinen suunnittelu nojaa asiantuntijoidenkokemukseen ja peukalosääntöihin

§ Käytännössä ollaan jossain näiden ääripäidenvälillä ja mukana on muitakin elementtejä§ Malliperustainen testaus, tilastolliset mallit,

riskianalyysit, standardit, uudelleenkäyttö,tarkistuslistat, asiantuntijoiden takapuolituntuma


Testausaktiviteetit,Vikaraporttien käsittely

§ Kurssikirja luvut 6.5 – 6.8.§ Kuuluu koealueeseen

www.cs.helsinki.fi

Testauspäällikön rooliketterässä kehityksessä



Ketterä kehitys ja testaus

§ Ei kurssikirjassa§ Video: Agile Test Management by Fran O’Hara§ http://www.youtube.com/watch?v=4WngZa3efaU



§ Siirtymä ketterään reaktiivisessa moodissa – oleproaktiivinen

§ Kaksi roolia§ Linjaesimies – rekrytointi, sopivuus ketteriin

kehitystiimeihin, valmennus§ Testauksen johtaminen projekteissa

§ Testaus tapahtuu projekteissa, ei erillisessä siilossa§ Testausstrategian muodostamisessa pitäisi pyrkiä

ennaltaehkäisevään strategiaan§ Automatisointistrategia, automaation rooli (mitkä tasot)



§ Älä ole liian määräävä testausprosessinmäärittelyssä projektille; tarjoa neuvoja ja tukea jaohjeita ja katso että tehdään järkeviä valintoja

§ ”Definition of done” määrittely avainasemassa –riskit, testaus

§ Testaajat ovat mukana projekteissa alusta alkaen,mikä korostaa testauksen merkitystä ja testaajienroolia

§ Laatuvaatimusten testauksen haasteet – mitensaadaan mukaan näitten testaus heti alusta alkaeneikä vasta projektin lopussa§ Profilointi ym.



§ Esteiden poistaminen testauksen tieltä§ Testaajat voivat opettaa kehittäjiä laatimaan

parempia testejä

www.cs.helsinki.fi

Testaustyökalut


www.cs.helsinki.fi

§ Työkalujen käytön tavoitteet§ Käsin tehtävän, samanlaisena mekaanisesti toistuvan

ja/tai aikaa vievän työn automatisointi (ihmiset ovathuonoja automaatteja)

§ Sellaisten testien tekeminen, joita on vaikeaa taimahdotonta tehdä manuaalisesti (rasitus- jasuorituskykytestit)

§ Inhimillisten virheiden riskin vähentäminen esimerkiksisuurten testi- ja tulosdatamäärien käsittelyssä

30 April 2018 47Faculty of ScienceDepartment of Computer Science

Työkalut ja testaus

www.cs.helsinki.fi

§ Testien suorituksen automatisointi,testidatan generointi, testitapaustengenerointi, testausprosessin hallinta, testinkohteen monitorointi, monikäyttötyökalut,jne.

§ Yleiskäyttöisiä ja hyvin erikoistuneita§ Kaupallisia ja avoimia§ Esimerkiksi OSS työkaluja löytyy osoitteesta

http://www.opensourcetesting.org/§ Muita http://www.imbus.de/english/test-tool-list/


Työkalutyyppejä

www.cs.helsinki.fi

§ Testitapausten määrittely, luokittelu,priorisointi ja muu hallinta

§ Testien suorituksen tilan seuranta§ Mahdollisesti linkitys vaatimushallintaan§ Vikaraporttien luonti- ja seurantatyökalut

ovat välttämättömiä (incident management,bug tracking)

§ Hallintatyökalujen integrointi muihin§ Testiraporttien ja –dokumenttien generointi


Testauksen hallintatyökalut

www.cs.helsinki.fi

§ Testia Tarantula –demohttps://www.youtube.com/watch?v=OiVTh2-R7w4


Testauksen hallintatyökalut

www.cs.helsinki.fi

§ Testitapauksen määrittelyyn kuuluvat esi- jajälkiehdot, syöte ja odotettu tulos

§ Testitapausten ja –datan generointityökaluthelpottavat testien laatijan työtä tuottamallatestisyötteitä tai kokonaisia testitapauksiaautomaattisesti


Testien määrittelytyökalut

www.cs.helsinki.fi

§ Tietokantarakenteen määrittely (data baseschema)§ Tuotetaan skeeman mukainen testitietokanta

§ Testikohteen koodi (white box)§ Testioraakkeli tarvitaan§ Pelkkä koodi (toteutus) on huono lähtökohta

testaukselle


Testitapausten generoinninperuste

www.cs.helsinki.fi

§ Testikohteen rajapinta (black box)§ Automaattinen ekvivalenssiluokkiin jako ja raja-arvo

analyysi rajapinnan määrittelyn perusteella (API, GUI)§ Negatiivisten testitapausten automaattinen generointi

(myös heuristiset säännöt)§ Testioraakkeli tarvitaan

§ Testikohteen (formaali) spesifikaatio§ Model based testing§ Testisyötteiden ja tulosten generointi UML mallin avulla§ Malli toimii oraakkelina


Testitapausten generoinninperuste

www.cs.helsinki.fi

§ AgitarOne: Junit –yksikkötestienautomaattinen generointi§ Yhdistää black-box ja white-box menetelmiä§ Kaupallinen työkalu§ http://www.agitar.com/solutions/products/agitarone.html

§ Menetelmän yksityiskohdat ja analyysialgoritmitliikesalaisuuksia, mutta tutkimustietoa aihepiiristälöytyy


Esimerkki

www.cs.helsinki.fi

§ Katselmoinnit§ Spesifikaatioiden ja mallien staattinen

analyysi§ Model checking§ UML-mallin täydellisyys ja ristiriidattomuus

§ Koodin staattinen analyysi§ Datavuoanomaliat, turvallisuusongelmat§ …ja kymmeniä muita, katso. esimerkiksi

http://findbugs.sourceforge.net/bugDescriptions.html


Staattisen testauksen työkalut

www.cs.helsinki.fi

§ Testien suorittamisen automatisointi§ Testitapaukset syötteineen ja odotettuine tuloksineen

koodataan testiskripteiksi tai –ohjelmiksi (JUnit -testitapausluokat)

§ Työkalu ajaa testit automaattisesti ja kirjaa tulokset(JUnit –laajennokset NetBeans ja Eclipse -ympäristöissä)

§ Debuggerit§ Kehittäjän työkaluja pääasiassa, mutta voivat olla

tarpeellisia tiettyjen virhetilanteiden luomiseksi


Dynaamisen testauksen työkalut

www.cs.helsinki.fi

§ Testikehikot ja –ajurit (test framework, testharness)§ Testiympäristön automaattinen generoiminen

testikohteen analysoinnin perusteella§ Tuki ajurien kirjoittamista varten§ Riippuvuuksien analysointi ja tynkien (stubs) tai

jäljittelijöiden (mock object) automaattinen (osittainen)generointi§ http://en.wikipedia.org/wiki/Mock_object

§ Google Test C++ testing frameworkhttp://code.google.com/p/googletest/wiki/Primer



www.cs.helsinki.fi

§ Simulaattorit, emulaattorit§ Testausrobotit (capture and replay)§ Käyttöliittymätapahtumien nauhoitus ja toisto

testitapausten määrittelyn avuksi§ Selenium on suosittu työkalu selaimessa toimivien

sovellusten testitapausten muodostamiseen jasuorittamiseenhttp://www.youtube.com/watch?v=OeyeY6gaDVg



www.cs.helsinki.fi

§ Datalähtöinen testaus (data driven testing)§ Periaatteessa sama testitapaus suoritetaan monta kertaa

peräkkäin vain syötteiden vaihtuessa§ Syötedata ja odotettu tulos talletetaan tiedostoon,

tietokantaan tai taulukkon, josta testiskripti lukee datarivitja ajaa testitapauksen

§ Komento- tai avainsanatestaus(command/keyword driven testing)§ Testitapaukset ja -skenaariot koostuvat abstrakteista

toiminnoista (”enter login credentials”) ja niiden syötteistä§ Testiä suoritettaessa abstrakti toiminto korvataan

konkreettisella testikohteen toiminteella/dialogilla



www.cs.helsinki.fi

§ Vertailijat (comparator)§ Suurien tietomassojen vertailuun (testin tuottama

tulosdata vs. oraakkelin tuottama data)

§ Dynaamiset analysaattorit testikohteensuorituksen aikana§ Muistin käyttö jne.

§ Kattavuusanalyysi testitapausten suorituksesta§ Lause- ja haarautumakattavuus jne.§ Työkaluissa paljon eroja§ Esimerkiksi EclEmma coverage plugin for Eclipse



www.cs.helsinki.fi

§ Kuormitustestaus, vasteajat§ Datan ja tapahtumien generointi

§ Määrä, frekvenssi

§ Monitorointi§ Testin aikaisen käyttäytymisen mittaaminen ja

mittausdatan kerääminen§ Profilointi§ Vaatii erikoistuneita ja joskus kalliita välineitä

§ Turvauhkien testaus§ http://www.metasploit.com


Suorituskyvyn testaus jamonitorointi

testauksen suunnittelu - helsinki

Documents