Ohjelmiston testaussuunnitelma

Transkriptio

1 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ä: Versio:

2 Sisällysluettelo 1 Johdanto Tavoitteet Laajuuslausunto Tärkeimmät rajoitteet Testaussuunnitelma Testattava ohjelmisto Testaamisstrategia Yksikkötestaus Integrointitestaus Järjestelmätestaus Testausresurssit ja -miehitys Testaustyön tulokset Testausrekisteri Testausmetriikat Testaustyökalut Testauksen aikataulu Testausmenettely Testattava ohjelmisto Testausmenetelmä Yksikkötestitapaukset Algoritmi Graph Node Edge FileIO-luokka Integrointitestaus CAAlgorithm SA Hyväksymistestaus Järjestelmätestaus Testauksen kirjanpito ja testiloki Liitteet

3 Liite 1 Versiohistoria Liite 2 MPS suoritusarvoja Liite 3 MOPS suoritusarvoja

4 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. UTAG on riippuvainen kolmannen osapuolen kirjastosta GTL. Projektissa pyritään testaamaan UTAG:n toiminnallisuutta ja täten GTL tulee testattua vain niiltä osin mitä UTAG käyttää toimintansa tukena. 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 4

5 olla, että testaus suurimpia syötteitä käyttäen joudutaan aikataulusyistä jättämään pois. 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 Testaamme graafitutkimukseen tarkoitetun UTAG-kirjaston algoritmeja sekä graafien käsittelemiseen tarvittavia yksittäisiä komponentteja ja funktioita. 2.2 Testaamisstrategia 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. Mitään täsmällistä viikonpäivää ei testeille kuitenkaan ole, joten testeja ei suoriteta täsmälleen viikon välein. Komponentin testii testaa tämän koko toiminnallisuus siten, että voidaan yksiselitteisesti ja automatisoidusti todeta, toimiiko komponentti odotetulla tavalla vai ei. Komponentin suorituksen kaikki mahdolliset peruspolut 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 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 5

6 vastaavan algoritmin toteutuksiin (esim. Timo Porasen apptopinv-ohjelma). Tällä tasolla testejä suoritetaan harvemmin kuin yksikkötestaustasolla: ehkä noin 1-3 kertaa kuukaudessa 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 noin 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. 6

7 2.5 Testausrekisteri Koko ohjelmiston kattavat automatisoidut testit ajetaan noin kerran viikossa ja testeistä saadut 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ötesteiltä voidaan odottaa tietynlaisia mitattavia ja verrattavissa olevia 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 testata samoja komponentteja ja dataa voidaan 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. 2.8 Testauksen aikataulu Tässä vaiheessa annamme vasta karkean aikataulun. Maaliskuun loppuun mennessä tavoitteenamme on saada integraatiotestaus suoritettua. Pääosa testauksesta tulisi olla valmis huhti- ja toukokuun vaihteessa. 3 Testausmenettely Tässä luvussa kuvataan testausstrategian soveltamista omassa ohjelmassamme sekä

8 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 muutama yksinkertainen sovellus, joka toimii komentopohjaisesti. Nämä testataan järjestelmätestauksen yhteydessä. Lisäksi GTL-kirjasto tulee testattua osin. 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 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. Joukko-operaatiot tulee myös testata, vaikka emme toteuta niitä itse. Näitä voidaan testata esimerkiksi siirtelemällä särmiä joukosta toiseen 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. 8

9 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ä ennalta määrätyllä tavalla toimiva "tyhmä" versio, 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 ongelma on NP-täydellinen tai muuten jotain heuristiikkaa noudattava, tulee algoritmin yksikkötestauksen keskittyä algoritmin sellaisiin syötteisiin, joista saadaan optimitulos. Jos tiedettyä tulosta ei saada millään syötteellä, keskitytään algoritmin perustoiminnan testaamiseen ja suoritetaan vasinainen toiminnallisuus integraatiotestauksen yhteydessä sellaisella syötteellä, josta on saatavilla lähes optimaaliset tulokset. Algoritmien testausta helpottaa se, että satunnaisuutta voidaan kontrolloida kiinnitämällä ns. siemenarvo, jonka avulla satunnaisgeneraattori tuottaisi aina saman luvun. Jos algoritmi käyttää toista algoritmia yksikkötestauksessa, tulee sen 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ä. CA-, CA1- ja CA2-algoritmeja testattaessa pitää muistaa, että kyseiset algoritimit antavat tuloksena tasograafin. CA:n ja CA1:n tapauksessa palautettava graafi voi olla ulkotasograafi 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->numberOfNodes() == 3 9

10 testnumberofnodes2 G->delNode(node1) G->numberOfNodes() == 2 testnumberofnodes3 G->hideNode(node2) G->numberOfNodes() == 2 testnumberofnodes4 G->hideNode(node3) G->restoreGraph() G->numberOfNodes() == 3 testnumberofnodes5 G->clear() G->numberOfNodes() == 0 testnumberofnodes6 G->hideNode(node1) G->restoreNode(node1) G->numberOfNodes() == 3 int Graph::number_of_edges() testnumberofedges1 G->numbeOfEdges() == 2 testnumberofedges2 G->delEdge(edge2) G->numberOfEdges() == 1 testnumberofedges3 G->hideEdge(edge1) G->numberOfEdges() == 1 testnumberofedges4 G->hideEdge(edge1) G->restoreGraph() G->numberOfEdges() == 2 testnumberofedges5 G->clear() G->numberOfEdges() == 0 testnumberofedges6 G->hideEdge(edge2) G->restoreEdge(edge2) G->numberOfEdges() == 2 list<node> Graph::nodes() testnodes1 G->nodes() palauttama lista sisältää kaikki kolme solmua ja ainoastaan ne (vertailu == operaattorilla) 10

11 testnodes2 G->hideNode(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->hideEdge(edge1) 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) 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 11

12 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->hideNode(node2) node2.ishidden() == true testishidden2 G->hideNode(node2) G->restoreNode(node2) node2.ishidden() == false testdegree1 node1.degree() == 2 testdegree2 G->hideNode(node2) node1.degree() == 1 Test Test Test Test testadjnodes1 node1.adjnodes() palauttama lista sisältää vain ja ainoastaan node2 ja node3 (vertailu == operaattorilla) testadjnodes2 node2->adjnodes() palauttama lista sisältää vain ja ainoastaan node1 (vertailu == operaattorilla) testadjedges1 node1.adjedges() palauttama lista sisältää vain ja ainoastaan edge1 ja edge2 (vertailu == operaattorilla) testadjedges2 node3.adjedges() palauttama lista sisältää vain ja ainoastaan edge2 (vertailu == operaattorilla) 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. 12

13 testcompare1 edge1 == edge1 && edge2 == edge2 testcompare2 edge1!= edge2 && edge2!= edge1 testsource1 edge1.source() == node1 testsource2 edge1.changesource(node3) edge1.source() == node3 testtarget1 edge2.target() == node3 testtarget2 Node node4 = G->newNode() edge2.changetarget(node4) edge2.target() == node4 testishidden1 edge2.ishidden() == false testishidden2 G->hideHdge(edge2) edge2.ishidden() == true FileIO-luokka Projektissa luodaan tuki ainakin kolmelle eri tiedostoformaatille. Tiedostoformaatit kuuluvat FileIO-kategoriaan. Lopullista FileIO-luokkien määrä ja laatua ei vielä tässä vaiheessa osata ennustaa. Esimerkkinä FileIO luokan yksikkötestistä annetaan ohessa GMLFileIO-luokan yksikkötestin lyhyt kuvaus. GMLFileIO käsittelee GML-formaattia. GMLFileIO luokan toimivuutta voidaan testata siten, että ensiksi luodaan jokin graafi ja tallennetaan se GMLFileIO:ta käyttäen. Tämän jälkeen juuri tallennettu graafi ladataan ja todetaan sen samankaltaisuus alkuperäisen kanssa. FileIO:n latausoperaatfileiota voidaan myös testata erikseen jo olemassa olevilla tiedostoon tallennetuilla graafeilla. Tässä tapauksessa testit pitää räätälöidä graafien mukaan. : GMLFileIO1 : Graph g; GMLFileIO.load(g, graph.gml ); Testaus: Tutkitaan, vastaako ladattu graafi tiedostoon tallennettua. 13

14 : GMLFileIO2 : Rakennetaan graafi g; GMLFileIO.save(g, graph.gml ); Graph h; GMLFileIO.load(h, graph.gml ); Testaus: g==h; 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 odotettavat tulokset, testattavat komponentit, mahdolliset tilanteeseen rakennetut testiohjelmat ja niiden käyttöohjeet ja lyhyt kuvaus testin kulusta. Ohessa esimerkkeinä lyhyet kuvaukset siitä, miten kahden kahden eri algoritmin integraatiotestauksessa saatetaan toimia 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. 14

15 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 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 tulosten mittaaminen on melko hankalaa. Täten SA:n yksikkötestaus jääkin vähäiseksi. SA:n integraatiotestauksessa käytetään oikeaa algoritmia alkutuloksen saamiseksi, tosin alkutuloksen antaminen ei ole välttämätöntä. Jos esimerkiksi käytettäisiin CA:ta, voitiinaisiin 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. SA:ta testattessa pitää myös muistaa, että algoritmi tarvitsee syötteekseen tasograafin. SA:n testauksen prioriteetti (kuin myös sen toteutuksen) on melko pieni Hyväksymistestaus Hyväksymistestauksessa pyrimme CA-, CA1- ja CA2-algoritimien kohdalla vähintään saamaan tehokkuuteen kuin alkuperäisessä apptopinv-ohjelmassa oli vastaavien algoritmien kanssa. Tässä meillä on lähteenä työnantajamme Timo Porasen väitöskirja, josta me saamme kyseisten algoritmien suoritusajat sekä risteämäarvojen määrän testigraafeille (sekä mps- ja mops-tapauksissa). Taulukot ovat liitteinä dokumentin lopussa (Liite 2 ja 3) Järjestelmätestaus Järjestelmätestaus suoritetaan kuten integraatiotestaus. tilanteessa tutkitaan myös 15

16 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. Maksimaalista ulkotasograafia (MOPS) ja maksimaalista tasograafia (MPS) laskevat ohjelma toimivat sekä konkreettisina ohjelmina, jotka on rakennettu kirjaston päälle, että yksittäisinä isompina esimerkkitapauksina UTAG-kirjaston käytöstä. MOPS- ja MPS-ohjelmien testaus suoritetaan samalla tavalla kuin pääosa integraatiotestauksesta. 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 Liite 1 Versiohistoria Päivämäärä: Versio: Tekijät: Muutokset: Timo Nummenmaa Aki Mäkinen Jussi Rantala Rami Saarinen Harri Smått 16

17 Päivämäärä: Versio: Tekijät: Muutokset: Rami Saarinen Muokattu kappaleita ja Aki Mäkinen Rami Saarinen Harri Smått + korjattu muutama kirjoitusvirhe (Aki Mäkinen) Muokattu 3.2:n yksikkötestitapauksia (lähinnä yhteneistetty nimeämisiä) (Harri) Korjattu luvun 2.1 ristiriita otsikon ja ensimmäisen kappaleen alun välillä, lisätty luku 2.8 (Testauksen aikataulu) lisätty lukuun maininta joukkooperaatioiden testaamisesta, korjattu maininta algoritmin NP-täydellisyydestä ( ), samaiseen lukuun lisätty kappale CA:n, CA1:n ja CA2:n tuloksista, muokattu lukua , lisätty luku (Hyväksymistestaus), lisätty Liiteet 2 ja 3 (tulokset) sekä muutama kirjoitusvirhe (Aki) Luvun 1.2 loppu, ja 4. kappale, kaikki IO:t muutettu FileIO:ksi (siis nimetty uudelleen), luvun lopussa oli yksi kappale monistettu (se on nyt poistettu), 3.2.3:n alkua muutettu sekä useita kirjoitusvirheitä ja selvennyksiä (Rami) Liite 2 MPS suoritusarvoja Seuraavissa taulukoissa on CA-, CA1- ja CA2-algoritmien suoritusarvoja mps-tapauksessa. Taulukoissa on eräitä graafeja ja näille arvot. Taulukot ovat peräisin Timo Porasen väitöskirjasta (sivut ). Taulukoissa ensimmäisellä sarakkeella on graafin nimi. Suoritusarvoista ensimmäisenä on aika, jota seuraavat huonoin tapaus, keskiarvo ja paras tapaus maksimaaliselle alitasograafille. 17

18 CA ave t. worst ave best cimi-g1 0, cimi-g2 0, ,82 88 cimi-g3 0, ,79 38 cimi-g4 0, cimi-g5 0, ,77 59 cimi-g6 0, g10 0, ,21 36 g11 0, ,21 36 g12 0, ,07 36 g13 0, ,4 73 g14 0, ,64 73 g15 0, ,72 73 g16 0, , g17 0, , g18 0, g19 0, , CA1 ave t. worst ave best cimi-g1 0, cimi-g2 0, , cimi-g3 0, cimi-g4 0, ,75 16 cimi-g5 0, cimi-g6 0, g10 0, ,95 47 g11 0, ,96 47 g12 0, ,98 47 g13 0, ,76 97 g14 0, g15 0, g16 0, , g17 0, , g18 0, , g19 0, ,

19 CA2 ave t. worst ave best cimi-g1 0, cimi-g2 0, , cimi-g3 0, cimi-g4 0, ,7 16 cimi-g5 0, cimi-g6 0, g10 0, ,94 47 g11 0, ,89 47 g12 0, ,84 47 g13 0, ,8 97 g14 0, ,96 97 g15 0, ,96 97 g16 0, , g17 0, , g18 0, , g19 0, , Liite 3 MOPS suoritusarvoja Seuraavissa taulukoissa on CA- ja CA1-algoritmien suoritusarvoja mops-tapauksessa. Taulukoissa on eräitä graafeja ja näille arvot. Taulukot ovat peräisin Timo Porasen väitöskirjasta (sivu 129). Taulukoissa ensimmäisellä sarakkeella on graafin nimi. Suoritusarvoista ensimmäisenä on aika, jota seuraavat huonoin tapaus, keskiarvo ja paras tapaus maksimaaliselle ulkoalitasograafille. CA ave t. worst ave best o , , o , , o , , o , , o , ,8 147 o , ,2 292 o , , o , , o , , o , ,

20 CA1 ave t. worst ave best o , , o , ,4 194 o , , o , , o , , o , , o , , o , , o , , o , ,