Testplan Redaktör: Version: 1.1 I Tal-Lab kan ingen höra dig skrika Sammanfattning STUM är ett system för talsyntes. Det utvecklas åt avdelningen för Human- Centered Systems (HCS) vid (IDA) vid Linköpings Tekniska Högskola. Syftet med projektet STUM är att utveckla en applikation för att utvärdera en ny metod för talsyntes. Detta dokument beskriver den planerade testningen av STUM-systemet. Dokumentet innehåller specifikationer av de test som kommer att utföras under de olika testfaserna enhetstest, modultest, integrationstest, systemtest och acceptanstest. Ansvarsroller, tillvägagångssätt, testprocedurer och testmetoder beskrivs. Dokumentet innehåller även en tidsplanering över hela testarbetet och över de specifika testfaserna.
Projektidentitet Projektgrupp Stum Linköpings tekniska högskola (IDA) Projektmedlemmar Namn Ansvarsområde Telefon E-post Ali Aghajani Projektledare 0730-460493 aliag988@student.liu.se Kjell Enblom Dokumentansvarig 0762-353375 kjeen007@student.liu.se Filip Klasson Kvalitetsansvarig 0762-311778 filkl784@student.liu.se Johan Millving Designansvarig 0709-788619 johmi359@student.liu.se Andreas Rasmussen Implementationsansvarig 0703-718879 avatar@lysator.liu.se Gustav Veide Systemansvarig 0705-514745 gusve322@student.liu.se Patrik Sandström Kundansvarig 0735-464898 patsa014@student.liu.se Testansvarig 0709-507595 tomja961@student.liu.se E-postlista för hela gruppen pum1@und.ida.liu.se Hemsida www-und.ida.liu.se/~pum1 Kund Kundkontakt Bertil Lyberg, berly@ida.liu.se Mustapha Skhiri, mussk@ida.liu.se Handledare Sten Sunnergren, sten.sunnergren@ekhosat.se Examinator och kursansvarig Robert Kaminski, IDA
Dokumenthistorik Version Datum Utfärdade ändringar Utfärdade av 0.1 2005-11-02 Dokumentet skapades. 0.2 2005-11-08 Små justeringar av grammatik och testspecifikationer efter kommentering. 1.0 2005-11-11 Korrigering av layout och grammatik. Omskrivning av för långa meningar och av vissa stycken för att förtydliga. Utfört efter inspektion. iii
Version Datum Utfärdade ändringar Utfärdade av 1.1 2005-11-25 Döpte om tester i kapitel 8 Modultestspecifikation till Modultest 1-10 Lagt till felaktig indata i Modultest 1, 4, 9 Döpte om tester i kapitel 9 Integrationstetspecifikation till Integrationstest 1-4 Lagt till felaktig indata i Integrationstest 1, 3, 4 Integrationstest 3 involverar inte DataBase längre och anrop av databas görs endast med ljuddata Integrationstest 4 involverar inte längre ansiktsdata. Metodnamn i "Utförande" har ändrats för att matcha modiferad design. Systemtest 1 en definition har lags till om vad som anses vara orlimig minnes- och CPU-åtgång Tog bort gammal dator från Systemtest 1. Systemtest 3 utgår pga. bortfall av krav Lagt till utrustning, verktyg och dokument i kapitel 3-7 Ny underrubrik 2.3.1 Prioriteringar under avsnitt 2.3 Lagt till uppmärkning under avsnit 1.5 Förklaring av begrepp Förtydligade indatat för Integrationstest 1 - DataBase, DataBaseGUI på sid Förtydligade indata för Integrationstest 2 Synthesizer, Processor, StumVisualizer Förtydligade alla modultest Förtydligade hur modulerna hängerihop i kapitel 5 Integrationstestplan Utökat testmetodbeskrivningen i enhetstestplanen (stycke 3.4). Lagt till en rubrik om täckning (3.9) i enhetstestplanen. Uppdaterat metodmotiveringen i modultestplanen (4.4.2). Skrivit om och uppdaterat metodmotiveringen i integrationstestplanen (5.5.3). Lagt till ett avsnitt om täckning i integrationstestplanen (5.9). Lagt till ett avsnitt om täckning i systemtestplanen (6.9). Lag till avsnitt om prioritering i enhets-, modul-, integrations- och systemtestplan. iv
1 Inledning... 1 1.1 Syfte... 1 1.2 Läsanvisningar... 1 1.3 Dokumentöversikt... 1 1.4 Dokumentberoende... 2 1.5 Förklaring av begrepp... 2 2 Översiktlig testplanering... 5 2.1 Tidsplanering... 5 2.2 Ansvar och roller... 5 2.2.1 Testsamordnare...5 2.2.2 Testkonstruktör... 5 2.2.3 Testare... 6 2.2.4 Utvärderare... 6 2.3 Testordning... 6 2.3.1 Prioritering... 6 3 Enhetstestplan... 7 3.1 Syfte... 7 3.2 Ansvar... 7 3.3 Tidsplan... 7 3.4 Utrustning, verktyg och dokument... 7 3.5 Testmetod... 7 3.6 Genomförande... 8 3.6.1 Kriterier för att få påbörja enhetstest... 8 3.6.2 Testprocedur... 8 3.7 Kriterier för ett lyckat test... 8 3.8 Uppföljning... 8 3.9 Täckning... 8 3.10 Prioritering... 8 4 Modultestplan... 9 4.1 Syfte... 9 4.2 Ansvar... 9 4.3 Tidsplan... 9 4.4 Utrustning, verktyg och dokument... 9 4.5 Testmetod... 10 4.5.1 Svartlådetest... 10 4.5.2 Motivering... 10 4.6 Genomförande... 10 4.6.1 Kriterier för att få påbörja modultest... 10 4.6.2 Testprocedur...11 4.7 Kriterier för ett lyckat test... 11 4.8 Uppföljning... 11 4.9 Täckning... 11 4.10 Prioritering... 11 5 Integrationstestplan... 13 5.1 Syfte... 13 5.2 Ansvar... 13 v
5.3 Tidsplan... 13 5.4 Utrustning, verktyg och dokument... 13 5.5 Testmetod... 14 5.5.1 Funktionell testning... 14 5.5.2 Sandwich-test...14 5.5.3 Motivering... 14 5.6 Genomförande... 14 5.6.1 Kriterier för att få påbörja integrationstest... 14 5.6.2 Testprocedur...15 5.7 Kriterier för ett lyckat test... 15 5.8 Uppföljning... 15 5.9 Täckning... 15 5.10 Prioritering... 15 6 Systemtestplan... 17 6.1 Syfte... 17 6.2 Ansvar... 17 6.3 Tidsplan... 17 6.4 Utrustning, verktyg och dokument... 17 6.5 Testmetod... 18 6.6 Genomförande... 18 6.6.1 Kriterier för att få påbörja systemtest... 18 6.6.2 Testprocedur...18 6.7 Kriterier för ett lyckat test... 18 6.8 Uppföljning... 18 6.9 Täckning... 18 6.10 Prioritering... 19 7 Acceptanstestplan... 21 7.1 Acceptanstest... 21 7.1.1 Syfte... 21 7.1.2 Ansvar... 21 7.2 Tidsplan... 21 7.3 Utrustning, verktyg och dokument... 21 7.4 Genomförande... 22 7.4.1 Kriterier för att få genomföra ett acceptanstest... 22 7.4.2 Testprocedur...22 7.5 Kriterier för ett lyckat test... 22 7.6 Uppföljning... 22 7.7 Täckning och prioritering... 22 8 Modultestspecifikation... 23 8.1 StumVisualizer... 23 8.1.1 Modultest 1 - StumVisualizer... 23 8.2 Synthesizer... 23 8.2.1 Modultest 2 - Synthesizer... 23 8.3 StumGUI... 23 8.3.1 Modultest 3 - StumGUI... 23 8.4 DataBaseGUI... 23 vi
8.4.1 Modultest 4 - DataBaseGUI... 23 8.4.2 Modultest 5 - DataBaseGUI... 24 8.4.3 Modultest 6 - DataBaseGUI... 24 8.4.4 Modultest 7 - DataBaseGUI... 24 8.5 DataBase... 24 8.5.1 Modultest 8 - DataBase... 24 8.5.2 Modultest 9 - DataBase... 24 8.5.3 Modultest 10 - DataBase... 25 9 Integrationstestspecifikation... 27 9.1 Databashantering... 27 9.1.1 Integrationstest 1 - DataBase, DataBaseGUI... 27 9.1.2 Integrationstest 2 - DataBase, DataBaseGUI... 27 9.2 GUI mot databasen... 27 9.2.1 Integrationstest 3 - StumGUI, Synthesizer... 27 9.3 Visualisera... 27 9.3.1 Integrationstest 4 - Synthesizer, Processor, StumVisualizer... 27 10 Systemtestspecifikation... 29 10.1 Systemtest 1... 29 10.2 Systemtest 2... 29 10.3 Systemtest 3... 29 10.4 Systemtest 4... 29 11 Referenser... 31 11.1 Externa dokument... 31 11.2 Interna dokument... 31 Bilaga A Checklista för enhetstest... 33 Bilaga B Testprotokoll... 35 Bilaga C Felrapport... 37 Bilaga D Testskript... 39 vii
viii
1 Inledning Detta kapitel beskriver dokumentets upplägg och innehåll. 1.1 Syfte Syftet med testplanen är att redogöra för hur testningen av STUM-systemet kommer att gå till. De metoder som används beskrivs och motiveras. Samtliga tester för enhets-, modul-, integrations- och systemtest finns beskriva i dokumentet. Testfall för acceptanstest finns beskrivna i Kravspecifikationen [Sandström, 2005]. 1.2 Läsanvisningar För att få en överblick över planeringen av testarbetet bör kaptiel 2 - Översiktlig testplanering läsas först. Den detaljerade planeringen av testmomenten återfinns i kapitel 3 till 7. Planerna beskriver vad som skall utföras. Specifikationer över hur detta skall utföras återfinns i kapitel 8 till 11. Beskrivning av acceptanstestfall finns i acceptanstestspecifikationen i projektets kravspecifikation [Sandström, 2005]. 1.3 Dokumentöversikt 1. Inledning Detta kapitel beskriver i generella drag dokumentets upplägg och innehåll. 2. Översiktlig testplanering Ger en översiktlig planering av testarbetet. 3. Enhetstestplan Beskriver vilka testmoment och testmetoder som ingår i enhetstestarbetet. 4. Modultestplan Beskriver hur man utför modultest och innehåller även en tidsplanering. 5. Integrationstestplan Beskriver testmetod och utförande av integrationstest tillsammans med en tidsplanering. 6. Systemtestplan Beskriver hur systemtest kommer att gå till. 7. Acceptanstestplan Beskriver vad som krävs för att systemet skall vara redo för ett slutligt acceptanstest. Kapitel 1: Inledning 1
8. Modultestspecifikation Här beskrivs de testfall, med sina förväntade testresultat, som skall utföras under modultestningen. 9. Integrationstestspecifikation Här beskrivs de testfall, med sina förväntade testresultat, som skall utföras under integrationstestningen. 10. Systemtestspecifikation Här beskrivs de testfall, med sina förväntade testresultat, som skall utföras under systemtestningen. 11. Referenser En lista över använda referenser. 1.4 Dokumentberoende Dokument som påverkar testplanen: Projektplan [Aghajani, 2005]. Kravspecifikation [Sandström, 2005]. Arkitekturspecifikation [Rasmussen, 2005]. Designspecifikation [Millving, 2005]. Dokument som påverkas av testplanen: Testresultat [Janowski, 2005]. 1.5 Förklaring av begrepp Här förklaras en del begrepp som förekommer i dokumentet. Stubb Testprogram Testskript Testgrupp, Implementationsgrupp Ett program som har som syfte att simulera en utomstående modul, för att möjliggöra testning av ett ofärdigt system. Används för att initiera den/de moduler som skall testas. Skrivs vid behov av testkonstruktören. Ibland också ett annat ord för stubb. En steg för steg-beskrivning av hur man utför ett specifikt test. Se Bilaga D för exempel. De projektmedlemmar som är involverade i testarbetet och implementationsarbetet. Se även Projektplan [Aghajani, 2005]. 2 Kapitel 1: Inledning
TEST, PL, KVAL, DOK, SYS, DES, IMP, KUND Uppmärkning Medlemmar av projektgruppen: testansvarig, projektledare, kvalitetsingenjör, dokumentansvarig, systemansvarig, designansvarig, implementationsansvarig och kundansvarig. Uppmärkning är en lingvistisk konstruktion för ord och stavelser som beskriver deras uttal. STUM-systemet arbetar i första hand med uppmärkta ord och deras ljuddata. Kapitel 1: Inledning 3
4 Kapitel 1: Inledning
2 Översiktlig testplanering Detta kapitel beskriver den översiktliga tidsplaneringen av testarbetet, de olika ansvarsrollerna och den övergripande testordningen. För en kompletterande, översiktlig beskrivning av testarbetet se Övergripande Testplan [Janowski, 2005]. 2.1 Tidsplanering I tabellen nedan finns en översiktlig tidsplanering över testrelaterat arbete. Mer detaljerade tidsplaner för varje testfas finns under respektive kapitel. Vecka Fas Personer Tid 35-36 Kvalitetsarbete Övergripande testplan skrivs TEST, PL 6 36-39 Definition Acceptanstestfall för kravspecifikationen skrivs TEST, KUND 10 43-45 Testfas Dokumentet testplan skrivs TEST, DES 20 45-47 Testfas Modultest Testgruppen 34 46-47 Testfas Integrationstest Testgruppen 22 47 Testfas Systemtest Testgruppen 22 45-48 Testfas Dokument testresultat skrivs TEST, Testgruppen 25 47-48 Testfas Acceptanstest Alla 16 Summa: 155 2.2 Ansvar och roller Här beskrivs kortfattat de roller som behövs för att utföra ett test och det ansvarsområde som omfattas av respektive roll. 2.2.1 Testsamordnare Huvudansvarig för testarbete är testansvarig (TEST). Denne skall samordna testarbetet, utse ansvariga för olika deluppgifter och utdela arbetsuppgifter till dessa. Testansvarig skall hållas informerad om när en modul eller ett delsystem är redo för testning och hålla reda på vilka moduler eller delsystem som blivit godkända för nästa testnivå. 2.2.2 Testkonstruktör Testkonstruktören ansvarar för att ett specifikt test med tillhörande stubbar och testprogram konstrueras och att ett testskript skrivs utifrån aktuellt testfall. Kapitel 2: Översiktlig testplanering 5
2.2.3 Testare Testaren är den som utför testerna och antecknar resultat i ett testprotokoll. Denne noterar även eventuella fel i en felrapport. 2.2.4 Utvärderare Under flertalet testmoment kommer TEST att agera utvärderare. Utvärderaren tar beslut om när det är dags att sluta testa och gå vidare till nästa modul eller testnivå. Om fel upptäcks rapporterar utvärderaren detta till respektive implementerare och planerar in eventuella framtida test i väntan på att felen åtgärdas. 2.3 Testordning Enhetstest påbörjas då programmeraren börjar skriva kod och pågår under hela implementationsfasen. Då det finns en färdig modul påbörjas modultest. När moduler som kommunicerar med varandra är färdigtestade kan integrationstest påbörjas. Modultest och integrationstest kommer att pågå parallellt. Systemtest utförs när modultest och integrationstest har slutförts och godkänts. Acceptanstest utförs efter ett gemensamt beslut från projektgruppen om att systemet är redo att acceptanstestas. 2.3.1 Prioritering Alla moduler som ingår i STUM är lika viktiga. Om en modul inte fungerar betyder det att man inte får någon meningsfull funktionalitet i programmet. Detta innebär att lika mycket tid kommer att läggas på testning av varje modul, i den mån det är möjligt. En modul som man eventuellt kan prioritera lägre är DataBaseGUI. Om den inte fungerar tillfredsställande kan man använda sig av manuell inmatning av data till databasen. Samma sak gäller under integrations av systemet. Kopplingar mellan alla moduler måste fungera för att programmet skall kunnas användas överhuvudtaget. 6 Kapitel 2: Översiktlig testplanering
3 Enhetstestplan Enhetstestningen består av kompilering och kodgranskning enligt en enkel checklista. Detta kommer att utföras regelbundet av implementeraren själv. 3.1 Syfte Syftet med enhetstestningen är att upptäcka fel, så som uppenbara programmeringsfel och buggar på ett så tidigt stadium som möjligt. Detta för att öka kvaliteten av programmet och underlätta senare testningsarbete. 3.2 Ansvar Testsamordnare - TEST Testkonstruktör - TEST Testare - Implementationsgruppen Utvärderare - TEST, IMP 3.3 Tidsplan Enhetstest sker löpande under hela implementationen och är en vital del av denna. Den behöver därför inte en egen tidsplan. 3.4 Utrustning, verktyg och dokument Här anges den utrustning, verktyg och de dokument som behövs för att genomföra enhetstester. Utrustning och verktyg: Kod som skall testas Eftersom enhetstest skall utföras samtidigt som implementationen kan det vara bra att använda det utvecklingsverktyg som implementeraren jobbar i för att utföra testningen. T ex IDEA eller någon liknande utvecklingsmiljö. Det behövs även en kompilator för java (javac) och en virtuell maskin för java (JVM) för att köra applikationen. Versionen av Java måste vara minst 1.5. Dokument: Enhetstestplan Checklista och protokoll för enhetstest 3.5 Testmetod En checklista kommer att användas (se Bilaga A) för att kontrollera koden. De flesta punkter på listan är naturliga att tänka på under all slags implementation där man vill uppnå kod av hög kvalitet. Att följa listan bör därför inte orsaka problem eller ta onödig tid för programmeraren. Implementerarna kommer att använda sig av ett etablerat utvecklingsverktyg, en så kallad Integrated Development Environment (IDE). I ett sådant verktyg Kapitel 3: Enhetstestplan 7
sker det mesta av enhetstestningen per automatik. Parameterantal och typ kontrolleras och många punkter på enhetschecklistan täcks också in. 3.6 Genomförande 3.6.1 Kriterier för att få påbörja enhetstest Implementeraren skall vara väl bekant med Programmeringshandboken [Rasmussen, 2005] och ha både den och checklistan för enhetstest (se Bilaga A) till hands under hela implementationsarbetet. 3.6.2 Testprocedur Implementeraren följer alla standarder och konventioner som anges i Programmeringshandboken [Rasmussen, 2005]. Vid jämna mellanrum (t ex när ett visst kodstycke, så som en funktion eller en klass, är klart) utför implementeraren kompilering av koden och rättar direkt fel som rapporteras av kompilatorn. Implementeraren går igenom checklistan för enhetstest (se Bilaga A) punkt för punkt och rättar eventuella fel som då upptäcks. När implementeraren är nöjd med enhetstestet av hela kodstycket (klassen) markerar denne detta med en kommentar i koden ( //Enhetstestat YY-MM-DD ) och meddelar utvärderaren. Implementeraren lämnar även eventuella övriga synpunkter angående enhetstestningen till utvärderaren. 3.7 Kriterier för ett lyckat test För att ett enhetstest skall anses vara lyckat skall implementeraren till sin bästa förmåga ha följt testproceduren och markerat koden som enhetstestad. 3.8 Uppföljning Testsamordnaren noterar vilka delar av koden som är enhetstestade och så fort en hel modul är fullständigt enhetstestad markeras den redo för modultest. 3.9 Täckning De utvecklingsverktyg som kommer att användas, tillsammans med implementerarnas tidigare erfaranhet av Java bör innebära att enhetstestningen kommer att täcka kravet på högkvalitativ kod med så få fel som möjligt väl. 3.10 Prioritering Varje implementerare kommer att prioritera den automatiska enhetstestningen som utvecklingsverktyget tillåter. Vid tidsbrist kommer manuell genomgång av koden med hjälp av checklista att prioriteras ned. 8 Kapitel 3: Enhetstestplan
4 Modultestplan I denna fas testas de enskilda modulerna var för sig. En modul bör modultestas så snart den är färdigställd och enhetstestad. Ett skäl till detta är att den person som har tagit fram den har uppfattningen om hur den är byggd färskt i huvudet och snabbt kan åtgärda eventuella fel. Ett annat är att arbetet med att testa delsystem som modulen används i skall kunna inledas så tidigt som möjligt. 4.1 Syfte Syftet med modultesterna är att upptäcka fel i de enskilda modulernas inre funktionalitet och verifiera att designspecifikationen har följts. 4.2 Ansvar Testsamordnare - TEST Testkonstruktör - DES, TEST Testare - DOK, SYS Utvärderare - TEST, KVAL 4.3 Tidsplan Tabellen nedan beskriver hur mycket tid respektive projektmedlem beräknas lägga på varje modultestmoment. Aktivitet Person Tid KVAL DES TEST DOK SYS Skriva testskript och hjälpmedel 10 7 17 Genomförande. 5 5 10 Utvärdering 2 5 7 Summa 2 10 12 5 5 34 Tabell 1: Tidsplanering för modultestmoment 4.4 Utrustning, verktyg och dokument Här anges den utrustning, verktyg och de dokument som behövs för att genomföra modulstestet. Utrustning och verktyg: För att genomföra modultesten behövs en kompilator för java (javac) och en virtuell maskin för java (JVM) för att köra applikationen. Java måste vara av minst version 1.5. Testaren kan också behöva tillgång till valfritt verktyg för att ändra i källkoden på de testprogram som används. Detta verktyg kan t.ex. vara Idea, Emacs eller valfri texteditor. Modulen som skall testas Kapitel 4: Modultestplan 9
Drivrutiner och stubbar Dokument: Modultestplan Modultestspecifikation Modultestskript Modultestprotokoll Felrapporter 4.5 Testmetod 4.5.1 Svartlådetest I ett svartlådetest behandlar man modulen som en svart låda, vars inre struktur är okänd. Man tar inte hänsyn till vad som sker inuti modulen utan testar bara hur väl given indata resulterar i önskad utdata. Metoden för att välja ut sådana testdata grundar sig på designspecifikationen. Så mycket som möjligt av mått, gränser och tillåtna data skall testas. Detta gäller även helt ologiska data, ett s k idiottest, där man matar in vad som helst. Då fel tenderar att oftast uppstå vid gränserna för indatans domäner bör man testa dessa gränser extra noga. Detta är något som testkonstruktören och testaren skall vara medvetna om vid konstruktion och testning. 4.5.2 Motivering Eftersom de moduler som ingår i STUM-systemet är relativt enkla i både design och implementation bedöms detta vara den lämpligaste testmetoden. Att vitlådetesta en eller ett par moduler vore eventuellt möjligt men STUMsystemet anses inte ha några kritiska moduler. Alla moduler måste fungera korrekt för att man skall få någon meningsfull funktionalitet ur systemet och att vitlådetesta alla moduler bedöms vara för tidskrävande. Eftersom programspråket Java används i utvecklingen anses detta minska kravet på vitlådetest ytterligare. Javaprogram körs i en s k sandlåda och även om ett fel som inte påvisas av svartlådetestet lever kvar i systemet bör det inte orsaka några större problem för användaren. Den enhetstestning som sker innan modultestet anses alltså vara tillräcklig för att eliminera behovet av extra kodgranskning. Enkla stubbar och testprogram kommer att konstrueras för att testa funktionaliteten hos de olika modulerna StumGUI, Synthesizer, DataBaseGUI, DataBase och StumVisualizer, se Designspecifikation [Millving, 2005]. 4.6 Genomförande 4.6.1 Kriterier för att få påbörja modultest Modulen i fråga måste vara klar och markerad som enhetstestad. Testskript med eventuell motsvarande stub eller testprogram skall vara färdigställt och tillgängligt. Detta ansvarar testkonstruktören för. Testspecifikation, testskript, testprotokoll (se Bilaga B) och felrapport (se Bilaga C) skall vara tillgängliga. 10 Kapitel 4: Modultestplan
4.6.2 Testprocedur Testaren får aktuell modul från implementeraren och utför testet utifrån testfall och testskript. Utfallet av dessa dokumenteras i en testrapport och eventuell felrapport som testsutvärderaren får ta ställning till. 4.7 Kriterier för ett lyckat test För att modultestet skall anses vara lyckat för en hel modul skall en genomkörning av alla testfall ge förväntat resultat. För att ett specifikt testfall skall anses vara lyckat skall testresultatet motsvara förväntat resultat enligt testfallsspecifikationen. 4.8 Uppföljning Alla testprotokoll som genereras skall sparas för att man senare skall kunna gå tillbaka till dem. Fel som upptäcks skall rapporteras till respektive implementerare och rättas. Utvärderaren tar beslut om nya tester skall planeras in. Om så är fallet upprepas testproceduren för modultest. När alla upptäckta fel korrigerats markerar utvärderaren modulen som testad och således redo för integrationstest. Utöver ovanstående skall vissa typer av moduler speciellt uppmärksammas: - Moduler som testas mycket mer än genomsnittet. En eventuell omdesign av modulen bör i så fall övervägas. - Moduler som blivit godkända efter relativt få test. Skapandet av fler testfall bör i så fall övervägas. 4.9 Täckning De flesta STUM-moduler är enkla och fungerar på det sättet att viss indata resulterar i viss motsvarande utdata. Modulerna kommer att testas med dels korrekt indata och dels felaktig sådan och detta anses täcka kravet på deras funktionalitet och stabilitet väl. Vissa delar av modulerna kommer möjligen inte att kunna testas. Exempelvis de bitar som innehåller felhantering av fel som är svåra att generera genom testprogram. Vitlådetest av dessa kodstycken vore möjligen på sin plats men projektgruppen anser att detta inte är nödvändigt eftersom de flesta moduler implementeras i grupp, av två-tre personer samtidigt. Detta innebär att mycket implicit kodgranskning sker automatiskt. 4.10 Prioritering Testning av alla moduler förutom en, DataBaseGUI, kommer att prioriteras lika högt. Detta på grund av att alla moduler anses vara lika viktiga. Om någon modul ej fungerar korrekt innebär det att hela programmet blir oanvändbart. Vid tidsbrist kommer man eventuellt prioritera ner testningen av Data- BaseGUI, då kommunikation med databasen eventuellt kan skötas manuellt. Kapitel 4: Modultestplan 11
12 Kapitel 4: Modultestplan
5 Integrationstestplan I integrationstestet är målet att testa hur väl de olika modulerna fungerar tillsammans. Olika delsystem av moduler testas och dessa delsystem utökas tills dess att alla moduler omfattas. Testet kan påbörjas så snart ett flertal moduler som bildar ett delsystem är modultestade och godkända. 5.1 Syfte Syftet med integrationstesterna är att hitta fel i gränssnitten mellan de olika samverkande modulerna. 5.2 Ansvar Testsamordnare - TEST Testkonstruktör - DES, TEST Testare - IMP, TEST Utvärderare - TEST, IMP, KVAL 5.3 Tidsplan Tabellen nedan beskriver hur mycket tid respektive projektmedlem beräknas lägga på varje integrationstestmoment. Aktivitet Person Tid KVAL DES IMP TEST Skriva testskript och hjälpmedel 5 5 10 Genomförande. 2 4 6 Utvärdering 2 3 1 6 Summa 2 5 5 10 22 Tabell 2: Tidsplanering för integrationstestmoment 5.4 Utrustning, verktyg och dokument Här anges den utrustning, verktyg och de dokument som behövs för att genomföra integrationstest. Utrustning och verktyg: För att utföra integrationstest behöver testaren en virtuell maskin för java (JVM) för att köra applikationen samt i förekommande fall en korrekt installerad version av databasverktyget Derby. Java måste minst vara av version 1.5. Berörda moduler Testdata Dokument: Kapitel 5: Integrationstestplan 13
Integrationstestplan Integrationstestspecifikation Integrationstestskript Integrationtestprotokoll Felrapporter. 5.5 Testmetod 5.5.1 Funktionell testning Vid funktionell testning används samma strategi som vid svartlådetest för moduler. Testen tar inte hänsyn till delsystemens inre logik utan koncentrerar sig på att given indata ger förväntad utdata. Därmed kommer testfallen i integrationstestet likna de i modultestet. 5.5.2 Sandwich-test Denna testmetod är en kombination av top-down- och bottom-up-metoderna. Top-down innebär att man testar de olika modulerna uppifrån i programstrukturen och bottom-up är motsatsen, där man testar de nedersta modulerna först. Fördelen med att välja sandwich-metoden jämfört med t ex top-down är att mer testarbete kan utföras parallellt. Om t ex de två olika STUM-modulerna DataBase och DataBaseGUI blir klara kan de testas direkt, utan att exempelvis StumGUI (som ligger i toppen av systemhierarkin, se Designspecifikation [Millving, 2005]) måste vara klar. För mer information om sandwich-metoden se RUT 12.5 [Nilsson, 2003]. 5.5.3 Motivering Valet av testmetod baseras alltså främst på att denna metod ger oss möjlighet att påbörja integrationstestning utifrån vilka moduler som blir klara först. Denna information finns inte på förhand då man planerat att utföra allt implementationsarbete parallellt. Eftersom modulerna i STUM-systemet har relativt enkla, väldefinerade gränssnitt anses ovanstående testmetod vara lämplig för integrationstest. STUMmodulerna hänger ihop i en enkel serie där varje modul måste fungera korrekt för att man skall få någon meningsfull funktionalitet hos det slutliga programmet. Varje modul är alltså lika viktig eftersom systemet behandlar en begränsad mängd data och gör det mer eller mindre enligt en löpande band - princip. Med det menas att viss indata (t ex ett uppmärkt ord) bearbetas på ett visst sätt i en modul och skickas vidare, endast framåt, till nästa modul. Viss indata resulterar alltid i motsvarande utdata i ett 1:1-förhållande. Detta bör innebära att ett noggrant genomfört modultest, där modulerna visats göra sin del korrekt, kommer leda till ett smärtfritt integrationstest. 5.6 Genomförande 5.6.1 Kriterier för att få påbörja integrationstest Modultesterna för berörda moduler skall vara genomförda och godkända. Alla eventuella fel som hittills upptäckts i systemet och i dokumentationen skall vara korrigerade. 14 Kapitel 5: Integrationstestplan
Testskript skall vara skrivna utifrån testfallen (se kapitel 9) och eventuella stubbar och testprogram skall vara konstruerade. Dessa lämnas i samråd med testsamordnaren till testaren. Relevanta dokument såsom integrationstestplan, testfall, testskript, testprotokoll och felrapport skall vara tillgängliga. 5.6.2 Testprocedur Testaren får aktuella moduler från implementeraren och utför testet utifrån testfall och testskript. Utfallet av dessa dokumenteras i ett testprotokoll med tillhörande, eventuell felrapport som testutvärderaren får ta ställning till. Alla klasserna i systemet är starkt bundna till varandra, vilket medför att det är omöjligt att plocka ut några få klasser och integrera dessa innan alla klasser är klara. Klassen DataBase t.ex. är central för hela systemet eftersom inget annat kan fungera korrekt utan den. 5.7 Kriterier för ett lyckat test För att integrationstestet skall anses vara lyckat för ett antal moduler skall en genomkörning av alla testfall för dessa moduler ge förväntat resultat enligt testfallsspecifikationen. 5.8 Uppföljning Testprotokoll arkiveras för framtida referens. Om interaktionen mellan testobjekten inte fungerar som det är tänkt kontaktas implementerarna för ett möte där de interaktionsproblem som uppkommit kommer att analyseras och lösas. När alla moduler är integrationstestade tar testansvarig tillsammans med designansvarig beslut ifall det är dags att gå vidare till systemtest. 5.9 Täckning Integrationstesterna är inte helt täckande. Valet har gjorts att dela upp STUM i tre delsystem och testa de var för sig. Man hade behövt konstruera fler delsystem för att täcka in alla möjliga kopplingar mellan moduler. Ett mer täckande alternativ vore att exempelvis köra top-down-testning, där man verkligen testar varje modulgränssnitt stegvis. Gränssnitten mellan de tre olika delsystemen är å andra sidan väldigt enkla och ett antagande har gjorts att om eventuella integrationsproblem dyker upp då man sätter ihop ett helt system kommer det vara enklt att lokalisera dem. Man har alltså flyttat en del av integrationstestarbetet ut till systemtest. 5.10 Prioritering De integrationstest som utförs anses vara lika viktiga, förutom möjligen Data- Base mot DataBaseGUI-integrationen. Vid tidsbrist kan man eventuellt prioritera ner DataBaseGUI då kommunikationen med databasen kan skötas manuellt. De resterande modulerna och modulkopplningarna är alla lika viktiga för att man skall kunna få ut meningsfull funktionalitet ur det slutliga programmet. Kapitel 5: Integrationstestplan 15
16 Kapitel 5: Integrationstestplan
6 Systemtestplan Systemtest utförs när samtliga moduler anses vara färdiga och interaktionen mellan dessa fungerar på ett tillfredsställande sätt. 6.1 Syfte Systemtestet skall kontrollera att systemet överensstämmer med de funktionella och icke funktionella kraven (se Kravspecifikation [Sandström, 2005]). Detta för att försäkra sig om att systemet kommer klara det påföljande acceptanstestet. 6.2 Ansvar Testsamordnare - TEST Testkonstruktör - Testgruppen Testare - PL, KUND Utvärderare - TEST, KVAL, Projektgruppen 6.3 Tidsplan Tabellen nedan beskriver hur mycket tid respektive projektmedlem beräknas lägga på varje systemtestmoment. Aktivitet Person Tid PL KUND KVAL TEST Genomförande. 4 5 9 Utvärdering 2 5 7 Summa 4 5 2 5 16 Tabell 3: Tidsplanering för systemtestmoment 6.4 Utrustning, verktyg och dokument Här anges den utrustning, verktyg och de dokument som behövs för att genomföra systemstesten. Utrustning och verktyg: Java Version 1.5 Derby Det färdiga programmet Testdata i form av ljudfiler (wave) Dokument: Systemtestplan Systemtestspecifikation Systemtestskript Systemtestprotokoll Kapitel 6: Systemtestplan 17
Felrapporter 6.5 Testmetod Systemtestet är inte menat att verifiera att systemets funktionalitet under optimala omständigheter utan det skall även utsätta systemet för stress och felaktig indata i den utsträckning det är möjligt. Detta återspeglas av testfallen i kapitel 10. Det är upp till testarna att ta fram indata enligt detta mönster. 6.6 Genomförande 6.6.1 Kriterier för att få påbörja systemtest Integrationstest mellan alla systemets moduler skall vara slutfört och godkänt. Alla eventuella fel som hittills upptäckts i systemet och i dokumentationen skall vara korrigerade. Testskript skall vara skrivna utifrån testfallen i kapitel 10. Dessa lämnas i samråd med testsamordnaren till testaren. Relevanta dokument så som systemtestplan, testfall, testskript, testprotokoll och felrapport skall vara tillgängliga. 6.6.2 Testprocedur Testaren testar det kompletta STUM-systemet utifrån testfall och testskript. Utfallet av dessa dokumenteras i ett testprotokoll och eventuell felrapport. 6.7 Kriterier för ett lyckat test För att systemtestet skall anses vara lyckat skall en genomkörning av alla testfall ge förväntat resultat enligt testfallsspecifikationen (se kapitel 10). 6.8 Uppföljning När systemtestet utförts kallar testsamordnaren till ett testmöte. På testmötet skall alla projektmedlemmar medverka. Under mötet kommer resultatet av systemtestet att diskuteras. Beslut om eventuell förändring av testspecifikation och testskript kan tas under mötet. Särskilt bör följande frågor ställas: Var testfallen relevanta? Testades systemets alla funktioner? Testades alla krav i kravspecifikationen? Gemensamt beslut fattas huruvida systemet är redo för acceptanstest. 6.9 Täckning Alla funktionella krav som ställts på systemet kommer att testas och man kommer även att testa med så mycket felaktig indata som möjligt. Detta, tillsammans med den kompletterande stress- och prestandatestningen bör täcka kundens krav på systemet väl. 18 Kapitel 6: Systemtestplan
6.10 Prioritering Systemtestfallen kan delas upp i två delar, stresstest och funktionstest. Vid tidsbrist kommer man att prioritera ner stress- och prestandatestningen och fokusera på funktionell testning. Om ytterligare inskränkning är nödvändig kommer man att fokusera på endast funktionell testning med korrekt indata. Detta anses vara allra viktigast då STUM-systemet trots allt är ett experimentellt verktyg menat att vidareutvecklas. Därför kan man tänka sig att det inte har lika högt krav på stabilitet och felhantering som andra, för slutanvändare menade applikationer. Kapitel 6: Systemtestplan 19
20 Kapitel 6: Systemtestplan
7 Acceptanstestplan 7.1 Acceptanstest Acceptanstestet är kundens möjlighet att kontrollera att systemet uppfyller acceptansvillkoren som återfinns i projektets kravspecifikation. 7.1.1 Syfte Kunden skall få kontrollera att systemet uppfyller de önskemål och krav som kunden och projektgruppen kommit överens om i kravspecifikationen. 7.1.2 Ansvar Testsamordnare - TEST Testkonstruktör - TEST, KUND, SYS Testare - KUND, Kunden Utvärderare - TEST, Hela projektgruppen 7.2 Tidsplan Tabellen nedan beskriver hur mycket tid respektive projektmedlem beräknas lägga på varje systemtestmoment. Aktivitet Person Tid PL KUND KVAL TEST Genomförande. 5 5 Utvärdering 3 3 3 9 Summa 3 8 3 14 Tabell 4: Tidsplanering för acceptanstest 7.3 Utrustning, verktyg och dokument Här anges den utrustning, verktyg och de dokument som behövs för att genomföra acceptanstest. Utrustning och verktyg: PC med Windows XP och Java version 1.5 installerat Den färdiga versionen av STUM Testdata i databasen Dokument: Kravspecifikation Acceptanstestplan Acceptanstestspecifikation Acceptanstestskript Acceptanstestprotokoll Acceptansöverenskommelse Kapitel 7: Acceptanstestplan 21
Felrapporter. 7.4 Genomförande 7.4.1 Kriterier för att få genomföra ett acceptanstest Systemtestet skall vara avslutat och godkänt. Alla upptäckta och relevanta fel i dokument och programvara skall vara åtgärdade. Kunden skall ha getts möjlighet att förbereda egna testfall. Alla dokument som är nödvändiga för testet, så som eventuella testskript, skall vara färdigställda och tillgängliga. Eventuell nödvändig installation av systemet skall ha utförts. 7.4.2 Testprocedur Acceptanstestet enligt acceptanstestfallen i Kravspecifikationen [Sandström, 2005] kommer att utföras i samråd med kunden. Testansvarig och eventuella andra projektgruppmedlemmar kan närvara. Resultatet kommer att bokföras i ett testprotokoll. 7.5 Kriterier för ett lyckat test Kunden är nöjd och undertecknar acceptansöverenskommelsen, se Kravspecifikation [Sandström, 2005]. 7.6 Uppföljning Om kunden är nöjd och godkänner produkten undertecknas acceptansöverenskommelsen. Är kunden missnöjd kallar testsamordnaren till möte där beslut angående eventuella åtgärder tas. Ett nytt acceptanstest planeras in i samråd med kunden. 7.7 Täckning och prioritering Acceptanstestfallen anses täcka kundens krav på systemet väl. De kommer att gås igenom tillsammans med kunden ett efter ett. Om allvarliga problem uppstår kommer de testfall som testar bas-kraven att prioriteras över eventuella normal- och extrakravtestfall. 22 Kapitel 7: Acceptanstestplan
8 Modultestspecifikation 8.1 StumVisualizer 8.1.1 Modultest 1 - StumVisualizer Syfte: Testar att ljud och ansiktsrörelser kan spelas upp synkroniserat. Indata: phrase - Med ljuddata och ansiktsdata. Utförande: Använd metoden visualize. Testa helst med ett ord som innehåller tre eller fyra stavelser som indata. Prova med både korrekt och felaktig data. Förväntat resultat: Ljudet skall spelas upp samtidigt som ansiktet skall animeras. Det bör inte finnas en uppenbar tidskillnad mellan tal och munrörelser. Även om indatat inte är en korrekt ljuddata så skall den spelas upp som någon typ av brus. 8.2 Synthesizer 8.2.1 Modultest 2 - Synthesizer Syfte: Testar att ett ord som inte finns i databasen kan delas upp i stavelser. Indata: phrase - Med ett flerstavigt ord som inte finns i databasen. Utförande: Använd metoden synthesize samt en testkonstruktion i metoden som returnerar phrase-objekt istället för att skicka dem vidare. Förväntat resultat: Metoden skall returnera en array med phrase-objekt som korrekt representerar stavelser ur det ursprungliga ordet. 8.3 StumGUI 8.3.1 Modultest 3 - StumGUI Syfte: Testar att användargränssnittet fungerar tillfredställande och kan dela upp en textsträng i ord. Indata: Godtycklig mening med mer än ett ord, uppmärkt med korrekt syntax. Utförande: Starta STUM som vanligt, mata in text i fönstret och klicka på knappen som startar talsyntesen. Skapa en teststubb av synthesize som endast skriver ut det ord som skickas till den. Förväntat resultat: Varje ord i den inmatade meningen skall skrivas ut ett efter ett. 8.4 DataBaseGUI 8.4.1 Modultest 4 - DataBaseGUI Syfte: Testar att användargränssnittet kan hantera tillägg av nya fraser. Indata: Godtyckligt ord och tillhörande uppmärkning. Utförande: Starta STUM för databashantering, mata in text i fönstret avsett för tillägg av ny data och klicka på knappen för att lägga till. Använd en testkonstruktion som skriver ut den data som finns i Phrase-objektet som skapas av GUI:t. Kapitel 8: Modultestspecifikation 23
Prova att ge felaktig indata i framförallt textfältet för ljuddata. Förväntat resultat: Ett objekt av typen Phrase som korrekt representerar det ord som skall läggas till. GUIt skall säga ifrån om ljuddatafilen är felaktig eller inte existerar. 8.4.2 Modultest 5 - DataBaseGUI Syfte: Testar att användargränssnittet kan läsa in ljuddata och lägga till det i databasen. Indata: En ljudfil (i filformatet WAVE) för ett ord. Utförande: Starta STUM för databashantering, ange ljudfilens namn och sökväg, klicka på knappen för lägg till. Skapa en stub för DataBase:addSound- Data som endast kontrollerar att den får rätt indata. Förväntat resultat: Ett godkännande från addsounddata-stubben. 8.4.3 Modultest 6 - DataBaseGUI Syfte: Testar att användargränssnittet kan läsa in ansiktsdata och lägga till det i databasen. Indata: En fil med ansiktsdata för ett ord. Utförande: Starta STUM för databashantering, ange filens namn och sökväg, klicka på knappen för lägg till. Skapa en stub för DataBase:addFaceData som endast kontrollerar att den får rätt indata. Förväntat resultat: Ett godkännande från addfacedata-stubben. 8.4.4 Modultest 7 - DataBaseGUI Syfte: Testar att användargränssnittet kan lista alla resultat av en sökning. Indata: En söksträng som matchar fler än ett ord. Utförande: Starta STUM för databashantering, skriv in söksträngen och klicka på knappen för sök. Skapa stubbar för de funktioner som hanterar en sökning i DataBase. Det bör finnas flera ord som matchar sökningen helt och även delvis samt några ord som inte matchar sökningen alls. Förväntat resultat: En lista med ord som korrekt matchar söksträngen. 8.5 DataBase 8.5.1 Modultest 8 - DataBase Syfte: Testar att det går att lägga till data i databasen. Indata: phrase - med godtyckligt innehåll. Utförande: Använd metoden add och en testmetod som listar allt innehåll i databasen. Förväntat resultat: Data skall läggas till och representeras korrekt i databasen. Detta kan kontrolleras med Derbys databaskonsol. 8.5.2 Modultest 9 - DataBase Syfte: Testar att det går att ta bort data från databasen. Indata: ID-nummer för det data som skall tas bort. 24 Kapitel 8: Modultestspecifikation
Utförande: Kalla på remove och använd en testmetod som listar allt innehåll i databasen. Prova även att ange ett ID för ett objekt som inte existerar. Förväntat resultat: Data skall helt tas bort från databasen. Vid felaktigt IDnummer skall ett felmeddelande visas. 8.5.3 Modultest 10 - DataBase Syfte: Testar att det går att söka i databasen. Indata: En textsträng som skall matchas mot databasen. Utförande: Kalla på findtext och findmarking. Använd en testkonstruktion som skriver ut ID-numret för den data som hittas. Förväntat resultat: Korrekt matchning mellan sökt text och motsvarande IDnummer på eftersökt data. Kapitel 8: Modultestspecifikation 25
26 Kapitel 8: Modultestspecifikation
9 Integrationstestspecifikation 9.1 Databashantering Klasser i testet: DataBase och DataBasGUI. 9.1.1 Integrationstest 1 - DataBase, DataBaseGUI Syfte: Testar att det går att lägga till data till databasen genom användargränssnittet. Indata: Korrekt uppmärkta ord och stavelser, se kapitel 1.5, "Förklaring av begrepp", på sidan 2. Utförande: Starta STUM för databashantering och använd GUI:t för att skriva in data för ett nytt ord. Förväntat resultat: Databasen skall innehålla en korrekt representation av den data som läggs till. Alla strängar skall bevaras så som användaren skriver in dem. Det finns inget krav på att de måste vara riktigta ord eller liknande. 9.1.2 Integrationstest 2 - DataBase, DataBaseGUI Syfte: Testar att det går att ta bort data från databasen genom användargränssnittet. Indata: Ingen. Utförande: Använd användargränssnittet för att markera den data som skall tas bort och utför borttagningen. Förväntat resultat: Den valda frasen skall inte längre finnas i databasen. 9.2 GUI mot databasen Klasser i testet: StumGUI och Synthesizer. 9.2.1 Integrationstest 3 - StumGUI, Synthesizer Syfte: Testar att synthesizer kan anropa databasen med ljuddata för ett ord som matas in i användargränssnittet. Indata: En mening som består av ord och stavelser. Utförande: Starta STUM som vanligt och mata in textsträngen. Skapa en testkonstruktion i synthesize som skriver ut resultatet av databasaropet istället för att skicka data vidare till Processor. Förväntat resultat: En korrekt utskrift från synthesize. Synthesizer skall även kunna hantera indata som inte finns i databasen. 9.3 Visualisera Klasser i testet: Synthesizer, Processor och StumVisualizer. 9.3.1 Integrationstest 4 - Synthesizer, Processor, StumVisualizer Syfte: Testar att Synthesizer kan få ett ord visualiserat via Processor och Visualizer. Indata: phrase - Med korrekt ljuddata (wave-fil). Kapitel 9: Integrationstestspecifikation 27
Utförande: Kalla på consume från synthesize. Förväntat resultat: Frasen skall spelas upp i form av korrekt ljud. Om indatat inte är korrekt skall proces meddela detta på något sätt. 28 Kapitel 9: Integrationstestspecifikation
10 Systemtestspecifikation Alla acceptanstestfall i Kravspecifikationen [Sandström, 2005] kommer att utföras som del av systemtestet. Dessa testfall är utförliga och testar systemets funktionalitet i detalj. Utöver dessa kommer man att utföra nedanstående systemtestfall, designade för att testa systemet under annat än optimala förhållanden. 10.1 Systemtest 1 Syfte: Testa att systemet inte kräver orimligt höga systemresurser. Indata: En längre sekvens av uppmärkta ord. Utförande: Spela upp sekvensen och undersök minnes- och processoråtgången m h a task manager eller liknande. Förväntat resultat: STUM-systemet fungerar felfritt, utan hack eller avbrott i uppspelningen och utan att orimliga mängder minne, mer än 64 MB, och processorkraft, mer än 50 %, används. 10.2 Systemtest 2 Syfte: Testa att systemet inte läcker minne och är stabilt. Indata: En större mängd ord och fraser för uppspelning. Utförande: Spela upp ett större antal ord eller meningar. Låt systemet stå igång en lång stund, exempelvis över natten, utan omstart. Förväntat resultat: Systemet använder inte märkbart mycket mer minne (mindre än 50 % ökning) efter längre användning och uppspelning av ljud och bild fungerar lika bra oberoende av hur länge systemet varit igång. 10.3 Systemtest 3 Syfte: Testa att det går att korrigera synkroniseringen mellan ljud och bild i systemet. Indata: En eller ett par fraser till databasen. Utförande: Spela upp fraser med olika värden på offset-parametern (se Designspecifikation [Millving, 2005]). Förväntat resultat: Man ser och hör tydligt att synkroniseringen har förskjutits eller korrigerats. Obs ej aktuellt för tillfället då kravet om ansiktsanimering utgår. 10.4 Systemtest 4 Syfte: Testa att systemet är robust och ej känsligt för avbrott. Indata: En sekvens av uppmärkta ord för uppspelning. Utförande: Spela upp en ljud- och bildsekvens men avbryt systemet mitt i genom att döda processen eller stänga av datorn. Utför också motsvarande under inmatning av data till databasen. Förväntat resultat: Systemet beter sig som förväntat vid nästa körning, utan att databasen blivit korrupt eller något annat oförutsett har skett. Kapitel 10: Systemtestspecifikation 29
30 Kapitel 10: Systemtestspecifikation
11 Referenser De externa dokument som används finns samtliga tillgängliga online på adressen http://www-und.ida.liu.se/~tddc02/hemligt/rut/aktuella-pdf/ De interna dokumenten finns tillgängliga på http://www-und.ida.liu.se/ ~pum1/ 11.1 Externa dokument [Sjanic, 2001] Sjanic, Zoran (2001), RUT - Utvecklingshandbok 11.1 Testprocedur v 3.2, (IDA) vid Linköpings universitet, Linköping. [Fällström, 2005] Fällström, Anders (2005), RUT - Development manual 11.2 Planning unit testing v4.0, (IDA) vid Linköpings universitet, Linköping. [Arvedahl, 2002] Arvedahl, Svante (2002), RUT - Development Handbook 12.1 Choice of Test Strategy v 6.0, (IDA) vid Linköpings universitet, Linköping. [Nilsson, 2003] Nilsson, Per (2003), RUT - development handbook 12.5 Testing according to the Sandwich method v 6.0-en, (IDA) vid Linköpings universitet, Linköping. [Andersson, 2005] Andersson, Karl (2005), RUT - development handbook 13.1 How to find test cases for the system test v2.0-en, (IDA) vid Linköpings universitet, Linköping. [Karlsson, 2005] Karlsson, David (2005), RUT - development tutorial 14.1 Acceptance test v 2.0, (IDA) vid Linköpings universitet, Linköping. 11.2 Interna dokument [Aghajani, 2005] Aghajani, Ali (2005), Projektplan, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Rasmussen, 2005] Rasmussen, Andreas (2005), Arkitekturspecifikation, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Millving, 2005] Millving, Johan (2005), Designspecifikation, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Rasmussen, 2005] Rasmussen, Andreas (2005), Programmeringhandbok, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. [Sandström, 2005] Sandström, Patrik (2005), Kravspecifikation, Institutionen för Datavetenskap vid Linköpings universitet, Linköping. Kapitel 11: Referenser 31
32 Kapitel 11: Referenser
Bilaga A Checklista för enhetstest Checklistan används för att kontrollera koden under implementationen. Vid behov kan den fyllas i punkt för punkt så att resultaten kan sammanställas och diskuteras med enhetstestsamordnare och utvärderare. Område Fel Beskrivning B Kommentar nr B = Bedömning = 1 (tar helt avstånd).. 5 (instämmer helt) Gränssnitt 001 Är antalet indataparametrar korrekt? 002 Är indataparametrarna i rätt ordning? 003 Är indataparametrarna av korrekt typ? 004 Sker kontroll av att indata ligger i rätt domän? 005 Ges ett felmeddelande vid felaktiga indata? 006 Används alla indataparametrar någonstans i modulen? 007 Tilldelas alla utdataparametrar värden i modulen? 008 Är alla anrop till andra moduler korrekta med avseende på parametrarnas antal, ordning och typ? Variabler 101 Förblir input only -variabler oförändrade? 102 Är användandet av globala variabler konsistent med designen? 103 Används alla deklarerade variabler? 104 Är variabelnamnen vettiga och informativa? 105 Är variablernas defaultvärden korrekta? 106 Sker tester för under- och overflow vid användande av datastrukturer där detta är relevant? Filhantering 201 Öppnas filerna innan de används? 202 Stängs filerna efter användning? 203 Är öppna/stäng-instruktionerna korrekta? 204 Tas hänsyn till end-of-file vid läsning från fil? 205 Finns felhantering för I/O-fel vid filhantering? Felhantering 301 Finns tillräcklig felhantering? 302 Ger felmeddelanden tillräcklig information om felen? Övrigt 401 Överensstämmer implementationen av modulen med designen? 402 Finns det tillräckligt med kommentarer i koden? Tabell: Checklista för enhetstest Bilaga A : Checklista för enhetstest 33
34 Bilaga A : Checklista för enhetstest
Bilaga B Testprotokoll Modul/moduler: Testare: Testdatum: Testomgång nr: Tidsåtgång: Antal fel: Testfall Utfall Kommentar Felrapport Typ-Nr Godkänd/ Påpekande/ Lätt fel/ Svårt fel. Kort om resultatet. Referens till eventuell felrapport. Tabell 5: Testprotokoll Bilaga B : Testprotokoll 35
36 Bilaga B : Testprotokoll
Bilaga C Felrapport Datum: Feltyp Påpekande Lätt Svårt Felrapport nr: Utfärdad av: Fil: Kodversion: Felbeskrivning: Kommentar av den som åtgärdat felet: Åtgärdas av: senast: utfört (datum, signatur): Omtestas av: senast: utfört (datum, signatur): Tidsåtgång för rättning: Tabell 6: Felrapport Bilaga C : Felrapport 37
38 Bilaga C : Felrapport
Bilaga D Testskript Detta är ett generellt exempel på hur testkonstruktören kan utforma ett testskript. Modul Stubbar/drivrutiner: Åtgärder före test: Modulfiler Utförande Åtgärder vid lyckat test: Åtgärder vid misslyckat test: Tabell 7: Testskript Bilaga D : Testskript 39
40 Bilaga D : Testskript