Mobiililaitteiden audiotestauksen automatisointi Diplomityö

Transkriptio

1 TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto Juhana Gummerus Vesa Poikajärvi Mobiililaitteiden audiotestauksen automatisointi Diplomityö Aihe hyväksytty osastoneuvoston kokouksessa Tarkastajat: Tommi Mikkonen (TTY) Atri Vainikainen (SysOpen Digia)

2 Alkulause Olemme tehneet diplomityömme SysOpen Digian älypuhelinliiketoimintadivisioonassa Tampereella osana laajempaa testausautomaatioprojektia. Kiitokset tasapuolisesti kaikille työssä mukana olleille. Erityisesti tahdomme esittää kiitoksemme työmme ohjaajalle, professori Tommi Mikkoselle, sekä SysOpen Digian puolesta ohjaajanamme toimineelle projektipäällikkö Atri Vainikaiselle. Lämpimät kiitokset myös projektissa mukana olleille Tommi Toropaiselle, Jarkko Suontaustalle, Jussi Routakankaalle sekä SysOpen Digian työntekijöille heidän tuestaan ja näkemyksestään. Lopuksi haluamme kiittää myös Elina Ylöstaloa ja Terhi Svennsiä. Tampereella Juhana Gummerus Vesa Poikajärvi Tarjanteenkatu 7 Härmälänsaarenkatu Tampere Tampere i

3 TAMPEREEN TEKNILLINEN YLIOPISTO Tietotekniikan osasto Ohjelmistotekniikka Juhana Gummerus, Vesa Poikajärvi: Mobiililaitteiden audiotestauksen automatisointi Diplomityö, 81 s., 5 liites. Tarkastaja: Tommi Mikkonen Rahoittaja: SysOpen Digia Oyj, Smartphone Business Division Elokuu 2006 Avainsanat: matkapuhelin, audio, testaus, testauksen automatisointi Ohjelmistotestaus on tärkeä, mutta helposti unohduksiin jäävä ohjelmistoprosessin osa. Huolellisesti suunniteltu ja suoritettu testausprosessi auttaa löytämään ohjelmistosta virheitä. Testaus on kuitenkin manuaalisesti suoritettuna aikaavievä ja vaativa prosessi. Koska testattavat ohjelmistot ovat yhä suurempia ja uusia ohjelmistoversioita ilmestyy yhä useammin, hyväksi ratkaisuksi on havaittu testauksen automatisointi. Automatisointi ei kuitenkaan ole yksinkertaista, etenkään jos automatisoidaan multimediaominaisuuksien testausta. Matkapuhelinten audiotestaus on jo aiemminkin ollut osittain automatisoitua. Audiotestien suoritus on automatisoitu, mutta testien tulosten automaattinen verifiointi on puuttunut. Testaajan onkin täytynyt tehdä päätös hyväksytystä testitapauksesta korvakuulolla eli kuunnella samoja matkapuhelimen tuottamia ääniä testikierroksesta toiseen. AATE (Automated Audio Testing Environment) on ohjelmisto, joka toimii yhteistyössä olemassa olevan testiautomaatiojärjestelmän kanssa, ja sen tarkoituksena on vapauttaa testaaja kuuntelemasta audiotestien tuloksia. AATE tallentaa matkapuhelimessa suoritetun audiotestin tuottaman audiodatan datankaappauskortin avulla ja vertaa tallennettua audiodataa aiemmin hyväksyttyyn verrokkidataan. Vertailun tuloksena saadaan tieto siitä, ovatko matkapuhelimen uuden ohjelmistoversion audio-ominaisuudet edelleen hyväksyttävällä tasolla. ii

4 TAMPERE UNIVERSITY OF TECHNOLOGY Department of Information Technology Institute of Software Systems Juhana Gummerus, Vesa Poikajärvi: Automated Testing of Audio Features of Mobile Devices Master of Science Thesis, 81 pages, 5 enclosure pages. Examiner: Tommi Mikkonen Financier: SysOpen Digia Plc, Smartphone Business Division August 2006 Keywords: mobile phone, audio, testing, test automation Software testing is an important but easily neglected part of the software development process. Carefully planned and executed testing process will help in tracking down software errors. However, manually executed testing can be a timeconsuming and demanding process. Since the software components under testing are getting bigger and bigger, and new software versions are being released more and more frequently, the automated testing process is perceived as a good solution. The automated testing process is by no means a trivial task, especially if the subject of testing is multimedia features. Audio testing of mobile phones is already partially automated. The execution of the audio tests is automated but an automated verification of the test results has been missing. Test engineers have been forced to aurally verify the test case results - meaning the listening of the same sounds produced by the mobile phone test round after another. AATE (Automated Audio Testing Environment) is a software application which works in cooperation with an existing test automation system, and its purpose is to liberate the test engineer of listening audio test results. AATE stores audio data produced by an audio test execution in a mobile phone using data acquisition card and compares the stored audio data against the reference data which was approved earlier. The comparison result tells if audio features of a new software release in the mobile phone are still on an acceptable level. iii

5 Sisällysluettelo 1 Johdanto 1 2 Ohjelmistotestaus Johdanto Ohjelmistotuotanto Vesiputousmalli ja testauksen V-malli Vaihtoehtoiset elinkaarimallit Testauksen tasot Yksikkö- tai moduulitestaus Integrointitestaus Järjestelmätestaus Hyväksymistestaus Testitapausten tunnistaminen Lähestymistavat ja niiden käyttö Toiminnallinen testaus Rakenteellinen testaus Testauksen riittävyyden arviointi Testauksen ja testausohjelmistojen kehittäminen Ohjelmistotestauksen automatisointi Johdanto Mitä ja milloin automatisoida Ensisijaiset ehdokkaat Regressio- ja savutestaus Stressi- ja kuormitustestaus Suorituskyky- ja luotettavuustestaus Automatisointi testauksen eri tasoilla Yksikkötestaus Integrointitestaus Järjestelmätestaus Hyväksymistestaus Automatisoinnin hyödyt Ohjelmiston luotettavuuden paraneminen Testauksen laadun paraneminen iv

6 3.4.3 Käytettävien resurssien tarpeen väheneminen Automatisoinnin haasteet Väärät odotukset Kustannukset ja niiden saaminen takaisin Lisätyö Rajoitteet Muut ongelmat Tulosten analysointi automaattisesti Matkapuhelinten testaus Matkapuhelinten erityisvaatimukset testaukselle ja testauksen automatisoinnille Ympäristö, laitteet ja työkalut Testauslaitteisto Testiautomaatiojärjestelmä Testikehys Audiotestaus AATE idea ja vaatimukset Yleiskuvaus Yhteensopivuus testiautomaatiojärjestelmän kanssa Laitteisto Audiosignaalien tallennus ja käsittely Audiosignaalien vertailu Järjestelmän tallentamat tiedot Uudelleenkäytettävyys, laajennettavuus ja siirrettävyys Toteutus ja testaus Suunnittelu ja ohjelmistoarkkitehtuuri Tilakoneet viestien käsittelyyn Säikeistys Kommunikointi testiautomaatiojärjestelmän kanssa Protokolla ja toteutus Yhteentoimivuuden testaus Audiodatan kaappaus v

7 6.5.1 Datankaappauskortin ohjelmointirajapinta Datankaappaustoimintojen testaus Audiosignaalien vertailu Vertailumetodin toteutus Vertailumetodin testaus Käyttäytyminen virhetilanteissa Analyysi ja jatkokehitysajatuksia Audiosignaalien vertailun soveltuvuus, ongelmat ja rajoitukset Audiodatan käsittely segmenteissä Näytearvojen vaakapoikkeama Käyttökokemukset ja saavutetut hyödyt Jatkokehitysajatuksia Äänipuheluiden testaus Kuva- ja video-ominaisuuksien testaus Signaalien vertailumetodin jatkokehitys Yhteenveto 79 Lähdeluettelo 80 Liitteet 82 A WAVE PCM -otsikkotiedot B Korrelaatiolaskennan testisignaalit vi

8 Määritelmät ja lyhenteet AATE Automated Audio Testing Environment. Audacity Avoimen lähdekoodin äänieditori. Bluetooth Lyhyen kantaman radiotekniikkaan perustuva langaton tiedonsiirtomenetelmä. CD Compact Disc. Audion digitaaliseen tallentamiseen käytettävä media. DC Direct Current, tasavirta. DFT Discrete Fourier Transform, diskreetti Fourier-muunnos. FFT Fast Fourier Transform, nopea Fourier-muunnos. Algoritmi DFT:n laskemiseen. GCC GNU Compiler Collection. Avoimen lähdekoodin kääntäjäkokoelma. GNU GNU s Not UNIX. Projekti, jonka tarkoituksena on kehittää Unixin kaltainen, vapaa käyttöjärjestelmä. IEEE Institute of Electrical and Electronics Engineers, Inc. IP Internet Protocol. Linux Avoimen lähdekoodin käyttöjärjestelmä. Matlab Kaupallinen ohjelmisto matriisilaskentaan ja numeriikkaan. Microsoft Windows Kaupallinen käyttöjärjestelmä. NI-DAQmx National Instrumentsin ohjelmointirajapinta. Octave Avoimen lähdekoodin ohjelmisto matriisilaskentaan ja numeriikkaan. OS Operating System, käyttöjärjestelmä. PCM Pulse Code Modulation. POSIX Portable Operating System Interface. Käyttöjärjestelmille kehitetty standardi- ja määrittelykokonaisuus. RAD Rapid Application Development. Sovelluskehitysmalli. RIFF Resource Interchange File Format. Microsoftin spesifikaatio multimediatiedostojen tallentamiseen. Symbian OS Symbian Ltd:n mobiililaitteiden käyttöjärjestelmä. TCP Transmission Control Protocol. TCP/IP Tietoliikenneprotokollaperhe, jossa kuljetuskerroksena on TCP ja verkkokerroksena IP. WAVE Waveform Audio File Format. Audiotiedostoformaatti. vii

9 1 Johdanto Ohjelmistokehityksen aikataulut tiukentuvat, ja ohjelmistojen monimutkaisuus kasvaa jatkuvasti. Yhdessä nämä asettavat kovia paineita ohjelmistotestaukselle. Lisäksi usein kehitetään samanaikaisesti kokonaisia ohjelmistotuoteperheitä yhteisine ominaisuuksineen ja piirteineen, jolloin ohjelmistotestausprosessin pitäisi olla mahdollisimman uudelleenkäytettävä tehokkuuden lisäämiseksi. Hyvänä esimerkkinä voidaan mainita matkapuhelinten valmistus, jossa laadukkaan tuotteen ajoissa markkinoille saaminen saattaa olla erityisen kriittistä. Testauksen tulisi olla yhtä aikaa entistä syvällisempää, nopeampaa ja edullisempaa laadusta kuitenkaan tinkimättä. Koska näitä vaatimuksia on vaikea täyttää manuaalisella testauksella, on ratkaisua ryhdytty hakemaan testauksen automatisoinnista. Ohjelmistotestauksen automatisoinnissa on monia kompastuskiviä. On tärkeää tietää, millaisia testitapauksia, mitä osa-alueita ja missä testausprosessin vaiheessa on mahdollista ja kannattavaa automatisoida. Lisäksi tulisi ymmärtää, että automatisointi vaatii usein huomattavaa panostusta käytännössä jopa oman ohjelmistokehitysprojektin, jossa testausohjelmistoa kehitetään varsinaisen tuotteen ohjelmistokehityksen rinnalla. Jos automatisointi onnistutaan toteuttamaan oikein, automatisointiin sijoitetut investoinnit yleensä maksavat itsensä pidemmällä aikavälillä takaisin. Testauksen automatisointi yleensä myös tehostaa tuotteiden testausta ja vahvistaa niiden laatua. Tässä diplomityössä käsitellään niin ohjelmistojen testausta kuin sen automatisointiakin. Työssä esitellään tarkemmin erään ohjelmistotestauksen automatisointiprosessin osana toteutettu ohjelmisto, AATE (Automated Audio Testing Environment). AATE mahdollistaa matkapuhelimille tarkoitettujen automaattisten audiotestien tulosten automaattisen oikeaksi varmistamisen. AATE toimii käytössä olevan testiautomaatiojärjestelmän ohjastamana tallentaen matkapuhelimen soittamaa audiota, jota se vertaa testaajan aiemmin riittävän hyväksi toteamaan audiodataan. Vertailutuloksen perusteella tehdään päätös testitapauksen hyväksymisestä tai hyväksymättä jättämisestä. Oman järjestelmän toteuttamiseen päädyttiin, koska tarkoitukseen suoraan sopivaa valmista järjestelmää ei löytynyt. Valmiiden audion vertailuun sopivien ohjelmistojen ongelmina olivat yhteensopimattomuus käytössä olevan testiautomaa- 1

10 tiojärjestelmän kanssa sekä lisenssimaksut. Näiden ohjelmistojen ohjaamiseen olisi joka tapauksessa jouduttu toteuttaa erillinen ohjelmisto, joten parhaaksi ratkaisuksi todettiin toteuttaa koko järjestelmä itse, jolloin se voitiin suunnitella täsmälleen tarvetta vastaavaksi. Samalla pystyttiin minimoimaan riippuvuudet kolmansien osapuolten ohjelmistoihin tai ohjelmistokomponentteihin, mikä laskee ohjelmiston käyttökustannuksia. Itse toteutetun ohjelmiston käyttäminen yrityksen sisällä on lisenssimielessä ilmaista, joten kaikki halukkaat voivat ottaa ohjelmiston käyttöön ilman merkittäviä kustannuksia. Diplomityön toinen luku aloittaa ohjelmistotestauksen tarkastelun osana ohjelmistotuotantoprosesseja. Luku esittelee yleisen tavan jakaa ohjelmistotestas eri tasoihin ja keskeisimmät lähestymistavat testitapausten tunnistamiseen, sekä käsittelee lyhyesti testauksen ja testausohjelmistojen kehittämistä. Kolmannessa luvussa esitellään ohjelmistotestauksen automatisointia. Siinä esitellään edellisen luvun pohjalta automatisoinnin perustiedot sekä automatisointi testauksen eri tasoilla. Luvussa perehdytään automatisoinnin haasteisiin ja hyötyihin sekä tulosten automaattiseen analysointiin. Analysointi on toteuttamassamme ohjelmistossa tärkeässä roolissa, sillä multimediaominaisuuksien testauksessa hyväksymispäätöksen tekeminen ei ole suoraviivaista. Neljäs luku käsittelee matkapuhelinten testausta sekä yleisesti että diplomityössä kuvatun ohjelmistototeutuksen puitteissa. Luvussa esitellään matkapuhelinten erityisvaatimuksia testaukselle ja sen automatisoinnille sekä käytössä olevia järjestelmiä. Näiden järjestelmien avulla suoritettavaa audiotestausta kuvataan luvun lopussa. Tässä yhteydessä kuvataan myös syitä automatisointiprosessin käynnistämiselle. Viidennessä luvussa alkaa diplomityönä toteutetun ohjelmiston AATE:n kuvaus. Lukuun sisältyy järjestelmän yleiskuvauksen, tärkeimpien määrittelyvaatimuksien, ohjelmiston tarvitseman laitteiston sekä audiosignaalien vertailuun tarvittavan taustateorian esittely. Kuudes luku sisältää AATE:n toteutuksen suunnittelun ja ohjelmistoarkkitehtuurin kuvauksen sekä käytetyt ohjelmistosuunnittelumallit. Lisäksi luvussa kuvataan AATE:n tärkeimpien kokonaisuuksien, kuten audiosignaalien vertailumenetelmän, toteutus ja testaus. 2

11 Seitsemäs luku esittelee työn toimivuuden arvion. Luvussa esitellään niin saavutetut hyödyt kuin havaitut ongelmatkin. Ongelmiin esitetään mahdolliset ratkaisutavat. Käyttäjäkokemukset sekä jatkokehitysajatukset esitellään myös tässä luvussa. Viimeinen, kahdeksas luku on varattu yhteenvedolle. Luvussa arvioidaan toteuttamamme ohjelmiston ja sen kehitysprosessin onnistumista sekä yleistä asennetta testausohjelmistojen ja niiden kehittämisen suhteen. 3

12 2 Ohjelmistotestaus 2.1 Johdanto Ohjelmistotestaus on keskeinen osa ohjelmistojen laadunvarmistusta. Jo vuonna 1979 Myers kuvasi yhdessä alan perusteoksista, The Art of Software Testing, ohjelmistotestausta seuraavasti: Testing is the process of executing a program or system with the intent of finding errors., mikä pitää edelleen hyvin paikkansa (Myers, 2004). Ohjelmistotestaus on luonteeltaan tuhoava prossessi, jossa testaaja pyrkii osoittamaan, että ohjelmisto toimii väärin. Tämän takia testausinsinöörin tulisikin hallita oikeat systemaattiset menetelmät testata ohjelmiston toiminnallisia ja rakenteellisia ominaisuuksia. Yksi ohjelmistotestaukseen liittyvä ongelma on, että se mielletään usein ohjelmistotuotantoprosessin jälkeen suoritettavaksi erilliseksi vaiheeksi. Kun aikatauluissa viivästymiset ovat tavallista ohjelmistotuotannossa, saatetaan juuri testausvaihe suorittaa huolimattomasti ja riittämättömästi viimeisenä. Tämän takia ohjelmistotestauksen tulisikin olla, kuten Craig ja Jaskiel (2002) asian muotoilevat,...a concurrent lifecycle process of engineering, using and maintaining testware in order to measure and improve the quality of the sortware being tested, kiinteästi ja samanaikaisesti ohjelmistotuotannon kanssa testaustyökaluin suoritettava prosessi. 2.2 Ohjelmistotuotanto Vesiputousmalli ja testauksen V-malli Perinteisesti ohjelmistotuotannossa on käytetty jonkinlaista peräkkäisin vaihein etenevää elinkaarimallia, jossa ensin kerätään vaatimukset, suunnitellaan ja tehdään toteutus sekä lopuksi aloitetaan testaus. Tällaista ohjelmistotuotannon elinkaarimallia kutsutaan myös vesiputousmalliksi, joka on esitetty kuvassa 2.1. (Jorgensen, 2002; Myers, 2004) 4

13 Kuva 2.1: Vesiputousmalli (Jorgensen, 2002) Peräkkäisin vaihein etenevän tuotantomallin ilmeisin etu on, että resurssit on kerralla keskitetty yhteen vaiheeseen, ja näin jokainen vaihe saa lähtökohdakseen edellisen, valmiiksi saadun vaihetuotoksen. Tämä on kuitenkin tuotantomallin ongelma. Erityisesti testaajien tulisi olla kiinnostuneita vaatimusten laadusta, täydellisyydestä ja tasapainoisuudesta. Ohjelmistotuotannon alussa huonosti toteutettu vaatimusmäärittely johtaa todennäköisimmin toteutukseen, jota loppukäyttäjä ei halunnut, tai pahimmassa tapauksessa tuotantoprosessin loppuvaiheen testauksessa löytyviin vikoihin. Vesiputousmallin mukaisessa tuotannossa esiintyykin usein tarvetta palata edelliseen vaiheeseen yllätysten tai laiminlyötyjen asioiden takia. Ongelma on myös testauksen sijoittuminen tuotannon loppuun, jolloin testaajat voivat yrittää löytää vikoja vain lähes valmiista tuotteesta. Koska usein ohjelmistotuotannon aikataulut venyvät, kutistuu mahdollisuus kattavaan testaukseen entisestään julkaisupaineen alla. (Craig ja Jaskiel, 2002) Testausprosessin tasot ovat yksikkö- tai moduulitestaus, integrointitestaus, järjestelmätestaus ja hyväksymistestaus. Nämä kuvataan usein vastaamaan vesiputousmallin vaiheita, jolloin puhutaan ohjelmistotestauksen V-mallista (kuva 2.2). Tämän mallin mukaan testauksen tasojen suunnittelu voidaan aloittaa samalla kuin vastaavan tuotannon; esimerkiksi hyväksymistestaus voidaan suunnitella samalla, kun määritellään vaatimukset. (Craig ja Jaskiel, 2002) 5

14 Kuva 2.2: V-malli (Jorgensen, 2002) Vaihtoehtoiset elinkaarimallit Perinteisen vesiputousmallin heikkoudet ovat luoneet vesiputousmallin rinnalle uusia tapoja toteuttaa ohjelmistotuotantoprojekti. Suurimmat heikkoudet, eli tarve ymmärtää toteutettavan ohjelmiston vaatimukset täysin ja ohjelmistotuotannon tarvitsema aika vaatimuksista valmiiseen tuotteeseen, ovat luoneet niin sanottuja inkrementaali- tai evoluutiokehitysmalleja (kuva 2.3). Ideana on aloittaa yksinkertaisista, hyvin tunnetuista ominaisuuksista sekä lisätä vaiheittain uusia ominaisuuksia ja ehkä poistaa huonoksi osoittautuneita. Ensimmäisen ohjelmistokäännöksen tai prototyypin jälkeen voidaan kehitystä jatkaa esimerkiksi asiakkaan tai käyttäjän asettamien muuttuvien vaatimusten tai tarpeiden mukaan. Jatkokehitystä voivat ohjata myös havaitut teknologiaan liittyvät riskitekijät. (Jorgensen, 2002) Koska peräkkäin lisätyt ominaisuudet (increments) ja niiden käännökset (builds) ovat joukko loppukäyttäjälle näkyviä toiminnallisuuksia, yksi merkittävä etu inkrementaalikehitysmalleille on aikainen toimiva ohjelmiston kokoonpano. Tämä johtaa aikaiseen asiakaspalautteeseen, mikä vähentää perinteisen vesiputousmallin ongelmia. Inkrementaalikehitysmalli onkin käytössä useimmissa tuotekehitysprojekteissa. Peräkkäiset ominaisuuslisäykset tuovat myös uuden tärkeän piirteen järjestelmätestaukseen; regressiotestauksen (alakohta 3.2.2). (Jorgensen, 2002) 6

15 Kuva 2.3: Inkrementaalikehitysmalli (Jorgensen, 2002) Motiivina inkrementaalikehitysmalleille on yleensä myös henkilöstön rakenne. Perinteinen vesiputousmalli saattaa tarvita suuren määrän henkilöstöä tuotannon eri vaiheisiin suunnittelusta testaukseen. Useimmat yritykset pystyvät tukemaan paremmin pienempiin osiin jaettua kehitysmallia olemassa olevalla henkilöstöllään. (Jorgensen, 2002) 2.3 Testauksen tasot Yksikkö- tai moduulitestaus Yksikkö- tai moduulitestauksen (unit testing, module testing) tarkoitus on testata koko valmiin ohjelmiston sijaan aluksi sen pienimmät rakennuspalikat: aliohjelmat, funktiot, luokat ja niin edelleen. Testattava moduuli tarvitsee erityisen ajurimoduulin (driver) sekä yhden tai useamman tynkämoduulin (stub). Ajurin tehtävänä on välittää testitapaukset testattavalle moduulille sekä esittää testitulokset. Tyngät edustavat taas muita moduuleita, joita testattava moduuli kutsuisi. (Myers, 2004) Yksikkötestaukseen motivoi kolme asiaa: se on tapa hallita testauksen yhdistäviä elementtejä, koska aluksi keskitytään pienimpiin moduuleihin; se helpottaa 7

16 virheenkorjausta ja -paikantamista, koska virheen tiedetään sijaitsevan tietyssä moduulissa; ja se mahdollistaa testausprosessin tehostamisen, kun useita moduuleita voidaan testata rinnakkain. (Myers, 2004) Moduulitestitapausten suunnittelun pohjana käytetään moduulisuunnitteludokumentaatiota ja moduulin lähdekoodia, mistä johtuen käytetään usein rakenteellista lähestymistapaa (alakohta 2.4.3). Tavoite ei ole osoittaa ohjelmiston toimivan, vaan että ohjelmisto ei toimi kuten on suunniteltu. (Myers, 2004) Integrointitestaus Integrointitestauksen (integration testing) tarkoituksena on taata, että ohjelmiston moduulit toimivat yhdessä, rajapinnat toimivat ja data siirtyy oikeassa muodossa. Alimmalla tasolla integrointitestausta tekee normaalisti ohjelmistokehitysryhmä taatakseen, että moduulit toimivat yhdessä oikein. Korkeammalla tasolla integrointitestausta ja käännösten testausta tekevät testausryhmät. (Craig ja Jaskiel, 2002) Yksi tärkeimmistä asioista on päättää tapa, jolla moduulit yhdistetään. Tähän vaikuttavat järjestys, jossa moduulit toteutetaan ja testataan, missä muodossa testitapaukset toteutetaan, minkä tyyppisiä testaustyökaluja voidaan käyttää sekä mitkä ovat testauksen ja testitapauskehityksen kustannukset. Integrointitestaukseen käytetään tavallisesti joko inkrementaalista tai ei-inkrementaalista testaustapaa. Kysymys testaustavan valinnassa on, tulisiko moduulit testata ensin itsenäisesti ja sitten yhdistää toimivaksi ohjelmistoksi, vai tulisiko testattava moduuli ennen testausta yhdistää aikaisemmin testatun moduulin kanssa. (Myers, 2004) Ei-inkrementaalisessa testaustavassa (kutsutaan myös big-bang -tavaksi) moduulit (kuva 2.4) testataan ensin itsenäisinä yksikköinä, joko peräkkäin tai rinnan riippuen testiympäristöstä ja henkilöstöstä. Tällöin jokainen moduuli tarvitsee omat ajuri- ja tynkämoduulinsa. Lopuksi yksikkötestatut moduulit yhdistetään ohjelmistoksi. (Myers, 2004) Inkrementaalisessa testaustavassa, jota voidaan pitää myös ohjelmistotuotantotapana, on kaksi vaihtoehtoa: jäsentävä tai osittava testaus (top-down testing), tai kokoava testaus (bottom-up testing). Jäsentävässä testauksessa (kuva 2.5) aloitetaan ylimmän tason moduulista, jonka kutsumille alemman tason moduu- 8

17 Kuva 2.4: Integrointitestauksen big-bang -testaustapa (Jorgensen, 2002) leille kirjoitetaan tyngät. Haasteena on tynkien toteutus, sillä niiden tulee olla usein monipuolisempia kuin vain esimerkiksi tulostustoiminto. Lisäksi testitapausten suorituksen tulee tapahtua tynkien kautta, jolloin saattaa esiintyä tarvetta tehdä eri testitapauksille erilaisia ja ehkä monimutkaisiakin tynkätoteutuksia. Testaustavan suurin etu on, että ohjelmistosta saadaan aikainen demoversio vakuuttamaan ohjelmiston toimivuudesta. (Myers, 2004) Kuva 2.5: Integrointitestauksen jäsentävä testaustapa (Jorgensen, 2002) Kokoavassa testauksessa (kuva 2.6) aloitetaan alimman tason moduuleista, jotka eivät kutsu muita moduuleita. Näille luodaan ajurimoduulit, jotka kutsuvat testattavaa moduulia testisyötteillä ja näyttävät tulokset. Ajureista ei ole tarvetta kirjoittaa eri versioita, koska ne voivat iteratiivisesti kutsua testattavaa moduu- 9

18 lia. Tämä tekee niistä monissa tapauksissa myös helpommin toteutettavia kuin tynkämoduulit. Testaustavan haittana on, että ohjelmistosta saadaan toimiva versio vasta, kun viimeinenkin moduuli on testattu ja lisätty. (Myers, 2004) Kuva 2.6: Integrointitestauksen kokoava testaustapa (Jorgensen, 2002) Järjestelmätestaus Järjestelmätestauksen (system testing) tarkoituksena on taata, että tuote kokonaisuudessaan täyttää alkuperäiset tavoitteet. Järjestelmätestausta on mahdotonta suorittaa, jos kirjallisia, mitattavia tavoitteita ei ole olemassa. (Myers, 2004) Riippuen toteutettavasta ohjelmistosta järjestelmätestauksen testitapaukset voivat kattaa ohjelmiston vaatimusten lisäksi muun muassa suunnittelupiirteiden, ohjelmiston tilojen, suurten datamäärien käsittelyn ja tallentamisen, raskaiden laskentojen eli suorituskyvyn, rinnakkaisuuden testejä. Myös konfiguraation, laitteiston, asennuksen, rajapintojen, lokalisoinnin, virhetilanteista toipumisen, resurssien käytön, turvallisuuden ja luotettavuuden tai käytettävyyden testejä voi kuulua järjestelmätestaukseen. Järjestelmätestauksen testitapaukset tai niiden osa muodostavat yleensä osan regressiotesteistä (alakohta 3.2.2) tuotteen tulevia julkaisuja (release) varten. (Craig ja Jaskiel, 2002; Myers, 2004) 10

19 2.3.4 Hyväksymistestaus Hyväksymistestaus (acceptance testing) perustuu pääasiassa käyttäjävaatimuksiin, ja se osoittaa niiden täyttymisen. Testaus on kaikkein tehokkainta suorittaa käyttäjän toimesta hänen omissa tiloissa aidossa ympäristössä, mikä onkin suurin ero järjestelmä- ja hyväksymistestauksen välillä. Tuotantotiloissa suoritettavasta testauksesta käytetään termiä alpha-testaus (alpha testing), kun taas käyttäjän tai asiakkaan tiloissa suoritettavasta testauksesta käytetään termiä beta-testaus (beta testing). (Craig ja Jaskiel, 2002) Hyväksymistestit suunnitellaan ensimmäisenä. Niiden tarkoituksena on mallintaa, miltä valmis ohjelmisto tulee näyttämään. (Craig ja Jaskiel, 2002) 2.4 Testitapausten tunnistaminen Lähestymistavat ja niiden käyttö Testausprosessin vaiheiden testitapausten määrittelyssä käytetään tavallisesti kahta lähestymistapaa: toiminnallinen testaus (functional testing) ja rakenteellinen testaus (structural testing). Toiminnallisessa testauksessa ohjelmiston toteutus ei ole tunnettu ja testitapaukset määritellään vain ulkoisen rajapinnan avulla, sekä syötteiden ja tulostusten perusteella. Rakenteellisessa testauksessa ohjelmiston toteutus on tunnettu, ja testitapausten määrittely perustuu oikealle toiminnallisuudelle. Valittuun lähestymistapaan vaikuttaa saatavilla oleva informaatio kussakin tuotannon vaiheessa. Esimerkiksi yksikkötestauksessa käytetään tavallisesti rakenteellista testausta, jolloin ohjelmistosta on saatavilla toteutus tai yksityiskohtainen arkkitehtuurikuvaus, kun taas järjestelmätestauksessa käytetään toiminnallista testausta, jolloin ohjelmistosta on saatavilla vaatimus- ja toiminnallinen määrittely. (Jorgensen, 2002) Lähestymistavat testitapausten määrittelyyn eivät ole toisiaan poissulkevia, koska molemmilla on vahvuutensa. Rakenteellinen testaus ei tunnista käyttäytymistä, joka ei perustu ohjelmiston toteutukseen; toiminnallinen testaus taas ei tunnista käyttäytymistä, jota ei ole kuvattu ohjelmiston toiminnallisessa määrittelyssä. Testitapausten suunnittelussa tulisi käyttää molempia lähestymistapoja riittävän testikattavuuden ja ohjelmiston toimintavarmuuden saavuttamiseksi. 11

20 Seuraavissa alakohdissa tarkastellaan näitä lähestymistapoja tarkemmin. (Jorgensen, 2002; Myers, 2004) Toiminnallinen testaus Toiminnallisessa testauksessa, jota kutsutaan myös mustalaatikkotestaukseksi (black-box testing) tai käyttäytymistestaukseksi (behavioural testing), ohjelmisto käsitellään suljettuna laatikkona. Laatikon sisäinen toiminta on tuntematon, mutta sille voidaan antaa syötteitä, joiden tuottamaa tulosta tarkastellaan. Testitapaus tulkitaan hyväksytyksi, jos tulos on mitä odotettiin. Testitapaukset tunnistetaan ohjelmiston toiminnallisen määrittelyn pohjalta. (Craig ja Jaskiel, 2002; Jorgensen, 2002) Toiminnallisen testauksen hyödyt ovat ilmeiset. Testitapaukset ovat riippumattomia ohjelmiston toteutuksesta, eli jos toteutus muuttuu, testitapaukset ovat edelleen käyttökelpoisia. Testitapausten kehitys voi edetä rinnan toteutuksen kanssa lyhentäen projektin kokonaiskestoa. Toisaalta ilmeisenä haittana määrittelemätön käyttäytyminen jää todennäköisesti testaamatta, koska toiminnallinen testaus perustuu vain ohjelmiston toiminnalliseen määrittelyyn. Toiminnallisessa testauksessa saattaa esiintyä päällekkäisyyttä sekä aukkoja testitapausten välillä johtaen testaamattomaan ohjelmakoodiin. Seuraavaksi esitellään metodeita toiminnallisen testauksen testitapausten löytämiseen ja suunnitteluun. (Jorgensen, 2002) Ekvivalenssiosituksessa (equivalence partitioning, equivalence class testing) testitapaukset jaetaan ekvivalenssiluokkiin, jotka ohjelmiston oletetaan käsittelevän samalla tavalla. Yksinkertainen esimerkki ekvivalenssiluokista on lentokoneen ensimmäinen luokka ja turistiluokka tai ikkuna- ja käytäväpaikka. Käytetyt syötteet käsitellään samalla tavalla, ja ne tuottavat samanlaisen tuloksen, joten ekvivalenssiluokkia on kahta tyyppiä ohjelmistolle laillisia ja laittomia syötteitä tarjoavat ekvivalenssiluokat (valid equivalence class, invalid equivalence class). Oikein valituilla ekvivalenssiluokilla on mahdollista vähentää testitapausten määrää ja päällekkäisiä testejä. (Craig ja Jaskiel, 2002; Jorgensen, 2002; Myers, 2004) Raja-arvoanalyysissä (boundary value analysis) testauksen kohteena ovat syöteja ulostuloraja-arvot: minimiarvo, minimiarvoa seuraava arvo, maksimiarvo ja maksimiarvoa edeltävä arvo. Raja-arvotestien on todettu paikantavan virheitä 12

21 tehokkaasti, koska sen sijaan, että tutkittaisiin vain ekvivalenssiluokan edustajaarvo, tutkitaan yksi tai useampi ekvivalenssiluokan raja-arvo. (Craig ja Jaskiel, 2002; Jorgensen, 2002; Myers, 2004) Päätöstaulutestauksessa (decision table testing) pyritään täydelliseen syötteiden ja tulosteiden kombinaatiokattavuuteen. Päätöstauluihin listataan systemaattisesti syötteet, niiden tarkastussäännöt ja sääntöjen toteutumista vastaavat toiminnot. Testaus sopii ohjelmiin, joissa tehdään suuri määrä päätöksiä loogisesti toisiin liittyvien syötteiden kesken. Haittana testausmenetelmässa on suuri määrä syntyviä testitapauksia. Eräs vastaava menetelmä on nimeltään syy-seurausgraafitestaus (cause-effect graphing). (Craig ja Jaskiel, 2002; Jorgensen, 2002; Myers, 2004) Tilasiirtymätestauksessa (state-transition diagrams) testattava ohjelmisto pyritään mallintamaan tilasiirtymäkaavion avulla. Tulokseen vaikuttavat viimeisimmän testisyötteen lisäksi aikaisemmat testisyötteet, joiden tuottama tulos on ohjelmiston senhetkinen tila. (Craig ja Jaskiel, 2002) Ortogonaalinen taulukko (orthogonal array) on kaksiuloitteinen taulukko, jolla on eräs mielenkiintoinen matemaattinen piirre. Valitsemalla taulukosta kaksi saraketta saadaan kaikkien näissä sarakkeissa esiintyvien arvojen kombinaatiot, toisin sanoen kaikki mahdolliset parit. Taulukossa 2.1 on esitetty L 9 (3 4 ) ortogonaalinen taulukko, jossa luku 9 ilmoittaa rivien määrän, 4 sarakkeiden määrän, ja jokainen taulukon solu sisältää arvon 1, 2 tai 3. Valittaessa esimerkiksi sarakkeet 2 ja 4 saadaan kaikki parit (1,1), (1,2), (1,3), (2,1), (2,2), (2,3), (3,1), (3,2) ja (3,3). Kaikkia arvojen 1, 2 ja 3 sarakekombinaatioita, joita on yhteensä 81 kappaletta Taulukko 2.1: L 9 (3 4 ) ortogonaalinen taulukko (Craig ja Jaskiel, 2002)

22 (3x3x3x3), ei kuitenkaan esiinny. Usein testaustilanteissa on olemassa liian monta testitapausta toteutettavaksi ja suoritettavaksi. Parikombinaatio-ominaisuuden takia ortogonaalisia taulukoita voidaankin käyttää löytämään riittävän hyvä ja kattava testitapausten alijoukko kahdelle sarakkeen osoittamalle ominaisuudelle kaikkien sarakekombinaatioiden sijaan. Esimerkiksi verkkopalvelu, joka ajetaan usealla palvelimella (Apache, Internet Information Services, Netscape Enterprise), käyttöjärjestelmällä (Linux, Windows 2000, Windows NT), ja jota käytetään usealla selainohjelmalla (Firefox 1.0, Netscape 6.2, Internet Explorer 6.0) ja laajennossovelluksella (ei käytössä, RealPlayer, Windows Media Player), saadaan yhteentoimivuusmielessä testattua tehokkaasti pareittain kaikilta muuttujiltaan, vaikka kaikkia 81 kombinaatiota ei testatakaan. (Craig ja Jaskiel, 2002) Lähteestä riippuen eri englanninkielisillä nimillä esiintyvä virheiden arvaus (ad hoc testing, special value testing, error guessing) on ehkä yleisimmin käytetty, intuitiivisin ja epätäsmällisin toiminnallisen testauksen muoto. Siinä testaaja käyttää erityisosaamista tai kokemusta samantyyppisistä ohjelmista hyväkseen määritellessään testitapauksia. Hyvä esimerkki on kalenterisovelluksissa helmikuun 28. ja 29. päivä sekä karkausvuosi. (Craig ja Jaskiel, 2002; Jorgensen, 2002; Myers, 2004) Satunnaislukutestauksessa (random testing) voidaan valittavat arvot valita satunnaisesti raja-arvojen sijaan. Ongelmana on usein muun muassa valita kuinka monta testitapausta on riittävästi, ja mitkä ovat niiden oikeat tulokset. Nimitystä puolisatunnaislukutestaus (semi-random testing) voidaan käyttää useampaa arvoa testattaessa, kun ei haluta testata niiden kaikkia kombinaatioita arvojen ekvivalenssiluokista. Satunnaisyhdistelmiä on helppo valita, mutta niiden tarjoama toiminnallinen kattavuus on heikko. (Craig ja Jaskiel, 2002; Jorgensen, 2002) Tutkivassa testauksessa (exploratory testing) testitapauksia suunnitellaan ja suoritetaan samanaikaisesti. Testitapauksia ei valita satunnaisesti tai arvaillen, vaan testaajat käyttävät kokemustaan testauksen aikana paikantamaan tärkeitä kohteita. Testausmenetelmä on hyvä lisä systemaattisempien testausmenetelmien rinnalle riittävän ammattitaitoisten testaajien suorittamana. (Craig ja Jaskiel, 2002) 14

23 2.4.3 Rakenteellinen testaus Rakenteellisessa testauksessa, jota kutsutaan myös lasilaatikkotestaukseksi (whitebox, clear-box tai glass-box testing), testitapaukset suunnitellaan perustuen ohjelmiston toteutukseen. Rakenteellisessa testauksessa voidaan soveltaa muun muassa vahvoja teoreettisia menetelmiä, kuten graafiteoriaa. Menetelmien avulla saadaan tarkat testikattavuusmittaukset ohjelmistosta sekä testitapausten joukko optimaalisen pieneksi, mikä lisää testauksen mielekkyyttä. Rakenteellisen testauksen rajoite on, että testitapausten avulla on vaikea havaita ohjelmiston käyttäymistä, jota ei ole ohjelmoitu. Seuraavaksi esitellään metodeita rakenteellisen testauksen testitapausten löytämiseen ja suunnitteluun. (Craig ja Jaskiel, 2002; Jorgensen, 2002) Polkutestaus (path testing) ja kattavuustestaus (coverage testing) on johdettu matemaattisesta graafiteoriasta: ohjelmakoodi kuvataan suunnattuna graafina. Kattavuusmetriikat kertovat mitä testata ja onko testattu riittävästi. Lisäksi metriikoita voidaan käyttää toiminnallisen testauksen kanssa paikantamaan aukkoja jä päällekkäisyyksiä testeissä. Kattavuutta voidaan mitata muun muassa seuraavilta osin: lausekattavuus (statement coverage), päätöskattavuus (decision coverage), ehtokattavuus (condition coverage), päätösehtokattavuus (decisioncondition coverage), moniehtokattavuus (multiple-condition coverage). Thomas McCaben mutkikkuusmitta (cyclomatic complexity) mittaa ohjelmamoduulin kompleksisuuden ja maksimimäärän testitapauksille päätöskattavuuden saavuttamiseen. (Craig ja Jaskiel, 2002; Jorgensen, 2002) Tietovirtatestaus (data flow testing) ei nimestään huolimatta viittaa tietovirtatai tietovuokaavioihin (data flow diagram), vaan tarkoittaa testausta kohdissa, joissa muuttujat saavat arvoja, ja joissa muuttujien arvoja käytetään tai niihin viitataan. (Jorgensen, 2002) 2.5 Testauksen riittävyyden arviointi Testauksen ehkä suurin ongelma on sen lopettaminen, eli lopetuskriteeri hyväksymistestaukselle. Lopetuskriteerin täyttyminen tarkoittaa, että ohjelmistotuote on valmis toimitettavaksi ja käyttöönotettavaksi. Boris Beizer on todennut (Craig ja Jaskiel, 2002), että testauksen lopettamiselle ei ole olemassa yksittäis- 15

24 tä pätevää ja järkevää kriteeriä. Lisäksi minkä tahansa kriteerijoukon painotus riippuu vahvasti tuotteesta, ympäristöstä ja kulttuurista sekä riskiin suhtautumisesta. Jorgensen (2002) listaa muutamia mahdollisia vaihtoehtoja testauksen lopettamiselle: 1. Aika loppuu. 2. Testaus ei aiheuta uusia häiriöitä ohjelmiston ulkoisessa toiminnassa. 3. Testaus ei paljasta uusia virheitä ohjelmiston suorituksessa. 4. Testaaja ei keksi enää uusia testitapauksia. 5. Virheiden löytymisaste on pienentynyt. 6. Vaadittu kattavuus on saavutettu. 7. Kaikki virheet on löydetty. Listan viimeisintä kohtaa on mahdoton taata ja ensimmäinen on liian yleinen. On totta, että ajan tai muiden resurssien loppuminen on järkevä syy lopettaa testaus. Tällöin ohjelmistotuote voidaan julkaista siitä syystä, että huonolaatuinenkin tuote on kuitenkin parempi kuin mitä käyttäjillä sillä hetkellä on käytettävissään. Toinen syy voi olla, että riski virheellisen tuotteen julkistamatta jättämiseen on suurempi kuin liiketoimintariski, esimerkiksi riippuvuus muihin olemassa oleviin tuotteisiin tai kilpailutilanne. (Craig ja Jaskiel, 2002; Jorgensen, 2002) Kohdat 2-4 saattavat olla hyviä vaihtoehtoja, ja niitä on käytetty teollisuudessa menestyksekkäästi, erityisesti jos testitapausten suunnittelussa on käytetty muun muassa kohdassa 2.4 mainittuja menetelmiä. Toisaalta virheiden löytymättömyys on huono kriteeri, koska se on riippumaton testitapausten laadusta, ja se saattaa olla tuottamatonta, koska se helposti rohkaisee huono laatuisten testitapausten toteuttamiseen ja virheitä löytyvien, tuhoavien testitapausten välttämiseen. (Myers, 2004) Kohta 5 on melko hyvä vaihtoehto. Se vihjaa, että omistautunut testaus on jatkunut pidempään ja virheiden löytymisaste on vähentynyt selkeästi, jolloin tuote olisi valmis julkaistavaksi. Vaikka tämä on tyypillisesti hyvä merkki, täytyy kuitenkin muistaa, että esimerkiksi testauspanostuksen väheneminen tai uusien testitapausten puute saattavat vähentää virheiden löytymisastetta. Tämän takia 16

25 päätökset onkin hyvä perustaa useamman mitan varaan. Kuva 2.7 esittää virheiden löytymisastetta suhteessa testauksen kustannuksiin oletuksella, että testauspanostus on pysynyt vakiona. Julkaisuhetkeksi voidaan arvioida piste, jolloin testauksen kustannukset nousevat korkeammiksi kuin löydettyjen virheiden arvo. Tämän arvion tueksi tulisi myös tehdä riskiarviointia löydettyjen virheiden vakavuudesta. Jos laskevaa trendiä ei havaita sekä virheiden löytymisen asteessa että virheiden vakavuudessa, saattaa ohjelmistotuote olla kelvoton julkaistavaksi. (Craig ja Jaskiel, 2002) Kuva 2.7: Virheiden löytymisaste (Craig ja Jaskiel, 2002) Kohta 6 on myös hyvä testauksen lopettamisvaihtoehto. Rakenteellisen testauksen kattavuusmitat johtavat erityisesti hyviin tuloksiin yhdistettynä toiminnalliseen testaukseen. (Jorgensen, 2002) Ohjelmistotuotteen testauksen lopettamisen ja julkaisuhetken arviointi voidaan tehdä myös vertaamalla löydettyjen virheiden trendejä aikaisempien ohjelmistoprojektien vastaavien kanssa. Tämä tosin normaalisti vaatii merkittävän tietomäärän keräämistä ja käsittelyä sekä tietynlaista normalisointia, jotta projektien väliset erot, kuten laajuus ja vaikeusaste, otettaisiin huomioon. (Craig ja Jaskiel, 2002) 17

26 2.6 Testauksen ja testausohjelmistojen kehittäminen On itsestään selvää, että testaajat arvioivat ohjelmiston vaatimusten, suunnittelun ja toteutuksen tehneiden työtä. Kuka arvioi testaajien työtä? Joissakin yrityksissä on erillisiä laadunvarmistusyksiköitä, mutta lopulta asiakas tai loppukäyttäjä tekee arvion testaajien työn laadusta. On tärkeää huomata, että henkinen panostus ohjelmiston testaukseen on usein lähes yhtä suuri kuin ohjelmiston toteutukseen vaadittu, ja siksi testaajien työtä sekä testausohjelmistojen laatua tulisi arvioida. (Craig ja Jaskiel, 2002) Testauksen laatua voidaan arvioida esimerkiksi ohjelmistoprojektin jälkeen. Mitattavia asioita ovat muun muassa testauksen kattavuus ja virheiden tunnistustehokkuus. Yleisesti testausohjelmistoja voidaan arvioida samoilla menetelmillä, joita käytetään ohjelmistojen testaukseen. Katselmoinneilla, joissa tulisi olla mukana muitakin kuin testausryhmän jäseniä, kuten loppukäyttäjiä ja ohjelmistokehittäjiä, voidaan tarkistaa testaussuunnitelmat ja testitapaukset. Testitapaukset voidaan suorittaa ohjelmiston vanhemmilla versioilla, jolloin osa testitapauksista menee läpi samojen ohjelmisto-ominaisuuksien takia ja osa epäonnistuu eroavaisuuksien takia. Testitapausten jäljitettävyyttä (traceability) tulisi myös arvioida, eli jokaisen testitapauksen tulisi voida kuvautua ohjelmiston vaatimuksiin, suunnitteluun tai toteutukseen. Testausohjelmistoja voidaan testata myös virheiden kylvön (defect seeding) avulla. Tällöin testattavaan ohjelmistoon kylvetään virheitä, minkä jälkeen mitataan löydetyt ja löytymättömät kylvetyt virheet sekä uudet kylvämättömät virheet. Menetelmän ongelmana on se, että kylvetyt virheet vastaavat harvoin tosielämän virheitä, ja että yrityksillä ei ole usein aikaa ja resursseja käyttää menetelmää. (Craig ja Jaskiel, 2002) 18

27 3 Ohjelmistotestauksen automatisointi 3.1 Johdanto Ohjelmistotestausta voidaan automatisoida monella tasolla. Yksinkertaisimmillaan automatisointi kohdistuu yksittäiseen testitapaukseen, mikä automatisoi lähinnä sen suorittamisen ja saadun tuloksen vertailun odotettuun tulokseen. Vastakohtana on kokonaan automatisoitu testaus, jossa testiympäristö huolehtii testitapausten alustamisesta, suorittamisesta ja tulosten analysoinnista. Kuva 3.1 selventää tätä eroa. Automatisoidusta testauksesta puhuttaessa tarkoitetaan useimmiten jotakin näiden kahden ääripään väliltä, kuitenkin niin että liikutaan lähempänä jälkimmäistä. (Craig ja Jaskiel, 2002; Fewster ja Graham, 1999) Kuva 3.1: Automatisoitujen testien ja automatisoidun testauksen ero (Fewster ja Graham, 1999) 19

28 Kuten edellä todettiin, tarve testauksen automatisoinnille syntyy useimmiten silloin, kun resurssit eivät riitä manuaaliseen testaukseen. Tämä tilanne on syntynyt pitkälti nopean sovelluskehityksen (rapid application development, RAD) myötä. Nopeaan sovelluskehitykseen liittyy olennaisesti käännösten runsas määrä, ja kun jokaisessa käännöksessä on tehty muutoksia ohjelmakoodiin, tulee kaikki käännökset testata. Ilman automatisointia tämä olisi käytännössä mahdotonta. (Dustin et al., 1999) Ohjelmistotestauksen automatisointiin on kehitetty useita malleja (esimerkiksi Craig ja Jaskiel (2002); Dustin et al. (1999); Pol et al. (2002)), joista osa pohjautuu perinteisiin testausmalleihin. Useimmat mallit ovat kuitenkin jääneet melko tuntemattomiksi, sillä ne sopivat harvoin sellaisenaan käytäntöön. Useimmiten automatisointi aloitetaan manuaalisessa testauksessa käytettyjen mallien ja prosessien pohjalta. (Mosley ja Posey, 2002) 3.2 Mitä ja milloin automatisoida Ensisijaiset ehdokkaat Ohjelmistotestauksen automatisoinnin onnistumisen tärkein kriteeri on löytää oikeat testit automatisoitaviksi. Tämä ei kuitenkaan pelkästään riitä, sillä automatisointi ei välttämättä ole kannattavaa, vaikka sopivia kohteita löytyisikin. Testaus tulee automatisoida ainoastaan silloin, kun se edesauttaa testauksen tavoitteiden saavuttamista. Mosley ja Posey (2002) kehottavat automatisoimaan kaiken, mikä on järkevää. Valitettavasti järkevyyden selvittämiseen ei löydy yhtä oikeaa ratkaisua, vaan sitä on tutkittava jokaisessa projektissa uudelleen. Arviointikyky kasvaa kokemuksen myötä ja arviointistrategian kehittäminen auttaa päätöksenteossa. (Kaner et al., 2002; Mosley ja Posey, 2002) Testauksen automatisointi tai sen kannattavuus ei ole erityisesti sidoksissa testauksen eri tasoihin. Ensisijaisia ehdokkaita automatisointiin ovat usein toistetut testit, kuten regressio- ja savutestit (alakohta 3.2.2), riippumatta siitä millä tasolla niitä suoritetaan (kuva 3.2). Muita hyviä kohteita ovat tyypillisesti stressi-, suorituskyky-, kuormitus- ja luotettavuustestit (alakohdat ja 3.2.4). (Craig ja Jaskiel, 2002; Mosley ja Posey, 2002) 20

29 Kuva 3.2: Ensisijaiset ehdokkaat automatisointiin (Craig ja Jaskiel, 2002) Automatisointi aloitetaan testaustyypistä riippumatta tärkeimpien ominaisuuksien ja toimintojen testauksesta, aivan kuten manuaalisesti testattaessakin. Testattavien kohteiden määrää kasvatetaan tasaisesti resurssien niin salliessa, mutta vain tarpeen olessa todellinen. Automatisointiprosessin aikana on tärkeää muistaa pitää mielessä, että kaikkea ei voi eikä kannata automatisoida. (Fewster, 2001; Mosley ja Posey, 2002) Regressio- ja savutestaus Regressiotestaus (regression testing) koostuu testitapauksista, joiden tarkoituksena on taata, että ominaisuudet, jotka toimivat virheettömästi edellisessä käännöksessä, toimivat myös uudessa käännöksessä virhekorjausten ja uusien ominaisuuksien lisäyksen jälkeen. Regressiotestausta tehdään kaikilla testauksen tasoilla. (Craig ja Jaskiel, 2002; Jorgensen, 2002) Savutestauksen (smoke testing) testitapausten tehtävänä on osoittaa, että ohjelmisto on vakaa, ja että kaikki päätoiminnallisuudet toimivat normaaleissa olosuhteissa. Testitapausten tehtävä ei ole löytää virheitä, vaan kertoa järjestelmätestausryhmälle mikä on lähtökohta testaukselle. Savutestauksella autetaan myös ohjelmistokehitystä, sillä sen testitapaukset määrittävät jonkinlaisen tavoitetason ohjelmiston vakaudelle. Savutestitapausten tulisi kattaa testattavat ominai- 21

30 suudet laaja-alaisesti, mutta ei välttämättä syvällisesti. Ideaalisti ne voisivat olla osa regressiotestauksen testitapauksista. (Craig ja Jaskiel, 2002) Automatisointi on suosituinta regressio- ja savutestauksen kohdalla (katso esimerkiksi Craig ja Jaskiel (2002); Dustin et al. (1999); Kaner et al. (2002)). Nämä testaustyypit soveltuvat luonteensa puolesta erittäin hyvin automatisoitavaksi, sillä kumpaakin toistetaan usein, ja kumpikin vaatii suhteellisen vähän ylläpitoa. Useimmiten testausprosessi aloitetaan automatisoimalla molemmat tai ainakin toinen mainituista testaustyypeistä. Tuotannon alkuvaiheessa, sekä moduuli- ja integrointitestauksessa usein toistuvat käännökset ovat kätevä työkalu laadunvalvontaan. Tuotannon loppuvaiheessa regressiotestauksen tarvitsema aika saattaa kuitenkin olla liian suuri verrattuna julkaistavan tuotteen tarvitsemaan muuhun testaukseen. Täten regressiotestaus soveltuukin automatisoitavaksi käännösten yhteyteen. Regressiotestaus on kuitenkin vaikeaa, jos testattava ohjelmisto ja testitapaukset ovat epävakaita ja muuttuvat usein. Tästä syystä on käytännöllistä luoda siirtymäkriteerit julkaisuiden välille moduuli- ja integrointitestauksesta järjestelmätestaukseen sekä järjestelmätestauksesta hyväksymistestaukseen. Siirtymäkriteerin määrittelyssä voidaan käyttää savutestejä. (Craig ja Jaskiel, 2002) Regressio- ja savutestauksen automatisoinnin tarjoamat hyödyt ovat huomattavia, ja ne saavutetaan nopeasti. Ohjelmistokäännöksen perustoiminnallisuuksien testaaminen automaattisesti säästää huomattavasti aikaa ja rahaa, sillä ohjelmistokäännöstä ei päästetä muuhun testaukseen, ennen kuin regressio- ja savutestit on suoritettu onnistuneesti. Molempien testaustyyppien kiinnostavuutta automatisoinnin kohteiksi lisää se, että ne ovat huomattavan tärkeitä ohjelmistokehityksen kannalta. Erityisesti regressiotestaukselle on tarvetta, sillä muutosten tekeminen ohjelmistoon aiheuttaa helpommin virheitä kuin uuden ohjelmiston kirjoittaminen. Tällöin tarvitaan helposti käyttöönotettavaa mekanismia, jolla voidaan varmistaa, ettei jo toimiva ohjelmisto mene epäkuntoon kehitystyön aikana. (Craig ja Jaskiel, 2002; Mosley ja Posey, 2002; Myers, 2004) 22

31 3.2.3 Stressi- ja kuormitustestaus Stressi- ja kuormitustestauksessa tarkoituksena on tutkia ohjelmiston toimintaa kuorman alla. Eroavaisuutena tyypeillä on se, että stressitestauksessa kuormaa lisätään vähitellen, kun taas kuormitustestauksessa kuorma nostetaan suoraan korkeaksi. Stressi- ja kuormitustestaus automatisoidaan useimmiten siksi, että niiden suorittaminen manuaalisesti on liian työlästä. Näiden testaustyyppien automatisointiin käytetään sekä kaupallisia että itse toteutettuja työkaluja. (Mosley ja Posey, 2002) Toisena yleisenä perusteena näiden testien automatisoinnille ovat manuaalisessa suorituksessa ilmenevät toistettavuusongelmat. Manuaalisessa testauksessa ei useimmiten voida toistaa jotakin toimintosarjaa täsmälleen samalla tavalla uudestaan. Toistettavuus on kuitenkin tärkeää stressi- ja kuormitustestauksessa, sillä niissä löytyvät virheet ovat usein vaikeita paikallistaa. Automatisointi vähentää yleensä merkittävästi toistettavuusongelmia. (Hedge et al., 2002) Suorituskyky- ja luotettavuustestaus Suorituskyky- ja luotettavuustestauksen suosio automaation kohteina pohjautuu perimmiltään samaan seikkaan kuin stressi- ja kuormitustestauksenkin ne ovat liian työläitä manuaalisesti suoritettaviksi, vaikka ne tyypillisesti suoritetaankin harvakseltaan. Suosiota kasvattaa myös mahdollisuus käyttää stressitestaustyökaluja etenkin suorituskykytestauksen osana. Suorituskykyä ja luotettavuutta testattaessa järjestelmää yleensä kuormitetaan samalla, jolloin näiden testityyppien automatisointi on luonnollinen jatke stressi- ja kuormitustestauksen automatisoinnille. (Dustin et al., 1999; Mosley ja Posey, 2002) 3.3 Automatisointi testauksen eri tasoilla Ohjelmistotestauksen tasot eivät yleensä ole pohjana testauksen automatisoinnille, mutta testitapaukset kehitetään niiden mukaan. Automatisoidussa testauksessa testitapausjoukot koostuvat loogisesti ja toiminnallisesti yhteensopivista testitapauksista riippumatta siitä, mille tasolle ne on kohdennettu. 23

32 3.3.1 Yksikkötestaus Automatisoitu yksikkötestaus on nykyään lähes välttämättömyys, jotta ohjelmistokehitys pysyy aikataulussaan. Yksikkötestaus soveltuukin hyvin automatisoitavaksi. Yksikkötestejä voidaan lisäksi suorittaa regressio- ja savutestauksen osana. (Kaner et al., 2002; Mosley ja Posey, 2002) Yksikkötestauksen automatisointiin ei yleensä kannata toteuttaa omaa järjestelmää. Valmiita testausjärjestelmiä, niin kaupallisia kuin ilmaisiakin, on olemassa useille ohjelmointikielille. Testausjärjestelmät ovat monipuolisia ja helposti käyttöönotettavia. Ohjelmistokehittäjä kirjoittaa testitapaukset samalla ohjelmointikielellä kuin itse ohjelmistonkin, ja testitapaukset suoritetaan valitun testausjärjestelmän avulla. Joissakin testausjärjestelmissä testitapauksetkin voidaan enimmäkseen luoda järjestelmän avulla. Manuaalisessa testauksessa tynkien ja ajureiden toteuttaminen vaatisi runsaasti ohjelmointityötä, mistä johtuen yksikkötestauksen suorittaminen jää usein vähäiseksi. Automaattinen testausjärjestelmä suorittaa testitapaukset huomioiden niiden oman ympäristön, jolloin tynkiä ja ajureita ei tarvita. (Dustin et al., 1999; Kaner et al., 2002; Mosley ja Posey, 2002) Yksikkötestaus kannattaa automatisoida jo pelkästään sen vuoksi, että löytyneen virheen aiheuttamat kustannukset kohoavat huomattavasti mitä myöhäisemmässä vaiheessa se havaitaan. Tästä syystä testattavien moduulien tulisi läpäistä kaikki yksikkötestit ennen kuin moduuleja päästetään eteenpäin integroitavaksi. (Mosley ja Posey, 2002) Integrointitestaus Integrointitestauksen automatisoinnin perusteet ovat pitkälti samat kuin yksikkötestauksenkin ja sen automatisointia pidetään vähintäänkin yhtä tärkeänä. Integrointitestaus automatisoidaan useimmiten savutestauksen osana. Automatisointia ajatellen integrointitestauksella on vahva side yksikkötestauksen kanssa. Integrointitestaus todennäköisesti epäonnistuu, mikäli yksikkötestaus on suoritettu huolimattomasti tai jätetty kokonaan suorittamatta. (Mosley ja Posey, 2002; Pol et al., 2002) 24

33 Integrointi- ja yksikkötestaus ovat yleensä ohjelmistokehittäjien vastuulla. Mikäli niitä ei ole automatisoitu, niillä on taipumus jäädä suorittamatta kokonaan. Tästä seuraa ongelmia varsinaisille testaajille, sillä testattavaksi tulevat käännökset eivät välttämättä toimi lainkaan. Tällöin testaushenkilöstö joutuu suorittamaan yksikkö- ja integrointitestauksen selvittääkseen vikalähteen. Ylimääräinen testaus vaikeuttaa todennäköisesti jo muutenkin kireän aikataulun toteutumista. (Kaner et al., 2002; Mosley ja Posey, 2002) Järjestelmätestaus Järjestelmätestaus on, edellisten tasojen tärkeydestä huolimatta, suosituin kohde automatisoinnille. Se automatisoidaan useimmiten regressiotestauksena, mutta myös stressi-, kuormitus-, suorituskyky- ja luotettavuustestauksessa käytetään enimmäkseen järjestelmätestaustason testitapauksia. Nämä testaustyypit on esitelty tarkemmin kohdassa 3.2. (Mosley ja Posey, 2002) Järjestelmätestaus on yleensä vaativin testaustaso. Tällä tasolla löytyvät virheet eivät ole välttämättä mitättömiä, jolloin testaajilta voi kulua runsaasti aikaa pelkästään testien suorittamiseen. Koska testauksen pääpaino on useimmiten järjestelmätestauksessa ja koska järjestelmätestaus vaatii usein odottamattoman paljon aikaa, se kannattaa automatisoida niiltä osin kuin se on mahdollista. Järjestelmätestauksenkin automatisointiin on olemassa valmiita työkaluja, mutta on tavallista toteuttaa testitapaukset tällä tasolla itsekin. (Craig ja Jaskiel, 2002; Dustin et al., 1999) Hyväksymistestaus Hyväksymistestaus (alakohta 2.3.4) soveltuu määritelmänsä puolesta automatisoitavaksi hyvin harvoin. Hyväksymistestaus tapahtuu normaalisti ympäristössä, jossa suoritusta ei voida kontrolloida, ja sen vuoksi automatisointi on mahdotonta. Se voidaan kuitenkin joskus automatisoida suljetussa ympäristössä järjestelmätestauksessa käytettyjä testitapauksia hyödyntäen. Hyväksymistestauksen automatisointi ei kuitenkaan ole yleensä järkevää, sillä kyseinen testaus suoritetaan korkeintaan muutaman kerran. (Dustin et al., 1999) 25

34 3.4 Automatisoinnin hyödyt Automatisoinnista on hyötyä vain, jos sillä saavutetaan etuja verrattuna manuaaliseen toimintamalliin. Tämä koskee myös ohjelmistotestauksen automatisointia. Automatisoinnin tuomia hyötyjä on helppo keksiä runsain määrin, mutta niiden toteutuminen ei aina ole itsestäänselvää. Dustin et al. (1999) mukaan automatisoinnista saatavat hyödyt voidaan jakaa kolmeen ryhmään: ohjelmiston luotettavuuden paranemiseen, testauksen laadun paranemiseen sekä käytettävien resurssien tarpeen vähenemiseen Ohjelmiston luotettavuuden paraneminen Ohjelmistotestauksen automatisointi vaikuttaa positiivisesti testattavan ohjelmiston luotettavuuteen, mikä on havaittavissa jo ohjelmiston määrittelyvaiheessa. Testauksen ja erityisesti testauksen automatisoinnin suunnittelu ei onnistu epämääräisien ohjelmistovaatimusten avulla. Tämä johtaa tarkentuneeseen määrittelydokumenttiin (niin sanotut testausvalmiit vaatimukset), josta on puolestaan apua ohjelmistokehitystyön kaikissa myöhemmissä vaiheissa. (Dustin et al., 1999) Automatisoidusta testauksesta saadaan kerättyä manuaalista testausta luotettavampia laatumetriikoita. Erilaisten laatumetriikoiden tarkkailu ja niiden pohjalta tehty toiminnanohjaus parantavat ohjelmistotuotantoprosessin käytäntöjen laatua, mistä seuraa toteutettavien ohjelmistojen laadun ja luotettavuuden paraneminen. (Dustin et al., 1999) Testauksen laadun paraneminen Automatisoimalla voidaan testata myös asioita, joita ei voida testata manuaalisesti tai jotka vaativuutensa vuoksi jäisivät testaamatta. Dustin et al. (1999) mainitsevat esimerkkeinä muun muassa stressi-, suorituskyky- ja kuormitustestaukset. Erityisesti monen käyttäjän toiminnan simulointi onnistuu automatisoimalla huomattavasti pienemmällä vaivalla kuin manuaalisesti. Myöskään staattisen analyysin menetelmiä ei voida suorittaa manuaalisesti. Tällaisia ovat esimerkiksi moniehtokattavuuden tutkiminen tai monimutkaisuuden (cyclomatic complexity, 26

35 McCaben metriikka) mittaaminen. (Dustin et al., 1999) Testauksen laadun paranemiseen liittyy myös testaukseen käytetty aika. Vaikka automatisoinnilla pyritään vähentämään testaukseen käytettyä työaikaa, varsinainen testausaika usein lisääntyy automatisoinnin myötä. Kun testaus on automatisoitua, sitä voidaan suorittaa myös työajan ulkopuolella. Testaajat voivat lisäksi suorittaa manuaalista testausta samalla, kun automatisoidut testit ovat suoritettavana. (Dustin et al., 1999) Käytettävien resurssien tarpeen väheneminen Testaukseen käytettävien resurssien vähenemistä tai niiden vapauttamista muuhun käyttöön sekä testaukseen käytettävän ajan lyhenemistä pidetään usein jopa tärkeimpänä perusteena ohjelmistotestauksen automatisoinnille. Automatisoimalla testausta säästetään sekä henkisiä että aineellisia resursseja. Ohjelmistotestaus manuaalisesti suoritettuna ei testaajan kannalta ole useimmitenkaan erityisen motivoivaa. Samojen testien suorittaminen yhä uudelleen vähentää testaushenkilöstön mielenkiintoa, mikä johtaa testauksen laadun heikkenemiseen ja sitä kautta kohonneisiin työnantajan kustannuksiin. Tilannetta parantaa jo yksinkertaisimpien testitapausten suorituksen automatisointi, mikä jättää vain haasteellisemmat testitapaukset testaajalle manuaalisesti suoritettavaksi. (Dustin et al., 1999; Myers, 2004) Automatisointi tarjoaa myös mahdollisuuden parantaa ohjelmistokehittäjien ja testaajien välejä. Ohjelmistokehittäjät ovat perinteisesti pitäneet testaustyötä arvottomampana ja helpompana kuin ohjelmistokehitystyötä ja siksi suhtautuneet testaukseen negatiivisesti. Automatisointi kuitenkin vaatii testaajilta samanlaista ohjelmistoteknistä osaamista kuin kehittäjilläkin on, ja usein se pakottaa testaajat ja kehittäjät yhteistyöhön. Molemminpuolinen arvostus lisääntyy ja turhaan byrokratiaan kuluva aika vähenee henkilöiden ymmärtäessä toistensa tehtävät ja kokiessa olevansa työtovereita. (Dustin et al., 1999; Kaner et al., 2002; Pol et al., 2002) Aineellisista resursseista ehkä tärkeimpänä säästyy rahaa. Rahallisia säästöjä kertyy pienentyneistä henkilöstökuluista, mikä on seurasta testaukseen käytetyn työajan vähenemisestä. Quality Assurance Instituten suorittamassa tutkimuksessa testauksen automatisoinnilla saavutettiin parhaimmillaan 95 prosentin 27

36 ajansäästö verrattuna testien suorittamiseen manuaalisesti. Kun huomioon otettiin kaikki testausaktiviteetit testien suunnittelemisesta aina tulosten raportointiin, saatiin kokonaistulokseksi 75 prosentin ajallinen säästö. Ainoastaan testien suunnitteluun käytetty aika kasvoi automatisoinnin myötä. (Dustin et al., 1999) 3.5 Automatisoinnin haasteet Ohjelmistotestauksen automatisoinnista saatavat hyödyt ovat melko ilmeisiä, mistä johtuen niitä käsitellään alan kirjallisuudessa vähänlaisesti. Hyötyjä tavoiteltaessa vastaan tulee kuitenkin monenlaisia haasteita, jotka saattavat tehdä automatisointityöstä kannattamatonta ellei niihin ole osattu varautua. Näitä ovat muun muassa väärät odotukset, automatisoinnin kustannukset sekä lisätyö Väärät odotukset Tietotekniikka-alalla työskentelevillä on taipumus pitää jokaista uutta teknologiaa ja toimintamallia kaikenkattavana ratkaisuna ongelmiin (Fewster ja Graham, 1999). Tämä pätee myös ohjelmistotestauksen automatisoinnissa, minkä vuoksi väärät odotukset, etenkin korkeamman johtotason keskuudessa, on yksi suurimpia haasteita. (Dustin et al., 1999) Automatisointiprosessin alussa odotetaan usein välittömiä rahallisia säästöjä, testaukseen käytetyn ajan lyhentymistä ja löydettyjen virheiden määrän kasvamista. Todellisuudessa automatisoinnin hyödyt tulevat kuitenkin esiin vasta ajan myötä. Testauksen automatisointi maksaa, ja siihen kuluu moninkertaisesti se aika, joka olisi kulunut manuaaliseen testaukseen. Testausta automatisoitaessa joudutaan suorittamaan samat tehtävät kuin manuaalisessakin testauksessa, minkä seurauksena virheitä löytyy eniten automatisoinnin kehitysaikana. Tästä johtuen löydettyjen virheiden määrä pienenee, kun automatisoitujen testien varsinainen suorittaminen aloitetaan. (Dustin et al., 1999; Mosley ja Posey, 2002) Vääriä odotuksia liittyy myös valmiiden testiautomaatiojärjestelmien käyttöönottoon. Uusien työkalujen käyttöönotosta päättävät usein tahot, jotka eivät tule olemaan tekemisissä niiden kanssa. Testaushenkilöstö saattaa kuvitella työkalujen huolehtivan kaikesta aina testien suunnittelusta niiden suorittamiseen. Virheellisten odotusten vuoksi aikatauluja saatetaan kiristää ja testausresursseja 28

37 vähentää heti, kun uusi järjestelmä on hankittu. Työkalujen käyttöönotto vaatii kuitenkin aikaa ja niistä saatava ajallinen hyöty tulee näkyviin vasta, kun työkalut on otettu onnistuneesti käyttöön. (Dustin et al., 1999) Kustannukset ja niiden saaminen takaisin Eräs testauksen automatisoinnin tavoitteista on usein kustannussäästöjen aikaansaaminen. Huolimatta siitä, että sitä pidetään usein virheellisenä lähtökohtana (katso esimerkiksi Kaner et al. (2002)), kustannukset ja niiden takaisin saaminen ovat merkittävä seikka automatisointiprosessissa. Kustannukset tulisi arvioida huolellisesti etukäteen, jotta voidaan tehdä perusteltu päätös automatisointiprosessin aloittamisesta tai aloittamatta jättämisestä (Fewster ja Graham, 1999). Kustannuksia syntyy automatisointiprosessissa lähinnä henkilöstökuluista sekä tarvittavista laitteistoista, ohjelmistoista ja muista hankinnoista. Hankintojen kustannukset ovat yleensä hyvin ennustettavissa olevia ja kertaluontoisia, mutta henkilöstökulujen arviointi on jo huomattavasti vaikeampaa. Henkilöstökuluja kertyy paitsi itse automatisointityöhön käytetystä ajasta, myös taustatyöstä, koulutuksesta, ylläpidosta ja muista oheistoiminnoista. (Dustin et al., 1999; Fewster ja Graham, 1999; Kaner et al., 2002) Kustannusten takaisin saamisessa onnistuminen riippuu pitkälti siitä, onko valittu oikeat asiat automatisoitaviksi (kohta 3.2). Helpointa kustannusten takaisin saaminen on niistä manuaalisesti suoritettavista testeistä tai testijoukoista, joita uudelleensuoritetaan usein (esimerkiksi regressio- ja savutestit). Kaner et al. (2002) tosin muistuttavat, että tällaisissa tapauksissa säästöä kertyy vain, jos testaus todella olisi suoritettu yhtä monta kertaa manuaalisesti. Selvää rahallista säästöä kertyy myös pidemmällä tarkkailujaksolla. Parantamalla testauksen laatua löydetään enemmän virheitä, jolloin niitä ei jouduta korjaamaan lopputuotteen julkistamisen jälkeen. (Fewster ja Graham, 1999; Myers, 2004) Rahallisten säästöjen lisäksi testauksen automatisoinnista seuraa usein välillisiä säästöjä, joita on hyvin hankala mitata. Tällaisia ovat esimerkiksi testaushenkilöstön motivaation paraneminen, tuottavuuden lisääntyminen ja yrityskuvan paraneminen asiakaskunnan keskuudessa. Mainitun kaltaiset hyödyt tulisi pyrkiä huomiomaan automatisoinnin kustannusvaikutuksia mietittäessä, vaikka niitä ei laskelmiin selvinä lukuina saadakaan. (Fewster ja Graham, 1999) 29

38 3.5.3 Lisätyö Testauksen automatisointi vaatii aikaa ja vaivaa. Vaikka testitapaukset olisivat hyvin suunniteltuja ja osin toteutettujakin, niiden automatisointi kestää pidempään kuin testien manuaalinen suorittaminen. Mosley ja Posey (2002) esittävät, että yksittäisen testitapauksen automatisointi kestää keskimäärin kolmesta neljään kertaa niin kauan kuin sen suorittaminen manuaalisesti, Kaner et al. (2002) puolestaan arvioivat sen kestävän jopa kymmenen kertaa kauemmin. Tästä syystä kannattaa yleensä automatisoida vain sellaisia testitapauksia, jotka suoritetaan useita kertoja ja joiden automatisointiin kuluu vähemmän aikaa kuin niiden manuaaliseen suorittamiseen yhteensä. (Craig ja Jaskiel, 2002; Dustin et al., 1999; Fewster ja Graham, 1999) Testauksen automatisoinnin vaatima lisätyö on kuitenkin yleensä vähäisempää kuin automatisoitujen testien ylläpitoon käytettävä työmäärä. Automatisoidut testit ja testausjärjestelmät ovat ohjelmistoja itsessään niistä löytyy virheitä ja niitä joudutaan muuttamaan vastaamaan testattavaa ohjelmistoa. On tavallista, että ohjelmiston ominaisuudet ja toiminnallisuudet muotoutuvat vasta kehitysvaiheessa, jolloin automatisoitujen testien ylläpidosta voi tulla lähes täyspäiväistä työtä. (Mosley ja Posey, 2002) Testattavan ohjelmiston ominaisuuksien muuttuessa automatisoituja testejä täytyy korjata, jotta ne toimisivat muuttuneen ohjelmiston kanssa. Ylläpitokulut ovat tyypillisesti suuremmat kuin manuaalisen testauksen tapauksessa, sillä manuaalisessa testauksessa testaaja voi useimmiten muuttaa testitapausta muutostarpeen huomattuaan. Automatisoitu testi taas ei kykene mukautumaan muuttuneeseen ympäristöön ja toimii mahdollisesti väärin. (Fewster ja Graham, 1999) Rajoitteet Automatisoitu testaus ei ratkaise kaikkia ongelmia eikä löydä kaikkia virheitä. Kaikkia testitapauksia ei kannata, tai edes voi, automatisoida (Dustin et al., 1999; Kaner et al., 2002). Mosley ja Posey (2002) arvioivat käytännön kokemukseen perustuen, että noin 60 prosenttia testauksesta on ylipäänsä automatisoitavissa. Testauksen automatisointia suunniteltaessa on huomioitava myös työkalujen rajoitteet. Tällä hetkellä ei ole olemassa, ja Dustin et al. (1999) mukaan mitä to- 30

39 dennäköisimmin ei tule koskaan olemaankaan, sellaista testiautomaatiojärjestelmää, joka toimisi kaikilla alustoilla ja joka suoriutuisi kaikenlaisesta testauksesta. Testausprojekteissa joudutaan väistämättä hankkimaan tai toteuttamaan useita testiautomaatiojärjestelmiä tai automatisoituja testejä. (Dustin et al., 1999) Muut ongelmat Ohjelmistotestauksen automatisointiin liittyy edellä mainittujen haasteiden lisäksi lukuisia muitakin mahdollisia sudenkuoppia. Mahdollisia ongelmakohtia löytyy jokaiselta tasolta, niin työkaluista kuin henkilöstöstäkin. Suunnittelun merkitystä testauksen automatisoinnissa ei voi korostaa liikaa. Huolellisesti suunnittelemalla voidaan välttää suurimmat ongelmakohdat ja saadaan kehitettyä testejä, joita tullaan suorittamaan useamminkin kuin kerran. Dustin et al. (1999) kertovat, että huonosti suunniteltu automatisointi voi nostaa kustannuksia jopa 150 prosenttia verrattuna siihen, että testaus olisi suoritettu kokonaan manuaalisesti. Automatisoimalla mahdollisimman paljon mahdollisimman lyhyessä ajassa ajaudutaan helposti tilanteeseen, jossa kustannuksia ei saada koskaan takaisin. (Craig ja Jaskiel, 2002; Myers, 2004) 3.6 Tulosten analysointi automaattisesti Tulosten analysointi suoritetaan yleensä automaattisesti jo automatisoitujen testien tapauksessa, ja automaattiseen testaukseen se kuuluu olennaisesti. Tuloksia tutkitaan kuitenkin edelleen manuaalisestikin useimmiten siksi, että automaattisen analysoinnin toteuttaminen olisi työlästä. (Mosley ja Posey, 2002) Testaustulosten analysointi automaattisesti vaatii aina odotettua tulosta, johon todellista tulosta verrataan 1. Odotettu tulos saadaan useimmiten joko ohjelmiston määrittelydokumentista tai testin aiemman suorituskerran tuloksesta. Jälkimmäisessäkin tapauksessa odotetun tuloksen tulisi luonnollisesti vastata määrittelydokumenttia. Hyväksymispäätöksen tekemisen avuksi tarvitaan lisäksi hyväksymiskriteerit (pass/fail criteria), jotka määritellään kunkin testaustason testaussuunnitelmassa. Hyväksymiskriteerinä käytetään yleensä odotettua tulosta, 1 On mahdollista toteuttaa älykkäitä järjestelmiä, jotka analysoivat tulokset ilman vertailutulosta. Tällaiset järjestelmät ovat kuitenkin harvinaisia. 31

40 mutta toisinaan odotetusta tuloksesta sallitaan poikkeamia. (Craig ja Jaskiel, 2002; Mosley ja Posey, 2002) Automaattinen tulosten vertailu suoritetaan joko testitapauksen suorituksen yhteydessä (dynamic comparison, dynaaminen vertailu) tai sen jälkeen (post-execution comparison). Dynaamista vertailua tuetaan kaupallisissa ohjelmistoissa, mistä johtuen sitä arvioidaan käytettävän enemmän. Sen etuihin luetaan mahdollisuus ohjata testitapauksen suoritusta sekä se, ettei kaikkia tulosteita tarvitse tallentaa, mistä johtuen sitä käytetään paljon käyttöliittymätestauksessa. Dynaamisen vertailun haittapuolina ovat testiskriptien monimutkaisuus sekä ongelmien hankalampi jäljitettävyys. (Fewster ja Graham, 1999) Jälkikäteen suoritettava vertailu, jonka eri toteutusvaihtoehdot on esitetty kuvassa 3.3, tarjoaa joitakin merkittäviä etuja dynaamiseen vertailuun nähden, vaikka sen käyttö ei olekaan yhtä suosittua. Jälkikäteen vertailu voidaan suorittaa monipuolisemmin, kun testien tulosteet ja muu data ovat käytettävissä kerralla. Tämä mahdollistaa useiden ohjelmistojen käyttämisen vertailuun sekä helpottaa Kuva 3.3: Jälkikäteen suoritettavan vertailun toteutusvaihtoehtoja: (a) erillinen testijärjestelmä suorittaa vertailun testitapauksen suorituksen jälkeen; (b) testit suorittava testijärjestelmä suorittaa myös vertailun; (c) ja (d) jompi kumpi testijärjestelmistä tarjoaa yhtenäisen tavan sekä testitapauksen että vertailun suorittamiseen. (Fewster ja Graham, 1999) 32

41 virheiden jäljitettävyyttä. Jälkikäteen suoritettava vertailu ei myöskään vaadi merkittävästi ylimääräistä laskentatehoa testitapauksen suorituksen aikana eikä siten häiritse testattavan ohjelmiston toimintaa. Tämä vertailumenetelmä on myös helpompi yhdistää olemassa oleviin testiautomaatiojärjestelmiin. (Fewster ja Graham, 1999) Vertailuun voidaan käyttää myös suodattimia tai muuntimia, joiden avulla muunnetaan sekä odotetut että todelliset tulokset yhtenevään muotoon. Tällä menetelmällä voidaan helpommin toteuttaa yleiskäyttöisiä ohjelmistoja tulosten analysointiin. Kuva 3.4 selventää muuntimen käyttöperiaatetta. (Fewster ja Graham, 1999) Kuva 3.4: Tulosten vertailu muuntimen avulla (Fewster ja Graham, 1999) Multimediaelementtien vertailu on huomattavasti tekstimuotoisen datan vertailua monimutkaisempaa. Suurimmat haasteet syntyvät siitä, että multimediaelementeissä pienet virheet ovat sallittavia. Ei ole mielekästä vaatia, että esimerkiksi kuva piirtyy täsmälleen samalla tavalla jokaisella suorituskerralla, sillä ihminen ei yleensä huomaa yksittäisten kuvapisteiden muutoksia. Tämä ongelma ratkaistaan useimmissa kaupallisissa kuvien vertailuun soveltuvissa ohjelmistoissa siten, että testitapaukselle on mahdollista määrittää kynnysarvo, jolla voidaan hienosäätää sallittujen poikkeamien esiintymistiheyttä ja laatua. Tämäkin mahdollisuus jättää kuitenkin rajallisen liikkumavaran ja voi helposti johtaa virheelliseen testitulokseen. Liikkuva kuva ja ääni tuovat vielä oman lisänsä haasteisiin. (Fewster ja Graham, 1999) Fewster ja Graham (1999) kirjoittavat, ettei heidän tiedossaan kirjoitushetkellä ollut yhtään kaupallista ohjelmistoa äänen tai liikkuvan kuvan vertailuun. Tämän diplomityön osana tehdyn taustatutkimuksen perusteella tilanne ei odotuksista huolimatta vaikuta oleellisesti parantuneen. 33

42 Tulosten automaattinen vertailu ei ole ongelmatonta edes tekstimuotoisten tulosten tapauksessa. Automaattinen vertailu, toisin kuin testausta manuaalisesti suorittava testaaja, ei useimmiten kykene selviytymään testattavan ohjelmiston muutoksista. Muutoksia tarvitaan yleensä testiskripteihin tai jopa itse vertailuohjelmistoon. Ongelmia aiheutuu myös jos verrokkituloksissa on virheitä. Tällöin automaattisesti suoritettava vertailu hylkää oikean tuloksen. Vertailun automaattinen suorittaminen voi myös helposti vaatia paljon laskentatehoa, etenkin multimedian tapauksessa, ja siten hidastaa testauksen edistymistä. (Fewster ja Graham, 1999) Testitulosten analysointi automaattisesti on kuitenkin luonteva suunta testauksen automatisointiasteen nostamisessa. Se on parhaimmillaan helppoa ja varmatoimista, ja parantaa virheiden löytymistarkkuutta verrattuna manuaalisesti suoritettuun tulosten tutkimiseen. (Fewster ja Graham, 1999) 34

43 4 Matkapuhelinten testaus 4.1 Matkapuhelinten erityisvaatimukset testaukselle ja testauksen automatisoinnille Matkapuhelinten rajoitetut ominaisuudet asettavat omat vaatimuksensa niiden ohjelmistojen testaamiselle, ja erityisesti testauksen automatisoinnille. Heikkotehoiset prosessorit, rajallinen muisti ja vähäinen virrankulutus ovat matkapuhelimen ominaispiirteitä, jotka on huomioitava myös testauksessa. (Mikkonen, 2004) Ohjelmistoja testattaessa joudutaan yleensä kirjoittamaan ylimääräistä ohjelmakoodia, jonka tarkoitus on testata varsinaista ohjelmistoa. Testikoodi on ladattava normaaliin tapaan matkapuhelimen muistiin suoritusta varten, ja sen suorittaminen kuluttaa käytössä olevia resursseja. Matkapuhelimen rajallisten resurssien tapauksessa lisäresurssien tarve vaikuttaa testien toteutukseen. Lisäresurssien tarve ei saa kasvaa liian suureksi, sillä tällöin testausympäristö ei vastaisi ominaisuuksiltaan lopullista ympäristöä 1. Testikoodi ei saa vähentää merkittävästi käytössä olevaa käyttömuistia eikä laskentatehoa. Liiallinen resurssien kulutus hidastaa järjestelmän toimintaa. Rajoitteita testikoodille aiheutuu myös rajallisesta massamuistista. Matkapuhelimissa ei välttämättä ole juurikaan ylimääräistä levymuistia, joten testikoodia voi olla vain rajallinen määrä. Tämä rajoite on kuitenkin pienentynyt merkittävästi nykyisissä älypuhelimissa, joihin massamuistia voidaan lisätä. 1 Tässä yhteydessä jätetään huomioimatta esimerkiksi stressitestaus, jossa suoritusympäristöä kuormitetaan tarkoituksella. 35

44 4.2 Ympäristö, laitteet ja työkalut Testauslaitteisto Testauslaitteisto koostuu tietokoneesta ja testattavasta matkapuhelimesta, jotka on kytketty toisiinsa useimmiten kaapelilla. Vaihtoehtoisesti kytkentä voidaan tehdä myös langattomasti Bluetooth-yhteydellä. Matkapuhelin voidaan kytkeä tietokoneeseen joko suoraan siinä olevan liitännän avulla, tai käyttäen matkapuhelinten ohjelmointiin tarkoitettua laitetta sekä erillistä sovitinta, jolla puhelin kytketään ohjelmointilaitteeseen. Joissakin testijärjestelyissä testaukseen käytettäviä laitteita, niin matkapuhelimia kuin tietokoneitakin, voi olla enemmänkin Testiautomaatiojärjestelmä Testien automaattinen suoritus on toteutettu käyttäen alunperin Symbian OS -matkapuhelinten yksikkötestaukseen suunniteltua testiautomaatiojärjestelmää. Järjestelmä soveltuu myös osittain manuaalisesti suoritettavaan testaukseen, mutta sen päätarkoitus on mahdollistaa täysin automatisoitu testaus. Järjestelmä kykenee ohjelmoimaan testattavan laitteen, käynnistämään sen, siirtämään tarvittavat tiedostot laitteelle ja suorittamaan testitapaukset. Tapahtumatiedot ja testitapausten tulokset tallentuvat järjestelmään, josta ne voidaan haluttaessa siirtää testauksen hallintajärjestelmään. Tuloksia voidaan myös vertailla edellisten suorituskertojen tuloksiin. Testitapausten suoritusta ohjataan testikehyksen (alakohta 4.2.3) mukaisilla skripteillä. Testiautomaatiojärjestelmässä on verkkorajapinta, jonka kautta ulkopuoliset ohjelmistot voivat liittyä järjestelmään ja toimia osana testausta. Ulkopuoliset ohjelmistot voidaan toteuttaa millä tahansa alustalla ja tekniikalla. Ne kommunikoivat testiautomaatiojärjestelmän kanssa testikehyksen protokollan mukaisilla viesteillä. Tekstimuotoiset viestit kulkevat sovellustasolla TCP/IP-protokollaperheen päällä. Ulkopuolisia ohjelmistoja ohjataan skripteillä samaan tapaan kuin testikehyksen mukaisia testitapauksiakin. 36

45 4.2.3 Testikehys Testattavassa laitteessa suoritettavat testitapaukset toteutetaan käyttäen Symbian OS -matkapuhelimille suunniteltua testikehystä. Testikehys soveltuu sellaisten testitapausten kirjoittamiseen, jotka eivät tarvitse graafista käyttöliittymää. Kehys erottaa testitapausten toteutuksen testattavasta laitteistosta mahdollistaen testitapausten helpon siirrettävyyden alustalta toiselle, ja se tukee käytössä olevaa testiautomaatiojärjestelmää. Testitapaukset toteutetaan testimoduuleina. Testimoduulityyppejä on useita ja ne sopivat erilaisiin tarkoituksiin. Yhteen testimoduuliin voidaan toteuttaa useita testitapauksia. 4.3 Audiotestaus Matkapuhelimen audiotestaus on toteutettu käyttäen testiautomaatiojärjestelmää, joka on suorittanut testikehyksen mukaan toteutettuja testitapauksia. Testitapauksia on noin 600 ja ne testaavat kattavasti äänitoimintoja. Testitapauksissa muun muassa soitetaan ääntä, pysäytetään soitto ja jatketaan sitä sekä säädetään äänenvoimakkuutta ja muita ääniasetuksia. Soitettavat ääninäytteet sisältävät sekä pakkaamatonta että lukuisilla eri tavoilla ja asetuksilla pakattua ääntä. Riippuen testaustilanteesta ja testauksen tavoitteista, kaikkia audiotestitapauksia ei välttämättä suoriteta kaikille testattaville matkapuhelimille tai matkapuhelimien ohjelmistoversioille. Testaajan rooli audiotestauksessa on ollut testitapausten soittaman äänen kuuntelu. Testaaja on tehnyt subjektiivisen arvion testattavan käännöksen äänentoiston toimivuudesta ja ääniominaisuuksien laadusta. Tässä järjestelyssä on kuitenkin joitakin puutteita, jotka pyritään korvaamaan automatisoinnilla. Yksi tärkeimmistä syistä tulosten automaattiselle analysoinnille on ollut testaajan vapauttaminen tuottavampaan työhön. Kuten kohdassa todettiin, manuaalinen testaus ei ole testaajalle kovin motivoivaa. Audiotestauksen tapauksessa testaaja joutuu kuuntelemaan satojen testitapausten tuottamaa ääntä tuntien ajan viikoittain. Testauksessa on aina vähintään viisi eri matkapuhelinmallia, joille tulee uusia ohjelmistokäännöksiä keskimäärin kolme kertaa viikossa (kaikille käännöksille ei tosin yleensä suoriteta audiotestausta kokonaisuudessaan). 37

46 Korvakuulolla tehtävä arvio vaatii testaajaa keskittymään testitapausten kuunteluun, joten hän ei käytännössä pysty samalla tekemään muuta keskittymistä vaativaa työtä. Toinen tärkeä syy automatisoinnille on ollut subjektiivisen arvion epäluotettavuus. Testaaja pystyy tekemään subjektiivisen arvion äänentoiston toimivuudesta, mutta subjektiivisuuden vuoksi se voi vaihdella suorituskerrasta toiseen. Lisäksi eri testaajat arvioivat äänentoistoa eri tavoin. Automatisoimalla pystytään pääsemään eroon suorituskerrasta toiseen vaihtelevista arvioista, subjektiivisuutta sen sijaan ei edes lähdetty tässä vaiheessa poistamaan. Analysoinnin automatisointi on myös luonnollinen jatke tehdylle automatisointityölle. Regressiotestauksena (alakohta 3.2.2) suoritettava audiotestaus on ollut jo pidempään automatisoitu siten, ettei testaajan ole välttämätöntä suorittaa manuaalisesti jokaista testitapausta erikseen. Ainoa järkevä jatkokehityssuunta on pyrkiä automatisoimaan loputkin audiotestaukseen liittyvistä toimista. 38

47 5 AATE idea ja vaatimukset 5.1 Yleiskuvaus AATE (Automated Audio Testing Environment) on tietokoneella suoritettava ohjelmisto, joka toimii audiotestejä suorittavan testiautomaatiojärjestelmän kanssa. AATE:n rooli audiotestauksessa on suorittaa koneellisesti aiemmin testaajan korvakuulolta tekemä ulostulon analysointi. AATE:ia käytetään pääasiassa regressiotestauksen (alakohta 3.2.2) automatisoinnissa. Testauslaitteiston kokoonpano koostuu datankaappauskortista, jota AATE ohjaa, testiautomaatiojärjestelmää suorittavasta tietokoneesta, testattavasta laitteesta, ohjelmointilaitteesta, sovittimesta ja näitä yhdistävistä liitännöistä (kuva 5.1). Laitteistoa on kuvattu tarkemmin kohdassa 5.3. Kuva 5.1: Testauslaitteiston kokoonpano Testiautomaatiojärjestelmä ohjaa testattavassa laitteessa suoritettavia testejä. AATE:n avulla se voi ohjata datankaappauskorttia sekä suorittaa kortin avulla tallennetun audiodatan vertailun verrokkidataan (reference data). Näiden toimintojen avulla testiautomaatiojärjestelmä saa tiedon siitä, ovatko testattavan laitteen audio-ominaisuudet hyväksyttävällä tasolla. AATE koostuu neljästä, uudelleenkäytettävyyden ja siirrettävyyden vaatimukset (kohta 5.7) toteuttavasta komponentista: testausautomaatiojärjestelmän yhteyskomponentista, AATE-pääkomponentista sekä datankaappaus- ja signaalinkäsittelykomponenteista. Nämä komponentit on esitetty kuvassa

48 Kuva 5.2: AATE rakennekuvaus Mainitut komponentit mahdollistavat AATE:n datankaappaus ja audiosignaalien vertailu -toiminnallisuuksien käytön joko itsenäisesti komentorivikäskyjen avulla tai testiautomaatiojärjestelmän kautta automaattisesti audiotestien suorituksen yhteydessä. Jälkimmäisessä tapauksessa kommunikointi tapahtuu TCP/IPyhteyden yli välitettävien testiautomaatiojärjestelmän määrittelemien viestien avulla (kohta 6.4). Testiautomaatiojärjestelmä suorittaa audiotestit erityisten testiskriptien avulla, joihin lisätään käskyt AATE:n ohjastukseen. Esimerkiksi audion toistotestin yhteydessä AATE:lle voidaan antaa käsky aloittaa tallentaminen, kun itse testitapaus alkaa toistaa audiotiedostoa, ja testitapauksen suorituksen ja tallentamisen jälkeen käsky suorittaa audion vertailu. AATE:ia on mahdollista käyttää kahdessa eri toimintatilassa. Alustustoimintatilassa AATE:n avulla tallennetaan verrokkidataa myöhemmin suoritettavaa regressiotestausta varten. Verrokkidataa voidaan tallentaa, kun testaaja on korvakuulolta todennut audiotestien tuottavan hyväksyttävän tuloksen. Tämän jälkeen AATE:ia käytetään normaalissa toimintatilassa regressiotestaukseen. Tällöin audiotestitapauksen tuottamaa audiodataa verrataan verrokkidataan tulosten todentamiseksi automaattisesti. AATE palauttaa vertailutuloksen testiautomaatiojärjestelmälle, joka kaikki testitapaukset suoritettuaan tekee päätöksen koko testitapausjoukon hyväksymisestä tai hyväksymättä jättämisestä. AATE raportoi tekemisensä ja mahdolliset virhetilanteet koko suorituksen ajan lokitiedostoon. 40

49 5.2 Yhteensopivuus testiautomaatiojärjestelmän kanssa AATE:n suunnittelun lähtökohtana oli yhteensopivuus testiautomaatiojärjestelmän ja olemassa olevien audiotestitapausten kanssa. Vaatimuksena oli, ettei olemassa olevien testitapausten puhelimessa suoritettavaa ohjelmakoodia muuteta. Koska matkapuhelimen kapasiteetti ei riitä suunniteltuun toiminnallisuuteen, ja koska testiautomaatiojärjestelmä tukee ulkopuolisten ohjelmistojen käyttöä (alakohta 4.2.2), päätettiin AATE toteuttaa työasemassa toimivana ohjelmistona. Tällöin AATE vaatii korkeintaan pieniä muutoksia testitapauksia ohjaaviin skripteihin. Testiautomaatiojärjestelmän kanssa kommunikointiin käytetään alakohdassa lyhyesti kuvattua protokollaa. Koska toteutuskieleksi valittiin C++ 1, asetettiin samalla vaatimus uudelleenkäytettävyydestä (kohta 5.7). AATE:ia suoritetaan erillisenä prosessina työasemalla ja se toimii testiautomaatiojärjestelmän ohjeistuksen mukaan. AATE voidaan vertailujärjestelmänä luokitella kohdassa 3.6 esitetyn kuvan 3.3 mukaan lähinnä kategoriaan b. Toisaalta, koska AATE on muutakin kuin tulosten vertailuun sopiva ohjelmisto ja helposti laajennettavissa tekemään mitä moninaisimpia tehtäviä, se voidaan luokitella myös kategoriaan c, eli testiautomaatiojärjestelmän ohjaamaksi testijärjestelmäksi. 5.3 Laitteisto AATE:n käyttö vaatii kaksi kytkentää testattavan matkapuhelimen ja tietokoneen välille. Ensimmäinen on testiautomaatiojärjestelmän kanssa kommunikointiin tarvittava kytkentä (kohta 5.2), ja toinen puhelimen soittaman äänen tallentamiseen tarvittava kytkentä. Testiautomaatiojärjestelmän kanssa voidaan kommunikoida joko langattomasti tai käyttäen ohjelmointilaitetta ja sovitinta. Puhelimessa olevaa liitäntää ei voida käyttää, sillä sitä tarvitaan äänen tallentamiseen. Tähän liitäntään kytketään niin sanottu hands free -laite, johon on lisätty erilliset liittimet tietokoneeseen kytkemistä varten. Äänen tallennukseen suunniteltiin käytettävän erillistä tietokoneeseen asennet- 1 C++ valittiin lähinnä tehokkuussyistä sekä siksi, että datankaappauskorteille oli useimmiten tarjolla C++-ohjelmointirajapinta (kohta 5.3). 41

50 tua datankaappauskorttia. Mahdollisuutta käyttää tietokoneen äänikorttia tutkittiin myös, mutta yleisesti korttien vaihtelevat ominaisuudet ja hankala hallittavuus sulkivat ne pois varteenotettavien vaihtoehtojen joukosta. Äänikorttiin ei olisi myöskään voinut kytkeä puhelinta suoraan, sillä äänikortissa ei ole differentiaalisisääntuloa. Datankaappauskorttia valittaessa kiinnitettiin erityistä huomiota sen ohjelmointirajapintaan. Alkuperäinen valinta kohdistui yleiskäyttöiseen datankaappauskorttiin. Kortin ohjelmointirajapinta oli hyvä ja kortti oli helppokäyttöinen, mutta se ei kaikilta osin soveltunut AATE:n kanssa käytettäväksi. Kortin suurin yksittäinen ongelma oli runsas kohina, jota se aiheutti nauhoitettuun dataan. Toisella kerralla valittiin National Instrumentsin nimenomaan audiokäyttöön suunniteltu datankaappauskortti. Valittu kortti kykenee kaappaamaan yli satatuhatta näytettä jopa kahdeksalta kanavalta yhtäaikaisesti eikä se aiheuta ylimääräistä kohinaa. Kortille on vain C-kielinen ohjelmointirajapinta, NI-DAQmx, mutta sitä pystyy käyttämään C++-kielelläkin kunhan on valmis joustamaan hiukan olio-ohjelmointityylistä. Kortin vaihto tapahtui vasta, kun toteutus oli jo ehditty aloittaa. Vaihto onnistui ongelmitta, mikä osoitti hyvin sen, että laajennettavuusvaatimus (kohta 5.7) oli ainakin tältä osin toteutettu onnistuneesti. 5.4 Audiosignaalien tallennus ja käsittely AATE tallentaa audiosignaalit yleisesti käytetyllä, alunperin Microsoftin ja IBM:n kehittämällä, WAVE-audiotiedostoformaatilla (Waveform Audio File Format). Formaatissa käytetään analogisen audiodatan digitaalisessa muodossa tallentamiseen niin kutsuttua pulssin modulointia (Pulse Code Modulation, PCM). Tiedostoformaatti on osa Microsoftin RIFF -spesifikaatiota (Resource Interchange File Format) multimediatiedostojen tallentamiseen, ja sen 44 tavun kokoinen otsikko-osa (header) koostuu liitteessä A esitetyistä kentistä. (Boer, 2003; IBM ja Microsoft, 1991) Pulssin moduloinnissa analoginen signaali muutetaan digitaaliseen muotoon näytteistämisen avulla. Signaalin korkeus, amplitudi, näytteistetään t sekunnin tasavälein, jolloin saadaan N :stä diskreetistä arvosta x n koostuva digitaalinen signaali: 42

51 x n = x(t n ) = x(t 0 + n t), n = 1, 2,..., N. (5.1) Näytteistetyn datan kokonaispituudeksi saadaan T = N t, ja dataan liittyvä näytteenottotaajuus, niin kutsuttu Nyquistin rajataajuus saadaan kaavasta: f c = 1 2 t. (5.2) Diskreetit arvot tallennetaan tavallisesti 4-24 bitillä per näyte ja näytteenottotaajuutena käytetään näytettä per sekunti tai hertsiä (Hz). (Bendat ja Piersol, 1986; Boer, 2003) Jokaisella näytteenottohetkellä signaaliaallon amplitudi tallennetaan kokonaislukuarvona. Voidaan havaita, että signaalin digitaalisen esitysmuodon tarkkuus riippuu suoraan näytteenottotaajuudesta ja näytearvojen resoluutiosta, jotka muodostavat analogi-digitaalimuunnoksen näytteistysruudukon (kuva 5.3). Näytteistämisessä on aina jonkin verran epätarkkuutta, mutta mitä korkeampi resoluutio näytteistysruudukossa on (korkeampi näytteenottotaajuus ja suurempi määrä bittejä per tallennettava näytearvo), sitä varmemmin ihmiskorva ei havaitse eroa signaalin analogisen ja digitaalisen esitysmuodon välillä. Yleisesti on havaittu, että tällainen ideaalinäytteistysresoluutio saavutetaan 16 bitillä per näytearvo ja näytteellä per sekunti, jota käytetään standardina muun muassa musiikki-cd -levyissä. (Boer, 2003) Kuva 5.3: Näytteistetty siniaalto (Boer, 2003) Bittien määrä per näyte vastaa näytteen resoluutiota pystyakselilla (amplitudi). Kuvasta 5.4 havaitaan, että matala resoluutio ei esitä näytettä riittävän tarkasti tuoden niin sanottua kvantisointivirhettä, joka tarkoittaa pyöristysvirhettä muu- 43

52 tettaessa signaaliarvoja näytearvoiksi. Säännöllisessä sinisignaalissa virhe toisi säännöllisen vääristymän signaaliin. Epäsäännöllisissä signaaleissa virhe esiintyy satunnaisena kohinana. Mitä pienempi resoluutio, sitä enemmän vääristymää tai kohinaa signaalissa esiintyy. (Boer, 2003) Kuva 5.4: Kvantisointivirhe ja kasvatettu bittien määrä per näyte (Boer, 2003) Näytteenottotaajuus mitataan tavallisesti hertseissä (Hz) tai kilohertseissä (khz) ja se vastaa näytteen resoluutiota vaaka-akselilla. Kuvassa 5.5 on esitetty korkeataajuuksinen sinisignaali näytteistettynä eri näytteenottotaajuuksilla. Liian pienellä näytteenottotaajuudella näytteistetty signaali ei juurikaan muistuta alkuperäistä ja kadottaa alkuperäisen signaalin korkeat taajuudet, koska näytteenottoteoreeman mukaan vain taajuudet näytteenottotaajuuden puolikkaaseen (Nyquistin taajuus, kaava 5.2) saakka voidaan tallentaa. Kuvasta havaitaan helposti, että tuplattaessa näytteenottotaajuutta, digitaalisessa muodossa esitetty signaali alkaa lähestyä muodoltaan yhä enemmän alkuperäistä analogista. (Boer, 2003) Näin ollen alkuperäisen signaalin korkein taajuus määrää käytettävän näytteenottotaajuden. Korkeataajuussignaaleilla kannattaa käyttää 44,1 khz näytteenottotaajuutta, jonka avulla voidaan tallentaa lähes kaikki ihmiskorvan kuulemat taajuudet. Matalataajuussignaalien kanssa voidaan taas haluttaessa käyttää matalampia näytteenottotaajuuksia tuottamatta häiriötä. (Boer, 2003) Tallennetun audiodatan koko määräytyy siis näytettä kohden olevien bittien määrän, näytteenottotaajuuden sekä kanavien määrän mukaan. Näistä testaajan on mahdollista asettaa näytteenottotaajuus haluamalleen tasolle testitapauskon- 44

53 Kuva 5.5: Analoginen sinisignaali (a) ja sen digitaaliset versiot näytteistettynä eri näytteenottotaajuuksilla (b), (c), ja (d) (Boer, 2003) figuraatiotiedostossa (kohta 5.6). Testaaja voi valita sopivan näytteenottotaajuuden riittävän hyvältä kuulostavalle audiotallenteelle ja kontrolloida näin tallennettavan datan määrää. Ainoan rajoitteen näytteenottotaajuudelle asettaa käytetty datankaappauskortti, sillä useissa korteissa yleinen näytteenottotaajuuden maksimiraja on 100 khz per kanava (kohta 5.3). 5.5 Audiosignaalien vertailu AATE:ssa valittiin PCM-muodossa tallennettujen signaalien aikatason (time domain) näytearvojen vertailumenetelmäksi ristikorrelaatio (cross-correlation), joka on mitta kahden signaalin samanlaisuuden tai yhteisten ominaisuuksien välillä. Menetelmän sovellusalueita ovat muun muassa signaalin, esimerkiksi tutkan paluusignaalin, havaitseminen häiriösignaalista (noise), hahmon tunnistus (pattern matching), kuvien vertailu konenäkösovelluksissa ja viiveen mittaus. Autokorrelaatio (autocorrelation) on ristikorrelaation erikoistapaus, johon liittyy vain yksi signaali, ja se kertoo tietoja signaalin rakenteesta ja käyttäytymisestä aikatasossa. Autokorrelaatiota käytetään vastaavissa sovelluksissa kuin ristikorrelaatiota. (Ifeachor ja Jervis, 2002) Kuvassa 5.6 on esitetty kaksi signaalia x(t) ja y(t), joista jälkimmäinen on ensimmäisen signaalin viivästynyt ja häiriöllinen versio, sekä signaalien ristikorrelaatiotulos. Tuloksen maksimiarvo kuvaa signaalien samanlaisuutta ja sen sijainnista 45

54 Kuva 5.6: Ristikorrelaatio: Signaali x(t) (a), saman signaalin viivästynyt ja häiriöllinen versio y(t) (b) ja signaalien ristikorrelaatio (c) (Ifeachor ja Jervis, 2002) voidaan päätellä signaalien välinen viive-ero. (Ifeachor ja Jervis, 2002) Kahden signaalivektorin x(t) ja y(t) analoginen eli jatkuva-aikainen ristikorrelaatio on keskiarvo tekijöiden x(t) ajanhetkellä t ja y(t) ajanhetkellä t + τ tulosta integroituna äärellisellä aikavälillä T : R xy (τ) = 1 T T 0 x(t)y(t + τ)dt. (5.3) Ristikorrelaatiota R xy (τ) kutsutaan autokorrelaatioksi R xx (τ) erikoistapauksessa, kun pätee x(t) = y(t). (Bendat ja Piersol, 1986) Diskreetin ristikorrelaation niin kutsuttu suoramuoto (direct procedure) aikaviiveellä r t lasketaan näytearvoista kaavalla R xy (r t) = 1 N r x n y n+r, r = 0, 1, 2,..., m ja m < N, (5.4) N r n=1 46

55 jossa r on viivearvo (lag number) ja m maksimiviivearvo (m < N ). Jokaisella viivearvolla r kertolaskujen määrä on N - r, josta saadaan skaalaustekijä. (Bendat ja Piersol, 1986) Ristikorrelaatio lasketaan eri viivearvoilla r, jotta olisi mahdollista löytää suurin korrelaatioarvo. Vaikka kahden signaalin aaltomuodot olisivat samat, saattaa niiden korrelaatiotulos olla nolla signaalien eri vaiheesta johtuen (kuva 5.7). Tämän takia toista signaalia y siirretään viivearvon r verran korrelaation maksimiarvon löytämiseksi. (Ifeachor ja Jervis, 2002) Kuva 5.7: Eri vaiheissa olevat korreloivat signaalit x 1 ja x 2 (a) ja signaalin x 2 siirto viivearvon j verran (b) Diskreetti ristikorrelaatio voidaan myös toteuttaa diskreetin Fourier-muunnoksen (discrete Fourier transform, DFT) avulla. Fourier-muunnos muuntaa aikatason reaali- tai kompleksiarvoisen signaalin x(t) taajuustason (frequency domain) kompleksiarvoiseksi signaaliksi X(f). Tasavälein t näytteistetylle signaalille x n saadaan diskreetit taajuusarvot kaavasta f k = k T = k, n = 0, 1, 2,..., N 1. (5.5) N n Näillä taajuuksilla saadaan signaalin x n diskreetin Fourier-muunnoksen arvot: X k = N 1 n=0 (Bendat ja Piersol, 1986) 2πkn j x n e N, k = 0, 1, 2,..., N 1. (5.6) Arvot ovat yksikäsitteisiä indeksiin k = N/2 saakka, jota kutsutaan Nyquistin rajataajuudeksi. Vastaavasti diskreetin Fourier-käänteismuunnoksen (discrete in- 47

56 verse Fourier transform) kaava: x n = 1 N N 1 k=0 jossa 1/N on skaalaustekijä. (Bendat ja Piersol, 1986) X k e j 2πkn N, n = 0, 1, 2,..., N 1, (5.7) Fourier-muunnoksen laskeminen N :n mittaiselle signaalille x(n) tarvitsee paljon laskutoimituksia: N 2 kompleksista kerto- ja yhteenlaskua. Diskreetti Fouriermuunnos voidaan kuitenkin laskea tehokkaasti Cooleyn ja Tukeyn nopean Fouriermuunnoksen algoritmin (Fast Fourier Transform, FFT) avulla signaaleille, joiden pituus on kahden potenssi (N = 2 p ). (Bendat ja Piersol, 1986) FFT hyödyntää kompleksilukujuurien ominaisuuksia mahdollistaen DFT:n (kaava 5.6) laskemisen ajassa Θ(N lgn) DFT:n suoramuodon (kaava 5.4) suoritusajan Θ(N 2 ) sijaan. Kompleksiluvun N:s juuri on kompleksiluku ω, jolle pätee ω N = 1. N kappaletta kompleksiluvun N :s juuria (complex N th root of unity) asettuvat tasavälein kompleksitason yksikköympyrän origon ympärille (kuva 5.8) ja ne voidaan laskea kaavalla: (Cormen et al., 1992) ωn k = e j 2πk N = cos ( 2πk N ) + j sin (2πk ), k = 0, 1, 2,..., N 1. (5.8) N Kuva 5.8: Kompleksitason arvot ω8, 0 ω8,...,ω 1 8, 7 joista ω 8 = e j 2π 8 kutsutaan 8. pääjuureksi (Cormen et al., 1992) Arvo ω N = e j 2π N on niin kutsuttu kompleksiluvun N:s pääjuuri (the principal complex N th root of unity). Kaikki kompleksiluvun N:s juuret ovat kompleksiluvun pääjuuren ω N potensseja ωn 0, ω1 N,...,ωN 1, joilla on seuraavat ominaisuu- N det: 48

57 1. ω N N = ω 0 N = 1, ω 1 N = ωn 1 N, ωj N ωk N = ω jk N. (5.9) 2. Mitätöintilemma (cancellation lemma): Kaikille N 0, k 0, ja m 0 pätee: ω mk mn = (e j 2π mn ) mk = (e j 2π N ) k = ω k N, (5.10) josta seuraa, että kaikille parillisille N > 0: 3. Puolituslemma (halving lemma): ω N/2 N = ω 2 = 1. (5.11) Jos N > 0 on parillinen, niin N:n kompleksiluvun N:nen juuren neliöt ovat N/2:n kompleksiluvun N/2 juuria: (ω k+ N 2 N ) 2 = ω 2k+N N = ω 2k N ω N N = ω 2k N = (ω k N) 2 = ω k N/2. (5.12) Puolituslemma on oleellinen FFT:n käyttämän hajoita ja hallitse -lähestymistavan kannalta, koska se takaa rekursiivisten aliongelmien olevan vain puolet alkuperäisen ongelman koosta. 4. Summauslemma (summation lemma): Kaikille N 1 ja positiivisille k, jotka eivät ole jaollisia N:llä pätee geometrisen sarjan kaavaa soveltaen: N 1 (ωn) k j = (ωk N )N 1 ωn k 1 = (ωn N )k 1 ωn k 1 = (1)k 1 = 0. (5.13) 1 n=0 Vaatimus k:n jakamattomuudesta N:llä takaa, että nimittäjä ei ole 0, koska ω k N = 1 vain, jos k on jaollinen N:llä. ω k N (Cormen et al., 1992) 49

58 DFT:n kaava voidaan kirjoittaa seuraavasti: X k = N 1 n=0 2πkn j x n e N N 1 = n=0 x n ω kn N = X(ω k N), k = 0, 1, 2,..., N 1. (5.14) Hajoita ja hallitse -lähestymistavan mukaan FFT käyttää erikseen X(ω):n parillisja paritonindeksisiä kertoimia määrittämään kaksi uutta N/2 asteista polynomia X [0] (ω) ja X [1] (ω): X [0] (ω) = x 0 + x 2 ω + x 4 ω x N 2 ω N 2 1, (5.15) X [1] (ω) = x 1 + x 3 ω + x 5 ω x N 1 ω N 2 1. (5.16) X [0] (ω) sisältää kaikki X:n parillisindeksiset (indeksin binääriesitys päättyy lukuun 0) kertoimet, ja X [1] (ω) sisältää kaikki X:n paritonindeksiset (indeksin binääriesitys päättyy lukuun 1) kertoimet. Näiden avulla saadaan: X(ω) = X [0] (ω 2 ) + ωx [1] (ω 2 ), (5.17) joten X(ω):n laskeminen arvoilla ωn 0, ω1 N,...,ωN 1 N suppenee N/2 asteisten polynomien X [0] (ω) ja X [1] (ω) laskemiseen arvoilla (ωn 0 )2, (ωn 1 )2,...,(ω N 1 N )2 sekä tulosten yhdistämiseen. (Cormen et al., 1992) Puolituslemman mukaan N/2 asteiset polynomit X [0] (ω) ja X [1] (ω) lasketaan rekursiivisesti N/2:lla kompleksiluvun N/2 juurella. Näillä alitehtävillä on täysin sama muoto kuin alkuperäisellä (kaava 5.17), mutta vain puolet sen koosta. Näin N-elementin DFT:n laskeminen voidaan jakaa kahteen N/2:n elementin DFT:n laskemiseen, kun N on kahden potenssi. (Cormen et al., 1992) Ristikorrelaation laskemaan viiveiden määrään voidaan vaikuttaa nollien lisäyksellä (zero padding) verrattavien signaalien perään. Esimerkiksi N :n mittaiset signaalit x(t) ja y(t) voidaan pidentää pituuteen 2N lisäämällä nollia signaalien perään, jolloin ristikorrelaatio lasketaan kaikilla mahdollisilla viivearvoilla (Press et al., 1988). AATE käyttää nollien lisäystä myös pidentämään mahdol- 50

59 lisen lyhyemmän signaalin pidemmän mittaiseksi sekä varmistamaan signaalien pituuksien olevan kahden potensseja FFT:n laskentaa varten. Signaalien diskreetille ristikorrelaatiolle saadaan kaava: R xy = 1 2N [X ky k ], k = 0, 1,..., 2N 1, (5.18) jossa X k ja Y k ovat signaalien x(t) ja y(t) FFT-arvot, ja merkki * tarkoittaa kompleksikonjugaattia. FFT-arvojen kertomistuloksesta otetaan käänteis-fft ja tulos skaalataan arvolla 1. Reaaliarvoisten signaalien Fourier-muunnokset 2N voidaan lisäksi laskea samanaikaisesti sijoittamalla toinen signaali x n kompleksisen signaalin z n reaaliosaksi ja toinen signaali y n imaginääriosaksi: z n = x n + jy n, n = 0, 1, 2,..., N 1. (5.19) Kompleksisen signaalin z n Fourier-muunnokselle saadaan kaava: N 1 Z k = [x n + jy n ]e n=0 j 2πkn N, k = 0, 1, 2,..., N 1, (5.20) josta voidaan johtaa kaavat signaalien x(t) ja y(t) Fourier-muunnoksille X k ja Y k : X k = Z k + Z N k 2 (Bendat ja Piersol, 1986), Y k = Z k ZN k, k = 0, 1,..., N 1. (5.21) 2j Korrelaatiotuloksen ensimmäinen puolisko 0 n N 1 kuvaa korrelaatioarvoja positiivisilla viiveillä (0 n m) ja toinen puolisko N n 2N 1 kuvaa arvoja negatiivisilla viiveillä ( m n 0) (Bendat ja Piersol, 1986). Esimerkiksi Matlab ja Octave vaihtavat korrelaatiotuloksen puoliskojen paikat keskenään, jotta tuloksen kuvaajan keskelle saadaan korrelaatioarvo viiveen arvolla 0. Käytettäessä AATE:ia normaalitoimintatilassa tallennetaan audiotestitapauksen tuloksena saatava audiodata. Testitapauksen audiodataa verrataan testitapauk- 51

60 sen verrokkiaudiodataan, joka on tallennettu aikaisemmin AATE:n avulla alustustoimintatilassa. Vertailu suoritetaan jokaiselle audiodatan kanavalle erikseen ristikorrelaatiolla, jonka tuloksen maksimiarvoa verrataan niin ikään alustustilassa tallennettuun kynnysarvolla (threshold value) painotettuun verrokkimaksimiarvoon. Verrokkimaksimiarvo on verrokkiaudiodatan autokorrelaation, eli datan ristikorrelaation itsensä kanssa, maksimiarvo. Kynnysarvot ovat asetettavissa audiotestitapauksille niiden testitapauskonfiguraatiotiedostoissa (kohta 5.6) ja ne saavat arvon väliltä Kynnysarvo tarkoittaa prosenttimäärää verrokkimaksimiarvosta, jonka verran testitapauksen vertailutuloksen maksimiarvo saa poiketa. Arvo 0 asetetaan, jos vertailutuloksen maksimiarvon täytyy olla täsmälleen sama kuin verrokkimaksimiarvon ja 100, jos maksimiarvo voi olla mikä tahansa (kuva 5.9). Kuva 5.9: Audiodatan vertailu kynnysarvon avulla Kynnysarvon käyttö antaa testaajalle mahdollisuuden hienosäätää audiodatan vertailun hyväksymisastetta. Esimerkiksi ensimmäisellä audiotestitapauksen automatisointikierroksella voidaan kynnysarvo asettaa nollaan tai hyvin lähelle sitä, minkä jälkeen testitapausten tuottamien audiodatojen korvakuuloarviolla voidaan kynnysarvoa kasvattaa hyväksymisastetta keventämään. Käytännössä on kuitenkin mahdotonta saada täysin samaa vertailutulosta toistetuilla testitapauksen suorituskerroilla johtuen muun muassa testauksessa käytetystä laitteiston ja ohjelmiston synkronoinnin epävakaudesta, joka aiheuttaa pientä vaihtelua tallennettuun audiodataan. Ristikorrelaation ominaisuuksista on tärkeää havaita, että se ei pysty kertomaan erillisiä virhelähteitä audiodatassa, kuten impulsseja (impulses), kohinaa (white noise) tai signaaliarvojen leikkautumista (clipping). Ristikorrelaatio kertoo ainoastaan vertailtavien datojen samanlaisuuden. 52

61 5.6 Järjestelmän tallentamat tiedot AATE:n toimintaa ohjataan sekä yleisten että testitapauskohtaisten konfiguraatiotiedostojen avulla. Yleisen konfiguraatiotiedoston avulla asetetaan yleiset toiminnallisuuteen liittyvät asetukset, kuten testiautomaatiojärjestelmän yhteysosoite ja -portti, lokitiedoston, verrokkidatan ja vertailutulosten hakemistojen sijainnit sekä toimintatila. Testitapauskohtaisiin konfiguraatiotiedostoihin tallennetaan yksittäisiin audiotestitapauksiin liittyvää tietoa, kuten audiotestitapauksen toistamien audiotiedostojen nimet ja niiden sisältämien kanavien määrät, audiotiedostojen kestot sekä näytteenottotaajuudet. Testitapauskonfiguraatiotiedostoon tallennetaan myös audiotiedostojen vertailuun käytettävä kynnysarvo. Alustustoimintatilassa AATE tallentaa kaapatun audiodatan WAVE PCM -formaattia olevaan tiedostoon, laskee audiodatan jokaisen kanavan autokorrelaatiotuloksen maksimiarvot sekä tallentaa ne verrokkidataksi audiotestitapaus- ja kanavatunnistein. Normaalissa toimintatilassa AATE tallentaa vastaavasti audiotestin tuottaman audiodatan WAVE PCM -tiedostoon ja laskee sen kanavien ristikorrelaatiot audiotestitapauksen nimen avulla tunnistettavan verrokkidatan kanssa. Ristikorrelaatiotulokset tallennetaan kokonaisuudessaan ja sijoitetaan tuloshakemistoon aikaleimalla varustettuun alihakemistoon, jolloin virhetilanteissa voidaan helposti hakea tietyn audiotestitapauksen suorituksen tiedot lähempää tarkastelua varten. AATE tallentaa suoritustietonsa lokitiedostoon ja haluttaessa näyttää ne reaaliaikaisesti komentorivi-ikkunassa. Lokiviestit koostuvat aikaleimasta, viestin lähettäneen luokan nimestä sekä itse viestistä. Lokiviestien avulla voidaan selvittää esimerkiksi mahdollisia virhetilanteita jälkikäteen. 5.7 Uudelleenkäytettävyys, laajennettavuus ja siirrettävyys Uudelleenkäytettävyys, laajennettavuus ja siirrettävyys olivat AATE:n tärkeimpien vaatimusten joukossa. Matkapuhelinala ja -teknologiat ovat nopeasti muuttuvia, joten muidenkin ohjelmistojen on oltava joustavia. Ohjelmistoja ei ole 53

62 kannattavaa toteuttaa kokonaan uudestaan joka kerta ympäristön muuttuessa. Testiautomaatiojärjestelmä, jonka kanssa AATE toimii, on laajalti käytössä testauksessa. Monissa tapauksissa on tarve käyttää apuna tietokoneella toimivaa ohjelmistoa, jota testiautomaatiojärjestelmä ohjaa. Tällaisia ohjelmistoja löytyi entuudestaan jonkin verran, mutta ne oli toteutettu Javalla tai Perlillä. C++kielellä toteutettua yleiskäyttöistä komponenttia kommunikointiin testiautomaatiojärjestelmän kanssa ei ollut. Tästä syystä uudelleenkäytettävyys on AATE:n vaatimuksissa. Sama vaatimus koskee muitakin AATE:n suurempia komponentteja. Myös laajennettavuus asetettiin vaatimukseksi. Nykyinen testiautomaatiojärjestelmä saattaa korvautua toisella tai sen rinnalle voi tulla muita järjestelmiä. Käytettävä datankaappauskortti voi vaihtua tai analysointiin voidaan haluta käyttää muitakin menetelmiä kuin ristikorrelaatiota. Näistä syistä johtuen AATE:n suuremmille kokonaisuuksille asetettiin laajennettavuusvaatimus. Laajennettavuusvaatimuksen toteutumiselle ei asetettu mitään erityistä mittaria. Nykyiset testausjärjestelmät, samoin kuin datankaappauskortit, toimivat vain Microsoft Windows -alustalla. Tulevaisuutta ajatellen AATE:n vaatimuksiin kirjattiin kuitenkin vaatimus siirrettävyydestä. Siirrettävyysvaatimuksena oli, että AATE voidaan joko suoraan tai pienellä vaivalla kääntää myös muilla alustoilla kunhan tarvittavat ohjelmointirajapinnat toimivat niillä. Siirrettävyyden mittariksi asetettiin se, että toteutettava ohjelmakoodi kääntyy myös Linux-alustalla käyttäen GCC:n (GNU Compiler Collection) C++-kääntäjää. 54

63 6 Toteutus ja testaus 6.1 Suunnittelu ja ohjelmistoarkkitehtuuri AATE:n tärkeimmät suunnittelunäkökohdat olivat yhteistoiminta käytössä olevan testiautomaatiojärjestelmän kanssa sekä uudelleenkäytettävyys-, laajennettavuus- ja siirrettävyysvaatimukset. AATE on testiautomaatiojärjestelmän kanssa asiakas-palvelin -suhteessa. Tästä seurasi rinnakkaisuusvaatimuksia, jotka toivat oman lisänsä suunnitteluun. Ohjelmakoodia AATE:n ensimmäiseen versioon kertyi kommentteineen hieman yli riviä. Kuvan 6.1 AATE-pääluokka koostuu luokista TasCommsBase, SignalAcquisition, SignalProcessing, Configuration, Logger, AateState ja AateMessage. AateMessage on järjestelmän sisäiseen viestinvälitykseen käytetty luokka, jonka ilmentymiä välitetään AateCallbackInterface-rajapinnan toteuttavan luokan kautta. AateState-luokka ja sen johdannaiset on toteutettu tilasuunnittelumallia (kohta 6.2) käyttäen. AateState-luokasta periytetyt luokat käsittelevät AateMessage-luokan ilmentymiä ja ohjaavat AATE:n toimintoja, kuten audiosignaalien tallentamista ja vertailua, saatujen viestien mukaisesti. AateStateluokan johdannaisten tilasiirtymät on kuvattu kohdassa 6.2. AATE käyttää Logger-luokkaa lokitietojen kirjoittamiseen ja Configuration-luokkaa konfiguraatiotiedoston lukemiseen. TasComms-luokka toteuttaa kommunikoinnin testiautomaatiojärjestelmän kanssa, ja se periytyy abstraktista TasCommsBase-kantaluokasta, joka määrittelee yleisen rajapinnan ulkoisten järjestelmien kanssa kommunikointiin. SocketConnectionluokka tarjoaa toiminnallisuuden kommunikointiyhteyden luomiseen. TasComms käyttää TasMessage-luokkaa testiautomaatiojärjestelmältä saamiensa viestien käsittelyyn ja AATE:n sisäisten viestien, AateMessage-luokan ilmentymien, luomiseen. TasComms asettaa saamiensa viestien perusteella tilansa käyttäen Tas- CommsState-luokkaa. TasCommsState-luokka ja siitä periytetyt luokat on toteutettu tilasuunnittelumallin (kohta 6.2) mukaisesti. SignalAcquisition-luokka tarjoaa yleisen rajapinnan datankaappauskorteille ja toimii kantaluokkana datankaappauskorttien ohjelmointirajapintoja käyttäville toteutusluokille. Esimerkiksi SignalAcquisitionNI-luokka käyttää Natio- 55

64 SocketConnection 1 TasComms 1 TasCommsState WaitReserve <<interface>> AateCallbackInterface TasCommsBase WaitRelease WaitCommand Utils AateCallbackInterface 1 TasMessage WaitEventRequest SignalProcessing 1 AATE * AateMessage Idle 1 AateState Quit WaitCommand AudioData 1 SignalAcquisition 1 Logger 1 Configuration StartAcquisition StopAcquisition PCMData SignalAcquisitionMCC SignalAcquisitionNI StartComparison ComparisonReady Kuva 6.1: Luokkakaavio nal Instrumentsin datankaappauskorteille tarkoitettua ohjelmointirajapintaa ja SignalAcquisitionMCC käyttää Measurement Computingin Universal Library -ohjelmointirajapintaa. SignalAcquisition käyttää AudioData-luokkaa ja siitä erikoistettua PCMData-luokkaa audiodatan tallentamiseksi WAVE PCM -formaattia olevaksi tiedostoksi. SignalProcessing-luokka toteuttaa signaalinkäsittelytoiminnallisuuden. Sekin käyttää PCMData-luokkaa WAVE PCM -formaattia olevien audiotiedostojen käsittelyyn. Utils-luokka tarjoaa yleishyödyllisiä palveluita, kuten merkkijonojen käsittelyä, joita käytetään valtaosassa AATE:n luokista. SignalAcquisition, SignalProcessing sekä TasComms käyttävät AATE-luokkaa AateCallbackInterface -rajapinnan kautta. Näin luokat voivat kommunikoida niistä koostuvan luokan kanssa olematta siihen kiinteästi sidoksissa. Tällaisen niin kutsutun vastakutsurajapinnan (callback interface) avulla voidaan toteuttaa uudelleenkäytettävyys- ja siirrettävyysvaatimus. Mainitut komponentit voidaan siirtää sellaisenaan toisiin järjestelmiin, kunhan järjestelmästä löytyy vastakutsurajapinnan toteuttava luokka. 56

65 AateCallbackInterface-rajapinnan kautta AATE-luokan koostavat luokat voivat käyttää Logger- ja Configuration-luokkia, jotka on toteutettu luontimalleihin (creational patterns) kuuluvan ainokainen suunnittelumallin (singleton) avulla. Ainokaisen ajatuksena on varmistaa, että jostakin luokasta on käytettävissä vain yksi ilmentymä. Se eroaa globaalista muuttujasta siten, että ainokaisen luonnista ja jakelusta vastaa luokka itse, eikä siitä ole mahdollista luoda rinnakkaisia ilmentymiä. Ainokainen soveltuu erityisen hyvin sellaisen tiedon välittämiseen ja palveluiden tarjoamiseen, joita tarvitaan monissa ohjelmiston eri osissa. Se vähentää parametrien välittämistä funktiokutsuissa funktiosta toiseen ja tarvetta lukea samoja tietoja useita kertoja esimerkiksi tiedostosta. (Gamma et al., 1995) Ainokaisen käytölle AATE:ssa oli useampia perusteita. Rinnakkaisuus vaati mekanismin, jossa esimerkiksi lokitietojen kirjoitus tapahtui keskitetysti niin, että yhtäaikaiset kutsut voidaan suorittaa poissulkevasti. Uudelleenkäytettävyysvaatimusten seurauksena toisistaan mahdollisimman hyvin erotetut komponentit tarvitsivat pääsyn samoihin konfiguraatiotietoihin, mihin ainokainen tarjosi helposti toimivan tavan. 6.2 Tilakoneet viestien käsittelyyn Uudelleenkäytettävyysvaatimuksista ja rinnakkaisuudesta johtuen AATE:n eri osien välinen kommunikointi suunniteltiin toteutettavaksi käyttäen viestinvälitystä, jossa yksi moduuli tarjoaa välityspalvelun viesteille. Nämä viestit puolestaan ohjaavat AATE:n toimintaa tietyn algoritmin mukaisesti. AATE koostuu kahdesta tilakoneesta: sisäiseen viestinvälitykseen ja testiautomaatiojärjestelmän kanssa kommunikointiin liittyvistä tilakoneista. Ensimmäisen tilakoneen tilasiirtymät on esitetty kuvassa 6.2. Tilakoneen suunnittelun lähtökohtana oli myös käytetty testiautomaatiojärjestelmä, jonka toiminnasta johtuen tilakoneeseen syntyi eräänlainen keskustila, joka ohjaa viestin edelleen sitä vastaavalle tilalle. Ratkaisuun päädyttiin, koska eri toimintojen suoritusjärjestys vaihtelee testitapauksittain, ja koska testiautomaatiojärjestelmä toimii virhetilanteissa siten, että joitakin toimintoja ei välttämättä suoriteta lainkaan. Suunnitellun tilakoneen keskustila hyväksyy kaikki järjestelmän käyttämät viestityypit. Tällä on saatu aikaan lukkiutumaton tilakone, jolloin testitapausjoukon suoritus ei keskeydy, vaikka yksittäinen testitapaus ei toimisikaan odotetulla tavalla. 57

66 START_ALL_OVER Idle START_ACQUISITION START_PLAYBACK StartAcquisition QUIT START_ALL_OVER QUIT WaitCommand StopAcquisition StartComparison Quit ComparisonReady Tilasiirtymät WaitCommand-tilasta tapahtuvat kun tilaa vastaava viesti vastaanotetaan. Kuva 6.2: AATE:n tilakone Testiautomaatiojärjestelmän ja ennustamattoman suoritusjärjestyksen vaikutukset näkyvät vielä selkeämmin järjestelmän toisessa tilakoneessa. Tämä kuvassa 6.3 esitetty tilakone toimii testiautomaatiojärjestelmän kanssa kommunikoinnista huolehtivan moduulin yhteydessä. Testiautomaatiojärjestelmän kanssa kommunikointiin käytettävä protokolla vaatii muun muassa kättelyviestejä, jotka eivät ole AATE:n toiminnan kannalta merkityksellisiä. Näihin viesteihin täytyy kuitenkin vastata, joten niiden käsittely on toteutettava. Lisäksi testiautomaatiojärjestelmä voi lähettää, yleensä testitapauksessa tapahtuneen virheen johdosta, viestejä, joita ei viestin saapumishetkellä olla odottamassa. Tämän vuoksi tilakoneen jokaisesta tilasta on siirtymä alkutilaan. AATE:n tilakoneiden toteutuksiin, kuvan 6.1 AateMessage- ja TasComms-luokkiin, soveltui hyvin käyttäytymismalleihin (behavioral patterns) lukeutuva tilasuunnittelumalli (state pattern). Tilasuunnittelumallin mukainen luokkakaavio on esitetty kuvassa 6.4. Tilasuunnittelumallissa järjestelmän toimintoja kontrolloi tilakone. Jokainen tila (esimerkiksi TilaA) toteuttaa kantaluokassa (AbstraktiTila) määritellyn rajapinnan, jolloin kutsujan ei tarvitse tietää mikä tila käsittelyn kulloinkin hoitaa. Tila, joka kulloinkin on vastuussa toiminnon toteuttamisesta, tietää kokonaistilakoneesta ne osat, joihin kyseisestä tilasta voi olla siirty- 58

67 REMOTE RUN start_acquisition REMOTE RUN stop_acquisition REMOTE RUN start_playback REMOTE RUN start_comparison RESERVE WaitCommand REMOTE REQUEST REMOTE RUN start_playback WaitReserve RESERVE WaitEventRequest RESERVE RELEASE RELEASE WaitRelease Kuva 6.3: Testiautomaatiojärjestelmän kanssa kommunikoivan osan tilakone miä. Tila valitsee saamiensa tietojen perusteella sopivan toimintatavan tai ohjaa käsittelyn jollekin toiselle tilalle. Mikäli tila käynnistää toiminnon suorituksen tai suorittaa toiminnon itse, se asettaa suorituksen jälkeen tilakoneen hallussapidosta vastaavalle moduulille uuden tilan, joka tulee käsittelemään seuraavan komennon. Tilasuunnittelumalli mahdollistaa myös helpon laajennettavuuden, sillä uusien tilojen lisääminen ei vaadi muutoksia olemassaoleviin moduuleihin. (Gamma et al., 1995) Kuva 6.4: Tilasuunnittelumalli (Gamma et al., 1995) 59

68 6.3 Säikeistys Tietoliikenneyhteyden yli tapahtuva kommunikointi testiautomaatiojärjestelmän kanssa aiheuttaa sen, että AATE:n on kyettävä suoriutumaan useista tehtävistä yhtäaikaisesti. AATE:n täytyy kyetä lukemaan saapuvia viestejä, lähettämään vastausviestejä sekä ohjaamaan datankaappauskorttia. Erityisesti kommunikoinnin sujuvuus on tärkeää, sillä testiautomaatiojärjestelmälle on vastattava lyhyehkön ajan sisällä, jotta se huomaa AATE:n olevan vielä käytössä. Ratkaisu näihin ongelmiin on ohjelmiston toteuttaminen monisäikeisenä. Säikeet ovat prosessin sisäisiä skeduloitavia yksiköitä, jotka saavat kukin vuorollaan suoritusaikaa tietokoneen prosessorilta. Näin yksi prosessi kykenee suorittamaan useita tehtäviä näennäisen yhtäaikaisesti. Säikeiden skeduloinnista, eli niiden suoritusjärjestyksestä, huolehtii tietokoneen käyttöjärjestelmä. (Haikala ja Järvinen, 2003) Säikeistyksen toteutukseksi valittiin IEEE-standardoitu POSIX Threads (IEEE, 2004). Kyseinen säietoteutus valittiin siksi, että sen avulla kyettiin toteuttamaan helposti siirrettävä ohjelmisto ja näin täyttämään siirrettävyysvaatimus (alakohta 5.7) myös säikeiden osalta. Microsoft Windows -alustalla POSIX Threads -toteutus ei ole vielä täydellinen, mutta toteuttaa AATE:n käyttöön riittävät ominaisuudet. AATE käyttää jatkuvasti kolmea säiettä. Näistä yhdessä suoritetaan pääohjelmaa, yksi vastaanottaa viestejä testiautomaatiojärjestelmältä ja yksi lähettää viestejä sille. Signaalien vertailu suoritetaan myös omassa säikeessään, joka luodaan ja käynnistetään tarvittaessa. Monisäikeisyys voi aiheuttaa hankaluuksia ohjelmiston toteutukseen. Säikeillä on yhteinen muistiavaruus, ja ne voivat käsitellä samaa tietorakennetta yhtäaikaisesti. Samaan tietorakenteeseen yhtäaikaisesti kohdistuvat tapahtumat voivat aiheuttaa esimerkiksi tiedon häviämistä. Tällaiset niin kutsutut kriittiset alueet tulee monisäikeisessä ohjelmistossa suojata siten, että vain yksi säie saa kerrallaan käsitellä tietorakennetta, jolloin tietorakenteeseen kohdistuvat käskyt suoritetaan loogisesti jakamattomana. (Haikala ja Järvinen, 2003) Edellä kuvattu poissulkemisongelma ratkaistaan käyttämällä kriittisten alueiden suojaukseen semaforeja ja etenkin mutexeja, semaforien erikoistapauksia. Semafori toimii siten, että kriittiselle alueelle pyrkimässä oleva säie yrittää ot- 60

69 taa semaforin haltuunsa. Jos semafori ei ole vapaana, säie siirtyy odotustilaan. Kun semafori vapautuu, säie pääsee jatkamaan suoritustaan kriittiselle alueelle. Semafori sisältää eräänlaisen laskurin, jonka avulla se voi päästää kriittiselle alueelle useampiakin säikeitä kerrallaan. Tälle semaforin ominaisuudelle löytyy hyödyllinen käyttötarkoitus AATE:n kaltaisessa järjestelmässä, jossa pääohjelma on ikuisessa silmukassa. Mutex toimii muuten samoin kuin semafori, mutta mutex ei koskaan päästä enempää kuin yhden säikeen kerrallaan kriittiselle alueelle. (Haikala ja Järvinen, 2003) AATE:ssa poissulkemisongelma ilmenee viestinvälityksessä komponentilta toiselle sekä lokitietojen kirjoittamisessa. Lokitietojen kirjoittamisessa suojauksella varmistetaan, että tiedostoon kohdistuu vain yksi kirjoitusoperaatio kerrallaan. Viestinvälityksen tapauksessa AATE säilyttää saamiaan viestejä viestijonossa, johon muut säikeet voivat lisätä viestejä ja josta AATE lukee niitä. Vastaavanlainen viestijono löytyy myös komponentista, joka huolehtii kommunikoinnista testiautomaatiojärjestelmän kanssa. Molemmat viestijonot on suojattu omilla mutexeillaan, jolloin voidaan varmistaa, että niitä käsittelee vain yksi säie kerrallaan. Viestien käsittelyn yhteydessä käytetään myös semaforeja. Semaforien avulla ikuisessa silmukassa suoritettavat osat saadaan pysähtymään siksi aikaa, kun niille ei ole tekemistä. Kun johonkin viestijonoon tulee uusi viesti, semaforin arvoa kasvatetaan. Viestiä odottava komponentti saa tällöin luvan jatkaa suoritusta. Tämä komponentti jää seuraavaksi odottamaan, että se saa haltuunsa viestijonoa suojaavan mutexin. Mutexin saatuaan komponentti ottaa saamansa viestin viestijonosta ja käsittelee sen. 6.4 Kommunikointi testiautomaatiojärjestelmän kanssa Protokolla ja toteutus AATE muodostaa testiautomaatiojärjestelmän kanssa asiakas-palvelinmallin mukaisen järjestelmän, jossa testiautomaatiojärjestelmä on palvelimena. AATE ottaa käynnistyessään yhteyden testiautomaatiojärjestelmän verkkorajapintaan ja asettuu molemminpuolisen esittelyn jälkeen vapaaksi resurssiksi. Yhteys muodostetaan TCP/IP-yhteyden yli käyttöjärjestelmän tarjoamalla socket-rajapinnalla. 61

70 Kommunikointi järjestelmien välillä tapahtuu käyttäen tekstimuotoista protokollaa, joka toimii sovellustasolla TCP/IP-protokollaperheen päällä. Protokolla on melko yksinkertainen. Protokollan mukaiset viestit koostuvat alkuosassa olevasta merkkijonosta, jossa kerrotaan viestin loppuosan pituus. Pituuden jälkeen tulee erotinmerkki, jota seuraa itse viesti. Viesti sisältää tiedon lähettäjästä ja vastaanottajasta sekä varsinaisen komennon parametreineen. Alla on esimerkki protokollan mukaisesta viestistä. 64#abcd remote run module=start_acquisition testcase=1 AATE käyttää käyttöjärjestelmän tarjoamaa socket-rajapintaa. Nykyään käyttöjärjestelmän tarjoama socket-rajapinta on hyvin samankaltainen käyttöjärjestelmästä riippumatta käytännössä eroja esiintyy joidenkin rajapinnan funktioiden nimissä ja parametreissa. Tämä helpottaa siirrettävän ohjelmakoodin tekemistä, sillä vähäiset erikoistukset voi hoitaa helposti esikääntäjäkomennoilla. AATE:n TasComms-luokka käynnistää kaksi säiettä, joista toinen lukee testiautomaatiojärjestelmältä saapuvia viestejä ja toinen lähettää viestejä sille. Kuvassa 6.5 on yksinkertaistettu sekvenssikaavio testiautomaatiojärjestelmän ja AATE:n sekä AATE:n sisäisten komponenttien välisestä viestinvälityksestä. Kaavio kuvaa AATE:n käynnistymisen sekä yksittäisen testitapauksen suorituksen. Testitapaus koostuu audiodatan tallennuksesta sekä sen vertailusta verrokkidataan Yhteentoimivuuden testaus Testausympäriston kanssa yhteentoimivuuden testaaminen oli monimutkaisin testattavista asioista. Yhteentoimivuus testattiin järjestelmätestausvaiheessa, sillä sitä ei voinut testata luotettavasti ennen kuin kaikki järjestelmän komponentit olivat kunnossa. AATE:n täytyi tätä vaihetta varten kyetä lukemaan testiautomaatiojärjestelmän lähettämät viestit, toimia niiden mukaan sekä lähettää kelvollinen vastaus. Yhteentoimivuuden testaus toimi siten samalla AATE:n sisäisten tilasiirtymien toiminnan testaamisena. Testausta varten toteutettiin palvelinohjelma, joka otti käyttäjältä syötteitä ja lähetti ne edelleen AATE:lle. Vastaavasti se esitti AATE:n lähettämät viestit ruudulla käyttäjälle. Tällä järjestelyllä pystyttiin lähettämään AATE:lle viestejä, jotka eivät olleet protokollan mukaisia tai jotka olisivat aiheuttaneet vir- 62

71 Kuva 6.5: Sekvenssikaavio testiautomaatiojärjestelmän kanssa kommunikoinnista heellisiä tilasiirtymiä. AATE asetettiin tulostamaan saamansa viestit ruudulle, jotta voitiin varmistua siitä, että palvelinohjelma lähettää viestit oikein. AATE testattiin huolellisesti myös testiautomaatiojärjestelmän ohjaamana. Testiautomaatiojärjestelmää ei saa lähettämään suoranaisesti virheellisiä viestejä, mutta 63

72 virheellisiä parametreja tai tilasiirtymiä aiheuttavia viestejä sillä voi lähettää. Protokollan tietynlaisen monimutkaisuuden vuoksi testidatan kehittämiseen käytettiin useampaakin alakohdassa esiteltyä menetelmää. Pohjimmiltaan testaus pohjautui tilasiirtymätestaukseen. Testidata sisälsi eri tavoin virheellisiä viestejä: protokollan mukaisia viestejä, jotka eivät sopineet tilanteeseen tai eivät olleet AATE:lle suunnattuja sekä täysin kelvollisia viestejä virheellisin parametrein. Luonnollisesti myös täysin oikeanlaisia viestejä käytettiin. Yhteentoimivuuden testaamiseen asetettiin ehkä jopa turhan tiukat kriteerit. Reaalimaailmassa testiautomaatiojärjestelmä lähettää virheellisiä viestejä vain, jos se itse menee epäkuntoon, jolloin testaamista ei ole muutenkaan mielekästä jatkaa. Testiautomaatiojärjestelmä on myös jossakin määrin vikasietoinen, ja se kykenee useimmiten toimimaan odotetulla tavalla, vaikka sille toimitettu viesti ei olisikaan täsmälleen protokollan mukainen. 6.5 Audiodatan kaappaus Datankaappauskortin ohjelmointirajapinta Valittua datankaappauskorttia ohjataan kortin valmistajan tarjoaman C-kielisen ohjelmointirajapinnan, NIDAQmx:n avulla. Ohjelmointirajapinta oli alunperin saatavilla vain Microsoft Windows -alustalle, mutta siitä ilmestyi äskettäin myös Linuxille suunnattu versio. Vain C-kielelle tarjolla ollut rajapinta aiheutti joitakin ongelmia AATE:n toteutukseen. Rajallista kaappaustapaa käytettäessä rajapinta istui hyvin C++kielellä toteutettuun AATE:in, mutta tällä tavalla käytettynä kortilla oli mahdollista nauhoittaa korkeintaan 190 sekuntia CD-tasoista stereoaudiota. Rajattoman kaappaustavan käyttö puolestaan vaati vastakutsufunktiota (callback function), joka ei voinut olla luokan jäsenfunktio. Tämän seurauksena vastakutsufunktiosta ei pääse käsittelemään SignalAcquisitionNI-luokan yksityisiä jäsenmuuttujia. Vastakutsufunktiolle sai kuitenkin välitettyä parametrina tietorakenteen, johon kaapattu audiodata on tarkoitus tallentaa. Tämän tietorakenteen alkupäätä käyttämällä myös muiden tarvittavien tietojen välitys vastakutsufunktiolle saatiin toteutettua ilman muutoksia SignalAcquisitionNI-luokan rajapintaan. 64

73 Kuvatulla toteutustavalla jäi vielä ongelmaksi se, että nauhoituksen keskeytyessä dataa saattaa kadota määritellyn kutsuintervallin verran. Tämä ongelma johtuu siitä, että takaisinkutsufunktiota kutsutaan säännöllisin väliajoin. Jos nauhoitus keskeytetään juuri ennen seuraavaa kutsua, jää edellisen kutsun jälkeen kaapattu audiodata lukematta talteen. Ongelma ei kuitenkaan ole kovin merkittävä, sillä valitulla kutsuintervallilla audiodataa katoaa korkeintaan sadasosasekunnin verran Datankaappaustoimintojen testaus Audiodatan kaappaustoimintojen varsinainen, rikkova testaus suoritettiin komentorivikäyttöliittymän avulla. Valinnan perustana oli se, että kyseinen tapa oli huomattavasti nopeampi testaus kuin testiautomaatiojärjestelmän kanssa. Molemmilla tavoilla ohjelmistossa käytetään sisäisesti samaa toimintoa samoin parametrein, joten testiautomaatiojärjestelmän kanssa riitti testata välitettyjen parametrien lukeminen. Audionkaappaustoiminnot tulivat myös testatuiksi testiautomaatiojärjestelmän ohjauksessa testiautomaatiojärjestelmän kanssa kommunikointia testattaessa (kohta 6.4.2). Testitapaukset suunniteltiin käyttäen päätöstaulutestausta (alakohta 2.4.2). Käytettävät arvot valittiin raja-arvoanalyysiä käyttäen. Näitä menetelmiä käyttäen saatiin hyvin kattava joukko testitapauksia. Audiodatan kaappausta varten AA- TE:lle annetaan parametreina käytettävä jännitealue, kanavien lukumäärä, näytteenottotaajuus ja nauhoitusaika sekä muutama valinnainen arvo. Näiden parametrien ja niiden eri arvojen kombinaatioista muodostuu jo kohtuullinen kokoelma testitapauksia. Audiodatan kaappaustoimintojen testauksen yhteydessä varmistettiin myös audiodatan käsittelystä huolehtivien komponenttien toiminta. AATE:n tallentamia signaaleja tutkittiin Audacity-ohjelmistolla. Audacity esittää signaalin graafisesti, jolloin vakavat puutteet on nopea havaita ilman, että signaalia tarvitsee kuunnella. 65

74 6.6 Audiosignaalien vertailu Vertailumetodin toteutus Audiosignaalien vertailuun käytettävä ristikorrelaatio (kaava 5.18) voidaan toteuttaa tehokkaasti nopean Fourier-muunnoksen (FFT) avulla (kaava 5.14). FFT voidaan toteuttaa helposti rekursiivisesti (kaava 5.17). Jokainen rekursiivinen FFT-kutsu suorittaa kaksi rekursiivista FFT-kutsua niin kauan kuin syötteenä on yhden elementin mittainen vektori. Rekursiivisten kutsujen syötevektorit voidaan esittää kuvan 6.6 mukaisena puurakenteena. (Cormen et al., 1992) Kuva 6.6: Rekursiivisten FFT-kutsujen syötevektorit, kun alkuperäisen syötteen pituus n = 8 (Cormen et al., 1992) Rekursiivista FFT:n toteutusta tehokkaampi iteratiivinen toteutus saadaan, jos alkuperäinen syötevektori voidaan järjestää kuvan 6.6 puun lehtiä vastaavaan järjestykseen, niin sanottuun käänteisbittibinäärijärjestykseen (bit-reverse binary order). Tämä tarkoittaa sitä, että jos rev(k) on lgn-bittinen kokonaisluku, joka on saatu kääntämällä k:n binääriesityksen bitit, niin alkuperäisen vektorin elementti a k sijoitetaan vektorin kohtaan A[rev(k)]. Käänteisbittibinäärijärjestys yleisesti tarkoittaa, että puun ylemmällä tasolla indeksit, joiden vähiten merkitsevä bitti on 0, sijoitetaan vasempaan alipuuhun ja indeksit, joiden vähiten merkitsevä bitti on 1, sijoitetaan oikeaan alipuuhun. Tämä toistetaan puun jokaisella tasolla, kunnes puun lehdissä päädytään käänteisbittibinäärijärjestykseen. (Cormen et al., 1992) Esimerkiksi kuvan 6.6 vektorielementtien alkuperäinen järjestys (0, 1, 2, 3, 4, 5, 6, 7), joka on binääriesitykseltään (000, 001, 010, 011, 100, 101, 110, 111), saadaan kuvan 66

75 puunlehdissä käänteisbittibinäärijärjestykessä (0, 4, 2, 6, 1, 5, 3, 7), joka on binääriesitykseltään (000, 100, 010, 110, 001, 101, 011, 111). (Cormen et al., 1992) Iteratiivinen FFT:n toteutus on esitetty pseudokoodina algoritmissa 1. Siinä Bit- Reverse-Copy(a,A) järjestää vektorin a vektoriin A käänteisbittibinäärijärjestykseen, muuttuja s pitää kirjaa kuvan 6.6 puun tasoista saaden arvoja 1:stä (puun alimmalla tasolla, kun yhdistetään parit muodostamaan 2:n elementin DFT:t) arvoon lgn (ylimmällä tasolla, kun yhdistetään kaksi n/2-elementin DFT:tä muodostamaan lopullinen tulos). (Cormen et al., 1992) Iterative-FFT(a) 1: Bit-Reverse-Copy(a, A) 2: n length[a] 3: for s 1 to lgn do 4: m 2 s 5: ω m e j 2π m 6: ω 1 7: for j 0 to m 2 1 do 8: for k j to n 1 by m do 9: t ωa[k + m 2 ] 10: u A[k] 11: A[k] u + t 12: A[k + m 2 ] u t 13: end for 14: ω ωω m 15: end for 16: end for 17: return A Algoritmi 1: Iteratiivinen FFT:n toteutus (Cormen et al., 1992) Suoritusaika algoritmille 1 on Θ(nlgn). Bit-Reverse-Copy(a,A)-kutsu suoriutuu ajassa O(nlgn), koska on mahdollista käydä läpi n vektorin elementtiä ja kääntää kokonaisluku 0 ja n 1 välillä, esitettynä (lgn)-bitillä, ajassa O(nlgn). Täten iteratiivisen FFT:n sisimmän silmukan rivit 9-12 suoritetaan ajassa Θ(nlgn): lgn L(n) = s=1 2 s 1 1 j=0 lgn n 2 = s s=1 n 2 s 2s 1 = lgn s=1 n = Θ(nlgn) (6.1) 2s (Cormen et al., 1992). Algoritmin 1 rivit 7-15 suorittavat niin kutsutun perhosoperaation (butterfly operation), jossa väliaikaismuuttujaan t sijoitettu arvo ωa[k + m ] lisätään ja vähen- 2 67

76 netään arvosta A[k] (kuva 6.7). Näin vältetään arvon ωa[k + m ] kahteen kertaan 2 laskenta, jota kutsutaan kääntäjäterminologiassa yhteiseksi alilauseeksi (common subexpression). (Cormen et al., 1992) Kuva 6.7: Perhosoperaatio: Syötteenä arvot y [0] k, ja y[1] k tulosteena summa ja erotus (Cormen et al., 1992) kerrottuna arvolla ω k n, ja Käänteis-DFT (kaava 5.7) voidaan toteuttaa FFT:n avulla vaihtamalla algoritmissa 1 rivillä 5 potenssin etumerkki (Ifeachor ja Jervis, 2002). Ristikorrelaation laskenta kaavan 5.18 mukaan vaatii kahden reaaliarvoisen signaalin sijoittamisen yhteen kompleksiarvoiseen signaaliin (kaava 5.19), kompleksiarvoisen signaalin FFT:n laskemisen (kaavojen 5.20), reaalisignaalien FFT-arvojen selvittämisen (kaava 5.21) ja näiden keskenään kertomisen, kertolaskutuloksen käänteis-fft:n laskemisen sekä lopputuloksen skaalauksen Vertailumetodin testaus Audiosignaalien vertailu testattiin sekä SignalProcessing-luokan yksikkötestauksen yhteydessä että järjestelmätestausvaiheessa. Taulukossa 6.1 on esitetty yksikkötestausvaiheessa ristikorrelaatiotuloksia alkuperäisen ja testisignaalien välillä, joita verrattiin Matlab ja Octave -ohjelmistojen tuottamiin vastaaviin ristikorrelaatiotuloksiin oikean toiminnallisuuden varmistamiseksi. Matlab ja Octave -ohjelmistot valittiin niiden yleisesti laajan tunnettavuuden ja käytön takia takaamaan luotettavat verrokkitulokset yksikkötestaukselle. Alkuperäisen signaalin autokorrelaatiotuloksen maksimiarvoa verrataan testisignaalien ristikorrelaatiotulosten kynnysarvolla painotettuihin maksimiarvoihin testitapausten hyväksytty-tuloksen päättämiseksi. Käytetyt testisignaalit on esitetty liitteessä B. Testisignaalien valinnan tarkoituksena oli oikean toiminnallisuuden varmistamisen lisäksi testata myös itse ris- 68

77 tikorrelaation ominaisuuksia ja virheellisten signaalien vaikutusta ristikorrelaatiotuloksen maksimiarvoon. Taulukko 6.1: Korrelaatiotulosten maksimiarvot testisignaaleittain alkuperäiseen signaaliin verrattaessa Vertailtava signaali Matlab-tulos AATE-tulos Alkuperäinen signaali (autokorrelaatio) e e+012 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+011 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+012 Testisignaali e e+011 Testisignaali e e+011 Testisignaalit 1 ja 2 sisältävät impulssimaisia virhearvoja. Yksittäinen impulssi on tuskin korvakuulolla havaittavissa eikä vaikuta käytännössä ollenkaan maksimiarvoon. Testisignaalit 3-6 sisältävät eri asteista kohinaa heikosta voimakkaampaan, joka luotiin muuttamalla yksittäisiä näytearvoja satunnaisesti. Kohina on sitä selkeämmin havaittavissa, mitä useampi näytearvo on muuttunut. Testisignaali 7:n tarkoituksena on jäljitellä äänenvoimakkuuden muutosta, joka toteutettiin kaikkien näytearvojen yhtenäisellä pienentämisellä. Testisignaali 8:ssa on signaalin alkuun lisätty viive, joka ei vaikuta korrelaatiotuloksen maksimiarvon suuruuteen, vaan ainoastaan sen sijaintiin tulosvektorissa. Testisignaali 9:ssä on lisätty signaalin näytearvojen keskelle tauko, joka on muutos signaalin alkuperäisessä rakenteessa vaikuttaen ristikorrelaatiotuloksen maksimiarvoon. Testisignaalien tarkoituksena on esittää signaaliarvojen leikkautumista. Näytearvojen leikkautuminen kuulostaa ehkä kuvaavimmin metalliselta kohinalta tai särinältä. Testisignaalien 14 ja 15 avulla tutkittiin tempon muutoksen vaikutusta. Audacity-ohjelmiston avulla toteutettiin 35 prosentin nopeutuksen ja hidastuksen omaavat versiot alkuperäisestä signaalista. 69

78 6.7 Käyttäytyminen virhetilanteissa Virhetilanteissa AATE pyrkii toimimaan hallitusti, tiedottamaan käyttäjää sekä jatkamaan toimintaansa normaalisti. Jos normaalin toiminnan jatkaminen ei ole mahdollista, AATE sammuttaa itsensä ja toimintonsa hallitusti. Syötedata tarkistetaan korruptoituneen tai virheellisen datan varalta ja poikkeukset otetaan kiinni ohjelmistomoduuleissa. Epänormaali käyttäytyminen kirjoitetaan lokitiedostoon muodossa aikaleima moduuli virheen syy. Erityiset virhekoodit lähetetään myös testiautomaatiojärjestelmälle AATE:n tilan ilmoittamiseksi. Mikäli tapahtuu virhe, josta ei voida toipua, AATE lähettää itselleen AateMessage-luokan ilmentymän, joka sisältää lopetuskomennon. Viesti menee käsittelyyn vuorollaan, jolloin käsittelystä huolehtiva Quit-tila lopettaa kaikkien muiden komponenttien toiminnan. Samaa mekanismia käytetään myös silloin, kun käyttäjä lähettää AATE:lle signaalin ohjelman sulkemiseksi. Mikäli lopetusviestin luominen epäonnistuu, AATE havaitsee sen ja sulkeutuu. 70

79 7 Analyysi ja jatkokehitysajatuksia 7.1 Audiosignaalien vertailun soveltuvuus, ongelmat ja rajoitukset Audiodatan käsittely segmenteissä AATE:n audiosignaalien vertailuun käyttämässä ristikorrelaatiossa havaittiin virheettömästä toiminnasta huolimatta muutamia rajoituksia ja ongelmia. Nämä liittyivät pääasiassa audiodatan muuttamiseen optimaaliseen muotoon näytearvoja vääristämättä sekä audiodatan määrän säätelyyn vertailumetodia varten. Vääristyneet näytearvot sekä liian suuret datamäärät aiheuttavat helposti laskutoimituksiin käytettyjen lukuarvojen kasvamisen liian suuriksi, mikä aiheuttaa käytettyjen muuttujien lukualueiden ylittymisen eli niin sanotun ylivuodon. Ylivuodon takia saadaan vertailukelvottomia ristikorrelaatiotuloksia. Rajoittuneesta muistista tai reaaliaikaprosessointivaatimuksesta johtuen signaalinkäsittelysovelluksissa käytetään usein suurten datamäärien käsittelyyn niin sanottua segmentointia (segmentation) tai ikkunointia (windowing). Tällöin käsiteltävä data pilkotaan pienempiin paloihin, joille jokaiselle suoritetaan erikseen haluttu signaalinkäsittelyoperaatio. AATE:ssa segmentointia voidaan soveltaa audiodatan vertailussa. Tallennettu audiodata luetaan tiedostosta riittävän pienissä segmenteissä, joille vertailumetodi, ristikorrelaatio, voidaan suorittaa ilman ylivuodon vaaraa. Tämän jälkeen testitapauksen hyväksymispäätös tehdään segmenttien ristikorrelaatiotulosten pohjalta. Valittaessa vertailtavia segmenttejä verrokkiaudiodatan ja testitapauksen tulosaudiodatan välillä täytyy ottaa huomioon mahdollinen audiosignaalien välinen vaihe-ero signaalien vastinarvojen kohdistamiseksi. Vaihe-ero voidaan selvittää myös ristikorrelaation avulla, jonka tuloksen maksimiarvon sijainti kertoo vaiheeron. Esimerkkinä testauksessa käytetyn alkuperäisen signaalin (liitteen B kuvas- 71

80 sa B-1) sekä testisignaalin 8, eli alkuperäisen signaalin viiveellisen version (liitteen B kuvassa B-3), ristikorrelaatiotulokset on esitetty kuvassa 7.1. Verrattaessa signaalia itseensä sijaitsee ristikorrelaatiotuloksen maksimiarvo tuloksen keskikohdassa, nollaviiveen kohdalla. Verrattaessa signaalia viiveelliseen versioon, sijaitsee ristikorrelaatiotuloksen maksimiarvo tuloksen keskikohdan oikealla puolella, kuvan 7.1 tapauksessa näytearvon päässä ilmoittaen vaihe-eron. Mikäli ristikorrelaatiotuloksen maksimiarvo sijaitsee tuloksen keskikohdan vasemmalla puolella, on kyseessä verrattavan signaalin edistäminen. Kuva 7.1: Alkuperäisen signaalin autokorrelaatiotulos (a) sekä alkuperäisen ja viiveellisen signaalin ristikorrelaatiotulos (b) Segmentointia on mahdollista soveltaa myös audiodatan tallentamisessa. Tällöin audiodata voidaan varastoida sopivan kokoiseen puskuriin, jonka täyttyessä sisältö kirjoitetaan tiedostoon Näytearvojen vaakapoikkeama Eräs havaittu ongelma liittyy testausjärjestelyn laitteistokokoonpanoon, jossa ohjelmointilaite aiheutti audiosignaalin näytearvoihin vaakapoikkeaman (DC offset). Vaakapoikkeama näkyy aikatasolla signaalin amplitudin keskiarvon poikkeamana nolla-arvosta. Kuvassa 7.2 on esitetty tallennettu audiosignaali, jonka näytearvot sijaitsevat vaakapoikkeaman verran vaaka-akselin positiivisella puolella. Poikkeamasta johtuen ristikorrelaatiolaskennassa tulokset kasvavat nopeasti liian suuriksi, mistä seuraa jälleen muuttujien lukualueiden ylivuoto. Vaakapoikkeama voidaan korjata reaaliajassa ylipäästösuotimella. Käytössä ole- 72

81 Kuva 7.2: Vaakapoikkeama kaapatussa signaalissa (a) ja sen korjaus datankaappauskortin avulla (b) va datankaappauskortti tarjoaa tällaisen mahdollisuuden, mutta korjaus aiheutti signaalin alkuun ja loppuun piikin sekä lyhyen siirtymävaiheen, jossa signaali palautuu nollatason ympärille. Tästä johtuen ensimmäiset näytearvot vääristyivät (kuva 7.2). Tilanteessa, jossa koko audiosignaali on saatu tallennettua, voidaan käyttää segmenteissä laskettavaa keskiarvoa paikantamaan vaakapoikkeama. Mikäli peräkkäisten, pienten segmenttien keskiarvojen ero on riittävän suuri, ollaan todennäköisesti vaakapoikkeaman siirtymävaiheessa. Siirtymävaiheiden poiston jälkeen myös itse audiodata voidaan korjata keskiarvon avulla: näytearvot voidaan keskittää nollatason ympärille vähentämällä niistä audiodataarvojen amplitudin keskiarvo. Keskiarvon käyttö on yleinen datan standardointitapa, joka saadaan näytearvoille u n kaavalla: u mean = 1 N N u n, n = 1, 2,..., N. (7.1) k=1 Näytearvot u n on käytännöllistä muuttaa myöhempiä laskutoimituksia varten uuteen joukkoon x n, jonka keskiarvo on nolla kaavalla: (Bendat ja Piersol, 1986) x n = x(t 0 + n t) = u n u mean, n = 1, 2,..., N. (7.2) 73

82 7.2 Käyttökokemukset ja saavutetut hyödyt Käyttöönottovaiheessa lisätyötä aiheutui testiautomaatiojärjestelmän tarvitsemien testiskriptien kirjoittamisesta. Vaikka audiotestien suorittamisesta matkapuhelimessa vastaakin jo olemassa oleva ohjelmisto, vaatii AATE:n mukaan ottaminen kyseisen ohjelmiston ohjaamiseen käytettävien skriptien muokkaamista. Lisäksi tarvitaan vielä erillinen testiskripti, joka synkronoi AATE:n ja puhelimessa suoritettavat testitapaukset, sekä testitapauskohtainen asetustiedosto AATE:lle, jotta sille voidaan välittää riittävät tiedot testitapauksen suorittamisesta. Ristikorrelaation avulla voidaan hylätä kaikki tulokset, jotka poikkeavat verrokkiarvoista. Kynnysarvon avulla hyväksymistarkkuutta voidaan keventää. Koska ristikorrelaatio ei erottele eri virhelähteitä, saattaa kynnysarvon asettaminen olla kuitenkin vaikeaa tilanteissa, joissa esiintyy vähäisesti ristikorrelaatiotulokseen vaikuttavia erilaisia virhelähteitä. Näitä voivat olla impulssit tai kohina, jotka koetaan eri tavalla häiritseviksi. Tästä johtuen todennäköisesti tuleekin tarve AATE:n jatkokehityksessä toteuttaa uusia, audion laatua tarkemmin mittaavia menetelmiä (7.3). AATE:n käyttöönoton myötä tarjoutuu mahdollisuus tehostaa audio-ominaisuuksien testausta. Koska AATE ei vaadi testaajan läsnäoloa, voidaan testitapauksia suorittaa ympäri vuorokauden. Testitapauksia voidaan siten suorittaa enemmän ja useammin. Testauksen tarkkuus voi myös parantua automatisoinnin myötä. Testaajan huomiointikyky saattaa herpaantua ulkoisten ärsykkeiden vuoksi, mutta ohjelmistoa ne eivät häiritse. Tarkkuuden parantuminen kuitenkin edellyttää, että kohdassa 7.1 kuvatut haasteet ratkaistaan. Kuten kohdassa 4.3 kuvattiin, testaukseen käytettävän työajan vähentäminen oli merkittävimpiä syitä automatisointityön aloittamiselle. Vaikka järjestelmä on ollut vasta koekäytössä, voidaan tämän tavoitteen toteutuminen nähdä jo nyt. Erään 39 testitapausta sisältävän testitapausjoukon suorittaminen pelkästään testiautomaatiojärjestelmän avulla vie 38 minuuttia. Tämän lisäksi testaajan on raportoitava tulokset testauksen hallintajärjestelmään. AATE:ia käytettäessä saman testitapausjoukon suorittaminen vie keskitehoisella työasemalla 91 minuuttia. Vaikka suoritukseen käytettävä aika onkin yli kaksinkertainen manuaaliseen suoritukseen verrattuna, näkyy AATE:n käyttö testaajalle siten, että hänellä on 38 minuuttia aikaa johonkin muuhun työhön käytettäväksi. Testaajan ei tarvitse 74

83 myöskään raportoida tuloksia manuaalisesti, jolloin voidaan laskea noin kymmenen minuutin lisäsäästö. Koska kyseinen testitapausjoukko suoritetaan vähintään viisi kertaa kahden viikon aikana, voidaan laskea kahden tunnin säästö viikoittain pelkästään yhden testitapausjoukon automatisoinnin myötä. AATE:lla automatisoitaviksi sopivia testitapausjoukkoja on luonnollisesti useita, mistä johtuen ajan säästö kasvaa yhä merkittävämmäksi. 7.3 Jatkokehitysajatuksia Äänipuheluiden testaus AATE:n tämänhetkistä päätoiminnallisuutta eli ohjattua audiodatan kaappausta ja vertailua voidaan laajentaa matkapuhelimella toistettavien audiotiedostojen ulkopuolelle. Yksi tällainen sovellutus voisi olla äänipuheluiden automaattinen testaus. Äänipuheluita testattaessa tarvitaan kaksi matkapuhelinta. Toisen puhelimen mikrofoniliitäntään kytketään äänilähde, jota testiautomaatiojärjestelmä voi ohjata. Tällainen laajennos olisi melko helposti toteutettavissa AATE:iin. Toinen puhelin kytketään AATE:n ohjaamaan datankaappauskorttiin nykyiseen tapaan. Testiautomaatiojärjestelmän ohjauksessa nämä kaksi puhelinta voisivat avata äänipuhelun, jonka jälkeen AATE soittaisi audiodataa toisen puhelimen mikrofoniin ja nauhoittaisi puhelun yli kulkeneen audion toisesta puhelusta. Tämänhetkisen toteutuksen lisäksi testijärjestely vaatisi ohjattavan äänilähteen toteuttamisen Kuva- ja video-ominaisuuksien testaus Kenties mielenkiintoisin jatkokehitysajatus on AATE:n laajentaminen kuva- ja video-ominaisuuksien testauksen automatisointiin. Audiotestaukseen kehitetty järjestelmä sopii toimintalogiikkansa puolesta hyvin myös visuaalisten ominaisuuksien testaamiseen, mutta laitteisto ja toteutus vaativat lisätyötä. Visuaalisten toimintojen testaaminen on audiotestausta herkempää testausjärjestelyn ulkopuolisille häiriötekijöille. Tällaisessa testauksessa tutkittava kuva olisi kuvattava matkapuhelimen ruudulta, jotta kaikki virheitä mahdollisesti aiheut- 75

84 tavat osat pääsisivät vaikuttamaan kuvan syntymiseen. Järjestelyssä matkapuhelimen näyttöä kuvaava laitteisto täytyisi saada kohdistettua tarkasti, ja ulkopuolelta tuleva valo pitäisi pystyä sulkemaan pois. Tämän tulisi lisäksi onnistua hyvin pienellä vaivalla, koska testattavia laitteita ja ohjelmistokäännöksiä on paljon Signaalien vertailumetodin jatkokehitys Uusien AATE:n sovelluskohteiden tutkimisen lisäksi jatkokehitystä ja -tutkimusta vaativat myös AATE:n käyttämät signaalinkäsittelymenetelmät. Ristikorrelaatio aikatason signaaliarvoille soveltuu vertailumetodiksi vähintäänkin ensimmäisessä vaiheessa audion verifiointia automatisoitaessa. Mikäli käytössä on hyvälaatuiset verrokkisignaalit, soveltuu ristikorrelaatio korvaamaan testaajan korvakuulolla suorittaman verifionnin erityisesti silloin, kun suoritettavia testitapauksia on satoja. Aikatason signaaliarvojen vertailu ristikorrelaatiolla ei kuitenkaan ole täysin riittävä varman vertailutuloksen antamiseen, ja sen tueksi tulisikin ottaa mukaan paremmin audion laatua taajuustasossa mittaavia menetelmiä. Lisäksi voitaisiin hyödyntää ihmiskuuloa tutkivan psykoakustiikan malleja. Psykoakustiikan tavoitteena on sovittaa akustinen ärsyke ja sen tieteelliset ja fysikaaliset ominaisuudet yhteen niiden ihmisessä aiheuttamien psykologisten reaktioiden kanssa. Kaksi ihmiskuuloa hallitsevaa ilmiötä ovat kuuluvuuden minimitaso (mimimum threshold of hearing) ja peittoilmiö (masking). Kuuluvuuden minimitaso kuvaa minimitason, jolla korva havaitsee äänen tietyllä taajuudella, ja se saa arvon 0 db 1 khz taajuudella. Korvan maksimiherkkyys sijaitsee välillä 1-5 khz, jolla voidaan havaita signaaleja useita desibelejä alle verrokkiarvon 0 db, ja on suhteellisen vastaanottamaton matalilla ja korkeilla taajuuksilla. Korvan vaste taajuuksille on logaritminen, esimerkiksi väli Hz havaitaan oktaaviksi, kuten myös väli Hz. Lineaarisesti toinen oktaavi on paljon suurempi, mutta korva kuulee sen samana välinä. (Pohlmann, 1995) Kuvassa 7.3 on esitetty Robinson-Dadsonin äänenvoimakkuuskäyrät, jotka on johdettu testauksen kautta, ja ne kuvaavat taajuuksien joukkoja, jotka kuullaan yhtä voimakkaina. Alin käyrä kuvaa minimiäänenpainetasoa, jonka normaalikuuloinen henkilö havaitsee. Esimerkiksi juuri ja juuri kuultava 30 Hz:n ääni on 60 db voimakkaampi kuin vastaava 4 khz:n ääni. Vaste vaihtelee suhteessa voimakkuuteen: mitä voimakkaampi ääni, sitä tasaisempi käyrä. Käyrät mitataan 76

85 Kuva 7.3: Robinson-Dadson äänenvoimakkuuskäyrät osoittavat, että kuulo on epälineaarinen taajuuden ja äänenvoimakkuuden suhteen. Kuvan käyrät perustuvat psykoakustisiin tutkimuksiin sinisignaaleilla. phon:ssa, joka on käyrän äänenvoimakkuus 1 khz taajuudella. (Pohlmann, 1995) Yleisesti kaksi saman vahvuista, eri taajuuksista ääntä eivät kuulosta yhtä voimakkailta. Kuulon herkkyys laskee korkeilla ja matalilla taajuuksilla. Amplitudin peittoilmiö esiintyy, kun ääni siirtää kuuluvuuden minimitasoa ylöspäin ääntä ympäröivällä taajuusalueella. Kuvassa 7.4 on esitetty tilanne, jossa kaksi ääntä kuuluvat samaan aikaan ja peittoilmiö esiintyy, kun voimakkaampi ääni (peittävä ääni) peittää täysin heikomman äänen (peittyvä ääni). Tästä seuraa, että äänen olemassaolo ei takaa sen kuuluvuutta eikä voi taata, että toiset äänet eivät kuulu. (Pohlmann, 1995) Pelkkiä aikatason signaaliarvoja vertailtaessa vaarana saattaa olla joko virheellisen audiotestin tuloksen hyväksyminen tai oikean tuloksen hylkääminen. Teoriassa on mahdollista, että verrokkisignaaliksi tulisi valittua hyvältä kuulostava signaali, joka pitäisi sisällään korvakuulolla kuulumattoman taajuusarvon. Tällainen verrokkisignaali saattaisi hylätä korvakuulolla hyväksyttävät testitulokset, mikä saattaisi johtaa vaikeasti jäljitettävään virheeseen. On myös mahdollista, että sopiva ihmiskuulon alueella oleva taajuusarvo tuottaa vain pienen muutok- 77

86 Kuva 7.4: Kuuluvuuden minimitaso kuvaa heikoimmat äänet ihmiskorvan kuuloalueella. Peittävä ääni tai häiriö nostaa minimitasoa lokaalisti luoden peittokäyrän. Normaalisti kuultava, peittyvä ääni jää peittokäyrän alle eikä ole kuultavissa. sen ristikorrelaatiolaskennan tulokseen, jolloin saatettaisiin hyväksyä virheellinen testitulos. 78

87 8 Yhteenveto Diplomityön tavoitteena oli ratkaista ongelma eräällä matkapuhelinten ohjelmistotestauksen automatisointiprosessin osa-alueella: audiotestauksen tulosten automaattinen verifiointi. Työ tehtiin ympäristössä, jossa alkujaankin suhtauduttiin testausohjelmistoihin ja niiden kehittämiseen myönteisesti, ja kokonaisuutena työ onnistuikin mielestämme erittäin hyvin. Vaikka joitakin puutteita havaittiin, ohjelmisto saavutti tärkeimmät tavoitteensa. Lopputuloksena saatiin olemassa olevan testiautomaatiojärjestelmän kanssa yhdessä toimiva ja helposti laajennettavissa oleva audiotestien tulosten verifiointiohjelmisto. Ohjelmisto on herättänyt myös kohtuullisesti mielenkiintoa, mikä osaltaan tukee mielipidettämme onnistumisesta. Työn tekeminen oli lisäksi varsin opettavaista, koska tämän kokoluokan ohjelmiston toteuttaminen vaatii huolellista suunnittelua. Suunnittelun ja toteutuksen aikana pääsimme tutustumaan menetelmiin ja tekniikoihin, jotka eivät olleet ennestään meille lainkaan tuttuja. Diplomityön kirjoittamisen myötä syvensimme tietämystämme erityisesti testauksen ja sen automatisoinnin saralla. AATE:n suunnitteluratkaisut ja käytetyt suunnittelumallit osoittautuivat toimiviksi ja hyviksi valinnoiksi. Laajennettavuuden toimivuutta päästiin kokeilemaan jo kehitysvaiheessa muun muassa datankaappauskortin vaihdon yhteydessä, ja erityisesti tilasuunnittelumallin käyttö on jatkokehitysvaiheessa osoittautunut hyväksi valinnaksi. Tilakoneen käyttäminen on mahdollistanut täysin uusien toimintojen ohjaus- ja toimintalogiikan joustavan ja vaivattoman lisäämisen ilman muutoksia muihin vanhempiin moduuleihin. Valittu audiosignaalien vertailumetodi, ristikorrelaatio aikatason näytearvoille, toimii pitkäkestoisessa audioverifioinnissa todennäköisesti luotettavammin kuin testaajan korvakuulolla tekemä verifiointi. On kuitenkin todennäköistä, että se ei yksinään riitä kattavaan audioverifiointiin, ja tulevaisuudessa tuleekin melko varmasti tarve ottaa lisäksi käyttöön laajemmin audion laatua mittaavia menetelmiä, jotka esimerkiksi tutkivat audion eri taajuuskomponentteja ja ottavat huomioon ihmisen kuulon luonteen. Tarkemmat ja monimutkaisemmat audion laatua mittaavat menetelmät vaativat kuitenkin laajempaa erityisosaamista, mikä luokin vaatimuksen ohjelmistotestauksen automatisoinnin toteuttamiselle eri alojen asiantuntijoiden yhteistyönä. 79

88 Lähdeluettelo Bendat, J. ja Piersol, A. (1986). Random Data: Analysis and Measurement Procedures. John Wiley & Sons, Inc. Boer, J. (2003). Game Audio Programming. Charles River Media, Inc. Cormen, T., Leiserson, C. ja Rivest, R. (1992). Introduction to Algorithms. The MIT Press / McGraw-Hill Book Company. Craig, R. ja Jaskiel, S. (2002). Systematic Software Testing. Artech House. Dustin, E., Rashka, J. ja Paul, J. (1999). Automated Software Testing: Introduction, Management and Performance. Addison-Wesley. Fewster, M. (2001). Common mistakes in test automation. Fewster, M. ja Graham, D. (1999). Software Test Automation: Effective Use of Test Execution Tools. ACM Press. Gamma, E., Helm, R., Johnson, R. ja Vlissides, J. (1995). Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley. Haikala, I. ja Järvinen, H.-M. (2003). Käyttöjärjestelmät. Talentum Media Oy. Hedge, P., Hunter, P., Liang, F. ja Reynolds, D. (2002). Monkey testing revisited: Using automated stress testing. IBM ja Microsoft (1991). Multimedia programming interface and data specifications 1.0. IEEE (2004). IEEE Std TM : Standard for Information Technology Portable Operating System Interface (POSIX R ): System Interfaces. Institute of Electrical and Electronics Engineers, Inc. Ifeachor, E. ja Jervis, B. (2002). Digital Signal Processing: A Practical Approach. Prentice Hall. Jorgensen, P. (2002). Software Testing: A Craftsman s Approach. CRC Press. Kaner, C., Bach, J. ja Pettichord, B. (2002). Lessons Learned in Software Testing. John Wiley & Sons, Inc. 80

89 Mikkonen, T. (2004). Mobiiliohjelmointi. Talentum Media Oy. Mosley, D. ja Posey, B. (2002). Just Enough Software Test Automation. Prentice Hall. Myers, G. (2004). The Art of Software Testing. John Wiley & Sons, Inc. Pohlmann, K. C. (1995). Principles of Digital Audio. McGraw-Hill. Pol, M., Teunissen, R. ja van Veenendaal, E. (2002). Software Testing: A Guide to the TMap R Approach. Addison-Wesley. Press, W., Flannery, B., Teukolsky, S. ja Vetterling, W. (1988). Numerical Recipes in C: The Art of Scientific Computing. Cambridge University Press. 81

90 Liitteet A WAVE PCM -otsikkotiedot Alkutavu Koko tavuina Kentän nimi Kuvaus RIFF-otsikkolohko 0 4 Lohkon ID Sisältää kirjaimet RIFF 4 4 Lohkon koko Tiedoston loppuosan koko ilman kahta ensimmäistä kenttää (koko - 8 tavua) 8 4 Formaatti Sisältää kirjaimet WAVE Dataformaatin kuvaava FMT-lohko 12 4 Alilohkon ID Sisältää kirjaimet fmt 16 4 Alilohkon koko Alilohkon loppuosan koko 20 2 Audioformaatti Arvo 1 tarkoittaa PCM-audiota, muut arvot jollakin tavalla pakattua audiota 22 2 Kanavien määrä Monoaudio = 1, stereoaudio = 2 jne Näytteenottotaajuus Hertseinä, esimerkiksi 8000 tai Tavutiheys Lasketaan kaavalla näytteenottotaajuus x kanavien määrä x (bittejä per näyte / 8) 32 2 Blokkikoko Kaikki kanavat sisältävän näyteblokin koko tavuina. Lasketaan kaavalla kanavien määrä x (bittejä per näyte / 8) 34 2 Bittejä per näyte Esimerkiksi 8 tai 16 Audiodatan koon ja itse datan sisältävä datalohko 36 4 Alilohkon ID Sisältää kirjaimet data 40 4 Alilohkon koko Datan koko tavuina. Lasketaan kaavalla näytteiden määrä x kanavien määrä x (bittejä per näyte / 8) 44 * Data Audiodatan näytearvot kanavittain lomitettuna, esimerkiksi stereoaudion tapauksessa joka toinen näyte on oikealle kanavalle ja joka toinen vasemmalle 82

91 B Korrelaatiolaskennan testisignaalit Kuva B-1: Alkuperäinen signaali (a); testisignaali 1, positiivinen ja negatiivinen impulssiarvo indekseissä ja (b); testisignaali 2, positiivisia ja negatiivisia impulssiarvoja (c); ja testisignaali 3, kohinaa luotu joka näytearvo satunnaistamalla (d). 83

92 Kuva B-2: Testisignaali 4, kohinaa luotu joka näytearvo satunnaistamalla (a); testisignaali 5, kohinaa luotu joka 100. näytearvo satunnaistamalla (b); testisignaali 6, kohinaa luotu joka 50. näytearvo satunnaistamalla (c); ja testisignaali 7, äänenvoimakkuuden laskeminen (d). 84

93 Kuva B-3: Testisignaali 8, viive signaalin alussa (a); testisignaali 9, tauko signaalin puolessa välissä (b); testisignaali 10, positiivisten ja negatiivisten näytearvojen leikkaus amplitudin arvosta (c); ja testisignaali 11, positiivisten ja negatiivisten näytearvojen leikkaus amplitudin arvosta (d). 85

94 Kuva B-4: Testisignaali 12, positiivisten ja negatiivisten näytearvojen leikkaus amplitudin arvosta 5000 (a); testisignaali 13, positiivisten ja negatiivisten näytearvojen leikkaus amplitudin arvosta 2500 (b); testisignaali 14, 35 prosentin tempon nopeutus (c); ja testisignaali 15, 35 prosentin tempon hidastus (d). 86