Ohjelmiston testaussuunnitelma

Ohjelmiston testaussuunnitelma Ryhmän nimi: Crossing Tekijät: Timo Nummenmaa (PM) Aki Mäkinen Jussi Rantala Rami Saarinen Harri Smått Toimeksiantaja: Timo Poranen (UTA) Muutospäivämäärä: 12.2. 2005 Versio: 1.0.0 1

Sisällysluettelo 1 Johdanto...3 1.1 Tavoitteet... 3 1.2 Laajuuslausunto... 3 1.3 Tärkeimmät rajoitteet...3 2 Testaussuunnitelma... 4 2.1 Testattava ohjelmisto... 4 2.2 Testaamisstrategia...4 2.2.1 Yksikkötestaus... 4 2.2.2 Integrointitestaus... 4 2.2.3 Järjestelmätestaus...5 2.3 Testausresurssit ja -miehitys...5 2.4 Testaustyön tulokset...5 2.5 Testausrekisteri... 5 2.6 Testausmetriikat...6 2.7 Testaustyökalut... 6 3 Testausmenettely... 6 3.1 Testattava ohjelmisto... 6 3.2 Testausmenetelmä...7 3.2.1 Yksikkötestitapaukset... 7 3.2.1.1 Algoritmi... 7 3.2.1.2 Graph...8 3.2.1.3 Node... 10 3.2.1.4 Edge...11 3.2.1.5 IO-luokka...11 3.2.2 Integrointitestaus... 12 3.2.2.1 CAAlgorithm...12 3.2.2.2 SA...13 3.2.3 Järjestelmätestaus...13 3.3 Testauksen kirjanpito ja testiloki... 13 4 Liitteet...14 4.1 Versiohistoria...14 2

1 Johdanto Testaussuunnitelmadokumentin tavoitteena on kuvata järjestelmälle suoritettavat testit ja näiden odotetut tulokset. 1.1 Tavoitteet en tavoitteet ovat seuraavat: Graafien käsittelyyn käytetyt algoritmit testataan huolellisesti. Tässä käytetään apuna vanhaa apptopinv-ohjelmaa ja projektin asiakkaan antamia testejä. Yksittäiset funktiot testataan pääasiallisesti toteutuksen aikana. Apuna käytetään erityisesti yksikkötestaukseen tarkoitettua ohjelmistoa. GTL:n ja omien osien välinen toiminta testataan. Tämä testaus liittyy läheisesti ensimmäiseen kohtaan. Pyrimme testaamaan myös kirjaston toimivuutta. Tätä varten teemme muutaman testiohjelman, joilla käytetään UTAG:tä. Ohjelman tehokkuudelle ei oikeastaan ole asetettu rajoja, mutta pyrimme pääsemään apptopinv:n tehokkuuteen. 1.2 Laajuuslausunto Ohjelma tullaan testaamaan graafien käsittelyn kannalta läpikotaisin. SA-, CA-, CA1-, CA2- ja greedy-algoritmien testaamiseen käytetään asiakkaalta saatua artikkelia sekä testigraafeja. Samoja testigraafeja käytetään myös algoritmeihin, jotka liittyvät risteämäarvon minimointiin. Risteämäarvon minimointiongelmissa käytetään lisäksi täydellisiä ja täydellisiä kaksijakoisia graafeja. GTL-kirjastoa ei testata erikseen. Sen toiminta UTAG:n rinnalla tulee kuitenkin testattua eri testivaiheissa. 1.3 Tärkeimmät rajoitteet Liiketoiminnalliset tai tekniset seikat eivät aseta suurempia rajoitteita testaukselle. Suurimmat rajoitteet testauksen suhteen ovat lähinnä henkilöstöön liittyviä; ohjelmiston luonteen vuoksi testattavaa riittäisi todella pitkäksi ajaksi. Pyrimme testaamaan kaikki olennaisimmat algoritmit ja toteutukset niin huolellisesti kuin mahdollista. Lisäksi SA-algoritmin ajoaika kasvaa syötegraafin koon mukaan varsin nopeasti, jolloin sen testaaminen vaikeutuu. Voikin olla, että testaus suurimpia syötteitä käyttäen joudutaan aikataulusyistä jättämään pois. 3

2 Testaussuunnitelma Tässä luvussa käsittelemme testistrategiaamme käymällä läpi käytettävät testaustavat. Luvussa kolme käsittelemme todellisia testitapauksia. 2.1 Testattava ohjelmisto Ohjelmisto on ehkä väärä sana tässä yhteydessä. Testaamme graafitutkimukseen tarkoitetun UTAG-kirjaston algoritmeja sekä graafien käsittelemiseen tarvittavia yksittäisiä komponentteja ja funktioita. 2.2 Testaamisstrategia 2.2.1 Yksikkötestaus UTAG:n testaamistrategia on kolmitahoinen, eli testauksessa käytetään v-mallia. Alimmalla ja aktiivisimmalla tasolla on yksinkertainen yksikkötestaus, jossa erilliset ohjelmistokomponentit testataan yleisen toiminnallisuuden ja oikeellisuuden mukaan. Jokaiselle komponentille luodaan omat testinsä, jotka ajetaan aina, kun järjestelmään on tehty suurempia muutoksia tai vähintään kerran viikossa. Komponentin testin tulee testata tämän koko toiminnallisuus siten, että voidaan yksiselitteisesti ja automatisoidusti todeta, toimiiko komponentti odotetulla tavalla vai ei. Jokainen peruspolku tulee siis testattua, eli toisin sanoen esimerkiksi kokeillaan jokainen looginen vaihtoehto sekä true- että false-vaihtoehdolla. Projekti käyttää yksikkötesteihin CPPUnit-nimistä yksikkötestausohjelmistoa. Viikottaisten yksikkötestien tulokset julkaistaan projektin kotisivuilla. 2.2.2 Integrointitestaus Keskimmäisellä tasolla testataan valmiiden kokonaisuuksien toimivuutta. Voidaan esimerkiksi testata algoritmin toimivuutta sellaisilla graafeilla, joihin kyseisen algoritmin tulokset ovat tiedossa. Koska kyseessä on usein NP-täydellinen ongelma, optimaalisia tuloksia on harvemmin saatavilla. Tällöin olemassa olevat tulokset antavat kuitenkin ohjenuoran siitä, minkä suuntaisia tulosten pitäisi olla. Lisäksi voidaan vertailla algoritmin ajoaikaa aiempiin vastaavan algoritmin toteutuksiin (esim. Timo Porasen apptopinv-ohjelma). Tällä tasolla testejä suoritetaan harvemmin kuin yksikkötestaustasolla: ehkä noin 1-3 kertaa kuukaudessa. 4

2.2.3 Järjestelmätestaus Korkeimmalla tasolla on järjestelmätestaus. Projektissa luodaan muutama erillinen UTAGkirjastoa käyttävä ohjelma. Nämä ohjelmat tarjoavat monia hyödyllisiä kehitystilanteita. Ensinnäkin näemme, onko kirjaston käyttö yksinkertaista. Toiseksi näin voimme tarjota aitoja esimerkkejä kirjaston oikeanlaisesta ja tehokkaasta käytöstä. Lisäksi pystymme kartoittamaan kirjaston toimivuuttaa varsinaista sovellusta apuna käyttäen. On hyvinkin mahdollista, että näistä testeistä tulee muutosvaatimuksia kirjaston arkkitehtuuriin. Tällä tasolla ei niinkään testata suoritusaikaa tms., vaan keskitytään kaikkien ohjelmistokomponenttien integrointiin eheäksi ohjelmaksi. Tällainen ohjelma todennäköisesti ratkaisee tietyn tyylisen graafiongelman (mops, mps yms.). Täten voidaan ajaa toisen tason testejä vastaavat testit myös valmiille ohjelmille valmiilla materiaalilla. 2.3 Testausresurssit ja -miehitys Testausmiehitykseen kuuluu koko Crossing-ryhmän jäsenistö, johon kuuluvat siis projektimanageri Timo Nummenmaa sekä Aki Mäkinen, Jussi Rantala, Rami Saarinen ja Harri Smått. 2.4 Testaustyön tulokset Testausstrategia johtaa seuraaviin työtuloksiin: Testaussuunnitelma. Tämä dokumentti kuvaa ohjelmiston testausstrategian ja sen soveltamisen toteutuksen eri vaiheissa. tapaukset. Nämä määrittelevät yksityiskohtaisesti jokaisen testityypin. lokit. Automatisoidut testit ajetaan kerran viikossa. Lisäksi eri komponenttien yhdistämisen tai muiden merkittävien muutosten yhteydessä voidaan testit ajaa useamminkin. raportit. lokien perusteella kirjoitetaan erilliset raportit, joissa esitellään testiajoista saadut tulokset muodossa, jonka perusteella on mahdollisimman helppoa tehdä tarvittavat muutokset. 2.5 Testausrekisteri Koko ohjelmiston kattavat automatisoidut testit ajetaan kerran viikossa ja testeistä saadut 5

tulokset laitetaan raporttimaisessa muodossa projektin kotisivuille 1. Lisäksi rekisteriin voidaan tallentaa viikottaisten testiajojen lisäksi muitakin tärkeiksi koettuja testituloksia. 2.6 Testausmetriikat Yksikkötestit ovat pääosin melko yksinkertaisia ja näin luonteeltaan sellaisia, että niiltä voidaan odottaa tietynlaisia tuloksia. Toteutetulle komponentille ajetaan testi, jonka perusteella nähdään yksiselitteisesti se, toimiiko testattava osa halutulla tavalla. Algoritmien tapauksessa tarkkoja vaatimuksia tuloksille ei voida asettaa. Voimme vain verrata niitä aikaisemman apptopinv-ohjelman vastaaviin tai muuten yleisesti tiedossa oleviin aikarajoihin. 2.7 Testaustyökalut Testauksen perustyökaluna käytetään yksikkötestaukseen (Unit test) tarkoitettua CPPUnitnimistä 2 ohjelmaa. Ohjelmalla luodaan yksinkertaisia testirutiineja, joille määritellään tulokseksi haluttava vakio. Samaa dataa tai komponentteja käyttävät testit niputetaan yleensä testijoukkoihin (fixture). joukossa voidaan samoja komponentteja ja dataa jakaa testirutiinien kesken. joukoista voidaan koostaa sarjoja (suite), joiden ajaminen ja raportointi voidaan pitkälti automatisoida. Yksikkötestauksen avulla nähdään välittömästi, jos tehdyt muutokset vaikuttavat vahingollisesti jo tehtyihin kokonaisuuksiin. Täten ohjelmiston laatua ja sisäistä eheyttä on helpompi valvoa. 3 Testausmenettely Tässä luvussa kuvataan testausstrategian soveltamista omassa ohjelmassamme sekä esitellään esimerkkitestitapauksia. 3.1 Testattava ohjelmisto Testauksen pääpaino on UTAG-kirjaston algoritmien ja apukomponenttien testauksessa. Kirjastosta löytyvien algoritmien käyttämiseksi tullaan toteuttamaan yksinkertainen sovellus, joka toimii komentopohjaisesti. Tämän osan toimivuus testataan toteutuksen yhteydessä. Lisäksi GTL-kirjasto tulee testattua osin. 1 http://www.uta.fi/~jr69996/crossing/testaus.html 2 http://cppunit.sourceforge.net/cgi-bin/moin.cgi 6

3.2 Testausmenetelmä Projektissa valitaan henkilö, joka suorittaa viikottaiset yksikkötestaukset ja jakelee tulokset ryhmän muille jäsenille. Tulokset julkaistaan projektiryhmän kotisivuilla. Kun jokin toiminnallisuuskokonaisuus saadaan rakennettua ja perinpohjin testattua, kirjoitetaan erillinen testausmuistio aiempien muistioiden pohjalta. Tämä muistio julkaistaan jälleen projektin kotisivuilla ja lisäksi se toimitetaan asiakkaalle tarkempaa tutustumista varten. 3.2.1 Yksikkötestitapaukset en on tarkoitus simuloida jollain tasolla yksinkertaisia potentiaalisia käyttötapauksia. Kaikkia mahdollisia käskykombinaatioita ei testata projektin puitteissa, koska testaus muuttuisi hyvin nopeasti GTL:n testaamiseksi. Kuormitustestejä ei myöskään suoriteta esimerkiksi luomalla graafi, jossa on miljoona solmua. Testauksella pyritään lähinnä varmistamaan, että kirjasto toimii dokumentoidulla tavalla tulevaa algoritmien toteuttamista varten. 3.2.1.1 Algoritmi Algoritmi-luokan edustajille tehdään algoritmikohtaiset yksikkötestit. Koska projektissa saatetaan kehittää useampia myöhemmin päätettäviä algoritmeja, on tässä syytä kuvata yleiset toimintakäytännöt algoritmien testaamiseksi. Ne algoritmit, jotka palauttavat eksplisiittisesti todistettavan tai optimin ratkaisun, voidaan testata tavallisella yksikkötestillä (modulitestillä), joka kartoittaa algoritmin toimintaa kattavalla syötemäärällä. Mikäli algoritmi käyttää toista algoritmia oleellisena osana toimintaansa (esimerkiksi simuloitu jäähdytys), tulee toisesta algoritmista tehdä tyhmä versio, joka toimii ennalta määrättävällä tavalla, jolloin voidaan yksikkötestissä keskittyä itse testattavaan algoritmiin. Integraatiotestauksessa testataan algoritmien yhteistoiminta määrätyillä syötteillä, joista on tiedossa optimit tai vähintäänkin lähellä optimia olevat ratkaisut. Mikäli algoritmi on NP-täydellinen tai muuten jotain heuristiikkaa noudattava, tulee algoritmin yksikkötestauksen keskittyä algoritmin sellaisiin syötteisiin, joista saadaan optimitulos. Jos tiedettyä optimaalista tulosta ei saada millään syötteellä, keskitytään algoritmin 7

perustoiminnan testaamiseen ja suoritetaan vasinainen toiminnallisuus integraatiotestauksen yhteydessä sellaisella syötteellä, josta on saatavilla lähes optimaaliset tulokset. Jos algoritmi käyttää toista algoritmia yksikkötestauksessa, tulee tämän algoritmin yksikkötestaus suorittaa ennen tämän algoritmin yksikkötestiä. Olisi hyvä, jos testi suoritettaisiin manuaalisesti. Esimerkiksi graafin latausta tietystä formaatista voidaan testata siten, että testi aluksi tallettaa luodun graafin kyseisellä formaatilla ja sen jälkeen lataa sen. Olisi silti pyrittävä minimoimaan vastaavien testien määrä. 3.2.1.2 Graph Jokaista testiä ennen luodaan uusi graafi G. Graafiin lisätään solmut node1, node2 ja node3 sekä kaaret edge1 solmujen node1->node2 ja edge2 solmujen node1->node3 välille. Jokaisen testin jälkeen graafi tuhotaan. int Graph::number_of_nodes() testnumberofnodes1 G->number_of_nodes() == 3 testnumberofnodes2 G->del_node(node1) G->number_of_nodes() == 2 testnumberofnodes3 G->hide_node(node2) G->number_of_nodes() == 2 testnumberofnodes4 G->hide_node(node3) G->restore_graph() G->number_of_nodes() == 3 testnumberofnodes5 G->clear() G->number_of_nodes() == 0 int Graph::number_of_edges() testnumberofedges1 G->number_of_edges() == 2 testnumberofedges2 G->del_edge(edge2) G->number_of_edges() == 1 testnumberofedges3 G->hide_edge(edge1) G->number_of_edges() == 1 testnumberofedges4 8

G->hide_edge(edge2) G->restore_graph() G->number_of_edges() == 2 testnumberofedges5 G->clear() G->number_of_edges() == 0 list<node> Graph::nodes() testnodes1 G->nodes() palauttama lista sisältää kaikki kolme solmua ja ainoastaan ne (vertailu == operaattorilla) testnodes2 G->hide_node(node2) G->nodes() palauttama lista sisältää node1 ja node3, ja ainoastaan ne (vertailu == operaattorilla) testnodes3 G->clear() G->nodes().size() == 0 list<edge> Graph::edges() testedges1 G->edges() palauttama lista sisältää kaaret edge1 ja edge2, ja ainoastaan ne (vertailu == operaattorilla) testedges2 G->hide_node(node2) G->edges() palauttama lista sisältää ainoastaan edge2:n (vertailu == operaattorilla) testedges3 G->clear() G->edges().size() == 0 list<node> Graph::all_nodes() testallnodes1 G->all_nodes() palauttama lista sisältää kaikki kolme solmua ja ainoastaan ne (vertailu == operaattorilla) testallnodes2 G->hide_node(node3) G->all_nodes() palauttama lista sisältää kaikki kolme solmua ja ainoastaan ne (vertailu == operaattorilla) testallnodes3 G->clear() G->all_nodes().size() == 0 list<edge> Graph::all_edges() testalledges1 G->all_edges() palauttama lista sisältää kaaret edge1 ja edge2, ja ainoastaan ne (vertailu == operaattorilla) 9

testalledges2 G->hide_node(node2) G->all_edges() palauttama lista sisältää kaaret edge1 ja edge2, ja ainoastaan ne (vertailu == operaattorilla) testalledges3 G->clear() G->all_edges().size() == 0 3.2.1.3 Node Jokaista testiä ennen luodaan uusi graafi G. Graafiin lisätään kolme solmua node1, node2 ja node3. Graafiin lisätään kaksi kaarta solmujen node1->node2 ja node1->node3 välille. Jokaisen testin jälkeen graafi tuhotaan. testcompare1 node1 == node1 && node2 == node2 && node3 == node3 testcompare2 node2!= node3 && node3!= node2 testishidden1 G->hide_node(node2) node2.is_hidden() == true testishidden2 G->hide_node(node2) G->restore_node(node2) node2.is_hidden() == false testdegree1 node1.degree() == 2 testdegree2 G->hide_node(node2) node1.degree() == 1 Test Test Test Test testadjnodes1 node1.adj_nodes() palauttama lista sisältää vain ja ainoastaan node2 ja node3 (vertailu == operaattorilla) testadjnodes2 node2->adj_node() palauttama lista sisältää vain ja ainoastaan node1 (vertailu == operaattorilla) testadjedges1 node1.adj_edges() palauttama lista sisältää vain ja ainoastaan edge1 ja edge2 (vertailu == operaattorilla) testadjedges2 node3.adj_edges() palauttama lista sisältää vain ja ainoastaan edge2 (vertailu == operaattorilla) 10

3.2.1.4 Edge Jokaista testiä ennen luodaan uusi graafi G. Graafiin lisätään kolme solmua node1, node2 ja node3. Graafiin lisätään kaksi kaarta solmujen node1->node2 ja node1->node3 välille. Jokaisen testin jälkeen graafi tuhotaan. testcompare1 edge1 == edge1 && edge2 == edge2 testcompare2 edge1!= edge2 && edge2!= edge1 testsource1 edge1.source() == node1 testsource2 edge1.change_source(node3) edge1.source() == node3 testtarget1 edge2.target() == node3 testtarget2 Node node4 = G->new_node() edge2.change_target(node4) edge2.target() == node4 testishidden1 edge2.is_hidden() == false testishidden2 G->hide_edge(edge2) edge2.is_hidden() == true 3.2.1.5 IO-luokka Projektissa luodaan tuki ainakin kolmelle eri tiedostoformaatille. Tiedostoformaatit kuuluvat IO-kategoriaan. Lopullista IO-luokkien määrä ja laatua ei vielä tässä vaiheessa osata ennustaa. Esimerkkinä IO luokan yksikkötestistä annetaan ohessa GMLIO-luokan yksikkötestin lyhyt kuvaus. GMLIO käsittelee GML-formaattia. GMLIO luokan toimivuutta voidaan testata siten, että ensiksi luodaan jokin graafi ja tallennetaan se GMLIO:ta käyttäen. Tämän jälkeen juuri tallennettu graafi ladataan ja todetaan sen samankaltaisuus alkuperäisen kanssa. 11

IO:n latausoperaatiota voidaan myös testata erikeen jo olemassa olevilla tiedostoon tallennetuilla graafeilla. Tässä tapauksessa testit pitää räätälöidä graafien mukaan. : GMLIO1 : Graph g; GMLIO.load(g, graph.gml ); Testaus: Tutkitaan, vastaako ladattu graafi tiedostoon tallennettua. : GMLIO2 : Rakennetaan graafi g; GMLIO.save(g, graph.gml ); Graph h; GMLIO.load(h, graph.gml ); Testaus: g==h; IO:n latausoperaatiota voidaan myös testata erikeen jo olemassa olevilla tiedostoon tallennetuilla graafeilla. Tässä tapauksessa testit pitää räätälöidä graafien mukaan. 3.2.2 Integrointitestaus Integraatiotestit, joissa siis testataan eri komponenttien yhteensopivuutta, kuten kahden algortimin yhteispeliä, suoritetaan projetin kaikkien jäsenten läsnäollessa (ellei toisin erikseen sovita). On luultavaa, että testaustilanteessa on nähtävissä erilaisia rooleja. Kun nämä ollaan tunnistettu, niin voidaan voidaan edeltäkäsin nimetä henkilöt tiettyihin rooleihin (testin ajaja, suoritusajan tarkastelija jne.). n tuloksista kirjoitetaan lyhyt muistio ja se julkaistaan projektin kotisivulla. Kun jokin toiminnallisuuskokonaisuus saadaan rakennettua ja perinpohjin testattua, kirjoitetaan erillinen testausmuistio aiempien muistioiden pohjalta. Tämä muistio julkaistaan jälleen projektin kotisivuilla ja lisäksi se toimitetaan asiakkaalle tarkempaa tutustumista varten. Integraatiotestattaville komponenteille pyritään laatimaan automatisoidut testit, mutta koska on kyse pääsääntöisesti NP-täydellisten ongelmien heuristiikoista, tarvinnee integraatiotestaus suorittaa manuaalisesti syötteellä, johon on saatavilla optimit tai lähes optimit tulokset. Mikäli automatisoituja testejä saadaan aikaiseksi, lisätään ne tähän dokumentiin myöhemmin. Muussa tapauksessa testikokonaisuudelle laaditaan testikehys, jossa testi määritellään yksityiskohtaisesti. kehyksestä tulisi ilmetä testissä käytettävät syötteet ja niitä vastaavat 12

odotettavat tulokset, testattavat komponentit, mahdolliset tilanteeseen rakennetut testiohjelmat ja niiden käyttöohjeet ja lyhyt kuvaus testin kulusta. Ohessa esimerkkeinä lyhyet kuvaukset siitä, mitä kahden kahden eri algoritmin integraatiotestauksessa saatetaan toimia. 3.2.2.1 CAAlgorithm Kaktuspuu heuristiikassa (triangular cactus heuristic, CA) etsitään graafista syklejä, jotka ovat kolmion muotoisia. Lopuksi saatuun aligraafiin lisätään jäljellä olevia kaaria, kunnes graafi on yhdistetty. Kyseessä on approksimointialgoritmi, joten optimaalista tulosta ei välttämättä ole ollenkaan saatavilla. Mikäli on olemassa graafeja, joille CA voidaan suorittaa optimaalisesti, voidaan näistä tapauksista tehdä CA:n yksikkötesti. Tämän lisäksi CA:ta testataan valitulla, mahdollisimman heterogeenisellä, graafijoukolla, jonka graafeista on saatavilla lähes optimit tulokset. CA ajetaan näitä tuloksia vasten ja manuaalisesti todetaan algoritmin toimivuus. Tässä yhteydessä voidaan myös ottaa ylös algoritmin suoritusaikoja ja verrata niitä esimerkiksi apptopinv-ohjelman vastaaviin aikoihin. 3.2.2.2 SA Simuloitua jäähdytystä käytetään parantamaan jonkin toisen algoritmin tulosta. UTAGkirjastossa SA-algoritmille tulee asettaa alkutuloksen antava algoritmi (esim. CAAlgorithm). Tällöin on kyseessä kahden erillisen algoritmin yhteistoiminta, eikä vastaavan kokonaisuuden modulitestaaminen ole mielekästä. Kuten modulitestaamisen yhteydessä annetussa algoritmien yleisessä testausskenaariossa kuvattiin, tulisi algoritmeille suorittaa erilliset modulitestit, mikäli mahdollista. Silloin SA:n perustoiminnallisuuden testaamiseen luodaan testialgoritmi, joka antaa ennalta määrättyjä vastauksia. Tällöin toisen algoritmin toiminta ei haittaa SA:n testaamista. SA on kuitenkin satunnaistettu algoritmi, joten se ei anna selkeästi mitattavia tuloksia. Täten SA:n yksikkötestaus jääkin vähäiseksi. SA:n integraatiotestauksessa käytetään oikeaa algoritmia alkutuloksen saamiseksi. Jos esimerkiksi käytettäisiin CA:ta, voitaisiin integraatiotestauksessa tarkastella pelkän CA:n antamia tuloksia SA:n antamiin tuloksiin. SA:n tulisi parantaa tulosta. ssä pitää luonnollisesti olla hyväksyttävät ja lähes optimit tulokset annetuille syötteille. Vertailukohteena voidaan myös käyttää apptopinv-ohjelman vastaavia tuloksia. SA:n toiminta-aika voidaan myös mitata ja verrata. 3.2.3 Järjestelmätestaus Järjestelmätestaus suoritetaan kuten integraatiotestaus. tilanteessa tutkitaan myös 13

ohjelman käytettävyyttä ja sen sopivuutta kirjaston käyttöesimerkiksi. On mahdollista, että testeissä muodostuu ohjelmalle dokumentaatiota. Myös tämän tason testeistä kirjoitetaan lyhyt muistio ja se julkaistaan projektin kotisivuilla. Järjestelmätestausta projektissa ei juuri ole seuraavia komentoriviohjelmia lukuunottamatta. MPS- ja MOPS-ohjelmat toimivat sekä konkreettisina ohjelmina, jotka on rakennettu kirjaston päälle, että yksittäisinä isompina esimerkkitapauksina UTAG-kirjaston käytöstä. Maksimaalisen ulkotasograafin (MOPS) ja maksimaalisen tasograafin (MPS) laskevien ohjelmien testaus suoritetaan samalla tavalla kuin pääosa integraatiotestakesesta. Ohjelmilla ratkotaan ennaltamäärätyn graafijoukon taso- ja ulkotasograafit ja tuloksia ja suoritusaikoja verrataan olemassa oleviin tuloksiin (esim. apptopinv). t pitää suorittaa kaikille asianmukaisille algoritmeille, jotka on liitetty osaksi ohjelmien toimintaa (CA, CA1, GCA jne.). 3.3 Testauksen kirjanpito ja testiloki Yksikkötestausohjelma CPPUnit antaa tulokset määritellyistä testiajoista XML-muodossa. Nämä voidaan tallentaa ja arkistoida sellaisenaan tai muuntaa soveltuvalla ohjelmalla HTMLmuotoon, jolloin ne saataisiin suoraan näkyviin projektisivustolle. Lisäksi jokaisesta testiajokokonaisuudesta luodaan käsin kirjoitettu raportti, johon kootaan merkittävimmät testitulokset. Näiden perusteella voidaan suunnitella korjauksia tai muutoksia toteutuksiimme. 4 Liitteet 4.1 Versiohistoria Päivämäärä: Versio: Tekijät: Muutokset: 10.01. 2005 0.9.0 Timo Nummenmaa Aki Mäkinen Jussi Rantala Rami Saarinen Harri Smått Tämä dokumentti. 12.01. 2005 1.0.0 Rami Saarinen Muokattu kappaleita 3.2.1.5 ja 3.2.3 + korjattu muutama kirjoitusvirhe (Aki Mäkinen) 14

15