PRESTANDATESTER I FÖRVALTNING

Transkript

1 Examensarbete 15 högskolepoäng C nivå PRESTANDATESTER I FÖRVALTNING Reg.kod: Oru Te DT3017 D105/08 Daniel Pettersson Dataingenjörsprogrammet 180 högskolepoäng Örebro vårterminen 2008 Examinator: Lars Karlsson PERFORMANCE TESTING DURING MANAGEMENT Örebro universitet Örebro University Institutionen för teknik Department of technology Örebro SE Örebro, Sweden

2 Sammanfattning Denna rapport beskriver ett examensarbete på 15 poäng inom DataIngenjörsprogrammet vid Örebro Universitet. Arbetet är utfört hos Consulting AB Lennermark & Andersson 1 i Örebro. Syftet med arbetet är att ta fram ett direktiv om hur tester, testmiljöer och testdata ska hanteras samt att applicera resultatet på en test applikation. Abstract This report describes a degree project within the Computer Engineering Program at Örebro University. The work was made for Consulting AB Lennermark & Andersson in Örebro during 20 weeks in the spring term The aim for this project is to develop a directive on how to tests, testing enviroments and test data should be handled, and to apply the results on a test application. 1 hädanefter benämnt CAB 1

3 Förord Detta examensarbete är en del av min ingenjörsutbildning inom Datateknik vid Örebro Universitet. Arbetet är på C-nivå och omfattar 15 hp. Jag skulle vilja tacka Consulting AB Lennermark & Andersson som gett mig möjligheten att göra detta examensarbete. Jag vill rikta ett särskilt tack till Kjell Mårdensjö (handledare på universitetet), Stefan Pettersson (handledare på Consulting), Christer Löwdahl(ansvarig för examensarbetet på Consulting) för deras stöd under detta examensarbete. Sist men inte minst vill jag tacka min sambo Catrin för att hon varit så förstående under arbetet med detta examensarbete. Örebro den Daniel Pettersson 2

4 Innehåll 1 Inledning Översikt Bakgrund Mål Tester De olika testerna Funktionella och ickefunktionella tester Prestandatester Stresstester Vad är prestanda? Varför ska man prestandatesta? Prestandatesternas beståndsdelar De olika miljöerna Definiering av och krav på miljöerna Testfallen Scenarier Testdata Testplanen Kommunikation av testresultat och åtgärder Resurser för prestandatester Testapplikationen Översikt Arbetsgång Uppbyggnaden av applikationen Arkitektur Utvecklingmiljön och dess mjukvaror Prestandatester Testupplägg Testdata

5 4 Sammanfattning Prestanda Testapplikationen Implementationen Testerna

6 Figurer 2.1 En icke rekommenderad systemdesign En möjlig men ej rekommenderad systemdesign En rekommenderad systemdesign Mall för testfall Önskat läge, 2 vägs kommunikation mellan utvecklare och testare Oönskat läge, 1 vägskommunikation mellan utvecklare och testare Oönskat läge, ingen kommunikation mellan utvecklare och testare Kommunikationsvägen i testapplikationen Översikt över testapplikationens beståndsdelar Översikt över hur de olika delarna av testen hänger ihop Klientens huvudfönster Val av den filial vars flöde som man vill se Visning av aktuellt flöde

7 Tabeller 4.1 Markeringsystem för momentstatus

8 Kapitel 1 Inledning 1.1 Översikt Detta dokument är resultatet av 10 veckors examensarbete hos Consulting AB Lennermark & Andersson i Örebro. Detta dokument beskriver arbetet med att ta fram riktlinjer för hantering av testmiljöer, testdata samt testfall för att säkerställa att förutsättningarna ska vara samma vid prestandatester av kommande versioner av systemen som byggs hos CAB. Detta dokument beskriver även framtagandet av en testapplikation och appliceringen av den första delens resultat på testapplikationen. 1.2 Bakgrund Bakgrunden till detta arbete är att då kraven på systemen som byggs, hela tiden ökar så måste systemen trimmas och utvecklas så att de kan klara av nya belastningar. Även i de fall då systemen inte måste bli snabbare så får de ej heller tappa för mycket hastighet när de byggs ut och nya versioner släpps. Med en fastslagen rutin för hantering av tester och testmiljöer så kan man på ett enkelt sätt jämföra tester från olika versioner och på så sätt se hur ändringar i kodbasen slår igenom på prestandan. Nu finns det ju andra faktorer så som hårdvaran som systemet körs på och uppkoppling (om systemet är nätverksbaserat dvs) att ta hänsyn till, men i detta arbete så kommer jag att inte ta med dessa två utan koncentrera mig på prestandan i själva systemen. 7

9 1.3 Mål Målet med detta arbete är att det hos CAB ska finnas en fastställd rutin för hur man går till väga för att ta fram testfall, testdata samt hur man ska hantera testmiljöerna. Det ska även ha bevisas att rutinerna fungerar genom att de ska applicerats på den testapplikation som ska skrivas. 8

10 Kapitel 2 Tester Följande genomgång bygger på de slutsatser som jag har dragit genom mitt arbete inom detta område det senaste året. Uppdelningen av de olika testerna kan diskuteras, men jag anser att den uppdelning som görs i följande genomgång är den som bäst speglar hur man bör se på dem. 2.1 De olika testerna När man ska testa ett system så finns det flera olika sorters tester som man kan utföra. Dessa är: Funktionella & ickefunktionella tester Prestandatester Stresstester Funktionella och ickefunktionella tester Funktionella tester används för att kontrollera att funktionaliteten hos systemet, dvs man verifierar att systemet fungerar som det är tänkt. Icke-funktionella tester är tester som man använder för att kontrollera utseendet på systemet. Man baserar dessa tester på de testfall 1 som man har identifierat i systemet. Varje testfall som man hittat ger ett funktionellt eller ickefunktionellt test. Dessa tester kan vara både manuella och automatiserade, de andra testerna som finns kräver att man automatiserar för att de ska gå att genomföra men då de flesta funktionella tester inte har några tidskrav så spelar det oftast ingen roll om man automatiserar dem eller inte (om man inte vill spara tid dvs). Oavsett vilket system som man bygger 1 se sid 15 för mer information 9

11 så kommer man att behöva funktionella tester, detta då man måste verifiera att systemet fungerar så som det är tänkt Prestandatester Prestandatester används för att ta fram hur mycket systemet kan belastas innan dess prestanda blir för dåligt för att det ska gå att använda systemet. Förutom funktionella tester så är prestandatester de tester som man bör lägga mest tid på. Man kan ofta använda sig av automatiserade versioner av testfall och scenarier för att simulera den verkliga användningen. Genom att utföra prestandatester och samtidigt profilera systemet så kan man ta reda på vilka flaskhalsar som finns i det. Till skillnad från funktionella tester så måste man inte prestandatesta ett system men man bör göra det för att få en ide om hur det klarar den belastning somman tror att det kommer att bli utsatt för Stresstester Stresstester är ganska likt prestandatester men här så har man inte målet att ta fram var gränsen för acceptabel prestanda går utan här är målet att få fram hur mycket systemet klarar av innan det slutar svara, dvs hur mycket det klarar innan det blir oanvändbart. Även här så kan man använda sig av automatiserade versioner av de funktionella testerna för att ta fram bra tester, och liksom med prestandatesterna så måste man inte utföra dessa tester och ska man rangordna deras betydelse så skulle denna hamna sist då dessa tester inte ger något annat än att man vet var maxgränsen för systemet går. Om man vill veta mer om systemet beteende så är prestandatesterna ett mycket bättre val. 2.2 Vad är prestanda? Prestanda är ett relativt begrepp, beroende på vad man håller på med så kan definitionen av rätt prestanda skilja sig ganska mycket. Man skulle kunna säga att prestanda är som skönhet, dvs det bestäms av personen som upplever det. Bara inom datorindustrin så kan prestanda vara beräkningskraft, laddningstid, möjligheter att leverera innehåll (både grafik och data), svarstider mm. 2.3 Varför ska man prestandatesta? I alla system som byggs så är prestandan en faktor som man måste räkna med. Oavsett vad man skapar så måste man ta prestanda i beaktande, användare tappar 10

12 lätt intresset och byter snabbt ut ett system som det tar för lång tid att arbeta i. För att bevisa påståendet ovan så kan vi ta ett enkelt exempel. Tänk på en hemsida som tex. När man öppnar denna så kan det ta några sekunder att ladda in alla animationer som de har, och det är oftast inget som man reflekterar över. Men tänk om sidan skulle ta uppåt sekunder att ladda, då skulle många tröttna och välja en annan nyhetssida med kortare laddningstider. Nu är ju exemplet ovan ganska enkelt, men det är utmärkt för att få fram poängen, dvs att oavsett vad man gör så måste man se till att det är tillräckligt snabbt för att människor ska fortsätta att använda det. Ett bra exempel på att man måste testa prestanda (och även stabilitet) är Lehmans lagar[3]. Lehmans två första lagar lyder: 1. Any software system used in the real-world must change or become less and less useful in that environment. 2. As time flows forwards, entropy increases. That is, as a program evolves, its structure will become more complex. Enligt dessa lagar så måste ett system alltid fortsätta att utvecklas för att man ska fortsätta att använda det och genom dess utveckling så kommer det att växa och blir mer och mer komplext. Detta fenomen är en av prestandans största fiender (kanske till och med den största). Effekten av dessa lagar visar på behovet att kontinuerligt prestandatesta systemen. Ett tankvärt citat kommer från en artikel på MSDN[8]. We recently conducted load testing well into the development of a complex n-tier Web architecture. We made two underestimations. First, we underestimated how many problems we would uncover in the system once testing began. Our first test run failed at just 2 users and 100 order processed. Detta citat visar på hur det kan gå om man inte dimensionerar och/eller designar systemen rätt, dvs med prestanda i tanken. Nu finns det ju inget som säger att det inte kan gå så även om man designar systemet med avseende på prestanda, men chanserna att det går bra ökar markant om man tänker rätt från början. Förutom citatet ovan så rekommenderar de i artikeln på MSDN[8] att man ska lägga mellan 15 till 20% av tiden och pengarna på tester av systemen, och att av denna tid så bör ungefär 1/3 läggas på prestandatester. 2.4 Prestandatesternas beståndsdelar Först så kanske en förklaring kan vara på sin plats, när det i detta examensarbete talas om prestandatester så avses lasttester och inte stresstester. Skillnaden mellan 11

13 dessa förklaras i kapitel 2.1 på sidan De olika miljöerna Varje system bör ha tre miljöer att köras i, dessa är: Utvecklingsmiljön Testmiljön 2 Produktionsmiljön Denna uppdelning är inte absolut utan ska mer ses som en rekommenderad uppdelning. Varför man bör dela upp miljöerna så här kommer att förklaras här nedanför. När begreppet maskin används i nästa kapitel så kan det avse både fysiska och virtuella maskiner Varför dela på miljöerna? Det finns många skäl för men enkelt uttryckt så bör man dela upp miljöerna för att undvika att de stör varandra. Följande uppdelningar är de som förekommer: Samtliga miljöer i samma maskin. Test och utveckling ligger i samma maskin och produktionen ligger i en egen maskin. Samtliga miljöer har egna maskiner. Vi ska nu gå genom dessa olika alternativ. Odelad miljö Designen i figur 2.1 är en design som man inte bör använda sig av då man inte har separerat någon av de olika miljöerna från varandra. Då de inte är separerade så ökar man risken för att miljöerna ska störa varandra. De störningar som kan uppstå är både prestandarelaterade (då de alla delar på samma resurser) och stabilitetsmässiga (både utvecklingsversioner och testversioner kan vara ganska instabila). 2 Används för tester av nya versioner innan de går i produktion. 12

14 Figur 2.1: En icke rekommenderad systemdesign. Delvis delad miljö Designen i figur 2.2 är inte att rekommendera då man fortfarande inte har separerat utvecklings och testmiljön från varandra. Om man inte kan/har råd att ha samtliga miljöer i egna maskiner så kan man använda sig av denna design men då bör man tänka på att de kan störa varandra, både stabilitetsmässigt och prestandamässigt. Det viktiga här är att man prioriterar produktionsmilj n, dvs att den får en egen maskin så att man säkerställer att den inte störs av någon av de andra miljöerna. Figur 2.2: En möjlig men ej rekommenderad systemdesign. Helt delad miljö Designen i figur 2.3 är den design som man bör använda sig av när man sätter upp maskinerna. Med denna design så minimerar man risken för att de olika miljöerna ska kunna störa varandra. Här så har man tagit bort de risker för störningar som delade miljöer för med sig och behöver endast tänka externa faktorer såsom hårdvarufel mm. 13

15 Figur 2.3: En rekommenderad systemdesign Definiering av och krav på miljöerna För att tester ska kunna upprepas om och om igen och samtidigt ge tillförlitliga resultat så måste man ställa krav på systemen som används för testerna, dessa krav måste ställas både för hård och mjukvaran som används Mjukvaror Kraven på miljöerna ser olika ut beroende på vad man utvecklar för system, men generellt så kan man säga att alla miljöer ska ha samma version av de mjukvarorna som används. Uppgraderingar(och patchar) bör först testats ordentligt i test och utvecklingsmiljön innan de appliceras på produktionsmiljön då både uppgraderingar och patchar (även för existerande problem) kan introducera nya buggar. Man kan komma undan med enkla tester av uppgraderingar och patchar i utvecklingsmiljön om man gör omfattande tester i testmiljön. Förutom att man bör se till att samtliga miljöer är så lika varandra som möjligt så bör man även frysa en version av systemet som man sedan testar på. Under testandet så bör man endast ändra på denna version för att testa åtgärder mot identifierade problem i systemet. Anledningen att man bara ska ändra i den frysta versionen om man hittar fel i den är att om man inför ändringar som inte har med problem att göra så kan man introducera nya problem och/eller ändra den prestanda som systemet kan leverera, vilket gör att man måste exekvera alla tester igen så att alla tester har utförts på samma kodbas Hårdvaran När det gäller hårdvaran så finns det flera saker att tänka på. Man bör sträva efter att ha en testmiljö som är så lik produktionsmiljön som möjligt, men oftast så är det inte möjligt att spegla produktionsmiljön då det inte är kostnadseffektivt att ha en extra miljö stående (det är möjligt om man har tänkt att använda den 14

16 som en kall backup men det är ändå oftast inte en realistisk lösning). Lösningen på detta är att man använder sig av en testmiljö vars resurser man enkelt kan räkna om till motsvarande resurser i produktionsmiljön, tex ett styrkeförhållande på 1:2 (test:produktion), men detta förhållande är ofta inte rättvisande utan man bör då även jämföra resultaten av de olika testerna i de två systemen för att få fram mätetal som kan användas. Det hela blir mycket enklare om man använder sig av virtuella produktionsmiljöer, man kan då ofta klona produktionsmiljön (såvida denna inte är för stor) och utföra testerna i denna klon. Om man inte kan klona hela produktionsmiljön så kan man oftast ta fram en miljö i en mindre skala tex tex 1:3, dvs testmiljön motsvarar en tredjedel av produktionsmiljön osv. Om systemet är nätverksbaserat så bör man börja testa långt innan man släpper systemet, och genom att man gör på detta sätt så kan man använda sig av den kommande produktionsmiljön för att utföra tester. Detta ger väldigt bra insikter om vad man kan vänta sig för prestanda när man väl släpper systemet, och som en bonus så får man med det upplägget även en bra uppfattning om styrkeförhållandet mellan test och produktionsmiljön Testfallen För att testa olika funktioner, krav och buggar som dyker upp för ett system så lägger man upp ett testfall per funktion, krav respektive bugg (om de inte har med samma sak att göra, då kan man gruppera dem i ett och samma testfall). Man kan även dela in testfall i olika kategorier (beroende på vad de behandlar, grafik, funktionalitet eller båda), denna uppdelning kommer att behandlas här nedanför Olika sorters testfall Testfallen kan delas upp i två olika kategorier, funktionella och icke-funktionella. I system som inte har något grafisk gränssnitt (GUI 3 ) så får man några enstaka icke-funktionella krav (hjälpfiler och annat nödvändigt), resten av kraven kommer då att vara funktionella. I system som byggs på ett GUI så får man en del ickefunktionella och en del funktionella men de flesta testfallen kommer att vara en kombination av de båda andra då designen även kan räknas in i funktionen. När man går igenom testfallen för att ta fram de som man behöver vid prestandatester så kommer man nästan uteslutande att använda sig av funktionella testfall då man oftast inte kommer att testa ett GUI (om det inte gäller hemsidor dvs), utan oftast så kommer man att testa kommunikationen mellan en klient och en server. 3 Graphical User Interface 15

17 Att ta fram testfall Att ta fram testfall är oftast en ganska enkel process. Det räcker ofta med att titta på hur man vill att systemets delar ska bete sig och/eller hur de ska se ut och med sedan skriva instruktioner utifrån hur man på bästa (och oftast enklaste) sättet kontrollerar att kraven som ställts är uppfyllda. Man kan med fördel dela upp systemet i olika delar och sedan gruppera testfallen efter denna uppdelning. Detta ger fördelen att man testa genom en viss del av applikationen utan att behöva gå igenom samtliga testfall för att hitta de som man ska köra. De olika grupperna kan med fördel läggas i olika dokument (om man använder sig av ett sådant upplägg dvs). Man bör skriva testfall varje gång som en ny funktion, krav eller bugg dyker upp, detta då man bör täcka in alla delar av systemet och att man bör ha testfall för at kontrollera att kända fel/problem. Framtagandet av testfallen bör göras i samråd med systemdesigners/utvecklare för att få testfall som överensstämmer med hur det är tänkt att resultatet ska se ut/fungera. Det är väldigt lätt att missa testfall, men har man missat testfall så kommer man ofta på det när man testar systemet(man hittar testfallen samtidigt som man hittar buggar) Testfallens uppbyggnad Hur testfallen ska designas är upp till var och det gäller att hitta en stil som man tycker om och som känns bra, men när man skriver testfall så bör man följa de råd som finns i boken Programvaruprojekt [4] sid Det är viktigt när man definierar testfall att sträva efter att göra testfasen tankebefriad i den mån det går. Den som testar ska bara göra som det står i planen och kontrollera att resultaten blir de förväntade. Förväntade resultat ska skrivas ner på ett lättförståeligt sätt utan formler i testplanen. Att testa bör inte vara svårt. Om det visar sig vara svårt kan det bero på att man har ägnat för lite tid åt testplaneringen. Om man följer de ovanstående idéerna så för man följande effekter: Enklare tester. - Enkelt att skriva. - Säkrare att testerna utförs på rätt sätt. Man är inte bunden till att använda sig av speciell personal för att kunna testa. 16

18 Enkla och väldefinierade testfall gör det hela mer överskådligt. då man enklare kan dela upp dem i grupper och områden. För exempel på mall för testfall, se figur 2.4. Designen i figur 2.4 ser ut så här: Figur 2.4: Mall för testfall Överst (första delen) så har vi huvudet, där anger man en kod för den del av systemet som testet avser, detta följs av ett löpnummer för det aktuella testet. Under det så har vi del 2, vilket är en en steg för steg guide till hur man ska gå till väga för att utföra testet. Varje rad som innehåller orden kontrollera att ska ha en motsvarande rad i den tredje delen av testfallet, dvs i verifieringsdelen. Verifieringsdelen innehåller de saker som man ska kontrollera i del 2. De krav som står i denna del ska uppfyllas för att testfallet ska anses som godkänt. Den näst sista delen är ett fält där testaren signerar efter att denne har utfört testet. Den sista delen är ett fält där man skriver in resultatet av testet, det är även här som man anger de kommentarer och och tankar som man har fått under testet. 17

19 Om man följer denna uppbyggnad av testfallen så får man en enkel struktur som gör det enkelt både att testa och att omsätta till tester som man kan använda i prestandatester. De testfall som skrevs för testapplikationen finns i bilaga A Kriterier för testfall för användning vid prestandatester När man ska välja ut vilka testfall som ska ingå i tester av prestandan så måste man ställa sig frågan Vad är det jag vill testa?. Kan man inte svara på den frågan så har man inte riktigt klart för sig vad man ska testa, och detta kommer att försvåra testandet och troligtvis förlänga den tid som det tar att skapa/exekvera testerna. En annan effekt som kan fås av att man inte har klart för sig vad man egentligen vill/ska testa är att man till slut kan få alldeles för mycket data att gå igenom, vilket kan göra att man missar de verkliga problemen och i stället hittar någon mindre viktig punkt som inte kommer att få lika stor effekt som de riktiga flaskhalsarna. För att kunna ta fram de testfall som man verkligen bör använda sig av så bör man ställa sig följande frågor: Vilket/vilka områden i systemet ska testas? Vad vill vi uppnå med testerna? Frågorna ovan kan se väldigt enkla ut men man bör tänka igenom svaren noggrant. Den första frågan är den som det oftast är enklast att svara på, man bör kunna säga vilken del av systemet man vill testa. Den andra frågan är lite klurigare att svara på, man bör fundera igenom vilken sorts test som man ska utföra. Det kan vara enkelt att säga Vi kör på och ser hur mycket belastning en server klarar innan den går ner., men är detta alltid ett bra sätt att testa på? Svaret på detta är att ofta så bör man inte testa på detta sätt utan man bör i stället sätta upp värden för vad man tycker är bra (rimliga) svarstider och man bör även sätta upp ett mål för var man vill nå. Sedan så väljer man ut testfall som innehåller de delar som man vill testa och sedan testar man hur mycket man kan belasta den aktuella servern innan de önskade svarstiderna överskrids. När man sedan hittat gränsen så bör man utvärdera var flaskhalsen ligger och om det är möjligt så bör man eliminera denna och se om man nu når upp till den utsatta gränsen. Genom att göra på detta sätt så kan man mellan varje testomgång utvärdera testmaterialet och se om man behöver ändra något i testfallen och/eller testskripten för att på ett bättre sätt modellera hur verkligheten ser ut. 18

20 2.4.4 Scenarier Vad är ett scenario? Ett scenario kan beskrivas som en samling testfall som kan utföras i följd. Man får inte förväxla scenarier och testfallsområden, dessa två är helt skilda saker, då ett scenario kan innehålla hela testfallsområden så kan man ibland tro att de är samma sak. Skillnaden är att ett scenario inte är bundet till ett visst område utan då man följer flöden så kan det spänna över flera olika testfallsområden Varför dela in i scenarier Scenarier har man nytta av när man vill testa flöden i ett system, varje flöde blir då ett scenario. När man designar ett scenario/flöde så bryr man sig inte om den data som ska flöda genom systemet utan man bryr sig bara om hur den ska transporteras och vilket mål som ska uppnås. Ofta kan man få olika slutresultat i ett och samma scenario om man använder sig av olika testdata. När man designar ett scenario så bör man lägga upp det så att det blir cirkulärt, dvs när scenariot är slut så ska allt se likadant ut som innan man började testa. Detta gör att man enkelt kan köra samma scenario om och om igen utan att behöva återställa testmiljön mellan körningarna (underlättar mycket vid automatiska tester). Om man inte kan få ihop ett scenario som är cykliskt så måste man kunna se till att man kan skapa upp tillräckligt med testdata så att man kan exekvera längre tester(alltså mer än en enstaka körning) innan man måste gå in och återställa allt manuellt. Detta bör man göra då det annars (oftast) tar mycket längre tid om man hela tiden måste återställa systemet till startläget Testdata Testdatan är en av de saker som man verkligen får tänka till när man skapar. Beroende på vad för sorts system som ska testas så kan arbetet med testdatan skilja ganska markant, en del system kräver nästan inget arbete medans vissa kräver mängder av arbete för att se till att man har tillräckligt med korrekt testdatan. En tumregel är att ju komplexare system desto mer arbete med testdatan, denna regel är som sagt inte alltid korrekt men den stämmer i de flesta fallen Skapa testdata När man skapar testdata så ska man försöka få den så lik verkligenheten som möjligt, men man bör även ha specialfall för att täcka in de olika fel/extremfall som kan uppstå i systemet. Först så bör man skapa upp testdata till normalfallen, då det är dessa som man oftast testar så brukar man vanligtvis behöva ha mest av 19

21 dessa data. När man har skapat datan för normalfallen så bör man koncentrera sig på att identifiera den data som behövs för att testa specialfallen, detta arbete är oftast det svåraste då det är lätt att missa de mest extrema fallen. Man måste även se till att skapa testdata så att volymen motsvarar den volym som man beräknar att man kommer att behandla i framtiden Lagring av testdata Beroende av vilken sorts testning som man gör och vilka hjälpmedel som man använder så bör man lagra testdatan på olika sätt. Använder man sig endast av testfall så kan man oftast skapa datan on the fly, dvs när man testar. När man använder sig av verktyg för att testa systemen så kan man ofta behöva ha stora mängder data, dessa data lagras olika beroende på vad verktygen klarar av. De flesta verktygen klarar att man lagrar testdatan i databaser. Fördelen med detta är att den är lätt att säkerhetskopiera och att flytta. En annan fördel med detta är att man oftast inte behöver ha datan på maskinen som man använder för tester utan den kan finnas på en annan maskin. Detta sänker kraven för testmaskinen men ökar kraven på det nätverk som då måste finnas. Kan man inte lagra den aktuella datan i en databas så måste man lagra den i filer på tex. hårddisken. Använder man sig av denna metod så bör man se till att testdatan är lättåtkomlig, helst så ska denna följa med testversionen av systemet, detta för att man inte behöver lägga in en massa saker manuellt då detta gör testandet svårare Testplanen Inför varje testomgång så bör man skriva en testplan. En testplan bör innehålla följande saker: Vad som ska testas Hur det ska testas Vilka data som ska användas Vilka scenarier/testfall som ska testas Vilka som ska ingå i testteamet och deras respektive roller En veckoplanering med mål uppsatta för varje vecka. Man kan med fördel använda den första testplanen som man skriver som en mall och sedan bara uppdatera de delar som ändrats. Om man upprepar samma tester 20

22 så blir det bara deltagarna och deras roller som ska uppdateras. Det är även viktigt att man uppdaterar testplanen när det sker förändringar i testerna, vanligast är att man får ändra planeringen men även ändringar i scenarierna förekommer (dessa ändringar kommer oftast vid profileringen av systemet) Kommunikation av testresultat och åtgärder Oavsett hur mycket man testar så gör det ingen nytta om man inte kan kommunicera resultatet till utvecklarna. Varje utvecklingsprojekt bör ha fastslagna sätt som testresultaten ska rapporteras via, dessa får inte på något sätt användas till annat än att rapportera testresultat då det annars är risk för att man matar in för mycket irrelevant data denna väg och genom detta gör att personen som informationen är avsedd för inte orkar sortera ut den information som är relevant. Men oavsett hur mycket information man sparar så gör den ingen nytta om den inte kommuniceras ut till de andra i utvecklingsteamet. Följande scenarier finns för kommunikationen mellan utvecklare och testare: 2-vägs kommunikation Både utvecklare och testare kommunicerar sina resultat och aktuell status. 1-vägs kommunikation Endast utvecklare eller testare kommunicerar sina resultat och aktuell status. Ingen kommunikation Varken utvecklare eller testare kommunicerar sina resultat och aktuell status. Vi kommer nu att gå igenom samtliga scenarier vägs kommunikation Figur 2.5 visar hur man vill att kommunikationen ska fungera, dvs både testare och utvecklaren kommunicerar med varandra. Detta scenario innebär att utvecklaren kommunicerar vad som gjorts till testaren och testaren kommunicerar resultaten av testerna till utvecklaren. Detta gör att båda parterna vet hur läget ser ut. Effekten av detta är att kvaliteten på systemet antingen blir bättre eller ligger kvar på samma nivå, då de buggar som hittas åtgärdas innan de kommer till produktion vägs kommunikation Ser det ut som i figur 2.6 så har man hamnat i ett oönskat läge. I detta scenario så förs det ingen dialog mellan utvecklare och testare utan det är bara en av dem som försöker kommunicera. Detta betyder att antingen så får testaren inte reda på vad som gjorts eller så får utvecklaren ingen information om hur testerna har gått 21

23 Figur 2.5: Önskat läge, 2 vägs kommunikation mellan utvecklare och testare. Figur 2.6: Oönskat läge, 1 vägskommunikation mellan utvecklare och testare. 22

24 och kan på så vis inte åtgärda de fel som uppstått. I detta scenario finns två utfall. I fall 1 så blir buggar liggandes länge eftersom de inte kommer till utvecklarnas kännedom innan utvecklarna själva hittar dem eller användarna hör av sig med buggrapporter. Detta gör att utvecklingen blir ineffektiv (då buggar kan störa ny funktionalitet) och kvaliteten på systemet sjunker då det innehåller fler och fler buggar. I fall 2 så får inte testaren veta vad som gjorts sedan sist utan denne får testa bäst den vill och hoppas att de buggar som hittas blir åtgärdade i kommande version. Av de två fallen ovan så är det första fallet det värsta då det ger ett system med sämre kvalitet eftersom de buggar som skapas inte blir åtgärdade. I fall 2 så kan en testare hålla en ganska bra koll på vilka de kända felen är genom att skriva ner när de hittades och hur man gör för att få fram dem(dvs skapa testfall). Med hjälp av de anteckningarna(testfallen) så kan man enkelt kontrollera om en viss bugg fortfarande existerar eller om det blivit åtgärdad. Denna lösning ger mycket arbete men kan alltså ordna upp en situation där man bara har 1-vägs kommunikation Ingen kommunikation Figur 2.7: Oönskat läge, ingen kommunikation mellan utvecklare och testare. Denna situation är den sämsta tänkbara utav de som man kan råka ut för. Har man nått det stadium där man inte längre har någon kommunikation mellan utvecklare och testare så måste man ta i med kraftiga åtgärder såsom omorganisering av utvecklingsteamet för att det ska gå att fortsätta utvecklingen. Gör man inget i det här läget så kommer utvecklingen till slut att gå i stå då utvecklarna till slut måste ägna allt mer tid till att testa systemet istället för att fixa problem och fortsätta utvecklingen. Har man någon struktur för uppföljning, kanske med 23

25 statusmöten en gång per vecka eller dylikt så brukar man kunna förhindra att man hamnar i detta läge Kommunikationsvägar Det bästa sättet för att kommunicera mellan testare och utvecklare att skriva ner resultaten i ett överenskommet format och sedan vara beredd på att förklara det som de andra i teamet inte förstår genom att läsa det som man skrivit. Man kan även ta kommunikationen muntligt men då är det en större risk att man glömmer saker (gäller det enstaka saker så kan det gå bra men då är det bra om man antecknar vad det gällde strax efter genomgången så att man inte glömmer det). Men oavsett vilket sätt man väljer för att kommunicera aktuell status och testresultat så är det viktigt att man håller en bra balans av mängden av relevant information. Om man har för lite information så kommer man att få förklara de saker som de andra i teamet inte förstår och har man med för mycket irrelevant information så kommer de inte att orka ta sig igenom allt utan de kommer då troligtvis att skippa en del av informationen. Förslagsvis så bör man efter varje testrunda samla ihop alla buggar/anmärkningar i ett dokument och se till att alla läser det. Ett annat förslag är att man så fort som en bugg/anmärkning dyker upp direkt gör utvecklarna medvetna om den och om man har ett ärendehanteringssystem lägger in buggen/anmärkningen där för behandling. Oavsett vilket sätt man väljer så bör man se till att alla informeras om de saker som hittas. 2.5 Resurser för prestandatester När man ska göra prestandatester så är det rekommenderat att man använder sig av lastgenereringsverktyg då det oftast inte är ekonomiskt att göra testen manuellt(enligt källor så finns det tillfällen då detta förekommit, men det är oftast inte ekonomiskt försvarbart). Om man kontrollerar vad som finns på marknaden så kommer man att hitta en mängd olika verktyg, detta kan ställa till problem när man ska välja vilket verktyg man ska använda. För att kunna välja ett verktyg så bör man ha lite kunskap om det verktyget, har man ingen kunskap om verktygen så kan man hyra in kompetenser som kan hjälpa till med valet och om det är nödvändigt bistå med mer eller mindre hjälp under hela testet. Dessa kompetenser kan beroende på vad man vill spendera göra allt från att planera testet och analysera resultatet till att utföra hela test-arbetet. En nackdel som finns om man låter externa resurser utföra allt testarbete är att man efter slutförda testandet saknar kompetens i de testverktyg som användes, på grund av detta så är det alltid en bra ide att låta interna resurser delta i åtminstone själva testarbetet. 24

26 Kapitel 3 Testapplikationen Testapplikationen är en standalone lösning av flödesvisningen som finns i CAB s planeringssystem CAB Plan. Orsaken till att vi har valt att göra flödesvisningen som testprojekt är för att se hur CAB Plan skulle fungera som en Smart client lösning. 3.1 Översikt Flödesvisningen visar hur långt som de olika objekten 1 som finns på den aktuella plåt/lack-verkstaden har kommit i reparationsprocessen. Även om resten av planeringssystemet innehåller så mycket mer saker så är flödesvisningen den del som de flesta använder. Det finns verkstäder som planerar att visa flödesvisningen på verkstadsväggen med hjälp av projektor, detta ger ett enkelt sätt att visa hur man ligger till. Nyttan med flödesvisningen är att man direkt kan se vad som är redo för nästa moment och vilket moment som det är, det visas även när de olika momenten startades och när de stoppades. Nyttan med att få flödesvisningen i en egen applikation är att man inte behöver navigera fram till den via webbgränssnittet utan att man kan få upp den direkt. 3.2 Arbetsgång Följande moment ingår i utvecklingen: 1. Kravställning och grafisk design 2. Insamling av information för kommunikation med CAB Plan-servicen 1 Oftast bilar 25

27 3. Tidsuppskattning 4. Identifierande och skrivande av testfall 5. Iterativ implementation av applikationen kombinerat med tester av de färdiga delarna. Momenten ovan ligger i den ordningen som de är tänkta att utföras. Identifiering och skrivande av testfall kan varvas med den sista punkten då det är lätt att missa testfall innan man påbörjar implementationen, detta då man lättare hittar testfallen genom att man känner på systemet. 3.3 Uppbyggnaden av applikationen Testapplikationen ska bestå av ett huvudfönster där flödesvisning ska visas. Det ska finnas möjlighet att välja inställningar för vad som ska visas genom en inställningsdialog, alt check-boxar överst i fönstret. Det ska vara möjligt att uppdatera manuellt genom att trycka på en knapp. Applikationen kommer att fungera på följande sätt: Figur 3.1: Kommunikationsvägen i testapplikationen 1. Klienten anropar FlowShowServer-tjänsten på servern och ber om data, antingen flödet eller grunddatan. 2. FlowShowServer-tjänsten anropar SQL-servern och hämtar den begärda informationen genom anrop till olika lagrade procedurer (vilken som anropas beror på vilken data som efterfrågas). 3. SQL-servern returnerar resultaten av den lagrade proceduren. 4. FlowShowServer-tjänsten vidarebefordrar resultatet till klienten som sedan visar upp det för användaren. De anrop som kan ske till servern är följande: 26

28 getbasedata - Hämtar basdatan som behövs för att välja företag/filial vars flöde man ska visa. getflow - Hämtar aktuella flödet för den filial vars id skickats med i anropet. Eftersom detta är en intern testapplikation så görs ingen kontroll att användaren har rättigheter att se flödet utan det förutsätts att användaren har rättigheterna för att se de aktuella flödena Arkitektur Applikationen kommer att bestå av en client-server lösning skriven i WCF 2. Klienten kommer att vara av typen smart client vilket innebär att mycket av logiken kommer att ligga där, detta gör att servern kommer att bli mycket enkel och dess enda uppgift kommer att vara att ställa frågor mot databasen och sedan returnera resultatet (lite kontroller kommer att göras men inte många då det mesta av logiken och felkontrollerna ska ligga hos klienten). Uppbyggnaden av systemet har följande utseende: Designen av systemet kommer att ske enligt SOA 3, vilket Figur 3.2: Översikt över testapplikationens beståndsdelar. innebär att servern kommer att köras som en Webb service och kommunikation kommer att ske med hjälp av SOAP anrop. 2 Windows Communication Foundation 3 Service Oriented Applications 27

29 3.4 Utvecklingmiljön och dess mjukvaror Utvecklingsmaskinen är en vanlig pc med en tvåkärnig Intel Core Duo (båda a 2.16GHz), operativsystemet är Windows XP. Som utvecklingsmiljö så ska Visual Studio 2008 användas, det är även den som ska användas under prestandatesterna (men då ska versionen Visual Studio Team System 2008 Test edition användas). Som grund i kommunikationen mellan klient och server så kommer biblioteket WCF(Windows Communication Foundation) att användas. WCF kom i.net 3.0, och är en del av Microsofts verktyg för att ta fram SOA-applikationer. 3.5 Prestandatester Dokumentationen av testerna har ett upplägg med följande dokument: Testplan - Beskriver vilka tester som ska genomföras, tillgängliga resurser (både mänskliga och maskinella), aktuell tidsplan samt att i detta så definieras vilka verktyg som ska användas. Körrapport - Innehåller resultaten av de testkörningar som gjorts, komplett med utdrag ur testmiljöns summering av varje körning. Testrapport - Ett dokument som innehåller sammanställningarna från resultaten som finns i Körrapporten och de analyser/tankar som kommit upp under körningarna. Som man kan se så är det inget stort antal dokument som ska tas fram, men de är designade för att täcka in testprocessen Testupplägg Testerna kommer att utföras med hjälp av Visual Studio 2008 Team Test Edition. Testerna görs genom att skapa skript utformade som enhetstester från vilka man sedan gör anrop till servern. Då anropen till servern är ganska få så kommer det att testas med olika kombinationer av de anrop som finns. Då det största anropet tar väldigt många parametrar (runt 20st) så finns det en del att testa med. testerna kommer att köras både baserat på processorbelastning och med olika fasta antal användare. Genom att börja med måltester så kan man få fram var gränsen för användbarhet bör ligga. Maskinerna som ska användas under testerna är: Lastgenerator/server 1: CPU: Intel Core Duo 28

30 RAM: 1 GB OS: Windows XP Övrigt: Samma maskin som används för utveckling och lastgenerering. Server 2: CPU: Intel Core Duo RAM: 2 GB OS: Windows Vista Övrigt: Laptop, letades fram när testerna visade att den första datorn inte klarade att både generera last och agera server samtidigt. Som man kan se så är det en ganska stor skillnad mellan de två olika testmaskinerna. Det bästa sättet att köra testerna nu är att köra dem från båda maskinerna för att sedan jämföra prestandan, men då de skiljer både i styrka och i operativsystem så skulle en jämförelse varken bli rättvis eller enkel Testdata Testdatan är rätt så enkel då det kommer att handla om kombinationer av parametrar samt listor över de flödesvisningar som finns att välja mellan. För ytterligare information om testerna se bilaga B, Testplanen. 29

31 Kapitel 4 Sammanfattning 4.1 Prestanda I början så kan hela tänket runt hur man lägger upp testerna för prestandatester verka väldigt krångligt och abstrakt, men när man väl börjar arbeta med det så märker man rätt så snart att man väldigt enkelt kan få en bra överblick över hur saker ska testas. Som man kan se i figur 4.1 på sida 31 så är uppbyggnaden av testmaterialet ganska enkel och överskådlig. Alla krav (både ickefunktionella och funktionella), bugrapporter och ändringar ligger som grund till de testfall som man skriver för systemet. När man skriver sina testfall så delar man upp dessa beroende på vad som testas. Man bör ha ett område för varje del av systemet samt minst ett område för tester av sådant som inte går att koppla ihop med ett visst område av systemet. När man sedan ska utföra funktionstester så tar man ett testområde i taget, och man börjar med det område som har högst prioritet. När man ska planera för prestandatester så bör man ta fram de scenarier som är mest tänkbara att belasta systemet. Detta arbete bör man göra med hjälp av analyser av användningen av systemet och i samråd med de som utvecklar systemet, detta då de som utvecklar systemet brukar ha en väldigt bra uppfattning på vilka delar av systemet som man ska belasta för att på bästa sätt hitta vad som behöver förbättras. Riktlinjer för testfallen är: Enkelhet - Alla ska kunna utföra testerna. Noggrannhet - Allt som finns i systemet ska ha minst ett testfall kopplat till sig. Upprepningsbarhet - Varje test ska (om det är möjligt) avslutas med att man återställer systemet till status quo, detta för att det ska underlätta att man automatiserar testet. 30

32 Figur 4.1: Översikt över hur de olika delarna av testen hänger ihop. 31

33 Om man inte kan uppnå status quo med ett testfall så kan man skriva ett till där man återställer allt. Tydliga avgränsade testområden - Det ska inte råda något tvivel om vilket testområde som man ska leta i för att hitta tester för en viss del av systemet. Om testfallen spänner över flera områden och det då inte går att peka ut ett visst testområde så kan man lägga dessa testfall i ett eget testområde namngivet efter vad man testar. Följer man dessa riktlinjer så får man ett system med bra tester och som är enkelt att testa. Har man skapat testfallen på rätt sätt så kan man ofta (med små eller inga ändringar) använda dem vid prestandatesterna. I de fall som man inte kan nå status quo under ett testfall så bör det finnas ett testfall som återställer allt. Ser man till att det finns så kan man alltid automatisera testerna utan att man ska behöva göra manuella ändringar i testdatan för att återställa det efter att ha kört ett test. 4.2 Testapplikationen Testapplikationen delades upp i två faser, dessa var implementationen och testerna Implementationen Implementationen av serverdelen av testapplikationen gick gick relativt snabbt och var förhållandevis enkel. Det som tog tid var att förstå uppbyggnaden av WCF-servicen, men till det så fanns det litteratur att tillgå. Design och implementation av klienten tog däremot längre tid än väntat. Själva användargränssnittet (GUI t) gick relativt fort men att tolka och behandla svaren från databasen tog mycket längre tid än beräknat. En annan sak som tog tid var att hitta en grid(rutnät) som klarade av att man hade olika antal kolumner. Det grid som följer med i.net har inga sådana funktioner, genom tester av olika varianter (även ett försök att kombinera Winforms med WPF 1 ) så slutade det med att (Ultra)WinGrid från Infragistics valdes. Detta är uppbyggt runt en samling av band som var för sig kan innehålla en valfri mängd kolumner. Resultatet av detta val är att varje schema som använts blir ett eget band i schema-vyn, detta ger även att funktioner för sortering av resultaten inte behöver implementeras då WinGrid redan har grundläggande sortering inbyggt från början. 1 Windows Presentation Foundation 32

34 Klientens utseende I detta avsnitt visas klientens slutgiltiga utseende. Följande delar kommer att visas: Klientens huvudfönster Val av filial Visning av flödet Klientens huvudfönster Klientens huvudfönster är som man kan se i figur 4.2 ganska spartanskt utformat, men det innehåller samma kontroller som den webblösning som den ska likna. Det enda som fattas är Visa Detaljinformation, detta då denna information nu ligger i inforutan som ligger på rutan med registreringsnumret på varje rad. Figur 4.2: Klientens huvudfönster. 33

35 Val av filial Fönstret för att välja vilken filial som ska visas är delat i tre delar, för att välja den filial som ska visas så måste man först välja företag och sedan en region för att sedan kunna välja bland de filialer som finns i regionen. Anledningen till detta är att ett företag kan vara uppdelat på flera regioner och att varje region då kan ha flera olika filialer. Figur 4.3: Val av den filial vars flöde som man vill se. 34

36 Visning av flödet De olika momentens status markeras med hjälp av olika färger och symboler. Följande markeringssystem används: Status Bakgrundsfärg Symbol Obokad Vit Bokad Grå Röd bock Planerad Vit Svart Bock Startad Gul Grön pil Pausad Röd Klar Grön Ska ej utföras Vit Svart pil Tabell 4.1: Markeringsystem för momentstatus Varje tabell som visas i bilden motsvarar ett bokningsschema i systemet. Skillnaden här mot originalet är att i originalet så kan man trycka på raden för det aktuella objektet för att få se mer information, i denna implementation så ligger denna information i inforutan för rutan där man ser registreringsnumret. Valet att lägga informationen här är att det förenklade arbetet med implementationen. Figur 4.4: Visning av aktuellt flöde. 35

37 4.2.2 Testerna Testerna av testapplikationen gick inte helt utan problem. Först så fanns det bara en maskin att köra mot (samma maskin som testerna skulle exekveras på, detta är i sig är en dödssynd inom prestandatester), och detta gjorde att när lasten ökade så gick maskinen på nästan ned vid 2 samtidiga användare samt att svarstiderna blev otroligt långa (de flesta gångerna resulterade det i timeout). Problemen med svarstiderna gällde endast anropen för att hämta själva flödesvisningen, de anrop som gjordes för att hämta grunddatan gick att skala upp tills det berodde på andra delar än minne och cpu (mestadels så verkar de flaskhalsarna ligga i hårddisken). Efter en del sökande så kom det fram ytterligare en maskin att köra tester mot, denna maskin hade till skillnad mot den föregående maskinen(med Windows XP) Windows Vista. Den nya maskinen var bra utrustad och borde utan problem kunna leverera den prestanda som behövs för att kunna pressa tiderna för anropen. Nu låg problemen istället i operativsystemet, första försöket att köra tester föll på att Vistas brandvägg blockerade alla anrop. Eftersom företagets IT-policy inte tillåter att brandväggen stängs av så blev resultatet att det fick läggas in regler för att släppa igenom trafiken från lastgeneratorn. Men trots att regler som öppnade de aktuella portarna lades in samt att kraven på autentisering togs bort så ville servern inte tillåta att testerna utfördes utan problem. Ibland så gick det inte att få kontakt med server-mjukvaran på servern (anslutningen nekades av brandväggen) och ibland så kom det bara tillbaka krav på autentisering genom proxy (trots att kravet för detta tagits bort i inställningarna). När man till slut lyckades komma igenom brandväggen så gick det max att köra tester i 2.5-3,5 minuter innan det återigen började komma krav på autentisering genom proxyn. Efter många timmars försök att råda bot på problemen och mycket sökande efter lösningar på internet så fick denna maskin ges upp och testerna exekverades istället mot den dator som användes som lastgenerator Testresultat Sammanfattningen av testerna är att i scenario 1 (Hämtning av grundinformation) så var det till slut hårddisken som var flaskhalsen. Detta resultat kom av att processor-belastningen inte ökade när antalet anropande trådar ökade, utan processor-belastningen låg ganska stabilt medans väntetiden i sql-servern började stiga samtidigt som köerna på hårddisken växte. Resultatet i scenario 2 (Hämtning av grundinformation samt flöde) blev lite annorlunda, även här så förekom det köer till hårddisken men redan vid 2 anropande trådar så gick processor-belastningen i topp och sjönk sällan under 95%. Detta tyder på att det behövs mer beräkningskraft, då en medelbelastning på över 65-70% betyder att processorn börjar bli hårt belastad och att den kommer att 36