T-76.115 Testaussuunnitelma 11.2.2002 Confuse 1
Tila Versio: 2.01 Tila: Sisäisesti katselmoitu Jakelu: Julkinen Luotu: 01.11.2001 Antti Haapakoski Muutettu viimeksi: 11.02.2002 Jani Myyry Versiohistoria Versio Pvm Tekijä Kuvaus 0.1 01.11.2001 Haapakoski Antti Dokumenttipohja 0.11 20.11.2001 Jani Myyry Ensimmäinen versio 0.12 02.12.2001 Jani Myyry Lisätty testattava kohde, menetelmät, testiympäristö. 0.13 03.12.2001 Jani Myyry Lisätty riskienhallinta, vastuut, kriteerit. 0.14 04.12.2001 Jani Myyry Korjattu katselmoinnin pohjalta virheitä, lisätty testi- ja virheprioriteetit. 1.0 05.12.2001 Jani Myyry Sisäisesti katselmoitu versio. 1.1 27.01.2002 Jani Myyry Lisätty pohjat testitapauksia varten. 1.2 05.02.2002 Antti Haapakoski Mapperille lisätty testcaseja kappaleeseen 4.1. 1.3 05.02.2002 Jani Myyry Mapperille lisää testcaseja kappaleeseen 4.1. 1.4 05.02.2002 Jani Myyry Lisätty Arin käyttöliittymän testitapaukset kappaleeseen 4.2. 1.5 05.02.2002 Jussi Vainionpää Lisäsin installerin testitapaukset kappaleeseen 4.3. 1.6 06.02.2002 Jani Myyry Korjattu katselmoinnin pohjalta aikatauluja yms. 2.0 06.02.2002 Jani Myyry Sisäisesti katselmoitu versio. 2.01 11.02.2002 Jani Myyry Korjattu pieniä typoja. 2
Sisältö 1 Johdanto 4 1.1 Tarkoitus ja kattavuus.......................................... 4 1.2 Määritelmät, termit ja lyhenteet..................................... 4 1.3 Viitteet.................................................. 6 1.4 Yleiskatsaus dokumenttiin....................................... 6 2 Testattava järjestelmä 6 2.1 Testauksen kohde............................................ 6 2.2 Testattavat ominaisuudet........................................ 6 2.3 Ominaisuudet joita ei testata...................................... 7 3 Testausprosessi 7 3.1 Menetelmät testaukseen......................................... 7 3.2 Moduulitestaus............................................. 7 3.3 Integrointitestaus............................................ 8 3.4 Järjestelmätestaus............................................ 8 3.5 Hyväksymystestaus........................................... 8 3.6 Vaadittava tulosaineisto......................................... 8 3.7 Aikataulu ja työmäärät......................................... 9 4 Testitapaukset 9 4.1 Mapper................................................. 9 4.2 GUI - käyttöliittymä.......................................... 12 4.3 Installer - paketin asennusohjelma................................... 14 4.4 Prioriteetit testaukselle......................................... 17 5 Kriteerit testaukselle 17 5.1 Järjestelmätestauksen hyväksymiskriteerit............................... 17 5.2 Järjestelmätestauksen hylkäämiskriteerit................................ 18 5.3 Järjestelmätestauksen päättämiskriteerit................................ 18 5.4 Testauksen aloittamiskriteerit...................................... 18 5.5 Testauksen keskeyttämiskriteerit.................................... 18 5.6 Testauksen jatkamiskriteerit...................................... 19 6 Testausympäristö ja henkilöstö 19 6.1 Testausympäristö............................................ 19 6.1.1 Vaatimukset testausympäristölle................................ 19 6.1.2 Laitteisto............................................ 19 6.1.3 Ohjelmistot........................................... 19 6.1.4 Turvallisuus........................................... 20 6.1.5 Työkalut............................................ 20 6.2 Henkilöstö................................................ 20 6.2.1 Henkilöstön tarve........................................ 20 6.2.2 Testihenkilöstö......................................... 20 6.2.3 Koulutus............................................ 21 6.3 Vastuualueet............................................... 21 6.3.1 Integrointitestausryhmä..................................... 21 6.3.2 Järjestelmätestausryhmä.................................... 21 6.3.3 Hyväksymistestausryhmä................................... 21 7 Riskienhallinta 21 8 Liitteet ja viittaukset 21 3
1 Johdanto 1.1 Tarkoitus ja kattavuus Tämä dokumentti on kurssin T-76.115 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 T3-vaiheessa hyödyntäen T2-vaiheen lopussa toteutettua moduulitestausta. 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 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. 4
ipkg Itsy Package Management System. A lightweight configuration system for Familiar Linux. Kevyt konfiguraationhallintasysteemi Familiar Linuxille. ISO 8601 International Standard for numeric representations of date and time. Kansainvälinen standardi päiväyksen esittämiseen numeerisessa muodossa. Java Object-oriented programming language. Olio-ohjelmointikieli. JSP JavaServer Pages, technology for creating WWW-pages. Teknologia www-sivujen rakentamiseen. 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. Perl Powerful high-level interpretable programming language. Korkeantason tulkattava ohjelmointikieli. 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ä. Redhat Linux Free UNIX like operating system. Vapaa UNIX-tyyppinen käyttöjärjestelmä. 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. SSL Secure Sockets Layer, security protocol that provides communications privacy over the Internet. Protokolla, joka turvaa datan luottamuksellisuuden siirrettäessä Internetin yli. 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. 5
USDP UML ViCa WinCE Wireless Ethernet WLAN WWW XML xmodem X environment Unified Software Development Process, Generic context for a software project. Ohjelmistoprosessin yleinen viitekehys. Unified Modeling Language, a standard for visualization and specification of a software system. Standardi ohjelmiston visualisointiin ja määrittelyyn. Visualization Client Application. Visualisointi ohjelma. Windows CE, Microsoft s operating system for handhelds. Microsoftin käyttöjärjestelmä käsimikroille. 802.11b Wireless Ethernet, See WLAN. Wireless Local Area Network. Computer network that uses radio waves to transmit data. Langaton verkko tietokoneiden välillä. World Wide Web. Maailmanlaajuinen tietoliikenneverkko. 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. 6
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. 3 Testausprosessi 3.1 Menetelmät testaukseen Testaus aloitetaan moduulien testauksesta, jatkaen USDP-prosessin mukaisesti iteratiivisesti kohti järjestelmätestausta, joka suoritetaan T3-vaiheessa. 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ä 7
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, käyttäen hyödyksi määriteltyjä testitapauksia, joita hyödynnetään myös myöhemmissä testausvaiheissa. 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 ohjelmoinnin aikaisista testeistä ei tuoteta testiraporttia, mutta ennen siirtymistä integrointivaiheeseen tulee tärkeimmistä testitapauksista 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. 3.4 Järjestelmätestaus Järjestelmätestaus suoritetaan onnistuneiden integrointitestausten jälkeen. Järjestelmätestaus suoritetaan T3-vaiheessa, käyttäen hyödyksi edellisten vaiheiden testitapauksia, laajentaen niitä mahdollisuuksien mukaan koskemaan myös järjestelmän ulkopuolisia komponentteja (Configurator Engine). 3.5 Hyväksymystestaus Hyväksymistestaus suoritetaan T3-vaiheen lopulla tai LU-vaiheen alussa ryhmän edustajan toimesta yhdessä asiakkaan kanssa. 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/eri testivaiheissa), varmistaen että modulin toiminnallisuus säilyy oikeana ohjelmointiprosessin aikana. Testit pyritään automatisoimaan, jotta testin suorittaminen olisi mahdollisimman helppoa. Moduuli-testeistä kirjataan ylös erilliseen testitapaus-tiedostoon, testiraporttiin siirretään yhteenvedot tuloksista, tarkemmin määriteltynä testiraportissa: aika Testin ajankohta ISO 8601-merkinnällä [1]. testitapauksen tunniste Testitapauksen tunniste, eriteltyinä kappaleessa 4. modulien nimet Mihin komponentteihin testaus liittyy. modulien versiot Jos modulista on tehty release, niin sen versio, muuten esim. CVS-revisio. testaaja Kuka testaa. ympäristö Kuvaus ympäristöstä ja työkaluista. kuvaus 8
Kuvaus juuri tehtävästä testistä. syöte Tiedostot (tiedot) syötteestä. palaute Modulin palaute kokonaisena. kommentit Kommentit testien suorittajilta. virheet Kommentit virheistä, onko tehty virheraportti Buranaan. liitteet Mahdolliset liitteet ajojen tuloksista. 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. Henkilö T1 T2 T3 LU Testivastaava Myyry Jani 5 19 20 5 Haapaniemi Ari 4 11 10 0 Haapakoski Antti 2 5 10 0 Kujala Petri 2 0 6 0 Martsola Mikko 2 5 10 0 Vainionpää Jussi 2 5 6 0 Yhteensä 17 45 51 5 Taulukko 1: Allokoidut tunnit testaukselle, sisältää testaussuunnitelman 4 Testitapaukset Testauksessa käytetään seuraavia määriteltyjä testejä, joiden lopputulokset ovat erillisessä testiraportissa. Seuraavassa komponettikohtaisesti eriteltyinä testitapaukset, joita käytetään testauksessa. Komponenttien yksityiskohdat löytyvät toiminnallisesta ja teknisestä määrittelystä. ten merkintätapa on seuraava: TC-M-01, jossa TC on tunniste testitapaukselle, seuraava lyhenne on komponentti (M = Mapper, G = GUI, I = Installer) ja viimeinen järjestysnumero testitapaukselle. Tunnistetta käytetään kaikissa testaukseen liittyvissä dokumenteissa yksilöimään tapaukset. Vaatimukset liittyen testitapauksiin löytyvät eriteltyinä vaatimusmäärittelystä. 4.1 Mapper Seuraavat testitapaukset ovat Mapper-komponenttia varten. 9
TC-M-01 High UR-04 Must, UR-08 Must Mapper Moduuli, Integraatio, Järjestelmä Usean paketin metadata lisätään kerralla järjestelmään (syötetään Mapperin stdin:iin) ja tarkistetaan skriptillä tulivatko kaikkien pakettien nimet allpackages.xml:ään ja packages.rl:ään. allpackages.xml ja packages.rl eivät sisällä yhtään pakettia. Packages (tekstitiedosto jossa usean paketin tiedot) Kaikkien Packages-tiedostossa olevien pakettien nimet löytyvät myös allpackages.xml:stä ja packages.rl:stä. TC-M-02 High UR-04 Must, UR-08 Must Mapper Moduuli, Integraatio, Järjestelmä Usean paketin metadata lisätään kerralla järjestelmään (syötetään mapperin stdin:iin) ja tarkistetaan skriptillä tulivatko kaikkien pakettien tiedostonimet oikein allpackages.xml:ään. allpackages.xml (ja packages.rl) eivät sisällä yhtään pakettia. Packages (tekstitiedosto jossa usean paketin tiedot) Kaikkien Packages-tiedostossa olevien pakettien tiedostonimet löytyvät polkuineen myös allpackages.xml:stä. TC-M-03 High UR-04 Must, UR-08 Must Mapper Moduuli, Integraatio, Järjestelmä Usean paketin metadata lisätään kerralla järjestelmään (syötetään mapperin stdin:iin) ja tarkistetaan skriptillä tulivatko kaikki pakettien väliset Depends-riippuvuudet packages.rl:ään. packages.rl (ja allpackages.xml) eivät sisällä yhtään pakettia. Packages (tekstitiedosto jossa usean paketin tiedot) Kaikkien Packages-tiedostossa olevat Depends: - riippuvuudet löytyvät myös packages.rl:stä. 10
TC-M-04 Medium UR-04 Must, UR-08 Must Mapper Moduuli, Integraatio, Järjestelmä Usean paketin metadata lisätään kerralla järjestelmään (syötetään mapperin stdin:iin) ja tarkistetaan skriptillä onko luotavassa packages.rl:ssä kaikki kentät Configurator Enginen syntaksin mukaista ja ettei mikään kenttä sisällä erikoismerkkejä (joita ei ole etukäteen kaavailtu olevan). packages.rl ei sisällä yhtään pakettia. Packages (tekstitiedosto jossa usean paketin tiedot) packages.rl:ssä kaikkien määrittelyn kentässä on hyväksyttävä arvo, kenttien arvoissa ei ole ylimääräisiä tyhjiä merkkejä ja määrittelyt ovat ehjiä. TC-M-05 Low UR-04 Must, UR-08 Must Mapper Moduuli Itse generoitu Packages-tiedosto lisätään järjestelmään (syötetään mapperin stdin:iin) ja tarkistetaan käsin, onko tulos (packages.rl ja allpackages.xml) syöte-tiedoston määrittelyn mukaista. Packages-tiedostossa on erikoismerkkejä, duplikaattipaketteja ja syktaktisesti vääriä kenttiä. packages.rl ja allpackages.xml eivät sisällä yhtään pakettia. Packages (tekstitiedosto jossa usean paketin tiedot) Ajon yhteydessä mapperilta pitäisi tulla varoitus virheellisistä kentistä ja duplikaattipaketeista. Tarkistetaan ovatko packages.rl ja allpackages.xml syötetyn Packagestiedoston kanssa yhteneväisiä sisällön suhteen. TC-M-06 High UR-04 Must, UR-08 Must Mapper Moduuli, Integraatio, Järjestelmä Usean paketin metadata (Packages) lisätään kerralla järjestelmään (syötetään mapperin stdin:iin) ja luodaan packages.rl ja allpackages.xml-tiedostot. Syntyneet tiedostot siirretään talteen. Lisäksi mapperille syötetään kaikki paketit, joista Packages on alkujaan luotu ja saadaan toiset packages.rl ja allpackages.xml-tiedostot. Tiedostoja verrataan keskenään. packages.rl ja allpackages.xml eivät sisällä yhtään pakettia. Packages (tekstitiedosto jossa usean paketin tiedot) ja kaikki ipkg-paketit (jotka vastaavat Packages-tiedoston sisältöä). Molempien ajojen tuloksena syntyneet tiedostot packages.rl ja allpackages.xml ovat identtisiä toistensa kanssa. 11
4.2 GUI - käyttöliittymä Käyttöliittymän testitapaukset. TC-G-01 High UR-03 Must, UR-09 Must, UR-27 Must GUI Moduuli, Integraatio, Järjestelmä GUI lukee allpackages.xml tiedoston ja muodostaa tämän tiedoston sisällön perusteella pakettilitauksen käyttäjän web-selaimeen HTLM muodossa. Mapper on muodostanut pakettilistauksen XML formaatissa allpackages.xml tiedostoon. Käyttäjä on ottanut yhteyden palvelimen web-serveriin web-selaimensa avulla. Käyttäjä syöttää Configurator-palvelun URL:n webselaimensa osoitekenttään. Käyttäjän web-selaimeen muodostuu HTML pakettilistaus palvelimella olevista paketeista. TC-G-02 High UR-05 Must, UR-27 Must GUI Moduuli, Integraatio, Järjestelmä Käyttäjä valitsee paketteja omaan konfiguraationsa. Mapper on muodostanut pakettilistauksen XML formaatissa allpackages.xml tiedostoon. Käyttäjä on ottanut yhteyden palvelimen pakettilistaus sivuun web-selaimensa avulla ja hänelle on muodostettu pakettilistaus. Painamalla pakettikohtaista Add2Config2 linkkiä käyttäjä lisää kyseisen paketin omaan konfiguraatioonsa. Valitun paketin Add2Config linkki muuttuu Remove linkiksi ja kyseinen paketti lisätään käyttäjän konfiguraatioon. (Tämä voidaan nykyisellään testata siten, että kirjoitetaan konfiguraatio tiedostoon - Save Configuration - ja tulkitaan tiedoston sisältöä). TC-G-03 High UR-06 Must, UR-27 Must GUI Moduuli, Integraatio, Järjestelmä Käyttäjä poistaa paketteja omasta konfiguraatiostansa. Käyttäjä on valinnut omaan konfiguraatioonsa vähintään yhden paketin, tai hän voinut myös lisätä paketteja konfiguraatioonsa valitsemalla Load Configuration - toiminteen. Painamalla pakettikohtaista Remove -linkkiä käyttäjä poistaa kyseisen paketin omasta konfiguraatiostaan. Valitun paketin Remove -linkki muuttuu Add2Config - linkiksi ja kyseinen paketti poistetaan käyttäjän konfiguraatiosta. (Tämä voidaan nykyisellään testata siten, että kirjoitetaan konfiguraatio tiedostoon - Save Configuration - ja tulkitaan tiedoston sisältöä). 12
TC-G-04 Medium UR-19 Must, UR-27 Must GUI Moduuli, Integraatio, Järjestelmä Käyttäjä haluaa tallettaa valitsemansa konfiguraation tiedostoon. Käyttäjä on ottanut web-selaimella yhteyden Configurator-palvelun pääsivuun, johon hänelle on luotu listaus saatavilla olevista paketeista ja niiden tiedot. Käyttäjä on valinnut konfiguraatioonsa joitakin paketteja painalmalla pakettikohtaista Add2Config linkkiä. Käyttäjä painaa pääsivulla olevaa Save Configuration - painiketta, jonka jälkeen hän pääsee sivulle, jolla määritellään tiedoston nimi, johon konfiguraatio tallennetaan. Tällä sivullä käyttäjä nimeää tiedoston johon konfiguraatio kirjoitetaan ja painaa OK nappia. Käyttäjä voi myös valita BACK TO MAIN PAGE napin jolloin hän palaa pakettilistaus sivulle. Jos tiedoston nimi on pituudeltaan 0 tai se sisältää hakemiston erotin merkkejä, tulostetaan käyttäjälle virheilmoitus ja kehoitetaan antamaan uusi tiedoston nimi. Jos tiedoston nimi on hyväksyttävä, suoritetaan tiedostoon kirjoitus ja tulostetaan käyttäjälle onnistuneen kirjoituksen ilmoitus ja pakettien lukumäärä, jotka tiedostoon kirjoitettiin. TC-G-05 Medium UR-20 Must, UR-27 Must GUI Moduuli, Integraatio, Järjestelmä Käyttäjä haluaa haluaa ladata tallettamansa konfiguraation tiedostosta. Käyttäjä on tallettanut aikaisemmin konfiguraation tiedostoon. Käyttäjä painaa pääsivulla olevaa Load Configuration - painiketta, jonka jälkeen hän pääsee sivulle jolla määritellään tiedoston nimi, josta konfiguraatio ladataan. Tällä sivullä käyttäjä nimeää tiedoston, josta konfiguraatio ladataan ja painaa OK nappia. Käyttäjä voi myös valita BACK TO MAIN PAGE napin, jolloin hän palaa pakettilistaus-sivulle. Jos tiedoston nimi on pituudeltaan 0 tai se sisältää hakemiston erotin merkkejä, tulostetaan käyttäjälle virheilmoitus ja kehoitetaan antamaan uusi tiedoston nimi. Jos tiedoston nimi on hyväksyttävä suoriteaan lukuoperaatio ja tulostetaan käyttäjälle onnistuneen suorituksen ilmoitus ja pakettien lukumäärä, jotka tiedostosta luettiin. 13
4.3 Installer - paketin asennusohjelma Seuraavat testitapaukset ovat Installer-komponenttia varten. TC-I-01 High UR-14 Must, UR-15 Must, UR-21 Useful Installer Moduuli Asetetaan testausta varten tehty configuration.xml installerin saataville, ja ajetaan installer. configuration.xml sisältää jo asennettuja paketteja sekä yhden asennettavan paketin. Varmistetaan paketin asentuminen seuraamalla installerin tulosteita sekä tarkistamalla ipaq:n tiedostojärjestelmästä. Jos UR-21 on toteutettu, tarkistetaan että vain uusi paketti asennettiin. Tarkistetaan että installerin paluuarvo on 0. Testipakettia ei ole asennettu ipaq:iin. configuration.xml, joka sisältää jo asennettuja paketteja, sekä yhden asennettavan testipaketin. Paketti on asennettu ipaq:iin ja installer palautti onnistumista merkitsevän paluuarvon 0. TC-I-02 Low UR-14 Must, UR-15 Must Installer Moduuli Asetetaan testausta varten tehty configuration.xml installerin saataville, ja ajetaan installer. configuration.xml sisältää yhden asennettavan paketin, jonka nimessä on välilyöntejä sekä muita erikoismerkkejä. Varmistetaan paketin asentuminen seuraamalla installerin tulosteita sekä tarkistamalla ipaq:n tiedostojärjestelmästä. Tarkistetaan että installerin paluuarvo on 0. Testipakettia ei ole asennettu ipaq:iin. configuration.xml, joka sisältää yhden asennettavan testipaketin, jonka nimessä on välilyöntejä sekä muita erikoismerkkejä. Paketti on asennettu ipaq:iin ja installer palautti onnistumista merkitsevän paluuarvon 0. 14
TC-I-03 High UR-15 Must Installer Moduuli Asetetaan testausta varten tehty configuration.xml installerin saataville, ja ajetaan installer. configuration.xml sisältää jo asennettuja paketteja sekä yhden asennettavan paketin, jota ei ole saatavilla. Varmistetaan installer käyttäytyy siististi virheestä huolimatta seuraamalla installerin tulosteita. Tarkistetaan että installerin paluuarvo on muuta kuin 0. Testipakettia ei ole asennettu ipaq:iin. configuration.xml, joka sisältää paketin jota ei ole saatavilla. Paketin asennus ipaq:iin on epäonnistunut ja installer palautti epäonnistumista merkitsevän paluuarvon, joka on muuta kuin 0. TC-I-04 Medium UR-15 Must Installer Moduuli Asetetaan testausta varten tehty configuration.xml installerin saataville, irroitetaan ipaq verkosta ja ajetaan installer. Varmistetaan installer käyttäytyy siististi virheestä huolimatta seuraamalla installerin tulosteita. Tarkistetaan että installerin paluuarvo on muuta kuin 0. ipaq ei ole kiinni verkossa. configuration.xml. Paketin asennus ipaq:iin on epäonnistunut ja installer palautti epäonnistumista merkitsevän paluuarvon, joka on muuta kuin 0. TC-I-05 High UR-15 Must Installer Moduuli Asetetaan testausta varten tehty configuration.xml installerin saataville, täytetään ipaq:n muisti siten, ettei testi paketti mahdu sinne, ja ajetaan installer. configuration.xml sisältää asennettavan paketin. Varmistetaan installer käyttäytyy siististi virheestä huolimatta seuraamalla installerin tulosteita. Tarkistetaan että installerin paluuarvo on muuta kuin 0. Testipakettia ei ole asennettu ipaq:iin ja ipaq:n muisti on niin vähissä ettei paketti mahdu ipaq:iin. configuration.xml, joka sisältää paketin jota ei ole saatavilla. Paketin asennus ipaq:iin on epäonnistunut ja installer palautti epäonnistumista merkitsevän paluuarvon, joka on muuta kuin 0. 15
TC-I-06 Medium UR-15 Must Installer Moduuli Asetetaan testausta varten tehty configuration.xml, joka ei sisällä tarvittavia attribuutteja tai sisältää syntaksivirheitä, installerin saataville. Varmistetaan installer käyttäytyy siististi virheestä huolimatta seuraamalla installerin tulosteita. Tarkistetaan että installerin paluuarvo on muuta kuin 0. Virheellinen configuration.xml. Asennus on epäonnistunut ja installer palautti epäonnistumista merkitsevän paluuarvon, joka on muuta kuin 0. TC-I-07 High UR-15 Must Installer Moduuli Asetetaan testausta varten tehty configuration.xml installerin saataville. configuration.xml:ään sisällytetään useita asennettavia paketteja, joista yhden asennuksessa on odotettavissa virhe. Tarkistetaan että virhe havaitaan ja että installerin paluuarvo on muuta kuin 0. configuration.xml, jossa on monta asennettavaa pakettia, joista yhtä ei voida asentaa. Asennus on (osittain) epäonnistunut ja installer palautti epäonnistumista merkitsevän paluuarvon, joka on muuta kuin 0. TC-I-08 Low UR-16 Nice to have Installer Moduuli Asetetaan testausta varten tehty configuration.xml installerin saataville, ja ajetaan installer. configuration.xml sisältää jo asennettuja paketteja sekä yhden poistettavan paketin. Varmistetaan paketin poistuminen seuraamalla installerin tulosteita sekä tarkistamalla ipaq:n tiedostojärjestelmästä. Tarkistetaan että installerin paluuarvo on 0. Testipaketti on asennettu ipaq:iin. configuration.xml, joka sisältää jo asennettuja paketteja, sekä yhden poistettavan testipaketin. Paketti on poistettu ipaq:sta ja installer palautti onnistumista merkitsevän paluuarvon 0. 16
TC-I-09 Low UR-25 Nice to have Installer Moduuli Asetetaan testausta varten tehty configuration.xml installerin saataville, ja ajetaan installer. configuration.xml sisältää kaksi asennettavaa pakettia, jotka ovat niin suuria, ettei ipaq:n muisti riitä, jos molemmat paketit ovat ipaq:ssa asennuksen aikana. Varmistetaan asennuksen onnistuminen ja tarkistetaan että installerin paluuarvo on 0. ipaq:n muisti on niin täynnä, että molemmat paketit sekä paketteina että asennettuna eivät mahdu muistiin. Tilaa tulee kuitenkin olla molemmille asennettuna ja yhdelle pakettina. configuration.xml, joka sisältää asennettavat testipaketit. Paketit on asennettu ipaq:iin ja installer on palauttanut onnistumista merkitsevän paluuarvon 0. 4.4 Prioriteetit testaukselle 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. 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. 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. 17
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. 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ä. 18
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ä. 6 Testausympäristö ja henkilöstö 6.1 Testausympäristö 6.1.1 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. 6.1.2 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 6.1.3 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 1.3.22 (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 0.4.1 Apache, Java 2 Standard JSP-palvelualusta Edition, Java 2 Enterprise Edition Taulukko 5: Palvelinohjelmistot käyttäliittymää varten 19
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. 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. 6.1.5 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 5.6.0 tulkattava scriptikieli automatisoimaan testiajoa ja testaamaan palautteita ohjeellisiin time mittaa prosessin suoritusajan mitataan komponettien suoritusaikaa, viiveitä käyttäjälle LATEX2e (TEX) 3.14159 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ö 6.2.1 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. 6.2.2 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. 20
Komponentti Ohjelmoija Testaaja Mapper Antti Haapakoski Jani Myyry GUI Ari Haapaniemi Petri Kujala Installer Mikko Martsola Jussi Vainionpää Taulukko 7: Moduulitestauksesta vastaavat 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. 6.3.1 Integrointitestausryhmä Integrointitestauksesta vastaa testausvastaava. Moduulien testaajat ottavat osaa testaukseen, tarvittaessa myös ohjelmointivastaavat. 6.3.2 Järjestelmätestausryhmä Järjestelmätestauksesta vastaa testausvastaava. Testaus suoritetaan yhdessä järjestelmän suunnittelijoiden (arkkitehtien) kanssa. Tarvittavaa teknistä tukea saadaan ohjelmoijilta. 6.3.3 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, 2001. http://www.cl.cam.ac.uk/ mgk25/iso-time.html [2] Patrik Simons, Smodels, 2000 http://www.tcs.hut.fi/software/smodels/ [3] Tommi Syrjänen, Lparse, 2000 http://www.tcs.hut.fi/software/smodels/ 21
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 22