Tik-76.115 Testaussuunnitelma

Älykäs kalenteri

Viimeksi päivitetty $Date: 2001/02/12 09:48:39 $.

SISÄLLYSLUETTELO

Versiohistoria

1. Johdanto

1.1 Tarkoitus

Dokumentti on Teknillisen korkeakoulun ohjelmistotyökurssilla (Tik-76.115) tehtävän Osprey-projektin testaussuunnitelma.

Tässä dokumentissa kuvataan testausprosessi toteutettavalle kalenteriarkkitehtuurille ja demosovellukselle.

Dokumentin kohdeyleisönä on projektin jäsenet, asiakas ja kurssin henkilökunta.

1.2 Tuote ja ympäristö

Testattava tuote on projektin aikana syntyvä kalenteriarkkitehtuuri sekä arkkitehtuurin päälle rakennettu demosovellus.

1.3 Määritelmät, termit ja lyhenteet

Käytettävät termit, määritelmät ja lyhenteet on määritelty erillisessä omassa projektin termistödokumentissa [OSPREY-T].

1.4 Viitteet

[HAIKALA] Ilkka Haikala, Jukka Märijärvi, Ohjelmistotuotanto, 5. painos, 1998 Suomen Atk-kustannus
[OSPREY-T] Osprey-ryhmä, Projekti Ospreyn termistöä, termit.html, viitattu 30.11.2000
[OSPREY-TOIM] Osprey-ryhmä, Toiminnallinen määrittely, viitattu 3.12.2000
[OSPREY-VAAT] Osprey-ryhmä, Vaatimusmäärittely, viitattu 3.12.2000
[JUNIT] http://www.junit.org/, Testauskehys, viitattu 3.12.2000
[OSPREY-CODECONV] Osprey-ryhmä, Projekti Ospreyn ohjelmointikäytäntö, viitattu 2.2.2000
[OSPREY-TESTITAPAUKSET] Osprey-ryhmä, Projekti Ospreyn testitapaukset, viitattu 11.2.2000

2. Ympäristö

Tuotteen käyttämä ajoympäristö on Java 2 Standard Edition. Eräs projektin tavoitteista on laitteistoriippumattomuus, joten laitteistovaatimuksia ei ole.

Moduulitestaus suoritetaan kunkin kehittäjän kehityskoneella.

Integraatio ja järjestelmätestaus suoritetaan projektin käyttöön varatuilla tietokoneilla.

2.1 Työkalut

Testaukseen pyritään käyttämään olemassa olevia työkaluja sellaisten ollessa saatavilla. Tarpeen mukaan voidaan myös tehdä omia testaus työkaluja.

BURANA ohjelmistoa käytetään virheiden raportointiin.

Netscape Communicator 4.7x ja Internet Exporer 5.x ovat käytössä www-liittymän testauksessa.

Moduulitestausohjelmistona käytetään JUnit testauskehystä. [JUNIT]

3. Koulutus

Testauksen vaatimaksi koulutukseksi katsotaan riittävän testausprosessin kuvaus. Yksittäiset käytettävät työkaluohjelmistot saattavat kuitenkin tuoda esiin lisäkoulutustarpeita jotka otetaan käsiteltäväksi sellaisten sattuessa.

4. Vastuu

Testauksesta on vastuussa Petri Väkeväinen.

Järjestelmätestauksen suorittamisen ja raportoinnin suorittaa Petri Väkeväinen.

Moduulitestauksen suunnittelu, suorittaminen ja raportointi on kunkin ko. moduulin kehittäjän vastuulla. Tämä ei ole hyvän testauskäytännön mukaista, mutta projektin resurssien puitteissa välttämätöntä.

Virheiden luokittelu tapahtuu projektiryhmän toimesta ja virheiden korjaus on ko. moduuleista vastaavien henkilöiden vastuulla.

5. Testauksen prosessikuvaus

5.1 Malli

Testauksessa pohjaudutaan yleisesti tunnettuun V-malliin. V-malli keskittyy eri vaiheissaan eri kerroksiin ohjelmistossa pienimmästä suurimpaan.

V-malli [HAIKALA]

Moduulitestauksessa testataan yksittäisten moduulien sisäistä toimintaa käyttäen työkaluina integroituja testi ohjelmia ja katselmointia. Kyseiset testimenetelmät kuuluvat ns. black- ja white box testausmenetelmiin. Testaus tapahtuu ko. suunnitteludokumentteja vasten.

Integraatiotestauksessa testataan moduulien välistä toimintaa. Fokus on tällöin keskittynyt moduulien rajapintoihin ja niiden yhteistyöhön. Käytettävät työkalut ovat samat kuin moduulitestauksessa. Testaus tapahtuu ko. suunnitteludokumentteja vasten.

Järjestelmätestauksessa testataan koko tuotteen toimivuutta. Testaus tehdään vaatimus- ja toiminnalisuusmäärittely dokumentteja vastaan.

5.2 Käytettävät menetelmät

Black box testauksessa testaus tehdään ohjelman tunnettujen toimintojen mukaan ilman että ohjelman sisäisestä toiminnasta tiedetään. Kyseessä on siis eräänlainen I/O testaus, tuleeko tietyllä syötteellä tietty vastaus.

White box testauksessa testaajat tietävät ohjelman sisäisen toiminnan ja pyrkivät joko katselmoinnin avulla tai käyttäen jotain soveltuvaa ohjelmistoa käymään läpi ohjelman toiminnan. Tämän projektin parissa pyritään käyttämään white box testausta ainoastaan katselmointien muodossa.

Katselmointi - katselmoinnissa kokenut ohjelmoija käy läpi seuraavia asioita ko. moduulin osalta:

1. Standardi katselmointi - tarkistetaan että koodi on kirjoitettu javakoodausstandardin [OSPREY-CODECONV] mukaisesti. Tarkistetaan koodin yleinen luettavuus. Tarkistetaan että java dokumentit ovat asiallisia ja niiden perusteella voidaan ymmärtää luokan/moduulin toimita.
2. Suunnittelu katselmointi - luetaan läpi ja tarkistetaan että suunnitteludokumentit vastaavat moduulin toteutusta.
3. Toteutus katselmointi - luetaan huollella läpi koodi ja keskitytään siihen kuinka koodi on toteutettu keskittyen mm. seuraaviin asioihin:
   • Virhetilanteet ja poikkeustapaukset - kuinka johdonmukaisesti näitä käsitellään, riittävyys
   • Uudelleenkäytettävyys - kuinka muokattavissa moduuli on, yleiskäyttöisyys.
   • Tehokkuus - kuinka 'optimaalisesti' koodia on tuotettu ja miten moduuli täyttää suorituskyvylle asetetut vaatimukset.

5.3 Virheiden käsittely

Testauksen tarkoituksena on järjestelmällisesti etsiä virheet ohjelmistosta. Virheiden etsimisessä ja korjaamisessa menetellään seuraavasti:

1. Testitapaus tehdään ko. dokumenttia vasten
2. Testitapaus suoritetaan
3. Testausraportti tehdään testitapauksesta
4. Jos testitapaus oli virheellinen, virhe luokitellaan ja korjausaikataulu määritetään
5. Testitapaus ajetaan uudelleen, sekä kaikki tästä ominaisuudesta riippuvat testitapaukset ajetaan uudelleen

5.4 Testauskäytäntö

Testauksessa noudatetaan seuraavaa käytäntöä:

• Testaaja lukee testiskenaarion läpi
• Testaaja alustaa skenaarion testitapauksen kuten ko. skenaarion alustusohjeissa on ilmoitettu.
• Testaaja suorittaa testitapauksen.
• Testaaja kirjaa testin suoritetuksi, päivämäärän ja testauksen epäonnistuessa kirjataan poikkeamat testitapauksen ohjeistoon verrattuna
• Testaaja jatkaa seuraavaan testitapaukseen

5.5 Aikataulu

T2		T3		T4		LU
		Moduulitestaus
			Integraatiotestaus
				Järjestelmätestaus
						Hyväksymistestaus

Kaikki testausvaiheet alkavat heti kun on jotain mitä testata. Moduulitestaus alkaa kun ensimmäiset moduulit ovat valmiita. Integraatiotestaus alkaa kun ensimmäiset moduulit voidaan yhdistää. Järjestelmätestaus alkaa kun riittävästi moduuleita on saatu integroitua jotta testattavaa on.

5.6 Testauksen tulosaineisto

Testauksesta syntyvät dokumentit ovat tämä dokumentti, testitapaukset, tapauskohtaiset raportit ja yhteenveto.

5.7 Hyväksyminen

Testaus katsotaan hyväksytysti kun:

• kaikki testitapaukset ovat menneet läpi hyväksytysti
• virheelliset tapaukset ovat luokiteltu ominaisuuksiksi

6. Testauksen keskeyttäminen

Testaus keskeytetään kun 50% testitapauksista ei pystytä suorittamaan taikka kun 30% testitapauksista ei voida alustaa.

Päätöksen testauksen keskeyttämisestä tekee testaaja yhdessä testausvastaavan kanssa.

Keskeytyspäätöksestä on välittömästi ilmoitettava projektiryhmälle ja -päällikölle.

Testausta jatketaan kun seuraava versio on saatu tuotekehityksestä testattavaksi jolloin kaikki testitapaukset tulee käydä uudelleen läpi.

7. Riskit

Testaukselle suurimman riskin tuottaa tiukka aikataulu. Projektille ei ole varattu suurta testausbudjettia ja lisäksi asiakas on valmis tinkimään testauksesta dokumentaation kattavuuden vuoksi. Jos ko. riski toteutuu joudutaan testaus lopettamaan ja virheelliset ominaisuudet luokittelemaan ominaisuuksiksi. Tämä sen vuoksi että tämän kurssin työaika loppuu.

Toinen riski on arkkitehtuurin testaus. Koska arkkitehtuurin muodostaa joukko dokumentaatiota on olemassa riski että kaikkea ei saada dokumentoitua riittävän kattavasti. Ehkäistäksemme tämän riskin toteutumista käytämme kaikki dokumentaatiomme asiakkaalla kommentoitavana ja lopullisen dokumentaation hyväksynnän teemme yhdessä asiakkaan kanssa.

8. Testattavat ominaisuudet

Arkkitehtuurin testaus on dokumenttien kattavuuden arvionti yhdessä asiakkaan kanssa.

Arviointikriiteerit ovat seuraavat:

1. Käyttötapaukset ovat dokumentoitu
2. Keskeisimmät suunnittelupäätökset ja -kriteerit ovat dokumentoitu
3. Tekninen dokumentaatio vastaa vaatimus- ja toimminnallismäärittelyjä

Demosovelluksen testattavat ominaisuudet ovat liitteenä testitapaus dokumentissa. [OSPREY-TESTITAPAUKSET]