Project group Tete Work-time Attendance Software. Henkilökohtainen SE harjoitus: loppuraportti

Transkriptio

1 Project group Tete Work-time Attendance Software Henkilökohtainen SE harjoitus: loppuraportti Staattiset menetelmät Jaakko Nyrölä

2 T Software project 2(8) Muutosloki Versio Pvm Tekijä Kuvaus Jaakko Nyrölä Eka versio Jaakko Nyrölä Päivitetty toisen kierroksen kokemukset Jaakko Nyrölä Päivitetty kolmannen kierroksen tulokset sekä muokattu etenemisraportista loppuraportti

3 T Software project (8) 1. Virheiden vakavuuden luokitus Virheille käytettiin viisiportaista luokitusta, joka perustuu Qstudion vaikutusmalliin. Mallin jokainen taso kuvastaa sitä, mihin ohjelmiston tekijään kyseisellä virheellä on vaikutusta. Level 1 Ohjelmiston valmistaja Level 2 Valmistustiimi Level Ohjelmistoprosessi Level 4 Ohjelmiston käyttäjä Level 5 Ohjelmiston vikatilanne Lisäksi jokainen virhetyyppi arvioidaan erikseen Bugzillan akselilla triviaali - blocker. 2. Arviointi I1-vaiheessa Staattisia menetelmiä käytettiin I1-vaiheessa suunnitelman mukaan eli suoritin yhden testiajon molemmilla menetelmillä juuri ennen järjelmätestausta. Tuloksena tuli runsaasti pieniä huomautuksia, jotka olivat lähes pelkästään koodauskonventiovirheitä. Näillä tarkoitan esimerkiksi puutteita javadoc:issa, liian monimutkaisia metodeja ja luokkia, *-muotojen käyttämistä importeissa (esim. import java.util.*) sekä merkkijonojen käyttämistä koodin seassa. Lisäksi FindBugs ilmoitti virheestä, jota se piti tietoturvan kannalta pienenä puutteena. Sama virhe oli tosin esiintynyt jo aiemmin Qstudiossa, mutta ilman yhtä suurta painotusta, mikä asettaa sen olennaisuudelle suuren kysymysmerkin. Menetelmästä ei vielä tässä vaiheessa voi sanoa kuitenkaan olleen kovin paljoa suoranaista hyötyä merkittävien virheiden puuttuessa. Koodauskonventio- ja selkeysvirheitä on hankalaa lähteä korjaamaan ennen kuin ryhmän kanssa on sovittu, mitkä niistä lasketaan olennaisiksi ja mitkä ei. Virheitä tulee nimittäin niin paljon, että niiden läpikäynti ja varsinkin korjaus kestäisi muuten liian pitkään. Menetelmien hyöty tässä vaiheessa oli siis menetelmien idean ja niistä saatujen tuloksien oppiminen käytännön kautta. Vain sen kautta pystytään seuraavissa vaiheissa saamaan niistä mahdollisesti oikeata hyötyä irti. Kaikki virheet ilmoitettiin Bugzillaan korjaamisen sijasta Metriikat tehdystä arvioinnista Taulukko 1. Ohjelmien havaitsemat virheet ensimmäisessä iteraatiossa Ohjelma Löydetyt virheet Virheiden luokitus Huomioon otetut virheet Kommentti

4 T Software project 4(8) Qstudio n FindBugs 6 6 Kaikki huomioon otetut virheet olivat samanlaisia, mutta vain eri lähdekooditiedostoissa. Kaikki virheet olivat samanlaisia, mutta vain eri lähdekooditiedostoissa. Taulukko 2. Huomioon otetut virheet ensimmäisessä iteraatiossa Ohjelma Vakavuus Kuvaus Qstudio Molemmat Javadoc puutteellista Action.logger ei ole mallia final (Eli käytetty loki ei ole final) Päätelmiä kerätyistä metriikoista ja heränneitä ajatuksia Jo tässä vaiheessa voidaan tehdä tilastojen perusteella pätevää analyysiä menetelmien ominaisuuksista. Ensinnäkin molemmista saadaan hyvin erilaisia tuloksia FindBugs:in keskittyessä virheiden hakuun ja Qstudin huomauttaessa virheistä koodauskonventiossa. Tämä puolestaan osoittaa näiden kahden menetelmän rinnakkaisen käytön olevan järkevää, jos siis menetelmät ovat itsessään järkeviä. Toiseksi voidaan sanoa, etteivät staattiset menetelmät korvaa millään tapaa muita testauksen osa-alueita, vaan tuovat niihin omat lisänsä. Qstudion avulla pystyy helposti tarkastamaan, onko koodi haluttujen Javan konventioiden mukaista ja niiden avulla pääsee eroon ainakin joistain tavoista, jotka aiheuttavat epäselvää koodia. FindBugs:in avulla voi automaattisesti tarkastaa, olisiko koodiin jäänyt mahdollisesti virheitä, joita ilmestyy tavallisesti Java-järjestelmissä. Nämä huomiot pätevät myös web-sovelluksiin, joissa käytetään runsaasti ulkopuolisia luokkia. Tällöin tosin tulee runsaasti (Qstudio) tai vähemmän runsaasti (FindBugs) ylimääräisiä virheilmoituksia, sillä ulkopuolisten luokkien rajapinnat ei välttämättä noudata konventioita. Ensimmäisessä vaiheessa kerättyjen tilastojen perusteelta ei voida kuitenkaan tehdä vielä pitkälle meneviä johtopäätöksiä menetelmien hyödyllisyyden suhteen, vaikka molemmat menetelmät vaikuttavat lupaavilta. Sen verran voi kuitenkin jo sanoa, että Qstudion tapauksessa hyöty saadaan irti vain rajaamalla etsittävät bugit tarkasti, sillä huomautuksia tuli yli 20 per kooditiedosto. Tämä tietenkin lisää muuten vaivattoman ja nopean asennuksen kustannuksia. FindBugs onkin asennuksen osalta huomattavasti helpompi ja siten siitä saatavien hyötyjen ei tarvitse olla niin merkittäviä. Kuitenkin molempien menetelmien kohdalla on sanottava, ettei niistä ollut ensimmäisen iteraation osalta vielä hyötyä projektille suhteessa kulutettuun aikaan. En nimittäin laskea kumpaakaan virheistä edes pieneksi, vaan ne ovat triviaaleja.

5 T Software project 5(8). Arviointi I2-vaiheessa Ennen I2-vaiheen testausta oli päätettävä mitä menetelmiä tässä sekä seuraavassa vaiheessa tullaan käyttämään. Päädyimme käyttämään loppujen lopuksi molempia menetelmiä, sillä asennuksien ollessa valmiita ei pelkästä käytöstä enää tulisi merkittäviä kustannuksia. Lisäksi ennen testausta päätimme, mitkä Qstudion tarkistimista koettiin hyödyllisiksi ja mitkä ei. Silti lähes kaikki Qstudion ilmoittamat bugit olivat turhia, vaikka niiden määrä luokkaa kohti laski puoleen viime iteraatioon nähden. Ongelmaksi muodostuivat runsaat määrät varoituksia asioista, jotka sinänsä ovat yleisellä mittakaavalla tärkeitä, mutta jotka eivät päteneet juuri kyseisessä kohdassa. Lisäksi emme millään osanneet karsia kaikki turhia tarkistuksia pois, koska niitäkin on loppujen lopuksi niin paljon. Kolmannen ongelman muodostivat luokkien/metodien kompleksisuutta erilaisilla mittareilla arvioineet tarkistimet. Päätin jättää ne loppujen lopuksi huomioimatta, sillä refaktorointi olisi joka tapauksessa projektin laajuuden ulkopuolella ja lisäksi ne tuntuivat antavan varoituksia lähes koko koodista. Vaikuttaakin siltä, ettei Qstudion tapauksessa sopivia säätöjä saa muuten kuin kokemuksen kautta ja tällöinkin ne ovat hyvin projektiriippuvaisia. FindBugs puolestaan teki tässä iteraatiossa tehtävänsä ja ilmoitti lähes pelkästään virheitä, jotka otettiin myös huomioon projektissa. Virheiden vakavuusaste oli tosin hyvin pientä. Myös tässä iteraatiossa kaikki bugit ilmoitettiin Bugzillaan korjaamisen sijasta..1. Metriikat tehdystä arvioinnista Taulukko 1. Ohjelmien havaitsemat virheet toisessa iteraatiossa Ohjelma Löydetyt virheet Virheiden luokitus Huomioon otetut virheet Kommentti Qstudio n FindBugs Kaksi huomioon otettua virhetyyppiä Kolme virhetyyppiä, josta kaksi otettiin huomioon Taulukko 4. Huomioon otetut virheet toisessa iteraatiossa Ohjelma Vakavuus Kuvaus Qstudio Qstudio FindBugs 2 Javadoc puutteellista Käyttämätön muuttuja Poikkeusta ei välttämättä saada kiinni

6 T Software project 6(8) FindBugs Methodi käyttää enemmän muistia käyttävää boolean konstruktoria metodin Boolean.valueOf() sijaan Päätelmiä kerätyistä metriikoista ja heränneitä ajatuksia Qstudion virheistä lähes kaikki huomioon otetut virheet oli puutteellisia Javadoc-kommentteja. Lisäksi oli muutama ilmoitus käyttämättömistä muuttujista. Molemmat ovat hyödyllisiä tietoja, joskin eivät mitenkään kriittisiä. Lisäksi monet puutteellisista Javadoc-tiedoista olivat esiintyneet jo viime iteraatiossa. FindBugs ilmoitti huomattavasti olennaisimmista bugeista, mutta Boolean virhe on selkeästi triviaali, kun taas poikkeuksien tapauksessa kyse oli väärästä hälytyksestä. Täten molempien menetelmien hyöty ei vastaa käytettyä aikaa myöskään tässä iteraatiossa, joskin kehitystä viime iteraatioon nähden on huomattavasti. 4. Arviointi I-vaiheessa Huolimatta heikoista tuloksista kolmannessa vaiheessa päätettiin käyttää molempia menetelmiä, koska testien suoritukseen ei kulu kovin paljon aikaa ja edes yhden pienen virheen löytäminen olisi hyödyllistä. Tarkoitus oli jatkaa Qstudion automaattitarkistusten kehittämistä, mutta valitettavasti tietokoneen vaihdon takia kaikki vanhat Qstudion projektitiedot hävisivät, jolloin karsinta jouduttiin tekemään pelkästään muistiin perustuen. Tämä aiheutti valitettavasti askeleen taaksepäin, sillä Qstudion tapauksessa kehitys tapahtuu hitaan muokkaamisen kautta. Tässä iteraatiossa ei löytynyt kummallakaan menetelmällä yhtään uutta huomioon otettua virhettä. Qstudion virhelastia alkoi olla jo hankalaa hallita lukuisten tiedostojen takia, mutta osasyynä tähän on toki edellä mainittu tietokato. Tarkistuksia olisi pitänyt karsia vielä huomattavasti enemmän, mutta toisaalta tällöin voi aina mennä potentiaalinen virhelähde ohi Metriikat tehdystä arvioinnista Taulukko 5. Ohjelmien havaitsemat virheet kolmannessa iteraatiossa Ohjelma Löydetyt virheet Virheiden luokitus Huomioon otetut virheet Kommentti Qstudio n FindBugs 19 0 Pitkälti samat virheet kuin toisessa iteraatiossa Samat virheet kuin toisessa iteraatiossa Päätelmiä kerätyistä metriikoista ja heränneitä ajatuksia Suurin silmiinpistävä statistiikka on huomioon otettujen virheiden määrä, joka on pyöreä nolla. Virheitä toki ilmeni, mutta ne olivat I2-vaiheen ilmentymien kopioita, joten en lähtenyt niitä sen enempää ilmoittamaan Bugzillaan. Tosin FindBugs:in osalta edes määrissä ei tullut yhtään lisää, joten voisi ehkä ajatella toteuttajien

7 T Software project 7(8) oppineen tekemään virheetöntä koodia suoraan, vaikka vanhoja virheitä ei korjattukaan. Tällaisen oletuksen tekeminen ei kuitenkin ole kovin vakaalla pohjalla. Toinen mielenkiintoinen huomio on FindBugs:in hyvä skaalautuvuus runsaaseen tietomäärään. Siitä voisi oikeasti olla hyötyä kokemattomien koodaajien tapauksessa, jolloin tavanomaisten virheiden todennäköisyys kasvaa huomattavasti. Qstudio sen sijaan tuntuu tukehtuvan tietomääräänsä, vaikka tarkistimia karsisikin reilulla kädellä. 5. Yhteenveto Taulukko 6. Menetelmien tulokset Ohjelma Suoritetut ajot Löydetyt virheet Virheiden luokitus Huomioon otetut virheet Kommentti Qstudio n FindBugs Vain kahta virhetyyppiä ja niistäkin 90 % ilmoituksia puutteellisesta javadoc:sta Virheet jakautuivat tasaisesti kolmen tyypin kesken 5.1 Johtopäätöksiä menetelmien tuloksista Sekä metriikat että oma mielipiteeni osoittavat, ettei menetelmästä ollut vastaavaa hyötyä projektille siihen käytettyyn aikaan nähden. Täysin hyödytön se ei ollut, mutta tavallisella testauksella saatiin pienemmässä ajassa huomattavasti parempia tuloksia. Aikaa staattiseen testaukseen kului tasan 20 tuntia, jos laskee mukaan asennuksien ja testiajojen lisäksi myös menetelmiin tutustumisen, niiden käytön suunnittelun sekä kokemuksien raportoinnin. 6. Loppusanat Vaikka menetelmistä ei ollut suurta hyötyä projektille, en kuitenkaan yleisellä tasolla ole valmis kuoppaamaan staattisen testauksen ajatusta, enkä kumpaakaan menetelmää edes web-sovelluksien tapauksessa. FindBugs on varsinkin ensimmäisen tutustumisen jälkeen hyvin nopea asentaa, ja sillä voi potentiaalisesti saada kiinni pahojakin virheitä. Luonnollisesti jos tällaisia ei ilmene koodissa ei FindBugs:ista ole hyötyä, mutta edes yhdenkin muuten havaitsemattoman virheen löytäminen olisi saanut menetelmän kannattavaksi sekä tälle projektille että miksei myös muille projekteille. Jos FindBugs oli helppokäyttöinen, vaatii Qstudion käyttö puolestaan paljon sen käyttäjältä. Vaihtoehtojen ja saatujen virheilmoitusten määrä on niin suuri, että käyttäjien pitää osata karsia joko kokeilujen tai kokemuksen kautta jokaiselle projektille omat säädöt. Uskoisin sopivien säätöjen löydyttyä myös Qstudiosta olevan hyötyä projektille, vaikka sen skaalautuvuus isoihin projekteihin onkin vähän kyseenalaista. Erityisesti jos projektin kannalta on tärkeätä saada helppolukuista ja helposti muokattavaa koodia, antaa Qstudio sopivilla parametreillä varoitukset niistä ohjelmiston osa-alueista, joita tulisi refaktoroida yksinkertaisemmiksi.

8 T Software project 8(8) Kuitenkin molempien näiden menetelmien tapauksessa tulee väistämättä mieleen, että ovatko ne kuitenkaan loppujen lopuksi parempia kuin koodin käyminen läpi ihmisten toimesta? Kokeneet testaajat huomaavat paperilta virheet taatusti paremmin kuin kone, joten kasvanut ajankäyttö ei riitä perusteluksi koneellisen testauksen käytölle. Avainsanaksi muodostuu mielestäni kokemus. Kokemattomat testaajat eivät välttämättä huomaa paperilta virheitä, mutta kone taas on tasaisen varma testaussuorituksessaan. Tätä tietoa voidaan käyttää hyväksi myös ohjelmiston laatua arvioitaessa, kunhan ensin on saatu tarpeeksi kokemusta kyseisestä menetelmästä, jolloin sen saamien tuloksien pohjalta voidaan tehdä päätelmiä. Valitettavasti kyseinen iterointi on tämän projektin laajuuden ulkopuolella.