T Testaussuunnitelma

Transkriptio

1 T Testaussuunnitelma 5. joulukuuta 2001 Confuse 1

2 Tila Versio: 1.0 Tila: Sisäisesti katselmoitu Jakelu: Julkinen Luotu: Antti Haapakoski Muutettu viimeksi: Jani Myyry Versiohistoria Versio Pvm Tekijä Kuvaus Haapakoski Antti Dokumenttipohja Jani Myyry Ensimmäinen versio Jani Myyry Lisätty testattava kohde, menetelmät, testiympäristö Jani Myyry Lisätty riskienhallinta, vastuut, kriteerit Jani Myyry Korjattu katselmoinnin pohjalta virheitä, lisätty testi- ja virheprioriteetit Jani Myyry Sisäisesti katselmoitu versio. 2

3 Sisältö 1 Johdanto Tarkoitus ja kattavuus Määritelmät, termit ja lyhenteet Viitteet Yleiskatsaus dokumenttiin Testattava järjestelmä Testauksen kohde Testattavat ominaisuudet Ominaisuudet joita ei testata Testausprosessi Menetelmät testaukseen Moduulitestaus Integrointitestaus Järjestelmätestaus Hyväksymystestaus Vaadittava tulosaineisto Aikataulu ja työmäärät Testitapaukset 9 5 Kriteerit testaukselle Järjestelmätestauksen hyväksymiskriteerit Järjestelmätestauksen hylkäämiskriteerit Järjestelmätestauksen päättämiskriteerit Testauksen aloittamiskriteerit Testauksen keskeyttämiskriteerit Testauksen jatkamiskriteerit Testausympäristö ja henkilöstö Testausympäristö Vaatimukset testausympäristölle Laitteisto Ohjelmistot Turvallisuus Työkalut Henkilöstö Henkilöstön tarve Testihenkilöstö Koulutus Vastuualueet Integrointitestausryhmä Järjestelmätestausryhmä Hyväksymistestausryhmä Riskienhallinta 13 8 Liitteet ja viittaukset 13 3

4 1 Johdanto 1.1 Tarkoitus ja kattavuus Tämä dokumentti on kurssin T Tietojenkäsittelyopin ohjelmatyö-kurssia suorittavan ryhmän Confuse testaussuunnitelma. Ryhmän tarkoituksena on kehittää konfigurointiympäristö mobiilipäätelaitteille, hyödyntäen projektissa Compaq ipaq PDA-laitetta. Konfigurointiympäristön tarkemmat yksityiskohdat löytyvät vaatimusmäärittelystä ja toiminnallisesta määrittelystä. Tämän dokumentin tarkoituksena on esitellä yleiset periaatteet testaukselle, käyttäen hyödyksi USDP-prosessin tapaa iteratiivisesti laajentaa testattavaa kokonaisuutta. Koska konfigurointiympäristö on jo valmiiksi luonteeltaan modulaarinen, toteutetaan testaus osissa aloittaen yksittäisistä osista laajeten konfiguraattorikokonaisuuteen. Integrointi- ja järjestelmätestaus suoritetaan T2- ja T3-vaiheissa, eikä siihen vielä oteta kantaa. 1.2 Määritelmät, termit ja lyhenteet BLUETOOTH Bootloader Burana CCCC CF-card configuration configurator deb Debian GNU/Linux Delphi method Ethernet Ethernet frame Familiar Linux firewall Flash Gb GB GPRS HUT IP ipaq ipkg A Technology that implements small range radio link between computers, celluler phones, PDAs etc. Teknologia joka toteuttaa radioyhteyden tietokoneiden, matkapuhelimien, taskutietokoneiden yms. välille lyhyillä matkoilla. Program that boots computer. Tietokoneen käynnistävä ohjelma. Bug Report And Nag Application. Bugiraportointi ja versionhallintajärjestelmä. C and C++ Code Counter, A free software tool for measurement of source code related metrics by Tim Littlefair. Ilmainen koodirivien laskentaohjelma. Compact Flash Card, Memory card for handhelds, mp3 players and digital cameras. Muistikortti kämmentietokoneille, mp3 soittimille ja digitaalikameroille A set of components or packages forming a system. In this context a list of packages to be installed in the PDA. Systeemin muodostava joukko komponentteja tai paketteja. Tässä yhteydessä lista paketeista, jotka asennetaan PDA:han. A program that helps the user to make a valid configuration and possibly use that configuration. Ohjelma, joka helpottaa kelvollisen konfiguraation luomisessa. extension for Debian Linux packages. Debian Linuxin pakettien tarkenne. Free UNIX like operating system. Vapaa UNIX-tyyppinen käyttöjärjestelmä. A method for combining several estimations. Menetelmä useiden arvioiden yhdistämiseksi. Typical method of implementation for local LANs. Tyypillinen paikallisverkon toteutustapa. Packet that is directed trough ethernet network. This packet can carry for example IP packets. Ethernet-verkossa kuljetettava paketti. Tämä paketti voi kuljettaa esim. IP paketteja. Linux distribution for handheld computers using StrongArm 110 Processor. Kämmentietokoneelle tarkoitettu Linux-jakelu. Limits accessibility between local and public network. Rajoittaa liikennettä paikallisen ja julkisen verkon välillä. Non-volatile Random Access Memory. Haihtumaton luku ja kirjoitusoperaatiot salliva muisti. Gigabit. Gigabitti Gigatavu. Gigatavu General Packet Radio System. A new nonvoice value added service that allows information to be sent and received across a mobile telephone network. Uusi palvelu datan siirtoon matkapuhelinverkossa. See TKK. Internet Protocol. A connectionless network level protocol layer of the TCP/IP. Yhteydetön TCP/IP:n verkkokerros. A handheld pen operated computer by Compaq. Compaqin tekemä kynäohjattu taskutietokone. Itsy Package Management System. A lightweight configuration system for Familiar Linux. Kevyt konfiguraationhallintasysteemi Familiar Linuxille. 4

5 ISO 8601 International Standard for numeric representations of date and time. Kansainvälinen standardi päiväyksen esittämiseen numeerisessa muodossa. LAN Local Area Network, infrastructure of physical connections between computers. Allows data transfers. Tiedonsiirron mahdollistava infrastruktuuri tietokoneiden välillä. lparse Front end for smodels. Esiprosessori smodelssiin. Mb Megabit. Megabitti. MB Megabyte. Megatavu. NFS Network File System, Filesystem that allows the use of remote harddisks. Tiedostojärjestelmä joka sallii kovalevyjen etäkäytön. package One component of a configuration. Package can be for example a file containing some program or library. Konfiguraation osa, joka voi sisältää esim. ohjelman tai kirjaston. PC Personal Computer, a desktop computer with x86 compatible processor. Tavallinen x86- yhteensopiva pöytäkone. PC-Card See PCMCIA. PCMCIA Personal Computer Memory Card International Association, An accessory bus used in laptops and handhelds. Salkku- ja kämmenmikrojen yleinen oheislaiteliitäntä. PDA Personal Digital Assistant, A mobile, handheld computer with software like calendar, contacts, calculator and more. Kannettava tietokone, jossa on ohjelmia kuten kalenteri, yhteystiedot, laskin yms. porting Modifying the code to work in some other environment. Porttaaminen, koodin muokkaaminen toisessa ympäristössä toimivaksi. PPP Point to Point Protocol, Protocol for serial lines. Protokolla sarjayhteyksille. Processor An integrated chip that makes arithmetic and memory operations. Integroitu piiri, joka suorittaa aritmeettisia- ja muistioperaatioita. RAM Random Access Memory, usually volatile. Luku- ja kirjoitusoperaatiot salliva muisti, ei pysyvä. RL Rule based Language. A language for representing configuration knowledge. Kieli konfiguraatiotiedon esittämiseen. ROM Read Only Memory. Vain luettavissa oleva muisti. RPM Extension for RedHat Linux packages. RedHat Linuxin pakettien tarkenne. SoberIT Software Business and Engineering Institute (in HUT). Ohjelmistoliiketoiminnan ja - tuotannon instituutti (TKK:lla). SSH Secure Shell, Secure replacement for Telnet. Turvallinen Telnetin korvike. SCP Secure CoPy, Secure replacement for FTP. Turvallinen FTPn korvike. SSHD Secure Shell Daemon, SSH Server. SSH-palvelin. smodels An implementation of the stable model semantics for logic programs. Logiikkaohjelmatulkki joka etsii syötteelle vakaan mallin. TCP/IP Transmission Control Protocol, a connection-oriented internet protocol. Yhteydellinen internetprotokolla. Tirana Work raporting system. Tuntiraportointijärjestelmä. TKK Helsinki University of Technology, Teknillinen Korkeakoulu. UMTS Universal Mobile Telecommunications System, Third-generation (3G) mobile communications system. Kolmannen sukupolven matkapuhelinjärjestelmä. USB Universal Serial Bus, Serial interface that is used in computers and accessories. Sarjaväylä jota käytetään tietokoneissa ja oheislaitteissa. USDP Unified Software Development Process, Generic context for a software project. Ohjelmistoprosessin yleinen viitekehys. UML Unified Modeling Language, a standard for visualization and specification of a software system. Standardi ohjelmiston visualisointiin ja määrittelyyn. ViCa Visualization Client Application. Visualisointi ohjelma. WinCE Windows CE, Microsoft s operating system for handhelds. Microsoftin käyttöjärjestelmä käsimikroille. Wireless Ethernet b Wireless Ethernet, See WLAN. WLAN Wireless Local Area Network. Computer network that uses radio waves to transmit data. Langaton verkko tietokoneiden välillä. 5

6 XML xmodem X environment Extensible Markup Language. A markup language for documents containing structured information. Kieli rakenteisten dokumenttien kirjoittamiseen. A file transfer protocol for serial connections. Tiedostonsiirtoprotokolla sarjayhteyksille. Graphical window system for UNIX. Graafinen ikkunajärjestelmä UNIXille. 1.3 Viitteet Viitteet ovat listattuina dokumentin lopussa. 1.4 Yleiskatsaus dokumenttiin Dokumentin ensimmäinen kappale antaa yleiskuvan käsiteltävästä aiheesta ja määrittelee termit joita dokumentissa käytetään. 2. kappale määrittelee testattavan kohteen, ominaisuudet sekä rajaa pois ominaisuudet, joita ei testata. 3. kappale määrittelee menetelmät, joita käytetään testauksessa. Lisäksi määritellään rakenne testiraporteille sekä aikataulutus koko testausprosessille. 4. kappale sisältää testitapaukset. 5. kappale määrittelee hyväksymis- ja hylkäämiskriteerit testeille, sekä kriteerit testien keskeyttämiseen, jatkamiseen ja hylkäämiseen. 6. kappale määrittelee testausympäristön sekä henkilöstöön liittyviä vastuu- ja koulutuskysymyksiä. 7. kappale sisältä riskianalyysin liittyen testausprosessiin. Lopussa ovat viittaukset ja mahdolliset liitteet. 2 Testattava järjestelmä 2.1 Testauksen kohde Testauksen kohteena on asennuspakettien konfigurointijärjestelmä Familiar Linux:lle käyttäen hyödyksi projektin ulkopuolella Debian GNU/Linux-ympäristöön kehitettyä logiikkakonetta tarkistamaan valitun konfiguraation laillisuus. Paketteina käytetään valmiita ipkg-paketteja, jotka tulevat Familiar Linux-jakelun mukana. Järjestelmässä on useita itsenäisiä osia, jotka kommunikoivat toistensa kanssa rajapintojen kautta. Pääasiallisin rajapinta on komentorivi, johtuen muunmuuassa logiikkakoneen asettamista rajoituksista. Tiedon ja käyttäjän valitsemien pakettien tilatietojen tallentamiseen käytetään XML-tiedostoja. Lisätietoja löytyy toiminnallisesta määrittelystä. 2.2 Testattavat ominaisuudet Testauksen tarkoituksena on varmistaa, että testattava järjestelmä pystyy jollain käyttäjän valinnalla löytämään laillisen konfiguraation ja asentamaan valitut paketit ipaq:iin. Vaatimusmäärittelyssä on ryhmitelty vaatimukset tärkeysluokkiin, jotka määrittelevät järjestyksen testattaville ominaisuuksille. Toisaalta modulaarinen rakenne ja käytettävät menetelmät ohjaavat testausta prosessin aikana. Testitapahtumat moduulitestaukseen rakennetaan vaiheessa T2. Moduleita, joita tämä koskee ovat Mapper, joka rakentaa pakettilistaukset, GUI, jolla käyttäjä valitsee haluamansa paketit ja Installer, joka huolehtii pakettien asennuksesta ipaq:iin. Moduulitestauksen jälkeen komponenttien yhteistoimintaa testataan integrointi- ja järjestelmätestauksessa vaiheessa T3 yhdessä ulkopuolisen komponentin: logiikkakoneen kanssa. 2.3 Ominaisuudet joita ei testata Testejä ei suoriteta ulkopuolisille komponenteille muuten kuin toteamalla yksinkertaisella syötteellä että ne toimivat kyseisellä syötteellä. Mahdolliset ulkopuolisten komponenttien aiheuttamat virheet eivät kuulu ryhmän vastuulle, riittää että on olemassa jokin syöte, jolla järjestelmän toiminnallisuus voidaan todeta. Käyttöliittymän käytettävyyttä ei testata, koska vaatimusmäärittelyn mukaan riittää että pakettien valitseminen onnistuu. Mitään ryhmittelyä tai muuta käyttöä mahdollisesti helpottavaa ei vaadita, mutta jos sellainen implementoidaan, voidaan käytettävyyteen ajan salliessa käyttää voimavaroja. 6

7 3 Testausprosessi 3.1 Menetelmät testaukseen Testaus aloitetaan moduulien testauksesta, jatkaen USDP-prosessin mukaisesti iteratiivisesti kohti järjestelmätestausta, joka suoritetaan T2- ja T3-vaiheissa. Testausmenetelmänä on V-malli, jossa onnistuneiden moduulitestien jälkeen siirrytään ensin integrointitestaukseen. Integrointitestausvaiheessa testataan moduulien yhteistoimintaa ajamalla syötteitä läpi usean moduulin läpi ja toteamalla palautteesta testien onnistuminen tai epäonnistuminen. Viimeiseksi toteutetaan järjestelmätestaus, jolla pyritään varmistamaan konfigurointiympäristön toimiminen oikeilla käyttäjillä ja tuotantoympäristössä. Vaatimusten määrittely Hyväksymistestaus Vaatimusten analyysi Järjestelmätestaus Arkkitehtuurin suunnittelu Integrointitestaus Moduulien suunnittelu Moduulitestaus Koodaaminen Kuva 1: V-malli ohjelmistojen testausta varten Konfigurointiympäristön arkkitehtuurin vuoksi moduulien pääasiallisina testeinä käytetään black-box-tyyppisiä syöte-vastine ajoja. Moduuleille syötetään sekä rakenteellisesti oikeita syötteitä että myös vääriä, joilla voidaan varmistaa moduulien käyttäytyminen virhetilanteissa. Integrointitestausvaiheessa moduulien ajoja yhdistetään ja pyritään valmiilla syötteillä asentamaan paketteja ipaq:iin. Testitapaukset määritellään tarkemmin moduulitestausvaiheen testien pohjalta, eikä vielä oteta kantaa. Järjestelmätestausvaiheessa myös GUI:ta käyttäen suoritetaan ajoja tunnetusti toimivilla että myös oikeiden käyttäjien vapaavalintaisesti tekemillä valinnoilla. Tähän ei vielä oteta sen tarkemmin kantaa. Ennen luovutusta suoritetaan hyväksymistestaus. 3.2 Moduulitestaus Moduulitestaus suoritetaan ohjelmointiprosessin aikana, ohjelmoijan ja määritetyn testaajan voimin. Määritetyn testaajan osuus keskittyy moduulin ohjelmoimisen loppupuolelle, kun järkeviä black-box-testejä voidaan suorittaa. Moduulit ovat testeissä itsenäisiä komponentteja, eikä testausta muiden muiden moduulien kanssa suoriteta tässä vaiheessa. Testit suoritetaan heti ohjelmoimisen jälkeen ja testit täytyy olla suoritettuina ennen moduulin integroimista järjestelmään. Moduulitestaus suoritetaan pääasiassa syöte vastine-ajoilla, mutta varsinaisia testicasejä ei tuoteta. Syötteinä käytetään sekä tunnetusti hyväksyttäviä syötteitä, että syötteitä, joiden pitää tuottaa virheilmoitus. Moduulitestauksen tarkoituksena on testata koko moduulin toimintaa ja kaikki moduulin toiminnot pyritään kattamaan jollain testillä vähintään kerran. Kaikista moduulitesteistä ei tuoteta testiraporttia, mutta ennen siirtymistä integrointivaiheeseen tulee raportti olla tehty. 3.3 Integrointitestaus Integrointitestaus suoritetaan, kun integroitavien komponenttien moduulitestaus on hyväksytysti suoritettu. Integrointitestaus voidaan aloittaa myös vaiheittain, testaamalla komponetteja, jotka ovat valmiita, ennen kuin kaikki valmistuvat. Testit suoritetaan syöte-vastine-ajoilla, yhdistämällä moduulitestauksessa luotuja ajoja. 7

8 3.4 Järjestelmätestaus Järjestelmätestaus suoritetaan onnistuneiden integrointitestausten jälkeen. Järjestelmätestaus suoritetaan aikaisintaan T2-vaiheessa. Järjestelmätestauksen testitapaukset ja yksityiskohdat tarkentuvat myöhemmin. 3.5 Hyväksymystestaus Hyväksymistestaus suoritetaan T3-vaiheen lopulla tai LU-vaiheen alussa. Asiakas voi ottaa osaa testaukseen. 3.6 Vaadittava tulosaineisto Testaus suoritetaan pääasiassa erilaisilla syötteillä moduleille ja tutkimalla syötteen aiheuttamaa palautetta. Testauksessa raportoidaan syötteet, saadun palautteen erot oikeaksi määriteltyyn palautteeseen. Testien vaiheet (komennot) kirjataan testiraporttiin niin kuin ne moduleille syötetään. Samoja testejä ajetaan tietyin väliajoin (muutosten jälkeen), varmistaen että modulin toiminnallisuus säilyy oikeana ohjelmointiprosessin aikana. Testit pyritään automatisoimaan, jotta testin suorittaminen olisi mahdollisimman helppoa. Moduuli-testeistä kirjataan ylös testiraporttiin: aika Testin ajankohta ISO 8601-merkinnällä [1]. modulien nimet Mihin komponentteihin testaus liittyy. modulien versiot Jos modulista on tehty release, niin sen versio, muuten esim. CVS-revisio. kuvaus syöte Kuvaus juuri tehtävästä testistä, työkaluista. Tiedostot (tiedot) syötteestä. palaute Modulin palaute kokonaisena. kommentit bugit Kommentit testien suorittajilta. Kommentit bugeista, onko tehty bugiraportti Buranaan. Testeissä vastaan tulleet virheet kirjataan bugien raportointijärjestelmä Buranaan. Testiraportti on LATEX2e-muodossa. 3.7 Aikataulu ja työmäärät Testauksen aikataulu projektin kuluessa on määritelty projektisuunnitelmassa. Taulukossa 1 on vaiheittain eriteltynä testaukseen allokoidut tunnit mukaanlukien testaussuunnitelma. 8

9 Henkilö T1 T2 T3 LU Testivastaava Myyry Jani Haapaniemi Ari Haapakoski Antti Kujala Petri Martsola Mikko Vainionpää Jussi Yhteensä Testitapaukset Taulukko 1: Allokoidut tunnit testaukselle, sisältää testaussuunnitelman Testitapaukset rakennetaan aikaisintaan moduulitestausvaiheen lopulla, vaiheessa T2. Testitapauksissa käytetään prioriteetteinä sekä vaatimusmäärittelyn Must, Nice To Have, Useful-tasoja, että testitapauksille määritettyjä tärkeystasoja taulukossa 2. Tasojen avulla testitapaukset voidaan järjestää ja määrittää olennaiseksi, jotka täytyy läpäistä, ennen kuin testaus on hyväksytysti suoritettu. Lisää testauksen kriteereistä kappaleessa 5. Testiprioriteetti Kuvaus Kohteet High Määrittelee testitapaukset, jotka täytyy läpäistä, jotta kokonaistestaus onnistuu. Muuten testaus epäonnistuu. Medium Määrittelee testitapaukset, joista täytyy osa läpäistä kriteerien määritysten mukaan, jotta kokonaistestaus onnistuu. Muuten testaus epäonnistuu. Low Määrittelee testitapaukset, joiden läpäisy ei vaikuta kokonaistestauksen onnistumiseen. Taulukko 2: Prioriteetit testitapauksille Virhetilanteille on omat vakavuusasteensa, taulukossa 3. Kriittiset osat, joita ilman kohde ei toimi eikä täytä tehtäväänsä. Tärkeät osat, joita ilman kohde toimii vaillinaisesti tai joissain tilanteissa virheellisesti. Osat, jotka eivät ole kokonaistoiminnan kannalta kriittisiä ja tuovat mahdollisesti lisäarvoa. Virheprioriteetti Kuvaus Toimenpiteet Fatal Virheet, jotka estävät kohteen toimimisen millään arvoilla. Virheet täytyy korjata, ennen kuin testejä voidaan jatkaa. Testejä ei voi läpäistä, niin kauan kuin tason virheitä on korjaamatta. Raportoidaan Broken Feature Kohde toimii, mutta tuottaa vääriä tuloksia. Kohde tuottaa jollain arvoilla vääriä tai epämääräisiä lopputuloksia. Taulukko 3: Prioriteetit bugeille aina. Voidaan jatkaa testausta, mutta testitapausta ei ole läpäisty ennen kuin virhe on korjattu. Raportoidaan, jos pikaista korjausta ei löydy. Testausta voidaan jatkaa normaalisti ja testaus voidaan läpäistä. Virheet korjataan, jos aikataulu sallii. Ei ole pakollista raportoida. 9

10 5 Kriteerit testaukselle 5.1 Järjestelmätestauksen hyväksymiskriteerit Järjestelmätestaus konfigurointiympäristölle on hyväksytysti suoritettu, kun seuraavat vaatimukset on toteutettu järjestelmätestauksen aikarajaan mennessä. Kaikki testitapaukset, jotka testaavat ominaisuuksia määriteltynä tasolle Must vaatimusmäärittelyssä, täytyy olla hyväksytysti läpäisty. Kaikki testitapaukset, jotka testaavat ominaisuuksia määriteltynä tasolle Useful vaatimusmäärittelyssä, testiprioriteetille High ja jotka on toteutettu, täytyy olla hyväksytysti läpäisty. Kaikki testitapaukset, jotka on määritetty testiprioriteetille High, täytyy olla hyväksytysti läpäisty. Testitapauksista testiprioriteetilla Medium täytyy olla 50% läpäisty. Kaikki testitapaukset on ohjeiden mukaan dokumentoitu. Kriteerejä tarkennetaan tarvittaessa, kun projekti etenee lähemmäksi järjestelmätestausvaihetta. 5.2 Järjestelmätestauksen hylkäämiskriteerit Järjestelmätestaus hylätään, jos jokin edellämainituista hyväksymiskriteereistä ei toteudu. 5.3 Järjestelmätestauksen päättämiskriteerit Järjestelmätestaus päättyy, kun jokin seuraavista täyttyy: Järjestelmätestauksen hyväksymiskriteerit on täytetty testaukselle määritetyn ajan sisällä. Järjestelmätestaukselle varattu aika loppuu ja lisäaikaa ei hyväksytä. Projektille varattu aika loppuu. Projekti keskeytetään. 5.4 Testauksen aloittamiskriteerit Järjestelmän testaus voidaan aloittaa, kun testiympäristö on luotu testausta varten. Testiympäristö luodaan hakemalla testattava revisio CVS:stä ja tallettamalla se omaan hakemistoon käyttäen hyödyksi versiointia. Symbooliset linkit käännetään osoittamaan kyseiseen hakemistoon, jolloin olemassa olevalla konfiguraatiolla esimerkiksi WWW-palvelin osaa hyödyntää testattavaa versiota. Tarvittaessa paluu entiseen ympäristöön onnistuu kääntämällä symbooliset linkit osoittamaan takaisin edelliseen version. 5.5 Testauksen keskeyttämiskriteerit Testaus keskeytetään, jos testiajo keskeytyy virheeseen jollain testitapaukseen kuuluvista syötteistä. Testaaminen voidaan keskeyttää minkä tahansa testin jälkeen, koska ympäristö on modulaarinen ja erillisä tiloja ei ole, joita pitäisi palauttaa. Ulkopuolisten komponenttien virheet eivät keskeytä testaamista. Jos virhe sattuu, kirjataan syöte epäonnistuneeksi ja jatketaan testin muilla syötteillä. 5.6 Testauksen jatkamiskriteerit Testauksen keskeydyttyä virheeseen, joka estää ajon suorituksen loppuun saakka, jatketaan kun virhe on korjattu. Mitään muita ajoja ei jatketa, kunnes virhe on korjattu, paitsi virheen korjaukseen liittyviä testiajoja voidaan suorittaa. Testauksen jatkamisesta päättävät yhdessä testien suorittaja ja kohteen ohjelmoija. Jos virhe johtuu ulkopuolisesta komponentista, voidaan testausta jatkaa toimivammaksi muutetuilla syötteillä. 10

11 6 Testausympäristö ja henkilöstö 6.1 Testausympäristö Vaatimukset testausympäristölle Konfigurointiympäristön ulkopuoleiset komponentit asettavat rajoituksensa käytettävälle ympäristölle, joten testaus suoritetaan pääasiassa ryhmän käyttöön annetussa työasemassa, jossa käyttöjärjestelmänä on Redhat Linux 7.1. Muita mahdollisia ympäristöjä ovat muut Linux-variantit, ensisijaisesti Debian/GNU Linux. Muita unixeja ei tueta, koska ulkopuolisen komponentin toimivuudesta niissä ei ole takuuta. Ryhmän käytössä Compaq ipaq PDA, jossa on Familiar Linux 0.5, jolle vaihtoehtoista ympäristöä ei ole olemassa, joten sitä käytetään testaukseen. ipaq on kiinni työasemassa jollain verkkoyhteydellä. Konfigurointiympäristön osien testaaminen installaatio-osuutta lukuunottamatta voidaan tehdä työasemassa, installaatiosuuden testaamiseen tarvitaan sekä työasema että ipaq. Konfiguraattorin suorituskyvylle ei ole asetettu tiukkoja määrityksiä, suorituskyky riippuu osittain ulkopuolisen komponentin suorituskyvystä, jonka pitäisi toimia testattavilla pakettimäärillä muutamassa sekunnissa. Suorituskyky on riittävä, jos ryhmän käytössä olevassa työasemassa voidaan konfigurointi suorittaa ilman suurempia kuin 10 sekunnin taukoja konfiguroinnin aikana, poislukien pakettien asennus, joka voi kestää kauemminkin Laitteisto Konfiguraatioympäristössä käytettävät laitteistot: Laitteisto Käyttöjärjestelmä Versio PC Redhat Linux 7.1 Compaq ipaq Familiar Linux 0.5 (pre-release) Taulukko 4: Testiympäristön laitteistot Ohjelmistot Palvelinlaitteistossa (PC) on asennettuna ohjelmistot käyttöliittymää (GUI) varten. Käyttöliittymänä toimii wwwselain, palvelinohjelmiston muodostavat Apachen kanssa pyörivä JSP-palvelualusta: Jakartan Tomcat. Tomcat tarvitsee alustakseen toimivan Java 2 Stardard Edition ja Java 2 Enterprise Edition asennuksen. WWW-palvelin ohjelmistona toimii siis Apache, jossa mod_ssl-modulina on tuki SSL-salatuille yhteyksille. Käyttöliittymän alustana olevat ohjelmat: Ohjelmisto Versio Tarvitsee Tarkoitus Apache+mod_ssl (mod_ssl 2.8.5) WWW-palvelin Java Stardard Edition 1.3.1_01 Java-ympäristö Java Enterprise Edition 1.3.1_01 Java Standard Edition Laajennettu Javaympäristö Jakarta Tomcat Apache, Java 2 Standard JSP-palvelualusta Edition, Java 2 Enterprise Edition Taulukko 5: Palvelinohjelmistot käyttäliittymää varten Testien tulosten kirjaamiseen käytetään vapaavalintaista editoria, jonka Linux tarjoaa. Testaus-ajojen mittaukseen voidaan käyttää käyttöjärjestelmästä vakiona löytyviä työkaluja, sekä scripti-kieliä, joiden päälle automatisoidut testit on tehty, kuten Perl. Testiraportit voidaan tehdä ympäristössä, jossa on LATEX2e asennettuna, myös muualla kuin testilaitteistossa. Yhteyden ottamiseen käytetään SSH:ta, jolla testien suorittaminen onnistuu myös etäajoina. Ulkopuolisista komponenteista täytyy olla asennettuna sekä Lparse [2] että Smodels [3], jotka toimivat logiikkakoneistona konfiguraattorille. 11

12 6.1.4 Turvallisuus Konfiguraattorijärjestelmä voidaan suojata muusta käyttöjärjestelmästä rajoittamalla oikeuksia niin, että siitä ei ole haittaa työaseman toimivuudelle ja turvallisuudelle. ipaq:n mahdollinen olemassa oleva sisältö saadaan dumpattua talteen kovalevylle, josta sen palauttaminen tarvittaessa onnistuu. Asennusvaiheessa ipaq:n kannalta kriittisin vaihe on bootloaderin asennus, jonka epäonnistuessa laitteen toimintaan saattaminen vaatii huoltokäynnin. Bootloader tarvitsee asentaa vaan kertaalleen, joten riski epäonnistumiseen on suhteellisen pieni. Epäonnistunut Familiar-asennus voidaan korvata bootloaderin avulla uudella. Testausta varten konfigurointi-tiedostojen paikat voidaan rajata esimerkiksi omaan testihakemistoon, jolloin järjestelmän tila ei muutu ajojen välissä. Käytännössä kaikki järjestelmän tilaa kuvaavat tiedot ovat teksti-tiedostoissa, jotka on XML tai muussa luettavassa formaatissa. Testihakemistoon rajaaminen voidaan suorittaa käyttöjärjestelmän tarjomain keinoin, esimerkiksi symboolisilla linkeillä ja versioinnilla Työkalut Konfigurointiympäristö rakennetaan Linux-käyttöjärjestelmän päälle, joten testaus tapahtuu myös sen päällä, lukuunottamatta käyttöliittymää, jota voidaan testata myös muualla. Testityökaluina on käyttöjärjestelmän tarjoamia työkaluja, joiden avulla testit pääasiassa suoritetaan. Seuraavassa taulukossa on listattu ohjelmia, joita käytetään. Ohjelma Versio Kuvaus Käytetään Perl tulkattava scriptikieli automatisoimaan testiajoa ja testaamaan palautteita ohjeellisiin time mittaa prosessin suoritusajan mitataan komponettien suoritusaikaa, viiveitä käyttäjälle LATEX2e (TEX) tekstin ladontaohjelmisto muotoilemaan testiraporttien ulkoasua Netscape 4.77 WWW-selain testataan käyttöliittymän toiminnallisuutta Internet Explorer 5.50 WWW-selain testataan käyttöliittymän toiminnallisuutta Taulukko 6: Testaukseen käytettävät ohjelmistot 6.2 Henkilöstö Henkilöstön tarve Testaus suoritetaan pääasissa ryhmän sisäisenä, joten koulutustarvetta ei ole. Projektisuunnitelmassa on varattu henkilöresursseja sekä moduuli-, integrointi- että järjestelmätestaukseen Testihenkilöstö Järjestelmän testauksesta vastaa testivastaava Jani Myyry, joka kontrolloi yleistä kokonaisuutta sekä kirjoittaa testisuunnitelman. Komponenttien testausta ei pääasiassa toteuta komponentin ohjelmoija, mutta kuitenkin henkilö, jolla on läheistä tietoa komponentin toiminnasta. Komponentti Ohjelmoija Testaaja Mapper Antti Haapakoski Jani Myyry GUI Ari Haapaniemi Petri Kujala Installer Mikko Martsola Jussi Vainionpää Taulukko 7: Moduulitestauksesta vastaavat 12

13 6.2.3 Koulutus Testaus toteutetaan pääasiassa ryhmän sisäisin resurssein, joten erillistä koulutusta ei järjestetä. Moduulivaiheen ja integrointivaiheen testauksessa tarvittavaa tukea antavat osien ohjelmoijat. Järjestelmätestauksessa jarjestelmäarkkitehdit toimivat tarvittaessa tukena testaukselle, tarvittaessa myös ohjelmoijat. Jos ulkopuolisia testaajia käytetään myöhemmissä vaiheissa, päätetään koulutuksen tarve erikseen. 6.3 Vastuualueet Testauksen suunnittelee, koordinoi ja valmistelee testausvastaava Jani Myyry, eri moduulien testaustavoista päätetään yhdessä testausvastaavan ja moduulien ohjelmoijien kesken. Testien seuranta järjestetään yhdessä projektin muun seurannan kanssa mukaanlukien dokumenttien katselmointi, joita testien yhteydessä syntyy Integrointitestausryhmä Integrointitestauksesta vastaa testausvastaava. Moduulien testaajat ottavat osaa testaukseen, tarvittaessa myös ohjelmointivastaavat Järjestelmätestausryhmä Järjestelmätestauksesta vastaa testausvastaava. Testaus suoritetaan yhdessä järjestelmän suunnittelijoiden (arkkitehtien) kanssa. Tarvittavaa teknistä tukea saadaan ohjelmoijilta Hyväksymistestausryhmä Hyväksymistestaus suoritetaan yhdessä ryhmän edustajan ja asiakkaan kanssa. 7 Riskienhallinta Projektin yleiset riskit, jotka on esiteltyinä projektisuunnitelmassa, pätevät myös testaukseen. Lisäksi taulukossa 8 on esiteltyinä muita riskejä liittyen testaukseen. 8 Liitteet ja viittaukset Viitteet [1] Markus Kuhn, A Summary of the International Standard Date and Time Notation, mgk25/iso-time.html [2] Patrik Simons, Smodels, [3] Tommi Syrjänen, Lparse,

14 Riski Kuvaus Vaik. Tod. Kok. Varautuminen RI-01 Järjestelmätestaukseen varatut voimavarat loppuvat, koska testaukseen vaadittava aika on pahasti aliarvioitu RI-02 RI-03 RI-04 RI-05 Järjestelmätestausta ei pystytä aloittamaan tai suorittamaan riittävästi ajan puutteen vuoksi Järjestelmätestauksessa paljastuu vakavia virheitä, jotka pakottavat keskeyttämään testauksen ja tekemään isoja korjauksia järjestelmään. Testaustyökalujen ei onnistu ryhmän puutteellisten taitojen suhteen Testausympäristö on saavutettamattomissa testaushetken aikana RI-06 Testausympäristö ei toimi testaushetken aikana 4 0,30 1,20 Varataan lisää aikaa järjestelmätestaukselle projektin edetessä, jos arviot näyttävät epätodellisilta. 4 0,45 1,80 Varataan projektissa aikaa testaukselle ja käytetään sisäisiä aikarajoja ohjelmoinnille, jotka jättävät vaiheiden loppuun aikaa testauskselle. 5 0,20 1,00 Projektin aikana järjestetään katselmointeja, joilla pyritään etsimään ja korjaamaan virheet koodista ja dokumenteista ennen järjestelmätestausvaihetta. 3 0,25 0,75 Testaus suoritetaan tarvittaessa manuaalisesti ja käyttäen hyödyksi työkaluja, jotka ovat ryhmän jäsenille ennestään tuttuja. 3 0,20 0,60 Varataan aikataulu niin, että testitila on avoinna testaushetken aikana. Varaudutaan pystyttämään testiympäristö muualle ottamalla varmuuskopiota ympäristöstä. 4 0,15 0,60 Testataan järjestelmän toiminnallisuus ennen testien aloittamista. Varaudutaan siirtämään testiympäristö toiseen laitteistoon tarvittaessa. Taulukko 8: Testaukseen liittyvät riskit 14