1. Introduktion Detta är en testplan för det kombinerade schack- och chatprogrammet, Schatck. Utgångspunken för detta dokument är den funktionalitet som beskrivs i dokumentet Kravspecifikation. 1.1 Mål Målet för de testförfaranden som anges i detta dokument är att erhålla ett system som är färdigt för demonstartion och kundacceptans. /Syfte/ Syftet med detta dokument är att beskriva hur de tester som ska genomföras på SYSTEMX ska utföras. Dokumentet ska även ta upp vilka förutsättningar som krävs för att testerna ska kunna genomföras. /Bakgrund/ MTTV är ett program för en taxiväxel, det finns en karttjänst som kan rita ut sökta taxibilar och man kan lätt föra in order, både bokningar och omedelbara körningar. För ytterligare information, se hemsidan undre produktbeskrivning. http://user.tninet.se/~zbg434c/hemsida/projekt/ /Omfattning/ Testplanen skall ligga till grund för all testning av MTTV, både för testningen av gränssnittet och för testerna av databaserna. Testplanen beskriver ingående de testprocedurer som ska genomföras på varje krav som finns beskrivet i kravspecifikationen. 2 Teststrategi Då projektgruppen har varit liten har det varit möjligt att genomföra rent tekniska funktionella tester av egna och medarbetares arbete kontinuerligt under projektarbets gång. Därför avser denna testplan att främst adressera de allmänna krav som åvilar projektet och som avseer mer abstraktva kravbegrepp.
2.1Test av funktionella krav 2.2 Protokoll primära krav Detta är ett testprotokoll utarbetat för de s.k. skall-kraven: Systemet skall grafiskt visualisera ett schackbräde Det skall vara möjligt att flytta pjäserna på detta bräde. Programmet skall vara musstyrt när operatörsindata är annat än textinmatningar Spel mot motståndare skall kunna ske över tcp/ip-nätverk Är pjäserna korrekt återgivna? Är utseendet på dessa sådant att det enkelt och intuitivt går att identifiera pjästyper? Är det utifrån färgsättningen av schackbrädet uppenbart vilken färg som motsvara svart repektive vit spelare? Är pjäserna grundplaceringe på brädet korrekt? Vad händer om pjäser placeras utanför brädet? Vad sker om pjäs placeras på ruta redan upptagen av annan pjäs, egen pjäs samt motståndarpjäs? Kontrollera och notera vilka moment som erfodrar att tangetbordet används Kontrollera att detta kan ske. 2.3 Sekundära krav Detta är testprotokollet för de s.k. bör-kraven. Det bör finnas en chat-funktion i schackprogrammet, för kommunikation mellan spelarna. Chat-sessionen skall automatiskt upprättas och avslutas med programmets schackdel. Spelarna kan kunna skicka meddelanden till varandra. Båda spelarna skall kunna skicka meddelanden på ett sätt som ur användarsynpunkt upplevs som samtidigt. Kontrollera vad som sker när tomma meddelanden eller meddelanden som endast innehåller blanktecken alternativt kontrolltecken skickas. Kontrollera att detta sker.
2.4 Icke-funktionella krav Programmet skall skrivas på svenska. Programspråket som skall användas är Java. Programmet skall bygga på ett gränssnitt baserat på grafisk representation. Gå igenom samtliga teststrängar i programmet och kontrollera att dessa är skrivna på svenska. Kontrollera att samtliga textsträngar är skrivna på god, ändamålsenlig och korrekt svenska. All programkod som projektet produceras skall läggas in i CVS varvid kontroll av detta enkelt kan ske. Kontrollera att detta är fallet. För detaljtestningen hänvisas till tidigare protokoll.
3. Användarfallsbaserade testfall De användarfall som finns beskrivna i kravspecifikationen skall gås igenom och relevanta fall med utgångspunkt från implementerad funktionalitet bör utföras. De användarfall som kommer att testas är följande: För in order för omedelbar upphämtning För in order för senare tillfälle Hantering av bokningspåminnelse Kommunikation med taxichauffören angående order. 4 typer av test Beskriver de olika testerna som ska göras. 3.1.1 Användargränssnittstest Att verifiera att användargränssnittet är ok. Alla knappar och paneler undersöks visuellt. Att alla knappar gör det dom ska och att bytena mellan panelerna fungerar som det ska. Även att det är enhetligt och lätt att använda. 3.1.2 Systemtest Att användarfallen går att utföra utan komplikationer Programmet kommer att testas genom att användarfallen i kravspecifikationer utförs med både korrekta och i den mån det går, felaktiga anrop. Att alla testmoment ska gå att genomföra utan komplikationer. 3.1.3 Databastest
Att informationen är lättåtkomlig och lagringen fungerar. Att anropa databasen med korrekta och felaktiga metoder och värden för att sedan analysera resultatet. Att databasen lämnar korrekta värden och klarar felaktiga anrop. 3.1.4 Konfigurationstest Att verifiera att systemet fungerar med angiven mjukvara Programmet körs med den givna mjukvara Att programmet skall fungera med angiven mjukvara 5. Testmiljö och verktyg Enligt tidigare projektmötesbeslut skall A2510 användas som utvecklings- och testmiljö. Detta baseras på initiala tester av mjukvarans egenskaper i avseende på platformsoberoende då det grafiska presentationsverktyget visade sig kräva enskild utrustningskonfiguration för att erhålla tillfredsställande funktionalitet. Detta var ett förfarande som projektgruppen ej hade möjlighetet att närmare analysera och adressera, varvid en specifik miljö stipulerades. 6. Felklassificering De avvikelser som upptäcks genom enskild modultestning under utvecklingsarbete och som ej kan ses om del av detta skall klassificeras och meddelas övriga projektet via e-post. De fel som upptäcks genom testprotokoll erhåller sin klassificering genom sin kravkategorityp i aktuell revision av kravspecifikationen. Fel klassificeras i två typer: 1) Fel som måste åtgärdas. Detta gäller allvarliga funktionella fel som sannolikt kan tänkas påverka acceptansförfarandet. Även vissa uppenbara kosmetiska fel kan komma att tillskrivas denna kategori om de kan anses ha signifikant påverkan på kundens accepansvillighet.
2) Övriga fel. Fel som sannolikt ej upptäcks vid acceptansförfarandet utan som kan lämnas till senare skeden av utvecklingsarbetet. Vidare skall meddelanden om genomför test innehålla information om vem som genomfört testet (Normalt antas detta vara e-brevets avsändare), när detta genomförts, en angivelse av vilken CVS-revision som använts. Normalt skall endast den senaste användas, men även i detta fall skall detta anges. Vidare bör åtminstone ett fall av entydiga instruktioner för hur felet återskapas, samt även vilken testmiljö som använts om denna är annan än projektets standardmiljö benämnd A2510. Om en bedömning om felets lokalitet är möjlig och en lämplig person att åtgärda bristen kan utses bör så ske. Nämnda person bör i så fall posta en uppgiftsacceptans inom 24 h efter det att en felrapport avhjälpningstekniskt adresserad till denne inkommit.
7. Användartestning och dokumentation När samtliga protokoll är genomgångna och inga klass 1-fel kvarstår skall en användarsstudie ske då två oberoende användare med enbart användarhandledningen som utgångspunkt skall använda programmet. Detta anses även vara en test av nämnda dokumentation vars kvalitetsaspekter eljest ej behandlas i detta dokument. 8 Testfall Här beskrivs hur de olika användarfallen ska testas. För att testutförandet ska vara givande förutsätts att databasen är initierad med testdata. 4.1.1 Systemet ska ge växeloperatören kännedom om vilka taxiförare som är i tjänst. Att verifiera kravet Taxiförare i tjänst. Teknik/ Man klickar på förarstatus och sedan på knappen i tjänst, en lista med förarnamn dyker upp. Att de förare som är i tjänst skall finnas med på denna lista. 4.1.2 Systemet ska ge växeloperatören kännedom om vilka taxiförare som är lediga. Att verifiera kravet Taxiförare som är lediga. Teknik/ Man klickar på förarstatus och sedan på knappen ledig.en lista med förarnamn dyker upp. Att de förare som är lediga skall finnas med på denna lista. 4.1.3 Systemet ska ge växeloperatören kännedom om vilka taxibilar som är i tjänst och lediga vid en viss tidpunkt. Att verifiera kravet antal taxibilar i tjänst samt antalet lediga bilar.
Går via förarstatus och väljer tillgängliga förare. En lista med förarnamn dyker upp. Att de förare som är tillgängliga skall finnas med på denna lista. 4.1.4 Aktuell karta över en taxizon med däri placerade taxibilar. Att verifiera kravet aktuell karta över en taxizon Klickar på Zoner på menyraden, väljer sedan de olika zonerna i tur och ordning. Att kartan för de aktuell zon ritas ut och att taxibilarna inom zonen visas. 4.1.5 Från en adress ska korrekt taxizon identifieras och taxibil namnges. Att verifiera kravet korrekt taxizon och bil från en adress. Skriver order och testar med olika adresser i olika zoner, samt adresser som inte existerar. Positionering fungerar endast för 2 nummer, så vi använder oss av slumpade koordinater. Rätt zon skall visas och en lista på chaufförer. 4.1.6 Korrekt zon skall kunna identifieras av systemet om ett gatunamn skrivs in av växeloperatören. Att verifiera kravet korrekt zon från ett gatunamn. Klickar på zonmenyn och väljer visa gata. Skriver in korrekta adresser i olika zoner samt adresser som inte existerar. Rätt zon visas och om adressen är felaktig ska felmeddelande komma upp.
4.1.7 Viss taxibils position ska kunna sökas och bilens status ska därefter ges av systemet. Att verifiera kravet taxibils position. Klickar på förarmenyn och går på sök förare. Skriver in felaktiga och korrekta mobilnummer. Positionering fungerar endast för 2 nummer, så vi använder oss av slumpade koordinater. Taxibilen som man söker ska synas på kartan och om fel mobilnummer anges ska felmeddelande uppkomma. 4.1.8 En lista på bokningar under aktuell dag ska finnas tillgängliga för växeloperatören. Systemet ska sedan automatiskt, en halvtimme innan körningen ska äga rum, göra växeloperatören uppmärksam på detta. Att verifiera kravet bokning och påminnelse. För in order som bokningar och se så att de sparas, sedan väntar man och ser så att påminnelsen kommer upp som den ska. Att alla bokningar finns med på bokningslistan och att påminnelsen kommer upp en halvtimme i förväg samt att bokningen tas bort då den behandlats. 4.1.9 Kommunikationen mellan växeloperatören och taxichauffören bör kunna ske för bekräftelse av körningar. Att verifiera kravet körningsbekräftelse. TaxiContact motsvara en kommunikationsförmedlare, men är i vårt program bara en testklass. Skickar en order till TaxiContact och väntar på svar.
Taxichauffören ska ge ett ja eller nejsvar vilket slumpas fram i nuläget. Svarar föraren nej, sätts dennes status till upptagen. 5 Testverktyg Testningen sker utan speciella testverktyg. Testningen av användargränssnittet sker genom manuell inmatning. Alla andra tester sker med hjälp av testscript. 6 Resurser Alla gruppmedlemmar utför teser under utvecklingsstadiet. Testningen av de i detta dokument angivna tester utförs även av alla i gruppen. 7 Testlogg Alla tester dokumenteras i en testlogg. Alla fel och hur de har åtgärdats finns även i testloggen. För att gradera felen använder vi oss av prioriteterna 1-4, vilket innebär att prioriten 1 är av högsta prioritet medans prioriten 4 är lägst. För mer information se hemsidan http://user.tninet.se/~zbg434c/hemsida/projekt/