Semantic Web - Metadata Editor

Transkriptio

1 Semantic Web - Metadata Editor Ohjelmistotuotantoprojekti Ohjelmistotuotantoryhmä 1, Meedio Mikko Apiola (M.A) Ari Inkovaara (A.I) Miikka Junnila (M.J) Justus Karekallas (J.K) Pekko Parikka (P.P) Helsinki 30. elokuuta 2002 Testausdokumentti HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos

2 Versiohistoria i Versio Päivämäärä Laatija Komentti Pekko Parikka Dokumentin runko Justus Karekallas Lopullinen versio

3 Sisältö ii 1 Johdanto (P.P.) Testatun ohjelmiston kuvaus Testausdokumentin suhde testaussuunnitelmaan Miksi testaus tehty siinä laajudessa kuin se on? Kuinka ohjelma olisi voitu testata, jos aikaa olisi ollut enemmän Moduulitestaus (J.K.) Ohjain (M.A.) MDEController-luokka MDEException-luokka XML-käsittelijä (A.I.) XMLHandler White box -testaus Black box -testaus XMLElement White box -testaus Black box -testaus RDF-käsittelijä (M.A.) MDEClass MDEProperty MDEOntologyHandler MDEInstanceHandler MDEQueryHandler

4 iii 5 Tiedostonkäsittelijä (J.K.) XmlCardIdentifier-luokka White box-testaus Black box -testaus MDEJoint-luokka White box-testaus Black box -testaus MDEXmlFile-luokka White box-testaus Black box -testaus MDEJointFile-luokka White box-testaus Black box -testaus MDEFileHandler-luokka White box-testaus Black box -testaus XMLFileHandler-luokka Käyttöliittymämoduuli (M.J.) 18 7 Integrointitestaus (J.K.) Ohjain ja tiedostonkäsittelijä (J.K) Testiluokka 1 (FHControllerIntegrationTest1) Testiluokka 2 (FHControllerIntegrationTest2) Testiluokka 3 (FHControllerIntegrationTest3) Testiluokka 4 (FHControllerIntegrationTest4)

5 8 Validointitestaus (Meedio) 22 iv 9 Suorituskyky (Meedio) Tiedossa olevat virheet (Meedio) Yhteenveto(Meedio) Viittaukset lähteisiin (P.P.) 26

6 1 Johdanto (P.P.) 1 Tässä dokumentissa on tarkoitus kuvata kuinka Meedio-ohjelmisto on testattu. Testausta on pyritty tekemään jatkuvasti, jotta ei tarvitsisi lopuksi testata kerralla isoa ohjelmaa. Eri osajärjestelmien tekijät ovat testanneet itse omia koodejansa white-box menetelmällä toteutuksen kanssa samanaikaisesti. Virheet on korjattu löydettäessä. Ohjelmistolle on tehty myös moduulitestausta black-box menetelmällä käyttäen JUnit testikehystä. Tässä testauksessa testaajana on ollut eri henkilö kuin moduulin tekijä. Yksittäisten moduulien testauksen lisäksi tehtiin integrointitestausta ja validointitestausta, joissa testataan eri osajärjestelmien toimintaa yhdessä ja tarkistetaan määriteltyjen ominaisuuksien toteutuminen. Validointitestaus on tehty käyttäen käyttötapauksia, joilla on pyritty kattamaan kaikki määritellyt toiminnot. Sekä moduulitestausta että integrointitestausta ei kumpaakaan ole ehditty testaamaan suunnitellulla kattavuudella johtuen aikataulun niukkuudesta. Moduulitestauksen ja integrointitestauksen arvoaluetestaus tehtiin molemmat pääosin käyttöliittymän avulla integroitaessa käyttöliittymää ohjaimeen. Koko järjestelmälle ei huolellista integrointitestausta ole ehditty tekemään, mutta osajärjestelmät on kyllä pyritty testaamaan. 1.1 Testatun ohjelmiston kuvaus Testattava ohjelmisto on Meedio metadataeditori, jolla luodaan instansseja RDF(S) muotoisesta ontologiasta, eli tehdään RDF-muotoista semanttista luokittelua. Ohjelmalla luetaan XML-muotoista esinedataa, joka on tuotettu museoiden esinetietokannasta. Tuosta XML-datasta luodaan esine-instansseja. Ohjelmisto on tuotettu Java-ohjelmointikielellä ja se toimii sekä Windows että Linux ympäristöissä ja Netscape Navigator sekä Internet Explorer selaimilla. Ohjelmisto tuotetaan Finnish Museums Online (FMO) projektille Helsingin yliopiston tietojenkäsittelytie-

7 2 teen laitoksen ohjelmistotuotantoprojekteissa Testausdokumentin suhde testaussuunnitelmaan Testaussuunnitelmassa kuvataan kuinka ohjelmisto tullaan testaamaan ja mitkä ohjelmiston osat testataan. Aikataulun niukkuuden vuoksi ja työn laajuuden vuoksi testaussuunnitelmaa ei ole täysin voitu noudattaa. Testaussuunnitelmassa esitetyistä osajärjestelmistä XML-käsittelijä ja tiedostonkäsittelijä ovat testattu kokonaan. Käyttöliittymää on testattu paljon lukuisissa eri yhteyksissä, joten käyttöliittymää ei ole erikseen tarvinnut testata. Käyttöliittymän testauksen yhteydessä on myös muita ohjelman osajärjestelmiä testattu, esimerkiksi RDF-käsittelijän testaaminen on suoritettu pääasiallisesti käyttöliittymän avulla. Myös ohjaimen testaus on suurimmalta osalta tehty käyttöliittymän avulla. Ohjaimelle ei ole tehty erillistä yksikkötestausta, sillä ei ole ollut mielekästä tehdä kaikista ohjaimen alla olevista alijärjestelmistä tynkäversioita ohjaimen yksikköterstaamista varten. Ohjaimen testaus on siis suoritettu suoraan integrointitestauksen yhteydessä. 1.3 Miksi testaus tehty siinä laajudessa kuin se on? Ajanpuutteesta johtuen ohjelmaa ei saatu testattua niin laajasti ja huolellisesti kuin olisi haluttu. Ohjelmiston testaamiselle jäi erittäin vähän aikaa projektin lopussa johtuen toteutusvaiheen viivästymisestä. Jotta mahdollisimman paljon virheitä olisi löydetty mahdollisimman lyhyessä ajassa, on käyttöliittymällä tehty erilaisia käyttötapaustestejä melko paljon. Tämä menetelmä oli tehokkaampi paljastamaan virheitä kuin huolellisen moduulitestauksen. Näin on myös pyritty varmistumaan siitä, ettei järjestelmään mahdollisesti jäävät virheet haittaisi kohtuuttomasti loppukäyttäjää. Käyttöliittymäl-

8 lä testaamisella pyrittiin myös varmistumaan siitä, että ohjelmisto toimii oikein suurimmassa osaa normaalikäyttötapauksia Kuinka ohjelma olisi voitu testata, jos aikaa olisi ollut enemmän Jos aikaa olisi ollut käytössä runsaasti, olisi ohjelma voitu testata ohjelmistotuotantokurssilla esitetyllä kunnollisella hyvällä testausstrategialla, johon kuuluu erilliset moduulitestaus, integrointitestaus ja validointitestaus. Ohjelmiston kaikki osajärjestelmien luokat, paitsi käyttöliittymän, olisi voinut testata huolellisella yksikkötestauksella. Integrointitestauksessa olisi voitu käyttää järjestelmällisesti bottom-up-testausta, jossa oltaisiin edetty alhaalta ylöspäin. Eli ensin olisi integroitu ohjain ja tiedostonkäsittelijä, sitten ohjain ja xml-käsittelijä sekä lopuksi ohjain ja rdf-käsittelijä. Nyt meidän piti integroida kaikkia näitä osajärjestelmiä yhtä aikaa, jonka tähden ei voitu tehdä kunnollista laajaa integrointitestausta kullekin osajärjestelmälle. 2 Moduulitestaus (J.K.) Moduulitestauksessa pyrittiin varmistamaan ohjelman eri osajärjestelmien toiminta omina yksikköinään. Osajärjestelmien yhteistoiminnan testaus on tehty integrointitestauksen yhteydessä. Moduulitestaus on jaettu kahteen osaan. Ensimmäisessä osassa on testattu jokaisen ohjelmiston osajärjestelmän yksittäisten luokkien toimintaa. Testaus on suoritettu White box -menetelmää käyttäen ja sen on suorittanut kyseessä olleen luokan toteuttaja. Toisessa moduulitestauksen osassa on testattu osajärjestelmän toimintaa, kun kaikki sen luokat ovat valmiit ja White box-testatut. Tarkoituksena on ollut osajärjestelmän luokkien yhteistoiminnan testaaminen Black box -menetelmällä. Kaikkia ohjelman luokkia ei ehdit-

9 4 ty testata black box-menetelmää käyttäen, joten testaamatta jääneiden luokkien toimintaa on testattu integrointitestauksen yhteydessä. Black box -menetelmällä testattiin ainoastaan xml-käsittelijä sekä tiedostonkäsittelijä. Black box -testaus suoritettiin JUnit-testausympäristössä ja White box- testaus suoritettiin normaaleina Javan testiluokkina. 2.1 Ohjain (M.A.) Ohjaimeen kuuluu yksi luokka, jonka välityksellä käyttöliittymämoduli kommunikoi järjestelmän muiden osioiden kanssa. Tämän luokan nimi on MDEController. Kaiken toiminnan keskittäminen ohjaimen hallintaan mahdollistaa käyttöliittymän vaihtamisen järjestelmään mahdollisimman vaivattomasti. Kommunikointi käyttöliittymän ja ohjaimen välillä noudattaa suurin piirtein asiakaspalvelin-mallin mukaista rakennetta. Järjestelmä on siis helposti muutettavissa myös niin, että käyttöliittymä kutsuu ohjainta tietoliikenneyhteyden yli MDEController-luokka Luokan tarkoitus on toimia järjestelmässä muiden osioiden ohjaimena. Ohjaimen kutsumisesta vastaa pääasiassa käyttöliittymä. Ohjaimen metodit ovat varsin yksinkertaisia, ja useimmat välittävät vain kutsun siitä vastaavalle järjestelmän osalle. Kaikki luokan metodit on todettu toimiviksi perusteellisilla testauksilla sekä erillisten testiohjelmien, että käyttöliittymän avulla. Ajanpuutteen vuoksi ei varsinaisia testiluokkia ja/tai Junit-testausta ehditty suorittaa.

10 MDEException-luokka MDEException-luokka säilöö tiedon yksittäisestä järjestelmässä tapahtuneesta poikkeustilanteesta. Luokka on erittäin yksinkertainen, eikä sisällä varsinaisesti mitään toiminnallisuutta. Luokan toimivuus on varmennettu erillisen testiohjelman avulla. Ajanpuutteen vuoksi ei varsinaisia testiluokkia ja/tai Junit-testausta ehditty suorittaa. 3 XML-käsittelijä (A.I.) XML-käsittelijän tehtävänä on huolehtia XML-dokumenttien käsittelystä metadataeditorissa. XML-käsittelijä koostuu kahdesta luokasta XMLHandler ja XM- LElement. 3.1 XMLHandler Luokan tehtävänä on validoida annettu XML-Skeeman ilmentymä ja muodostaa annetusta XML-kortista XMLElement-olioita White box -testaus Luokka on testattu ohjelmistotuotantoprojekti WWWMUSEOn XML-datalla, jonka validoinnissa on käytetty kyseistä dataa varten luotuja XML-Skeemoja. Kun testaus suoritettiin, niin MDEController-luokka ei vielä ollut valmis. Tämän takia kofiguraatiotietojen lukemiseen on käytetty XMLFileHandleria. Tämä ei kuitenkaan vaikuttanut testin suorittamisen onnistumiseen. Testaus suoritettiin antamalla erilaisia XML-ilmentymiä ja -skeemoja luokalle.

11 6 Testauksessa ei löydetty virheitä ja luokka toimi kuten oli suunniteltu Black box -testaus Testaus toteutettiin Junit-testausympäristössä. Luokasta testattiin konstruktori, parse()-metodi, validate()-metodi sekä getelements()-metodi. Näistä parse()-metodi suorittaa yksittäisen xml-kortin parsinnan, validate()-metodi tarkistaa xml-tiedoston kelvollisuuden ja getelements()-metodi palauttaa xml-korteista tehdyt XMLElementoliot linkitettynä listana. Muita metodeja ei erikseen testattu, koska niitä käytetään sax-parserin kautta. Testauksessa ei löydetty virheitä. 3.2 XMLElement XMLElement-luokan tarkoitus on säilöä yksittäisen XML-elementin tietoja White box -testaus Luokan konstruktori ja kaikki sen metodit on testattu. Koska luokka on aksessoreita setattribute() ja getattributes() lukuunottamatta toteutettu JavaBean -oliomallin mukaisesti, kaikki set- ja get-metodit ovat hyvin yksinkertaisia. Tämän takia testauksessa on riittänyt yksi testiajo, jolla on varmistettu konstruktorin ja aksessoreiden toiminnan oikeellisuus Black box -testaus Black box-testauksessa käytettiin Junit-testausympäristöä. Testaus toteutettiin luomalla luokka MDEXmlFileTest, johon kaikki testit laadittiin. Testi suoritettiin ai-

12 noastaan kelvollisilla arvoilla, koska XMLElement-luokan aksessorit saa parametreinaan ainoastaan String-arvoja. Testauksessa ei havaittu virheitä. 7 4 RDF-käsittelijä (M.A.) RDF-käsittelijän tehtävänä on käsitellä RDF(s)-muotoista ontologiaa ja tuottaa sen mukaista RDF- tietoa. RDF-käsittelijä tarjoaa toiminnot joilla saadaan järjestelmän tarvitsemat tiedot ontologiasta esille, toiminnot RDF-instanssien käsittelyyn sekä instanssikyselyn tekemiselle RDF-tietokantaan. RDF-käsittelijä koostuu seuraavista luokista: MDEOntologyHandler (vastaa RDF(s)-muotoisen ontologian käsittelystä), MDEInstanceHandler (vastaa instanssien käsittelystä), MDEQueryHandler (vastaa instanssikyselyn tekemisestä rdf-tietokantaan), MDEClass (pitää sisällään tiedot yhdestä RDF-luokasta), MDEProperty (pitää sisällään tiedot yhdestä RDF-luokan ominaisuudesta). 4.1 MDEClass Luokan tarkoitus on säilyttää tietoa yksittäisestä RDF-luokasta (ja siitä luotavasta instanssista). Luokan konstruktori ja kaikki sen metodit on testattu. Luokka on varsin yksinkertainen, eikä sisällä varsinaisesti mitään toiminnallisuutta, ainoastaan set- ja get- tyyppisiä metodeita. Tämän takia testauksessa on riittänyt yksi testiajo, jolla on varmistettu konstruktorin ja aksessoreiden toiminnan oikeellisuus. Tämä testimetodi on kommentoituna MDEClass.java-lähdekooditiedostossa.

13 8 4.2 MDEProperty MDEProperty-luokan tarkoitus on säilyttää tietoa yksittäisestä RDF-luokan ominaisuudesta. Luokkaa käytetään tiedonvälitykseen järjestelmän RDF-osion, ohjaimen ja käyttöliittymän välillä. Järjestelmä varastoi MDEProperty-luokan olioita MDEClass-luokan properties-vektoriin. Luokan konstruktori ja kaikki sen metodit on testattu. Luokka on varsin yksinkertainen, eikä sisällä varsinaisesti mitään toiminnallisuutta, ainoastaan set- ja get- tyyppisiä metodeita. Tämän takia testauksessa on riittänyt yksi testiajo, jolla on varmistettu konstruktorin ja aksessoreiden toiminnan oikeellisuus. Tämä testimetodi on kommentoituna MDEProperty.java-lähdekooditiedostossa. 4.3 MDEOntologyHandler MDEOntologyHandler-luokka vastaa RDF(S)-muotoisen ontologian lukemisesta. Järjestelmässä MDEController-luokka kutsuu MDEOntologyHandler-luokan metodeja saadakseen tietoja ontologiasta. Luokan toiminta on testattu Protege2000-ohjelmalla luodulla "museoesineet.rdfsontologialla, sekä "tekstiiliontologia.rdfs-ontologialla. Molemmat näistä tiedostoista löytyvät ohjelman CD-ROM-levyltä. Kaikkien ontologiaan kohdistuvien operaatioiden toimivuus on varmistettu näiden ontologiatiedostojen kanssa perusteellisella testauksella sekä erillisten testiohjelmien, että käyttöliittymän avulla. Ajanpuutteen vuoksi ei varsinaisia testiluokkia ja/tai Junit-testausta ehditty suorittaa.

14 9 4.4 MDEInstanceHandler MDEInstanceHandler-luokka vastaa RDF-instansseja sisältävän tiedoston käsittelystä. Järjestelmässä MDEControllor-luokka kutsuu MDEInstanceHandler-luokan metodeja halutessaan lukea, tai kirjoittaa RDF-instansseja. Luokan toiminta on testattu Protege2000-ohjelmalla luodulla "museoesineet.rdfinstanssitiedostolla, sekä "tekstiiliontologia.rdf-instanssitiedostolla. Molemmat näistä tiedostoista löytyvät ohjelman CD-ROM-levyltä. Lisäksi on ajettu testejä, joissa luokalla kirjoitetaan tyhjään tiedostoon instansseja jotka on myöhemmin luettu luokan metodeilla uudelleen. Kaikkien operaatioiden (instanssien lukeminen, korvaaminen, poistaminen, lisääminen) on todettu toimiviksi perusteellisilla testauksilla sekä erillisten testiohjelmien, että käyttöliittymän avulla. Ajanpuutteen vuoksi ei varsinaisia testiluokkia ja/tai Junit-testausta ehditty suorittaa. 4.5 MDEQueryHandler Luokan tarkoitus on huolehtia instanssikyselyiden suorituksesta. RDFQueryHandlerluokan kutsuminen on järjestelmässä MDEController-luokan tehtävä. Luokan toiminta on testattu ajamalla erikseen laaditulla ohjelmalla "tekstiiliontologia.rdf-instanssitiedosto rdf-tietokantaan, ja suorittamalla luokalla tähän kantaan kyselyjä. Tietokantahaun toimivuus on testattu lukuisten testien avulla sekä erillisten testiohjelmien, että käyttöliittymän avulla. Ajanpuutteen vuoksi ei varsinaisia testiluokkia ja/tai Junit-testausta ehditty suorittaa.

15 5 Tiedostonkäsittelijä (J.K.) 10 Tiedostonkäsittelijän testaus on toteutettu käyttämällä Whitebox-menetelmää heti luokan valmistuttua. Blackbox- menetelmää on käytetty, kun kaikki luokat ovat valmistuneet ja testattu Whitebox-menetelmällä. Whitebox-testauksella on tutkittu luokan konstruktorien ja aksessorien toimintaa kaikilla mahdollisilla suorituspoluilla ja erilaisilla syötteillä. Luokista löytyneet virheet on korjattu välittömästi niiden havaitsemisen jälkeen. 5.1 XmlCardIdentifier-luokka Luokka on testattu sekä white box-testauksella että black box testauksella. White box-testauksen suoritti luokan tekijä, Justus Karekallas, ja black box-testauksesta vastasi Ari Inkovaara. Black box-testaus suoritettiin käyttäen Junit-testausympäristöä White box-testaus XmlCardIdentifier-luokan avulla on tarkoitus yksilöidä xml-kortit niin, että ne voidaan erottaa toisistaan yksikäsitteisesti. Luokan avulla kortille annetaan idtunnus, otsikko ja tilatieto. Lisäksi kortista luotu rdf-olion osoite tallennetaan XmlCardIdentifier-olioon. White box-testauksessa on testattu em. ominaisuuksia tallentavien ja hakevien toimintojen toimivuutta kaikilla suorituspoluilla. Luokka käsittelee vain Stringarvoja, joten vääriä arvoja ovat kaikki muut arvot paitsi String-arvot. Tästä syystä luokkaa ei olla testattu muilla kuin String-arvoilla. Testauksessa on keskitytty tutkimaan vain luokan konstruktorien ja aksessorien toimintaa. Testauksessa on testattu molempien konstruktorien toiminta luomalla yksi olio sekä parametrittomalla että parametrillisella konstruktorilla. Näitä kahta oliota

16 on sitten käytetty aksessorien testaamiseen. Kummallakin luodulla oliolla on testattu kaikkien aksessorien toimintaa. 11 Testauksen avulla todettiin alunperin suunniteltu kaksiparametrinen konstruktori tarpeettomaksi ja se poistettiin. Lisäksi luokkaan lisättiin kortin otsikkoa käsittelevät aksessorit ja kortin tilan String-muodossa tulostava aksessori. Testauksessa ei löydetty virheitä ja luokka toimi kuten oli suunniteltu Black box -testaus Testaus toteutettiin Junit-testausympäristössä. Luokan molemmat kostruktorit ja kaikki set- ja get-akssessorit testattiin. Testauksessa havaittin, että aksessorin getcardstate(string id) parametri id on turha. Muilta osin luokka havaittiin toimivaksi. 5.2 MDEJoint-luokka Luokka on testattu sekä white box-testauksella että black box testauksella. White box-testauksen suoritti luokan tekijä, Justus Karekallas, ja black box-testauksesta vastasi Ari Inkovaara. Black box-testaus tehtiin käyttäen Junit- testausympäristöä White box-testaus MDEJoint-luokka on tarkoitettu liitettyjen ominaisuuksien tiedoston perusteella luotavien olioiden käsittelyyn. Sen avulla luetaan liitettyjen ominaisuuksien tiedosto ja muodostetaan sen perusteella MDEJoint-olioita, jotka kuvaavat kyseisiä ominaisuuksia järjestelmän sisällä. Luokka käsittelee vain String-arvoisia muuttujia, joten luokka on testattu vain

17 12 käyttämällä String-arvoja. Kaikki muut arvot ovat virheellisiä syötteitä. Tämän vuoksi testaamisessa on keskitytty vain luokan konstruktorien ja aksessorien toiminnan testaamiseen. Luokasta on testattu molempien konstruktorien toiminta luomalla kaksi oliota, yksi kummallakin konstruktorilla. Kyseisiä olioita käyttämällä on testattu kaikkien aksessorien toiminta. Testauksen perusteella todettiin luokan toimivan suunnitellusti, eikä virheitä löydetty Black box -testaus Testaus toteutettiin Junit-testausympäristössä. Luokan molemmat konstruktorit sekä kaikki aksessorit lukuunottamatta tostring() -aksessoria testattiin. Testauksessa ei havaittu virheitä. 5.3 MDEXmlFile-luokka Luokka on testattu sekä white box-testauksella että black box testauksella. White box-testauksen suoritti luokan tekijä, Justus Karekallas, ja black box-testauksesta vastasi Ari Inkovaara. Black box-testaus tehtiin käyttäen Junit- testausympäristöä White box-testaus MDEXmlFile-luokan avulla luodaan tiedosto-olioita järjestelmän käyttöön. Luokka säilyttää tietoja xml-korteista, rdf-tiedostoista sekäxml-kortteja sisältävistä tiedostoista. Luokka tarjoaa välineet kyseisten tiedostojen tallentamiseen ja käsitte-

18 13 lyyn. Testaamisessa keskityttiin vain luokan toiminnan tutkimiseen oikeilla syötteillä, jotta saataisiin luokka toimimaan suunnitellusti. Luokasta testattiin kaikki konstruktorit ja aksessorit. Testauksessa havaittiin melko paljon virheitä ennenkuin luokka saatiin toimimaan suunnitellulla tavalla. Eniten ongelmia tuotti tiedostojen hakemistopolkujen käyttäminen sekä xml-korttien käsitteleminen. Myös tiedostojen tallentamisessa oli jonkin verran ongelmia. Havaittuja virheitä: Virheelliset hakupolut tiedostoja avattaessa ja tallentaessa. Tiedostojen käsittelyssä oli aluksi suuria hankaluuksia, koska ei ymmärretty kunnolla Javan tapaa käsitellä tiedostojen hakupolkuja. Ongelmat johtuivat siitä, että aluksi käytettiin tiedostojen luomisessa ja avaamisessa File-luokan konstruktoria File(String, String) väärin. Virhe syntyi, kun ensimmäiseksi parametriksi annettiin luokassa vakiona määritelty hakupolku ja toisena parametrina annettiin tallennettavan tiedoston koko hakupolku tiedoston nimineen. Seurauksena oli se, että hakupolkuun tuli tiedostoa edeltävät hakemistot kahteen kertaan. Esim. systemfiles/xmlfiles/systemfiles/xmlfiles/yodata.xml. Tilanne saatiin korjattu, kun ymmärrettiin antaa toiseksi parametriksi vain pelkkä tiedostonnimi. Xml-kortin virheellinen lukeminen ja tulostaminen Xml-kortteja lukeva aksessori ei aluksi osannut lukea kortteja oikein. Yksittäisen kortin lukemisen ja tulostamisen sijaan aksessori luki koko xml-tiedoston ja tulosti sen sisältämät kortit. Vika johtui siitä, että kyseinen aksessori ei osannut tehdä eroa korttien välillä, koska korttien alun ja lopun ilmoittavien kenttien tulkinta oli virheellistä. Virhe korjattiin siten, että parametrina annettiin myös kortin alun ja lopun kertovien kenttien nimet.

19 14 Xml-korttien tietojen virheellinen lukeminen ja asettaminen Xml-tiedoston läpikäyvä metodi luki aluksi korttien id-tunnisteen väärin siten, että joka tunnisteesta jäi viimeinen numero pois. Tästä seurasi se, että kortit tallennettiin väärillä id-tunnistetiedoilla. Siitä puolestaan oli seurauksena se, kyseisillä id-tiedoilla varustettuja kortteja ei löydetty xml-tiedostosta. Virhe korjattiin muuttamalla metodi siten, että korttien id-tunnisteiden lukeminen tehtiin oikein. Tyhjän rdf-tiedoston luominen Tyhjän rdf-ilmentymine tallentamiseen tarkoitetun tiedoston luominen ei onnistunut, koska Javassa ei tyhjän tiedoston luominen näytä olevan mahdollista. Ongelma korjattiin luomalla tiedosto, johon oli kirjoitettu yksi rivi Black box -testaus Testaus toteutettiin Junit-testausympäristössä. Luokan molemmat konstruktorit sekä kaikki aksessorit testattiin. Testauksessa ei havaittu virheitä. 5.4 MDEJointFile-luokka Luokka on testattu sekä white box-testauksella että black box testauksella. White box-testauksen suoritti luokan tekijä, Justus Karekallas, ja black box-testauksesta vastasi Ari Inkovaara. Blackbox-testaus tehtiin käyttäen Junit- testausympäristöä White box-testaus MDEJoinFile-luokka on tarkoitettu välineeksi, jolla liitettyjen ominaisuuksien tiedosto voidaan muokata järjestelmän käyttöön.

20 15 Luokan testauksessa on keskitytty vain sen tarjoamien välineiden toiminnan testaukseen, jotta luokka saataisiin toimimaan halutulla tavalla. Luokkaa on testattu vain kelvollisilla syötteillä. Luokassa on toteutettu myös useita metodeja, joita ei ollut tarkoitus toteuttaa. Näitä metodeja ei ole testattu. Testauksessa ei havaittu isoja virheitä. Ainoa ongelma oli liitettyjen ominaisuuksien tiedoston muokkaamisessa, mutta ne ratkaistiin muuttamalla kyseisen tiedoston ulkoasua Black box -testaus Testaus toteutettiin Junit-testausympäristössä. Luokan konstruktori sekä kaikki aksessorit testattiin. Testauksessa ei havaittu virheitä. 5.5 MDEFileHandler-luokka White box-testaus Luokka on testattu sekä white box-testauksella että black box testauksella. White box-testauksen suoritti luokan tekijä, Justus Karekallas, ja black box-testauksesta vastasi Ari Inkovaara. Black box-testaus tehtiin käyttäen Junit- testausympäristöä. MDEFileHandler-luokka vastaa koko järjestelmän tiedostonkäsittelystä. Sen avulla järjestelmän muut osat pääsevät käyttämään tiedostoja. Luokan testauksessa on kiinnitetty huomiota ainoastaan luokan tarjoamienpalvelujen toimivuuden tutkimiseen. Luokan toimivuutta ei ole testattu virheellisillä syötteillä.

21 16 Testauksessa havaittiin useita virheitä, joiden ansiosta koko tiedostonkäsittelijän toiminta oli puutteellista ja virheellistä. Tiedostojen tallennuksessa ja avaamisessa oli vikaa eikä MDEFileHandler-olioiden luominenkaan aluksi sujunut suunnitellusti. Tiedostojen kopioimisessa järjestelmän käyttöön oli vaikeuksia eikä xmlkorttien lukeminenkaan toiminut. Havaittuja virheitä: Olioiden luominen Luokasta puuttui aluksi parametriton konstruktori, mikä aiheutti sen, että tiedostojen avaaminen järjestelmän ulkopuolelta oli mahdotonta. Ongelma korjattiin tekemällä luokkaan parametriton konstruktori, joka ainoastaan avasi konfiguraatiotiedoston ja liitettyjen ominaisuuksien tiedoston. Aluksi oli myös tarkoitus, että MDEFileHandler-olioita voitaisiin luoda siten, että annetaan parametrina koko hakemistopolku, jonka päässä sijaitsee avattava xmltiedosto. Tarkoituksena oli se, että voitaisiin konstruoida olio suoraan järjestelmän ulkopuolisesta xml-tiedostosta. Tämä aiheutti kuitenkin ongelmia siksi, että konstruktorissa piti tarkistaa oliko kyseinen tiedosto jo järjestelmän hakemistossa. Testauksessa todettiin, että on parempi, jos olioita luodaan vain järjestelmän hakemistossa olevista tiedostoista. Tiedostojen tallentamatta jättäminen Luokassa esiintyi sellainen virhe, että avattaessa uutta xml-tiedostoa, unohdettiin tallentaa aiemmin käsitellyt tiedostot. Tiedostoihin tehdyt muutokset eivät siis jääneet voimaan. Virhe korjattiin lisäämällä kaikkiin tiedostoja avaaviin aksessoreihin rivit, jotka tallentavat edelliset tiedostot ennen uuden tiedoston avaamista. Konfiguraatiotiedoston lukeminen

22 17 Konfiguraatiotiedostoa luettiin aluksi väärin. Konfiguraatiotiedostoa lukeva metodi ei löytänyt parametrina annettua kenttää tiedostosta eikä siksi palauttanut mitään. Virhe johtui siitä, että parametrina annettu kentän nimi tulkittiin väärin. Virhe korjattiin muokkaamalla tiedostoa lukeva metodi toimimaan oikein. Uuden xml-tiedoston kopioiminen järjestelmän käyttöön Uuden tiedoston kopioiminen aiheutti aluksi ongelmia, koska Javassa ei ole mahdollista suoraan kopioida tiedostoa sisältöineen hakemistosta toiseen. Kun kopioimista yritettiin, oli seurauksen uuden samalla nimellä varustetun tyhjän tiedoston luominen järjestelmän hakemistoon. Pulma ratkaistiin siten, että luotiin järjestelmän käyttöön uusi samanniminen tiedosto, johon alkuperäinen tiedosto kirjoitettiin rivi kerrallaan. XmlCardIdentifierin virheellinen tallennus XmlCardIdentifier-olioiden tallennuksessa oli sellainen virhe, että avattaessa uutta tiedostoa käsiteltäväksi edellinen identifier-olio tallentui niinkuin pitikin. Ongelmia syntyi, kun tallennettiin uutta identifier-oliota, sillä se tallentui edellisen identifierin tilalle. Virhe korjaantui, kun uuden MDEFileHandler-olion luomisen sijaan luotiinkin vain uusi MDEXmlFile-olio "vanhaan"mdefilehandler-olioon Black box -testaus Testaus toteutettiin Junit-testausympäristössä. Luokan konstruktori sekä kaikki aksessorit testattiin. Testauksen alkuvaiheessa havaittiin, että koko luokka ei edes käänny. Kääntymisongelma osoittautui pelkästään kirjoitusvirheeksi. Luokan sisältä yritettiin kutsua luokan MDEXmlFile aksessoria getcardidentifiers() väärällä nimellä. Muita virheitä ei havaittu.

23 XMLFileHandler-luokka XMLFileHandler-luokka on tarkoitettu helpottamaan xml-korttien läpikäymistä. Luokassa on vain kaksi aksessoria, joista toinen etsii xml-korttien id-tunnukset xml-tiedostosta ja toinen etsii halutulla id-tunnuksella varustetun xml-kortin. Luokka toteutettiin vasta aivan projektin lopussa, joten sen testaaminen suoritettiin integrointitestauksen yhteydessä. Luokasta löytyi integrointitestauksessa kaksi virhettä. Ensimmäinen virhe oli oikeastaan enemmän puute kuin virhe, koska luokan valmistuttua havaittiin, että xml-kortteja läpikäyvä aksessori ei etsinyt korttien otsikoita ollenkaan. Lisäksi aksessori palautti löytämänsä id-tunnukset String-taulukkona, vaikka tarkoituksena oli palauttaa XmlCardIdentifier- taulukko. Ongelma korjattiin lisäämällä aksessoriin kortin otsikon hakeva osio sekä osiot, jotka loivat uusia XmlCardIdentifierolioita ja sijoittivat ne palautettavaan taulukkoon. Toinen havaittu virhe oli yhden parametrin unohtuminen xml-kortin palauttavassa metodissa rivillä, jossa oli lause: trans.transform(new DOMSource(e), result). Puuttuva parametri oli uuden DOMSource-olion parametri e. 6 Käyttöliittymämoduuli (M.J.) Käyttöliittymän valmistuminen venyi odotettua myöhäisemmäksi, minkä vuoksi moduulitestaus jouduttiin jättäämään kokonaan väliin. Käyttöliittymän testaus on suoritettu kokonaisuudessaan integrointitestauksen yhteydessä. 7 Integrointitestaus (J.K.) Integrointitestauksen tarkoituksena on ollut testata järjestemän osajärjestelmien yhteistoimintaa. Testaus on suoritettu yhdistämällä muut osajärjestelmät yksi ker-

24 19 rallaan ohjaimeen käyttöliittymää lukuunottamatta. Käyttöliittymä on liitetty mukaan vasta, kun kaikki muut osajärjestelmät on saatu integroitua toimivaksi kokonaisuudeksi. Integrointitestaus on aloitettu ohjaimen ja tiedostonkäsittelijän yhdistämisellä. Tämän jälkeen testattiin ohjaimen ja xml-käsittelijän yhteistoimintaa. Lopuksi integroitiin rdf-käsittelijä ohjaimeen. Ennen käyttöliittymän mukaan ottamista testattiin vielä kaikkien muiden osajärjestelmien yhteistoimintaa. Viimeisessä vaiheessa liitettiin vielä käyttöliittymä muuhun järjestelmään. Koko integrointitestaus suoritettiin JUnit-testausympäristössä. Valitettavasti ajanpuutteen vuoksi ainoa dokumentoitu integrointitestauksen osa-alue on ohjaimen ja tiedostonkäsittelijän integrointi. Kaikkissa muissa integrointitestauksen vaiheissa ilmaantuneet virheet on korjattu sitä mukaa, kun niitä on löydetty. Minkäänlaista dokumentaatiota näistä virheistä ei ole laadittu. 7.1 Ohjain ja tiedostonkäsittelijä (J.K) Ohjaimen ja tiedostonkäsittelijän integrointitestaus suoritettiin Junit-ympäristössä. Testaus toteutettiin laatimalla testiluokkia, joissa testattiin jokaista ohjaimen ja tiedostonkäsittelijän välistä toimintoa. Toiminnot testattiin siten, että verrattiin ohjaimen ja tiedostonkäsittelijän saman toiminnon toteuttavien metodien toimintaa toisiinsa. Testi hyväksyttiin, jos testattavat metodit suorittivat toiminnon samalla tavalla annetuilla syötteillä. Testauksessa käytettiin neljää testiluokkaa, jotka erosivat toisistaan ainoastaan syötteinä annettujen arvojen osalta. Testiluokista kahdessa käytettiin kelvollisia arvoja ja kahdessa virheellisiä arvoja. Virheellisiä arvoja sisältävistä luokista toisessa käytettiin täysin vääriä arvoja ja toisessa osittain vääriä arvoja. Testauksessa havaittiin useita virheitä, jotka korjattiin välittömästi testauksen yhteydessä. Yhtä testiluokkaa testattiin, kunnes Junitin testausindikaattorit osoittivat kaikkien toimintojen sujuvan virheettömästi.

25 Testiluokka 1 (FHControllerIntegrationTest1) Testiluokassa käytettiin testimateriaalina yodata.xml-tiedostosta muokattua yodata1- tiedostoa. Havaitut virheet: 1) Xml-tiedoston poistamisen yhteydessä ei päivitetty sarjallistettuna oliona tallennettua lastfile-muuttujaa. Seurauksena oli se, että lastfile osoitti olematonta tiedostoa. Tilanne ratkaistiin siten, että valitaan käsittelyssä olevia tiedostojen nimiä säilövästä xmlfilesinuse-taulukosta ensimmäisessä alkiossa oleva tiedosto uudeksi lastfile-muuttujaksi. 2) Ohjain ja Tiedostonkäsittelijä eivät osanneet toimia oikein tilanteessa, jossa last- Filea ei ollut olemassa. Seurauksena oli NullPointerException. Tilanne ratkaistiin suorittamalla molempien luokkien openlastfile-metodeissa tarkistus, jossa tutkitaan viimeksi käsitellyn tiedoston olemassa oloa. 3) Xml-tiedoston poistamisen yhteydessä ei huomioitu sitä, että viimeisen tiedoston poistamisen jälkeen lastfile-muuttuja osoittaa edelleen poistettua tiedostoa. Avattaessa viimeksi käsiteltyä tiedostoa openlastfile-metodilla, tapahtui Null- PointerException, koska kyseistä tiedostoa ei ollut olemassa. Ongelma ratkaistiin siten, että viimeisen tiedoston poistamisen yhteydessä poistetaan myös sarjallistettuna oliona tallennettu lastfile-muuttuja. 4) Viimeisen xml-tiedostoja sisältävässä hakemistossa olevan tiedoston poistamisen jälkeen lastfile-tiedosto ei poistunut, vaikka olisi pitänyt. Ongelma johtui siitä, että hakemistossa oli piilotiedosto, jonka nimi asetettiin lastfile-muuttujan arvoksi. Kun lastfile seuraavalla kerralla avattiin, tapahtui NullPointerException. Ongelma korjattiin huomioimalla piilotiedostojen mahdollinen olemassaolo tiedostojen poistamisen yhteydessä.

26 Testiluokka 2 (FHControllerIntegrationTest2) Testiluokassa käytettiin testimateriaalina roskadataa.xml -tiedostoa, joka sisältää neljä xml-korttia. Testauksessa ei havaittu virheitä Testiluokka 3 (FHControllerIntegrationTest3) Testiluokassa käytettiin kaikkien toimintojen testaamisessa virheellisiä arvoja. Testimateriaalina käytettiin olematonta yodata10-tiedostoa. Havaitut virheet: 1) Avattaessa olematonta tiedostoa luodaan XmlCardIdentifier-taulukko, vaikka ei pitäisi. Lisäksi luodaan uusi rdf-instanssitiedosto, mitä ei myöskään saisi tapahtua. Vika johtui siitä, että MDEXmlFilen konstruktorissa ei oltu huomioitu sitä, että parametrina voidaan saada olematon tiedosto. Vika korjattiin lisäämällä asianmukaiset tarkistukset konstruktoriin Testiluokka 4 (FHControllerIntegrationTest4) Testiluokassa käytettiin toimintojen testaamisessa osittain virheellisiä arvoja. Testimateriaalina käytettiin yodata2-tiedostoa. Havaitut virheet: 1) MDEFileHandler-luokan metodit getfilenames ja getconfigurationinfo eivät reagoineet NullPointerException-poikkeuksiin. Tilanne korjattiin lisäämällä metodeihin tilanteen huomioiva try-catch -lause.

27 8 Validointitestaus (Meedio) 22 Validointitestaus on ajan puutteen vuoksi jätetty dokumentoimatta, mutta ohjelmalta vaadittujen ominaisuuksien toiminta on testattu ja ohjelman on havaittu toimivan halutulla tavalla. Testatut toiminnot: - RDF-skeeman sijaintitiedon luku konfiguraatiotiedostosta - Kortin alun ja lopun määrittelevä kenttä (esim. <Kortti>) Valmiissa versiossa ainoastaan kortin alun määrittelevä kenttä. - XML-skeeman sijaintitiedon luku konfiguraatiotiedostosta - Otsikkoattribuutti yksittäiselle kentälle Jätetty pois järjestelmästä - Kuvan sijainti levyjärjestelmässä-attribuutti - Osaa lukea XML-Skeeman - Osaa lukea XML-kortin tiedostosta - Osaa validoida XML-kortin skeeman mukaiseksi Jätetty pois järjestelmästä - Osaa antaa tarkat tiedot XML-kortista, ja sen tietojen oikeellisuudesta, siten että antaa tiedot kortin oikeellisuudesta - Konfiguraatiotiedostossa määritellyn RDF(S)- muotoisen ontologian lukeminen sisäiseen tietorakenteeseen

28 23 - Jena-oliomallin mukaisen rakenteen muodostaminen RDF(S)- ontologiasta - Jena-oliomallin mukaisen rakenteen välittäminen käyttöliittymälle - Osaa antaa käyttöliittymälle tiedot kohdan mukaisista luokista - XML-tiedoston tallennus - Valmiin kortin tallennus - Kuvan näyttäminen käyttäjälle käyttöliittymässä - Tiedoston sisältämien korttien näyttäminen havainnollisesti - Osaa tehdä XML-tiedostosta kopion järjestelmän käyttöön - Osaa lisätä / muuttaa kortin tilatiedot (käsitettelyssä / ei käsitelty / valmis) - Osaa lukea käsiteltävien XML-korttien ID-tiedot ja otsikot - Osaa tallentaa kortin - Osaa tallentaa tiedoston haluttuun paikkaan - Semanttisen kuvauksen tallennus XML-korttiin Ei tallenneta xml-korttiin

29 24 - XML-kortin tietojen havainnollinen näyttäminen - XML-kortin tietojen muokkaus Xml-tietoja ei muokata - XML-kortin virheellisten kenttien/attribuuttien korostus Jätetty pois - Ontologian esittäminen dynaamisena hierarkkisena listana - Semantiikan liittäminen XML-korttiin Jätetty pois. - Osaa tallentaa valmiit kortit haluttuun paikkaan - Kortin tallennus - Uusien instanssien vertaaminen olemassa oleviin instansseihin - Kyselyn suorittaminen Jena-rajapinnan yli RDF-tietokantaan - RDF-Skeematiedoston haku verkkoyhteyden yli Jätetty pois. - Osaa tuhota käsiteltävän XML-tiedoston 9 Suorituskyky (Meedio) Järjestelmän suorituskyvyn kuvaus.

30 10 Tiedossa olevat virheet (Meedio) 25 Ohjelmiston puutteellisesta testauksesta johtuen ohjelmaan on hyvin todennäköisesti jäänyt virheitä. Meedio-ryhmä on kuitenkin tietoinen ainoastaan seuraavista virheistä: 1) Instanssihaku onnistuu vain siirtymällä hakupuun oksalta seuraavalle tason oksalle. Useamman tason yli hakeminen ei onnistu. 2) Järjestelmä luo uuden tiedoston, vaikka xml-tiedosto ei ole validia ja se täytyy poistaa manuaalisesti käyttäjän toimesta. 3) Kun propertyn arvoksi on valittu luokka, niin hakupuu ei välttämättä aina häviä näkyvistä Internet Explorer-selaimessa. 11 Yhteenveto(Meedio) Ohjelmiston testaus on laadittuun suunnitelmaan nähden puuttellista. Alkuperäisen suunnitelman mukaista testausta ei käytännössä suoritettu ollenkaan, vaan jokainen testasi laatimansa luokat parhaaksi katsomallaan tavalla. Tämä tarkoittaa sitä, että saatuaan jonkin osa-alueen valmiiksi, kyseisen osa-alueen laatija testasi sen toimintaa korjaten samalla mahdolliset virheet. Kun osa-alue saatiin toimimaan halutulla tavalla, havaitut virheet ja toimenpiteet niiden korjaamiseksi dokumentoitiin, mutta minkäänlaista testaussuunnitelmassa mainittua jakoa tärkeysjärjestyksineen ja virheluokituksineen ei tehty. Testaussuunnitelman mukaan oli myös tarkoitus yksikkötestauksen yhteydessä testata laaditut luokat sekä white box -menetelmällä, että black box -menetelmällä. Suunnitelmaa noudatettiin kuitenkin ainoastaan white box -testauksen osalta. Black box -testausta käytettiin vain kahden osajärjestelmän testauksessa(xml-käsittelijä ja tiedostonkäsittelijä). Integrointitestauksen osalta suunnitelmaa ei myöskään noudatettu,

31 26 vaan testaus tehtiin sitä mukaa, kun osajärjestelmät valmistuivat. Integrointitestausta ei siis juurikaan suunniteltu tai dokumentoitu. Validointitestaus jouduttiin sivuuttamaan lähes kokonaan. Ohjelman toimintaa kyllä testattiin, mutta mitään dokumentaatiota ei tehty. Ohjelman suorituskyvyn ja vakauden testaamista ei ole suoritettu ollenkaan. Syy testauken kaoottisuuteen on selvä: ajanpuute. Ohjelmiston eri osajärjestelmien valmiiksi saaminen vaati niin paljon aikaa, että ohjelmiston suunnitelmallisesta testaamisesta oli pakko tinkiä, jotta saataisiin ohjelma valmiiksi määräaikaan mennessä. Kaikilla projektin jäsenillä oli niin kova kiire oman osa-alueensa toteuttamisessa, että kenellekään ei jäänyt aikaa kunnolla perehtyä systemaattiseen testaukseen ja testitulosten dokumentointiin. Puutteellisesta testauksesta ja dokumentoinnista huolimatta ohjelma näyttäisi toimivan suunnitellusti ja kaikki ensimmäisen prioriteetin toiminnot on saatu toteutettua. 12 Viittaukset lähteisiin (P.P.) Tässä luvussa kuvataan dokumentissa esiintyvät viittaukset eri tekniikoihin. - XML (Extensible Markup Language), lisätietoa: - XML-Skeema, lisätietoa: - RDF (Resource Description Framework), lisätietoa: - Java Server Pages, lisätietoa: - JSP+tag libraries, lisätietoa: - Jakarta Tomcat, lisätietoa: - Sax (Simple API for XML), lisätietoa:

32 27 - Apchen Xerces, lisätietoa: - Dom (Document object model), lisätietoa: - Jena, lisätietoa: - HTML (Hypertext Markup Language), lisätietoja: - CSS (Cascading Style Sheets), lisätietoja: - Java Applet, lisätietoja: - Java Servlet, lisätietoja: