Testplan Cykelgarage

Relevanta dokument
Kravspecifikation Cykelgarage

Kravspecifikation. Stefan Johansson D08 Grupp 15

Projektplan, Cykelgarage

PH Bicycle Storage 8000 Testplan

Exercise 1b: Requirements evaluation

Exercise 1b: Requirements Evaluation ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15

Exercise 1b: Requirements evaluation

Exercise 4a: Test 2 ETSA01 INGENJÖRSPROCESSEN 1 - METODIK VT15. Lund University Computer Science ETSA01 Ingenjörsprocessen - Metodik VT15 Exercise 1

Några grundläggande begrepp

Agil testning i SCRUM

Programvaruutveckling - Metodik 2016 Jonas Wisbrant

INGENJÖRSPROCESSEN METODIK ETSA01 VT13 JONAS WISBRANT

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

Agenda. Föreläsning 6: Utvärdering och om tentamen. Kursinformation

Agenda. Projektbeskrivning avsnitt 8: Acceptanstest - MS4 i korthet. Kursinformation

Agenda. Kursinformation. Manual för systemstart... Föreläsning 6: Utvärdering och om tentamen

Wittkopp. Primor 2000 Level 5

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

Agenda. Kursinformation. Manual för systemstart. Föreläsning 6: Summering och om tentamen. Målgrupp:

TPFD - TestPlan Före Design BESKRIVNING AV AKTIVITETER

Beröringsfri EM-läsare VDS

CAASE ROBUST KODLÅS FÖR ALLA DÖRRMILJÖER. 4 DIAX screw M5x16. 1 M5 DIAX skiftnyckel. 1 Varistor. Bakstycke: 105x80x45mm. Antal Beskrivning Bild

Wittkopp Primor 2000 Level

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

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

Version Testteam 4 Testledare: Patrik Bäck

Processbeskrivning Test

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

Beröringsfri EM-läsare VDS

Wittkopp Primor 2000 Level 15

Agenda. Föreläsning 6: Summering och om tentamen Kursinformation

PlantPuppy Räddaren för den som inte kan hålla växterna vid liv

Rapport Digitala Projekt EITF11 Grupp 4 Axel Sundberg, Jakob Wennerström Gille Handledare: Bertil Lindvall

Allmänna villkor avseende låst cykelparkering, Cykelstället.

Alla rättigheter till materialet reserverade Easec

Beröringsfri EM-läsare VDS

men borde vi inte också testa kraven?

Wittkopp Primor 2000 Level 15

TDDI02. Programmeringsprojekt, Föreläsning 2. Filip Strömbäck. Med utgångspunkt i tidigare slides av Jonas Lindgren

Detta har hänt... Föreläsning 2: Projektplanering & granskning. Pratat och provat kravhantering. Bildat projektgrupper :-) Skaffat litteratur?

Föreläsning 6. Utvärdering, om tenta, avrundning

Föreläsning 6. Utvärdering, om tenta, avrundning. Agenda. Kursinformation. Schemalagda kursmoment. Jonas Wisbrant. Kursinformation

ALM Live: Testfokus bättre mjukvarukvalitét med Visual Studio 2008 Team System

Verifiering & validering -

Unit testing methodology

men borde vi inte också testa kraven? Robert Bornelind

Pulsmätare med varningsindikatorer

Konstruktion av datorspråk

1 Kravspecifikation Snake App

Föreläsning 3 Verifiering och Validering

Testplan Autonom truck

Hemsidan här kan du bl a söka annan lägenhet och göra felanmälan direkt på hemsidan

Föreläsning 3 Verifiering och Validering

Är instruktionerna oklara, projektet rörigt och allmänt frustrerande?

Rekonditionering. EPIsafe 2 GSM. Art.nr Programversion x.x.x eller senare. Rev PA1 SE

Föreläsning 5 Processer, vidare utveckling

Föreläsning 5 Processer, vidare utveckling

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

Falck 6604 VaktFalk TeleLarm

Specifikationer i kompendiet Övningar på moodle.cs.lth.se Support Onsdag kl i E: (84?) Frågestund: F3

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

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

Kursinformation. Metodik för programvaruutveckling. Utvecklingsprocessen för programvara. Innehåll. Processmodell. Exempel

Hemtentamen: ETSA01 Ingenjörsprocessen för programvaruutveckling metodik

Hus 47 - Hjortvägen Hus 49 - Hammarbyvägen Hus 50 - Hammarbyvägen 40-54

Åtkomst Du kommer till ditt system via en webblänk som erhålles från oss. Via denna länk ges tillgång till sökning i bibliotekets katalog.

PIC-projekt: Kodlås till dörr

Exempel på verklig projektplan

Rutinbeskrivning Mallar för test

PROMI500 I N S T A L L A T I O N S A N V I S N I N G KODLÅS I KOMPAKT UTFÖRANDE MED INBYGGD BERÖRINGSFRI LÄSARE. PROMI500 Installationsmanual

Introduktion Vi har som uppgift att göra ett systemutvecklingsprojekt åt en kund. Målet är att tillfredställa alla behov denne kund har.

Installationsanvisning. Dokumenttyp Installationsanvisning Område Boss med delad databas

Interaktionsdesign - Prototyper. Användbarhetskrav

W i n T i. Uppgradering till version HRM

MANUAL. MEDICINSKT TANGENTBORD Compliance Standard K105C02-SWE. rev

Platina och kvalité. Rasmus Staberg, Teknisk direktör,

Riktlinje för säkerhetskrav vid upphandling av IT-stöd

Mer om kodkvalitet. Mer om kodkvalitet. Hur kan man jobba med kodkvalité? Hur kan man jobba med kodkvalité? Hur kan man jobba med kodkvalité?

Opponentrapport på examensarbete Utveckling av ett affärssystem med Unified Process av Therese Sundström.

Mer om språk och Ruby

TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 3. Verifikation, validering och testning

Inlämningsverktyget i Fronter för studenter

Migrering av applikationen AMM till molnet

Föreläsning 3. Programvaruutveckling för Stora System. Målsättning i programvaruprojekt. Fel och risker. Christin Lindholm

MANUAL RS-120/S GSM. Inkoppling av GSM-kort (Mobil 67) till larmsändaren RS-120/S

TDDI02. På denna föreläsning: Programmeringsprojekt, Föreläsning 3. Filip Strömbäck. Verifikation, validering och testning

R-CARD M5 PORTTELEFON HANDHAVANDE- INSTRUKTIONER

V!cto. Att tjäna pengar genom bättre testning med

Sammanfattningar Essentials of Software Engineering

RCO PORTTELEFON P-59 HANDHAVANDE- INSTRUKTIONER

Testplanering, test-first, testverktyg

AD Medical Academy presenterar

TDP003. Föreläsning 2. Filip Strömbäck

Välkommen till PlayStations värld. Få igång din PS4 med den här praktiska snabbhandledningen. Snabbhandledning. Svenska CUH-1004A

TDDC30 Programmering i Java, Datastrukturer och Algoritmer Lektion 5. Laboration 4 Lådplanering Exempel på grafik, ett avancerat program Frågor

PROJEKTRAPPORT EDA095 NÄTVERKSPROGRAMMERI

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

AD Medical Academy presenterar

Manual ThanGram Manuell programmering, sida 1-2. Håll in PROG-knappen i centralen under 3 sekunder. Den gula lampan tänds.

Transkript:

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) Jon Andersen D08 (dt08ja8@student.lth.se) Simon Ekvy D08 (dt08se2@student.lth.se) Grupp 15 Projekthandledare: Richard Berntsson Svensson Version 1.1 19 maj 2009

Innehåll 1 Ändringshistorik 2 2 Introduktion 2 2.1 Testat System............................. 2 3 Test process 2 3.1 Process översikt............................ 2 3.2 Enhetstest............................... 2 3.3 Intergrationstest........................... 3 3.4 Systemtest............................... 3 3.5 Acceptanstest............................. 3 4 Testade komponenter 3 5 Testdagbok 3 5.1 Enhetstest............................... 3 5.2 Intergrationstest........................... 4 5.3 Systemtest............................... 4 5.4 Acceptanstest............................. 4 6 Testfall för systemtestning 4 6.1 Testfall................................ 4 6.2 Kravtäckning och spårbarhet.................... 4 7 Appendix: Testfall 4 1

1 Ändringshistorik Ver Datum Förf. Förklaring 0.1 090502 JA Första utdrag 1.0 090505 SE Korrigeringar med avseende på kravspecifikationen. 1.1 090519 MC Korrigeringar med avseende på den uppdaterade kravspecifikationen. Referenser [1] Project and Exercises in the Software Engineering Process, Software Engineering Research Group Department of Computer Science Lund University [2] Projektplanen för grupp 15. [3] Kravspecifikation för grupp 15. 2 Introduktion 2.1 Testat System Systemet som ska testats är en kontrollenhet till ett cykelgarage som bla sköter läs och användarhantering. Syftet med det här dokumentet är att beskriva hur testet av kontrollenheten ska gå till. Testprocessen består av följande faser: Enhetstest, integrationstest, acceptanstest och systemtest. 3 Test process 3.1 Process översikt Testen är utförda enligt enligt beskrivning i [2]. 3.2 Enhetstest För enhetstest används huvudsakligen strukturerad testning. All kod testats av utvecklarna innan den skickas in. All kod ska minst ha blivit körd en gång innan den lämnas in för intergration. Utförs av: Utvecklare. Typ av testning: Struktuell Kriterie: Fullständig kodradsgenomgång. Stop regel: Inga fel funna. 2

3.3 Intergrationstest Integrationstestning genomförs av utvecklarna, testen utförs inte nödvändigtsvis av de utvecklarna som gjorde enhetestesten. Alla metoder ska testas. Utförs av: Utvecklare. Typ av testning: Struktuell Kriterie: Fullständig genomgång av API (Application programming interface). Stop regel: Inga fel funna. 3.4 Systemtest Systemtestet testar alla krav som blivit definierade för systemet. Utförs av: Utvecklare. Typ av testning: Funktionell. Kriterie: Alla krav testas. Stop regel: Inga kritiska fel funna. Test fallen som används vid systemtestning finns i Appendix. Alla krav [3] ska bli verifierade minst en gång. Alla test ska verifera minst ett krav. 3.5 Acceptanstest Acceptanstest utförs utav kunden och är inte beskrivet här. 4 Testade komponenter Enhetstesten utförs huvudsakligen genom användning av källkoden. Kraven används huvudsakligen för att avgöra om ett testfall utfördes korrekt, när detta inte kan bestämmas av koden. Integrationstest använder källkoden och designen för att härleda vilka testfall som uppfyller kriterierna ovan. Systemtestestning använder huvudsakligen kraven för att härleda testfall och för att godkänna systemet. I acceptanstesten används bara slutprodukten. Enhetstest och integrationstest utförs i den utvecklade miljön, dvs en simulerad miljö. 5 Testdagbok 5.1 Enhetstest Varje utvecklare testar sin egna kod. Resultatet av testen behöver inte sparas. 3

5.2 Intergrationstest För varje test ska utgången av de olika testen bokföras i ett separat dokument unikt för varje test. Detta dokument sparas av projektledaren tills dess att projektet är slutfört. 5.3 Systemtest För varje test ska utgången av de olika testen bokföras i ett separat dokument unikt för varje test. Detta dokument sparas av projektledaren tills dess att projektet är slutfört. För varje fel som hittas meddelas utvecklarna via mail. 5.4 Acceptanstest Acceptanstest utförs utav kunden och är inte beskrivet här. 6 Testfall för systemtestning 6.1 Testfall Endast systemtestfall beskrivs här. Enhetstest och testfall baseras på koden, och acceptanstestet utförs av kunden. Testfallen finns Appendix. 6.2 Kravtäckning och spårbarhet Alla funktionella krav ska bli testatade minst en gång, för att försäkra att funktionallitet är testad, se bild. 7 Appendix: Testfall Testfall 1. Inlämning av cyckel Pre-condition: Systemet är igång, dörren är låst, användaren är registred med cykeln. Post-condition: Systemet är igång, dörren är låst, cykeln är registreras som inlämnad. 1. streckkod registreras av streckkodsläsaren. 2. Cykeln registeras som inlämnad 3. Dörren öppnas. Testfall 2. Inlämning av cyckel till fullt garage Pre-condition: Systemet är igång, dörren är låst, garaget är fullt, användaren är registred med cykeln. Post-condition: Systemet är igång, dörren är låst, garaget är fullt. 1. streckkod registreras av streckkodsläsaren. 4

Testfall Krav 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 1 2 x x x 3 x 4 x x 5 x x 6 x x x x 7 8 x 9 x 10 x 11 x 12 x 13 x 14 x 15 x 16 x 17 x 18 19 20 22 23 24 25 x 26 x 27 x 28 x x x x 29 x 30 31 x 32 x x 33 x 34 x x x x 35 x 36 x 38 x 39 x 40 41 42 43 44 x Figur 1: Kravtäckning (vitt utrymme representerar ickefunktionella krav som ej kan testas) 2. Dörren öppnas inte. Testfall 3. streckkoden finns inte med i systemet Pre-condition: Systemet är igång, dörren är låst, streckkoden finns inte registrerad. Post-condition: Systemet är igång, dörren är låst. 1. streckkod registreras av streckkodsläsaren. 2. Dörren öppnas inte. Testfall 4. Uthämtning av cykel. Pre-condition: Systemet är igång, dörren är låst, en registrerad användaren har en cykel inlämnad, cykel har streckkod. 5

Post-condition: Systemet är igång, dörren är låst, cykel är inte registrerad som inlämnad. 1. Användaren knappar in sin pinkod. 2. Den gröna lampan lyser i 5 sekunder. 3. Dörren öppnas 4. Användaren läser in streckkoden vid utgångsterminalen inom tidsintervallet. 5. Utgångsdörren öppnas. Testfall 5. Uthämtning av cykel, ej inom tidsintervallet Pre-condition: Systemet är igång, dörren är låst, en registrerad användaren har en cykel inlämnad, cykel har streckkod. Post-condition: Systemet är igång, dörren är låst. 1. Användaren knappar in sin pinkod. 2. Dörren öppnas 3. Den gröna lampan lyser i 5 sekunder. 4. Användaren läser in streckkoden vid utgångsterminalen, ej inom tidsintervallet. 5. Utgångsdörren öppnas inte. Testfall 6. Uthämtning av cykel, ej inlämningsregistrerad. Pre-condition: Systemet är igång, dörren är låst, en registrerad användaren har en cykel, cykel har streckkod, cykel är inte inlämningsregistrerad. Post-condition: Systemet är igång, dörren är låst. 1. Användaren knappar in sin pinkod. 2. Dörren öppnas 3. Den gröna lampan lyser i 5 sekunder. 4. Användaren läser in streckkoden vid utgångsterminalen, inom tidsintervallet. 5. Utgångsdörren öppnas. Testfall 7. Registrering av användare. Pre-condition: Systemet är igång, användaren är oregistrerad. Post-condition: Systemet är igång, användaren är registrerad. 6

1. Operatören registrerar användaren genom kontrollsystemet. 2. Pinkod och streckkod skrivs ut. Testfall 8. Avregistrering av användare. Pre-condition: Systemet är igång, användaren är registrerad. Post-condition: Systemet är igång, användaren är oregistrerad. 1. Operatören avregistrerar användaren genom kontrollsystemet. Testfall 9. Avregistrering av användare med cyklar kvar i garaget. Pre-condition: Systemet är igång, användaren är registrerad, användaren har cyklar kvar i garaget. Post-condition: Systemet är igång, användaren är registrerad. 1. Operatören f örsöker avregistrera användaren genom kontrollsystemet. 2. Kontrollsystemet meddelar operatören om att det finns cyklar kvar i garget. Testfall 10. Uppdatering av användarinformation. Pre-condition: Systemet är igång, användaren är registrerad. Post-condition: Systemet är igång, användaren är registrerad med nya personuppgifter. 1. Operatören söker på personnummer i kontrollsystemet. 2. Operatören uppdaterar informationen. Testfall 11. Bortagning av cyklar som inte ska vara där. Post-condition: Systemet är igång. 1. Underhålls pinkoden knappas in. 2. Den gröna lampan lyser i 5 sekunder. 3. Dörren öppnas. 4. Underhålls streckkoden dras i utgångstreckkodsläsaren. 5. Utgångsdörren öppnas. Testfall 12. Tidsgränsen för uthämtning av cykeln uppdateras. 7

Post-condition: Systemet är igång, tidsgränsen är uppdaterad. 1. Operatören uppdatera tidsgränsen. Testfall 13. Databasen sparas vid strömförlust. Pre-condition: Systemet är igång, databasen är intakt. Post-condition: Systemet är igång, databasen är intakt. 1. Strömmen bryts. Testfall 14. 5 sekunder mellan pinkodsknapptryckningar. Post-condition: Systemet är igång, pinkoden är nollställd. 1. En siffra knappas in. 2. 5 sekunder fortlöper mellan knapptryckningarna. Testfall 15. Fel kod. Post-condition: Systemet är igång, pinkoden är nollställd. 1. Fel pinkod knappas in. 2. Dörren öppnas inte. 3. Röd lampar blinkar 5 gånger i snabb följd. Testfall 16. Kontroll av cykel. Post-condition: Systemet är igång. 1. Operatören matar in en streckkod. 2. System förser operatören med personuppgifter. Testfall 17. Kontroll av antal cyklar. Post-condition: Systemet är igång. 1. Operatören frågar kontrollsystemet hur många cyklar som finns i garaget. 8

2. System förser operatören med uppgiften. Testfall 18. Kontroll av inlämningstid för en cykel. Pre-condition: Systemet är igång, cykeln är registrerad. Post-condition: Systemet är igång, cykeln är registrerad. 1. Operatören frågar kontrollsystemet efter inlämningstiden för cykeln. 2. Kontrollsystemet förser operatören med uppgiften. Testfall 19. Uthämtning av cykel, ej någon inlämnad. Pre-condition: Systemet är igång, en registrerad användare har inte en cykel inlämnad. Post-condition: Systemet är igång. 1. Användaren knappar in sin pinkod. 2. Dörren öppnas inte. Testfall 20. Avregistrering av cykel. Pre-condition: Systemet är igång, en registrerad användare har en cykel registrerad. Post-condition: Systemet är igång, cykeln är avregistrerad. 1. Operatören avregistrerar cykeln från systemet. Testfall 21. Registrering av cykel. Pre-condition: Systemet är igång, en registrerad användare har en oregistrerad cykel, maxgräns för cyklarna är ej överstigen. Post-condition: Systemet är igång, cykeln är registrerad. 1. Operatören registrerar cykeln från systemet. Testfall 22. Ny pinkod Pre-condition: Systemet är igång, användare existerar, det finns lediga pinkoder. Post-condition: Systemet är igång, användaren har fått en ny pinkod. 1. Operatören frågar systemet efter en ny pinkod. 2. Systemet förser operatören med en pinkod. 9

Testfall 23. Lista för inlämnade cyklar Post-condition: Systemet är igång. 1. Operatören frågar systemet efter en lista på inlämnade cyklar. 2. Systemet förser operatören med en lista sorterad efter inlämningstid. Testfall 24. Ny streckkod Pre-condition: Systemet är igång, en registrerad användare har en registrerad cykel. Post-condition: Systemet är igång, cykelns streckkod har skrivits ut. 1. Operatören frågar systemet efter cykelns streckkod. 2. Systemet förser operatören med cykelns streckkod. Testfall 25. Operatören öppnar dörr. Pre-condition: Systemet är igång, dörren är låst. Post-condition: Systemet är igång, dörren är öppen 1. Operatören öppnar dörren genom GUI. 2. Systemet öppnar dörren. Testfall 26. Ändring av dörrtidsintervall. Pre-condition: Systemet är igång, dörrtidsintervallet är x. Post-condition: Systemet är igång, dörrtidsintervallet är y. 1. Operatören ändrar dörrtidsintervallet till y. Testfall 27. Spara databas genom GUI. Post-condition: Systemet är igång, datbasen finns lagrad i en fil. 1. Operatören spara databasen via kontrollsystemet. Testfall 28. Inlämnad cykel kommer in. Pre-condition: Systemet är igång, cykeln är inlämnad Post-condition: Systemet är igång, cykeln är inlämnad. 10

1. streckkoden dras i streckkodsläsaren vid ingången 2. Dörren öppnas. Testfall 29. Fullt garage. Pre-condition: Systemet är igång, garaget är fullt. Post-condition: Systemet är igång, garaget är fullt. 1. Det går inte att lämna in en cykel. Testfall 30. streckkoderna tar slut. Pre-condition: Systemet är igång, en streckkod finns ledig. Post-condition: Systemet är igång, alla streckkoder är upptagna. 1. Ny användare blir registrerad. 2. Operatören får reda på att det var den sista streckkoden. Testfall 31. Pinkoderna tar slut. Pre-condition: Systemet är igång, en pinkod finns ledig. Post-condition: Systemet är igång, alla pinkoder är upptagna. 1. Ny användare blir registrerad. 2. Operatören får reda på att det var den sista pinkoden. 11