Ohjelmistotekniikka Mika Katara: Ohjelmistojen testaus, 2011 271 6.3 Virheiden kylväminen • Error seeding • Lisätään tietoisesti virheitä ohjelmakoodiin, jotta – Voidaan yrittää arvioida jäljellä olevien ”oikeiden” virheiden määrää testauksen avulla löytyneiden kylvettyjen virheiden määrästä – Arvioida testauksen tehokkuutta • Merkitään V o :lla oikeiden ja V k :lla kylvettyjen virheiden kokonaismäärää sekä V ol :lla ja V kl :lla löydettyjen oikeiden ja kylvettyjen virheiden määrää • Oletetaan lisäksi, että V o /V ol = V k /V kl • Jäljellä olevien virheiden määrän arvioksi saadaan (V ol x (V k /V kl )) - V ol Ohjelmistotekniikka Mika Katara: Ohjelmistojen testaus, 2011 272 • Kylvämisen ongelmia: – Minkälaisia virheitä pitäisi kylvää? – Onko kaikki kylvetyt virheet muistettu poistaa? – Paljonko menetelmästä aiheutuu ylimääräistä työtä? • Tekniikkaa voi harrastaa dokumenttien tarkastusmenettelyssä – Voidaan mitata sitä, kuinka hyvin tarkastajat ovat perehtyneet dokumenttiin – Vaatii paljon organisaatiolta
30
Embed
6.3 Virheiden kylväminen - TUNI › ~tie21201 › s2011 › luennot › OHJ-3060... · Jatkuva integrointi käytännössä • Perustuu artikkeliin Martin Fowler & Matthew Foemmel:
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
• C++-ohjelma, joka saa syötteenään toisen C++-ohjelman ja generoi siitä mutantin
• Mutanttiin kylvetyt virheet saa selville vertaamalla sitä alkuperäiseen ohjelmaan (Unix-ympäristössä esim. diff)
• Määrittelee mm. operaattoreiden ja tyyppien joukkoja, joiden alkioita voidaan vaihtaa keskenään– Esim. {+,*,/}: jos ohjelmassa esiintyy jokin joukon alkio,
vaihdetaan se joksikin muuksi alkioksi– Esim. {short, int, long}: vaihdetaan tyyppiä
• Mukailtu lähteestä [Kaner et al. 02]• Uudet asiat: uusimmat ominaisuudet voivat toimia väärin• Uudet tekniikat: uudet käsitteet johtavat uusiin virheisiin• Uudet markkinat: erilaiset käyttäjät käyttävät ohjelmaa eri
tavalla• Muutos: muutokset saattavat rikkoa aiemmin toimineen
koodin• Myöhäinen muutos: kiireiset päätökset ja kiireiset ihmiset
johtavat virheisiin• Kiireinen työ: kun projektille ei ole budjetoitu tarpeeksi aikaa,
• Oppimiskäyrä: huolimattomuusvirheitä • Huono suunnittelu tai vaikeasti ylläpidettävä järjestelmä:
joidenkin suunnittelupäätösten takia järjestelmä on niin huonosti ylläpidettävä, että vikojen korjaukset johtavat säännönmukaisesti uusiin vikoihin
• Väsyneet ohjelmoijat: usean viikon kestävät ylityöjaksot johtavat tehottomuuteen ja virheisiin
• Muut henkilöstöasiat: henkilökohtaiset ongelmat, perheongelmat, ongelmat työyhteisössä (jos kaksi ohjelmoijaa eivät puhu keskenään, tuskin puhuvat heidän koodinsakaan)
• Bugisuus: ominaisuudet, joissa on paljon tunnettuja bugeja voivat sisältää paljon myös tuntemattomia bugeja
• Riippuvuudet: häiriöt voivat aiheuttaa muita häiriöitä• Untestability: järjestelmää on vaikea (ellei mahdoton) testata • Vähäinen yksikkötestaus: ohjelmoijien tulisi löytää ja korjata
suurin osa omista virheistään• Aikaisempi keskittyminen kapeisiin testausstrategioihin:
regressio- ja funktiotestauksen jäljiltä voi ohjelmistoon jäädä suuri määrä virheitä, jotka pysyvät versiosta toiseen
• Heikot testaustyökalut: mikäli ei käytetä työkaluja esim. karanneiden osoittimien paikallistamiseen, näillä virheillä on hyvät mahdollisuudet jäädä huomaamatta
Ohjelmointikielille tyypillisiä virheitä: Java esimerkkejä
• Vanhemmassa koodissa luettelotyypin (enum) puuttuminen on johtanut puolivillaisiin kiertoteihin
• Epätietoisuus siitä, mitä class-tiedostoja ladataan (jar, CLASSPATH, piste CLASSPATH:ssa)
• Kaikki olioihin viittaavat muuttujat ovat oikeastaan implisiittisiä osoittimia:– munOlio a, b; // muuttujat alustetaan arvoon null– a = b; // osoittimien kopiointi– a = new munOlio(b); // uuden olion luonti
• Perinteiseen, vesiputousmallia noudattavaan ohjelmistoprosessiin testaus liitetään V-mallin mukaisesti– V-mallin vasen sivu kuvaa vesiputousmallia, jossa edetään
ylhäältä alas ensin vaatimusmäärittelystä toiminnalliseen määrittelyyn ja siitä arkkitehtuurisuunnitteluun ja lopulta moduulisuunnitteluun ja toteutukseen
• Jokaisessa vaiheessa laaditaan testaussuunnitelmat vastaaville testausvaiheille (oikea sivu)
• Kun testattavissa olevaa toteutusta alkaa olla olemassa, aletaan sitä testata – Edetään V-mallin oikeaa sivua alhaalta ylös toimien em.
• Monesti vaatimukset selviävät vasta matkan varrella– Kaikkea ei voi tietää projektin aluksi ja muutoksiin on pakko
varautua• Perinteinen tulkinta V-mallista ei kuitenkaan tue iteratiivista
kehitystä, jossa ohjelmasta tuotetaan väliversioita– Järjestelmä pyritään tekemään kerralla valmiiksi asti– Mallin vaiheet käydään uudestaan läpi vasta sitten kun tehdään
järjestelmän seuraavaa versiota• Malli myös tekee oletuksia siitä, mitä dokumentoidaan, mistä
dokumenteista tuotetaan eri tasojen testitapauksia ja missä vaiheessa tuotetut testit ajetaan
• Tapa ajatella, suunnitella, kommunikoida ja kirjoittaa koodia– Tavoite: yksinkertainen, selkeä ja toimintavarma ohjelmisto– Taustalla eXtreme Programming -ideat
• Sivuvaikutuksena syntyy kattava kokoelma automatisoituja yksikkö/integrointitason testejä
• Ei näin: • stressiä -> testataan vähemmän -> enemmän virheitä -> lisää
stressiä• Vaan näin:
• stressiä -> testataan -> vähemmän virheitä -> vähemmän stressiä
• Kysymyksiä– Kuinka isoja askelten pitää olla?– Mitä ei tarvitse testata?– Mistä tietää, ovatko testit hyviä?– Kuinka paljon testejä pitää olla?– Milloin testi pitäisi poistaa?– Miten ohjelmointikieli ja -ympäristö vaikuttavat?– Voiko isoja järjestelmiä tehdä testausohjatusti?– Miten TDD otetaan käyttöön kesken projektin?– Sulautettujen järjestelmien testaus?
• Mitä hyötyä jatkuvasta integroinnista on?• Oletetaan, että kaksi kehittäjää tekee kumpikin omaa
komponenttiansa, joiden olisi tarkoitus toimia toistensa kanssa yhteen– Kumpikin testaa oman koodinsa, eikä löydä siitä virheitä– Kun komponentit integroidaan, huomataan, etteivät ne toimi
yhteen kuten pitäisi– Mikäli käytössä on perinteinen prosessi, voi virheen löytäminen
olla todella hankalaa, jos koodi on kirjoitettu jo viikkoja aikaisemmin
– Jatkuvassa integroinnissa virhe on luultavasti tehty samana työpäivänä, tai edellisenä, jolloin sen löytäminen on paljon helpompaa, koska uutta koodia on vähän ja kehittäjä muistaa vielä mitä on tehnyt
• Ennen tehtävän aloittamista kehittäjät hakevat tuoreimmat tiedostot versionhallinnasta
• Uuden koodin voi integroida paikallisesti kun joko koko tehtävä tai osa siitä on tehty, kunhan vain yksikkötestit on saatu ajettua onnistuneesti
• Integroinnin aluksi otetaan jälleen versionhallinnasta uusimmat versiot muista tiedostoista
• Kun paikallinen buildi on tehty ja savutestit ajettu onnistuneesti, kehittäjä laittaa koodinsa versionhallintaan ja jää odottamaan master buildia– Kun master build on tehty onnistuneesti, voi siirtyä seuraavaan
tehtävään
Department of Software Systems
Ketterä hyväksyntätestaus: ATDD
• TDD:ssä matalan tason testit ajavat koodausta eteenpäin• ATDD:ssä korkean tason testit ajavat koko prosessia
eteenpäin• Kuinka “Definition of done” määritellään asiakkaan tai
käyttäjän näkökulmasta?• ATDD perustuu siihen, että määritellään suoritettavia korkean
tason testejä ennen kuin toteutusta on edes aloitettu• Ideaalitapauksessa testit tekee asiakas tai loppukäyttäjä• Kun testi läpäistään, on vastaava vaatimus ”Done”• ATDD-työkalut tarjoavat helpon tavan määritellä testejä
muodossa, jota asiakas ja loppukäyttäjäkin ymmärtävät
Mika Katara: Ohjelmistojen testaus, 2011 302
Department of Software Systems
ATDD-prosessi (iteratiivinen)muokattu, alkuperäinen Niklas Collin, Kilosoft
Mika Katara: Ohjelmistojen testaus, 2011 303
Project Manager
Customer/end-user
Test automation engineer
Chief engineer
Requirements
Executable tests (backlog)
Specify
Derived to
Implements
Department of Software Systems
• Edut– Vähemmän monikäsitteisyyksiä vaatimuksissa, koska asiakas tai
loppukäyttäjä on hyväksynyt testit– Kun testi menee läpi, voidaan siirtyä toteuttamaan seuraavaa
vaatimusta• Testit määrittelevät projektin laajuuden: jos läpäisemättömiä
testejä ei ole, ei ole mitään mitä implementoida (kuten asiakas tai loppukäyttäjä on asian hyväksynyt)
• Etenemisen läpinäkyvyys johdolle ja asiakkaalle• Kannattaa kuitenkin muistaa, että ATDD-työkalut eivät
välttämättä tue kaikki sovelluskohteita• …ja kaikki asiakkaan eivät ole valmiit toimimaan näin!
– Tutkivaa testausta voidaan valmistellaan esim. tilauksien (charter) avulla
• tilaus sisältää tiedon siitä mitä testataan, miksi, miten, minkä tyyppisiä ongelmia etsitään ja lisäksi tietoa riskeistä, suosituksia työkaluiksi jne.
– Normaalin testaussession kesto noin kaksi tuntia– Pääasiallisena tuloksena bugiraportit, mutta myös muuta
dokumentaatiota, muistiinpanoja jne. tarpeen mukaan– Session jälkeen raportointi sovitulla tavalla
Ohjelmistotekniikka
Ongelmia
• Kuinka – Tiedetään mitä testejä tehtiin?– Toistaa ne?– Varmistaa tilivelvollisuus?– Kouluttaa uusia tutkivia testaajia?– Yhdistää tutkiva testaus muun tyyliseen testaukseen?– Saada tarkkaa, luotettavaa ja tasapuolista tietoa
lähestymistavasta?– Allokoida työ tiimin sisällä niin, ettei tehdä turhaan samaa työtä?
Tässä kohdassa tutustutaan testiautomaatioon sekä testaamista helpottaviin työkaluihin. Työkalujen suuren määrän vuoksi tarkoituksena on antaa lähinnä yleiskuva, jonka avulla voi sitten helposti hankkia lisätietoja. Yksi työkalu sopii yhteen hommaan ja toinen toiseen.
• Alkupään kalvot perustuvat Mika Maunumaan kokoamaan materiaaliin
• Eri näkökulmat– Ohjelmistosuunnittelu kuvaa, miten asiat ovat– Testaus kysyy ovatko asiat oikeasti niin
• Testaus on perinteisesti ollut käsityötä• Testausautomaation kultainen lupaus on poistaa käsityö ja
ratkaista testausongelmat– Kun ohjelma testaa ohjelmaa, säästetään aikaa ja rahaa– Ohjelma jaksaa testata virheettömästi, nopeammin ja pidempään– Kaikkea ei voida testata käsin
• Testiautomaatio on manuaalisen testauksen täydentäjä, ei sen korvaaja– Testit on suunniteltava etukäteen– Automatisoidaan vain parhaat testit– Käsityön rooli muuttuu, mutta ei poistu
• Ohjelmisto, jonka tarkoitus on ”ajaa” toista ohjelmaa– Molemmat ovat syntyneet (osittain) samoista vaatimuksista– Näkökulmassa ja tavoitteissa on suuri ero
• Testaus ja testien automatisointi vaativat erilaisia taitoja• Testiautomaatio ei ole testauksen hopealuoti
• Regressiotestaus helpottuu, enemmän testejä useammin• Voidaan suorittaa manuaaliselle testaukselle mahdottomia
testejä– Esim. verkkosovellusten kuormitustestaus
• Testauksessa tehdyt virheet vähenevät, kone on ihmistä tarkempi– Toisaalta myös uudenlaiset virheet tulevat mahdollisiksi
• Resurssien tehokkaampi käyttö• Testien eheys ja toistettavuus• Testit voidaan suorittaa eri laite- tai ohjelmistoalustoilla• Testien uudelleenkäyttö testikohteen pysyessä samana• Luottamus toimivuuteen kasvaa, markkinoille pääsy nopeutuu
• Manuaaliset testit löytävät enemmän virheitä– Virhe löytyy yleensä ensin manuaalisella testillä, joka sitten
automatisoidaan regressiotestausta varten– James Bach raportoi kokemuksistaan Borlandilla: automaatio
löysi vain alle 20 % kaikista projektin aikana löydetyistä virheistä vaikka automaatioon oli satsattu jo useita vuosia (James Bach, Test Automation Snake Oil, 1999)
• Uudet ominaisuudet pitävät sisällään enemmän virheitä kuin vanhat
• Manuaalinen testaaja voi nopeasti löytää paljon virheitä samalla kun automaatiota vasta laajennetaan uusille alueille
• Käyttöliittymän läpi testattaessa tulee eteen kysymys siitä, mistä vertailuissa tarvittava data saadaan– Pahimmassa tapauksessa täytyy vertailla kuvaruudulta kaapattuja
bittikarttoja• yhden pikselin värin muuttuminen voi saada aikaa väärän
hälytyksen testiajossa– jos automaatio ei toivu virheistä, voi seurauksena voi olla paljon
hukattua aikaa– Tekstintunnistus (Optical Character Recognition, OCR) voi auttaa
tekstikenttien vertailussa• tekniikka on kuitenkin hidas ja virhealtis
– Parhaassa tapauksessa käytetään suoraan käyttöliittymäkirjaston resursseja
• ikkuna tuntee sen sisällä olevat tekstikentät, joiden arvot saadaan suoraan merkkijonoina
• yleensä Windows-maailman GUI-työkalut perustuvat tähän
• Aloitetaan yleensä suurin lupauksin– Työkalu ratkaisee testauksen ongelmat– Automatisoidut testit ovat halpoja– Kun käyttöliittymän läpi testaava automaatio vilistää ruudulla,
tulee helposti euforinen olo siitä, että tuotteen laatu paranee silmissä – jos ei ymmärrä mitä todellisuudessa tapahtuu
• Kaatuu monesti illuusion särkymiseen– Huonojen käytäntöjen automatisointi ei parantanut tilannetta
• automatisoitiin vääriä, huonoja tai virheellisiä testejä– Valittiin väärä tai epäyhteensopiva (ja kallis) työkalu– Ylläpitoon ei oltu varauduttu
• skriptien muuttaminen työlästä• testien riippuvuutta ohjelmistoversiosta ei huomioitu
– ”Automatisoidaan kaikki testit” yms. epärealistiset tavoitteet– Automatisoijat ovat usein kalliimpia kuin manuaaliset testaajat,
samalla rahalla olisi saavutettu paljon aikaan manuaalisessa testauksessa
– Automaatio ei toivu virheistä• Kannattaa aloittaa kevyesti
– Kannattaa kokeilla useampia eri työkaluja– Pilottiprojekti– Aloitetaan esim. savutestien automatisoinnista– Otetaan selvää, onko joku muu projekti/organisaatio käyttänyt
vastaavaa välinettä vastaavassa projektissa– Testausstrategia ja ihmisten sitoutuminen kuntoon
• automaatio ei vähennä testauksen suunnittelun tarvetta
• Erityisesti käyttöliittymän kautta testaavasta automaatiosta voidaan havaita eri sukupolvia– Helppokäyttöisyys, ylläpidettävyys ja kyky löytää virheitä
kehittyvät• Seuraavassa testiautomaatio jaetaan viiteen sukupolveen
– Nauhoita ja toista– Komentojonot– Dataohjattu– Avain- ja toimisanat (keywords, action words)– Mallipohjainen