Tik-76.115 Testaussuunnitelma

Content Provider's Tool (CPT)

http://
Viimeksi päivitetty : 07.12.1997

Sisällysluettelo

Yhteenveto

1. Johdanto
1.1 Termistö
1.2 Dokumentin jaottelu
2. Testauksen kohde ja tavoitteet
2.1 Testauksen kohde
2.2 Testauksen tavoitteet
3. Testausympäristö
4. Testauksen organisointi ja raportointi
4.1 Testauksen suorittaminen
4.2 Testauksen raportointi
5. Toimintojen testitapaukset ja hyväksymiskriteerit
5.1 Modulitestaus
5.2 Järjestelmätestaus
6. Ei-toiminnallisten ominaisuuksien testaaminen

Yhteenveto

Content Provider's Tool (CPT) on sisällöntuottajan työkalu, joka mahdollistaa dokumentteihin liityvän metadatan käsittelyn. Sen avulla voidaan muokata jo olemassa olevaa metadataa, lisätä sitä tai poistaa tietoja joita käyttäjä ei näe tarpeelliseksi liittää käsiteltävään dokumenttiin. CPT liittyy osana isompaan SmartPush -projektiin, jonka tutkimusalueena on se miten älykkäitä agentteja voidaan käyttää hyväksi informaation täsmäjakelussa. CPT:n osuus tästä kokonaisuudesta on tarjota käyttäjälle, joka on esimerkisksi toimittaja, työkalu jonka avulla hän voi määritellä dokumentin sisällöstä avainasiat, jotka muutetaan metadatamuotoon, jotta systeemin (SmartPush) muut osat voivat hyödyntää tätä informaatiota.

Tämän dokumentin tarkoitus on kuvata miten CPT -järjestelmän testaus suoritetaan ja mitä menetelmiä testauksessa käytetään. Testaus suoritetaan vaiheittain. Näitä vaiheita ovat:

• Modulitestaus, jossa testataan ohjelmiston osakokonaisuudet erillisinä
• Systeemitestaus, jossa testataan ohjelmistokonaisuuden toiminta
• Rasitustestaus, jossa testataan ohjelmiston käyttäytyminen eri kuormitustilanteissa
• Poikkeamatilanteiden testaus
• Käytettävyys testaus, jonka avulla pyritään selvittämään ohjelmiston käyttäjäystävällisyys

Toiminnallisuuden testaus suoritetaan vaatimusmäärittelyä vasten, jonka avulla kartoitetaan onko halutut ominaisuudet toteutettu sekä onko havaittavissa joitain muutoksia, joiden avulla voitaisiin parantaa ohjelman käytettävyyttä tai pitäisikö lisätä toiminnallisuuksia, jotta ohjelma palvelisi käyttäjää paremmin.

1. Johdanto

1.1.Termistö

Tässä dokumentissa käytettyjä termejä:

• Dimensio = dokumentin luokittelu-ulottuvuus( esim. sisältö, tekijä, ...)
• Hierarkia = kuvaa kuinka dimensio on jakautunut eri tasoille ( esim. sisältö->urheilu->golf )
• JDBC = standardi Java-rajapinta tietokantaliityntään
• Painoarvo = tiettyyn dimensioon liityvän arvon esiintyminen dokumentissa ( 0...1)
• Metadata = tieto joka kuvaa dokumentin eri dimensioita ja niiden arvoja ja painoarvoja(esim. sisältö=golf, 0,6)
• Input lohko = toiminnallinen osa, joka otta vastaan dokumentin sekä siihen liittyvän metadatan
• Output lohko = toiminnallinen osa, joka tarjoaa muokatun metadatan sekä alkuperäisen dokumentin
• RDF = Resource Description Format, metadatan formaatin määrittely
• URL = Uniform Resource Locator, tiedostojen paikannustieto

1.2.Dokumentin jaottelu

Tämän testaussuunitelman luvussa 2 on kuvattu testauksen kohde sekä mitkä ovat testaksen tavoitteet. Testausympäristö on esitetty luvussa 3 . Kuinka testaus organisoidaan sekä millä aikataululla se toteutetaan kerrotaan luvussa 4. Varsinaiset testitapaukset ovat esitetty luvuissa 5 ja 6. Näiden yhteydessä on myös mainittu kriteerit, joiden perusteella voidaan testi todeta suoritetuksi hyväksyttävästi.

2. Testauksen kohde ja tavoitteet

2.1.Testauksen kohde

Tämä testisuunnitelma kattaa Sisällöntuottajan työkalun (CPT) testauksen toimivana kokonaisuutena. CPT on Windows NT ympäristöön suunniteltu ohjelmisto, joka liittyy ympäristöön seuraavasti:

• rajapinta tiedostoihin normaalien verkkoyhteyksien avulla (URL)
• metadata joko ASCII tai RDF formaatissa
• varsinainen dokumentti ( html)
• binääridata dokumenttien sisällä 
• tietokanta rajapinta (JDBC)
• käyttäjäliityntä joka on ikkunapohjainen
• system manager liityntä, dimensioiden käsittelyyn

2.2.Testauksen tavoitteet

Testauksen tavoitteena on varmistua, että yksittäiset modulit toimivat luotettavasti CPT:n kokonaisuuden osana ja että ne pystyvät käsittelemään myös aiheutuneet virhetilanteet. Testauksella pyritään myös varmistumaan siitä, että ohjelmaan on toteutettu kaikki asiakkaan vaatimat ominaisuudet, jotka ovat kirjattu vaatimusmäärittelyyn ja että ohjelmiston käyttö on juohevaa ja helppoa loppukäyttäjille.

Testaussuunnitelman mukaan testatun ohjelmiston tulee olla valmis luovutettavaksi asiakkaalle hyväksyttäväksi.

3. Testausympäristö

Testauksessa käytetään Windows NT 4.0 yhteensopivaa laitteistoa, jossa on verkkoyhteydet käytettävissä. Myös hiiri on välttämätön apuväline käyttäjän ja ohjelman väliseen kommunikointiin. Relaatiotietokantana on tässä vaiheessa Solid ja siihen liitytään standardi JDBC rajapinnan kautta. Standardi tietokantarajapinta mahdollistaa myöhemmin kannan vaihtamisen joksikin muuksi.

Testiajureita käytetään yksittäisten modulien testaukseen ennen kuin ne integoidaan yhdeksi kokonaisuudeksi. Alpha -proton testausvaiheessa tarvitaan lisäksi tiedostot, joihin on kirjoitettu ohjelmiston initialisointi parametrejä. Näitä ovat mm. eri dimensioiden hierarkia rakenteet. Näiden tietojen hallinta on lopullisessa tuotteessa tarkoitus hoitaa 'System manager' liitynnän kautta, mutta sen toteutus ajoittuu Alpha -proton jälkeen, joten tässä vaiheessa tarvitaan testitiedostot.

Testauksen suorittamiseksi tarvitaan myös esimerkki dataa ja se on luvattu toimittaa SmartPush -kokonaisprojektin toimesta. Alpha -proto vaiheessa toteutetaan ainoastaan ASCII muotoisen metadatan käsittely, jolla varmistetaan päätoiminnallisuuksien looginen toiminta. RDF -muotoisen metadatan käsittelyrutiinit toteutetaan prototyyppi 1 vaiheessa, jolloin voidaan myös testata tämän muotoisen metadatan käsittely. Tällöin on mahdollista myös testata näiden metadatojen mahdollisten kombinaatioiden käsittely.

Tietokantarajapinnan testauksessa käytetään hyväksi DataSet -rakenteita, joilla tietokantaliityntä on toteutettu ohjelmistossa. Tietokannan testaamiseen tehtävä testimoduli käyttää näitä tauluja hyväksi tietokannan taulujen luomiseen ja käsittelemiseen.

4. Testauksen organisointi ja raportointi

4.1.Testauksen suorittaminen

Tätä testaussuunnitelmaa ei noudateta kaikilta osin Alpha-proton testauksessa sen keskeneräisyyden vuoksi. Testit mitkä suoritetaan pelkästään Alpha proto vaiheessa on merkitty testitapuksien viereen merkinnällä '(A)'. Näden osalta testit suoritetaan lisäksi yksinkertaisempina eli esim. käytetään ainoastaan yhtä input -tiedostoa kerrallaan. Seuraavissa protovaiheiden testauksissa käydään läpi kaikki suunnitelman mukaiset testit. Modulitestaus suoritetaan ainoastaan kerran, eikä sitä toisteta seuraavissa vaiheissa mikäli moduliin ei ole tehty muutoksia kyseisen vaiheen aikana.

Eri testausvaiheiden aikataulutus on esitetty alla olevassa taulukossa:

Testauksen vastuuhenkilöt modulitestauksen osalta ovat modulin tekijät, mutta järjestelmätestauksessa ei modulin tekijä itse testaa pelkätään niitä ominaisuuksia, jotka ovat hänen toteuttamiaan. Testaukset ajoittuvat kunkin vaiheen loppuun ja ne aloitetaan noin viikkoa ennen vaiheen päättymistä, jotta testauksessa havaitut puutteet voidaan vielä korjata. Vastuuhenkilöt ja vastuualueet on kirjattu seuraavaan taulukkoon.

4.2.Testauksen raportointi

Testauksen edetessä kirjataan jokaisen testitapauksen lopputulos testin suorittamisen jälkeen. Siitä tulee käydä ilmi menikö testi läpi ja jos ei mennyt niin miten se ilmeni ja oliko ominaisuuden testauksella jokin vaikutus ohjelman muuhun toimintaan. Testitulokset kootaan yhteiseen testiraporttiin, josta käy ilmi testikierroksen tulokset. Raporttiin kirjataan myös mahdolliset havaitut ongelmat/puutteet jotka ovat tuleet esille testauksen aikana vaikka ne eivät olisi suoraan liittyneet johonkin yksittäiseen testiin.

5. Toimintojen testitapaukset ja hyväksymiskriteerit

5.1.Modulitestaus

5.1.1. Input lohko

Input lohkon testauksessa käytetään testiajuria joka antaa modulille tiedon niistä URL:sta joista tarvittavat tiedostot löytyvät sekä tynkämodulia joka vastaanottaa tietokantaoperaatiokutsut. Ajettavat testitapaukset:

1.Testitapaus (A)

• Input : kaksi oikeata tiedostoviittausta, varsinainen dokumentti ja metadatatiedosto (ASCII)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

2.Testitapaus (A)

• Input : kolme oikeata tiedostoviittausta, varsinainen dokumentti ja kaksi metadatatiedostoa (ASCII)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

3.Testitapaus

• Input : kaksi oikeata tiedostoviittausta, varsinainen dokumentti ja metadatatiedosto (RDF)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

4.Testitapaus

• Input : kolme oikeata tiedostoviittausta, varsinainen dokumentti ja kaksi metadatatiedostoa (RDF)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

5.Testitapaus

• Input : yksi oikea tiedostoviittaus, varsinainen dokumentti jossa metadata upotettuna (RDF)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

6.Testitapaus

• Input : kaksi oikeata tiedostoviittausta ja yksi virheellinen, varsinainen dokumentti (virheellinen) ja kaksi metadatatiedostoa (RDF)
• Output: moduli ilmoittaa ettei se löytänyt kyseista dokumenttia eikä talleta mitään tietokantaan
• Hyväksymiskriteeri: Imoitus tulee OK eikä tapahtunut tietokantaoperaatioita

7.Testitapaus

• Input : yksi oikea tiedostoviittaus ja yksi virheellinen, varsinainen dokumentti ja metadata (virheellinen) (RDF)
• Output: moduli ilmoittaa ettei se löytänyt kyseista dokumenttia eikä talleta mitään tietokantaan
• Hyväksymiskriteeri: Imoitus tulee OK eikä tapahtunut tietokantaoperaatioita

Seuraavassa testitapaukset, kun käsiteltävässä dokumentissa on mukana binääridataa

8.Testitapaus

• Input : kaksi oikeata tiedostoviittausta, varsinainen dokumentti joka sisältää binääridataa ja metadatatiedosto (ASCII)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

9.Testitapaus (A)

• Input : kolme oikeata tiedostoviittausta, varsinainen dokumentti joka sisältää binääridataa ja kaksi metadatatiedostoa (ASCII)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

10.Testitapaus

• Input : kaksi oikeata tiedostoviittausta, varsinainen dokumentti joka sisältää binääridataa ja metadatatiedosto (RDF)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

11.Testitapaus

• Input : kolme oikeata tiedostoviittausta, varsinainen dokumentti joka sisältää binääridataa ja kaksi metadatatiedostoa (RDF)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

12.Testitapaus

• Input : yksi oikea tiedostoviittaus, varsinainen dokumentti joka sisältää binääridataa ja jossa metadata upotettuna (RDF)
• Output: moduli täyttää tulkitsee vastaanotetun metadatan ja täyttää niiden perusteella DataSet:n ja kutsuu tämän jälkeen tietokantamodulia
• Hyväksymiskriteeri: DataSet on täytetty oikein ja moduli on informoinut kutsunutta modulia,että metadata on muokattu ja talletettu tietokantaan

5.1.2. Output lohko

Output lohkon testauksessa käytetään testiajuria joka antaa modulille tiedon niistä dokumenteista joita CPT on käsitellyt. Tarvittavat tiedostonimet syötetään testiajuria hyväksikäyttäen output -lohkolle, jonka tehtävänä n tallentaa annetut tiedostot määriteltyihin paikkoihin. Ajettavat testitapaukset:

1. Testitapaus

• Input : varsinainen dokumentti jossa metadata sisältyy tiedostoon (RDF)
• Output: moduli lähettää tiedoston eteenpäin tallentaen sen ilmoitettuun paikkaan
• Hyväksymiskriteeri: Tiedosto kulkee output-lohkon läpi ja lohko ilmoittaa että siirto OK

2. Testitapaus (A)

• Input : varsinainen dokumentti ja metadata erillisenä tiedostona(ASCII)
• Output: moduli lähettää tiedostot eteenpäin tallentaen ne ilmoitettuihin paikkoihin
• Hyväksymiskriteeri: Tiedostot kulkevat output-lohkon läpi ja lohko ilmoittaa että siirto OK

3. Testitapaus

• Input : varsinainen dokumentti ja metadata erillisenä tiedostona sekä binääridata viitaus(RDF)
• Output: moduli akee binääridatan väliaikaisvaratosta sekä lähettää tiedostot eteenpäin tallentaen ne ilmoitettuihin paikkoihin
• Hyväksymiskriteeri: Binääritiedon haku onnistuu ja tiedostot kulkevat output-lohkon läpi ja lohko ilmoittaa että siirto OK

5.1.3. Tietokanta lohko

Tietokantalohkon testauksessa käytetään testiajuria joka antaa modulille tiedon niistä operaatioista, joita tietokannalle annetaan. Ajettavat testitapaukset:

1. Testitapaus (A)

• Input : Luodaan uusi rivi tauluun
• Output: Moduli lähettää luontipyynnön ja ilmoittaa kun taulu on luotu
• Hyväksymiskriteeri: Taulu löytyy tietokannasta ja kuittaus luonnista

2. Testitapaus (A)

• Input : Poistetaan rivi taulusta
• Output: Moduli lähettää tuhoamispyynnön ja ilmoittaa kun taulu on poistettu
• Hyväksymiskriteeri: Taulu on hävitetty tietokannasta ja kuittaus saapunut

3. Testitapaus (A)

• Input : Tietojen haku
• Output: Kuittaus että tiedonhaku onnistunut
• Hyväksymiskriteeri: Tiedot löytyvät DataSet:stä ja kuittaus saapunut

4. Testitapaus (A)

• Input : Tietojen päivitys
• Output: Kuittaus että tiedot talletettu
• Hyväksymiskriteeri: Muuttuneet tiedot ovat tietokannasta luettavissa

5.2.Järjestelmätestaus

Tämän testauksen tarkoituksena on todentaa järjestelmän toimivuus kokonaisuutena. Modulitestauksessa on varmistuttu liityntöjen toimivuudesta, joten tässä vaiheessa pääpaino on käyttöliittymän toimivuudessa ja siinä kuinka hyvin se suoriutuu eri tilanteista. Käyttäjäliityntä on ikkunapohjainen ja siitä löytyy valikot eri toiminnoille. Työkaluriviltä löytyvät myös omat painikkeet toiminnoille. Testitapusten kohdalla testataan molemmat tavat suorittaa kyseinen tehtävä (sekä menujen kautta että työkalurivin nappuloiden avulla). Kyseinen testilista suoritetaan sekä ASCII- että RDF -muotoisen metadatan kanssa. Tämän lisäksi ajetaan samat testitapaukset tapauksessa jolloin dokumenttiin sisältyy binäärimuotoista dataa.

6. Ei-toiminnallisten ominaisuuksien testaaminen

6.1. Laajennettavuus

Ohjelman rakenteen tulee sallia uusien ominaisuuksien helpon lisääminen. Tämä on jatkon kannalta erittäin tärkeä ominaisuus sillä ohjelman jatkokehitys tapahtuu muiden kun tämän projektin henkilöiden toimesta.

1. Testitapaus

• Lisätään uudet input ja output modulit (RDF) proto1 vaiheessa
• Hyväksymiskriteeri: uudet modulit eivät saa aiheuttaa muutostarpeita vanhoihin moduleihin tai niiden liityntöihin

6.2. Siirrettävyys

1. Testitapaus

• Siirretään ohjelmisto UNIX umpäristöön.
• Hyväksymiskriteeri: Ohjelmiston tulee kääntyä UNIX ympäristössä sekä sen tulee toimia moitteitta tässä ympäristössä.

2. Testitapaus

• Vaihdetaan tietokanta
• Hyväksymiskriteeri: Tietokantarajapinnan tulee toimia myös muiden JDBC rajapinnalla varustettujen tietokantojen kuin Solid:n kanssa ilman ongelmia.

6.3. Käytettävyys

Ohjelman käytettävyydellä on suuri merkitys sille, kuinka loppukäyttäjät kokevat ohjelmatuotteen. Tämän selvittämiseksi valitsemme projektiryhmän ulkopuolelta muutaman henkilön koekäyttämään ohjelmaa ja kirjaamaan kommentteja, miten sen kanssa tulee toimeen ja onko toiminnot tarpeeksi loogisia. Erityistä huomiota tulisi kiinnittää sisältöhierarkian visuaaliselle esitystavalle ja kuinka käyttökelpoinen ja havainnollinen se on. Toinen seikka jota tutkitaan on isojen tiedostojen käsittely ja mitä se vaikuttaa ohjelman suoritusaikoihin.

1. Testitapaus

• Koekäyttäjät käsittelevät dokumentin työkalun avulla.
• Hyväksymiskriteeri: Ei saa esiintyä epäloogisuuksia, eikä kone saa jumiutua kokemattomalla käyttäjällä

2. Testitapaus

• Ladataan isoja tiedostoja jotka sisältävät binääridataa
• Hyväksymiskriteeri: Koneen käsittelynopeus ei saa pudota olennaisesti verrattuna 'tavallisiin' dokumentteihin.