Testresultat. Sammanfattning. Redaktör: Thomas Janowski Version: I Tal-Lab kan ingen höra dig skrika

Transkript

1 Testresultat Redaktör: Version: 1.0 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 innehåller en utvärdering av testningen av STUM-systemet. Dokumentet innehåller testrapporter för de olika testfaserna enhetstest, modultest, integrationstest, systemtest och acceptanstest. Det innehåller även testskript, testprotokoll och felrapporter.

2 I Tal-Lab kan ingen höra dig skrika

3 Projektidentitet Projektgrupp STUM (IDA) Projektmedlemmar Namn Ansvarsområde Telefon E-post Ali Aghajani Projektledare Kjell Enblom Dokumentansvarig Filip Klasson Kvalitetsansvarig Johan Millving Designansvarig Andreas Rasmussen Implementationsansvarig Gustav Veide Systemansvarig Patrik Sandström Kundansvarig Testansvarig E-postlista för hela gruppen Hemsida www-und.ida.liu.se/~pum1 Kund Kundkontakt Bertil Lyberg, Mustapha Skhiri, Handledare Sten Sunnergren, Examinator och kursansvarig Robert Kaminski, IDA

4 Dokumenthistorik Version Datum Utfärdade ändringar Utfärdade av Dokumentet skapades Dokumentet uppdaterat efter kommentering. Främst uppdaterat stavfel. 1.0 Dokumentet uppdaterat efter inspektion. Uppdaterat stavfel och layoutfel. iii

5 1 Inledning Syfte Läsanvisningar Dokumentöversikt Dokumentberoende Förklaring av begrepp Övergripande utvärdering Utförande Testspecifikation Tidsåtgång Testresultat Vanliga fel och diskussion av testresultat Tillräcklighet Enhetstestrapport Utförande Testmetod Testresultat Vanliga fel Tillräcklighet Modultestrapport Utförande Testmetod Tidsåtgång Testresultat Tillräcklighet Integrationstestrapport Utförande Testmetod Tidsåtgång Testresultat Tillräcklighet Systemtestrapport Utförande Testmetod Tidsåtgång Testresultat Vanliga fel Tillräcklighet Acceptanstestrapport Utförande Testmetod Tidsåtgång Testresultat Tillräcklighet Referenser iv

6 8.1 Interna dokument Bilaga A Modultestskript A.1 Modultest 1 - Visualizer A.2 Modultest 2 - Synthesizer A.3 Modultest 3 - StumGUI A.4 Modultest 4, 5, 6 - DataBaseGUI A.5 Modultest 7 - DataBaseGUI A.6 Modultest 8 - DataBase A.7 Modultest 9 - DataBase A.8 Modultest 10 - DataBase Bilaga B Modultestprotokol B.1 Testomgång B.1.1 Modultest 1 till B.1.2 Modultest 4 till B.2 Testomgång B.2.1 Modultest Bilaga C Felrapport för modultest C.1 Felrapport MT-1a Bilaga D Integrationstestskript D.1 Integrationstest 1 - DataBase, DataBaseGUI D.2 Integrationstest 2 - DataBase, DataBaseGUI D.3 Integrationstest 3 - StumGUI, Synthesizer D.4 Integrationstest 4 - Synthesizer, Processor, Visualizer Bilaga E Integrationstestprotokoll E.1 Testomgång E.1.1 Integrationstest 1 till E.2 Testomgång E.2.1 Integrationstest E.2.2 Integrationstest Bilaga F Felrapport för integrationstest F.1 Felrapport IT-2a Felrapport IT-3a Bilaga G Systemtestskript G.1 Systemtest G.2 Systemtest G.3 Systemtest G.4 Systemtest Bilaga H Systemtestprotokoll H.1 Testomgång H.1.1 Systemtest 1 till H.1.2 Systemtest 5 till H.1.3 Systemtest 11 till H.1.4 Systemtest 14 till H.2 Testomgång H.2.1 Systemtest 1, 2, H.2.2 Systemtest 6, 8, H.3 Testomgång v

7 H.3.1 Systemtest Bilaga I Felrapport för systemtest I.1 Felrapport ST-1a I.2 Felrapport ST-1b I.3 Felrapport ST-6a I.4 Felrapport ST-8a I.5 Felrapport ST-17a Bilaga J Acceptanstestskript J.1 Acceptanstest 1 (Systemtest 5) J.2 Acceptanstest 2 (Systemtest 6) J.3 Acceptanstest 3 (Systemtest 7) J.4 Acceptanstest 4 (Systemtest 8) J.5 Acceptanstest 5 (Systemtest 9) J.6 Acceptanstest 6 (Systemtest 10) J.7 Acceptanstest 7 (Systemtest 11) J.8 Acceptanstest 8 (Systemtest 12) J.9 Acceptanstest 9 (Systemtest 13) J.10 Acceptanstest 10 (Systemtest 14) J.11 Acceptanstest 11 (Systemtest 15) J.12 Acceptanstest 12 (Systemtest 16) J.13 Acceptanstest 13 (Systemtest 17) J.14 Acceptanstest 14 (Systemtest 18) J.15 Acceptanstest 15 (Systemtest 19) Bilaga K Acceptanstestprotokoll Bilaga L Felrapport för acceptanstest...67 vi

8 vii

9 1 Inledning Detta kapitel beskriver dokumentets upplägg och innehåll. 1.1 Syfte Syftet med testresultat är att sammanställa och utvärdera testningen av STUM-systemet. Utifrån dokumentet skall man kunna dra slutsatser om hur testarbetet har gått och hur väl produkten är testad. 1.2 Läsanvisningar Dokumentet bygger på Testplan [Janowski, 2005] och för att få en fullständig bild av testarbetet bör dokumenten läsas tillsammans. För att få en övergripande bild av testarbetet bör kapitel 2 läsas. För att få en detaljerad bild av de olika testfaserna bör de enskilda testrapporterna i kapitel 3 till 7 läsas. I slutet av dokumentet finns bilagor som innehåller samtliga testskript, testprotokoll och felrapporter som framtagits under testarbetets gång. Det är dessa som ligger till grund för själva utvärderingen och bedömningen av testarbetet. 1.3 Dokumentöversikt 1. Inledning Detta kapitel beskriver i generella drag dokumentets upplägg och innehåll. 2. Övergripande utvärdering Ger en översiktlig utvärdering av det utförda testarbetet. 3. Enhetstestrapport Innehåller utvärdering av enhetstest. 4. Modultestrapport Innehåller utvärdering av modultest. 5. Integrationstestrapport Innehåller utvärdering av integrationstest. 6. Systemtestrapport Innehåller utvärdering av systemtest. 7. Acceptanstestrapport Innehåller utvärdering av acceptanstest. 8. Referenser En lista över använda referenser. Kapitel 1: Inledning 1

10 Bilaga A - Modultestskript Innehåller modultestskript. Bilaga B - Modultestprotokoll. Innehåller de protokoll som togs fram under modultest. Bilaga C - Felrapport för modultest Innehåller felrapporter som utfärdades för modultest. Bilaga D - Integrationstestskript Innehåller integrationstestskript. Bilaga E - Integrationstestprotokoll Innehåller de protokoll som togs fram under integrationstest. Bilaga F - Felrapporter för integrationstest Innehåller felrapporter som utfärdades för integrationstest. Bilaga G - Systemtestskript Innehåller systemtestskript. Bilaga H - Systemtestprotokoll Innehåller de protokoll som togs fram under systemtest. Bilaga I - Felrapporter för systemtest Innehåller de felrapporter som utfärdades för systemtest. Bilaga J - Acceptanstestskript Innehåller acceptanstestskript. Bilaga K - Acceptanstestprotokoll Innehåller protokoll som togs fram under acceptanstest. Bilaga L - Felrapport för acceptanstest Innehåller de felrapporter som utfärdades under acceptanstest. 2 Kapitel 1: Inledning

11 1.4 Dokumentberoende Dokument som påverkar Testresultat: Testplan [Janowski, 2005]. Kravspecifikation [Sandström, 2005]. Dokument som påverkas av Testresultat: Systemförvaltning [Enblom, 2005]. 1.5 Förklaring av begrepp Här förklaras en del begrepp som förekommer i dokumentet. IDA Bitdata IDEA Uppmärkning vid Linköpings universitet. IDA tillhandhåller datorer och utrustning som används under testarbetet. Bitdata representerar godtycklig data i binärformat. Detta kan användas för att exempelvis testa lagringsrutiner i en databas. IntelliJIDEA är ett utvecklingsverktyg för programspråket Java. För ytterligare information se: 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

12 4 Kapitel 1: Inledning

13 2 Övergripande utvärdering I detta kapitel ges en översiktligt utvärdering av testningen av STUM-systemet. 2.1 Utförande Testningen har, i den utstäckning det varit möjligt, utförts enligt Testplanen [Janowski, 2005]. Tidsplaneringen har inte kunnat följas speciellt bra, främst på grund av förseningar i implementationen. För en mer specifik beskrivning av varje testfas, se de enskilda testrapporterna. 2.2 Testspecifikation Testspecifikationen har följts väl. Även om vissa testfall var aningen breda eller vagt definerade var det i princip inga problem att testa utifrån dem. Inte heller uppstod några missförstånd om vad det förväntade resultatet skulle vara. 2.3 Tidsåtgång Tidsplaneringen i Testplanen [Janowski, 2005] har inte följts speciellt bra. Dels påbörjades testningen senare än beräknat och dels lades inte lika mycket tid som det var tänkt på respektive testmoment. Detta beror främst på att implementationsarbetet blev försenat. Vissa missbedömningar gjordes också angående hur lång tid testkonstruktion och testutförande skulle ta. Under alla testmoment gick mer tid åt testkonstruktion än planerat, medan själva testningen, inklusive ett antal omtester, gick snabbare än väntat. För en mer detaljerad tidsåtgång för de specifika testfaserna, se respektive testrapport i nästföljande kapitel. I tabellen nedan återfinns en jämförelse mellan beräknad och verklig tidsåtgång under de olika testfaserna. Testfas Beräknad tid Utfall Modultest Integrationstest Systemtest Acceptanstest Summa: Tabell 1: Tidsåtgång 2.4 Testresultat Relativt få fel upptäcktes under testarbetet. Detta skulle dels kunna bero på att STUM-systemet är relativt litet och dels på att mycket testarbete utfördes Kapitel 2: Övergripande utvärdering 5

14 implicit, av implementerarna själva, innan modulerna lämnades vidare för formell testning. I tabellen återfinns alla fel som upptäckts. Testfas Antal Modultest 1 Integrationstest 2 Systemtest 7 Acceptanstest 0 Summa 10 Tabell 2: Testresultat 2.5 Vanliga fel och diskussion av testresultat Eftersom projektgruppen saknade erfarenhet av formellt testarbete var det svårt att avgöra var implementation slutar och testning börjar. Detta ledde till att ingen implementerare lämnade ifrån sig en modul som denne självintetestat utförligt, vilket också återspeglas av antalet upptäckta fel i de enskilda modulerna. De flesta implementerare skrev t ex egna stubbar och testprogram och kontrollerade sina respektive moduler noggrant. Detta gjordes utöver det enhetstest som egentligen var allt de var menade att utföra. Det är troligen detta som lett till att det formella testarbetet inte kunnat inledas i tid. Å andra sidan gick det väldigt snabbt att testa när man väl kom igång. Med ett så litet antal fel är det svårt att säga exakt vilka fel som var vanligast och vad det berodde på. Dock kan man konstatera att de flesta felen uppstod först när systemet satts ihop till ett färdigt program och att de ej var av funktionell karaktär. Detta kan bero på missförstånd mellan implementerarna eller otillräcklig precisering i designen. Integrationsfelen kunde rättas omdelebart och redan första dagen då integrationsarbetet inletts kunde man koppla ihop systemet till ett fullt fungerande program, som kunde spela upp tal. 2.6 Tillräcklighet Alla funktionalitetskrav som ställts på STUM-systemet har testats. Man har även testat med felaktig indata och stresstestat programmet i den mån det har varit möjligt. Projektgruppen anser sig ha utvecklat ett stabilt system, som uppfyller de grundläggande kraven väl. Det man möjligen kunnat lägga ner mer tid på är att testa uppförandet hos de grafiska gränssnitten. Dock har man medvetet valt att hålla dem så grundläggande som möjligt, eftersom sådant arbete är mycket krävande ur både implementations- och testsynpunkt. Detta bedömdes inte vara realiserbart på utsatt tid. 6 Kapitel 2: Övergripande utvärdering

15 3 Enhetstestrapport Detta kapitel beskriver hur enhetstestningen av STUM-systemet har gått. Denna typ av testning har utförts av implementerarna själva och saknar egen tidsplanering eller specifika testfall. 3.1 Utförande Testningen utfördes av respektive modulimplementerare, främst med hjälp utvecklingsverktyget IDEA, kompletterat av checklistan för enhetstest. Regelbunden kompilering och visuell genomgång av den egna koden utfördes av alla implementerare. 3.2 Testmetod Testmetoden bestod främst i att låta de inbyggda verktygen i utvecklingsmiljön (IDEA) hitta fel. Saker som parameterantal eller datatyper kontrollerades automatiskt. Detta kompletterades med en översiktlig kodgranskning som varje implementerare utförde innan denne lämnade vidare modulen för modultest. 3.3 Testresultat Enhetstestningen har varit en naturlig del av implementationen och det har inte funnits behov av att rapportera eller utvärdera något speciellt. 3.4 Vanliga fel Alla fel som upptäcks av utvecklingsverktyget stryks under i koden och rättas oftast direkt av implementeraren. Det är därför varken realistiskt eller relevant att utvärdera deras typ eller frekvens. 3.5 Tillräcklighet Projektgruppen är nöjda med enhetstestningen och tycker att IDEA varit till stor hjälp under utvecklingen. Programspråket Java ger naturligt oftast relativt felfri och robust kod, jämfört med exempelvis C. Det har ej ansetts vara nödvändigt att testa eller utvärdera noggrannare under denna fas. Kapitel 3: Enhetstestrapport 7

16 8 Kapitel 3: Enhetstestrapport

17 4 Modultestrapport Detta kapitel innehåller en utvärdering av den genomförda modultestningen. 4.1 Utförande All modultestning har utfört enligt testplanen, utifrån de testfall som finns i testspecifikationen. De testskript, testprotokoll och felrapporter som genererades återfinns i Bilaga A, B och C. Ett antal testprogram och stubbar skrevs av testkonstruktörerna. Detta arbete var den överlägset mest krävande delen av modultestningen. Testkonstruktörerna fick ofta gå tillbaka till designen och även rådfråga implementerarna för att få ihop fungerande testskript och testprogram. Själva testningen gick snabbt och smärtfritt och endast ett fel påträffades. 4.2 Testmetod Endast svartlådetest användes under modultestningen. Detta var för att man fäste stor tillit vid implementerarnas och enhetstestningens förmåga att upptäcka icke-funktionella fel. Ingen kritisk modul kunde identiferas och att kodgranska alla moduler skulle ta alldeles för lång tid. Alla moduler i STUM-systemet fungerar på det sättet att viss indata bör generera viss specifik utdata. Så länge denna data genereras korrekt under testning och felaktig indata inte ger oväntat uppförande hos modulen anses svartlådetest vara en tillräcklig modultestmetod. 4.3 Tidsåtgång På grund av tidsbrist och krockar med andra delar av projektarbetet fick PL och TEST helt ta över testutförande från SYS och DOK. I tabellen nedan finns en redovising av hur lång tid modultestarbetet tog. Den planerade tiden står i parentes. Aktivitet Person Tid KVAL DES TEST DOK PL Skriva testskript och hjälpmedel 12 (10) 12(7) 24 Genomförande. 1(0) 0(5) 1(5) 2 Utvärdering 1(2) 5(5) 6 Summa (34) Tabell 3: Tidsåtgång Som framgår av tabellen ovan tog modultestkonstruktion längre tid än planerat. Detta trots att man hade planerat rätt gott med tid redan från början. Själva Kapitel 4: Modultestrapport 9

18 testningen gick väldigt snabbt. Detta berodde troligen till stor del på att så få fel upptäcktes och att nån form av utförlig omtestning inte var aktuell. 4.4 Testresultat Endast ett fel påträffades och det felet var en missbedömning från implementerarnas sida på hur lång tid auto-detektering av ljudformat i realtid kan ta. Som redan nämnts i kapitel 2 så lade implementerarna mycket tid på att själva testa sina moduler noggrant innan de lämnades vidare för modultest. Detta återspeglas här av antalet fel som upptäckts. 4.5 Tillräcklighet Funktionaliteten hos modulerna har testats noggrant. Man kunde eventuellt ha lagt ner mer tid på att testa med felaktig indata, för att upptäcka eventuella buggar. Ytterligare alternativ vore att utföra vitlådetest på modulerna. Detta hade dock varit mycket tidskrävande då man i så fall bör ha testat alla moduler på detta sett, eftersom alla moduler anses vara lika viktiga. I efterhand inser man att man kunnat vitlådetesta utvalda delar av varje modul. Exempelvis felhantering eller kodbitar som inte nås eller körs under ett konstruerat test. Anledningen till att man ändå inte valt att göra detta är främst testgruppens begränsade erfarenhet av formell testning och av vilka testmetoder som är lämpliga. Man har istället litat på att implementerarna, som arbetade två eller tre samtidigt på varje modul skulle implicit hitta de fel som kunnat påvisats av ytterligare kodgranskning. 10 Kapitel 4: Modultestrapport

19 5 Integrationstestrapport Detta kapitel beskriver integrationstestningen av de olika STUM-modulerna. 5.1 Utförande All integrationstestning har genomförts enligt testplan för integrationstest i Testplanen [Janowski, 2005]. De testskript, testprotokoll och felrapporter som skrevs under integrationstest finns i Bilaga D, E och F. Integrationstesterna utfördes alla under ett och samma tillfälle och utan hänsyn till ordning. Då implementerarna fanns tillgängliga inleddes arbetet med att korrigera fel så fort de upptäckts. Detta ledde till att STUM-systemet var integrationstestat och ihopsatt till ett fungerande program på en och samma dag. 5.2 Testmetod Tanken var från början att integrationstesta STUM-systemet utifrån en enkel sandwich-metod. Anledningen till detta var att man skulle kunna börja integrationstesta delarna av systemet i godtycklig ordning, exempelvis i den ordning de blev klara. Detta hade inte varit möjligt om man begränsat sig till en top-down strategi. Modulerna blev dock alla klara i princip samtidigt, i slutet av implementationsvecka Tidsåtgång I tabellen nedan finns en redovising av hur lång tid integrationstestarbetet tog. Den planerade tiden står i parentes. Aktivitet Person Tid KVAL DES IMP TEST Skriva testskript och hjälpmedel 4(5) 10(5) 14 Genomförande. 2(2) 2(4) 4 Utvärdering 0(2) 1(3) 1(1) 2 Summa (22) Tabell 4: Tidsåtgång Återigen tog konstruktion av testskript och testprogram totalt sett längre tid än planerat, precis som under modultest. Själva integrationen av modulerna gick väldigt smidigt och STUM-systemet var redo för ett systemtest nästan direkt. 5.4 Testresultat Två fel upptäcktes under integrationstestningen. Det ena var ett enkelt syntaxfel som gick snabbt att korrigera då det väl lokaliserats. Det andra hade med Kapitel 5: Integrationstestrapport 11

20 borttagning av data ur databasen via DataBaseGUI att göra och åtgärdades först senare. Det hindrade dock inte att systemet kunde integreras helt och gå vidare till systemtest. 5.5 Tillräcklighet Precis som under modultest så har fokus lagts på rent fuktionell testning. Eftersom modulerna fungerade så pass bra under modultest var det väntat att integrationen skulle gå enkelt och smidigt, vilket den också gjorde. De test som utförts täcker tre huvuddelar av systemet. Man har ej specifikt integrationstestat kopplingen mellan delsystemen mot varandra utan detta har lämnats att utföras under systemtestning. Detta kan ha påverkat tillräckligheten av integrationstestet negativt. Denna avvägning har dock gjorts med tanke på att konstruktion av testprogram och stubbar för varje möjlig modulkoppling totalt sett skulle bli för utförligt för att realiseras på utsatt tid. 12 Kapitel 5: Integrationstestrapport

21 6 Systemtestrapport Detta kapitel beskriver och utvärderar den utförda systemtestningen av STUM-systemet. 6.1 Utförande All systemtestning har genomförts enligt testplan för systemtest i Testplanen [Janowski, 2005]. De testskript, testprotokoll och felrapporter som skrevs under systemtest finns i Bilaga G, H och I. Systemtestningen var den som påvisade flest fel och det var här testarna fick arbeta mest med att försöka lokalisera fel och skriva felrapporter. Systemtestningen var den enda testfas som gick vidare till en tredje testomgång, dvs att ett eller flera test fick köras om fler än två gånger. 6.2 Testmetod Testmetoden har varit dels rent funktionell testning efter testfallen i Kravspecifikationen [Sandström, 2005] och dels ett antal stress- och prestandatest. Detta har utförts i enighet med testspecifikationen. 6.3 Tidsåtgång I tabellen nedan finns en redovisning av hur lång tid systemtestarbetet tog. Den planerade tiden står i parentes. Aktivitet Person Tid PL KUND KVAL TEST Testkonstruktion 5(0) Genomförande 2(4) 3(5) 1(0) 7 Utvärdering 2(0) 0(2) 8(5) 10 Summa (16) Tabell 5: Tidsåtgång Som synes så tog den totala systemtestningen längre tid än planerat. Största skillnaden mot planen är att TEST fick gå in och hjälpa till med genomförandet av ett par test och PL hjälpte till med utvärdering istället för KVAL, som var upptagen med andra delar av projektet. Vi hade dessutom missat att ta med tid för testkonstruktion (framtagning av testskript) i testplanen. Själva utvärderingen av systemtestarbetet och sammanställningen av testdokument och testresultat tog också längre tid än väntat. Anledningen till att testarbetet tog längre tid än planerat är troligen dels det extra testkonstruktionsarbete som utfördes och dels en del administration och samordning som fick göras för att implementerarna skulle kunna korrigera felen. Kapitel 6: Systemtestrapport 13

22 6.4 Testresultat När testomgång ett av systemtest inletts stötte man genast på ett allvarligt fel och fick avbryta all systemtestning tills problemet var löst. Detta berodde på ett mindre missförstånd av designen, där DataBase använde en annan fysisk databas än resten av systemet och det ledde till att det var omöjligt att föra in testdata i databasen. Ytterligare fel som hittades berodde inte på felaktig integration och inte heller på att modulerna inte fungerade som de skulle. De berodde snarare på att man prioriterat ner visst implementationsarbete, exempelvis arbetet med att populera databasen med ljuddata. Man kan konstatera att valet av Java som programspråk, tillsammans med ett etablerat utvecklingsverktyg (IDEA) har underlättat testarbetet avsevärt. De fel som påträffats har varit lätta att lokalisera och åtgärda. 6.5 Vanliga fel De fel som påträffats var alla av typen svårt fel, förutom ett, som var ett påpekande. Då det totala antalet fel (sju stycken) ändå var relativt lågt är det svårt att uttala sig om vad som var vanligast. Möjligen kan man säga att felrapporteringen till användaren av STUM-systemet via GUI:t hade slarvats med en del. Å andra sidan hade man medvetet under implementationen prioriterat GUI-design lägre än grundläggande, inre funktionalitet så detta var inte helt oväntat. 6.6 Tillräcklighet De funktionella krav som ställts på systemet har testats noggrant och med positivt resultat. Detta har kompletterats av stress- och prestandatest och även med flera test med felaktig indata. Projektgruppen är nöjd med utfallet och anser att systemet är redo för acceptanstest. Det är svårt att utföra ytterligare systemtest då den funktionalitet som ingår i STUM-systemet trots allt är relativt begränsad och de test som utförts anses ha täckt in detta väl. 14 Kapitel 6: Systemtestrapport

23 7 Acceptanstestrapport Detta kapitel beskriver och utvärderar acceptanstestet som utfördes tillsamman och av kunden. 7.1 Utförande Acceptanstestet utfördes enligt testplan för acceptanstest i Testplanen [Janowski, 2005]. De testskript som användes finns i Bilaga J. Det fanns inte behov av att generera testprotokoll och felrapporter men bilagorna K och L finns med för fullständighets skull. Acceptanstestet bestod i att först låta kunden bekanta sig med systemet, vilket KUND, PL och TEST var närvarande vid. Sedan bad kunden, pga tidsbrist från hans sida, att få testa systemet på egen hand. Detta gjorde kunden vid ett senare tillfälle. Han gick igenom testfallen och godkände dem alla och skrev sedan på acceptansöverenskommelsen. 7.2 Testmetod Testmetoden bestod i att låta kunden gå igenom testfallen i Kravspecifikationen [Sandström, 2005], kompletterat med testskript ur Biaga J. 7.3 Tidsåtgång I tabellen nedan finns en redovisning av hur lång tid acceptansarbetet tog. Den planerade tiden står i parentes. Aktivitet Person Tid PL KUND DES TEST Testkonstruktion 4(0) 2(0) 6 Genomförande 1(0) 1(5) 1(0) 3 Utvärdering 0(3) 0(3) 2(3) 2 Summa (14) Tabell 6: Tidsåtgång Acceptanstestet gick snabbare än planerat, detta trots att man missat att ta med tid för testkonstruktion (framtagning av testskript) i testplanen. Vi insåg att det var bättre om fler än kundansvarig var närvarande vid acceptanstest och därför följde PL och TEST med. Det hela tog totalt en timme. Eftersom testet gick så snabbt att utföra och inte påvisade några fel behövdes endast två timmar för utvärdering, vilket TEST gjorde på egen hand. 7.4 Testresultat Resultatet av acceptanstestet var att samtliga krav blev godkända. Kunden var nöjd med systemet och skrev på acceptansöverenskommelsen. Kapitel 7: Acceptanstestrapport 15

24 7.5 Tillräcklighet En mindre delmängd av i övrigt identiska test som i systemtestet utfördes och godkändes. Kunden satt också och lekte med systemet en del, utan att hitta något att klaga på. Därför är det rimligt att anta att systemet är relativt bra testat, tillräckligt för kundens ändamål.. 16 Kapitel 7: Acceptanstestrapport

25 8 Referenser De interna dokumenten finns tillgängliga på ~pum1/ 8.1 Interna dokument [Janowski, 2005] Janowski, Thomas (2005), Testplan, 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 8: Referenser 17

26 18 Kapitel 8: Referenser

27 Bilaga A Modultestskript A.1 Modultest 1 - Visualizer Modul: Visualizer Modulfiler: Visualizer.java Stubbar/drivrutiner: TestVisualizer.java Åtgärder före test: Se till att ett antal wave-filer av varierande längd finns tillgängliga. Utförande: Kompilera TestVisualizer och Visualizer. Starta testprogrammet TestVisualizer med en wav-fil som parameter. Lyssna om ljudet spelas upp felfritt. Åtgärder vid lyckat test: Testa med flera ljudfiler av varierande längd. Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 19

28 A.2 Modultest 2 - Synthesizer Modul: Synthesizer Modulfiler: Synthesizer.java Stubbar/drivrutiner: TestSynthesizer.java Åtgärder före test: Kopiera kod från TestSynthesizer.java in i Synthesizer.java enligt kommentarer i TestSynthesizer.java. Utförande: Kompilera Synthesizer.java och TestSynthesizer.java. Starta testprogrammet. Synthesizer kommer nu försöka dela upp orden flickan, grader och datavetenskap. Kontrollera att testutskriften består av tre arrayer som består av de tre orden, korrekt uppdelade i stavelser. Åtgärder vid lyckat test: Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Notera specifikt vilket/vilka ord som ej gav korrekt uppdelning. Kontakta ansvarig implementerare och begär rättning av fel. 20

29 A.3 Modultest 3 - StumGUI Modul: StumGUI Modulfiler: StumGUI.java Stubbar/drivrutiner: StumGUIstart.java Åtgärder före test: Editera StumGUI.java genom att lägga till en spårutskrift i metoden start(), i första for-satsen: Lägg till System.out.println(markedwords[i]); och System.out.println(plainwords[i]);. Utförande: Kompilera StumGUIstart.java och StumGUI.java Starta StumGUIstart, mata in ett antal ord och uppmärkning i respektive textfält och klicka Starta talsyntes. Kontrollera att dina inmatade ord skrivs ut på skärmen ett och ett, i korrekt ordning. Åtgärder vid lyckat test: Testa med andra sekvenser av ord och uppmärkningar. Återställ StumGUI.java. Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Återställ StumGUI.java. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 21

30 A.4 Modultest 4, 5, 6 - DataBaseGUI På grund av omdesign av systemet måste dessa test utföras gemensamt. Modul: DataBaseGUI Modulfiler: DataBaseGUI.java Stubbar/drivrutiner: stum.java Åtgärder före test: Se till att ett antal testfiler (wav-filer eller godtycklig bitdata) finns tillgängliga i samma katalog som testprogrammet. Utförande: Starta databas-guit med kommandot./dbgui Skriv in godtyckligt ord och tillhörande uppmärkning. Ange sökväg till wavefilen. Klicka på Add Databas-guit ska svara med ett medelande om frasen har lagts till i databasen. Starta derbys console genom att köra scriptet dbconsole dom finns i cvsroten. Se till att du stängt ner stum innan. Kör kommandot connect jdbc:derby:stumdb ; i consolen. För att kontrollera vilket data det finns i databasen kör kommandot SELECT * FROM Phrase; För att kontrollera om phrase med en specifik märkning har lagt in i databasen använd kommandot SELECT * FROM Phrase WHERE marking= <märkning> ; Kontrollera att datat är tillagt. För att stänga dbconsole kör quit; Återupprepa testet på många olika typer av ord och märkningar. Åtgärder vid lyckat test: Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Försök lokalisera felet genom att prova med ett annat ord, annan uppmärkning eller en annan ljudfil. Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 22

31 A.5 Modultest 7 - DataBaseGUI Modul: DataBaseGUI Modulfiler: DataBaseGUI.java Stubbar/drivrutiner: stum.java Åtgärder före test: Se till att det finns ord i databasen med flera olika märkningar. Utförande: Kompilera stum med kommandot make i cvs-roten. Starta databas-guit med kommandot./dbgui Sök på ett ord som har flera olika märkningar. Kontrollera att listan som dyker upp i GUI:t visar flera uppmärkningar av orden. Åtgärder vid lyckat test: Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 23

32 A.6 Modultest 8 - DataBase Modul: DataBase Modulfiler: DataBase.java Stubbar/drivrutiner: dbtest_add.java Åtgärder före test: Skapa en testfil med en godtycklig data (t ex en textmening). Utförande: Kompilera stum med kommandot make. Skapa en testfil. Testfilens utseende ska se ut som följande: <text1> <märkning1> <ljudfil1> <text2> <märkning2> <ljudfil2> osv.. Starta testprogrammet med kommandot./dbtest_add <fil> Testprogrammet försöker lägga till allt data i textfilen. Kontrollera att utskriften från testprogrammet inte returnerar några felmeddelanden. Starta derbys console genom att köra scriptet dbconsole dom finns i cvsroten. Se till att du stängt ner stum innan. Kör kommandot connect jdbc:derby:stumdb ; i consolen. För att kontrollera vilket data det finns i databasen kör kommandot SELECT * FROM Phrase; För att kontrollera om phrase med en specifik märkning har lagt in i databasen använd kommandot SELECT * FROM Phrase WHERE marking= <märkning> ; Kontrollera att datat är tillagt. För att stänga dbconsole kör quit; Åtgärder vid lyckat test: Prova med ett antal andra/längre testfiler. Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Prova med en annan/kortare testfil. Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 24

33 A.7 Modultest 9 - DataBase Modul: DataBase Modulfiler: DataBase.java Stubbar/drivrutiner: dbtest_remove.java Åtgärder före test: Använd testskriptet beskrivet i modultest 8 för att lägga till data och kontrollera att det finns i databasen. Utförande: Kompilera stum med make i cvs-roten. Kör programmet för att ta bort ett ord som finns i databasen med kommandot./ dbtest_remove <märkning>. Kontrollera att det inte bli några felmeddelanden. Stäng anslutningen till databasen. Starta derbys console genom att köra scriptet dbconsole dom finns i cvsroten. Se till att du stängt ner stum innan. Kör kommandot connect jdbc:derby:stumdb ; i consolen. För att kontrollera vilket data det finns i databasen kör kommandot SELECT * FROM Phrase; För att kontrollera om phrase med en specifik märkning har lagt in i databasen använd kommandot SELECT * FROM Phrase WHERE marking= <märkning> ; Kontrollera att datat inte är tillgängligt. För att stänga dbconsole kör quit; Åtgärder vid lyckat test: Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 25

34 A.8 Modultest 10 - DataBase Modul: DataBase Modulfiler: DataBase.java Stubbar/drivrutiner: dbtest_find.java Åtgärder före test: Lägg till ett antal ord i databasen, med tillhörande uppmärkning och bitdata genom att använda instruktionerna i modultest 8. Utförande: Kompilera stum genom att skriva make i cvs-roten. Starta testprogrammet genom att köra./dbtest_find. Ange en märkning att söka efter. Kontrollera att utskriften från testprogrammet inte innehåller några felmedelanden och endast visar resultat som matchar ditt sökord. Ange en text att söka efter. Kontrollera att utskriften från testprogrammet inte innehåller några felmedelanden och endast visar resultat som matchar ditt sökord. Åtgärder vid lyckat test: Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Prova med ett annat ord som du lagt till i databasen. Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. 26

35 Bilaga B Modultestprotokol Nedan följer testprotokoll för alla utförda modultest. Utfallet av ett test markeras som: Godkänt: Testet gav förväntat resultat. Lätt fel: Felet bedöms inte vara allvarligt och/eller anses vara lätt att rätta till. Svårt fel: Ett allvarligt fel. Testet ger inte förväntat resultat. Påpekande: Testaren är osäker om det är något fel men vill ändå uppmärksamma implementeraren och testutvärderaren på ett visst beteende hos programmet. B.1 Testomgång 1 B.1.1 Modultest 1 till 3 Modul/moduler: StumVisualizer, Synthesizer, StumGUI Testare: Ali Aghajani Testdatum:: Testomgång nr: 1 Tidsåtgång: 45 min Antal fel: 1 Testfall Utfall Kommentar Felrapport MT-1 Påpekande Ibland så hackade uppspelningen när man körde. Hackningen uppstod slumpmässigt, samma fras kunde hacka en gång för att vara felfri en annan och vice versa. MT-1a MT-2 Godkänt MT-3 Godkänt 27

36 B.1.2 Modultest 4 till 10 Modul/moduler: DataBaseGUI, DataBase Testare: Testdatum:: Testomgång nr: 1 Tidsåtgång: 45 min Antal fel: 0 Testfall Utfall Kommentar Felrapport MT-4 Godkänt MT-5 Godkänt MT-6 Godkänt MT-7 Godkänt MT-8 Godkänt MT-9 Godkänt MT-10 Godkänt B.2 Testomgång 2 B.2.1 Modultest 1 Modul/moduler: StumVisualizer Testare: Ali Aghajani Testdatum:: Testomgång nr: 2 Tidsåtgång: 10 min Antal fel: 0 Testfall Utfall Kommentar Felrapport MT-1 Godkänt Uppspelningen fungerar utan hack. 28

37 Bilaga C Felrapport för modultest C.1 Felrapport MT-1a Datum: Felrapport nr: MT-1a Feltyp: Utfärdad av: Ali Aghajani X - Påpekande O - Lätt Fil: StumVisualizer O - Svårt Kodversion: Felbeskrivning: (MT-1) Ibland så hackade uppspelningen när man körde. Hackningen uppstod slumpmässigt, samma fras kunde hacka en gång för att vara felfri en annan och vice versa. Kommentar av den som åtgärdat felet: Visualizer har delvis skrivits om och optimerats. Uppspelning görs på ett annat sätt och med hjälp av en mindre buffert än innan. Åtgärdas av: Omtestas av: Ali Aghajani Tidsåtgång för rättning: 4 timmar Utfört (datum, namn): , Utfört (datum, namn): , Ali Aghajani 29

38 30

39 Bilaga D Integrationstestskript D.1 Integrationstest 1 - DataBase, DataBaseGUI Modul: DataBase, DataBaseGUI Modulfiler: DataBase.java, Data- BaseGUI.java Stubbar/drivrutiner: TestSTUM.java Åtgärder före test: Ha ett antal testfiler (t ex wav-filer) tillgängliga. Utförande: Kompilera DataBase.java, DataBaseGUI.java och TestSTUM.java. Starta testprogrammet. Fyll i ord, uppmärkning och sökväg till testfilen. Klicka på Add. Kontrollera att du inte får några felmeddelanden. Kontrollera innehållet i databasen genom att manuellt connecta till den och söka på ditt tillagda ord enligt: Starta en databaskonsol med kommandot dbconsole. I konsolen skriv: connect jdbc:derby:stumdb ; Nu kan databasen genomsökas med vanliga SQL-kommandon. Skriv: SELECT * FROM Phrase; Nu får du en lista med alla ord i databasen. För att endast visa ditt ord lägg till: WHERE Marking= DITTORD i SQLuttrycket. Åtgärder vid lyckat test: Testa med ett par olika ord med olika testfiler. Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 31

40 D.2 Integrationstest 2 - DataBase, DataBaseGUI Modul: DataBase, DataBaseGUI Modulfiler: DataBase.java, Data- BaseGUI.java Stubbar/drivrutiner: TestSTUM.java Åtgärder före test: Connecta till databasen manuellt och lägg till ord och uppmärkning enligt enligt: Starta en databaskonsol med kommandot dbconsole. I konsolen skriv: connect jdbc:derby:stumdb ; Nu kan databasen manipuleras med vanliga SQL-kommandon. Skriv: INSERT INTO Phrase (Phrase,Marking) VALUES ( ORD, UPP- MÄRKNING ); Utförande: Kompilera DataBase.java, DataBaseGUI.java och TestSTUM.java. Starta testprogrammet. Fyll i ordet du la till och klicka på Remove. Kontrollera att ordet inte finns i databasen längre genom att manuellt connecta till den och söka på ordet enligt: Starta en databaskonsol med kommandot dbconsole. I konsolen skriv: connect jdbc:derby:stumdb ; Nu kan databasen genomsökas med vanliga SQL-kommandon. Skriv: SELECT * FROM Phrase; Nu får du en lista med alla ord i databasen. För att endast söka på ditt ord lägg till: WHERE Marking= DITTORD i SQL-uttrycket. Åtgärder vid lyckat test: Testa med ett par andra ord och uppmärkning. Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 32

41 D.3 Integrationstest 3 - StumGUI, Synthesizer Modul: StumGUI, Synthesizer Stubbar/drivrutiner: StumGUIstart.java Åtgärder före test: Modulfiler: StumGUI.java, Synthesizer.java Utförande: Kompilera StumGUI.java, Synthesizer.java och StumGUIstart.java. Starta testprogrammet. Skriv in ett antal ord och uppmärkning och klicka på Starta talsyntes. Kontrollera de ord du skrev in korrekt skrivs ut på skärmen. Åtgärder vid lyckat test: Testa med ett par andra ord och uppmärkning. Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 33

42 D.4 Integrationstest 4 - Synthesizer, Processor, Visualizer Modul: Synthesizer, Processor, Stum- Visualizer Stubbar/drivrutiner: SynthesizerTest.java, ett antal ljudfiler (wav-filer). Åtgärder före test: Modulfiler: Synthesizer.java, Processor.java, Visualizer.java Editera filen Processor.java genom att lägga till spårutskrifter enligt: I metoden process() i första if-satsen lägg till System.out.println ("Processor: Phrase verified, adding to queue."); I metoden process() i första else-satsen lägg till System.out.println ("Processor: Phrase rejected."); I metoden run() i första while-loopen lägg till System.out.println ("Processor: Data appeared in queue."); Utförande: Kompilera SynthesizerTest.java, Synthesizer.java, Processor.java, Visualizer.java Starta testprogrammet och ange din en testljudfil som parameter. Kontrollera att du får de två utskrifterna Phrase verified och Data appeared in queue och inga felutskrifter. Kontrollera att den ljudfil du angav spelas upp korrekt. Åtgärder vid lyckat test: Testa med ett par andra ljudfiler. Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Kontakta ansvarig implementerare och begär rättning av fel. Meddela utvärderaren. 34

43 Bilaga E Integrationstestprotokoll Nedan följer testprotokoll för alla utförda integrationstest. Utfallet av ett test markeras som: Godkänt: Testet gav förväntat resultat. Lätt fel: Felet bedöms inte vara allvarligt och/eller anses vara lätt att rätta till. Svårt fel: Ett allvarligt fel. Testet ger inte förväntat resultat. Påpekande: Testaren är osäker om det är något fel men vill ändå uppmärksamma implementeraren och testutvärderaren på ett visst beteende hos programmet. E.1 Testomgång 1 E.1.1 Integrationstest 1 till 4 Modul/moduler: Alla Testare: Testdatum:: Testomgång nr: 1 Tidsåtgång: 2 timmar Antal fel: 2 Testfall Utfall Kommentar Felrapport IT-1 Godkänt IT-2 Svårt fel Programmet kraschar med null pointer exception. IT-2a IT-3 Svårt fel Programmet kraschar med en exception. IT-3a IT-4 Godkänt 35

44 E.2 Testomgång 2 E.2.1 Integrationstest 2 Modul/moduler: StumGUI, Synthesizer Testare: Testdatum:: Testomgång nr: 2 Tidsåtgång: 5 minuter Antal fel: 0 Testfall Utfall Kommentar Felrapport IT-2 Godkänt E.2.2 Integrationstest 3 Modul/moduler: StumGUI, Synthesizer Testare: Testdatum:: Testomgång nr: 2 Tidsåtgång: 15 minuter Antal fel: 0 Testfall Utfall Kommentar Felrapport IT-3 Godkänt 36

45 Bilaga F Felrapport för integrationstest F.1 Felrapport IT-2a Datum: Felrapport nr: IT-2a Feltyp: Utfärdad av: O - Påpekande O - Lätt Fil: DataBaseGUI X - Svårt Kodversion: Felbeskrivning: (IT-2) Databasen innehåller exakt två varianter på uppmärkning för ett visst ord. Användaren söker på detta ord och får en lista med de två uppmärkeringarna. Om användaren sedan markerar den uppmärkning som står överst i listan och klickar på Remove så kastas ett NullPointerException som inte fångas upp. GUIt slutar även fungera korrekt så länge programmet körs. Kommentar av den som åtgärdat felet: Listan uppdaterades innan alla åtgärder vid borttagning var slutförda. Denna uppdatering av listan måste stängas av på samma sätt som när vi lägger till text. Åtgärdas av: Johan Millving Omtestas av: Tidsåtgång för rättning: 15min Utfört (datum, namn): , Johan Millving Utfört (datum, namn): , 37

46 8.2 Felrapport IT-3a Datum: Felrapport nr: IT-3a Feltyp: Utfärdad av: O - Påpekande O - Lätt Fil: Synthesizer X - Svårt Kodversion: Felbeskrivning: (IT-3) Programmet kraschar med felmeddelandet: java.util.regex.patternsyntaxexception (Synthesizer.java:27). Kommentar av den som åtgärdat felet: Tecknet + har särskild betydelse i reguljära uttryck och måste därför ha ett escape-tecken (backslash) före. I java har dessutom \ särskild betydelse så ytterligare ett \ måste läggas till i källkoden för att det att kompilatorn inte skall klaga. -pattern = Pattern.compile("+"); +pattern = Pattern.compile("\\+"); Åtgärdas av: Andreas Rasmussen Omtestas av: Tidsåtgång för rättning: 10 minuter Utfört (datum, namn): , Andreas Rasmussen Utfört (datum, namn): , 38

47 Bilaga G Systemtestskript Notera att acceptanstest och acceptanstestskript (se Bilaga J) agerar som systemtest 5 till 20. Detta återspeglas av testprotokollen i Bilaga H och felrapporterna i Bilaga I. G.1 Systemtest 1 Modul: STUM Modulfiler: Stubbar/drivrutiner: Åtgärder före test: Se till att data för flertalet ord finns i databasen. Vid behov, använd DataBase- GUI. Se testskript för modultest 4 för instruktioner om hur du lägger till data. Utförande: Kompilera hela STUM-systemet genom att köra make i stumkatalogen (~/ stum/). Stäng av onödiga eller resurskrävande program som eventuellt körs på datorn. Starta STUM genom att skriva stumgui. Starta Task Manager (Windows XP, ctrl+alt+del, Task Manager) eller motsvarande Unix-verktyg. Gå till fliken Performance i Task Manager och ha den synlig vid sidan om STUM. Fyll i en längre sekvens av ord med uppmärkning i STUM. Klicka på Starta talsyntes. Övervaka CPU Usage History i Task Manager medan STUM spelar upp orden. Notera speciellt om CPU-användningen består av perioder där 100% CPU används under uppspelningen. Kontrollera även hur mycket minne STUM använder under uppspelning (fliken Processes i Task Manager). Åtgärder vid lyckat test: Testa med ett par andra ordsekvenser. Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Meddela utvärderaren. 39

48 G.2 Systemtest 2 Modul: STUM Modulfiler: Stubbar/drivrutiner: Åtgärder före test: Se till att data för flertalet ord finns i databasen. Vid behov, använd DataBase- GUI. Se testskript för modultest 4 för instruktioner om hur du lägger till data. Utförande: Kompilera hela STUM-systemet genom att köra make i stumkatalogen (~/ stum/). Starta STUM genom att skriva stumgui. Starta ett verktyg som övervakar minnesanvändning, t ex Task Manager (Windows XP) eller top (Unix). Kontrollera hur mycket minne STUM använder när det inte spelar upp någon ljuddata. Fyll i ett större antal ord med uppmärkning och spela upp dem genom att klicka på Starta talsyntes. Upprepa detta ett antal gånger, med olika ord. Samtidigt som du spelar upp olika meningar och fraser, övervaka minnesåtgången. Kontrollera att minnesåtgången inte ökar ju fler ord och meningar som spelas upp. Låt STUM stå på länge, t ex över natten och spela sedan upp fler meningar. Kontrollera att minnesåtgången inte märkbart ökat av en längre körning. Åtgärder vid lyckat test: Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Meddela utvärderaren. G.3 Systemtest 3 Utgår då kravet om ansiktsanimering (se Kravspecifikation [Sandström, 2005]) ej är aktuellt. 40

49 G.4 Systemtest 4 Modul: STUM Modulfiler: Stubbar/drivrutiner: En längre testljudfil (wav-fil). Åtgärder före test: Se till att data för flertalet ord finns i databasen. Vid behov, använd DataBase- GUI. Se testskript för modultest 4 för instruktioner om hur du lägger till data. Utförande: Kompilera hela STUM-systemet genom att köra make i stumkatalogen (~/ stum/). Starta STUM genom att skriva stumgui. Fyll i ett större antal ord med uppmärkning och spela upp dem genom att klicka på Starta talsyntes. Mitt under uppspelningen, stäng av STUM. (Vid behov, använd kill (Unix) eller Task Manager (Windows XP)). Starta STUM igen och spela upp samma ord som ovan. Kontrollera att STUM fortfarande kan spela upp orden. Starta DataBaseGUI genom att skriva stumdb. Fyll i ord, uppmärkning och sökväg till en testljudfil. Klicka på Add men avsluta sedan programmet snabbt, innan det hinner lägga till data. Starta stumdb och försök att lägga till ordet igen. Kontrollera att du får ett meddelande om att ordet redan finns i databasen eller att det lags till. Starta stumgui och spela upp det tillagda ordet. Kontrollera att det kan spelas upp felfritt och att ljuddata inte blivit korrupt. Åtgärder vid lyckat test: Fyll i testprotokoll och meddela utvärderaren. Åtgärder vid misslyckat test: Fyll i testprotokoll och felrapport. Meddela utvärderaren. 41

50 42

51 Bilaga H Systemtestprotokoll Nedan följer testprotokoll för alla utförda systemtest. Utfallet av ett test markeras som: Godkänt: Testet gav förväntat resultat. Lätt fel: Felet bedöms inte vara allvarligt och/eller anses vara lätt att rätta till. Svårt fel: Ett allvarligt fel. Testet ger inte förväntat resultat. Påpekande: Testaren är osäker om det är något fel men vill ändå uppmärksamma implementeraren och testutvärderaren på ett visst beteende hos programmet. H.1 Testomgång 1 H.1.1 Systemtest 1 till 4 Modul/moduler: STUM Testare: Ali Aghajani Testdatum:: Testomgång nr: 1 Tidsåtgång: 20min Antal fel: 3 Testfall Utfall Kommentar Felrapport ST-1 Svårt fel Uppspelning misslyckas helt. ST-1a ST-2 Svårt fel Uppspelning misslyckas helt. ST-1a ST-3 Testet utgår Funktionaliteten har utgått. ST-4 Svårt fel Uppspelning misslyckas helt. ST-1a 43

52 H.1.2 Systemtest 5 till 10 Modul/moduler: STUM Testare: Patrik Sandström Testdatum:: Testomgång nr: 1 Tidsåtgång: 2tim Antal fel: 2 Testfall Utfall Kommentar Felrapport ST-5 Godkänt Inga delays. Strängen i text: -fältet har ingen betydelse. Om ordet ej finns skrivs ett meddelande ut i consolen, även om stav elserna finns. ST-6 Svårt fel Talsyntesdelen fungerar, den spelade upp de ST-6a orden som var korrekta. däremot kom inget felmeddelande upp för det felaktiga ordet (förutom i konsollen). ST-7 Godkänt Spelas upp korrekt. ST-8 Svårt fel Se kommentar för ST-6. ST-8a ST-9 Godkänt Fungerar som det är tänkt. ST-10 Testet utgår Funktionaliteten har utgått från systemet. 44

53 H.1.3 Systemtest 11 till 13 Modul/moduler: STUM Testare: Ali Aghajani Testdatum:: Testomgång nr: 1 Tidsåtgång: 15 min Antal fel: 0 Testfall Utfall Kommentar Felrapport ST-11 Godkänt ST-12 Godkänt ST-13 Godkänt H.1.4 Systemtest 14 till 17 Modul/moduler: STUM Testare: Patrik Sandström Testdatum:: Testomgång nr: 1 Tidsåtgång: 50min Antal fel: 1 Testfall Utfall Kommentar Felrapport ST-14 Testet utgår Funktionaliteten har utgått. ST-15 Godkänt ST-16 Godkänt ST-17 Svårt fel Finns ej tillräckligt med data. ST-17a ST-18 Testet utgår ST-19 Godkänt 45

54 H.2 Testomgång 2 H.2.1 Systemtest 1, 2, 4 Modul/moduler: STUM Testare: Ali Aghajani Testdatum:: Testomgång nr: 1 Tidsåtgång: 30min Antal fel: 1 Testfall Utfall Kommentar Felrapport ST-1 Svårt fel Programmet drar % resurser. ST-1b ST-2 Godkänt ST-4 Godkänt H.2.2 Systemtest 6, 8, 17 Modul/moduler: STUM Testare: Patrik Sandström Testdatum:: Testomgång nr: 2 Tidsåtgång: 20 minuter Antal fel: 0 Testfall Utfall Kommentar Felrapport ST-6 Godkänt ST-8 Godkänt ST-17 Godkänt 46