2002:034 HIP EXAMENSARBETE Automatiserad Testning HÖGSKOLEINGENJÖRSPROGRAMMET DATATEKNIK Institutionen i Skellefteå 2002: 034 HIP ISSN: 1404-5494 ISRN:LTU - HIP - EX -- 02/034 --SE
Förord Denna rapport är en del av det examensarbete jag utförde åt FDT AB i Luleå under perioden 2002-04-02 2002-06-10. Examensarbetet ingår som ett delmoment i Dataingenjörsprogrammet vid Luleå tekniska universitet, Institutionen i Skellefteå och omfattar 10p. Jag vill tacka min handledare på FDT, Peter Joki, samt all övrig personal som utgjort ett stort stöd för mig under arbetets gång.
Sammanfattning Arbetet innehåller en allmän presentation om automatiserad testning, om var man kan tjäna tid samt vilka fällor som finns. Vidare har en analys gjorts på de olika verktyg som finns på marknaden idag och teknikerna bakom dessa. Jag kom fram till att de verktyg som endast har en Capture/Playback funktion inte skapar speciellt smarta scriptfiler, det bästa sättet är att manuellt skapa testsscript och skriva funktioner som kan anropas från de olika testuppsättningarna. Därefter valdes ett verktyg ut åt FDT, nämligen Rational Visual Test. En kort presentation av detta program och de tekniker som stöds tas upp. Slutligen har jag gett förslag på en uppdaterad version av FDT s testmetodik idag, för att just anpassas mot en delvis automatiserad testning.
Abstract This report contains an introduction to automated testing, where the cost benefits are, and what traps to look out for. An analyze of the different tools for testing programs with a GUI available on the marketing today has been made, and the different techniques behind these. Further on was an automated test tool chosen for the company (FDT AB). This tool is made by Rational and is called Visual Test. A short presentation of this program and the different techniques that can be used is also included. Finally I have given a proposal for an updated version of FDT s testmethology today adapted for an automated test tool.
Innehållsförteckning 1. INTRODUKTION... 4 2. AUTOMATISERAD TESTNING... 4 2.1 INLEDNING... 4 2.2 PROBLEM MED AUTOMATISERAD TESTNING... 4 3 VAD ÄR ETT FEL?... 4 3.1 LAGRINGSFEL... 4 3.2 TID/PRESTANDA FEL... 4 3.3 ANDRA FEL... 4 3.4 DATABASFEL...FEL! BOKMÄRKET ÄR INTE DEFINIERAT. 4. OLIKA VERKTYG PÅ MARKNADEN... 4 4.1 CAPTURE/PLAYBACK... 4 4.2 FUNKTIONELLA TESTSCRIPT... 4 4.3 VÄRDEFULLA KONTROLLER VID VAL AV VERKTYG... 4 5. ATT SKRIVA TESTSCRIPTER... 4 5.1 VEM SKA SKRIVA TESTSCRIPTER?... 4 5.2 VAD SKALL AUTOMATISERAS?... 4 5.3 FELHANTERING... 4 5.4 DEFINIERA KONSTANTER... 4 5.5 SKRIV FUNKTIONER... 4 5.6 OBEROENDE TESTCASES... 4 5.8 CAPTURE VERKTYGET... 4 5.9 LOGGNING... 4 5.10 KONTROLLPUNKTER... 4 6. VAL AV VERKTYG... 4 6.1 RATIONAL VISUAL TEST... 4 6.2 VISUAL TEST PROJEKT ETT PROJECT ÄR UPPBYGGT AV FÖLJANDE FILER.... 4 6.3 SCRIPTSPRÅKET... 4 6.4 IDENTIFIERA KONTROLLER... 4 6.5 PÅVERKA KONTROLLER... 4 7. NUVARANDE TESTMETODIK... 4 7.1 ÖVERBLICK... 4 7.2 TESTFASERNA... 4 7.3 TESTER VÄRDA ATT AUTOMATISERA... 4 7.4 VAD KAN INTE SIMULERAS?... 4 7.5 TESTMILJÖ... 4 8 TESTMETODIK ANPASSAD FÖR AUTOMATISERAD TESTNING... 4 8.1.1 TESTANPASSADE ANVÄNDARFALL... 4 8.1.2 GUI... 4 8.2 TESTPLANERING... 4 8.2.1 RIKTADE TESTER... 4 8.2.2 SAMTIDIGHETSTEST... 4 8.2.3 FAT TEST... 4
8.2.4 TESTMANUALER... 4 8 RESULTAT/SLUTSATS... 4 10 REFERENSER... 4
1. Introduktion 1.1 Problemställning FDT har flera affärssystem vilka ständigt utvecklas. När en förändring av programmet sker måste dels den nya programkoden testas men även den befintliga. Detta är ett tidskrävande arbete som dessutom kan anses tråkigt och enformigt. På FDT hade man en ide om att automatisera testningen för att kunna exekvera tester obemannat och analysera testresultaten i efterhand. 1.2 Bakgrund till problemställningen FDT är ett företag som utvecklar och säljer affärssystem för små- och medelstora företag i Sverige. De har funnits sedan 1979 och har mer än 4000 företag som använder deras system med cirka 30 000 användare. Systemen skall när de kommer till kunden vara testade och fungera klanderfritt från installation till drift i olika operativsystemsversioner av Windows. Kunderna har ofta en liten erfarenhet av datorer varför testning och verifiering är av största vikt. 1.3 Arbetets syfte Syftet med föreliggande arbete var att ta fram en strukturerad testmetod utformad för att ta hjälp av ett automatiserat testningsverktyg och testa standardprodukter som FDT utvecklar. I arbetet ingick även att ta fram en manual för hur testning ska gå till, och målsättningen var att en utomstående konsult i stort sett endast ska läsa manualen och därefter utföra testning på FDT s programvaror. Vidare så ingick i arbetet att välja ut ett verktyg för den automatiserad testningen, implementera och utvärdera detta samt att införa i skarp drift. 1.4 Förkortningar och begrepp GUI är en förkortning för Graphical User Interface, dvs. ett program med ett grafiskt gränssnitt. Med FAT menas ett test som ska simulera en längre användning tidsmässigt. CR är en förkortning för Capture/Replay, är den typ av program som har möjligheten att spela in musrörelser och knapptryckningar för att sedan spela upp dessa igen. Med testcase menas ett eller flera användarfall som exekveras efter varandra. En testsuite är en samling av testcases.
2. 2.1 Inledning Behovet för en automatiserad testning har vuxit fram i och med att allt fler applikationer idag har ett grafiskt interface (GUI). Det finns verktyg som hjälper programmerare att skapa avancerade grafiska system på ett enkelt och snabbt sätt. I och med detta får testavdelningen krav att testa fler rader kod på mindre tid och testningen blir ofta en flaskhals för de olika projekten. De dyraste felen är de fel som upptäcks ute hos kunden vilket är något man vill undvika. Ju tidigare man kan börja designa och planera testning desto bättre testresultat erhålls. För att kunna börja testdesignen så tidigt som möjligt krävs ett gott samarbete mellan testare och utvecklare. Det är viktigt att veta om det krävs förändringar av det grafiska gränssnittet och vilka funktioner i programmet som kanske kräver en noggrann testning. Under min tid hos FDT har jag uppdaterat deras testmetodik för att anpassas för ett automatiserat testverktyg. Dock har metodiken ej testats i ett skarpt projekt ännu, eftersom projektet som jag skulle involveras i blev uppskjutet en bra bit in i framtiden. Att automatisera tester innebär att man simulerar en aktörs agerande mot ett målsystem. För att göra detta kan man antingen simulera musrörelser, tangentbordstryckningar eller manipulera kontrollerna direkt. För att göra det sistnämnda måste man först av allt identifiera de Windows kontroller man vill manipulera, mer information om denna procedur finns längre ner i detta dokument. Idag finns det en mängd program på marknaden som känner av de flesta av Windows standardkontroller. Tanken med automatiserad testning är att testerna ska kunna exekveras obevakat, just därför måste testerna vara så gjorda att de inte hänger sig ifall ett fel uppstår, utan att de har möjlighet att logga vad som har hänt, vilket tillstånd programmet befann sig i och sedan fortsätta exekveringen. Mer om detta och andra tekniker för att skapa testscripter beskrivs senare i detta dokument. 2.2 Problem med automatiserad testning Att automatisera tester är långt ifrån en dans på rosor. Många faktorer kan påverka och göra att tester inte fungerar som dom skall. Några exempel på detta är: Knappar går inte att trycka på (inaktiverade) Verktygsfält och menyer ändras under programmets gång Datafält ändrar färg till gråa och blir endast läsbara Den bitmap bild du sparat som referensbitmap innehåller datum och tid Applikationen minimeras Hårdvara som inte går att simulera, ex. streckkodsavläsare, skrivare mm Andra överraskningar
3 Vad är ett fel? En lyckad testare är en testare som hittar många buggar. Mardrömsscenariot är att köra igenom ett test och testscriptet hittar inte några fel fastän det finns fel i programmet. Det gäller därför mäta data och säkerställa att allt går som det ska så ofta som möjligt. 3.1 Lagringsfel När tester spelas in med Capture/Replay verktyg som spelar in musknappar och tangentbords tryckningar, t.ex. tryck på spara knappen vänta tills sparat visats i en status ruta så spelas inte egentligen något meningsfullt test in eftersom vi inte verifierar att det vi skriver in verkligen har sparats. För att verifiera detta kan något verktyg utöver det automatiska testningsverktyget användas eller om det finns möjlighet laddas samma värden upp i programmet igen och jämförs. Följande steg kan man gå igenom för att bättre verifiera att rätt data har sparats ner. 1. Ange data 2. Spara data 3. Ladda in data i programmet igen 4. Verifiera att rätt data har sparats Men ovan angivna steg kan inte bevisa att data har sparats ner av någon annan klient på nätverket. Systemet kan visa en popupruta som frågar ifall vi vill skriva över data, detta skapar ett helt nytt problem, testcaset måste skrivas om till förslagsvis följande: 1. Ange data 2. Spara data 3. Om Skriv over ruta visas, tryck på OK knappen 4. Ladda in data i programmet igen 5. Verifiera att rätt data har sparats Efter ett test har exekverats måste databasens konsistens säkerställas. Detta är en enkel procedur ifall endast en klient har utnyttjat databasen, då utförs en jämförelse mellan utgångsdatabas och en slutdatabas. Svårigheterna uppstår när flera klienter samtidigt arbetar mot samma databas, hur kan då databasens konsistens säkerställas? Ett sätt som man använt hos FDT är att man i MS Access importerar den slutliga databasen till en tom databas och kontrollerar att inga felmeddelanden uppstått under importen. Ett annat sätt är att man skapar ett verktyg som kan verifiera att alla fält i databasen har fått korrekta värden för målprogrammet. 3.2 Tid/Prestanda fel I automatiska testverktyg kan specificeras hur lång tid man ska vänta på att kontroller skall visas eller få rätt status. Efter angiven tid kan ett prestandafel anses ha inträffat.
3.3 Andra fel Här följer en lista på andra fel som kan uppstå i ett program: Förbjudna åtgärder (skriver över felaktiga minnesadresser) Minnesläckage (kan yttra sig som Ont om virtuellt minne etc.) Matematik fel (division med noll, datatypen, overflow etc.) Nätverkskrockar (två klienter försöker använda samma utrymme i databasen samtidigt etc.) Fel i ini filer, variabler som räknats upp för högt etc
4. Olika verktyg på marknaden 4.1 Capture/Playback Första målet i arbetet var att hitta ett verktyg att automatisera testningen med. På marknaden finns en mängd olika verktyg för detta ändamål. Ett sätt att underlätta skapandet av testcases av grafisk programvara är att använda ett s.k. Capture/Playback verktyg, som idag används flitigt. Dock visade sig att denna metod inte är speciellt bra att skapa testscript med. Nackdelar med de script som är skapade av ett CR verktyg är följande: Testcasen som skapas blir väldigt hårdkodade, d.v.s. om en det sker en förändring av programmet eller man vill testa med andra inparametrar måste hela testet spelas in på nytt. De testcase som skapas brukar inte kunna hantera att ett fönster eller en annan kontroll tar längre tid på sig att visas än vad det gjorde när man spelade in testet. Om testaren gör ett fel under inspelningen måste hela testet spelas in på nytt. Kostnaden för att underhålla dessa script är höga. De flesta Capture/Playback verktyg som finns idag är objektorienterade, d.v.s. de känner av GUI objekt i programmet (EditBoxar, Radiobuttons, fönster etc) och inte bara X,Y koordinater. När man spelar in ett test med dessa verktyg skapas en scriptkod liknande C eller Visual Basic språk. Det kan därför vara en ide att när man bygger upp testscript använda Capture funktionen för att undersöka hur programmet anropar olika GUI objekt. De flesta scriptspråk tillåter att man bygger upp cases med loopar, subrutiner, filläsning, variabler etc, det går således att bygga väldigt avancerade testscript. Att skapa automatiska testcases är i sig ett programmeringsarbete, script som skapas måste således testas innan de kan tas i bruk. 4.2 Funktionella testscript Alternativet till Capture/Playback metoden är att bygga upp script med funktioner som kan anropas från olika testcases. Dessa funktioner måste vara oberoende av varandra och alla måste startas från samma tillstånd i programmet. Det finns några olika typer av funktioner: Navigation (tex. starta uppdatera kund rutan) Speciella funktioner (skapa en kund) Data verifikation (verifiera att kunden blev sparad på rätt sätt) Återvändande navigation (stäng ner uppdatera kundrutan och fokusera huvudfönstret) När alla funktioner man behöver har skapats, kan man på ett enkelt sätt anropa dessa från sina testcases och således komponera ihop olika varianter av tester. Ett smart sätt för att ytterligare återanvända funktioner är att ta emot inparametrar till funktionerna, exempelvis kan skapa kund funktionen ta emot kundens alla attribut som skall lagras.
4.3 Värdefulla kontroller vid val av verktyg Stöds de kontroller som finns i målprogrammet av verktyget? Detta kan kontrolleras vid vilken utvecklingsmiljö som målprogrammet är skapat i. Vad skall testas, funktionalitet, stress, web etc. Prisskillnaden är enorm på marknaden, det billigaste verktyget kan kosta under tusenlappen och de dyrare kan kosta uppåt tio tusen.
5. Att skriva testscripter 5.1 Vem ska skriva testscripter? Den person som skall skriva testscripter för automatiserad testning bör ha både goda programmeringskunskaper och testkunskaper. Det är viktigt att personen ifråga är medveten om att göra sina testscripter enkla att uppdatera när nya versioner av målprogrammet släpps. Det gäller att ha ett nära samarbete med dom som utvecklar programvaran ifall tex GUI måste ändras etc. 5.2 Vad skall automatiseras? En tumregel är att se på vad som tar lång tid just nu att testa manuellt, här kan det vara värt att införa en automatisering. Man vill inte automatisera tester och i efterhand upptäcka att det hade gått mycket snabbare att bara köra igenom testet manuellt. Detta kan lätt leda till att det inköpta testverktyget hamnar på en hylla och samlar damm. Att testa programvaror kan upplevas tråkigt, det är däför vanligt att testarna börjar automatisera de enklaste testerna som i egentligen borde exekveras manuellt bara för att de tycker att det känns mer meningsfullt att få koda scripter. Detta kan resultera i att testscripterna tar betydligt längre tid att skapa än vad de skulle ha tagit att köra de manuellt, detta för att själva testscripterna också måste testas så att de är felfria. 5.3 Felhantering Om testet skall gå under lång tid utan övervakning, säg tex över en natt så får scriptet inte hänga sig. Varje testcase måste kunna avbrytas vid fel, därefter ska en rutin ta tillbaka till ett state så att efterföljande testcase ska kunna fortsätta exekvera. Ifall en förbjuden åtgärd eller liknande inträffar kan Rational Suite ställas in så att datorn startar om och fortsätta exekveringen. Det absolut värsta som kan hända under en testexekvering är att det finns fel i programmet men att de ej upptäcks av testscriptet, detta kommer resultera i att ingen kommer att vilja använda scripten och testningen kommer sannorlikt gå tillbaka till den manuella formen. När scripter skapas är det viktigt att hela tiden verifierar att allt går bra i programmet. Viktigt är också att verifiera att testarna verkligen loggar de fel som inträffar i felhanteringen, så att inte tex en felmeddelande ruta släcks ner utan att något meddelande om detta lagras. Efter ett fel har upptäckts och loggats måste programmet återgå till ett känt tillstånd så att efterföljande testcase kan fortsätta exekvera, det kan handla om att släcka ner alla öppnade popuprutor etc. 5.4 Definiera konstanter Det är viktigt att hitta alla konstanter i programmet (captions på fönster, id på knappar etc) och definiera dessa i en include fil för att förenkla uppdateringen av testscripterna när en ny programversion släpps. 5.5 Skriv funktioner Skriv användarfall som funktioner (generalisera) som kan anropas från varje testcase för att förenkla ändring av scriptet. Skriv funktionerna i en include fil som alla testcases kan inkludera.
5.6 Oberoende testcases Skriv alla testcases så dom är oberoende av varandra, dvs samtliga cases ska börja exekvera från samma tillstånd i programmet. För att underlätta fortsatt exekvering även efter ett failure, är det av vikt att hitta ett tillstånd i programmet där samtliga testcases kan utgå ifrån. 5.8 Capture verktyget Capture verktyget bör användas för att dels kontrollera så att alla kontroller stödjs av verktyget samt för att på ett snabbt sätt få fram scriptkod som kan redigeras i efterhand. 5.9 Loggning Logga mycket och ofta, detta kommer att förenkla arbetet att hitta vad eventuella fel beror på. Felaktigheter måste lagras, vilken tid samt vilket testcase (vilket tillstånd programmet var i) som exekverades när felet upptäcktes. 5.10 Kontrollpunkter För att kontrollera att programmet exekverar korrekt, måste testaren under programmets gång hitta punkter där man kan kontrollera att alla värden är tillförlitliga. Det kan handla om värden i editrutor, fönster som kommer fram på rätt ställen och radiobuttons värden. 5.11 Inparametrar Inparametrar till testcases bör inläsas från en fil, så att de som skall använda de skapade testcases på ett enkelt sätt kan modifiera inparametrarna utan att exakt veta hur testscripten är uppbyggda eller hur testscriptsspråket fungerar.
6. Val av verktyg FDT utvecklar sina system i Microsoft Visual Basic och det var därför viktigt att hitta ett verktyg som stödjer Visual Basic kontroller. Vidare fanns ett behov för ett verktyg som var användarvänligt, dvs. enkelt att komma igång med och att det ska finnas möjlighet att enkelt uppdatera script för senare versioner av målprogrammet. Från Rational s hemsida laddades hem en demoversion av programmet Rational Visual Test och detta är ett verktyg som gott och väl fyller FDT s krav. På FDT fanns det av en slump redan en version av Rational Visual Test, men tyvärr fanns det ingen cd-skiva så en uppgradering för 2700kr till den senaste versionen (6.5) införskaffades. 6.1 Rational Visual Test Rational Visual Test använder sitt egna scriptspråk som påminner mycket om Visual Basic syntax. Programmet är uppbyggt följande fyra programdelar: Visual Test, i denna del skrivs all scriptkod. Programmets utseende liknar mycket Microsoft Visual C++, och man arbetar med projekt på ett liknande sätt. Suite Manager är det program som exekverar de testcases som skapats i Visual Test, man kan välja att exekvera script i en viss ordning och hur många gånger man vill repetera olika script filer/mappar. Window Information, denna programdel ger information om fönster och dess komponenter. Tex vad ett fönster har för caption, vilket ID en EditBox har etc. Scenario Recorder har möjligheten att spela in musrörelser och tangentbordstryckningar till scriptkod för att spelas upp senare (Capture/Replay). 6.2 Visual Test projekt Ett project är uppbyggt av följande filer. *.mst I dessa filer skriver man ner sina testcases i Rationals testscriptsspråk. *.tpl Templates är fördefinierade filer. När en ny mst fil skapas blir den likadan som denna fördefinerade fil. Man kan ha en tpl fil för varje katalog som man arbetar med i projektet. *.inc Include filer används till att definiera upp knappar, fönster, comboboxar etc. Så att man slipper ändra i varje mst fil ifall en ändring har gjorts på programmet. Man kan även i dessa lägga ofta förekommande funktioner som anropas från mst filer. *.vts Sparade filer från Suite vilka inkluderar flera mst filer.
6.3 Scriptspråket Rational Visual Test arbetar med ett eget scriptspråk som består av två delar.till att börja med själva testscriptsspråket som innehåller möjligheter att skapa funktioner, nyckelord, for satser, if else och definiera variabler av olika datatyper, m.m. Dessutom finns Rationals inbyggda funktioner som används för att manipulera och verifiera Windows kontroller. 6.4 Identifiera kontroller Ett sätt att identifiera vissa kontroller, till exempel fönster och knappar är att använda deras caption (d.v.s. texten associerad med dom). Det går även att använda sig av kontrollernas unika id nummer, vad numret är kan man ta reda på med Window Information programmet. Andra sätt är dess tabordningsnummer eller handles. Handle är ett nummer (long) som windows dynamiskt delar ut olika varje gång programmet startas till samtliga kontroller. För att ta reda på en handle måste man antingen veta Caption på kontrollen eller dess ID nummer. 6.5 Påverka kontroller När man väl har identifierat kontrollen vill man modifiera eller kanske kontrollera i vilket tillstånd kontrollen befinner sig. Rational har för varje komponent den stödjer en hel uppsättning av metoder för att påverka eller läsa av värden. Några exempel på metoder är: WMenuSelect(FILE_MENU) ' Klickar på den fördefinierade filmenyn WEditSetText("Mark","50") ' Anger värdet 50 i editrutan Mark WButtonClick("Calculate") ' Klickar på knappen med texten calculate Det går även att påverka kontroller utan att identifiera dem. Detta genom simulering av knapptryckningar och musrörelser. Detta rekommenderas inte eftersom det kan medföra buggar i testscripten, då scriptet inte bryr sig om timingproblem. Fel som kan uppstå är att saker utförs vid fel tidpunkt, tex. trycks ok knapp innan rutan med ok knappen har visats. För att simulera knapptryckningar och musrörelser i Rational Visual Test används kommandot PLAY. Några exempel på play: Play "Japan" Play "{ESC}" Play "{TAB 3}" Play "{CLICK 20, 30}" visst fönster Play "~" PLAY "{MOVETO 260, 135}" Skriver Japan Trycker Escape Trycker på TAB tangent tre gånger Klickar på en viss pixel i ett Trycker Enter Flyttar muspekaren
7. Nuvarande testmetodik 7.1 Överblick På FDT använder man sig idag av den s.k. vattenfallsmodellen vid utvecklingsprojekt. Det vill säga projektets olika faser efterföljer varandra. Eftersom testningen kommer sist i projektordningen kommer den att bli den sista fasen och kanske den som får mest tidspress pga. deadlines. Design/GUI Kodning Testning Final release Tid 7.2 Testfaserna Testmetodiken hos FDT skiljer sig mycket beroende på vilken programvara som skall testas. Faktorer som påverkar testningen kan vara att programmet är ett fleranvändarsystem (dvs. ska köras på ett nätverk) och hur komplext programmet är. Som första uppgift och för att lära mig Rational Visual Test bättre ansågs det lämpligt att skapa testcases mot FDT s butiksdataprogram vilket är det program som krävt mest testning. Man har delat upp testfaserna i dessa fyra steg: 1. Utseende och layout kontroll, här kontrolleras det grafiska gränssnittet. Man kontrollerar bl.a. stavning, positioner, tabbordning, snabbtangenter 2. Kontroll av indata, här kontrolleras vad som händer om ett fält får en annan datatyp inmatning än vad som förväntas. 3. Riktade tester, innebär funktioner i programmet som anses måste särtestas. Bland annat har man vart tvungen att utföra speciella momstester för att säkerställa att programmet hanterar olika momssatser samt att den skriver rätt i databasen. 4. Samtidighetskontroll, här verifieras att de olika modulerna fungerar tillsammans på ett nätverk. 5. FAT test, kontrollerar att programmet körs under en längre tidsperiod utan att hänga sig eller bli segt.
7.3 Tester värda att automatisera Testfaserna utseende kontroll och kontroll av indata är manuella tester som inte tar så lång tid att utföra, därför finns det ingen anledning att automatisera dessa tester. De riktade testerna, samtidighetstestet och FAT testet är tester som kommer repeteras flera gånger och därför lämpar sig en automatisering alldeles utmärkt. FAT testet är tänkt ska kontrollera målprogrammet under en längre tidsrymd, exempel på detta är deras Butiksdatasystem då vill man simulera en veckas körning på en diversehandels affär med en jämn kundström. Med Rational Visual Test går mycket snabbare att simulera kunder än i verkligheten och man kan på ca 6-7 timmar simulera en hel veckas körning i verkligheten. 7.4 Vad kan inte simuleras? Nackdelar med automatiserad testning är att man inte kan simulera all hårdvara, exempelvis kan inte streckkodsavläsningar simuleras och dessa ingick i FAT testets original specifikation. Möjligtvis kan streckkoderna läggas framför streckkodsavläsaren, men då kommer endast denna streckkod läsas in konstant. 7.5 Testmiljö På varje klient finns Rational Visual Test installerat och testet inkluderar två kassor med kontant och faktura kunder. Från min suite går det att välja hur många kunder som ska simuleras samt vad dom ska utföra. LAN Segment Ethernet Windows 2000 Server Butiksdator1 loggning Butiksdator2 loggning Program Databasfil Dokumentera alla fel och i vilket tillstånd som programmet befann sig i. Inför sedan till Bugcollector databas. Bugcollector databas med felaktigheter som skickas till utvecklarna för rättning.
8 Testmetodik anpassad för automatiserad testning 8 Design 8.1.1 Testanpassade användarfall 8.1.2 GUI att skapa testscript mot Utveckling Kodning Utveckling av mjukvara påbörjas. Utgår från GUI och om en ändring krävs måste test -avdelningen underrättas samt en ny exe fil byggas. Testning 8.2 Testplanering 8.2.1 Bestäm vilka riktade tester som ska köras. 8.2.2 Designa Samtidighetstest. 8.2.3 Designa FAT-testet. 8.2.4 Testmanualer Release Version X Ny exe fil, kontrollera om script måste uppdateras Bug fixar Genererar en ny programversion Grundläggande kontroller GUI kontroll Kontrollerar stavning, Menyer, knappar etc. Kontroll av indata Fel inmatningar Bugcollector databas Buggar Buggar Buggar Riktade/Manuella tester Riktade tester (indata utdata) Databas (tom eller fylld) 8.5 Samtidighetstest 8.5.1 Nätverkstester 8.6 FAT Test Testet OK Testet OK Testet OK 8.6.1 Prestanda, minnesläckor, etc
8.1.1 Testanpassade användarfall Utgå ifrån kravspecifikationen och bygg användarfall. Dokumentera dessa enligt en uppdaterad mall. Förskök till varje skapat användarfall finna en möjlighet att verifiera att användarfallet exekveradat korrekt. Användarfall Namn på användarfallet Vad som händer i systemet Detaljerad systembeskrivning om vad som händer under ytan Hur görs detta i programmet Hur ska man navigera sig igenom programmet för att utföra användarfallet? Verifikation Hur kan man verifiera att användarfallet har exekverat OK? Felmeddelanden/Utökningar Vilka utökningar finns till användarfallet, felmeddelande rutor etc. 8.1.2 GUI Kontrollera inledningsvis att de kontroller som finns i målprogrammet stödjs av Rational Visual Test. Om inte kontrollerna stödjs måste PLAY kommandot användas och det är något man vill undvika pga timingproblem. Kör efter detta företagets standard kontroll mot GUI (detta kan innehålla saker som rättstavning, tabavstånd etc). Bygg därefter en dummy exe version av programmet med tomma funktioner, denna skall användas att bygga testscript mot. Efter detta kan kodningen av programmet börja och testplaneringen.
8.2 Testplanering För att lyckas med testning gäller det att komma igång med planeringen så fort som möjligt. Avgör vilka tester som ska utföras, därefter vilka som det finns anledning till att automatisera. Att ha i åtanke vid testning är att allt inte går att automatisera, vissa hårdvaru komponenter kräver en manuell testning. Avgör sedan vilken prestanda systemet skall klara av (svarstider) och definiera dessa i Rational Visual Test. Bygg därefter de användarfall som skall automatiseras i Rational Visual Test. 8.2.1 Riktade Tester De riktade testerna skall särtesta vissa funktioner/användarfall i programmet, fundera vilka dessa är, vilka inparametrar som ska användas och vad utdata ska förväntas bli. Skapa testinstruktioner för de riktade testerna, där det anges hur man startar testerna samt vilka inställningar i scriptet som måste göras. 8.2.2 Samtidighetstest Samtidighetstestet skall verifiera att målprogrammets olika moduler fungerar tillsammans på ett nätverk. Avgör vilka användarfall/funktioner som ska ingå i testet. Försök hitta de användarfall som använder programmets databas längst tid. Skapa även här testinstruktioner till testerna. 8.2.3 FAT Test FAT testet är det sista testet och skall verifiera att programmet kan exekveras under en längre tid utan att bli segt eller hänga sig. Avgör här vilka användarfall som skall köras under testet, försök få med så många som möjligt. Vissa användarfall ska köras mer ofta än andra, försök återspegla verkligeheten i så stor utsträckning som möjligt. Skapa testinstruktioner till testerna. 8.2.4 Testmanualer Skapa för varje test en manual så att någon annan än den person som skapat scriptet har möjlighet att starta ett test. Förutsättningar: Simuleringstid Vilka klienter ingår i testet Datum och tid då testet utfördes Prestandakrav: Maximal timeout Databas: Utgångsdatabas Slutdatabas Hur lång tid ska vi simulera, dvs hur många testcases ska vi köra för att uppnå en verklig systemtid. De datorer som ingår i testet. 2002-05-30 10:59 till 12:05 Den timeout som bestämmer om ett prestanda fel hittats. Den databasfil som testet ska utgå ifrån Hur databasen ska se ut efter ett lyckat exekverat test
Systembeskrivning: Klient benämning Operativsystem : Windows 2000 Pro Swe Ex Butiksdator1 Hårdvara : PII450 Externa enheter : Kvittoskrivare Målprogram Program under test: ButikPE 1.1.10 Script inställningar Sökvägen till projektet Inställningar i testscriptet Inställningar i Rational Suite Övriga inställningar Åtaganden efter test Vad som skall utföras efter exekvering. Utfall av testet Notera vilken dator som upptäckte felet vilken tid samt vad de andra klienterna exekverade i samma stund.
8 Resultat/slutsats Resultaten visar att automatiserad testning definitivt inte ersätter manuell testning. Däremot finns det klara vinster med att automatisera tester som tar lång tid att exekvera manuellt och som skall repeteras många gånger. Ett annat resultat av detta arbete är att de så kallade Capture/Replay verktyg som finns på marknaden inte är speciellt smarta när det gäller att återanvända tester för på nya versioner av målprogram. Vad man istället bör göra är att skapa ett testscript i verktyget, där man anropar gemensamma funktioner (kan vara ett användarfall) för att det på ett enkelt sätt ska gå att komponera ihop olika testuppsättningar. Dessutom förenklar detta sätt uppdateringen av testscripterna för att även fungera på nya versioner av målprogrammet. Den som ska skriva testscripter bör ha kunskaper i både programmering och testning. Det är även av yttersta vikt att visa tålamod för den automatiserade testningen från början eftersom testscripterna i sig säkerligen kommer att bugga (dvs. inte hitta fel i programmet eller hänga sig). Visas inte tålamod i början är risken stor att verktyget kommer ignoreras och man istället går tillbaka helt till den manuella testningen. När man väl har byggt upp en testsuite till ett program går det på ett enkelt sätt uppgradera scripterna för att även testa nyare versioner av målprogrammet. Avslutningsvis kan sägas att innan man inför en automatiserad testning på ett företag bör man ha en fungerande manuell testmetodik. Det gäller att från den manuella testmetodiken skilja ut tester som tar lång tid att utföra manuellt och de som skall repeteras många gånger, dessa kan det vara meningsfullt att automatisera.
10 Referenser Automated Testing Specialists, Inc.(2002) http://www.sqa-test.com (2002-05-05) Keith Zambelich - Totally Data-Driven Automated Testing a White paper. http://www.sqa-test.com/w_paper1.html (2002-05-08) Bret Pettichord (Version of 28 June 2001) - Success with Test Automation http://www.io.com/~wazmo/succpap.htm (2002-05-20) Tilo Linz, Matthias Daigl (2002) - How to Automate Testing of Graphical User Interfaces http://www.imbus.de/forschung/pie24306/gui/aquis-full_paper-1.3.html (2002-05-23) KerryCQA, CSTE ( a few years ago ) - Automated Software Testing - A Perspective http://www.testingstuff.com/autotest.html (2002-05-10) Quality Checked Software, Ltd (2002) - Software Testing White Papers and Newsletters http://www.qcsltd.com/papers/pubs.htm (2002-05-29)