Testaussuunnitelma Ipa

Transkriptio

1 Testaussuunnitelma Ipa Helsinki Ohjelmistotuotantoprojekti HELSINGIN YLIOPISTO Tietojenkäsittelytieteenlaitos

2 Kurssi Ohjelmistotuotantoprojekti (9+1op/6ov) Projektiryhmä Duus Seppo Juhani Hela Ilkka Hukkanen Antti Petteri Karhu Keijo Markus, Projektipäällikkö Usenius Timo Sakari Asiakas Tino Johansson Joni Kukkola Arttu Paarlahti Tanja Stepanova Vastuuhenkilö Taina Juha Ohjaaja Simola Pekka Sähköposti Kotisivu

3 Versiohistoria Versio Aika Nimi Muutokset testaussuunnitelma0.1 Ensimmäinen versio. '' '' Johdanto, sanasto. '' '' Yksikkötestaus. '' '' Integrointitestaus. '' '' Järjestelmätestaus. '' '' Testitapauksia testaussuunnitelma Tekstin tarkastuksia testaussuunnitelma Suunnitteludokumentin ( ) pohjalta tehtyjä muutoksia ja lisäyksiä.

4 Sisällys 1 Johdanto Sanasto Testaus Ipa-projektissa Testauksen vaiheet ja testausprosessi Testauksen ajankohta ja suorittaja Kattavuus ja kattavuuskriteeri Testauksen raportointi Yksikkötestaus Testattava yksikkö Ajurit ja tyngät Luokkien testaus Yksikkötestauksen kattavuus Ipa-projektissa Yksikkötestauksen hyväksymiskriteerit Ipa-projektissa Testisyötteen valinta JUnit:n käyttö projektissa Cactus projektissa Integrointitestaus Integrointitestausprosessi Luokkien riippuvuuskaaviot Ongelmakohtia integrointitestauksen toteuttamisessa Ajurit ja tyngät integrointitestauksessa Integrointitestauksen ajankohta Integrointitestauksen hyväksymiskriteerit Järjestelmätestaus Järjestelmätestauksen testauskohteet Järjestelmän käyttöön liittyvät rajoitukset Järjestelmätestauksen suoritus Järjestelmätestauksen testitapaukset Sisään- ja uloskirjautuminen Rekisteröityminen ja omien käyttäjätietojen muuttaminen Pakettien julkaisu, asiasanat, kategoriat ja paikkatieto Pakettien haku ja lataaminen Käyttöliittymä ja käytettävyys Paikkaontologiat Ylläpitäjälle kuuluvia käyttötapauksia Rinnakkaisuuden hallintaa koskevat testit Muita järjestelmätestauksen testitapauksia Testausaikataulu Testauksen raportointi ja hyväksyntä Testauksen raportointi Testauksen hyväksyminen Lähteet... 34

5 1 Johdanto Tämä dokumentti esittää suunnitelman siitä, miten Ipa-projektissa toteutettavan ohjelmiston testaus suoritetaan. Ipa projekti on ohjelmistotuotantoprojekti, joka kuuluu Helsingin yliopiston tietojenkäsittelytieteen laitoksen ohjelmistotuotantoprojektikurssin (581260) suorittamiseen. Projekti on jatkoprojekti vuonna 2005 toteutetulle happi-projektille. Testaussuunnitelman perustana on jäädytetty Ipa-vaatimusdokumentti. Muutoksia ja lisäyksiä versioon on tehty myös ilmestyneen suunnitteludokumentin pohjalta. Testaus on systemaattista työtä ohjelmiston tuotantovaiheessa ohjelmistossa esiintyvien virheiden löytämiseksi ja korjaamiseksi. Testaukseen liittyvät vaiheet ovat testauksen suunnittelu (testaussuunnitelma, sisältäen testitapaukset), testiympäristön asennus (testauksen kohde ja testaus-välineet), testien suorittaminen, sekä tulosten analysointi. Testausvaiheisiin ja niihin liittyviin virheiden korjauksiin kuuluu tyypillisesti yli puolet ohjelmistoprojektin resursseista, joten testauksen määrä on aina kompromissi käytettävissä oleviin resursseihin (aika, raha,...) [HaM02]. Testausprosessi pyrkii vastaamaan seuraaviin kysymyksiin: Vastaako toteutettu ohjelmisto määrittelyjään? Tekeekö ohjelma sen mitä sen pitää tehdä? Tekeekö ohjelmisto sellaista, mitä sen ei pitäisi tehdä? Ohjelmointikielenä tuotantoprojektissa käytetään java-ohjelmointikieltä. Java-kielisten luokkien yksikkötestauksen apuvälineenä käytetään JUnit-testikehystä, joka sisältyy Eclipse java-kehitysympäristöön tai se voidaan erikseen asentaa. Testauksessa pyritään luomaan mahdollisimman hyvin kattavia testitapausjoukkoja ja käyttämään menetelmiä, joilla ohjelmissa esiintyvät virheet pystytään mahdollisimman hyvin löytämään. Projektissa toteutettava testaus perustuu yleisesti käytettyyn testauksen V-malliin, jossa testaus jakautuu eri vaiheisiin, jotka voidaan rinnastaa ohjelmistoprojektin kulun kanssa. V- mallin mukaiset testausvaiheet ovat alhaalta ylöspäin yksikkötestaus, integrointitestaus ja 1

6 järjestelmätestaus, joita käsitellään luvuissa 4,5 ja 6. Luvussa 7 esitetään järjestelmän testitapaukset ja odotetut tulokset. Testitapauksista kirjoitettuja odotettuja tuloksia verrataan saatuihin tuloksiin. Järjestelmätestit ja niistä saatavat tulokset kirjataan testausraporttiin. Luvussa 8 lyhyesti testauksen aikataulusta ja luvussa 9 raportoinnista ja koko järjestelmän hyväksymisestä. Ipa-projektissa tuotettavan ohjelmiston testauksessa pyritään täyttämään testaukselle asetetut hyväksytyt vaatimukset. Mikään verifiointi, validointi ja testaustekniikka ei voi kuitenkaan taata virheetöntä ja täysin varmasti toimivaa ja virheetöntä ohjelmaa. Projektissa testauksen täydelliseen toteutumiseen voi olla vaikea päästä testaukseen käytettävissä olevien resurssien, testauksen kohteena olevien uusien tekniikoiden, sekä pohjalla olevan järjestelmän virhetoimintojen johdosta. Tämä testaussuunnitelma perustuu Juha Tainan ohjelmistotuotantoprojektikurssin testausta ja testaussuunnitelmaa varten laatimiin ohjeistuksiin [Tai06]. 2 Sanasto Sanastoon on koottu Ipa-ohjelmistotuotantoprojektissa toteutettavaan ohjelmistoon ja sen testaamiseen liittyvää sanastoa. Ajuri (driver):testiajuri ottaa vastaan ja muokkaa testiaineiston testattavan komponentin vaatimaan muotoon, kutsuu komponenttia ja vastaanottaa tuloksen. Arvoalueanalyysi: Keino rajata testitapausjoukko järkeväksi kokonaisuudeksi. Cactus: (JUnit Cactus: Junitia käyttävä ja laajentava testikehys palvelinpuolen java-luokkien (Servletien, EJB:en, jne.) testaukseen. Käytetään projektissa Struts:n hallitseman osuuden testaukseen laajennoksella StrutsTestCase. DAO-luokat: DAO on standardi J2EE suunnittelumalli. DAO-luokkien avulla tietokannan käsittely voidaan erottaa toimintalogiikasta. Sisältävät tyypillisesti muun muassa luonti-, luku-, päivitys- ja poisto- operaatiot (create, read, update, delete,...). hbm.xml: Hibernaten tarvitsemat kuvaustiedostot oliomalleista. Hibernate: Tarjoaa palvelut, joiden avulla tietokantaoperaatioita voidaan suorittaa olioille. HTML (HyperText Markup Language): WWW-julkaisukieli. JavaScript on sulautettu HTML-sivujen sisälle. 2

7 Häiriö (failure): Tapahtuu kun komponentti ei pysty suorittamaan vaadittuja toimenpiteitä suorituskykyvaatimusten puitteissa. Integrointitestaus: Testausvaihe, jossa toimivia yksiköitä liitetään toisiinsa rajapintojen testausta. Java: Projektissa käytettävä ohjelmointikieli. Java-beans: Uudelleen käytettävien ohjelmakomponenttien luontiin tarkoitettu standardi. Niillä on yhtenäinen nimeämiskäytäntö, sekä parametriton konstruktori. Tässä sovelluksessa Model-luokat toteutetaan JavaBeaneina, jotta voidaan käyttää Hibernate:a tietokannan kanssa kommunikointiin. Java-luokka: Java-luokka kuvaa olion rakenteet (attribuutit) ja käyttäytymisen (metodit). Luokat yksikkötestauksen kohteina. JavaScript: WWW-sivuilla käytettävä skriptikieli. Selain tulkkaa sivujen latauksen yhteydessä javascript komennot, jotka on sulautettu HTML-sivujen sisään. Sivuilla komennot on sijoitettu <script> komentojen väliin. Java-servlet: Palvelinsovelma, joka vastaa käyttäjän palvelupyyntöihin. Esimerkiksi htmlsivujen välityksellä esitetyt pyynnöt ja niihin reagoiminen. JDBC (Java Database Connectivity): Sunin kehittämä ohjelmointirajapinta (API) javasovellusten ja tietokantojen välillä. JSP (Java Server Pages): Tekstitiedostojen, esimerkiksi HTML- ja XML-sivujen sekaan kirjoitettua java-koodia. JSP-sivujen säiliö muuntaa JSP sivun palvelinsovelmaluokaksi, kääntää sen ja suorittaa. JUnit ( Testikehys java-luokkien yksikkö- ja integrointitestaukseen. Järjestelmätestaus: Ohjelmistotuotteen (järjestelmän) testaus kokonaisuutena. Kattavuus (coverage): Kattavuus on luku, joka kertoo kuinka hyvin suoritetut testit ovat testanneet testatun yksikön rakennetta. Kattavuuskriteeri: Kattavuuteen liittyvä kattavuuskriteeri ilmoittaa millä tasolla testaus voidaan hyväksyä. Keskeytys (break): Ohjelman suoritus voidaan keskeyttää tiettyyn kohtaan ja tutkia muuttujien arvoja keskeytyskohdassa. Käyttötapaus (Use case): Käyttötapauksia käytetään toimijan (actor) ja järjestelmän 3

8 (system) välisen vuorovaikutuksen kuvaamiseen. Toimija voi olla henkilö, toinen tietojärjestelmä jne. Käyttötapauksessa kuvataan toimijan tavoite jonkin päämäärän saavuttamiseksi, ja mahdollisimman yksityiskohtaiset tiedot tilanteen taustoista (tilatiedot). Lasilaatikkotestaus (White-box testing): Lasilaatikkotestausta kutsutaan rakenteelliseksi testausmenetelmäksi. Se perustuu testattavan kohteen rakenteen tuntemiseen. Mahdollisia virhealttiita paikkoja voidaan arvioida tarkastelemalla koodia ja keskittää testaus näihin kohtiin. Testien tuloksia verrataan ja analysoidaan suhteessa odotettuihin tuloksiin. Lasilaatikkotestaus on välttämätöntä, koska koodin ominaisuuksien takia kaikkia virheitä ei mustalaatikkotestauksella havaita. Metodi: Java-luokan sisällä oleva aliohjelma, jota voidaan kutsua itse luokasta tai toisesta java-luokasta. Mustalaatikkotestaus (Black-box testing): Mustalaatikkotestauksessa testataan testattavan komponentin toiminnallisuutta. Siinä komponentin sisäinen rakenne (esimerkiksi koodi ja tietorakenteet) ei ole näkyvissä. Testaus perustuu syötteiden ja sovelluksen antamien tulosten analysointiin. Saatuja tuloksia verrataan odotettuihin, jolloin voidaan päätellä sovelluksen toimivuus testitapauksessa. MVC (model-view-controller): Malli-näkymä-ohjain-arkkitehtuurin, joka erottaa käyttöliittymän sovelluslogiikasta ja datasta. Malli sisältää testauksen kannalta erityyppisiä tiedostoja: Malli (Model) on järjestelmän oliomalli (java-luokkia). Näkymä (View) edustaa käyttöliittymän tilaa. Ohjaimet (Controller) toimivat sovittimina mallien ja näkymien välillä (servletit). Olio: Luokan ilmentymä. Pakkaus: Pakkaus on tapa kerätä yhteen toisiinsa jollain tavalla liittyvät ohjelmaluokat. Ryväs (cluster): Joukko vahvasti toisiinsa liittyviä luokkia. Servlet: Kts. Java-servlet. Struts: Struts on Apachen ( kehittämä J2EE sovelluskehys, joka perustuu läheisesti MVC malliin. Keskeisessä osassa strutsia on controller servletti, joka ottaa vastaan sovelluksen kutsut ja ohjaa ne eteenpäin action-luokkien avulla [AHÅ03]. Staattinen testaus: Ohjelmiston testausta ilman, että ohjelmakoodia suoritetaan. 4

9 StrutsTestCase: Cactus-kehys Apache Struts kehystä käyttävien operaatioiden yksikkö- ja integrointitestaukseen. Testattavuus (testability): On taso, jolla testattava ohjelmisto tai komponentti edesauttaa määriteltyjen testien suorittamista ja kriteerie täyttymistä. Tynkä: Yksikkö- ja integraatiotestauksessa yksikkö tarvitsee testaamattomien komponenttien palveluita. Testaukseen ei kuitenkaan saa liittää testaamattomia komponentteja, vaan on tehtävä tynkä, joka tarjoaa minimivaatimukset testauksen käyttöön. Esimerkiksi metodia testattaessa tyngät korvaavat kutsut muihin metodeihin ja olioihin. Validointi (validation): Validoinnilla varmennetaan, että toteutettava järjestelmä vastaa loppukäyttäjän tarpeita. Validointi suoritetaan ohjelman oikeassa ympäristössä tarkoituksena todentaa, että ohjelmiston toimintojen tarkoituksenmukaisuus. Verifiointi (verification): Verifioinnilla varmennetaan ohjelmakoodi ja sen suoritus tutkimalla, että ohjelma tekee sille vaatimustenmäärittelyssä määritellyt tehtävät. Vika (error): on ihmisen toimintaa, jonka seurauksena dokumenttiin tai ohjelmakoodiin syntyy virhe. Virhe, virhetoiminta (fail): Toiminta, joka poikkeaa määritellystä toiminnasta. Virheitä ovat: 1. Ajonaikaiset virheet (käännetty ohjelma suorittaa esimerkiksi nollalla jaon). 2. Käännösaikaiset virheet (ohjelmointivirheet). 3. Loogiset virheet (ohjelman suoritus poikkeaa määrittelyssä vaaditusta). Virheidenpoisto (debugging): Prosessi, jonka tarkoituksena on löytää ja poistaa virheiden syitä ja aiheuttajia ohjelmakoodista. XML (extensible Markup Language): html-protokollaa käyttävä tiedonvaihtotapa eri järjestelmien välillä. Yksikkötestaus (Unit testing): Testauksen kohteena pienimmät ohjelmiston kokonaisuudet, olio-ohjelmoinnissa luokat. 5

10 3 Testaus Ipa-projektissa Testauksen tavoitteena on varmistaa Ipa-projektissa kehitettävän ohjelmistotuotteen laatu, sekä varmistaa että kaikki vaatimusmäärittelyssä olevat vaatimukset täyttyvät. Tässä luvussa esitetään Ipa-projektissa käytettävä testausprosessin malli, sekä selvitetään testauksen hyväksymiseen liittyvät termit. 3.1 Testauksen vaiheet ja testausprosessi Ohjelmistotuotteen laatu pyritään osoittamaan verifioinnin ja validoinnin avulla. Testauksen tarkoituksena on osoittaa, että suunnittelun mukaan toteutettu ohjelmisto on riittävän virheetön ja toimii kaikilla syötteillä, sekä toteuttaa sille vaatimusmäärittelyssä asetetut vaatimukset. Testaus jakaantuu kahteen vaiheeseen: Rakenteelliseen testaukseen, jossa ohjelmakoodi, sen rakenteet ja yksityiskohdat ovat testaajan nähtävillä (lasilaatikkotestaus), joiden avulla testitapaukset voidaan suunnitella. Tämä testaustapa kohdistuu yksikkötestausvaiheeseen. Toiminnalliseen testaukseen, jossa yksityiskohtainen rakenne on piilossa (mustalaatikkotestaus) ja keskitytään analysoimaan tietyillä syötteillä saatuja tuloksia odotettuihin tuloksiin. Ipa-projektissa pyritään seuraamaan yleisesti käytössä olevaa testausprosessien V-mallia, jossa testaus on jaettu ohjelmistoprosessin mukaisiin hierarkkisiin tasoihin (kuva 1). Testattavan kokonaisuuden koko kasvaa edettäessä hierarkiatasolla ylöspäin. Pienempien kokonaisuuksien testaaminen huolellisesti edesauttaa myöhempiä testausvaiheita. 6

11 Kuva 1: V mallin mukaiset testausvaiheet. Testaus jakaantuu mallin mukaan pääasiassa kolmeen eri vaiheeseen: Yksikkötestauksessa testataan pienimpiä toiminnallisia yksiköitä. Integrointitestauksessa testataan yksiköiden välistä toimintaa (rajapintoja). Järjestelmätestauksessa testataan koko järjestelmän toimintaa. Testausvaiheista ja niiden suorittamisesta tarkemmin luvuissa 4, 5 ja Testauksen ajankohta ja suorittaja Yksikkö-, lasilaatikko-, mustalaatikko- ja integrointitestaus voidaan aloittaa yksiköissä sitä mukaa, kun yksikön (luokan) toteuttaja on määritellyt sen olevan lopullisessa muodossaan käyttöön otettavaksi Ipa-ohjelmistotuotantoprojektissa tuotettavaan järjestelmään. Uudet yksiköt: Yksikkötestauksen ja siitä raportoinnin toteuttaa pääsääntöisesti kyseisen yksikön toteuttaja, jolloin testitapaukset voidaan hahmotella yhdessä komponentin suunnittelu- ja toteutusvaiheessa. 7

12 Uudelleenkäytettävät HaPPi projektin testaamattomat yksiköt: Testitapausten suunnittelu ja toteutus jakautuu eri henkilöiden kesken aikataulujen sallimissa puitteissa. 3.3 Kattavuus ja kattavuuskriteeri Kattavuus on luku, joka ilmoittaa kuinka hyvin suoritetut testit ovat testanneet testattavan yksikön rakennetta. Kattavuuksia ovat muun muassa lause- ja haaraumakattavuudet. Kattavuuskriteeri tarkoittaa pienintä lukua, jolla tehty testaus voidaan hyväksyä. Kattavuuskriteerin tavoitetasona 100 % kattavuus, jolloin testauksen kohde voidaan osoittaa täysin toimivaksi mikäli virhetoimintoja ei testissä ole esiintynyt. Mitä suurempi yksikkö testauksen kohteena on, sitä vaikeampi 100 % tasoa on saavuttaa. Jos esimerkiksi ohjelmassa on 50 lausetta ja 40 niistä suoritetaan jonkun testin osana, tällöin kyseisellä testillä on saavutettu (40/50)*100 = 80 % lausekattavuus. Yleisimmin käytetyt kattavuudet: Lausekattavuus: lausekattavuus ilmoittaa, kuinka suuressa osassa testattavan yksikön lauseista on käyty. Haaraumakattavuus: ilmoittaa kuinka suuri osa siirtymistä (yhteys kahden lauseen välillä) on testeissä käyty läpi suhteessa testauksen kohteena olevan yksikön kaikkien siirtymien määrään. 3.4 Testauksen raportointi Testauksesta kirjoitetaan testausraportti, joka koskee lähinnä järjestelmätestausta, jossa todennetaan ohjelmiston toimivuus suhteessa vaatimuksiin. Yksikkötestaus: Toiminta kattaa valitun kriteerin OK ( ei kirjata testausraporttiin ). Integrointitestaus: Toiminta kattaa valitun kriteerin OK ( ei kirjata testausraporttiin ). Järjestelmätestaus: Testaukset ja niiden tulokset kirjataan testausraporttiin. 8

13 4 Yksikkötestaus Tässä luvussa kerrotaan yksikkötestauksen periaatteet Ipa-ohjelmistotuotantoprojektissa. Tavoitteena on se, että kaikki yksiköt tulee testattua riittävän kattavasti ja todennettua, että ne toteuttavat niiltä vaaditut tehtävät. Yksikkötestauksessa suoritetaan seuraavat testit: Toiminnallisuutta testaavat testit: testataan, että yksikkö suorittaa siltä vaaditut tehtävät, eikä tee sellaista mitä sen ei pitäisi tehdä (mustalaatikkotestaus). Rakennetta testaavat testit: testaus käy riittävän kattavasti läpi ohjelmakoodin osuudet (lasilaatikkotestaus). 4.1 Testattava yksikkö Yksikkötestauksessa testauksen kohteena ovat pienimmät loogiset ohjelmistonosat. Projektissa tällaisia ovat esimerkiksi java-luokat, sen metodit ja muut toiminnallisuutta sisältävät sivut. Myös pieniä vahvasti toisiinsa sitoutuneita luokkia eli ryppäitä (cluster) voidaan testata yksikkötestauksen menetelmin. 4.2 Ajurit ja tyngät Jotta yksiköt saadaan testattua on mahdollisesti käytettävä ajureita(driver) ja tynkiä (stub). Ajuri: Testiajurit korvaavat komponenttihierarkiassa komponenttien yläpuolelle sijoittuvat yksiköt, jotka kutsuvat tai käyttävät testattavan ohjelmistokomponentin palveluita. Testiajuri ottaa vastaan ja muokkaa testiaineiston testattavan komponentin vaatimaan muotoon, kutsuu komponenttia ja vastaanottaa tuloksen. Tynkä:Yksikkö- ja integraatiotestauksessa yksikkö tarvitsee testaamattoman komponentin palveluita. Testaukseen ei kuitenkaan saa liittää testaamattomia komponentteja, vaan on tehtävä tynkä, joka tarjoaa minimivaatimukset testauksen käyttöön (esimerkiksi metodia testattaessa tyngät korvaavat kutsut muihin metodeihin ja olioihin). 4.3 Luokkien testaus Yksikkötestauksessa testaustapaukset perustuvat ohjelman koodiin ja sen rakenteisiin. 9

14 Tämän vuoksi yksikkötestauksen ja testitapaukset kirjoittaa yleensä kyseisen luokan kirjoittaja. Toisaalta koodin kirjoittaja voi sokaistua omalle koodilleen, jolloin toisen henkilön on mahdollisuus löytää koodia tarkastamalla virheitä, jotka liittyvät virheellisiin indeksointeihin, alustamattomiin muuttujiin, käyttämättömiin attribuutteihin ja niin edelleen. Luokkatestaus on vastuupohjaista, sillä luokat ovat vastuussa siitä, että luokan palvelut toimivat oikein. Luokkatestauksessa keskeistä on palveluiden toiminnan ja poikkeustilanteiden varmistus. Luokkien testaaminen [Tai04]: Luokka sisältää sille suunnitellut metodit, jolloin se on valmis testaukselle. Luokka testataan lähettämällä viestejä (kutsuja) sen metodeille. Oliolla on tila, joka on siihen kohdistuneiden metodikutsujen summa. Kutsujärjestystä vaihtamalla voidaan päätyä eri tiloihin. Kaikki eri tilat tulee testata. Luokan ajuri kutsuu luokan metodeita seuraavassa järjestyksessä [Tai04]: Luo olion (konstruktori). Lukijametodien suoritus (get-metodit). Metodien suoritus, joiden palauttama arvo on totuusarvo (true/false). Kirjoittajametodien suoritus (set-metodit). Läpikäyvät metodit (iteraattorit). Olion tuhoavat metodit (destruktorit). 4.4 Yksikkötestauksen kattavuus Ipa-projektissa Lausekattavuus (statement coverage) on yksinkertaisin kattavuusmalli (IEEE ohjelmistostandardin minimivaatimus), mutta on riittävä tässä projektissa. Lausekattavuudessa kriteerinä on käydä läpi kaikki verkon solmut (lauseet). Yksikkötestauksen kattavuudet: 1.Lauseet: Kaikki lauseet suoritettava vähintään kerran. 2.Silmukat: muuttujille käytetään seuraavia arvoja: Liian pieni arvo. Minimiarvo +/

15 Arvo väliltä (minimi-maksimi), yleensä välin keskeltä. Maksimiarvo +/- 1 Liian suuri arvo 3. Taulukot: 1. indeksi negatiivinen 2. ylivuodon suoritus. 4. Merkkijonot: Tyhjä merkkijono, merkkijonon pituus 0. Merkkijonon pituus 1. Merkkijonon pituus maksimi. Merkkijonon pituus ylittää maksimin. Erikoismerkit merkkijonoissa. Esimerkki lausekattavuudesta ja silmukoiden testauksesta (kuva 2): 1. Kaikkien lauseiden läpikäynti vaatii testeissä rivin 4 ehto on tosi tai epätosi, sekä silmukan muuttujan n arvo on vähintään Silmukan testauksessa silmukka suoritetaan 0, 1, 2, (m on arvo väliltä: {2<m<MAX-1}, yleensä keskeltä väliä), (MAX-1), (MAX), (MAX+1) kertaa. Kuva 2: Lausekattavuusesimerkin 'koodi'. 11

16 Ongelmatilanteita lausekattavuuden käytössä: if(ehto)lause; vaatii vain yhden testin ehto on tosi, ei vaadi ehto on epätosi testausta! switch(ehto) case..., vaatii, että caset käydään läpi, mutta ei testiä, missä mikään case ei toteudu! 4.5 Yksikkötestauksen hyväksymiskriteerit Ipa-projektissa Ipa-projektissa yksikkötestauksen tavoitteena on käydä läpi kaikki ohjelmiston koodirivit, mutta 80 % kattavuuskriteerin täyttyminen voidaan katsoa yksikön testaamisen hyväksytyksi. Yksiköiden osalta tulee olla testattu (kattavuuskriteerin rajoissa): Kaikki yksikön toiminnot on testattu. Kaikki yksikön tilat on testattu. Kaikki poikkeustilanteet on testattu. 4.6 Testisyötteen valinta Testisyötteen valinta vaatii harkintaa ja suunnittelua, jotta testausprosessi olisi mahdollisimman täydellistä. Kaikkia mahdollisia testitapauksia ei kuitenkaan ole järkevää ja mahdollista suorittaa annettujen aikarajojen puitteissa. Esimerkiksi silmukkaa ei ole järkevää testata kaikilla mahdollisilla kierrosmäärillä. Arvoalueanalyysi on keino rajata testitapauksia. Arvoalueanalyysin ideana on rajata syötteet sellaisiin, että kaikki mahdolliset arvoalueet tulevat testatuiksi. Syötteen arvoalue ositetaan osa-arvoalueiksi, joissa yksikön toiminnan oletetaan olevan samanlaista. Esimerkki: yksikkö voi käsitellä tiedostoa, jonka MAX koko on 10kb. Osa-arvoalueet: tyhjä tiedosto tiedoston koko välillä 0<koko<10kb koko 10kb koko10kb (+/- 1b) koko>10kb 12

17 4.7 JUnit:n käyttö projektissa JUnit on testikehys java-luokkien testaamiseen. Eclipsessä on valmiina JUnit testausympäristö. Eclipseä käyttämällä ei siis tarvitse itse määritellä testausympäristöä. Junitissa testattavalle luokalle kirjoitetaan testiluokka seuraavasti: Testiluokan nimi johdetaan alkuperäisestä luokasta lisäämällä perään "Test". Testiluokka periytetään luokasta TestCase. Testiluokka sisällytetään samaan pakkaukseen kuin alkuperäinen luokka. Testiluokkaan kirjoitetaan testimetodeja siten, että nimet ovat aina "test"alkuisia. Testimetodit ovat java-metodeita ilman parametreja. Näissä käytetään väittämiä eli assert-metodeja vertaamaan odotettuja tuloksia saatuihin tuloksiin. Testit alustetaan siten, että testiluokkaan kirjoitetaan TestCase-luokan määrittelemään setup-metodiin luokan muuttujien alustusarvoja. Lisätietoja ohjelmasta sivuilla Cactus projektissa Cactus on testikehys palvelinpuolen luokkien testaukseen. Laajennoksella StrutsTestCase sitä voidaan käyttää projektin Struts:ia käyttävien osuuksien testaukseen. Lisätietoja ja ohjeita sivulla: 5 Integrointitestaus Integrointitestauksessa testataan yksiköiden välistä yhteistoimintaa. Yksiköiden välinen toiminta tapahtuu rajapintojen välityksellä, joten integrointitestaus voidaan käsittää rajapintojen testaamisena. Mitä pienempinä kokonaisuuksina integrointi tehdään, sitä helpommin havaitaan yhteistyössä esiintyvät ongelmat. Vaikka yksiköt toimisivat oikein eivät ne välttämättä toimi keskenään. Integrointitestauksessa pyritään löytämään tällaiset virheet. Tässä luvussa esitetään lyhyesti integrointitestauksen periaatteet Ipa-projektissa. Huomio: Integrointitestauksessa suurin virhe on koota kaikki komponentit kerralla yhteen (Big-bang menetelmä) ja yrittää testata rajapintoja tällä tavoin. Virheiden syyn löytäminen on tällöin hankalaa tai järjestelmä ei käynnisty ollenkaan. 13

18 5.1 Integrointitestausprosessi Integrointitestausprosessissa pyritään löytämään rajapintoja koskevia virheitä. Muunlaisia virheitä ei pitäisi tässä vaiheessa löytyä, sillä yksiköt on testattu. Integrointitestausprosessi jakaantuu seuraavanlaisiin vaiheisiin [Tai06]: Selvitetään erillisten yksiköiden kohdalta, mitä rajapintojen palveluita yksiköt vaativat tai tarjoavat toisilleen. Palveluille tehdään arvoalueanalyysi (kts. 4.6) ja valitaan testisyötteet. Käytetään rajapintaa annetuilla testisyötteillä kutsujan kautta. Integrointitestauksessa pyritään käyttämään Bottom-up strategiaa, jossa yksiköitä kootaan alhaalta ylöspäin yhteen, jolloin saadaan suurempia kokonaisuuksia. Ipa-projektissa tämä tarkoittaa, että integrointia suoritetaan tietokannasta päin kohti käyttöliittymää. Kyseistä bottom-up strategiaa havainnollistetaan seuraavassa esimerkissä. Esimerkki (kuva 3): Ohjelman komponentit A, B, C, D, E, F. Ylemmät komponentit käyttävät alempien komponenttien palveluita. Ensiksi testataan alemman tason komponentit E, C ja F, joille tarvitaan testiajurit, E:lle tarvitaan B:tä simuloiva testiajuri ja niin edelleen. Tämän jälkeen voidaan liittää (B-E) ja (D-F), joille tarvitaan A:ta simuloiva testiajuri. Lopuksi liitetään (A-B), (A-C) ja (A-D). Kuva 3: Integraatiotestauksessa yhteenliitettävät komponentit A, B, C,D, E ja F. 14

19 5.2 Luokkien riippuvuuskaaviot Integrointitestauksen suunnittelun apuna voidaan käyttää erilaisia luokista piirrettyjä riippuvuuskaavioita (kuva 4). Kaaviossa kuvataan luokkien ja niiden metodien välisiä yhteyksiä, joiden perusteella voidaan määrittää testauksessa läpikäytäviä rajapintoja näiden luokkien välillä. Kuva 4: Luokkien riippuvuuskaavio luokkien välisten yhteyksien hahmottamiseen [Win98]. 5.3 Ongelmakohtia integrointitestauksen toteuttamisessa Oliopohjaisissa järjestelmissä teoreettisia yhteyksiä voi olla n²-n kappaletta, n on luokkien lukumäärä [Win98]. Kaikkien eri yhteyksien kattava läpikäynti on usein hyvin vaikea toteuttaa. Tärkeimmät ja käytetyimmät yhteydet ovat testauksessa etusijalla. Perintä, monimuotoisuus ja ylikuormittaminen aiheuttavat ongelmia. Rajapinnan väärinymmärrys (kutsuja / kutsuttava). Rajapinnan käyttö ei-toivotulla tavalla. Sivuvaikutukset (kutsujan odottamat, kutsuttavan aiheuttamat, poikkeustilanteet). Arvoalueiden väärinymmärrykset ja arvoalueiden rajat 15

20 5.4 Ajurit ja tyngät integrointitestauksessa Kuten yksikkötestauksessa tarvitaan integrointitestauksessa ajureita ja tynkiä rajapintojen mukaisesti (katso 4.2 Ajurit ja tyngät.). 5.5 Integrointitestauksen ajankohta Integrointitestaus voidaan aloittaa heti kun integroitavaksi tarkoitetuille yksiköille on suoritettu yksikkötestaus siten, että ne täyttävät vaaditut hyväksymiskriteerit. 5.6 Integrointitestauksen hyväksymiskriteerit Kun yksiköiden välinen toiminta (niiden rajapinnat) on osoitettu toimiviksi ja kaikki komponentit on integroitu yhteen on integrointitestaus suoritettu. Tällöin voidaan ryhtyä testaamaan koko järjestelmää. 6 Järjestelmätestaus Järjestelmätestauksessa testataan ohjelmistotuotetta kokonaisuutena ja se suoritetaan ohjelmiston käyttöliittymän kautta eli on niin sanottua mustalaatikkotestausta. Täydellisesti suoritetun yksikkötestauksen ja integrointitestauksen jälkeen järjestelmätestausvaiheessa ei tulisi enää paljastua muita kuin virheellisestä vaatimusten määrittelystä johtuvia virheitä. Muuten edellä menneet testausvaiheet ovat epäonnistuneet ja niihin joudutaan palaamaan ennen kuin järjestelmätestausta päästään jatkamaan. Tässä luvussa kuvataan järjestelmätestauksen periaatteet Ipa-projektissa. 6.1 Järjestelmätestauksen testauskohteet Järjestelmätestauksessa pyritään saamaan vastaukset seuraaviin kysymyksiin: Tekeekö ohjelmisto ne toiminnot, jotka on vaadittu? Onko ohjelmisto helppokäyttöinen? Vastaavatko manuaalit ohjelmistoa? Toimiiko ohjelmisto kuormitettuna? Toimiiko ohjelmisto suunnitellussa ympäristössä? Pysyykö ohjelmisto pystyssä ja onko se vikasietoinen? 16

21 Onnistuuko asennus ohjeiden mukaan? 6.2 Järjestelmän käyttöön liittyvät rajoitukset Ipa-projektissa toteutettavan ohjelmiston käytön rajoitukset johtuvat käyttäjäryhmien erilaisista ominaisuuksista ja oikeuksista, sekä paketteja koskevista immateriaaliluokista. Seuraavassa lueteltu lyhyesti keskeisimmät järjestelmän testaukseen vaikuttavat erot näille käyttöä rajoittaville tekijöille. Järjestelmän käyttäjäryhmiä ovat: 1. Ylläpitäjällä on oikeudet kaikkiin järjestelmän resursseihin. 2. Toimittajalla on oikeudet lisätä, muokata ja poistaa omia pakettejaan. Resursseja säätelee annettu immateriaalioikeusluokka. 3. Sisäkäyttäjällä oikeus hakea ja käyttää kaikkia paketteja, joihin on annettu oikeus. Käyttäjällä ei ole oikeuttaa muokata paketteja. 4. Ulkokäyttäjä (sisäänkirjautunut (sähköpostin pääte ei ole.helsinki.fi)) oikeus julkisiin paketteihin). 5. Anonyymillä käyttäjällä (sisäänkirjautumaton) oikeus julkisiin paketteihin. Käyttäjäryhmillä on erilaisia oikeuksia kohdistuen järjestelmän käyttöön ja tietosisällön muokkaukseen. Ulkokäyttäjää korkeammat käyttäjäluokat on mahdollista saada vain ylläpitäjä tasolla varustetun käyttäjän myöntämänä (poikkeuksena uusi käyttäjä, jolla sähköpostitunnuksen pääte on helsinki.fi, joka saa sisäkäyttäjän oikeudet). Järjestelmällä on käyttäjästä seuraavanlaiset tiedot: Käyttäjätunnus. Käyttäjän nimi. Sähköpostiosoite. Immateriaalioikeusluokkia, jotka ilmoittavat luokat, joita käyttäjällä on oikeus katsoa. Käyttäjän kieli. 6.3 Järjestelmätestauksen suoritus Järjestelmätestauksen suorituksen pitäisi toteuttaa henkilö, joka ei ole ollut toteuttamassa 17

22 järjestelmää. Käytännössä Ipa-projektissa tällaiseen ei ole mahdollisuutta vaan järjestelmätestauksen testitapaukset ja kirjaaminen suoritetaan vapaiden henkilöresurssien puitteissa. 7 Järjestelmätestauksen testitapaukset Tässä luvussa kuvataan järjestelmätestauksessa käytettävät vaatimuksiin perustuvat testitapaukset. Nämä testitapaukset, niiden kuvaukset ja saadut tulokset kirjataan testausraporttiin. Testit on ryhmitelty niin, että yksi testi voi sisältää useita testitapauksia. Esimerkiksi paketin haku on testi, joka tehdään kaikille käyttäjäryhmille (6.2) erikseen. Järjestelmätestauksen merkkijonosyötteissä käytetään seuraavanlaisia testisyötteitä: Tyhjä merkkijono (pituus on 0). Merkkijonon pituus 1. Mahdolliset oikeat (odotetut) syötteet. Erikoismerkit merkkijonoissa. Oikea syöte (odotettu) + erikoismerkkejä (esimerkiksi: *,. / % ja niin edelleen). 7.1 Sisään- ja uloskirjautuminen Testi 001: Sisäänkirjautuminen: Virheetön toiminta. Järjestelmän aloitussivulla käyttäjä klikkaa kirjaudu sisään painiketta. Tämän jälkeen järjestelmä kysyy käyttäjätunnuksen ja salasanan, jotka käyttäjä syöttää annettuihin kenttiin virheettömästi. Testaus suoritetaan kaikille käyttäjäryhmille (6.2). Odotettu tulos: Käyttäjä pääsee kirjautumaan järjestelmään. Sisäänkirjoittautuneen tunnus näkyy käyttöliittymässä, sekä sisäänkirjoittautumistoiminto muuttuu uloskirjautumistoiminnoksi. Lisäksi käyttäjälle, joka on oikeutettu muuttamaan järjestelmän tietosisältöä esitetään vastaava valikko. Testi 002: Sisäänkirjautuminen: Virheelliset tapaukset. Testauksessa sisäänkirjautumiskenttiin syötetään virheellisiä merkkijonoja luvun 7 alussa 18

23 kuvattujen merkkijonosyötteiden ohjeiden mukaan. Testataan tapaukset joissa toinen tai molemmat kentät sisältävät edellä mainittuja poikkeuksellisia merkkijonoja. Etusijalla syötteet, joissa toinen kenttä on oikein ja toinen sisältää pientä poikkeamaa (esimerkiksi ylimääräinen * verrattuna oikeaan). Odotettu tulos: Kirjautuminen epäonnistuu, mistä järjestelmä antaa ilmoituksen. Testi 003: Kirjautuminen järjestelmästä ulos : Virheetön toiminta. Käyttäjä klikkaa kirjaudu ulos. Tehdään kaikille käyttäjäryhmille. Odotettu tulos: Käyttäjän tietoja ei enää saa näkyviin käyttöliittymässä, eikä käyttäjän tietoihin ja oikeuksiin pääse käsiksi ilman uutta sisäänkirjautumista. 7.2 Rekisteröityminen ja omien käyttäjätietojen muuttaminen Testi 004: Uuden käyttäjän rekisteröityminen: Virheetön toiminta. Uusi käyttäjä haluaa rekisteröityä järjestelmään ja painaa rekisteröintiin viittaavaa linkkiä. Käyttäjälle avautuu kentät, joihin hän antaa omat (vaaditut) tietonsa. Kun tiedot on täytetty lähettää käyttäjä tiedot järjestelmälle. Tämän jälkeen järjestelmä lähettää käyttäjälle vahvistuksen ja tunnuksen sähköpostilla, joiden avulla käyttäjä voi myöhemmin kirjautua järjestelmään. Odotettu tulos: Käyttäjä pääsee kirjoittamaan tietojaan järjestelmään, joka tallettaa käyttäjän tiedot. Järjestelmä lähettää käyttäjälle sähköpostin välityksellä tunnuksen, jonka avulla uusi käyttäjä rekisteröityy järjestelmän käyttäjäksi. Rekisteröitymisen jälkeen käyttäjä voi kirjautua järjestelmään annetuilla käyttöoikeuksilla (sisäkäyttäjä), kuten vanhat käyttäjät. Testi 005: Uuden käyttäjän rekisteröityminen, virheellinen toiminta. Uusi käyttäjä kirjoittaa jo käytössä olevan tunnuksen. Kaikkia tarvittavia tietoja ei ole annettu. Odotettu tulos: Kirjautuminen epäonnistuu. Järjestelmä ilmoittaa virheestä. Järjestelmän tietosisältöön ei muutoksia. Testi 006: Omien käyttäjätietojen muuttaminen: Virheetön toiminta. Rekisteröityneet käyttäjät voivat halutessaan ja tarvittaessa muuttaa omia 19

24 käyttäjäkohtaisia yhteys- ja kielitietojaan. Odotettu tulos: Kun yhteystietoja koskevat tietokentät on täytetty vaaditulla tavalla ja lähetetty järjestelmälle, se hyväksyy muutokset. Uusitut tiedot näkyvät käyttäjän tiedoissa. Testi 007: Omien käyttäjätietojen muuttaminen: Virheellinen toiminta. Testit eivät koske ylläpitäjätason käyttäjiä. Käyttäjä ei saa päästä muuttamaan omia käyttäjäoikeuksiaan. Käyttäjä ei saa päästä muuttamaan omia immateriaalioikeuksiaan. Tietoja muutettaessa tietokenttiin ei anneta kaikkea tarpeellista tietoa. Odotettu tulos: Järjestelmä ei tarjoa kyseisiä palveluita tai järjestelmä ei hyväksy muutoksia ja ilmoittaa virheestä. 7.3 Pakettien julkaisu, asiasanat, kategoriat ja paikkatieto Testi 008: Julkaisemattoman paketin muodostaminen. Käyttäjät joilla on oikeus pakettien luontiin (toimittajat, ylläpitäjät) voivat määritellä paketin julkaisemattomaksi, jolloin sen ei tarvitse sisältää kaikkia julkaistuun pakettiin vaadittavaa tietoa (seuraava testitapaus). Julkaisematon paketti ei näy muille käyttäjille. Odotettu tulos: Toimittaja tai ylläpitäjä voi määritellä paketin julkaisemattomaksi, jolloin se näkyy julkaisemattoman paketin tekijälle, mutta ei muille käyttäjille. Testi 009: Paketin julkaisu. Paketin voi julkaista vain siihen oikeutettu henkilö (toimittaja tai ylläpitäjä). Julkaistavaksi tarkoitettu paketti sisältää seuraavat tiedot, jotka paketin lisääjän tulee antaa vaaditulla tavalla. Paketin kieli (Suomi, ruotsi, englanti). Nimi, tarvitsee olla vain paketin kielellä. Paketin tila (tässä tapauksessa julkaistu). 20

25 Paketin immateriaalikategoria, jonka mukaan paketti on näkyvissä vastaavan immateriaaliluokan omaavan käyttäjän hakutuloksissa (1 määre. Esimerkiksi: julkinen, HY, ja niin edelleen). Sisällön kuvaus. Maantieteellinen paikka (ei tarvitse olla tarkka). Vähintään 1 asiasana. Vähintään 1 tieteenala. Pakettiin liittyvät aikamääreet. Vähintään 1 liitetiedosto. 1: Maantieteellisen paikan, asiasanan ja tieteenalan käyttäjä voi halutessaan valita käytössä olevasta valikoimasta. 2: Jos käytettävissä olevat vaihtoehdot eivät riitä, käyttäjä voi lisätä haluamansa vaihtoehdon. 3: Käyttäjä voi määrittää paketeille vain samoja immateriaalioikeuksia, kuin hänellä on. Käyttäjä määrittää palvelimelle ladattavan tiedoston käsittelytavan, joka voi olla joko tavallinen tiedosto tai zip-tiedosto. Odotettu tulos: Järjestelmä liittää paketin julkaistujen pakettien joukkoon lisäysmääreissä määriteltyyn paikkaan siten, että paketti löytyy haettaessa vastaavilla hakumääreillä. Paketin lataamisessa käytetään käyttäjän määrittelemää käsittelytapaa. Testi 010: Paketin julkaisuyritys (virheellisiä testejä). Testissä yritetään julkaista pakettia, vaikka kaikkia vaadittuja kenttiä ei ole täytetty oikein. Testauksessa riittää kun yksi kerrallaan vaadittavista kentistä muutetaan virheelliseksi muiden kenttien ollessa oikeellisia. Odotettu tulos: Pakettia ei julkaista. Järjestelmä ilmoittaa, että kaikkia julkaisemiseen vaadittuja tietoja ei ole annettu. Testi 011: Paketin julkaisu ja asiasana Paketin lisäämisen yhteydessä paketille on lisättävä vähintään 1 asiasana. Käyttäjä voi valita asiasanan järjestelmässä valmiina olevasta asiasanalistasta, joka päivittyy sen mukaan mitä käyttäjä tekstikenttään kirjoittaa. Valinta tapahtuu hyväksymällä valittu 21

26 asiasana, jolloin se liitetään luotavan paketin asiasanaksi. Odotettu tulos: Paketti lisätään järjestelmään ja se löytyy haettaessa vastaavalla asiasanalla. Testi 012: Uuden asiasanan lisääminen paketin lisäämisen yhteydessä Paketin lisäämisen yhteydessä käyttäjä haluaa liittää pakettiin asiasanan, jota ei löydy järjestelmässä valmiina olevasta asiasanalistasta. Tällöin käyttäjä voi lisätä haluamansa sanan asiasanalistaan ja lisättävään pakettiin. Odotettu tulos: Käyttäjä voi lisätä uuden asiasanan asiasanalistaan. Lisäämisen jälkeen se löytyy asiasanalistalta ja sitä voidaan käyttää uusien pakettien lisäämisen yhteydessä. Lisätty paketti myös löytyy asiasanan mukaan. Testi 013: Kategorian lisääminen pakettiin. Pakettiin on lisättäessä järjestelmään liitettävä kategoria johon se kuuluu. Järjestelmästä löytyy muuttumattomat yläkategoriat (julkaisustatus, kieli, paikka, tieteenala, teema ja paketin tiedostotyypit), joilla on alakategorioita (esimerkiksi tieteenala matematiikka). Pakettiin liitetään kategoria valmiina olevista vaihtoehdoista, jos sellainen löytyy. Odotettu tulos: Luotuun pakettiin on liitetty valittu kategoria. Myöhemmin hakuja tehtäessä haun kohdistuessa kyseiseen kategoriaan paketti löytyy hakutulosten joukosta. Testi 014: Uuden kategorian lisääminen paketin lisäämisen yhteydessä. Jos paketin lisäämisen yhteydessä kategorioista ei löydy haluttua voi paketin lisääjä lisätä uuden alakategorian. Esimerkiksi jos tieteenalojen yläkategorioista ei löydy tähtitiedettä, voidaan se lisätä kyseisen yläkategorian alakategoriaksi. Odotettu tulos: Uusi alakategoria löytyy myöhemmin alakategorioiden joukosta ja on valittavissa lisättäessä uusia paketteja. Myöhemmin hakuja tehtäessä haun kohdistuessa kyseiseen kategoriaan paketti löytyy hakutulosten joukosta. Testi 015: Paikan lisääminen paketin lisäämisen yhteydessä Lisättäessä pakettia on siihen liitettävä maantieteellinen paikka, joka voi olla joko tarkka (sisältää paikkakoordinaatit: leveys- ja pituusasteet) tai karkeampi esimerkiksi koko läänin alue. Pakettiin liittyvä maantieteellinen paikka valitaan järjestelmässä valmiina olevasta ontologiapuusta. Jos olemassa olevat vaihtoehdot eivät riitä, voi käyttäjä lisätä oman vaihtoehtonsa. Oma vaihtoehto liittetään johonkin ontologiasta löytyvään emosolmuun. 22

27 Odotettu tulos: Pakettiin on liitetty maantieteellinen määre siten, että haettaessa paketteja se löytyy hakutulosten joukosta vastaavalla paikkamääreellä. Testi 016: Paketin muokkaaminen Paketin sisältöä ja sen tietoja (Testi 011) voivat muuttaa paketin toimittaja tai ylläpitäjän oikeuksin varustetut käyttäjät pakettieditorin avulla. Muutokset voivat olla seuraavanlaisia: Liitetiedostoja voi lisätä ja poistaa Paketin kuvausta, hakumääreitä, immateriaalikategoriaa ja niin edelleen voi muuttaa. Odotettu tulos: Paketin sisällön muuttamisen ja hyväksymisen jälkeen uudet tiedot ovat voimassa ja haettaessa paketti löytyy muutetuilla tiedoilla. Testi 017: Paketin käyttäminen uuden pohjana Paketin lisääjät voivat Odotettu tulos: Testi 018: Paketin poistaminen Paketin voi poistaa järjestelmästä sen toimittaja tai ylläpitäjätason käyttäjät. Pakettissa ei poistettaessa ole liitetiedostoja jäljellä. Jos poistettava paketti sisältää liitetiedostoja on ne pakettieditorilla ensin poistettava. Odotettu tulos: Liitetiedostoja sisältämättömän paketin voi poistaa järjestelmästä. Se ei enää näy hakutuloksissa. 7.4 Pakettien haku ja lataaminen Paketteihin liittyy immateriaalioikeus, joka määrittää kenellä on oikeus paketin tietoihin. Julkinen paketti on avoin kaikille käyttäjille, muihin käyttäjällä täytyy olla määritelty vastaava immateriaalioikeus. Testi 019: Julkisten pakettien haku. Kaikki julkiset paketit, jotka vastaavat hakurajauksia näytetään hakutuloksissa kaikille käyttäjille. Odotettu tulos: Hakutuloksissa näkyvät kaikki julkiset paketit, joiden hakumääreet täyttyvät. 23

28 Testi 020: Immateriaalioikeuksilla rajoitettujen pakettien haku. Paketeille on lisättäessä järjestelmään määritelty 1 immateriaaliluokka, johon paketti kuuluu. Jos immateriaaliluokka on jokin muu, kuin julkinen täytyy käyttäjälle olla määritelty vähintään vastaava immateriaalioikeus, jotta paketti näkyy käyttäjän hakutuloksissa. Odotettu tulos: Käyttäjän hakutuloksiin ilmestyy vain paketteja, joihin hänellä on vastaava tai korkeampi immateriaalioikeusluokka. Testi 021: Pakettien haku kielen mukaan Haku voidaan tehdä valitsemalla paketissa käytetty kieli (suomi, ruotsi tai englanti). Odotettu tulos: Hakutuloksissa näytetään kieltä vastaava tulosjoukko, johon käyttäjällä on oikeudet. Testi 022: Pakettien haku asiasanalla Haussa voidaan käyttää valmiita järjestelmän sisältämiä asiasanoja. Asiasanaa klikkaamalla saadaan asiasanaa vastaava tulosjoukko. Odotettu tulos: Hakutuloksissa näytetään asiasanaa vastaavien pakettien tulosjoukko, joihin käyttäjällä on oikeudet. Testi 023: Pakettien haku kategorian mukaan Paketteja voidaan hakea kategorioiden (alueet, tieteenalat, teemat, kieli) mukaan klikkaamalla rajoittavaa kategoriaa. Odotettu tulos: Haun tuloksissa näkyvät ne kategoriaa vastaavat linkit, joihin käyttäjällä on vastaavat oikeudet. Kategorisoitua hakua voidaan jatkaa uudella kategorisoidulla haulla. Testi 024: Paketin haku paikkamääreellä Käyttäjä voi hakea paketteja eritasoisilla ja laajuisilla paikkamääreillä (esimerkiksi läänin, maakunnan, kaupungin jne.). Odotettu tulos: Haun tuloksissa näkyvät ne alueelle sijoittuvat paketit, joihin käyttäjällä on käyttöoikeudet. Testi 025: Pakettien haku vapaalla tekstihaulla 24

29 Paketteja voi hakea vapaalla tekstihaulla kirjoittamalla koko hakusanan tai vain osan siitä. Järjestelmä hakee hakusanaan tai sen osaan sopivia paketteja. Odotettu tulos: Hakutuloksiin ilmestyy tuloksia, jotka vastaavat vapaassa tekstihaussa olevaa hakurajausta ja joihin käyttäjällä on käyttöoikeudet. Vapaa tekstihaku voi päättyä myös tyhjään tulosjoukkoon. Testi 026: Paketin liitetiedostojen lataaminen. Hakutuloksiin ilmestyy vain paketteja, joita käyttäjä voi ladata itselleen. Käyttäjä klikkaa jonkin hakutuloksen linkkiä ja saa paketin sisällön näytölle. Käyttäjä haluaa ladata kaikki paketin sisältämät liitetiedostot tai vain osan niistä ja valitsee haluamansa kohteet. Lataaminen tapahtuu tiedoston lataamisena tai pakatun Zip-tiedoston lataamisena. Odotettu tulos: Hakutuloksiin ilmesty vain sellaisten pakettien linkkejä, joita käyttäjä on oikeutettu katselemaan ja lataamaan. Lataaminen tapahtuu pakatun tai pakkaamattoman tiedoston lataamisena, minkä jälkeen paketin tiedostot ovat käyttäjän koneella. Testi 027: Viittaukset URL:n kautta. Järjestelmän paketteihin ja niissä oleviin liitetiedostoihin voidaan viitata suoraan URLlinkin avulla. Odotettu tulos: URL-Linkkiä klikkaamalla käyttäjä joutuu pääsynhallintaan, jossa varmennetaan käyttöoikeus linkin viittaamaan materiaaliin. Jos käyttöoikeudet kyseiseen materiaaliin ovat kunnossa käyttäjä pääsee tarkastelemaan sitä. 7.5 Käyttöliittymä ja käytettävyys Nämä testit koskevat käyttöliittymän asiakkaalle näkyviä palveluita. Näissä testeissä kiinnitetään huomiota vain käyttöliittymän toimintaan. Vastaavanlaisia testejä tehdään muissakin osioissa, jolloin kiinnitetään tarkemmin huomiota järjestelmän toimintaan, esimerkiksi hakujen toimivuus. Testi 028: Kielivalinta. Käyttöliittymästä, etusivulta voidaan vaihtaa käytettävä kieli (Suomi, Ruotsi, Englanti). Odotettu tulos: Kielivalinta johtaa näkymään, joka vastaa valittua kieltä. Testi 029: Käyttöliittymässä käytettävän kielen yhdenmukaisuus. 25

30 Käyttöliittymässä (sen kentissä) käytettävä kieli on yhdenmukainen eri käyttötapauksissa ja näkymissä. Odotettu tulos: Käyttöliittymän kieli on yhdenmukainen eri tilanteissa. Ei esiinny esimerkiksi tilannetta, jossa jokin kenttä on ruotsiksi, kun käyttäjän kielenä on englanti. Testi 030: Sisään- / uloskirjoittautumiskenttä Sisään- / uloskirjoittautumiskentän toimivuus. Odotettu tulos: Alkutilassa kentässä lukee kirjaudu sisään, kirjauduttua siinä lukee kirjaudu ulos. Testi 031: Sivujen käyttäjävalikko Käyttöliittymä tarjoaa eri käyttäjäryhmille erilaiset järjestelmän resurssien käyttöön tarvittavat valikot. Odotettu tulos: Käyttöliittymän resurssien käyttöön oikeuttava valikko vastaa käyttäjän oikeustasoa. Ylläpitäjän resurssivalikoima on suurin. Testi 032: Vapaan tekstihaun kenttä Hakusivulla on vapaan tekstihaun kenttä, johon voi kirjoittaa vapaan hakusanan, tai sanan osan. Odotettu tulos: Hakusivu sisältää vapaan tekstihaun kentän. Testi 033: Asiasanarajaus hakusivulla. Hakusivulla on toimiva asiasanarajaus. Odotettu tulos: Klikkaamalla asiasanojen päätasoa saadaan kaikki järjestelmän sisältämät asiasanat pudotusvalikkona ja hakutuloksiin kaikki paketit. Asiasanan valinnalla listalta saadaan hakutuloksiin sellaiset paketit, joiden nimessä tai kuvauksessa kyseinen asiasana esiintyy. Testi 034: Kategoriarajaus hakusivulla. Hakujen tuloksia voidaan rajata hakusivulla olevien kategoriakenttien (kieli, tieteenalat ja paikan) avulla. Odotettu tulos: Käyttöliittymässä olevat kategoriakentät rajaavat hakutuloksia kategorian 26

31 määräämällä tavalla. Testi 035: Tulosjoukon hakuikkuna ja siirtyminen hakusivujen välillä. Hakuikkunassa esitetään hakujen ehtoja vastaavat tulokset (paketit). Tulosjoukon ollessa suurempi, kuin hakuikkunaan mahtuu voidaan siirtyä seuraavalle hakuikkunasivulle. Odotettu tulos: Hakutuloksia voidaan selata eri sivuilla, jos tulokset eivät mahdu yhdelle tulossivulle. Testi 036: Pakettiotsikon korostus Hakuikkunassa oleva otsikkolinkki korostuu kun hiiren kohdistin on pakettiin sopivan suodatusattribuutin päällä. Odotettu tulos: Pakettiotsikoiden korostus kohdistuu hakusivulla oleviin otsikoihin siten, että hakuattribuutti liittyy korostettuun pakettiin (paketin nimeen tai sen kuvaukseen). Testi 037: Tooltipit Haetuista paketeista halutaan tarkempaa sisältötietoa ilman, että ponnahdusikkunat jäävät ruudulle. Viemällä hiiren osoitin hakutulosten kohdalle näytetään lyhyt kuvaus paketin sisältämistä tiedoista tooltipissä (rajatussa kentässä) ilman, että pakettia tarvitsee ladata. Tooltip poistuu hiiren kohdistimen poistuttua pakettiotsikon päältä. Odotettu tulos: Hiiren osoittimen alapuolella esitetään tooltipissä yleistä tietoa paketista hiiren osoittimen ollessa pakettiotsikon päällä. Testi 038: Kartta hakutulosten tukena. Järjestelmän etusivulla on Suomen karttakuva, johon hakutuloksiin liittyvät paketeille kuuluvat paikat näkyvät pisteinä, jos niille on tarkka piste määritelty. Odotettu tulos: Kuhunkin pakettiin, johon kuuluu tarkka paikkakoordinaatti näkyy kartalle piirrettynä 'pisteenä' oikealla maantieteellisellä paikallaan. Viemällä hiiren osoitin hakutuloksen päälle korostuu vastaava piste kartalla, jos sellainen paketilla on. Testi 039: Käyttöliittymän pakettinäkymä (paketin sisältöikkuna) Haluttaessa lista paketin sisältämistä tiedostoista klikataan halutun hakutuloksen nimeä. Odotettu tulos: Klikkaamalla hakutuloksen nimeä, saadaan lista paketin sisältämistä tiedostoista pakettinäkymään ruudulla, josta voidaan valita ladattavaksi kaikki pakettiin 27

32 liittyvät tiedostot tai osa niistä. Testi 040: Pakettieditori Pakettieditori on sivu, joka tarjoaa kaikki toimenpiteet, joita paketille voidaan tehdä. Odotettu tulos: Pakettieditorilla voidaan tehdä kaikki pakettien muokkaukseen tarvittavat toimenpiteet. Testi 041: Mahdollisuus palata etusivulle Käyttäjän ollessa muualla, kuin järjestelmän etusivulla voidaan sinne palata. Odotettu tulos: Järjestelmän etusivulle päästään aina muilta järjestelmän sivuilta. 7.6 Paikkaontologiat Testi 042: Pakettien hakuontologia 1 (esimerkiksi murrenäyte Vilppulasta). Hakutuloksissa esiintyvistä paketeista voidaan selvittää pakettiin liittyvä paikkaontologia. Paketin lisätiedoista näkyy pakettia koskeva paikkaontologia, joka voi olla tarkkuustasoltaan hyvin erilainen. Tarkimmillaan paketin paikka voidaan piirtää kartalle. Odotettu tulos: Esimerkkipaketin lisätiedoista nähdään, että Vilppula kuuluu Pirkanmaahan ja Pirkanmaa Länsi-Suomen lääniin ja niin edelleen. Testi 043: Pakettien hakuontologia 2: paikkakategorian rajaus. Haetaan paketteja, mutta rajataan pakettien haku koskemaan jotakin aluetta, esimerkiksi Keski-Suomen lääniä. Odotettu tulos: Paketit, joita saadaan hakutuloksiksi sijoittuvat Keski-Suomen läänin alueelle. Paketin lisääminen paikkaontologiaan (kts. pakettien lisääminen 7.3) 7.7 Ylläpitäjälle kuuluvia käyttötapauksia Testi 044: Käyttäjän lisäys erilaisilla oikeustasoilla : Virheetön toiminta. 28

33 Ylläpitäjä voi lisätä järjestelmään uuden käyttäjän (ulko-, sisäkäyttäjä, toimittaja ja ylläpitäjä) käsin syöttämällä vaaditut käyttäjää koskevat tiedot. Odotettu tulos: Kyseisin oikeuksin varustettu järjestelmän käyttäjä on muodostettu ja voi käyttää järjestelmää myönnetyillä oikeustasoilla. Testi 045: Käyttäjän oikeustason nostaminen. Ylläpitäjä voi antaa käyttäjälle korkeampia oikeusluokkia, jotka antavat käyttäjälle eri oikeuksia katsella, muokata ja käyttää materiaalia nostettujen oikeuksien mukaan. Odotettu tulos: Ylläpitäjän määrittelemä korkeampi oikeustaso on käyttäjän käytettävissä seuraavalla sisäänkirjoittautumiskerralla. Testi 046: Käyttäjän oikeuksien vähentäminen : Virheetön toiminta. Ylläpitäjä voi madaltaa käyttäjän oikeustasoa, jolloin oikeudet. Odotettu tulos: Seuraavalla kirjautumiskerralla oikeuksien vähennyksen kohteena olleen käyttäjän käytössä ovat Testi 047: Käyttäjän poisto : Virheetön toiminta. Ylläpitäjä poistaa tietyn käyttäjän. Odotettu tulos: Käyttäjä ei voi enää suoraan kirjautua järjestelmään ylläpitäjän poistamilla tunnuksilla. Testi 048: Ylläpitäjätason käyttäjän poisto. Ylläpitäjä ei voi poistaa toista ylläpitäjä tasolla varustettua käyttäjää. Odotettu tulos: Ylläpitäjätason käyttäjän poisto ei onnistu. Testi 049: Paketin poisto : Virheetön toiminta. Ylläpitäjä voi poistaa järjestelmän tietosisällöstä paketteja riippumatta tekijästä. Odotettu tulos: Ylläpitäjän poistettavaksi määritelty paketti poistuu järjestelmän tietosisällöstä, eikä ole enää käytettävissä. Testi 050: Käyttäjien lisääminen ryhmänä (tiedosto) : 29