Automatiseret GUI-test

1. Automatiseret GUI-test Lars Kjølholm Testnet2 - 26. maj 2009

2. Lidt om mig selv… • Lars Kjølholm • Arbejdet med IT-udvikling i 14 år • Heraf med test som primært område i 5 år • Speciale : Testautomatisering • Derudover… • Forumvært på www.softwaretestforum.dk • Boardmember i HP Test Brugergruppe

3. Agenda • GUI-test – hvad er spændende ved GUI-test ? • Hvilke værktøjer benytter BRFkredit ? • DEMO af QuickTest Professional • GUI-test af miljøer • Automatiske test i projekternes udviklingsforløb • Automatiske test ved igangsætning / release • Automatiske test til produktionsovervågning

4. GUI-test

5. Hvad er spændende ved GUI-test ? • Client/Server-systemer • Funktionalitet i Backend (modulerne, services) • Funktionalitet i Frontend (grafiske brugergrænseflade) • Hændelsesorienteret • Sekvens vi kan gør tinge i (hierarkiske struktur) • Der er to områder, vi skal have i fokus når vi tester : • Vi skal teste alle hændelserne • Vi skal teste sekvensen vi kan gøre tinge i

6. Hændelse • Grænsefladen kan have forskellig udseende alt efter hvilken værdi brugeren vælger (hændelse) i eks. en dropdown-boks. • Felter vises/vises ikke • Forskellige valgmuligheder • Eks. ”Bestil LåneBevis”-dialogen

7. Sekvens • Måden hvor på brugeren kommer gennem applikationen. • Hvis nu jeg vælger… hvor kommer jeg så hen ? • Hvad nu hvis jeg IKKE vælger noget ? • Eks. ”Omlæg lån”

8. Måske det var en god idé… • GUI-test giver rigtig rigtig mange testcases • Testene skal være reproducerbare • Testene skal kunne afvikles om og om igen • Trivielt arbejde… • … så her er et godt område at automatisere !!!

9. Værktøjer

10. Hvilke værktøjer benytter BRFkredit • HP Quality Center • Registrering af automatiske testcases, set og status • HP QuickTest Professional • Til afvikling af automatiske GUI-tests • HP Service Test • Til afvikling af service tests • Sherlock (eget udviklet – udtrækker data fra QC) • Til at give overblik

11. DEMO – QuickTest Professional

12. GUI-test i BRFkredit • GUI-testcasene er bygget op som dialogflows, der dækker et givent område af applikationen. • Testcasene er bygget med to formål : • GUI-test (Flow Grafer) • Funktionstest

13. BRFkredits udviklings- og produktionsmiljø og testfaserne • Hvor benytter BRFkredit så automatiske GUI-test ? Produktionskontrol PROD Driftsaccepttest QA Systemtest/ Brugertest DEMO Komponenttest/ Integrationstest TEST

14. Automatiseret GUI-test ved klargøring af TEST- og DEMO-miljøerne • Regressionstest – INDEN ny/ændret kode flyttes til miljøet • Her afvikles automatiske testcases, som dækker produktionskoden. Alle SKAL afvikle ok. • Dette for at sikre, at miljøet som udgangspunkt fungerer. • Regressionstest – EFTER ny/ændret kode er flyttet til miljøet • Her afvikles automatiske testcases, som dækker produktionskoden igen – vel vidende at testcases på de rettede områder vil fejle.

15. Automatiseret test vedklargøring af TEST- og DEMO-miljøerne • Generering af testdata • De trivielle opgaver som vi laver gang på gang, f.eks. oprettelse af tilbud, ejendomme, interessenter o.s.v. • Testdata til undervisning (eks. EDC-uddannelsessystemet) • Sparer tid !!! • Optage én gang – afvikle mange gange !!! • Testerne leverer regneark med data

16. Automatiske GUI-test i projekternes udviklingsforløb • GUI-regressionstest efter natlig build og deployment

17. DEMO: Sherlock - Overblikket

18. DEMO: Sherlock – Hvad fejler ?

19. DEMO: Quality Center – Oprettelse af defect

20. DEMO: Quality Center – Oprettelse af defect

21. DEMO: Sherlock – Gentest fejlede testcases

22. DEMO: Sherlock – Gentest fejlede testcases

23. DEMO: Sherlock – Alt ok !

24. Automatiske test i projekternes udviklingsforløb … hvornår havde vi fejlen ? • Da al information vedr. status på afvikling af de automatiske test gemmes i Quality Center, har vi mulighed for at lave statistik på • hvor mange fejl vi har i miljøet • hvornår fejlene er introduceret i miljøet • hvor længe fejlene var i miljøet

25. Driftsaccepttesten • Regressionstest – INDEN ny/ændret kode flyttes til miljøet • Her afvikles automatiske testcases, som dækker produktionskoden. Alle SKAL afvikle ok. • Dette for at sikre, at miljøet som udgangspunkt fungerer. • Regressionstest – EFTER ny/ændret kode er flyttet til miljøet • Her afvikles automatiske testcases, som dækker den nye kode, der er på vej i produktion. Alle SKAL afvikle ok. • Dette for at sikre, at den tekniske opsætning sammen med den ændret/nye kode fungerer. Kan vi opsætte den ændrede/nye tekniske platform, og kan vi flytte koden…

26. Igangsætning/Produktionskontrol • Når driften melder klar – ny release er installeret, går autotesteren i gang… • Afvikling af automatiske test for at få et hurtigt overblik over produktionsmiljøets ”tilstand”. • Spejlede servere (kontrol af begge servere samtidig) • Sparer vi tid og ressourcer • Efterfulgt af manuel brugerkontrol • Manuelle brugerkontrol med fokus på rettet/ny funktionalitet

27. ”Overvågning” • Daglig afvikling af automatiske test mod produktionssystemerne RKI CPR-registret …

28. ”Overvågning”- eksempel på status-mail til IT-Service • Fokusere på de systemer, der fejler

29. ”Overvågning”- Fungerer GUI’en i produktionsmiljøet ? • Fungerer vores dropdown-menuer og listbokses med eks. de nyeste rentesatser og obligations-kurser ?

30. Opsamling… • Hvad er spændende ved GUI-test ? • DEMO af QuickTest Professional • GUI-/Funktionstest • Hvor benytter BRFkredit GUI-test ? • Projekternes udviklingsløb • Driftsacceptenstest • Igangsætning • ”Overvågning”

31. Besøg www.brf.dk