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

Storlek: px
Starta visningen från sidan:

Download "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

STUM. Övergripande Testplan. Sammanfattning. Redaktör: Thomas Janowski Version: Syntetiskt tal utan modulering

STUM. Övergripande Testplan. Sammanfattning. Redaktör: Thomas Janowski Version: Syntetiskt tal utan modulering STUM Syntetiskt tal utan modulering Övergripande Testplan Redaktör: Version: 1.1 Sammanfattning Detta är en övergripande testplan som i stora drag beskriver planerade testfaser och testaktiviteter under

Läs mer

Inspektionshandbok. Sammanfattning. Redaktör: Filip Klasson Version: 1.1 Datum: I Tal-Lab kan ingen höra dig skrika

Inspektionshandbok. Sammanfattning. Redaktör: Filip Klasson Version: 1.1 Datum: I Tal-Lab kan ingen höra dig skrika I Tal-Lab kan ingen höra dig skrika Inspektionshandbok Redaktör: Version: 1.1 Datum: Sammanfattning Detta dokument är till för att underlätta arbetet inför och under en inspektion Projektidentitet Projektgrupp

Läs mer

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

Testplan. Sammanfattning. Redaktör: Thomas Janowski Version: I Tal-Lab kan ingen höra dig skrika Testplan Redaktör: Version: 1.1 I Tal-Lab kan ingen höra dig skrika Sammanfattning STUM är ett system för talsyntes. Det utvecklas åt avdelningen för Human- Centered Systems (HCS) vid (IDA) vid Linköpings

Läs mer

Systemförvaltning. Sammanfattning. Redaktör: Kjell Enblom Version: 1.0 Datum: I Tal-Lab kan ingen höra dig skrika

Systemförvaltning. Sammanfattning. Redaktör: Kjell Enblom Version: 1.0 Datum: I Tal-Lab kan ingen höra dig skrika I Tal-Lab kan ingen höra dig skrika Systemförvaltning Redaktör: Version: 1.0 Datum: Sammanfattning STUM är ett system för talsyntes. Det utvecklades åt avdelningen för Human- Centered Systems (HCS) vid

Läs mer

Kravspecifikation. Sammanfattning. Redaktör: Patrik Sandström Version: 2.0 Datum: I Tal-Lab kan ingen höra dig skrika

Kravspecifikation. Sammanfattning. Redaktör: Patrik Sandström Version: 2.0 Datum: I Tal-Lab kan ingen höra dig skrika I Tal-Lab kan ingen höra dig skrika Kravspecifikation Redaktör: Version: 2.0 Datum: Sammanfattning Projektgruppen Pum-grupp 1 skall utveckla ett system för talsyntes åt avdelningen för Human-Centered Systems

Läs mer

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

Testrapport. Redaktör: Mikael Svärd Version: 1.0 Datum: Sammanfattning Redaktör: Version: 1.0 Datum: 2003-05-12 Sammanfattning Detta dokument utvärderar och beskriver resultatet av testningen av produkten Audio Jury utvecklas av i kursen TDDB61 Programvaruutveckling i ett

Läs mer

Kvalitetsrapport I. Sammanfattning. Redaktör: Filip Klasson Version: 1.1 Datum: I Tal-Lab kan ingen höra dig skrika

Kvalitetsrapport I. Sammanfattning. Redaktör: Filip Klasson Version: 1.1 Datum: I Tal-Lab kan ingen höra dig skrika I Tal-Lab kan ingen höra dig skrika Kvalitetsrapport I Redaktör: Version: 1.1 Datum: Sammanfattning Kvalitetsrapport I beskriver de kvalitetsrelaterade moment som utförts under perioden 20050825-20050927

Läs mer

Kvalitetsrapport III. Sammanfattning. Redaktör: Filip Klasson Version: 1.0 Datum: I Tal-Lab kan ingen höra dig skrika

Kvalitetsrapport III. Sammanfattning. Redaktör: Filip Klasson Version: 1.0 Datum: I Tal-Lab kan ingen höra dig skrika I Tal-Lab kan ingen höra dig skrika Kvalitetsrapport III Redaktör: Version: 1.0 Datum: Sammanfattning Kvalitetsrapport III beskriver de kvalitetsrelaterade moment som utförts under perioden 2005-11-07

Läs mer

Efterstudie. Sammanfattning. Redaktör: Gustav Veide Version: I Tal-Lab kan ingen höra dig skrika

Efterstudie. Sammanfattning. Redaktör: Gustav Veide Version: I Tal-Lab kan ingen höra dig skrika Efterstudie Redaktör: Version: 1.0 I Tal-Lab kan ingen höra dig skrika Sammanfattning Detta dokument sammanfattar erfarenheterna från det projekt som PUMgrupp 1 utfört i kursen TDDC02, Programutvecklingsprojekt

Läs mer

Några grundläggande begrepp

Några grundläggande begrepp Några grundläggande begrepp Validering bygger vi rätt system? Uppfyller kravspecifikationen de verkliga behoven? Verifiering bygger vi systemet rätt? Uppfyller det färdiga systemet kravspecifikationen?

Läs mer

Testning av program. Verklig modell för programutveckling

Testning av program. Verklig modell för programutveckling Fel i program När man skriver program uppkommer alltid fel. Felen kan indelas i följande kategorier: Under kompileringen upptäcker kompilatorn fel som handlar om att man använt konstruktionerna i programspråket

Läs mer

LiTH. WalkCAM 2007/05/15. Testplan. Mitun Dey Version 1.0. Status. Granskad. Godkänd. Reglerteknisk projektkurs WalkCAM LIPs

LiTH. WalkCAM 2007/05/15. Testplan. Mitun Dey Version 1.0. Status. Granskad. Godkänd. Reglerteknisk projektkurs WalkCAM LIPs Testplan Mitun Dey Version 1.0 Status Granskad Godkänd 1 PROJEKTIDENTITET Reglerteknisk projektkurs, WalkCAM, 2007/VT Linköpings tekniska högskola, ISY Namn Ansvar Telefon E-post Henrik Johansson Projektledare

Läs mer

Kvalitetsplan. Sammanfattning. Redaktör: Filip Klasson Version: 1.3 Datum: I Tal-Lab kan ingen höra dig skrika

Kvalitetsplan. Sammanfattning. Redaktör: Filip Klasson Version: 1.3 Datum: I Tal-Lab kan ingen höra dig skrika I Tal-Lab kan ingen höra dig skrika Kvalitetsplan Redaktör: Version: 1.3 Datum: Sammanfattning Kvalitetsplanen har tagits fram för att beskriva det kvalitetsarbete som skall utföras av PUM-grupp 1 i kursen

Läs mer

Projektplan. Sammanfattning. Redaktör: Ali Aghajani Version: I Tal-Lab kan ingen höra dig skrika

Projektplan. Sammanfattning. Redaktör: Ali Aghajani Version: I Tal-Lab kan ingen höra dig skrika Projektplan Redaktör: Version: 2.2 I Tal-Lab kan ingen höra dig skrika Sammanfattning Projektgruppen har fått till uppgift att skriva en modul till systemet Orator, en mjukvara för talsyntes. Modulen ska

Läs mer

Konsultbolag1. Testplan för Europa version 2. Testplan Projekt Europa Sid 1 (av 9) 2009-05-14. Europa-projektet. Dokumenthistorik

Konsultbolag1. Testplan för Europa version 2. Testplan Projekt Europa Sid 1 (av 9) 2009-05-14. Europa-projektet. Dokumenthistorik Testplan Projekt Europa Sid 1 (av 9) Europa-projektet Testplan för Europa version 2 Dokumenthistorik Utgåva Datum Författare Kommentar 1 2008-12-16 Ulf Eriksson Ursprunglig version, utkast 2 2008-12-18

Läs mer

Testplan Cykelgarage

Testplan Cykelgarage Testplan Cykelgarage Stefan Johansson D08 (dt08sj7@student.lth.se) Johan Anderholm D08 (dt08ja5@student.lth.se) Angelica Gabasio D08 (dt08ag8@student.lth.se) Marcus Carlberg D08 (dt08mc4@student.lth.se)

Läs mer

Kravspecifikation. LiTH Segmentering av MR-bilder med ITK Anders Eklund Version 1.0. Status

Kravspecifikation. LiTH Segmentering av MR-bilder med ITK Anders Eklund Version 1.0. Status 2006-02-02 Kravspecifikation Version.0 Status Granskad Godkänd Bilder och grafik projektkurs, CDIO MCIV LIPs 2006-02-02 PROJEKTIDENTITET MCIV 2006 VT Linköpings Tekniska Högskola, CVL Namn Ansvar Telefon

Läs mer

LiTH Segmentering av MR-bilder med ITK Efterstudie MCIV. Anders Eklund. Status

LiTH Segmentering av MR-bilder med ITK Efterstudie MCIV. Anders Eklund. Status Segmentering av MR-bilder med ITK 2006-05-15 Efterstudie MCIV Status Granskad Godkänd Bilder och grafik projektkurs, CDIO MCIV LIPs 1 Segmentering av MR-bilder med ITK 2006-05-15 PROJEKTIDENTITET MCIV

Läs mer

Testprotokoll. Redaktör: Sofie Dam Version 0.1. Status. Planering och sensorfusion för autonom truck Granskad Dokumentansvarig - Godkänd

Testprotokoll. Redaktör: Sofie Dam Version 0.1. Status. Planering och sensorfusion för autonom truck Granskad Dokumentansvarig - Godkänd Redaktör: Sofie Dam Version 0.1 Status Granskad Dokumentansvarig - Godkänd 1 GruppTruck Projektidentitet 2017/HT, GruppTruck Tekniska högskolan vid Linköpings universitet, ISY Gruppdeltagare Namn Ansvar

Läs mer

Projektplan. LiTH Segmentering av MR-bilder med ITK Anders Eklund. Version 1.0. Status. Bilder och grafik projektkurs, CDIO MCIV LIPs

Projektplan. LiTH Segmentering av MR-bilder med ITK Anders Eklund. Version 1.0. Status. Bilder och grafik projektkurs, CDIO MCIV LIPs Segmentering av MR-bilder med ITK 2006-02-02 Projektplan Version 1.0 Status Granskad Godkänd Bilder och grafik projektkurs, CDIO MCIV LIPs 1 PROJEKTIDENTITET MCIV 2006 VT Linköpings Tekniska Högskola,

Läs mer

Arkitekturspecifikation

Arkitekturspecifikation I Tal-Lab kan ingen höra dig skrika Arkitekturspecifikation Redaktör: Version: 1.0 Datum: Sammanfattning STUM är ett system för talsyntes. Det utvecklas åt avdelningen för Human- Centered Systems (HCS)

Läs mer

Kapitel 4 Arkivmenyn Innehåll

Kapitel 4 Arkivmenyn Innehåll Kapitel 4 Arkivmenyn Innehåll ARKIVMENYN...2 Byt aktuell användare...2 Utskrift till skärm eller skrivare...3 SQL verktyget...4 Ny SQL...4 Hämta SQL...5 Spara SQL...5 Kör SQL...5 Visa som...5 Avsluta...5

Läs mer

Inlämningsuppgifter, EDAF30, 2015

Inlämningsuppgifter, EDAF30, 2015 LUNDS TEKNISKA HÖGSKOLA Institutionen för datavetenskap Programmering i C++ Inlämningsuppgifter, EDAF30, 2015 Det finns två deluppgifter som båda ska lösas: 1. skriv ett program för att hantera bankkonton

Läs mer

LiTH 7 december 2011. Optimering av hjullastare. Testplan. Per Henriksson Version 1.0. LIPs. TSRT10 testplan.pdf WHOPS 1. tsrt10-vce@googlegroups.

LiTH 7 december 2011. Optimering av hjullastare. Testplan. Per Henriksson Version 1.0. LIPs. TSRT10 testplan.pdf WHOPS 1. tsrt10-vce@googlegroups. Testplan Per Henriksson Version 1.0 1 Status Granskad - Godkänd - 2 Projektidentitet Optimering av Hjullastare HT2011 Linköpings Tekniska Högskola, ISY Namn Ansvar Telefon E-post Per Henriksson Projektledare

Läs mer

Filhanterare med AngularJS

Filhanterare med AngularJS Filhanterare med AngularJS Författare: Filip Johansson Peter Emilsson Oskar Georgsson Christian Nilsson Datum: 2014-03-26 1 Sammanfattning Filhanterare med AngularJS är en filhanterare skapad för Sigma

Läs mer

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU

TDDI02. Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU TDDI02 Programmeringsprojekt. Föreläsning 3 Jonas Lindgren, Institutionen för Datavetenskap, LiU På denna föreläsning: Verifikation, Validering och Testning XP Extreme Programming Vad är ett fel? I engelskan

Läs mer

Bilaga KeyControl Felsökning

Bilaga KeyControl Felsökning Bilaga: Felsökning 1. Allmänt Genom att ge så detaljerad information som möjligt om problemet och de operationer som föregick problemet underlättas supporten. Du viktigaste komponenterna är - Operativsystemet

Läs mer

Objektorienterad programmering i Java I. Uppgifter: 2 Beräknad tid: 5-8 timmar (OBS! Endast ett labbtillfälle) Att läsa: kapitel 5 6

Objektorienterad programmering i Java I. Uppgifter: 2 Beräknad tid: 5-8 timmar (OBS! Endast ett labbtillfälle) Att läsa: kapitel 5 6 Laboration 2 Objektorienterad programmering i Java I Uppgifter: 2 Beräknad tid: 5-8 timmar (OBS! Endast ett labbtillfälle) Att läsa: kapitel 5 6 Syfte: Att kunna använda sig av olika villkors- och kontrollflödeskonstruktioner

Läs mer

Uppgift v1: Teststrategi i sammanhang Terese Berger. Teststrategi. Projekt CiviCRM. Version 0.9. Sida 1(7)

Uppgift v1: Teststrategi i sammanhang Terese Berger. Teststrategi. Projekt CiviCRM. Version 0.9. Sida 1(7) Teststrategi Projekt CiviCRM Version 0.9 Sida 1(7) Innehållsförteckning Referenser...2 Revisioner...2 1. Inledning...3 1.1 Uppgift...3 1.2 Bakgrund...3 1.3 Organisation...4 1.4 Granskning och godkännande...4

Läs mer

Testplan. Redaktör: Sofie Dam Version 0.1. Status. Planering och sensorfusion för autonom truck Granskad Dokumentansvarig - Godkänd

Testplan. Redaktör: Sofie Dam Version 0.1. Status. Planering och sensorfusion för autonom truck Granskad Dokumentansvarig - Godkänd Redaktör: Sofie Dam Version 0.1 Status Granskad Dokumentansvarig - Godkänd 1 GruppTruck Projektidentitet 2017/HT, GruppTruck Tekniska högskolan vid Linköpings universitet, ISY Gruppdeltagare Namn Ansvar

Läs mer

LiTH. WalkCAM 2007/05/15. Testrapport. Mitun Dey Version 1.0. Status. Granskad. Godkänd. Reglerteknisk projektkurs WalkCAM LIPs

LiTH. WalkCAM 2007/05/15. Testrapport. Mitun Dey Version 1.0. Status. Granskad. Godkänd. Reglerteknisk projektkurs WalkCAM LIPs Testrapport Mitun Dey Version 1.0 Status Granskad Godkänd 1 PROJEKTIDENTITET Reglerteknisk projektkurs, WalkCAM, 2007/VT Linköpings tekniska högskola, ISY Namn Ansvar Telefon E-post Henrik Johansson Projektledare

Läs mer

Översikt. Installation av EasyPHP 1. Ladda ner från http://www.easyphp.org/ Jag använder Release 5.3.4.0 2. Installera EasyPHP.

Översikt. Installation av EasyPHP 1. Ladda ner från http://www.easyphp.org/ Jag använder Release 5.3.4.0 2. Installera EasyPHP. Laboration 1 Översikt 1. Att komma igång med laborationsmiljön a. installera Aptana Studio 3 b. Installera EasyPHP 2. Testa lite programmering a. Testa enkla uppgifter b. Testa automatiskt 3. Skapa inloggningsformulär

Läs mer

LiTH Autonom styrning av mobil robot 2007-02-15. Projektplan. Martin Elfstadius & Fredrik Danielsson. Version 1.0

LiTH Autonom styrning av mobil robot 2007-02-15. Projektplan. Martin Elfstadius & Fredrik Danielsson. Version 1.0 Projektplan Martin Elfstadius & Fredrik Danielsson Version 1.0 Status Granskad Godkänd 1 PROJEKTIDENTITET Autonom styrning av mobil robot Vårterminen 2007 Linköpings Tekniska Högskola, ISY Namn Ansvar

Läs mer

Processbeskrivning Test

Processbeskrivning Test ProcIT-P-017 Processbeskrivning Test Lednings- och kvalitetssystem Fastställt av Sven Arvidson 2012-06-20 Innehållsförteckning 1 Inledning 3 1.1 Symboler i processbeskrivningarna 3 2 Testprocessen 4 2.1

Läs mer

Efterstudie. Redaktör: Jenny Palmberg Version 1.0. Status. LiTH Fordonssimulator. Granskad Godkänd. TSRT71 Jenny Palmberg

Efterstudie. Redaktör: Jenny Palmberg Version 1.0. Status. LiTH Fordonssimulator. Granskad Godkänd. TSRT71 Jenny Palmberg Efterstudie Redaktör: Version 1.0 Granskad Godkänd Status Sida 1 PROJEKTIDENTITET Grupp 1, 2006/VT, Linköpings Tekniska Högskola, ISY Gruppdeltagare Namn Ansvar Telefon E-post Simon Danielsson Kvalitetsansvarig

Läs mer

Testspecifikation. Henrik Hagelin TSRT10 - SEGWAY 6 december 2010 Version 1.0. Status:

Testspecifikation. Henrik Hagelin TSRT10 - SEGWAY 6 december 2010 Version 1.0. Status: Testspecifikation Henrik Hagelin TSRT10 - SEGWAY 6 december 2010 Version 1.0 Status: Granskad Alla 6 december 2010 Godkänd DOK, PL 6 december 2010 PROJEKTIDENTITET Segway, HT 2010 Tekniska högskolan vid

Läs mer

Exempel på verklig projektplan

Exempel på verklig projektplan Exempel på verklig projektplan Detta är ett exempel på en proffessionell projektplan hämtad ur verkliga livet. Den visas inte i sin fullständighet, det mesta är bortklippt, men strukturen och mycket av

Läs mer

Uppgraderingsinstruktion för Tekis-FB Avisering version 6.3.0

Uppgraderingsinstruktion för Tekis-FB Avisering version 6.3.0 Uppgraderingsinstruktion för Tekis-FB Avisering version 6.3.0 Allmänt Releasen omfattar uppgradering av Tekis Aviseringsprogram version 6.3.0 (för både Tekis-FIR och Tekis-KID avisering) samt databasuppgradering

Läs mer

Testprotokoll. LiTH Segmentering av MR-bilder med ITK Anders Eklund Version 1.0. Status

Testprotokoll. LiTH Segmentering av MR-bilder med ITK Anders Eklund Version 1.0. Status Segmentering av MR-bilder med ITK 2006-05-02 Testprotokoll Version 1.0 Status ranskad odkänd Bilder och grafik projektkurs, CDIO MCIV LIPs 1 Segmentering av MR-bilder med ITK 2006-05-02 PROJEKTIDENTITET

Läs mer

Uppgraderingsinstruktion för Tekis-FB Avisering version 6.3.1

Uppgraderingsinstruktion för Tekis-FB Avisering version 6.3.1 Uppgraderingsinstruktion för Tekis-FB Avisering version 6.3.1 Allmänt Releasen omfattar uppgradering av Tekis Aviseringsprogram version 6.3.1 (för både Tekis-FIR och Tekis-KID avisering) samt databasuppgradering

Läs mer

Kvalitetsplan. Redaktör: Johan Marnetoft Version: 1.0 Datum: Sammanfattning

Kvalitetsplan. Redaktör: Johan Marnetoft Version: 1.0 Datum: Sammanfattning Redaktör: Version: 1.0 Datum: 2003-02-02 Sammanfattning Denna kvalitetsplan är framtagen för att beskriva hur kvalitetsarbetet ska bedrivas inom projektet Audio Jury i kursen TDDB61 "Programvaruprojekt

Läs mer

Version 1.0. 2013-02-13 Testteam 4 Testledare: Patrik Bäck

Version 1.0. 2013-02-13 Testteam 4 Testledare: Patrik Bäck Version 1.0-2013-02-13 Testteam 4 Testledare: Patrik Bäck 0 Sammanfattning Testplanen är utarbetad som ett svar på Konsumentverkets förfrågningsunderlag avseende upphandling av ett nytt budget- och skuldsaneringssystem,

Läs mer

Testprotokoll Autonom målföljning med quadcopter

Testprotokoll Autonom målföljning med quadcopter Version 1.0 Robo Ptarmigan 3 december 2015 Status Granskad HC 2015-11-29 Godkänd Projektidentitet Gruppmail: Hemsida: Beställare: Kund: Kursansvarig: Projektledare: Handledare: karlo343@student.liu.se

Läs mer

PH Bicycle Storage 8000 Testplan

PH Bicycle Storage 8000 Testplan PH Bicycle Storage 8000 Testplan Projektdeltagare: Mattias Nordahl (dt07mn0@student.lth.se) Hannes Nevalainen (dt07hn2@student.lth.se) Daniel Olofsson (dt07do1@student.lth.se) Fredrik Andersson (dt07fa5@student.lth.se)

Läs mer

C++ Slumptalsfunktioner + switch-satsen

C++ Slumptalsfunktioner + switch-satsen C++ Slumptalsfunktioner + switch-satsen Veckans avsnitt består av ett antal lite udda funktioner man kan ha nytta av när man skriver program. Det är en slumptalsgenerator och lite annat smått och gott.

Läs mer

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson

Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson Rapport grupp 4 Software Engineering Kristoffer Eriksson Christer Oscarsson Andreas Dahlberg Martin Bengtsson 2009-10-29 Processer Sprinter Scrum har varit till stor hjälp för oss för att nå våra mål,

Läs mer

Testplan Autonom truck

Testplan Autonom truck Testplan Autonom truck Version 1.1 Redaktör: Joar Manhed Datum: 20 november 2018 Status Granskad Kim Byström 2018-11-20 Godkänd Andreas Bergström 2018-10-12 Projektidentitet Grupp E-post: Hemsida: Beställare:

Läs mer

emopluppen Användning av "Ant" Niklas Backlund Version: 1.4 ( 2002/04/26 07:27:52 UTC)

emopluppen Användning av Ant Niklas Backlund Version: 1.4 ( 2002/04/26 07:27:52 UTC) emopluppen Användning av "Ant" Version: 1.4 ( 2002/04/26 07:27:52 UTC) Niklas Backlund Sammanfattning Det här dokumentet handlar om programmet Ant, som är en byggmiljö för programutvecklingsprojekt. Dess

Läs mer

LiTH Autonom styrning av mobil robot 2007-03-26 Testplan Version 1.0 TSRT71-Reglertekniskt projektkurs Anders Lindgren L IPs

LiTH Autonom styrning av mobil robot 2007-03-26 Testplan Version 1.0 TSRT71-Reglertekniskt projektkurs Anders Lindgren L IPs Testplan Version 1.0 Status Granskad Godkänd TSRT71-Reglertekniskt projektkurs LIPs PROJEKTIDENTITET Autonom styrning av mobil robot Vårterminen 2007 Linköpings Tekniska Högskola, ISY Namn Ansvar Telefon

Läs mer

SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS

SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS SLUTRAPPORT: TEXAS HOLDEM 4 FRIENDS Individuellt Mjukvaruutvecklingsprojekt (Utvecklare av digitala tjänster) Den 1 juni 2011 ABSTRAKT Rapporten tar upp positiva och negativa erfarenheter som jag erhållit

Läs mer

Introduktion till programmering D0009E. Föreläsning 1: Programmets väg

Introduktion till programmering D0009E. Föreläsning 1: Programmets väg Introduktion till programmering D0009E Föreläsning 1: Programmets väg 1 Vad är en dator? En maskin vars beteende styrs av de innehållet (bitmönster) som finns lagrade i datorns minne (inte helt olikt förra

Läs mer

Laboration: Whitebox- och blackboxtesting

Laboration: Whitebox- och blackboxtesting Tilda11 höstterminen 2011 Laboration: Whitebox- och blackboxtesting Mål med laborationen Du ska lära dig begreppen white-box testing och black-box testing Du ska öva dig på att konstruera testfall Du ska

Läs mer

Konstruktion av datorspråk

Konstruktion av datorspråk Konstruktion av datorspråk Fö2: Funderingar kring hur man kan bedöma programspråk samt några fler detaljer i Ruby Peter Dalenius peter.dalenius@liu.se Institutionen för datavetenskap Linköpings universitet

Läs mer

Linköpings Tekniska Högskola Institutionen för Datavetanskap (IDA), Software and Systems (SaS) (c) Klas Arvidsson

Linköpings Tekniska Högskola Institutionen för Datavetanskap (IDA), Software and Systems (SaS) (c) Klas Arvidsson Linköpings Tekniska Högskola Institutionen för Datavetanskap (IDA), Software and Systems (SaS) (c) Klas Arvidsson 2012-01-14 Introduktion Det första du behöver veta om PintOS är att det är ett riktigt

Läs mer

Program. Kapitel make Program Interpreterande och kompilerande program

Program. Kapitel make Program Interpreterande och kompilerande program Kapitel 11 Program Detta kapitel är som synes mycket kort och nämner inte allt från föreläsningen. 11.1 Program Ett datorprogram är en samling instruktioner som beskriver något som en dator ska utföra.

Läs mer

HARALD Testprotokoll

HARALD Testprotokoll HARALD Testprotokoll Version 0.2 Redaktör: Patrik Sköld Datum: 9 maj 2006 Status Granskad Johan Sjöberg 2006-05-09 Godkänd - yyyy-mm-dd Projektidentitet Gruppens e-post: Beställare: Kund: Kursansvarig:

Läs mer

Testning. 1. Inledning

Testning. 1. Inledning Testning 1. Inledning I all ingenjörsmässig verksamhet är testning en vedertagen metod för att fastställa om en hypotes, konstruktion eller produkt är korrekt och fungerar som avsett. Datorprogram är ofta

Läs mer

SF Bio App. Repport. Test summary. 1- Syfte. 2. Produktöversikt. Författare: Zina Alhilfi Datum: Version: v1,0

SF Bio App. Repport. Test summary. 1- Syfte. 2. Produktöversikt. Författare: Zina Alhilfi Datum: Version: v1,0 Test summary SF Bio App. Repport Författare: Zina Alhilfi Datum: 2017-03-13 Version: v1,0 Granskad: Klar Ref: Test plan V1,0 Status: klar 1- Syfte Syftet med denna slutrapport är att redovisa vilka testaktiviteter

Läs mer

LEX INSTRUKTION LEX LDAP

LEX INSTRUKTION LEX LDAP LEX INSTRUKTION LEX LDAP Innehållsförteckning LEX INSTRUKTION LEX LDAP... 1 1 INLEDNING... 1 2 INSTALLATION... 2 3 LEXLDAPSERVICE - KLIENTEN... 3 3.1 HUVUDFÖNSTER... 3 3.2 INSTÄLLNINGAR... 4 3.2.1 Lex...

Läs mer

Filbeskrivningar ---------------- http://student.ing-steen.se/sql/ Eller på särskild CD skiva

Filbeskrivningar ---------------- http://student.ing-steen.se/sql/ Eller på särskild CD skiva Filbeskrivningar ---------------- http://student.ing-steen.se/sql/ Eller på särskild CD skiva OBS! Det finns ytterligare filer på Microsoft CD, som tillhör SQL 2000 Administration Self paced, vilka kan

Läs mer

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1

Bakgrund och motivation. Definition av algoritmer Beskrivningssätt Algoritmanalys. Algoritmer. Lars Larsson VT 2007. Lars Larsson Algoritmer 1 Algoritmer Lars Larsson VT 2007 Lars Larsson Algoritmer 1 1 2 3 4 5 Lars Larsson Algoritmer 2 Ni som går denna kurs är framtidens projektledare inom mjukvaruutveckling. Som ledare måste ni göra svåra beslut

Läs mer

Objektorienterad programmering i Java I

Objektorienterad programmering i Java I Laboration 0 Objektorienterad programmering i Java I Uppgifter: 2 Beräknad tid: ca 2 3 timmar Att läsa: sidan 45 52 Syfte: Att ladda hem och installera utvecklingsmiljön Att skriva ditt första Javaprogram

Läs mer

HARALD. Systemskiss. Version 0.3 Redaktör: Patrik Johansson Datum: 20 februari 2006. Status

HARALD. Systemskiss. Version 0.3 Redaktör: Patrik Johansson Datum: 20 februari 2006. Status HARALD Systemskiss Version 0.3 Redaktör: Patrik Johansson Datum: 20 februari 2006 Status Granskad Johan Sjöberg 2006-02-10 Godkänd - yyyy-mm-dd Projektidentitet Gruppens e-post: Beställare: Kund: Kursansvarig:

Läs mer

Programmering av NXT Lego- robot Labbrapport för programmering av en Lego- robot

Programmering av NXT Lego- robot Labbrapport för programmering av en Lego- robot KUNGLIGA TEKNISKA HÖGSKOLAN Programmering av NXT Lego- robot Labbrapport för programmering av en Lego- robot Josef Karlsson Malik 2015-09- 02 jkmalik@kth.se Introduktionskurs i datateknik (II0310) Sammanfattning

Läs mer

NetBeans 7. Avsikt. Projektfönster

NetBeans 7. Avsikt. Projektfönster NetBeans 7 Avsikt Att bekanta dig med NetBeans programmeringsmiljö, dvs att med hjälp av NetBeans 1. skapa ett nytt projekt 2. skriva in källkod (sparas som.java-fil) 3. kompilera (översätta) koden till

Läs mer

Efterstudie. LIPs. LiTH Autonom styrning av mobil robot Martin Elfstadius. Version 1.0. Status. TSRT71-Reglertekniskt projektkurs

Efterstudie. LIPs. LiTH Autonom styrning av mobil robot Martin Elfstadius. Version 1.0. Status. TSRT71-Reglertekniskt projektkurs Efterstudie Version 1.0 Status Granskad Godkänd TSRT71-Reglertekniskt projektkurs LIPs PROJEKTIDENTITET Autonom styrning av mobil robot Vårterminen 2007 Linköpings Tekniska Högskola, ISY Namn Ansvar Telefon

Läs mer

Värmedistribution i plåt

Värmedistribution i plåt Sid 1 (6) Värmedistribution i plåt Introduktion Om vi med konstant temperatur värmer kanterna på en jämntjock plåt så kommer värmen att sprida sig och temperaturen i plåten så småningom stabilisera sig.

Läs mer

Testning av applikationer

Testning av applikationer Tentamen, (20 YH-poäng) Plats: Övningstenta Tid: Övningstenta Tillåtna hjälpmedel: Papper, penna, suddgummi, linjal. Ej tillåtna hjälpmedel: Datorer, mobiltelefoner, surfplattor, miniräknare, böcker, anteckningar,

Läs mer

Systemskiss. LiTH AMASE Accurate Multipoint Acquisition from Stereovision Equipment. Jon Månsson Version 1.0

Systemskiss. LiTH AMASE Accurate Multipoint Acquisition from Stereovision Equipment. Jon Månsson Version 1.0 2006-02-15 Systemskiss Jon Månsson Version 1.0 Granskad Godkänd TSBB51 LIPs John Wood johha697@student.liu.se 1 PROJEKTIDENTITET VT2006, Linköpings tekniska högskola, ISY Namn Ansvar Telefon E-post Mikael

Läs mer

Test och kvalitetsrapport

Test och kvalitetsrapport Test och kvalitetsrapport Projektgrupp 1 Användaranpassat interface till Studiehandboken Version 1.0 Sida 2 av 231 Innehållsförteckning 3.1 Parter... 6 3.2 Dokumenthistorik... 7 3.3 Inledning... 7 3.3.1

Läs mer

NetBeans 5.5. Avsikt. Projektfönster

NetBeans 5.5. Avsikt. Projektfönster NetBeans 5.5 Avsikt Att bekanta dig med NetBeans programmeringsmiljö, dvs att med hjälp av NetBeans 1. skapa ett nytt projekt 2. skriva in källkod (sparas som.java-fil) 3. kompilera (översätta) koden till

Läs mer

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt

Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Sänk kostnaderna genom a/ ställa rä/ krav och testa effektivt Kravhantering / Testprocess - Agenda AGENDA Grundläggande kravhanteringsprocess. Insamling, dokumentation, prioritering, Test och förvaltning

Läs mer

LiTH, Reglerteknik Saab Dynamics. Testplan Collision avoidance för autonomt fordon Version 1.0

LiTH, Reglerteknik Saab Dynamics. Testplan Collision avoidance för autonomt fordon Version 1.0 LiTH, Reglerteknik Saab Dynamics Testplan Collision avoidance för autonomt fordon Version 1.0 Torbjörn Lindström 3 maj 2005 Granskad Godkänd Collision avoidance för autonomt fordon i Sammanfattning Testplan

Läs mer

Testplan. LiTH. Autopositioneringssystem för utlagda undervattenssensorer Martin Skoglund Version 1.1. Status

Testplan. LiTH. Autopositioneringssystem för utlagda undervattenssensorer Martin Skoglund Version 1.1. Status Autopositioneringssystem för utlagda undervattenssensorer 2007-05-04 LiTH Testplan Martin Skoglund Version 1.1 Status Granskad Godkänd testplan1.1.pdf 1 PROJEKTIDENTITET Autopositionering för utlagda undervattenssensorer,

Läs mer

TDDI16: Datastrukturer och algoritmer

TDDI16: Datastrukturer och algoritmer TDDI16: Datastrukturer och algoritmer Lab 3: Ordkedjor Höstterminen 2018 2018-05-14 1 Upplägg Första delen av instruktionen, avsnitt 2 till 6, innehåller en fullständig beskrivning av problemet utan några

Läs mer

SLUTRAPPORT RUNE TENNESMED WEBBSHOP

SLUTRAPPORT RUNE TENNESMED WEBBSHOP SLUTRAPPORT RUNE TENNESMED WEBBSHOP -05-30 Abstrakt Under 10 veckor har jag och Oskar Norling arbetat med att ta fram en webbshop-applikation till företaget Rune Tennesmed i Kalmar. I denna rapport tänker

Läs mer

Programmeringsteknisk översiktskurs för yrkeshögskoleprogram

Programmeringsteknisk översiktskurs för yrkeshögskoleprogram Programmeringsteknisk översiktskurs för yrkeshögskoleprogram Föreläsning 12 Våren 2005 Innehåll Palindrom Hur man hittar fel i program, debuggning Felhantering, hur man förhindrar program att krascha Ev.

Läs mer

LIPs Daniel Axehill ChrKr Projektdirektiv_Saab_v3 CKr

LIPs Daniel Axehill ChrKr Projektdirektiv_Saab_v3 CKr Daniel Axehill 2006-01-19 Sida 1 Projektnamn Beställare Daniel Axehill, ISY Projektledare Student Projektbeslut Torbjörn Crona, Daniel Axehill Projekttid Läsperiod 3-4, vårterminen 2006. Projektet klart

Läs mer

Systemskiss. Självetablerande sensornätverk med 3G och GPS. Version 0.2. Christian Östman Datum: 15 maj 2008

Systemskiss. Självetablerande sensornätverk med 3G och GPS. Version 0.2. Christian Östman Datum: 15 maj 2008 Systemskiss Självetablerande sensornätverk med 3G och GPS Version 0.2 Christian Östman Datum: 15 maj 2008 Status Granskad Johan Lundström 2008-02-08 Godkänd Projektidentitet Gruppens e-post: Hemsida: Beställare:

Läs mer

Laboration 1. "kompilera"-ikonen "exekvera"-ikonen

Laboration 1. kompilera-ikonen exekvera-ikonen Programmerade system I1 Syfte Laboration 1. Syftet med denna laboration är dels att göra dej bekant med de verktyg som kan vara aktuella i programmeringsarbetet, dels ge en första inblick i att skriva

Läs mer

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER TPFD Beskrivning Rev 4 1(10) TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER Anv.krav Terminologi Detaljkrav Konfigdok Hantera Utgåvor Projektplan Testplan Test-o-felrättning Ändringslogg Återst.

Läs mer

Vop handledning. Användarhandledning till Vop applikationen. UPPGJORD: Mattias Gyllsdorff GODKÄND:Mattias Gyllsdorff REV: A DATUM: 2010-12-08

Vop handledning. Användarhandledning till Vop applikationen. UPPGJORD: Mattias Gyllsdorff GODKÄND:Mattias Gyllsdorff REV: A DATUM: 2010-12-08 UPPGJORD: Mattias Gyllsdorff GODKÄND:Mattias Gyllsdorff REV: A DATUM: 2010-12-08 Vop handledning Användarhandledning till Vop applikationen Bring Technologies AB Innehållsförteckning 1 Introduktion...1

Läs mer

Vanliga frågor för VoiceXpress

Vanliga frågor för VoiceXpress Vanliga frågor för VoiceXpress 1) Hur stort ordförråd (vokabulär) innehåller VoiceXpress? VoiceXpress innehåller ett mycket omfattande ordförråd, och svaret på frågan varierar en aning beroende på hur

Läs mer

TDDC74 - Projektspecifikation

TDDC74 - Projektspecifikation TDDC74 - Projektspecifikation Projektmedlemmar: Namn Efternamn abcde123@student.liu.se Namn Efternamn abcde123@student.liu.se Handledare: Handledare handledare@ida.liu.se eller handledare@student.liu.se

Läs mer

Projektplan. LiTH AMASE 2006-02-15 Accurate Multipoint Acquisition from Stereovision Equipment. Johan Hallenberg Version 1.0

Projektplan. LiTH AMASE 2006-02-15 Accurate Multipoint Acquisition from Stereovision Equipment. Johan Hallenberg Version 1.0 AMASE 2006-02-15 Projektplan Johan Hallenberg Version 1.0 Granskad Godkänd 1 PROJEKTIDENTITET VT2006, AMASE Linköpings tekniska högskola, ISY Namn Ansvar Telefon E-post Mikael Karelid kundansvarig (KUN)

Läs mer

Mer om språk och Ruby

Mer om språk och Ruby Mer om språk och Ruby TDP007 Konstruktion av datorspråk Föreläsning 2 Peter Dalenius Institutionen för datavetenskap 2014-01-21 Översikt över dagens föreläsning 1. Hur kan man bedöma ett språk? 2. Enhetstestning

Läs mer

Synkronisering av kalenderdata

Synkronisering av kalenderdata Datavetenskap Jonas Lindelöw, Richard Löfberg Sten Hansson Bjerke, Anders Friberg Synkronisering av kalenderdata Oppositionsrapport, C/D-nivå 2006:07 1 Sammanfattat omdöme av examensarbetet Vi tycker att

Läs mer

Felhantering TDDD78, TDDE30, 729A

Felhantering TDDD78, TDDE30, 729A Felhantering TDDD78, TDDE30, 729A85 jonas.kvarnstrom@liu.se 2019 Felhantering 2 Ofta antar vi att allt ska fungera Alla filer vi behöver finns går att öppna Tillräckligt mycket minne finns Servrar som

Läs mer

Objektorienterad programmering Föreläsning 2

Objektorienterad programmering Föreläsning 2 Objektorienterad programmering Föreläsning 2 Copyright Mahmud Al Hakim mahmud@webacademy.se www.webacademy.se Agenda Inläsning av data via dialogrutor Repetitioner (While-satsen och For-satsen) Nästlade

Läs mer

SeaClean städbeställning via hyttelefonerna

SeaClean städbeställning via hyttelefonerna SeaClean städbeställning via hyttelefonerna version 1.0 99-10-29 MANUAL SEAPACER AB 1996 SNABBSTART SeaClean är ett system för städbeställning via hyttelefonerna. BESTÄLLNING VIA TELEFON Varje kommando

Läs mer

Introduktion till programmering, hösten 2011

Introduktion till programmering, hösten 2011 Föreläsning 1 Programmering är ett hantverk. Det betyder att man inte kan läsa sig till den förmågan, man måste träna och man tränar genom att skriva mer och mer avancerade program. Programmering förutsätter

Läs mer

Mer om språk och Ruby

Mer om språk och Ruby Mer om språk och Ruby TDP007 Konstruktion av datorspråk Föreläsning 2 Peter Dalenius Institutionen för datavetenskap 2017-01-17 2 Översikt 1. Hur kan man bedöma ett språk? 2. Enhetstestning 3. Likhet i

Läs mer

Installation av Butiksdata

Installation av Butiksdata Installation av Butiksdata Starta installationsfilen Butiksdata.exe eller kör installationen från CD-skivan/USB minnet. Följande dialoger visas. Tryck Next Ange registreringsuppgifter och vill man inte

Läs mer

Objektorienterad programmering D2

Objektorienterad programmering D2 Objektorienterad programmering D2 Laboration nr 2. Syfte Att få förståelse för de grundläggande objektorienterade begreppen. Redovisning Källkoden för uppgifterna skall skickas in via Fire. För senaste

Läs mer

LOTTA MANUAL. t.o.m. version Cederlund 2014-12-07

LOTTA MANUAL. t.o.m. version Cederlund 2014-12-07 LOTTA MANUAL t.o.m. version Cederlund 2014-12-07 Innehållsförteckning 1. Nedladdning, installation och start av programmet 2. Skapa en turnering 3. Lägga in spelare i programmet 3.1. Inmatning av spelare

Läs mer

Krav: * Filen MpUpdate.exe får inte köras när du startar denna uppdatering.

Krav: * Filen MpUpdate.exe får inte köras när du startar denna uppdatering. Uppdatera Mobilus Professional till version 2.0.1 Krav: * Filen MpUpdate.exe får inte köras när du startar denna uppdatering. * Filen MP.exe (Mobilus programmet) får inte användas* under tiden uppdateringen

Läs mer

Planering av ett större program, del 2 - for och listor. Linda Mannila

Planering av ett större program, del 2 - for och listor. Linda Mannila Planering av ett större program, del 2 - for och listor Linda Mannila 9.10.2007 Vad kan vi nu? Primitiva datatyper Tal, strängar, booleska värden Utskrift Indata Felhantering Funktioner och moduler (grunder)

Läs mer

Innehåll. Projekt Greed. Projekt definition. Projekt Greed En introduktion till projektmodellen LIPs

Innehåll. Projekt Greed. Projekt definition. Projekt Greed En introduktion till projektmodellen LIPs Innehåll Projekt Greed En introduktion till projektmodellen LIPs Före-fasen Under-fasen Efter-fasen Projekt Greed Utveckla en applikation för mobiltelefoner av tärningsspelet Greed Löses i projektform

Läs mer

Dokumentation och presentation av ert arbete

Dokumentation och presentation av ert arbete Dokumentation och presentation av ert arbete Reglerteknik Linköpings universitet Dagens föreläsning Första timmen Kursens mål Projektmodellen LIPS och dess användning i kursen Olika former av redovisning

Läs mer

Testplanering, test-first, testverktyg

Testplanering, test-first, testverktyg Testplanering, test-first, testverktyg Mats Skoglund Department of Computer and Systems Sciences Stockholm University/Royal Institute of Technology Stockholm, Sweden 12 mars 2007 Mats Skoglund Page 1(33)

Läs mer