Testrapport. Redaktör: Mikael Svärd Version: 1.0 Datum: Sammanfattning

Transkript

1 Redaktör: Version: 1.0 Datum: Sammanfattning Detta dokument utvärderar och beskriver resultatet av testningen av produkten Audio Jury utvecklas av i kursen TDDB61 Programvaruutveckling i ett helhetsperspektiv. Produkten är en programvara för evaluering av ljudkvalitet enligt önskemål från kunden Sony Ericsson Mobile Communications AB. Dokumentet innehåller en generell utvärdering av testarbetet, mer specifika beskrivningar för varje fas i testningen, samt appendix innehållande alla testskript, testprotokoll och felrapporter.

2 ii

3 PROJEKTIDENTITET, Linköpings tekniska högskola Projektmedlemmar Namn Ansvarsområde Telefon E-post Per Andersson Dokumentansvarig (DOK) David Akhvlediani Implementationsansvarig (IMP) Robert Johansson Designansvarig (DES) Lars Larsson Kundansvarig (KUND) Johan Marnetoft Kvalitetsansvarig (KVAL) Gustav Rosén Projektledare (PL) Testansvarig (TEST) Christoffer Årstrand Systemansvarig (SYS) E-postlista för hela gruppen Hemsida Kund Sony Ericsson Mobile Communications AB Kundkontakt Wanqing Shi, Sonia Sangari, Handledare Mustapha Skhiri, Kursansvarig Uwe Assman, PROJEKTIDENTITET iii

4 iv

5 Dokumenthistorik Datum Version Namn Förändring Dokumentet skapades. (PL, KVAL, TEST) Rättningar efter kommentering Johan Marnetoft Rättningar efter inspektion. Dokumenthistorik v

6 vi Dokumenthistorik

7 1 Inledning Syfte Kapitelöversikt Läsanvisningar Berörda dokument Översikt Källor Utförande Testmetod Testplan Tidsåtgång Testresultat Vanliga fel Anmärkningar Test av testning Tillräcklighet Modultestrapport Utförande Testmetod Testplan Tidsåtgång Testresultat Vanliga fel Tillräcklighet Integrationstestrapport Utförande Testmetod Testplan Tidsåtgång Testresultat Tillräcklighet Systemtestrapport Utförande Testmetod Testplan Tidsåtgång Testresultat Vanliga fel Tillräcklighet Innehållsförteckning vii

8 6 Acceptanstestrapport Utförande Testmetod Testplan Tidsåtgång Testresultat Vanliga fel Tillräcklighet Referenser Externa dokument Interna dokument Appendix A Indata till testfall Appendix B Modultestskript Appendix C Modultestprotokoll Appendix D Modultestfelrapporter Appendix E Integrationstestskript Appendix F Integrationstestprotokoll Appendix G Integrationstestfelrapporter Appendix H Systemtestskript Appendix I Systemtestprotokoll Appendix J Systemtestfelrapporter Appendix K Acceptanstestskript Appendix L Acceptanstestprotokoll Appendix M Acceptanstestfelrapporter viii Innehållsförteckning

9 1 Inledning Detta kapitel beskriver kortfattat dokumentets innehåll och redogör för vilka andra dokument som påverkas av testrapporten. 1.1 Syfte Syftet med denna testrapport är att sammanställa och utvärdera det testarbete som utförts under framtagandet av Audio Jury. Främst är dokumentet till för att ska kunna dra erfarenhet av testarbetet i andra framtida projekt. 1.2 Kapitelöversikt 1. Inledning Beskriver kortfattat innehållet i dokumentet. 2. Översiktlig utvärdering Beskriver utvärderingen av det totala testarbetet. 3. Modultestrapport Beskriver utvärderingen av modultestarbetet. 4. Integrationstestrapport Beskriver utvärderingen av integrationstestarbetet. 5. Systemtestrapport Beskriver utvärderingen av systemtestarbetet. 6. Acceptanstestrapport Beskriver utvärderingen av acceptanstestet. 7. Referenser Innehåller en förteckning över aktuella referenser. Appendix A. Indata till testfall Beskriver den använda metoden för framtagande av indata till testningen. Appendix B. Modultestskript Innehåller de testskript som användes under modultestningen. Appendix C. Modultestprotokoll Innehåller de testprotokoll som skrevs under modultestningen. Kapitel 1: Inledning 1

10 Appendix D. Modultestfelrapporter Innehåller de felrapporter som skrevs under modultestningen. Appendix E. Integrationstestskript Innehåller de testskript som användes under integrationstestningen. Appendix F. Integrationstestprotokoll Innehåller de testprotokoll som skrevs under integrationstestningen. Appendix G. Integrationstestfelrapporter Innehåller de felrapporter som skrevs under integrationstestningen. Appendix H. Systemtestskript Innehåller de testskript som användes under systemtestningen. Appendix I. Systemtestprotokoll Innehåller de testprotokoll som skrevs under systemtestningen. Appendix J. Systemtestfelrapporter Innehåller de felrapporter som skrevs under systemtestningen. Appendix K. Acceptanstestskript Innehåller de testskript som användes under acceptanstestningen. Appendix L. Acceptanstestprotokoll Innehåller de testprotokoll som skrevs under acceptanstestet. Appendix M. Acceptanstestfelrapporter Innehåller de felrapporter som skrevs under acceptanstestet. 1.3 Läsanvisningar Detta dokument bygger på testplanen [Svärd, 2003] och förutsätter till stora delar att ovanstående dokument lästs. Således bör dessa dokument läsas tillsammans för att få en fullständig bild av testarbetet. För att få en övergripande insyn i utvärderingen bör kapitel 2, "Översikt", på sidan 5 först läsas. Därefter kan utvärderingen av de olika faserna läsas. Bilagorna innehåller alla detaljer om specifika uppgifter önskas. 1.4 Berörda dokument Här redovisas de dokument som kan påverka dokumentet. Om någon av dessa förändras måste även detta dokument uppdateras. Requirements specification [Larsson, 2003] 2 Kapitel 1: Inledning

11 Design specification [Johansson, 2003] User s manual [Årstrand, 2003] Testplan [Svärd, 2003]. Kapitel 1: Inledning 3

12 4 Kapitel 1: Inledning

13 2 Översikt Detta kapitel innehåller en översiktlig utvärdering av det testarbete som utförts i samband med utvecklingen av systemet Audio Jury. Även felstatistik och källor till utvärderingen tas upp. 2.1 Källor I detta avsnitt anges de källor som legat till grund för denna testrapport. De dokument som är relevanta för utvärderingen är: Requirements specification [Larsson, 2003] Design specification [Johansson, 2003] Testplan [Svärd, 2003] User s manual [Årstrand, 2003] Testskript (se appendix till detta dokument) Testprotokoll (se appendix till detta dokument) Felrapporter (se appendix till detta dokument). Dessutom har teknisk expertis tillfrågats: John Wilander, IDA, Linköpings universitet Jon Edvardsson, IDA, Linköpings universitet. 2.2 Utförande Allt testarbete har utförts enligt testplanen [Svärd, 2003]. Inga större ombearbetningar av dokumentet har behövts utföras. Det handlar uteslutande om omdisponering av resurser. För utförligare beskrivningar av utförandet av de olika testfaserna hänvisas till respektive testrapport. 2.3 Testmetod De testmetoder vi har valt att arbeta efter har i de flesta fall visat sig fungera bra. Modulariseringen var lyckad och väl avgränsad, men detta till trots var det svårt att fullständigt uppnå den parallellism mellan implementation och testning som vi eftersträvat. Mest på grund av schematekniska problem, men även därför att implementationen tog mer tid än beräknat och svårigheten att hålla fullständiga leveranser av färdigimplementerade moduler. Bottom-up metoden fungerade bra eftersom modulariseringen stämde överens med systemets funktion och implementationsgruppen kunde göra regelbundna leveranser enligt denna ordning. 2.4 Testplan Vi har under alla testfaser kunnat följa testspecifikationerna i testplanen [Svärd, 2003]. Denna har fungerat bra som stöd för testgruppen och eftersom alla testare varit involverade i framtagningen var det också lättare att få med hela gruppen i testarbetet. Skrivandet av testskript kunde fullständigt grundas på testspecifikationerna och flera medlemmar i testgruppen Kapitel 2: Översikt 5

14 kunde utföra detta arbete, vilket gav en jämnare arbetsbelastning än vad som annars hade varit fallet. 2.5 Tidsåtgång Testningen har allmänt följt tidsramarna i testplanen på ett bra sätt. Modultestningen drog över lite i tid eftersom implementeringen av stubbar och drivrutiner tog mer tid i anspråk än planerat. Det som tagit mindre tid än planerat är genomförandet av testerna, då det inte upptäcktes så många fel. Därför behövdes inte heller så många omtester utföras. Detta återspeglas också i implementationsgruppens tidsrapportering, vilken genomgående ligger högt. Från detta drar vi slutsatsen att implementationsgruppen gjort en del av testgruppens arbete redan före leverans av moduler. Men man kan även se det som att vi haft en mycket lyckad design och noggranna implementerare. Testfas Beräknad tid (h) Utfall (h) Modultestning Integrationstestning Systemtestning Acceptanstestning Totalt Testresultat Tabell 1: Planerad tid och utfall. I tabell 2 visas en summering av alla fel som påträffats under de fyra testfaserna. Värt att påpeka är att det påträffats flest fel under modultestningen och att det var minst fel i systemtestningen. Det tyder på att inga fel följt med under testningen och att testningen har gett resultat. Det är även intressant att endast fyra stora fel upptäcktes. Som tidigare nämnts visar detta att implementationsgruppen varit så angelägna att överlämna ett kvalitativt system att de inte levererat moduler för testning förrän de försäkrat sig om att modulerna fungerar enligt specifikation. Felsummering Påpekanden Små fel Stora fel Totalt antal fel Modultest Integrationstest Systemtest Acceptanstest Totalt Tabell 2: Felsummering av allt testarbete. 6 Kapitel 2: Översikt

15 2.7 Vanliga fel I tabell 3 sammanställs de vanligaste felen som påträffades under testarbetet. Feltyp Modul Integr. System Accept. Totalt Skönhetsfel Felaktiga teststubbar Felaktiga testskript Felaktiga utdata Felaktig feedback Användbarhetsbrist Kravändringar från kund Totalt Anmärkningar Allmänt sett har testningen gått mycket bra. Dock finns det anledning att vara självkritisk och ifrågasätta testresultatet när så få fel upptäcks. Ingående analys av testningen visar att vi testat systemets funktion och struktur på ett bra sätt, men kanske missat några s k "idiottester". Felhanteringen har också testats utförligt och systemet känns mycket stabilt. Dock finns det några fall där feedback från systemet kunde vara bättre. Hur hade testningen kunnat utföras för att avslöja fler fel? Till att börja med skulle vi kunnat tillämpa en mer testdriven implementation. Testgruppen har dragit erfarenheten att vi skulle kunnat jobba mycket närmare implementationsgruppen så att inga "leveranser" av moduler till testning behövts göras. Hade vi haft tillgång till en lokal med flera PC i anslutning till varandra hade implementation och testning kunnat ske mer parallellt och därmed avlastat implementationsgruppen i större utsträckning. Något som däremot var en mycket positiv erfarenhet var användandet av CVS. Detta medgav snabb och precis kommunikation mellan implementationsgruppen och testgruppen trots bristen på gemensam lokal. T ex kunde TEST omedelbart ringa upp IMP, påvisa ett fel och, genom att båda kunde studera testkod och programkod, utreda vad det kunnat bero på. Vidare kunde ändringar verifieras av testgruppen på ett smidigt sätt och omtesterna kom att bli en naturlig del av de övriga testerna Test av testning Det skulle behövas någon form av verifiering av att systemet testas på rätt sätt. Någon sådan har inte utförts på annat sätt än att TEST noggrant analyserat testresultaten och jämfört testplaner med det färdiga systemet. 2.9 Tillräcklighet Tabell 3: Antal förekomster av varje feltyp. Testningen har täckt in alla krav i kravspecifikationen [Larsson, 2003]. Det är svårt att dra en gräns för när man ska anse testningen som tillräcklig och Kapitel 2: Översikt 7

16 därmed avslutad. Otaliga akademiska artiklar behandlar detta ämne (t ex [Ostrand, 2002]). I princip bör testningen fortgå så länge som produkten används och vidareutvecklas. Därmed borde även vår testning fortlöpa ytterligare en tid om vi hade de resurser som ett kommersiellt företag. Nu nöjer vi oss med att konstatera att kunden, högst troligt, kommer att bli nöjd med produkten och lämnar över till dem att fortsätta utvecklingsarbetet. 8 Kapitel 2: Översikt

17 3 Modultestrapport Detta kapitel redovisar hur modultestet har genomförts och resultatet av detta. 3.1 Utförande All modultestning har utförts enligt testplanen [Svärd, 2003]. De testskript, testprotokoll och felrapporter som skrevs under modultestningen finns i appendix B-D. Då framtagande av indata till testfallen till en början framstod som ostrukturerad så fanns ett behov av att göra framtagningen mindre "ad hoc". Testgruppen studerade en rad metoder för framtagande av testdata och konsulterade ett antal personer på IDA, varefter beslut om design av en egen strukturerad "metod" för framtagande av testdata togs. Detta beslut baserades på att de personer som konsulterades förespråkade mycket tidskrävande metoder och att tidsplanen inte tillät denna framtagning. För att trots detta nå en strukturerad framtagning av indata togs metoden fram. Metoden återfinns i avsnitt A.2, "Riktlinjer för framtagande av indata", efter det att redan existerande metoder kommenterats. 3.2 Testmetod Modultestningen bestod huvudsakligen av funktionell testning. Den metod för funktionell testning vi använt oss av är svartlådetest på varje modul. Detta för att garantera att produkten uppfyllde funktionella krav. Tyngdpunkten kom att läggas på den funktionella testningen, men även strukturell testning genomfördes. Vi hade dock aldrig ambitionen att uppnå fullständig "branch coverage", utan såg snarare den strukturella testningen som ett komplement till den funktionella i syfte att avslöja fler fel och även garantera hög kvalitet på programkoden. Ambitionen blev istället att utforma indata till testfallen på ett sådant sätt att så mycket som möjligt av programkoden kördes igenom. Vi diskuterade även några olika metoder att mäta "branch coverage" som involverade spårutskrifter av programkoden men kom fram till att detta skulle "svärta ned" vår programkod med testkod vilket vi inte önskade. Några kommersiella programvaror för att utföra denna estimering åt oss hittades inte till rimligt pris. Därför nöjde vi oss med att göra egna bedömningar vid konstruktion av testerna. 3.3 Testplan Testplaneringen i testplanen [Svärd, 2003] har följts mycket väl. Delar av modultestarbetet blev dock försenat till följd av att implementationen blev försenad p g a att IMP gjorde en utlandsresa. Därtill tog det längre tid än beräknat att skriva testskript och teststubbar. Detta är något som testgruppen dragit erfarenheter av och nu skulle detta arbete gå smidigare. Kapitel 3: Modultestrapport 9

18 3.4 Tidsåtgång I tabell 4 visas planerad tidsåtgång och utfall för modultestets olika uppgifter. Här ser man att det tog mycket mer tid i anspråk än planerat att implementera testmetoder. Detta kompenserades av att genomförandet tog mycket mindre tid i anspråk. Den planerade tiden ses i efterhand som något orimlig. Vi ser det som att vi vid testplanens skrivande hade något undermåliga insikter i hur testarbetet skulle komma att utveckla sig. Med vår manuella testmetod var implementationen av testmetoder det tunga arbetet. Person Aktivitet KUND KVAL PL TEST Tid Utfall Skriva testskript ,0 Konstruera hjälpmedel ,0 Genomförande Utvärdering och sammanställning Summa Testresultat Tabell 4: Planerad tid samt utfall. Angiven i mantimmar. I tabell 5 finns en sammanställning av de felrapporter som skrevs under modultestningen. I tabellen framgår det att många moduler var felfria redan vid första testet. Detta beror troligtvis på att det inte finns så mycket som kan gå fel i dessa moduler, antingen p g a att de innehåller lite funktionalitet eller att implementationsgruppen redan vid implementation utfört en del av testarbetet. Därvid vore det intressant att ha teststatistik även från implementationen. Sådan saknas dock i detta projekt. Modul Påpekanden Små fel Stora fel Totalt antal fel Konfigurationsmodulen 1 1 Projekthanteringsmodulen 2 2 Projektmodifieringsmodulen 2 2 Resultathanteringsmodulen 0 Ljuduppspelningsmodulen 0 Project-modulen 0 Test-modulen ProjectResults-modulen 0 Sound-modulen 2 2 Score-modulen 0 Scale-modulen 0 Tabell 5: Antal fel per modul. 10 Kapitel 3: Modultestrapport

19 Modul Påpekanden Små fel Stora fel Totalt antal fel Instruction-modulen 0 PairedJudgement-modulen 2 2 SingleJudgement-modulen 0 CCR-modulen 0 ACR-modulen 0 DCR-modulen 0 FullComparison-modulen 0 GeneralPairs-modulen 0 Totalt Vanliga fel Tabell 5: Antal fel per modul. I tabell 6 sammanställs de vanligaste felen som påträffades under modultestningen. Feltyp Antal fel Metod returnerar felaktigt resultat 3 Strukturellt fel 2 Skönhetsfel 0 Felaktiga testskript 4 Felaktiga teststubbar 3 Totalt Tillräcklighet Tabell 6: Antal förekomster av varje feltyp. Modultestspecifikationen i testdokumentationen [Svärd, 2003] täckte programmets funktionalitet bra. Det faktum att få fel upptäcktes kan antingen tyda på att systemet är relativt felfritt eller på att inte hela funktionaliteten testas. Vi tolkar dock detta enligt det första alternativet. När ska man bedömma ett modultest som tillräckligt? Enligt Some Notes on Software Testing [Wilander, 2003] blir det allt dyrare ju längre man håller på att hitta nya fel. Således måste man redan i förväg sätta upp kriterier för när ett test skall ses som tillräckligt. I fråga om funktionell testning anser vi att våra testfall täcker in funktionaliteten på ett bra sätt. Däremot vad beträffar den strukturella testningen, som ingen i testgruppen hade någon tidigare erfarenhet av, hade vi mer vagt definierade gränser för vilken "branch coverage" som förväntas. Här blev istället den avgörande faktorn att inte bryta tidsplanen utan att erhålla en så god "branch coverage" som möjligt inom givna tidsramar. Detta anses som tillräckligt för detta projekt, eftersom inga tidigare erfarenheter finns att läsa om ämnet på kurshemsidans "Bra dokument från tidigare år" [Kaminski, 2003]. Kapitel 3: Modultestrapport 11

20 12 Kapitel 3: Modultestrapport

21 4 Integrationstestrapport Detta kapitel redovisar hur integrationstestet har genomförts och resultatet av detta. 4.1 Utförande All integrationstestning har utförts enligt testplanen [Svärd, 2003], i den mening att testordningen varit i enlighet med planen och att testfallen överenstämt med de som föreskrivits. På samma sätt som i modultestningen har testskript skapats, som utförligare klargör hur testfallen skall utföras. För varje integrationsteststeg har en "testklass" skapats. Denna testklass innehåller en metod för varje testfall. Metoderna, som alltså representerar testfallen, har implementerats i enlighet med integrationstestskripten. Dessa metoder har sedan anropats från en main-metod. Då även testklasserna, jämte programmet, varit föremål för CVS-användande har förutom god kommunikation i testgruppen en snabb och precis återkoppling givits till implementationsgruppen. De testskript, testprotokoll och felrapporter som skrevs under integrationstestningen finns i appendix E-G. 4.2 Testmetod Bottom up-metoden har i enlighet med testplanen [Svärd,2003] tillämpats. Det visade sig lyckosamt att utföra testerna i de steg som specificerats. Integrationen mellan klasserna i domänen ("datamodulen") testades först och därefter lades modul för modul till med mer och mer abstrakta tester som följd, i den mening att metoder i överliggande moduler även testade funktionaliteten i de lägre i varje steg. I vårt fall gav den tillämpade integrationsmetoden även möjlighet till parallell testning då den graf som beskriver modulrelationerna, se designspecifikationen [Johansson, 2003], är ett träd med en rad löv och få noder med fler än ett underliggande träd. Då testfallen för de integrerande metoderna i varje modul valdes på samma sätt som vid modultesterna blev testfallen mycket lika och i många fall identiska. Då modulerna är mycket löst sammankopplade kunde funktionaliteten vid integrationen testas på ett bra sätt med få tester. Det som istället fokuserades på var den strukturella testningen. Testfallen på en specifik metod utsattes för indata som på ett mycket medvetet sätt provocerade fram en hög nivå av integration med underliggande moduler. Detta gjordes genom att studera kopplingar mellan modulerna och sedan förmå indatan att ge en hög täckningsnivå på anrop ut från modulen. 4.3 Testplan Testplaneringen i testplanen [Svärd, 2003] har följts mycket väl. Kalendermässigt har testningen varit mycket lyckad då integrationstestningen kunnat påbörjats redan efter ett litet antal modultester, då bottom up-metoden tillämpats vid integrationen och ordningen på modultesterna i efterhand anpassats efter detta. Kapitel 4: Integrationstestrapport 13

22 4.4 Tidsåtgång I tabell 7 visas planerad tidsåtgång och utfall för integrationstestets olika uppgifter. Tidsåtgången blev här, för samtliga personer, något mindre än planerat. Tid sparades framför allt vid skrivandet av testskript, då mycket från modultesterna kunde återanvändas. Dessutom gick det snabbare p g a erfarenheter från modultestet. Aktivitet Person Tid Utfall KUND KVAL PL TEST Skriva testskript Konstruera hjälpmedel Genomförande Utvärdering och sammanställning Summa Tabell 7: Planerad tid samt utfall. Angiven i mantimmar. 4.5 Testresultat Vid integrationstestningen påträffades inte ett enda fel. Detta resulterade i att testgruppen sammankallades till ett extra testmöte. Resultatet av detta möte återges i avsnitt 4.6 nedan. 4.6 Tillräcklighet Här redogörs för integrationstestets tilläcklighet. Detta avsnitt blir mycket viktigt då antalet funna fel var noll. Följande möjliga anledningar, givetvis möjliga i kombinationer, kan ges till att inga fel påträffades under integrationstestningen: 1. Implementationen har utförts mycket bra. 2. Programmets art, designen, med mycket löst sammankopplade moduler gör integrationstestningen mycket liten och därför minskar sannolikheten för fel. 3. Vid modultestning eliminerades många av de fel som skulle kunnat dyka upp i integrationstestningen. Stor vikt lades vid studie av korrekta gränssnitt hos modulerna och att dessa uppfyllde sin funktion. 4. Integrationstestningen har varit otillräcklig. I den första punkten ligger mycket sanning. Detta grundar sig på två faktorer. För det första så har kodskelettet med bl a metodhuvuden genererats av en programvara, utifrån givna specifikationer. Integrationsfel är ofta specifikationsfel, alltså att indata och returtyper inte stämmer. Detta har eliminerats genom ovanstående tillvägagångssätt. För det andra ligger mycket av projektgruppens styrka hos implementationsansvarige. Denne har mycket goda kunskaper och lång erfarenhet i programvarubranschen. Vidare har implementationsansvarige gjort mycket av kodningen på egen hand, varför integrationsfel av missförståndsbaserad art kunnat uteslutas. 14 Kapitel 4: Integrationstestrapport

23 Den andra punkten kan understrykas med att testfallen blev relativt få, grundat på att antalet metoder som kommunicerade med omvärlden i varje modul var få i sig. Programmet är medvetet designat på ett sätt som håller nere kommunikationen mellan modulerna. Den tredje punkten ges utan kommentarer. Den fjärde och mest kritiska punkten kan inte uteslutas. Dock kan nedanstående argument, jämte nivån av sannolikhet i de tidigare tre punkterna, ges mot denna: 1. De metoder som använts för att finna fel är allmänt vedertagna och accepterade. 2. Integrationstestningen får sägas vara utförlig i sin kvantitet, då integrationen mellan modulerna varit liten och god tid tagits till testningen. 3. De integrationstester som utförts får sägas vara av god kvalitet. De tesfall som utförts har givits indata baserat på partition testing; en mycket effektiv metod för framtagande av heltäckande testdata. Därtill har BVA använts vilket ger god testning av randvillkor och felaktiga data. Studier av integrationens art i koden har givit upphov till flera nya indata, strukturell testning har alltså använts för att provocera fram en täckning av integrationen. Efter diskussion slöt sig testgruppen till att inte utföra några ytterligare integrationstester. Integrationstestningen godkändes. Detta beslut togs framför allt baserat på ovanstående resonemang, men även med det efterliggande systemtestet i åtanke och att möjliga fel som passerat integrationstestningen skulle upptäckas under detta systemtest. Kapitel 4: Integrationstestrapport 15

24 16 Kapitel 4: Integrationstestrapport

25 5 Systemtestrapport Detta kapitel redovisar hur systemtestet har genomförts och resultatet av detta. 5.1 Utförande All systemtestning har utförts enligt testplanen [Svärd, 2003]. De testskript, testprotokoll och felrapporter som skrevs under systemtestningen återfinns i appendix H-J. 5.2 Testmetod Systemtestet har delats upp i två delar. Först testades funktionaliteten hos Audio Jury och alla krav i kravspecifikationen [Larsson, 2003] täcktes på detta sätt in. Det andra steget bestod i att testa systemet mot användarhandledningen [Årstrand, 2003]. Vi ser användarhandledningen som en del av systemet som levereras med produkten. Därför vill vi garantera konsistens i hela detta levererade system och därtill kompletteras testerna på funktionella krav med mer subtila tester på användbarhet. 5.3 Testplan Testplaneringen i testplanen [Svärd, 2003] har följts mycket väl. Systemtestarbetet blev dock försenat till följd av att implementationen blev försenad. 5.4 Tidsåtgång I tabell 4 visas planerad tidsåtgång och utfall för systemtestets olika uppgifter. Tidsåtgången blev här ungefär som planerad. Visserligen var det bara halva testgruppen som kunde arbeta med systemtestning p g a påskuppehåll och omtentor, men detta var ändå tillräckligt för att genomföra testningen på ett bra sätt. Aktivitet Person Tid Utfall KUND KVAL PL TEST Skriva testskript Genomförande Utvärdering och sammanställning Summa Tabell 8: Planerad tid samt utfall. Angiven i mantimmar. Kapitel 5: Systemtestrapport 17

26 5.5 Testresultat I tabell 9 finns en sammanställning av de felrapporter som skrevs under systemtestningen. Kontroll av att användarhandledningens [Årstrand, 2003] korrekthet utfördes utan några anmärkningar. Systemtestfall Påpek ande Litet fel Stort fel Administratörsprogrammet Klienten Totalt Vanliga fel Tabell 9: Antal fel i systemtestet. I tabell 10 sammanställs och graderas de vanligaste felen som påträffades under systemtestningen. Feltyp Antal fel Användbarhetsbrist 6 Skönhetsfel 2 Felaktig feedback 1 Totalt Tillräcklighet Tabell 10: Antal förekomster av varje feltyp. Systemtestspecifikationen i testplanen [Svärd, 2003] täcker alla krav i kravspecifikationen [Larsson, 2003]. Eftersom alla test är godkända och alla aktiva krav därmed är uppfyllda så täcks åtminstone funktionaliteten som omnämns i kravspecifikationen in. En mycket detaljerad kravspecifikation med ambitiösa kravnivåer tyder på att kunden fått med flertalet av sina önskemål på produkten. Därmed borde vi kunna dra slutsatsen att kunden kommer att bli nöjd. Dock vore det av stort intresse att följa upp testarbetet med ett test efter första release. Detta skulle med all säkerhet avslöja nya krav från kunden och en rad förbättringar för kommande versioner. På detta vis ser man hur testarbetet är en levande del av programutvecklingen. Testningen fortgår så länge produkten vidareutvecklas. 18 Kapitel 5: Systemtestrapport

27 6 Acceptanstestrapport Detta kapitel redovisar hur acceptanstestet har genomförts och resultatet av detta. 6.1 Utförande Acceptanstestet har utförts enligt testplanen [Svärd, 2003]. De testskript, testprotokoll och felrapporter som skrevs under acceptanstestet återfinns i appendix K-M. 6.2 Testmetod Acceptanstestet har baserats på kravspecifikationens krav på nivå bas och normal. I princip verifierades bara samma sak som redan testats i systemtestet. Dock förekom ingen testning av felhantering på samma sätt som i systemtestet. Däremot fokuserades efterdiskussionen på avändbarhet och framtida förbättringar. 6.3 Testplan Testplaneringen i testplanen [Svärd, 2003] har följts mycket väl. Acceptanstestet kunde genomföras i god tid före leverans till kund och presentation för övriga PUM-deltagare. Detta beror till stor del på mycket drivna programmerare och väl efterlevda milstenar i projektplanen [Rosén, 2003]. 6.4 Tidsåtgång I tabell 4 visas planerad tidsåtgång och utfall för acceptanstestets olika uppgifter. Tidsåtgången blev här ungefär som planerad. Oförutsedd förberedelsetid kompenseras av snabbare genomförande än planerat. Aktivitet Person Tid Utfall KUND DES PL TEST Skriva testskript Förberedelser Genomförande Utvärdering och sammanställning Summa Tabell 11: Planerad tid samt utfall. Angiven i mantimmar. Kapitel 6: Acceptanstestrapport 19

28 6.5 Testresultat I tabell 12 finns en sammanställning av de felrapporter som skrevs under acceptanstestet. Systemtestfall Påpekande Litet fel Stort fel Administratörsprogrammet Klienten Totalt Vanliga fel Tabell 12: Antal fel i acceptanstestet. I tabell 13 visar de vanligaste felen som påträffades under systemtestningen. Detta var också alla. Feltyp Antal fel Användbarhetsbrist - påpekande 12 Totalt Tillräcklighet Tabell 13: Antal förekomster av varje feltyp. Acceptanstestet täckte in all funktionalitet angiven på nivå bas och normal i kravspecifikationen [Larsson, 2003]. Att säga att detta var ett fullständigt test av systemet är en stark överdrift. Dock visade testet att rådande implementation uppfyller kundens önskemål. Testet kompletterades med en diskussion kring kraven på nivå extra. På detta sätt kunde vi även visa för kunden vilka extra funktioner som implementerats och vilka som bör läggas till i restlistan. Att konstruera ett fullständigt test av systemet till acceptanstestet är inte att uppfylla dess syfte. Syftet med testet är att visa att systemet uppfyller kundens önskemål. Därmed anses testet tillräckligt. Systemet uppfyller med god marginal kundens önskemål på funktionalitet och stabilitet. Förbättringar som redan nu planerats till restlistan handlar framför allt om systemets användbarhet. Eftersom systemet skall generera statistiskt material är det av högsta vikt att klientens utformning inte förvränger statistiken. Användarna ska inte fås att göra felaktiga inmatningar p g a dåligt formulerade instruktioner eller dåligt utformade systeminteraktioner. 20 Kapitel 6: Acceptanstestrapport

29 7 Referenser Referenser till dokument med engelsk titel, sker i texten med den svenska översättningen av denna titel, för att undvika förvirrande svengelska. 7.1 Externa dokument [Kaminski, 2003] - Bra dokument. ( ) vid Linköpings universitet, Linköping. [Ostrand, 2002] Ostrand, Thomas J. (2002), The distribution of Faults in Large Industrial Software System, AT&T Labs - Research, New Jersey. [Wilander, 2003] Wilander, John, Some Notes on Software Testing, ( ) vid Linköpings universitet, Linköping. 7.2 Interna dokument [Johansson, 2003] Johansson, Robert (2003), Design specification, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. [Larsson, 2003] Larsson, Lars (2003), Requirement specification, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. [Rosén, 2003] Rosén, Gustav (2003), Project plan, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. [Svärd, 2003] Svärd, Mikael (2003), Testplan, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. [Årstrand, 2003] Årstrand, Christoffer (2003), User s manual, Institutionen för datavetenskap (IDA) vid Linköpings universitet, Linköping. Kapitel 7: Referenser 21

30 22 Kapitel 7: Referenser

31 Appendix A Indata till testfall I denna bilaga finns rekommendationer om de indata som skall användas i testerna. Med indata menas inte bara de data som ges som argument till de metoder som skall testas, utan även de data som en metod opererar på efter att ha blivit anropad. Inga konkreta indata ges, då det skiljer sig mycket från fall till fall vad som är intressant att ge som indata för att få en bra testning. Det är upp till testaren ge relevanta indata i testfallen. Dessa kommer dock inte vara framtagna "ad hoc" av testaren, då denna skall följa riktlinjerna i avsnitt A.2. Kreativitet vid framtagning av indata förespråkas dock. A.1 Allmänt I detta avsnitt ges motiveringar till varför indata tas fram som avsnitt A.2 specificerar. A.1.1 Partition testing Anta att funktionen f definieras som den metod som är föremål för ett testfall. All möjlig indata till f utgör då en mängd. Mängdens omfattning är ofta för stor för att en perfekt, alltså en heltäckande, testning av f skall kunna utföras. För att få en så heltäckande testning som möjligt utan att testa alla möjliga indata är det vanligt att dela upp indata i partitioner. Varje subdomän till mängden av alla möjliga indata till f utformas så att den utgör en ekvivalensklass. Med detta menas att metoden förväntas reagera på ett likadant sätt för alla indata i ekvivalensklassen. Varje subdomän tjänar sedan som en källa till indata. För att anse sig ha täckt hela domänen av indata är det nödvändigt och även tillräckligt att ta minst ett indata från varje subdomän, förutsatt att dessa utgörs av ekvivalensklasser. Den typ av testning som beskrivs ovan, då målet är att täcka alla ekvivalensklasser kallas "partition testning". A.1.2 BVA I ovanstående stycke föreskrevs en uppdelning av indata i ekvivalensklasser för att täcka mängden av indata på ett bra sätt. Hur skall då denna uppdelning göras? En metod är att använda s k "Boundary Value Analysis". Denna metod föreskriver en uppdelning av indata i ekvivalensklasser baserat på de villkor som ställs på indatan. Man studerar helt enkelt de "boundary values" eller de gränsvärden som är satta på indatan. Är till exempel indatan alla positiva tal kan tre ekvivalensklasser snabbt tas fram: Alla negativa tal, alla positiva tal och gränsvärdet 0. Observera att två av dessa tillhör mängden av otillåtna indata. Är det då tillräckligt med endast ett tillåtet indata vid ett test? Mängden av tillåtna indata kan på nytt delas upp i ekvivalensklasser. Hur reagerar t ex en metod på ett mycket stort heltal? Detta resulterar i en ny uppdelning och vi kan anta att vi sluter oss till mängderna: m111={x x<0}, m112={x=0}, m113={x 0<x< } och m114={x x> }. Till detta bör även inkorrekta indata (indata av fel typ) adderas. A.2 Riktlinjer för framtagande av indata Villkoren på de indata som specificeras för en viss metod används för uppdelning av indata i partitioner. Appendix A: Indata till testfall 1

32 1. Starta med mängden m, som utgörs av alla typer (int, string o s v) och mängden d som är den tomma mängden. 2. Dela upp mängden i de två delmängderna m1 och m2, som utgörs av alla typer som utgör korrekt respektive felaktig typ av indata. 3. Ta fram minst ett indata ur m2. Detta indata representerar ett indata av felaktig typ. Addera erhållna indata till d. 4. Dela upp m1 i två nya delmängder; m11 och m12. Dessa skall utgöra mängden av tillåtna indata respektive mängden av otillåtna indata. Båda mängderna utgörs dock nu av indata med rätt typ. 5. Studera mängden av otillåtna indata; m12. Om denna utgörs av uppenbara delmängder (från exemplet ovan: x=0 och x<0) så väljs ett indata ur varje delmängd. Om så inte är fallet väljs endast ett element ur m12. Addera erhållna indata till d. 6. Studera nu mängden m11, som skall utgöras av alla indata av rätt typ som dessutom är tillåtna. Försök att dela upp m11 i delmängder m111, m112,..., m11n. Dessa delmängder skall utgöra ekvivalensklasser även de*. 7. Välj nu minst ett indata ur varje delmängd m111, m112,..., m11n. Om antalet mängder endast är en eller ett par, så rekommenderas att mer än ett indata ur dessa mängder tas. Addera erhållna indata till d. Den erhållna mängden d skall utgöras av: Minst ett indata från en felaktig typ. Minst ett indata från varje funnen ekvivalensklass av indata från rätt typ, men som är otillåten. Minst ett indata från varje funnen ekvivalensklass av indata som är tillåten. *Observera att definitionen på en ekvivalensklass var en mängd där alla indata förväntas ge samma reaktion hos metoden. I vårt fall skall detta tolkas till att det dels skall göras en uppdelning, av tillåtna indata, i ekvivalensklasser baserat på beskrivningen av indata, enligt BVA. Att stanna här vore att endast utföra s k "svartlådetestning". När denna uppdelning är gjord skall även en uppdelning göras baserat på metodens "inre" reaktion. Så många "branches" och "statements" som möjligt skall exekveras. Detta innebär att s k "vitlådetestning" utförs. Läs mer om dessa testmetoder i testplanen. 2 Appendix A: Indata till testfall

33 Appendix B Modultestskript I denna bilaga finns testskripten från modultestningen. B.1 Allmänt Alla tester utförs på den testdator som finns att tillgå på IDA. På denna testdator finns Windows XP och Sun One Studio installerat. Till varje modul som skall testas finns en klass. Denna "testklass" representerar ett modultest. I varje testklass finns ett antal metoder. Varje metod representerar ett testfall på den modul som skall testas. I varje testklass finns en main-metod. Testfallen görs genom att köra modultestet (testklassen) och i anropa de olika testfallen (metoderna) från main-metoden. Om inget annat anges testas testfallen i nummerordning för varje modul. B.2 Förberedelser Förberedelserna inför ett modultest görs genom att följa nedanstående steg. Om andra förberedelser krävs anges detta i det aktuella testskriptet. 1. Starta Sun One Studio. 2. Verifiera att uppdaterade version av program- och testmoduler finns tillgängliga lokalt. Om så inte är fallet kan avsnittet om Sun One Studio och hur en CVS-server används studeras i programmeringshandboken [Årstrand, Akhvlediani, 2003] för att nå test- och programklasser. Dessa skall dock finnas tillgängliga vid start av Sun One Studio. 3. Öppna den testklass som skall användas. Testklassen har namnet "MT_<modul som skall testas>.class". B.3 Genomförande Ett modultest genomförs genom att följa nedanstående steg. Om genomförandet ser annorlunda ut anges detta i det aktuella testskriptet. 1. Leta upp den metod som representerar det testfall som skall utföras. Metoden har namn efter sin testfallsbeteckning. Till exempel har testfall MT-2.14 namnet "MT_2_14". De övriga testfallen följer samma namngivningskonvention. 2. Verifiera att den kod som finns i metoden representerar det aktuella testskriptet. 3. Leta upp main-metoden. 4. Använd de verktyg för generering av indata som finns tillgängliga i metoden och gör ett anrop till den metod som skall köras. Variera indata som skapas i main-metoden och objekt som skapas i den aktuella metoden, allt enligt vad testskriptet föreskriver. 5. Kompilera och kör den aktuella testklassen. 6. Studera resultatet av ovanstående punkt och för dessa observationer till testprotokollet. 7. Om alla variationer på indata har genomgåtts, gå till nästa punkt. Hoppa annars till punkt 4. Appendix B: Modultestskript 1

34 8. Om alla testfall har genomgåtts, gå till nästa punkt. Hoppa annars till punkt Modultestet klart. B.4 Efterarbete Dokumentera utfallet av testerna i en testrapport och använd vid behov felrapporterna. När modultestet är avslutat uppdateras CVS-servern med de modifierade testklasserna. Glöm inte att skicka med kommentarer om vem som gjort ändringarna i testklasserna om detta har gjorts. Därefter skall Sun One Studio avslutas. B.5 Konfigurationsmodulen Förberedelser Förberedelser enligt avsnitt B.2. Dessutom måste instanser av klasserna ConfigManager och ConfigPlugin skapas. Efterarbete Efterarbete enligt avsnitt B.4. Testskript Testfallen utförs enligt avsnitt B.3, med nedanstående instruktioner. B.5.1 MT Använd metoden getvalues på alla konfigurationstyper som är flervärdiga. 2. Skriv ut resultatet av tidigare punkt på skärmen. 3. Anropa setvalues med indata enligt appendix A. Upprepa för alla konfigurationstyper som är flervärdiga. 4. Använd metoden getvalues på alla konfigurationstyper som ändrats. 5. Skriv ut resultatet av tidigare punkt på skärmen. 6. Studera resultaten från punkt 4 och 7. Utskriften från punkt 4 skall vara det initiala tillståndet, definierat i designspecifikationen. Resultatet från punkt 7 skall vara i enlighet med de inmatade data från punkt Fyll i testprotokoll. B.5.2 MT Använd metoden getvalue på alla konfigurationstyper som är enkelvärdiga. 2. Skriv ut resultatet av tidigare punkt på skärmen. 3. Anropa setvalue med indata enligt appendix A. Upprepa för alla konfigurationstyper som är enkel-värdiga. 4. Använd metoden getvalue på alla konfigurationstyper. 5. Skriv ut resultatet av tidigare punkt på skärmen. 6. Studera resultaten från punkt 4 och 7. Utskriften från punkt 4 skall vara det initiala tillståndet, definierat i designspecifikationen. Resulta- 2 Appendix B: Modultestskript

35 tet från punkt 7 skall vara i enlighet med de inmatade data från punkt Fyll i testprotokoll. B.6 Projekthanteringsmodulen Förberedelser Förberedelser enligt avsnitt B.2. Dessutom måste instanser av klasserna ConfigManager, ConfigPlugin, ProjectManager och ProjectStoragePlugin skapas. Testfall MT-1.12 kräver även att en instans av ProjectBuilder skapas. Efterarbete Efterarbete enligt avsnitt B.4. Testskript Testfallen utförs enligt avsnitt B.3, med nedanstående instruktioner. B.6.1 MT Om det inte finns en uppsättning projekt och tester så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden listprojectsandtests. 3. Skriv ut innehållet i hashtabell som returneras från punkt 2. Detta görs genom att plocka ut innehållet genom hashtabell-access och sedan skriva ut namnen på projekten och testerna. 4. Resultatet från punkt 3 skall vara i enlighet med den katalogstruktur som studerades i punkt Fyll i testprotokoll. B.6.2 MT Om det inte finns en uppsättning projekt så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden listprojects. 3. Skriv ut innehållet i hashtabell som returneras från punkt 2. Detta görs genom att plocka ut innehållet genom hashtabell-access och sedan skriva ut namnen på projekten. 4. Resultatet från punkt 3 skall vara i enlighet med den katalogstruktur som studerades i punkt Fyll i testprotokoll. B.6.3 MT Om det inte finns en uppsättning projekt så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden isuniqueprojectname. Variera indata enligt appendix A. Appendix B: Modultestskript 3

36 3. Resultatet från punkt 2 skall överensstämma med den katalogstruktur som togs fram i punkt 1. Om en namnkrock sker skall false returneras, annars true. 4. Fyll i testprotokoll. B.6.4 MT Om det inte finns en uppsättning projekt och tester så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden duplicateproject. Variera indata enligt appendix A. 3. Studera nu katalogstrukturen. Denna skall överensstämma med de indata som givits i punkt 2. Ett nytt projekt skall ha skapats och namnet på detta skall vara korrekt. 4. Fyll i testprotokoll. B.6.5 MT Om det inte finns en uppsättning projekt så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden renameproject. Variera indata enligt appendix A. 3. Studera nu katalogstrukturen. Denna skall överensstämma med de indata som givits i punkt 2. Det angivna projekt skall ha skapats och namnet på detta skall vara korrekt. 4. Fyll i testprotokoll. B.6.6 MT Om det inte finns en uppsättning projekt och tester så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden closeproject. Variera indata enligt appendix A. 3. Studera nu katalogstrukturen. Denna skall överensstämma med de indata som givits i punkt 2. Det angivna projekt skall ha flyttats från active till closed. Studera vidare det inre tillståndet hos projektet genom att använda metoden openprojectpassive och sedan ta fram tillståndet med metoden getstate i Project. Tillståndet skall vara closed. 4. Fyll i testprotokoll. B.6.7 MT Om det inte finns en uppsättning projekt och tester så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden activateproject. Variera indata enligt appendix A. 3. Studera nu katalogstrukturen. Denna skall överensstämma med de indata som givits i punkt 2. Det angivna projekt skall ha flyttats från dynamic till active. Studera vidare det inre tillståndet hos projektet genom att använda metoden openprojektpassive och sedan ta fram tillståndet med metoden getstate i Project. Tillståndet skall vara active. 4. Fyll i testprotokoll. 4 Appendix B: Modultestskript

37 B.6.8 MT Om det inte finns en uppsättning projekt och tester så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden activateproject. Variera indata enligt appendix A. 3. Studera nu katalogstrukturen. Denna skall överensstämma med de indata som givits i punkt 2. Det angivna projekt skall ha flyttats från closed till active. Studera vidare det inre tillståndet hos projektet genom att använda metoden openprojektpassive och sedan ta fram tillståndet med metoden getstate i Project. Tillståndet skall vara active. 4. Fyll i testprotokoll. B.6.9 MT Om det inte finns en uppsättning projekt och tester så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden deleteproject. Variera indata enligt appendix A. 3. Studera nu katalogstrukturen. Denna skall överensstämma med de indata som givits i punkt 2. Det angivna projekt skall ha tagits bort från closed. 4. Fyll i testprotokoll. B.6.10 MT Använd metoden newproject. Variera indata enligt appendix A. 2. Skriv ut det inre tillståndet hos projektet som skapades i punkt 1, genom att använda get-metoder i Project. 3. Använd metoden saveproject. Resultatet av punkt 1 ges som indata. 4. Använd metoden openproject. Referera till det tidigare skapade projektet. 5. Skriv ut det inre tillståndet hos projektet som skapades i punkt 1, genom att använda get-metoder i Project. 6. Resultatet av punkt 1 skall vara att ett nytt projekt skapas enligt givet indata. Detta project skall även finnas bundet vid attributet current- Project i ProjectBuilder. Studera nu katalog strukturen. Denna skall innehålla det nya projektet, som ett resultat av punkt 3. Dessutom skall resultaten av punkt 2 och 5 vara konsistenta. 7. Fyll i testprotokoll. B.6.11 MT Om det inte finns en uppsättning projekt och tester så skapa dessa och verifiera att dessa finns i den lokala katalogstruturen. Katalogstrukturen skall varieras enligt appendix A. 2. Använd metoden openprojectpassive. Variera indata enligt appendix A. 3. Skriv ut namnet på de test hos projektet som skapades i punkt 1, genom att använda get-metoder i Project och Test. 4. Studera nu katalogstrukturen. Resultatet från punkt 3 skall vara konsistent med denna. 5. Fyll i testprotokoll. Appendix B: Modultestskript 5