hovedopgave - aarhus universitet · automatiseret test af gui i webapplikationer preben christensen...

HovedopgaveDiplom i Informationsteknologi

linien i Softwarekonstruktion

Automatiseret Test af GUI i webapplikationer

afPreben Christensen og Niels Jordan Andersen

15. juni 2010

Preben Christensen,studerende

Niels Jordan Andersen,studerende

Jeppe Brønsted, vejleder


Side 1 af 66


Preben Christensen([email protected])Niels Jordan Andersen

([email protected])

15. juni, 2010

Abstract

Afdækning af kriterier for valg af værktøjer til automatiseringaf GUItest på webapplikationer, og evaluering af disse.

Dette med udgangspunkt i eksisterende litteraturog ved test af eksempler på programmer.


Side 2 af 66

Indholdsfortegnelse

Indholdsfortegnelse....................................................................... 31 Motivation................................................................................... 42 Indledning .................................................................................. 6

2.1 Problembeskrivelse ................................................................... 62.2 Hypotese ................................................................................. 62.3 Begrænsning ............................................................................ 6

3 Metode........................................................................................ 83.1 Begreber ................................................................................. 83.2 Terminologi .............................................................................. 8

4 Analyse og resultat ................................................................... 104.1 Litteratur ............................................................................... 104.2 Kriterier................................................................................. 13

4.2.1 Begrundelse for udeladelse af krav ...................................... 174.3 Programmer........................................................................... 20

4.3.1 Sahi................................................................................. 204.3.2 Canoo webtest .................................................................. 204.3.3 iMacros for Firefox ............................................................. 214.3.4 SeleniumHQ...................................................................... 214.3.5 Watir ............................................................................... 21

4.4 Udvælgelse af test-webapplikationer.......................................... 224.4.1 Egenudviklet lommeregnerapplikation .................................. 22

4.5 Beskrivelse testcase til vurdering af værktøjer op mod kriterier ..... 244.5.1 Test af maps.google.com.................................................... 244.5.2 Test af www.w3.org ........................................................... 244.5.3 Test af translate.google.com ............................................... 254.5.4 Test af lommeregner.......................................................... 254.5.5 Testcase for test af ændringer............................................. 254.5.6 Testcase for test af HTML5.................................................. 254.5.7 Testcase for test af pålidelighed .......................................... 26

4.6 Vurdering af fundne værktøjer op mod kriterier........................... 274.6.1 Verifikation af de enkelte værktøjer ..................................... 27

4.6.1.1 Sahi ........................................................................... 284.6.1.2 Canoo webtest............................................................. 354.6.1.3 iMacro ........................................................................ 414.6.1.4 SeleniumHQ ................................................................ 454.6.1.5 Watir.......................................................................... 52

4.6.2 Opsummering af fundne egenskaber .................................... 574.7 Det ideelle værktøj.................................................................. 60

5 Relateret arbejde ...................................................................... 615.1 [CSTTE]................................................................................. 615.2 [GUILLEMOT] ......................................................................... 61

6 Konklusion ................................................................................ 636.1 Fremtidigt arbejde .................................................................. 65

7 Referencer ................................................................................ 66


Side 3 af 66

1 Motivation

I takt med udbredelsen af internettet er vi blevet mere og mere afhængige afwebapplikationer. Vi bruger dem i dag til mange formål. Vi indrapporterer forbrug f.eks.af vand, varme og strøm. Vi indberetter vores skat og styrer vores banktransaktionergennem webapplikationer. Vores samfund er meget afhængig af, at webapplikationervirker og virker korrekt. Det er af stor samfundsmæssig betydning, at man kan havetiltro til disse applikationer. For at sikre at webapplikationer virker korrekt, er detnødvendigt at teste dem. Vi ønsker i denne opgave at beskrive kriterier for testværktøjertil test af webapplikationers brugergrænseflade (GUI).

I det følgende afsnit vil vi beskrive test processen nærmere for at kunne placere ogafgrænse vores arbejde med automatiseret GUI test.

For at teste mest effektivt bør man benytte en strategi for testen. Der findes mangestrategier for test. De kan inddeles i følgende hovedgrupper:

• "No Testing",• "Explorative testing" eller• "Systematic testing".[FRS] p. 402

I forhold til disse vil vi ikke beskæftige os med "No Testing" og "Explorative testing". Vivil derimod se på om der kan opstilles kriterier til testværktøjer, der kan anvendes til"Systematic testing". Systematic Testing defineres således af [FRS] p402: "Systematictesting is a planned and systematic process with the explicit goal of finding defects insome well-defined part of the system.".

For at teste systematisk må der anvendes teknikker der sikrer at testen bliverdækkende. Teknikkerne kan deles op i to grupper:

1. Black-box testing og2. White-box testing

I "Black-box testing" bliver enheden under test behandlet som en sort kasse, hvorindholdet er ukendt og testscenarier skrives ud fra specifikationen. Black-box testing ersåledes i [FRS] p 401 defineret:

"The unit under test (UUT) is treated as a black box. The only knowledgewe have to guide our testing effort is the specification of the UUT anda general knowledge of common programming techniques, algorithmicconstructs, and common mistakes made by programmers."

Dette er i modsætning til white-box testing, hvor den fulde implementation af enhedenunder test er kendt. Implementationen analyseres for at give dækkende testscenarier.

I denne opgave fokuseres på den sammenhængende webapplikation set fra etbrugerperspektiv. Vi vil derfor se på kriterier for værktøjer, som gør det muligt at testeved hjælp af black-box teknikken.

Man kan dele test ind i: 1) Integrationstest der forholder sig til samspillet mellem deenkelte moduler af applikationen, 2) review metoden hvor kildekoden inspiceres ogendelig 3) System test der tester systemet som et hele med forskellige områder. Vi vilisær se på elementet af system test: Funktionel testning.


Side 4 af 66

Web-applikationer kan udvikles på mange forskellige måder. Der findes mangeteknologier der bruges til at bygge web-applikationer. Man vil ofte forudsætte at denvalgte teknologi er gennemtestet. Alligevel vil der være et behov for at teste de deleman selv tilføjer samt integrationen til teknologien.

Nogle tekniske setups kan være krævende at teste. Dette gælder, hvis man f.eks. har enapplikation, der består af forskellige moduler skrevet i et mix af kendte teknologiersåsom JSF, JSP, Perl, ASP m.v. I de tilfælde kan det være svært gennem test af deenkelte moduler, at afgøre om det endelige resultat er som ønsket, da der ifølgeantikompositions aksiomet1 ikke er garanti for, at den færdige webapplikation ergennemtestet, blot fordi det enkelte modul er gennemtestet. Således er der behov fortestværktøjer til test af den samlede applikation - og dermed kriterier for sådannetestværktøjer.

Det er et stort og slavisk arbejde at teste GUI funktionalitet. Specielt at teste forregression ved videreudvikling kan være krævende, både tidsmæssigt ogressourcemæssigt. Automatiseret test af GUI funktionalitet kan gøres struktureret, derfindes en række frameworks og programmer til dette, men det er noget uklart, hvilkemuligheder de giver. Der er således efter vores opfattelse behov for et struktureretarbejde/oversigt der kan anvendes til at vælge testværktøj til en konkret opgave. Det ernetop dette, vi vil behandle i denne opgave og opnå en større forståelse for, hvilkettestværktøj der er bedst egnet i forskellige situationer - og hvordan dette afgøres.

1. [Burnstein] p. 122


Side 5 af 66

2 Indledning

I dette afsnit vil vi først uddybe vores problem, hvorefter vi vil opstille de udsagn vi vilundersøge gyldigheden af i vores hypotese. Afsnittet omfatter desuden en beskrivelse afde begrænsninger, som vi har foretaget for at holde fokus på det centrale i forhold tilhypotesen.

2.1 Problembeskrivelse

Vi ønsker helt konkret at løse det problem som man ofte står i, hvis man skal vælge etværktøj til automatisk test. For at kunne vælge det bedste testværktøj er der brug for atfå svar på en række spørgsmål såsom:

• Eksisterer der en best-practice for valg af automatiserede testværktøjer til GUIdelen af webapplikationer?

• Hvilke kriterier er væsentlige for et sådant valg?• Kan der opstilles kriterier for valg af værktøjer i en given situation?• Findes der værktøjer der opfylder disse kriterier?

Problemerne består således i at finde beskrivelser i litteraturen af kriterier somværktøjer til automatiserede GUI test af webapplikationer bør opfylde, identificere hvilkeaf disse der er relevante i vores kontekst, samt vurdere om nogle valgte konkreteværktøjer kan leve op til sådanne kriterier. Denne problemstilling har vi koncentreret ivores hypotese som vi agter enten at verificere eller tilbagevise.

Målet er at man med denne rapport i hånden er bedre hjulpen når man står og harbehov for at opsætte automatiseret test.

2.2 Hypotese

Det er på baggrund af vores motivation vores hypotese at:

1. Der kan opstilles meningsfulde kriterier for valg af programmer til automatiseretGUI test af webapplikation2. Der findes gratis programmer, der kan vurderes ud fra disse kriterier.3. Der findes programmer der kan leve op til de opstillede kriterier.

2.3 Begrænsning

Vores interesse og fokus går på den funktionelle del af brugergrænsefladen iwebapplikationerne - dvs. formfelter, sideflows m.v. Vi agter ikke at beskæftige os medlayout, browserspecifikke problemstillinger eller lignende.

Vi har ligeledes ikke intentioner om at modificere værktøjerne eller lave udvidelser. Viønsker ikke at forstå eller sammenligne opbygningen af værktøjerne. Integreredeelementer såsom flash eller lign. forventer vi ikke at tage højde for.


Side 6 af 66

Vi vil finde eksisterende webapplikationer at teste, samt hvor det er nødvendigt lave enegenudviklet webapplikation til specifikke test.

I opgaven vil vi kun beskæftige os med værktøjer der er gratis.

Vi ønsker ikke at undersøge om værktøjet kan planlægge eller styre testprocessen. Vi vilheller ikke se på om værktøjet sikre at de beskrevne testscenarier er dækkende. Styringaf fejlrapportering og gentest vil vi heller ikke se på. Det der har vores interesse erhvordan værktøjet er at arbejde med i forhold til at lave testcases ud fra de beskrevnetestscenarier samt hvor godt det er til at udføre de testcases.


Side 7 af 66

3 Metode

Vi har valgt at dele vores tilgang til hypotesen i flere underdele.

1. Vi har først udvalgt kriterier som er relevante. Dette er gjort på baggrund aflitteraturen på området, men også ud fra en subjektiv opfattelse. Vi harendvidere kvantificeret de enkelte kriterier ud fra et selvintroduceretpointsystem.

2. Dernæst har vi har udvalgt enkelte testværktøjer som er interessante at teste,fordi disse programmer er repræsentative i deres tilgang og fordi de er udbredtei brug. Endvidere har vi forsøgt at vælge programmer af forskellige typer.

3. Dernæst har vi udarbejdet testscenarier der kan anvendes til evaluering af deopstillede kriterier. Vi har dels baseret disse scenarier på allerede eksisterendewebapplikationer, dels lavet en ny til formålet.

4. Endelig har vi gennemført en test af de enkelte værktøjer og evalueret disse.

Med baggrund i hele dette arbejde har det således været muligt at tage stilling til voreshypotese. Nedenfor vil vi indledningsvis introducere nogle begreber og den anvendteterminologi.

3.1 Begreber

Den udførende del af testprocessen, hvor et system testes ud fra beskrevnetestscenarier, kan udføres på to måder:

• Manuelt eller• Automatisk

Manuel test er hvor QA-personale sidder og udfører testscenarierne.Automatisk test er, hvor testscenarierne udføres af et computerprogram.En meget brugt form for automatiseret test er unit test. [BECK] beskriver hvordan det erudviklerne der skriver software som tester dele af et system. Unit test bruges underudviklingen af et system.

Automatiseret test kan også bruges af QA-personale og når et system, eller dele af etsystem er klar til aflevering til kunden. Derefter kan de beskrevne test bruges til løbenderegressions test.

3.2 Terminologi

Nedenstående tabel forklarer de termer som enten er specielle for denne opgave(selvintroducerede), eller som ikke er almindelig kendt (såsom enkelttermer fraspecifikke kilder)

Term Forklaring

Teststep En klart defineret handling med et klartdefineret resultat.

Testcase En samling af teststep med defineretrækkefølge.

Data driven testing En term for at testdata gemmes et centraltsted - adskilt fra selve testbeskrivelsen.


Side 8 af 66

Ant

Generel komponent som giver mulighed forat afvikle flere aktiviteter sekventielt. Ofteanvendt i forbindelse bygning afapplikationer.

Testværktøj Program der kan anvendes til at hjælpemed eksekvering af en test i praksis

Testkriterium Et kriterium hvorefter et testværktøj kanevalueres

QA-personale Personer der er beskæftiget med qualityassurance (og dermed test)

EntryinvesteringRessourcer der skal anvendes for atkomme i gang med en given opgave /værktøj


Side 9 af 66

4 Analyse og resultat

Dette afsnit udgør vores egentlige arbejde med hypotesen og forsøger at nå frem til etresultat på hvert af de opstillede elementer i vores arbejdstese.For at gøre dette, arbejder vi først med hvilken litteratur der beskriver mulige kriterier tiltestværktøjer til automatiseret test i afsnittet "Litteratur". Herefter kombinerer vi dennelitteratur med vores egen erfaring på området for at opstille en række kriterier som vimener, det vil være hensigtsmæssigt at et givent testværktøj opfylder.For at afprøve disse kriterier i praksis - og for at kunne afgøre om testværktøjerne leverop til vores kriterier, beskriver vi efterfølgende i afsnittet "Programmer" det sæt afkonkrete testværktøjer, vi vil arbejde videre med.For at kunne udføre en sådan evaluering i praksis beskæftiger de næste to afsnit"Udvælgelse af test-webapplikationer" og "Beskrivelse af testcases til vurdering afværktøjer op mod kriterier" sig med konkret at beskrive forudsætningerne til det megetessentielle afsnit "Vurdering af de fundne værktøjer op mod kriterier". I dette afsnitforsøger vi at måle de enkelte fundne værktøjer op mod vores beskrevne kriterier. Dettearbejde vil således kunne hjælpe os med at afdække vores arbejdsteori - at der kanopstilles kriterier til testværktøjer og disse efterfølgende kan evalueres op imod dem.

4.1 Litteratur

I vores analyse har vi taget udgangspunkt i litteratur der beskæftiger sig med kriterier tilevaluering af værktøjer til automatiseret test. Vi har fundet følgende litteratur [LJW96],[KAL] og [CSTTE].

[LJW96]Ifølge [LJW96] nævner [WOL92, WIM92]2 at tre krav er nødvendige for at kunne testeGUI automatisk.

Disse er:"1) record and playback of physical events in the GUI,2) screen image capture and comparison, and3) shell scripts to control and execute test runs of the GUI."3

Disse krav tyder på en meget operationel tilgang til opgaven. Der lægges megen vægtpå selve det praktiske i udførelsen - og ikke på f.eks. stabilitet eller understøttelse afspecifikke teknologier. Der tages ikke hensyn til specielle GUI komponenter - mensnarere til screen comparison på et højere niveau.

[KAL][KAL] taler flere gange for en separation af testscript og testdata, for at gøre det lettereat rette og derved højne effektiviteten af test.

[KAL] lister også en række kriterier:• Less intrusive• Platform and language independent• Flexibility for upgrading• intuitive test automation.

2. Indirekte reference er anvendt da det ikke har været muligt at skaffe [WOL92,WIM92]3. [LJW96] p. 350


Side 10 af 66

[KAL] lægger vægt på at værktøjet ikke har for stor indvirkning på sine omgivelser ogdermed det der skal testes. [KAL]'s fokus er således markant anderledes end [LJW96],idet fokus her ikke er på det operationelle i testen men på forholdet til det der skaltestes.

[CSTTE]Artiklen [CSTTE] forsøger i stor udstrækning at foretage de samme overvejelser som vigør. Dog lægges der i artiklen en del mere vægt på mere procesorienterede/forretningsorienterede kvaliteter ved værktøjerne; Den lister en række kvalitetervedrørende licens, prissætning og support. Ethvert stykke software vil have en elleranden grad af disse kvaliteter, men dette er ikke ligger indenfor vores arbejdsområde ogderfor har vi valgt ikke at behandle dem.Derudover har [CSTTE] analyseret test processen ved hjælp af TORE metoden.Resultatet af analysen er, at test processen indeholder nedenstående 8 opgaver:

A: Test planning and monitoring.B: Designing Test Cases.C: Constructing Test Cases.D: Executing Test Cases.E: Capturing and comparing test results.F: Reporting test results.G: Tracking Software problem reports/defects.H: Managing the test ware.

I disse 8 opgaver har [CSTTE] identificeret 44 aktiviteter, som de mener, kanunderstøttes eller automatiseres af et værktøj til automatiseret test og bruges tilfunktionelle kriterier. Aktiviteterne er som følger:

A: Test planning and monitoring.1. customization of the organizational test process2. particular programming paradigms and/or languages, operating systems,

browser, network configuration3. application specific characteristics, which require specific testing techniques4. testing special application domain (e.g. avionics, automotive, etc.)5. planning of the test process (scheduling, project tracking, risk management)6. monitoring test activities7. integration with other tools.

B: Designing Test Cases.1. designing test cases for the required test level (unit, integration, system)2. selecting the test techniques3. defining test conditions derived from the defined test techniques4. defining templates for structuring the information specifying test cases5. generation of logical test cases from semi-formal models?6. generation of logical test cases from formal specifications (e.g. Z)7. generation/derivation of test data layout8. optimizing the test case set9. designing test cases to test quality criteria of the application

10. restricting the test case set (e.g. ranking by prioritisation of the test cases, risksassigned to test cases) in case of deadline constraints.

C: Constructing Test Cases.1. editing test scripts2. developing of test code conforming with accepted software engineering practices3. capturing of executable test cases4. generation of concrete test cases from (semi-)formal models5. generation of (in)valid test data6. generation of stubs, test drivers, mock objects,


Side 11 af 66

7. simulating missing faulty system components.

D: Executing Test Cases.1. setting-up and clearing-down of the test environment/pre condition and

respectively the post conditions for a set of test cases2. roll-back to initial in case of unexpected errors3. execution of captured, captured & edited or manually implemented test cases for

functional testing.4. execution of captured test cases for testing quality criteria5. stopping and continuation of the execution of a suspended test case.

E: Capturing and comparing test results.1. logging information on executed test cases2. comparison facilities between specified and actual outcomes

F: Reporting test results.1. aggregation of logged test results2. customizable, role specific amount of information.

G: Tracking Software problem reports/defects.1. specifying problem reports/defects by using predefined templates2. generating entries for recorded defects3. prioritizing defects4. tracking change requests/defects and their current status5. generating statistical information6. for regression testing.

H: Managing the test ware.1. management of the test ware2. traceability between the elements of the test ware3. by tracing modifications on a test object and communicating changes4. the maintenance of the test data, of the test cases5. for automated tests to be (re)used for regression testing/in other projects6. snapshot facilities (by freeze a special state of the test ware).


Side 12 af 66

4.2 Kriterier

På baggrund af ovenstående og vores egne erfaringer har vi udarbejdet de kriterier somvi vil arbejde videre med for at kunne teste vores hypotese.

1. Let at lære2. Det skal være let at opsætte test3. Understøtte "optage"4. Understøtte et scriptlignende sprog5. Let at revidere/modificere allerede beskrevne test6. Fleksibilitet7. Pålidelighed8. Enkelt at se om testen er fejlet (inkl. rapport over udførte test)9. Schedulering

Det skal bemærkes at dette er den overordnede beskrivelse af vore kriterier. Hvertkriterium kan indeholde en række delelementer der gør at kriteriet kan være delvistopfyldt m.v. f.eks. er et vigtigt emne såsom adskillelse af test og testdata under punktet"Let at revidere/modificere allerede beskrevne test" samt at autogenerering af testcasesbehandles under "Understøtte 'optage'".

Vi har valgt ikke at vægte de enkelte kriterier op imod hinanden, dels fordi en sådanvægtning ikke indgår i vores hypotese, dels fordi en sådan vægtning vil afhængebrugerens behov og konkrete omstændigheder.

Vi havde først overvejet blot at angive for hvert kriterium om det enkelte værktøjoverholder dette. Vi er dog nået frem til at der er så mange væsentlige delelementer (idet følgende benævnt sub-kriterier) at denne udtryksform ikke er kraftfuld nok. Vi harderfor valgt at introducere et pointsystem og givet disse subkriterier point.Der må nødvendigvis komme en grad af subjektiv vurdering ind i dette, f. eks hvis viopdeler et subkriterium i endnu flere kriterier vil det øge den samlede pointsum forsubkriterierne under dette kriterie og dermed nedtone vægtningen af de øvrigesubkriterier under kriteriet (scenariet er illustreret i figuren nedenfor hvor man ser atsubkriterie 2 i scenarie 1 har 33% af pointene, men i scenarie 2 kun 25% af pointene, dasubkriterie 1 er opdelt i to dele). Vi har generelt valgt at tilskrive de enkelte subkriteriersamme vægt, vi har dog lavet enkelte undtagelser, som vi konkret vil argumentere for.

Figur der viser scenarie vedr. vægtning af point i subkriterier


Side 13 af 66

Da et kriterium kan opfyldes delvist, har vi blandt andet valgt at anvenderadardiagrammer til at sammenligne i hvor høj grad de enkelte testværktøjer lever op tilde enkelte kriterier. Man skal i denne sammenhæng være opmærksom på at vi somtidligere anført ikke vægter de enkelte kriterier mod hinanden. Vi har derfor forholdsvisomregnet pointene så de enkelte kriterier slår lige kraftigt ud på graferne – uden atdette altså skal tillægges nogen vægtende betydning.

I det følgende argumenterer vi for hvorfor de valgte kriterier er relevante og i afsnit4.2.1 argumenteres for hvorfor de er tilstrækkelige.

1. Let at læreVi har valgt at fokusere på hvor nemt det er at komme i gang med værktøjet. Dettekriterium er valgt, da en for høj entry-level-cost helt kan betyde at værktøjet ikke vilblive anvendt. Hvis værktøjet bliver en hindring i arbejdet, vil det ikke blive brugt.Derfor er det vigtigt at værktøjet ikke er en hindring, men en hjælp. Vi ønsker af etgivent værktøj at det kræver et minimum af indlæring. Derved bliver det nemmereintroduceret til nye teammedlemmer, samt at udbrede det i en organisation. Naturligvisvil visse processer have forskellige indlæringskurver, men en stejl indlæringskurve børundgås. Dette kriterium relaterer sig til [KAL]'s krav "Intuitive test automation", hvor dernævnes at brug af et værktøj til automatisk test bør være naturligt.4

Dette kriterium har vi valgt at opdele i tre subkriterier: En subjektiv vurdering, enkontekstbaseret hjælp og endelig mulighed for hjælp på nettet. Vi har medtaget densubjektive vurdering, da det altid er en subjektiv vurdering om et værktøj er let at lære.En hjælpefunktion kan yderligere understøtte dette.Den subjektive vurdering har vi valgt at give 0 til 3 point, idet vi ser det som en megetvæsentlig del af "Let at lære" kriteriet, at brugeren overhovedet kan anvende værktøjet,og vi har således valgt at fravige reglen om at vægte subkriterierne ens.Der gives, som nævnt, også point baseret på en gennemgang af den tilgængeligemulighed for hjælp. Her gives igen undtagelsesvist 2 point for indbygget hjælp, idet vifinder at kontekstbaseret hjælp er af vital betydning for anvendelsen.

Mulige points:Subjektiv vurdering af hvor let værktøjet er at lære: 0-3 pointIndbygget hjælp giver 2 pointHjælp på nettet giver 1 pointIngen hjælp = 0 point

2. Det skal være let at opsætte testUdover at værktøjet skal være let at komme i gang med, har vi også valgt at fokuserepå hvor let det er at udarbejde testcases i det. Dette har en sammenhængmed [CSTTE]'s krav "Constructing Test Cases", samt relaterer sig til [KAL]'s krav"Intuitive test automation", hvor der anføres at lethed ved brug tillader start afautomatisk test med det samme.5

Hvis det tager betydeligt længere tid at lave en testcase vha. værktøjet end det tager atlave samme test i hånden, kan det bedre betale sig at lave den manuelt.Automatiserede test har den fordel at de kan gentages et uendeligt antal gange, mender vil være en grænse for hvor lang tid der skal bruges på at opbygge disse test, før enorganisation vil give sig i kast med arbejdet.Vi vil til dels evaluere ved at tælle hvor mange forskellige skridt man skal igennem for atopsætte en standard testcase, men også ud fra en subjektiv vurdering af den krævedeindsats.

4. [KAL] p. 125. [KAL] p. 12


Side 14 af 66

Mulige point:Hvis det tager relativ kort tid / få steps at opsætte en test gives 1 pointHvis det tager relativ lang tid / mange steps at opsætte en test gives 0 point

3. Understøtte "optage"Det vil være en hel klar fordel, hvis værktøjet har mulighed for at optage testcases,hvilket [LJW96] underbygger. Selvom [KAL] nævner det som mindre effektivt at optage,så giver det en god start på at bruge værktøjet, samt et udgangspunkt for scripts mansenere kan rette i.Vi ønsker også at fokusere på, om der findes støtte-funktionalitet til at lave testcases.Det kan f.eks. være at værktøjet selv finder HTML-elementerne som brugergrænsefladener opbygget af, så der kun skal udfyldes testdata.Evalueringen af dette kriterium er ganske simpel, det er blot en afklaring af om oghvorledes det kan optage testcases.

I dette kriterium ønsker vi ligeledes at undersøge hvordan værktøjerne gemmer det"optagne" testsæt, om det registreres som:

1. en grafisk optagelse (der klikkes på koordinat xx,yy)2. at man har aktiveret knappen med navn / id zzz (kontekst)

Endvidere ses på om det er muligt at autogenerere testcases i værktøjet.

Mulige point:Der er indbygget optager der kan foretage grafisk optagning, dette giver 1 pointDer er indbygget optager der kan foretage kontekst optagning, dette giver 1 pointAutogenerering af testcases giver 1 point.Ingen optagefunktion eller autogenerering giver 0 point.

4. Understøtte et scriptlignende sprogDet er kun muligt at rette i scripts, hvis de er forståelige for testerne. Derfor ønsker vi attestcasene er udtrykt på en måde, så det er muligt at fortolke for testerne, hvilket det ermed et scriptlignende sprog.Understøttelse af et scriptlignende sprog vil ligeledes gøre det nemmere at kontrollerepræcist hvad optage-funktionen i værktøjet har foretaget; F.eks. kan det ses om optagefunktionen har optaget, at man har trykket på koordinat x,y - eller at man har trykket påen knap navngivet "xyz".Det at testcasene gemmes i et scriptlignende sprog vil ligeledes gøre genbrug afdelelementer af enkelttest nemmere. Således at man vil kunne genbruge denprogrammatiske beskrivelse af en del af en testcase i en anden testcase. Således at manikke behøver at optage og/eller beskrive den igen. Derfor vil understøttelse af etscriptlignende sprog også mere eller mindre automatisk medføre at delelementer vilkunne genanvendes via duplikeret testkode.

Vi vil vurdere om der foreligger et scriptlignende sprog for værktøjet, og om hvad dettescriptsprog understøtter:

• Indtastning af data (fra fil, random, fast data etc.)• Aktivering af kontroller (knapper, links, mouse over etc.)• Tjek resultat (Tjekkes om resultatside indeholder noget bestemt, tjekkes om

resultatside matcher prædefineret billede, etc.)

Mulige point:Indtastning af data giver 1 pointAktivering af kontroller giver 1 point


Side 15 af 66

Tjek resultat giver 1 pointIngen scriptunderstøttelse giver 0 point

5. Let at revidere/modificere allerede beskrevne testDette kriterium hænger tæt sammen med [CSTTE]'s opgave C : "Constructing testcase", hvor der er et krav om at et værktøj bør give mulighed for at ændre i test scripts.

Ved regression-test, tester man om funktionalitet er uændret. Det er dog muligt at deleaf brugergrænsefladen har ændret sig, mens andre dele er uændrede. Det man ønskerat teste er om de uændrede dele ikke har ændret sig uønsket. Det er en fordel, hvis tester så løs koblet til brugergrænsefladen som muligt, samt at der er en adskillelse af testscript og testdata. En sådan afkobling vil nemlig medføre at det vil være muligt fortsat atafvikle den allerede beskrevne testcase hvis det bagvedliggende testsæt ændres. Dettekan skyldes at baggrundssystemerne opdateres med nyere testdata fra tid til anden afandre årsager eller lign.

Selv små ændringer kan have stor betydning, hvis man ikke let kan tage højde for det isine test.Hvis store dele af testscriptet skal fjernes eller ændres på grund af små ændringer ibrugergrænsefladen, vil det igen ikke kunne betale sig at bruge værktøjet.Ligesom kriterium 2 "Det skal være let at opsætte test", vil en organisation ikke tageværktøjet til sig, hvis der skal bruges uforholdsvis megen tid på at vedligeholde testene.Dette kriterium har vi tænkt os at teste på en egen udviklet webapplikation, som vi vilmodificere på passende vis, efter vi har lavet de første test scripts.

Mulige point:Der kan rettes i testscript = 1Der kan ikke rettes i testscript = 0

6. FleksibilitetDet er vigtigt at værktøjet er tilstrækkelig fleksibelt til at kunne foretage relevante testaf forskelligartede applikationer.Der er forskel på hvordan forskellige applikationer er opbygget og de bygger påforskellige teknologier. Derfor vil der være forskel på hvorledes de kan testes, hvilketstiller forskellige krav til test værktøjet.

Vi vil vurdere fleksibiliteten ved afprøvning af værktøjerne op mod forskelligeeksisterende hjemmesider, om de kan teste den funktionalitet disse sider udbyder etc.,det vil vi gøre ved hjælp af testcase 4.5.1 - 4.5.4.Derudover vurderes om værktøjet understøtter HTML5 (testcase 4.5.6) - og dermed erfremtidssikret.

Mulige point:Opfyldelse af testcase 4.5.1 giver 1 pointOpfyldelse af testcase 4.5.2 giver 1 pointOpfyldelse af testcase 4.5.3 giver 1 pointOpfyldelse af testcase 4.5.4 giver 1 pointOpfyldelse af testcase 4.5.6 giver 1 pointIngen opfyldelse af testcases nr. 4.5.1 til 4.5.4 eller 4.5.6 giver 0 point

7. Pålidelighed.Der kan spildes meget tid på et værktøj som ikke er stabilt. Hver gang en test fejler,skal der bruges tid på at finde ud af om der en reel fejl, eller fejlen stammer fraværktøjet. Ved at vælge et stabilt værktøj og derved minimere antallet af fejl fraværktøjet, bliver tiden brugt på at undersøge fejl også mindre.


Side 16 af 66

Det er essentielt at værktøjet er stabilt, så automatiserede test ikke bliver en udfordring- men noget det er naturligt at benytte.Dette kriterium vil vi vurdere ved at udføre et vist antal test med hvert værktøj - og seom der opstår problemer med dets stabilitet. I praksis foretages dette ved at udførevores definerede Testcase 4.5.7. Pålideligheden afgøres således af om denne testcasekan udføres.

Mulige point:Værktøjet er stabilt = 1Værktøjet er så ustabilt at der ikke kan laves test i det = 0

8. Enkelt at se om testen er fejlet (inkl. rapport over udførte test)Dette er et usabilitykriterium der er essentielt for anvendelse af værktøjerne. Hvis detikke er let at se, eller at få et overblik over, hvilke test der er fejlet, er det svært atreagere på de fejlede test. Derved bliver fejlretningsproceduren mere kompliceret oglængerevarende. Her vil vi vurdere om der kan genereres rapporter over fuldførte test.

Dette inkluderer• Rapport over fejlede test• Rapport over alle kørte test.

Mulige point:Rapport over fejlede test giver 1 pointRapport over alle kørte test giver 1 pointIngen af ovenstående rapporter giver 0 point.

9. ScheduleringDet sidste kriterium vi vil vurdere er om værktøjet understøtter schedulering af test.Dette kriterium har sit udspring i at det er bedst at teste så tidligt som muligt. I stil medunittest vil det være en fordel, hvis testene kan køres så ofte som muligt.Hvis testene kan opsættes, så de kører med et regelmæssigt interval, vil det ikke bliveglemt. Hvis værktøjet ikke i sig selv understøtter schedulering, vil det være en fordelhvis det subsidiært kan startes af en ekstern scheduler. Dette kriterium kan vurderes udfra specifikationerne i værktøjet - og kræver ikke opsætning af nogle test. Her har vivalgt at vurdere at en indbygget scheduler er af så stor værdi så den tildeles 2 point,altså en undtagelse fra reglen om 1 point pr. subkriterium.

Mulige point:Der er indbygget schedulering giver 2 pointDer er ikke indbygget schedulering, men kan aktiveres eksternt fra anden schedulergiver 1 pointDet er ikke muligt at schedulere giver 0 point

4.2.1 Begrundelse for udeladelse af krav

De første krav vi nævner i afsnit 4.1 litteratur er fra [LJW96] og er som følger:

1) record and playback of physical events in the GUI2) screen image capture and comparison3) shell scripts to control and execute test runs of the GUI.

Af det 1. krav "record and playback of physical events in the GUI", har vi valgt ikke atkigge på playback. Playback er påvirkning af brugergrænsefladen, f.eks. ved at trykke påen knap eller indtaste en tekst i et skrivefelt. Hvis værktøjet ikke kan påvirkebrugergrænsefladen, er det ikke muligt at ændre brugergrænsefladen og få et resultat


Side 17 af 66

frem. Det vil gøre værktøjet ubrugeligt. Derfor mener vi at det bliver implicit testet iselve brugen af værktøjet.

Af det 2. krav "screen image capture and comparison", har vi valgt ikke at arbejde med"screen image capture" som er aflæsning af brugergrænsefladen, f.eks. at aflæseteksten i et tekstfelt. Hvis værktøjet ikke kan aflæse brugergrænsefladen, giver detingen mulighed for at kontrollere om et resultat er korrekt. Derved er det ikke muligt atteste med værktøjet. I det vi bruger værktøjet til test, vil det blive implicit testet. Dettestemmer også overens med vores begrænsning i afsnit 2.3 hvor vi vælger at se bort fralayout, for at koncentrere os om formfelter.

Med hensyn til det 3. krav "shell scripts to control and execute test runs of the GUI",dækker det styring af brugergrænsefladen. At styre og påvirke brugergrænsefladen erdet samme, og derfor vil det som ovenfor beskrevet gøre værktøjet ubrugeligt, hvis detikke er muligt. Det er derfor igen testet implicit, idet at vi bruger værktøjet. "Executetest runs of the GUI" er afvikling af testen efter at den er optaget eller skrevet manuelt.Hvis værktøjet ikke kan afvikle en test, er værktøjet ikke i stand til at udføreautomatiserede test og derfor ikke indenfor rammerne af dette projekt.

Fra [KAL] har vi nævnt følgende krav:

• Less intrusive• Platform and language independent• Flexibility for upgrading• intuitive test automation.

Less intrusiveVi har valgt ikke at vurdere værktøjer for hvordan eller hvor meget, de påvirker dettestede. Det har vi gjort af den grund at vi, som beskrevet i afsnit 2.3 "Begrænsninger",ikke er interesserede i hvordan programmerne virker.

Platform and language independentVi har heller ikke set på [KAL]'s krav omkring platform- og sproguafhængighed. Det harvi valgt af den grund at, vi mener at de store forskelle mellem de enkelte platforme(browsere), kun giver sig i udtryk i layout af GUI. Med hensyn til sproguafhængighed harvi valgt ikke at komme ind på dette, da der ikke findes en standard for sprog tilbeskrivelse af test.

Flexibility for upgradingFlexibility for upgrading handler om hvor let det er at ændre de test der er lavet, når dettestede ændrer sig. Det behandler vi i kriterium 5 "Let at revidere/modificere alleredebeskrevne test"

Intuitive test automationIntuitive test automation, hvor værktøjet selv står for generering af testdata ogtestscript, dækker vi i kriterium 3 "Understøtter optage".

I [CSTTE] findes der 44 funktionelle kriterier. Af de kriterier, har vi undladt at beskæftigeos med de, der ikke direkte relaterer sig til selve udførelsen af testen, da vi som nævnt iafsnit 2.3 "Begrænsninger", har valgt at koncentrere os om selve udførelsen af testen.De kriterier der er udeladt falder under følgende opgaver:

A: Test planning and monitoring.B: Designing Test Cases.G: Tracking Software problem reports/defects.H: Managing the test ware.


Side 18 af 66

De tilbageværende opgaver er:C: Constructing Test Cases.D: Executing Test Cases.E: Capturing and comparing test results.F: Reporting test results.

I opgave C: Construction Test Cases har vi ikke set på kriterierne:2. "Developing of test code conforming with accepted software engineering practices"4. "Generation of concrete test cases from (semi-)formal models"5. "Generation of (in)valid test data"6. "Generation of stubs, test drivers, mock objects"7. "Simulating missing faulty system components".

Af kriterierne i opgave D: Executing test cases, har vi ikke kigget på kriterierne 1.Setting-up and clearing-down of the test environment/pre condition and respectively thepost conditions for a set of test cases, 2. Roll-back to initial in case of unexpected errorsog 5. Stopping and continuation of the execution of a suspended test case, da vi primærthar testet eksisterende eksempler på webapplikationer. Derfor har vi ikke haft mulighedfor andet end at teste ud fra den tilbudte brugergrænseflade.Kriterium 4. "Execution of captured test cases for testing quality criteria", handler om atudføre statisk analyse for at fastslå om source kode overholder style guides eller udføredynamisk analyser f. eks. af performance- eller loadtest.6 Da vi har valgt at koncentrereos om test af brugergrænsefladen og mest bruge eksisterende webapplikationer, har vivalgt ikke at behandle det kriterium.

Med hensyn til F: reporting test results har vi delvis behandlet dette i kriterium 8 "Enkeltat se om testen er fejlet". Vi har valgt at se på værktøjet som en enkeltstående del ogikke som [CSTTE], som en del af et større sammenhængende system. Derfor har vi ikkevurderet om værktøjernes rapporter kan aggregeres i sammenhæng med rapporter fraandre værktøjer eller om de kan tilpasses på anden vis, men kun om de rapporterværktøjerne selv genererer er tydelige og enkle.

6. [CSTTE] p. 6


Side 19 af 66

4.3 Programmer

For at vurdere hvilke værktøjer vi ville se nærmere på lavede vi en gennemgang atforskellige testværktøjer. Dette gjorde vi for at finde frem til nogle der:

1. Er rimelig repræsentative i deres tilgang2. Fortsat bliver aktivt vedligeholdt.

Punkt 1 er interessant for dette projekt, fordi vi vil kunne teste vore kriterier påforskellige typer af værktøjer. Punkt 2 er medtaget for at sikre at de udvalgte værktøjermed rimelighed vil kunne anvendes til at teste websider der er aktuelle pt.

For at kunne udvælge værktøjer med forskellig opbygning har vi valgt at inddeleværktøjerne i tre typer ud fra deres karakteristika:

1. Plugin til eksisterende browser2. Standalone applikation der betjener eksisterende browser3. Batchapplikation der selv simulerer en browser

Vi har ud fra denne betragtning valgt at gå videre med følgende 5 værktøjer:

4.3.1 Sahi

Emne Værdi

Udgiverhttp://sahi.co.in/w/

Type 2

Begrundelse for valg

Det er et standalone værktøj der fungerervha. proxyteknologi samt at der er supportfor adskillelse af testdata og testscript(Data driven testing).

4.3.2 Canoo webtest

Emne Værdi

Udgiver http://webtest.canoo.com

Type 3


Canoo webtest er et af et de værktøjer dervirker modent og avanceret. Derfor hargruppen valgt at inkludere det. Vi mener atdet er interessant at se hvilke mulighederet så modent produkt giver.


Side 20 af 66

4.3.3 iMacros for Firefox

Emne Værdi

Udgiver https://addons.mozilla.org/da/firefox/addon/3863

Type 1


Et macrobaseret system der fungerer somplugin til eksisterende browsereMulighed for record/playback script etc.Vi har valgt dette værktøj, med denbegrundelse at det virker meget simpelt. Viønsker at finde ud af om dette værktøjgiver nok muligheder til test. Vi synes deter interessant om det simple står mål medde mere omfattende produkter.

4.3.4 SeleniumHQ

Emne Værdi

Udgiver http://seleniumhq.org/

Type 1


Selenium er måske den mest brugte opensource løsning til automatiserede test.Derfor er det naturligt at vi kigger på detteværktøj.

4.3.5 Watir

Emne Værdi

Udgiver www.watir.com

Type 2


Ligesom Selenium og canoo er Watir etmeget omtalt værktøj. Igen er det naturligtat vi vælger at undersøge det af dennegrund.

Der findes forskellige varianter af Watir,hvor forskellige sprog kan bruges til atskrive test.Vi har valgt at betragte de forskelligevarianter under et og bruge den variant vimener er mest naturlig for os (Watir).


Side 21 af 66

http://www.iopus.com/imacros/

http://seleniumhq.org/

4.4 Udvælgelse af test-webapplikationer

For at kunne vurdere specielt tre af de udvalgte kriterier nemlig:

2: Det skal være let at opsætte test6. Fleksibilitet7: Pålidelighed

har der været et behov for at anvende værktøjerne på en række allerede eksisterendewebapplikationer samt en enkelt egenudviklet webapplikation. Disse webapplikationer erudvalgt så de repræsenterer forskellige typiske metoder og anvendelsesområder. Deudvalgte applikationer er:

Webapplikation Årsag til udvælgelse

maps.google.com Anvender massivt AJAX + meget grafiskorienteret

www.w3.org Opfylder med stor sandsynlighed w3c'sretningslinjer for valid kode

translate.google.com Enkel at teste op imod, tekst input/output.

Egenudviklet lommeregnerapplikationFuld kontrol over applikationen - ogapplikationen kan modificeres så konkretefejl introduceres

http://shwetankdixit.com/testpages/webforms2demo.htm Indeholder HTML5

4.4.1 Egenudviklet lommeregnerapplikation

Nedenstående meget simple lommeregnerapplikation har vi anvendt i forløbet medpassende modifikationer for, at have fuld kontrol over en testbar applikation. Der er taleom en jsp-side, der kan placeres i webapp folderen på en Tomcat hvorefter det kanafvikles. Som det fremgår, er det meget nemt at modificere koden i webapplikationen (tiltestcasene defineret i senere kapitler) så lommeregneren kan opføre sig "uventet" iforhold til de forventede testcases.

<html><head>

<title>Simple Calculator</title></head><body>

<h1>Test calculator</h1><form method=POST>

First number <input name="input1"><br>Second number <input name="input2"><br><button type="submit" name="command" value="add">+</button><button type="submit" name="command" value="mult">*</button><button type="submit" name="command" value="sub">-</button><button type="submit" name="command" value="div">/</button>

</form>


Side 22 af 66

<%int input1 = 0;int input2 = 0;boolean havevalue = false;try {

input1 = Integer.parseInt(request.getParameter("input1"));input2 = Integer.parseInt(request.getParameter("input2"));havevalue = true;

} catch (Exception e) {}if (havevalue) {

int result = 0;String command = (String) request.getParameter("command");if (command.equals("add")) { result = input1 + input2; }if (command.equals("mult")) { result = input1 * input2; }if (command.equals("sub")) { result = input1 - input2; }if (command.equals("div")) { result = input1 / input2; }//In testcase 4.5.5 ændres "+" i ovenstående til "*"out.println ("Result (i heltal)="+result);

}%>

</body></html>

Lommeregnerens brugergrænseflade består helt simpelt af to input-felter og knapper derkan behandle disse felter.

Ovenstående figur viser brugergrænsefladen på lommeregneren

Applikationen er som sagt lavet som en JSP / Tomcat applikation så der er mulighed forat et testværktøj kan indskydes mellem browser og applikation (hvilket ikke havde væretmuligt hvis der havde været tale om en ren klient applikation).Det er også på denne måde nogle af de testede værktøjer virker. Ved at lade al trafikmellem klient og server passere gennem en proxy, kan alle sider undersøges og sidernekan modificeres sådan at interaktion med brugeren kan opfanges.Med en så simpel og alligevel reel webapplikation har vi haft fuld kontrol over hvad vorestestværktøj arbejder på. Vi har kunnet introducere en fejl i applikationen (som ses itestcase 4.5.4 versus 4.5.5 nedenfor) for at se testværktøjets reaktion derpå.


Side 23 af 66

Oversigt over lommeregner arkitektur

4.5 Beskrivelse testcase til vurdering af værktøjer opmod kriterier

For at sikre en ensartet test, har vi valgt at definere følgende testcases.

De første 4 testcases har vi valgt for at sætte os i den situation testeren er i. Det vil sigeat man ikke har indgående kendskab til den tekniske opbygning af applikationen hvilketvil gøre det sværere at opbygge testscripts.

4.5.1 Test af maps.google.com

Teststep Handling

1 Hent maps.google.com

2 Klik linket "Få rutevejledning"

3 Udfyld testboksen ud for A med "Nordre Ringgade 1, 8000 Århus C,Denmark"

4 Udfyld testboksen ud for B med "Åbogade 34, 8200 Århus N, Denmark"

5 Tryk knappen "Hent rutevejledning"

6 Aflæs rutevejledning

Beståelseskriterium At første foreslåede rute er 1,3 km lang.

4.5.2 Test af www.w3.org

Teststep Handling

1 Hent www.w3.org

2 Klik på linket "Web Architecture"

3 Klik på linket "Internationalization"

Beståelseskriterium Aflæs at siden indeholder "What is Internationalization?"


Side 24 af 66

4.5.3 Test af translate.google.com

Teststep Handling

1 Hent translate.google.com

2 Verificer at der oversættes fra engelsk

3 Verificer at det oversættes til dansk

4 Indtast "This is a test"

Beståelseskriterium Aflæs oversættelsen "Dette er en test".

4.5.4 Test af lommeregner

Teststep Handling

1 Hent lommeregner

2 Indtast "5"

3 Tryk på "+"

4 Indtast "3"

5 Tryk på "="

Beståelseskriterium Kontroller at resultat er "8"

4.5.5 Testcase for test af ændringer

Teststep Handling

1 Gennemfør testcase 4.5.4

2 Gennemfør Testcase 4.5.4 på ny lommeregner (Hvor rækkefølgen af taler byttet om og "*" er tilføjet)

Beståelseskriterium Resultat er stadig "8"

4.5.6 Testcase for test af HTML5

Teststep Handling

1 Hent http://shwetankdixit.com/testpages/webforms2demo.htm

2 Kontroller at fokus er i feltet ved "First name"

3 Indtast 888 i feltet ved "Age".

4 Sæt fokus i feltet ved "Last name"

5 Indtast "Hokuspokus" i feltet ved "Last name"

6 Tryk på knappen "Move Down"

Beståelseskriterium Fokus er nu i feltet ved "Age" og værdien 25 skal fremgå.


Side 25 af 66

4.5.7 Testcase for test af pålidelighed

Teststep Handling

1 Udfør testcase 4.5.4

2 Gentag teststep 1 50 gange

3 Testen kan gennemføres uden fejl min. 90% af gangene


Side 26 af 66

4.6 Vurdering af fundne værktøjer op mod kriterier

Helt generelt har der vist sig i vores evaluering af testværktøjerne, at de på mangeområder deler styrker og svagheder. Vi har fundet det meget overraskende at der er endel værktøjer der netop har problemer med kriteriet: "Enkelt at se om testen er fejlet".Dette kan virke uhensigtsmæssigt, idet det netop er præsentationen af det udførtearbejde i testværktøjet. En anden bemærkelsesværdig betragtning har været, at det formange testværktøjer har været forholdsvist komplekst at installere dem. Dette gør detsværere at anvende dem.

4.6.1 Verifikation af de enkelte værktøjer

Herefter følger en beskrivelse af hvorledes de enkelte værktøjer lever op til de udvalgtekriterier, dette arbejde er til slut sat op i en matrix. For overskuelighedens skyld omtalesikke nødvendigvis alle testforløb for alle værktøjer fuldt ud, da vi har valgt at fokuserepå beskrivelse af de forløb der har fejlet eller på anden måde været interessante.


Side 27 af 66

4.6.1.1 Sahi

Sahi er et open source værktøj, lavet og primært vedligeholdt af Tyto Software Pvt fraIndien.

Sahi er nemt at komme i gang med, hvis man er teknisk mindet. Først skal Javainstalleres, derefter skal Sahi downloades som en zip. Efter man har pakket zip-filen ud,skal en proxy startes. Det er gennem denne proxy Sahi virker. Proxy’en modificerersider, som passerer igennem den. Derfor skal testerens browser indstilles til at brugeden.Når den første side er hentet gennem proxy’en, kan man begynde med at teste.

Let at læreSahi's grafiske brugergrænseflade er simpel og overskuelig, som det ses afnedenstående billede:

Eksempel på Sahi Controller

Billedet viser ”Sahi Controller” vinduet, der åbnes ved ALT+ dobbelt klik på enhjemmeside i en browser. ”Sahi Controller” giver mulighed for at optage de handlingerder fortages i GUI. Dette gøres let ved at indtaste et filnavn og derefter trykke på


Side 28 af 66

Record. I ”Sahi Controller” vinduet er det også muligt at se den seneste handling og derkan rettes i den. Ved at trykke på CTRL og lade musen svæve henover et sted på en sidevælges en komponent. Derefter kan man vælges om man vil aflæse komponenten ellerindsætte komponentens værdi.

Under dette kriterium, har vi også valgt at kigge på hjælpefunktionerne i værktøjet. Derer ikke indbygget hjælp i Sahi. På Sahi’s hjemmeside er der derimod en rigtig god video,der viser hvordan man bruger Sahi. Efter at have set videoen er man godt klædt på til atbruge Sahi.Det skal også nævnes at der på Sahi’s hjemmeside er lister over hvilke kommandoerSahi understøtter.Da der ikke har været problemer med at lære at bruge Sahi, vælger vi at give Sahi 3point i den subjektive vurdering. Sahi's mangel på indbygget hjælp gør at vi ikke kangive mere end 1 point i underkriteriet omkring hjælp.

Det skal være let at opsætte testDer er to metoder til at lave test i Sahi. Man kan enten optage eller selv skrive testene.Ofte vil man starte med at optage test i den grafiske brugergrænseflade. Det er sombeskrevet ovenfor meget let. Vælger man at skrive sine test selv, gøres det ved hjælp afSahi's eget scriptsprog, dette er simpelt men stadigvæk meget stærkt.Vi har testet dette kriterium ud fra hvor let det var at lave testcase 4.5.1-4.5.4. Da dethar været let at lave disse test, mener vi at Sahi gør det let at opsætte test. Dermed fårdette værktøj 1 point.

Understøtte "optage"Vi har ikke kunnet undlade at nævne Sahi's optagefunktion før. Det er en afhovedfunktionerne i Sahi. I ”Sahi controller” er det muligt at starte den indbyggedeoptagefunktion.Efter at have startet optageren, vil Sahi opfange de klik med musen som der udføres.Indtastes der noget i et tekstfelt bliver dette opfanget, når man forlader feltet.

Det skal nævnes at selv om handlinger overføres direkte til det optagne script, så skerdette ikke når man laver en verifikation som f.eks. at aflæse teksten i en komponent.Dette virker ind i mellem forvirrende og det er let at glemme at tilføje verifikationen tilscriptet. Således opnås 1 point for punktbaseret optagelse.

Understøtte et scriptlignende sprogSahi har et meget stærkt scriptsprog. Det består af linjer af kommandoer, der eropbygget på følgende måde:Handling (objekt type( object identifier ))Hvor:

• Handling: Er den handling der skal udføres på brugergrænsefladen, f.eks. klik• Objekt type: Er typen på HTML-elementet handlingen udføres, f.eks. knap• object identifier: Specificerer HTML-elementet entydigt, f.eks. teksten på

knappen


Side 29 af 66

Det ser umiddelbart ud til at Sahi har kommandoer til at udtrykke handlinger på deHTML-elementer der findes. Sahi understøtter de tre subkriterier for scriptsprog"Indtastning af data", "Aktivering af kontroller" og "Tjek resultat".

_assertExists(_select("sl"));_assert(_isVisible(_select("sl")));_assertEqual("Engelsk", _getSelectedText(_select("sl")));_assertExists(_select("tl"));_assert(_isVisible(_select("tl")));_assertEqual("Dansk", _getSelectedText(_select("tl")));_setValue(_textarea("text"), "This is a test.");_click(_submit("Oversæt"));_assertExists(_div("Dette er en test."));_assert(_isVisible(_div("Dette er en test.")));_assertEqual("Dette er en test.", _getText(_div("Dette er en test.")));_assertContainsText("Dette er en test.", _div("Dette er en test."));

Det skal også nævnes at der er mulighed for at lave funktioner i scriptsproget, hvilket eren meget stærk feature. Man kan derved inddele sin testcase i logiske dele.Sahi giver også mulighed for at læse og skrive til kommaseparerede filer og derved lavedata driven testing.På baggrund af ovenstående opfyldelse af de tre underkategorier opnås 3 point.

Let at revidere/modificere allerede beskrevne testSom før nævnt er Sahi’s scriptsprog enkelt opbygget. Dette gør at det er let at rette ieksisterende test. Sahi giver mulighed for at rette i en testcase uden at skulle hentescript-filen ind i igen. Det gør det hurtigt at revidere/ modificere allerede beskrevne testi testcases. Vi har også testet dette kriterium ved at udføre testcase "4.5.5 Testcase fortest af ændringer" og der var ingen problemer i at ændre testen. Vi mener derfor at deter let at revidere/ modificere allerede beskrevne test. Dermed opnås 1 point.

FleksibilitetSahi virker meget fleksibelt. For at teste dette kriterium, har vi set på hvor mange af deeksisterende testcases vi har kunnet teste med værktøjet heriblandt om der erunderstøttelse af HTML5. Som før nævnt er Sahi’s scriptsprog meget stærkt og der ergod mulighed for at teste mange HTML-elementer.Der har ikke været noget problem i at lave testcases for nogen af de test vi har på voresliste, på nær "4.5.6. Testcase for test af HTML5". Med hensyn til HTML5 så burde Sahihave en fordel ved at den virker gennem en eksisterende browser. Det er desværresådan at Sahi kun kan teste HTML-elementer det kender i forvejen. Derfor har det vistsig umuligt at teste HTML5 elementerne som vores testside i testcase 4.5.6 er bygget opaf.Dermed opnås 4 point for testcase 4.5.1-4.5.4.

PålidelighedVi har testet vores pålidelighedskriterium ved hjælp af vores testcase "4.5.7 Testcase fortest af pålidelighed" og der har ikke været problemer med dette værktøj. Fejlprocentenvar på 0, hvilket må siges at være meget godt. Sahi bedømmes derfor til at være etmeget pålideligt værktøj. Dermed opnås 1 point.

Enkelt at se om testen er fejletMed hensyn til vores kriterium om at det skal være enkelt at se om testen er fejlet, såbestår Sahi. I første omgang kan man se det i playback mode. Som det ses afnedenstående billede kan man i playback mode se de kørte kommandoer og at derafsluttes med en linje om testen er bestået eller ej.


Side 30 af 66

Brugergrænsefladen af Sahi

Sahi laver også logfiler over de kørte test. Ved at vælge "View logs" i "Sahi Controller"kommer der et skærmbillede op hvorfra det er muligt at se log-filerne. Selve log-filerneer rapporter, som er lavet i HTML. De giver igen mulighed for at se hvilke kommandoerder er kørt, og det er grafisk markeret hvilke kommandoer der er fejlet.Dermed tildeles 2 point i denne kategori.


Side 31 af 66

Eksempel på rapport genereret af Sahi

ScheduleringSahi giver mulighed for schedulering, selv om det ved første øjekast ikke ser sådan ud.Når Sahi bruges i playback mode skal startsiden for testen indtastes manuelt ogstartsiden gemmes ikke i scriptfilen.Sahi har dog en batchmode. Man kan lave en fil med angivelse af testscript og startside.Sahi kan så startes i batchmode, hvor den vil køre de angivne testscripts igennem.Batchmode kan også startes fra Ant. Det giver mulighed for at schedulere Sahi vedhjælp af cruise control. Således gives 2 point.


Side 32 af 66

Point tildelt Sahi

Følgende tabel opsummerer pointene givet til Sahi:Kriterium Subkriterium Point

Let at lære

Subjektiv vurdering (0-3p) 3

Indbygget hjælp (0-2p) 0

Hjælp på nettet (0-1p) 1

Let at opsætte test

Relativ kort tid / få steps atopsætte en testcase (0-1p) 1

Understøtte "optage"

Grafisk optage (0-1p) 0

Kontekst optage (0-1p) 1

Autogenerering af testcases(0-1p) 0

Understøtte etscriptlignende sprog

Indtastning af data (0-1p) 1

Aktivering af kontroller(0-1p) 1

Tjek resultatet (0-1p) 1

Let at revidere/modificereallerede beskrevne test

Der kan rettes i testscripts(0-1p) 1

Fleksibilitet

Testcase 4.5.1-4.5.4 (0-4p) 4

Testcase 4.5.6 (HTML5)(0-1p) 0

Pålidelighed

Stabilitet (0-1p) 1

Enkelt at se om testen erfejlet (inkl. rapport overudførte test)

Rapport over fejledetestcases (0-1p) 1

Rapport over kørte test(0-1p) 1

Schedulering

Schedulering mulig (0-1p) 1

Den mulige schedulering erindbygget (0-1p) 1


Side 33 af 66

Dette giver følgende fordeling af styrkerne ved værktøjet i forhold til de opstilledekriterier:

Radargraf for Sahi


Side 34 af 66

4.6.1.2 Canoo webtest

Canoo WebTest er et open source værktøj til automatiserede test af web applikationer.Det er lavet af Canoo Enginering AG fra Schweiz.

Canoo webtest er et batch-værktøj uden en grafisk brugergrænseflade. Det gør at detikke er muligt at optage fra Canoo Webtest i sig selv. Da der for andre af vore testedeværktøjer er tale om at værktøjet er splittet op i flere programmer, har vi besluttet ogsåat kigge på WebtestRecorder. WebtestRecorder er et plugin til Firefox, som gør detmuligt at optage test.

Let at læreI forhold til om værktøjet er nemt at bruge, lever det ikke umiddelbart op til alle dekriterier vi har opstillet.

Nedenfor vises et billede af WebtestRecoder:

WebtestRecorder skærmbillede

WebtestRecorder er meget simpel. Den giver mulighed for at fange klik med musen ogindtastninger i tekstfelter. Man kan også bruge WebtestRecoder som editor, hvilket dener god til, da der er farvning af syntaks. WebtestRecoder giver ikke mulighed for atgemme de testcases man optager. Man er overladt til copy'n'paste for at få gemt.Med hensyn til selve Canoo Webtest er der heller ikke meget der gør det let for en nybruger. Canoo webtest har en indbygget wizard, som opbygger en fornuftigprojektstruktur. Strukturen gør det let at starte på at teste. Desværre er det sådan atden indeholder en del prædefinerede test. Derfor er det nødvendigt at man starter medat rydde op.Canoo webtest bygger på Ant. For en der har brugt Ant før, vil det derfor være let atstarte med at bruge Canoo Webtest. Ant er lavet til og bliver mest brugt til bygge-script,derfor forventer vi ikke at der er det store kendskab til Ant hos QA-personale.Vi har valgt at give Canoo Webtest 1 point i den subjektive vurdering.


Side 35 af 66

Kigger man efter hjælp i programmet, er der ikke meget at hente. Der er tale om etbatch-værktøj/kommandolinjeværktøj, hvor der ikke findes en speciel editor til. Derfor erman overladt til den ellers udmærkede hjælp der findes på værktøjets hjemmeside.Heller ikke WebTestRecorder har nogen hjælp indbygget.

Værktøjet i sig selv er ganske ukompliceret at sætte op og der er et omfattende online-hjælpe katalog, samt at der er tale om en standard Java applikation, der blot skalpakkes ud og konfigureres. Canoo webtest er forholdsvis let at konfigurere, hvis man eravanceret computer bruger. Hvis man ikke før har sat den slags programmer op, vil detikke være let.På baggrund af online hjælpekataloget får værktøjet således 1 point

Det skal være let at opsætte testI forhold til om det er let at opsætte test, er det til dels tilfældet. Canoo webtest har somnævnt en indbygget wizard, som opbygger en fornuftig projektstruktur. De test somman har defineret i Canoo ligger i ens test-projektfil; således skal man for at tilføje enny test til sit eksisterende test-projekt blot tilføje denne testcase til projektfilen. F.eks.ved at tilføje:

<webtestname="demo">

<invoke url="http://www.xyz.com/"/><verifyTitle text="XYZ" />ebTest" />

</webtest>

Der er tale om at der kun skal tilføjes data til en scriptfil. Dermed må dette kriteriumbetragtes om opfyldt, det er let at opsætte test. Det kræver kun 1 logisk handling: Atindsætte testen i projektfilen. Således gives der trods ovenstående bemærkninger 1point.

Understøtte "optage"I forhold til at understøtte optagelse er dette kun muligt i WebTestRecorder.WebTestRecorder baserer sig på logisk optagelse, forstået på den måde at de grafiskekomponenter identificeres ved hjælp af deres HTML-id, navn eller hvilken tekst der ervist. WebTestRecorder integrerer sig med browserens højrekliksmenu sådan at det ermuligt at aflæse tekst og indsætte verifikationspunkter af komponenter. Det gør det endel lettere, hvis man ikke kender den tekniske opbygning af webapplikationen. Hvis manmedtager dette tillægsprogram kan man således give den 1 point for punktbaseretoptagning.

Understøtte et scriptlignende sprogCanoo understøtter i høj grad et scriptlignende sprog til beskrivelse af testcases. I denhenseende ligger Canoo's måde at fungere på tæt op af Ant. Sproget er et af de mestomfattende i forhold til de øvrige værktøjer, og det understøtter umiddelbart de treunderkriterier som vi har identificeret:

Indtastning af dataAktivering af kontrollerTjek resultat.


Side 36 af 66

Nedenfor vises et eksempel på Canoos scriptsprog:

<?xml version="1.0"?><!DOCTYPE project SYSTEM "../dtd/Project.dtd"><project default="test">

<target name="test"><webtest name="check that WebTest is Google's top 'WebTest' result">

<invoke url="http://maps.google.com/"/><clickLink description="Click link: Få rutevejledninger" htmlId="d_launchsel"/><setInputField name="saddr" value="Nordre Ringgade 1, 8000 Århus C,

Denmark"/><setInputField name="daddr" value="Åbogade 34, 8200 Århus N, Denmark"/><clickButton label="Hent rutevejledning"/><verifyTitle text="Nordre Ringgade 1, 8000 Århus, Danmark til Åbogade 34, 8200

Århus, Danmark - Google Maps"/></webtest>

</target></project>

Som det kan ses bygges test op i XML på samme måde som Ant. Der er en god supportaf de komponenter der findes i HTML. På baggrund af denne understøttelse opnås 3point.

Let at revidere/modificere allerede beskrevne testI forhold til at revidere/modificere allerede beskrevne test er dette, som beskrevet under"Let at opsætte", ganske enkelt i Canoo. Dermed er dette kriterium umiddelbart opfyldtog der gives 1 point.

FleksibilitetI denne kategori ser vi på hvilke af testcasene vi har fået Canoo til at teste, herunder omder er understøttelse for HTML5. Her har det vist sig at Canoo ikke er fleksibelt. Vedgennemførelsen af vores test var der ikke en af dem der kunne gennemføres:I testcase "4.5.1 Test af maps.google.com" kunne testen ikke gennemføres fordi Canooikke understøtter danske bogstaver. Det er så stort et problem for Canoo med danskebogstaver, at den nægter at gennemføre resten af testene. Det har heller ikke væretmuligt at få testen til at virke ved at escape de danske bogstaver, eller ved at angive attestfilen er i unicode.I testcase "4.5.2 Test af www.w3.org" kommer der en fejl når siden er hentet. Det eruvist hvorfor.I testcase "4.5.3 Test af translate.google.com", er det ikke muligt at få Canoo til ataflæse oversættelsen.I testcase "4.5.6 Testcase for test af HTML5" er første problem, at der ikke findesmulighed for at kontrollere om fokus er et bestemt sted på siden. Næste hindring er atCanoo ikke kan finde feltet "Age".Den eneste testcase som det var muligt for os at gennemføre var testcase "4.5.4 Test aflommeregner". Vi har derfor måtte konstatere at Canoo webtest ikke er fleksibelt.Dermed opnås kun 1 point.

PålidelighedDette kriterium er testet ved at eksekvere testcase "4.5.7 Testcase for test afpålidelighed" og der har i dette konkrete tilfælde ikke vist sig nogen fejl under denneafvikling. Således har fejlprocenten været nul for dette værktøj.Dermed opnås 1 point.


Side 37 af 66

Enkelt at se om testen er fejletDet er en af Canoo's store forcer, at det er let at se om testen er fejlet. Canoo webtesthar en genial rapportgenerator. Efter hver kørsel af Canoo Webtest, bliver der generereten testrapport som bliver vist i en browser. Rapporten er grafisk, hvor der med farvedestreger vises hvilke test der er kørt igennem samt om de er succesfulde eller fejlede,meget lig f.eks. Junit.

Eksempel på rapport genereret af Canoo Webtest

Som det kan ses af det ovenstående eksempel giver rapporten også mulighed for at sehvilke testtrin, der er fejlet og til en vis grad hvorfor. I vores kriterier har vi kun opstilletkrav til at der skal kunne vises en rapport over fejlede og alle kørte testcases: Detteopfyldes til fulde. Dermed er dette kriterium opfyldt og der tildeles 2 point.

ScheduleringCanoo understøtter ikke schedulering i sig selv. Det er dog muligt at schedulere Canoomed et eksternt program (f.eks. via Cruise Control). På samme måde som medoptagning har vi valgt at lade det indgå i testen. Det er således muligt at opsætteautomatiserede kørsler af Canoo. På baggrund af denne eksterne mulighed gives 1 point.


Side 38 af 66

Point tildelt Canoo

Følgende tabel opsummerer pointene givet til Canoo WebTest:Kriterium Subkriterium Point

Let at lære
















Fleksibilitet

Testcase 4.5.1-4.5.4 (0-4p) 1


Pålidelighed

Stabilitet (0-1p) 1




Schedulering




Side 39 af 66


Radargraf for Canoo Webtest


Side 40 af 66

4.6.1.3 iMacro

Der findes flere forskellige iMacro versioner. Vi har valgt at evaluere versionen, derfungerer som et plugin til Firefox, for at se hvordan et sådant værktøj er i forhold tilkriterierne.En vurdering af iMacro op imod vores valgte kriterier giver overordnet et indtryk af atiMacro, som navnet antyder, er et macro værktøj. Som sidegevinst kan det ogsåanvendes til automatiseret test. Værktøjet anvendes primært som macroværktøj, f.eks.hvis man skal logge ind i en applikation gentagne gange eller lignende.

Let at læreVærktøjet må siges umiddelbart at leve op til kriteriet om at være nemt at bruge. Detfungerer som et plugin til en eksisterende browser. Når man installerer plugin'et bliverder hentet en hjemmeside ind i browseren, der giver mulighed for at se en video med entutorial. Denne viser hvordan man kommer i gang med at lave macro'er i iMacro. Derbliver vist hvordan man optager, afspiller og ændrer i de testcases, man har optaget.Det tager kun fem minutter før man er i gang med at lave macro'er i iMacro. Det erderfor vi giver iMacro 3 point i den subjektive vurdering.

Med hensyn til underkriteriet hjælp, så er der en "Hjælp" funktion i iMacro. Dennefunktion åbner dog umiddelbart blot hjælpesiderne hos producenten, men da værktøjetnetop er integreret med browseren mener vi at dette kan betragtes som intern hjælp iprogrammet. Derudover er mange af de mere basale funktioner mere eller mindreselvforklarende. Da der både er integreret hjælp og hjælp på nettet opnås 3 point.

Det skal være let at opsætte testDet kræver nogle logiske skridt at opsætte test i værktøjet. Disse skridt kan opdeles i:

1. Vælge menupunkt Rec¦ Record2. Herefter optages ønsket macro3. Herefter vælges Stop4. Herefter skal Macroen gemmes5. Hvorefter man kan vælge manuelt at editere testen6. Og som afslutning gemme den

Der kræves således et ganske betydeligt antal skridt for at opsætte en ny test iværktøjet. Dette er umiddelbart upraktisk, da det kan virke hindrende på brugen. Det tiltrods må værktøjet vurderes til at opfylde kriteriet, men det er lidt mere omstændeligtend flere af de øvrige værktøjer, som vi har evalueret. Der gives 1 point.

Understøtte "optage"Værktøjet understøtter begge de metoder vi har defineret i forbindelse med optagning.Man kan selv vælge om det er punktbaseret eller baseret på HTML koder. Denpunktbaserede metode fungerer ikke optimalt, idet det f.eks. ikke kan lade sig gøre, vedat lave eksempeltestcases på googlemaps, at navigere rundt på det Ajax understøttedekort i denne applikation. Dette strider mod vores umiddelbare forventning, da et værktøjder fungerer som plugin til en eksisterede browser umiddelbart kan forventes atunderstøtte dette. Dog understøttes kravet om automatisk generering af testcases ikke.Der opnås 2 point.

Understøtte et scriptlignende sprogDen meget begrænsede understøttelse af et scriptlignende sprog er umiddelbart detvæsentligste kritikpunkt i forhold til de øvrige programmer. I forhold til voressubkriterier kan værktøjet understøtte "Indtastning af data" og "Aktivering af kontroller".Problemet er at "Tjek resultat" ikke understøttes i vanlig testforstand. Værktøjet kan


Side 41 af 66

præsentere resultatet, men kan ikke validere resultatet automatisk. Således kanværktøjet ikke siges at leve op til dette kriterium som en helhed. Det er f.eks. ikkemuligt at definere alternative flows eller at lave egentlig evaluering. Det skyldes denyderst begrænsede understøttelse. Det kan illustreres af nedenstående testcase, hvorbrugeren præsenteres for oversættelsen af ordet "house" fra engelsk til dansk på googletranslate men resultatet kan ikke automatisk verificeres:

VERSION BUILD=6600217 RECORDER=FXTAB T=1URL GOTO=http://translate.google.com/#TAG POS=1 TYPE=TEXTAREA FORM=NAME:text_form ATTR=ID:source CONTENT=houseTAG POS=1 TYPE=INPUT:SUBMIT FORM=ID:text_form ATTR=ID:old_submitWAIT SECONDS=2TAG POS=1 TYPE=SPAN ATTR=TITLE:house EXTRACT=TXT

På baggrund af den manglende verifikationsmulighed opnås kun 2 point.

Let at revidere/modificere allerede beskrevne testI forhold til at revidere/modificere allerede beskrevne test kan det betragtes på sammemåde som hos Canoo, da det er de samme egenskaber der gør sig gældende. Her skalblot redigeres i den allerede udfyldte testbeskrivelse. Der er dog en væsentlig forskel,man kan ikke umiddelbart "optage" en ændring til en allerede eksisterende test, menkun modificere den manuelt. Dette til trods må kriteriet stadig betragtes som opfyldt ogder opnås her 1 point.

FleksibilitetVærktøjet lever delvist op til kravet om fleksibilitet. Testcasene 4.5.1-4.5.4 kan testesuden problemer, hvorimod testcasen vedr. HTML 5 (4.5.6) ikke har været mulig atgennemføre. Årsagen til den manglende HTML5 support er, at iMacro versionen undertest fungerer som et plugin til Firefox og baserer sig således på browserens muligheder,og firefox understøtter ikke det element af HTML5 vi tester for. Dermed opnås 4 point.

PålidelighedVi har testet dette værktøj op mod vores testcase "4.5.7 Testcase for test afpålidelighed" og der har været nul procent fejl. Dermed er der tildelt 1 point.

Enkelt at se om testen er fejletiMacro lever ikke op til vores kriterium om, at det skal være enkelt at se om testen erfejlet. Dette har flere meget markante årsager. Det er ikke muligt i værktøjet at laveegentlig validering/test. Der er behov for en manuel proces, for at vurdere om enkonkret testcase er fejlet. Dermed er det ikke muligt for værktøjet at lave en enesterapport automatisk vedr. status på den udførte test, heller ikke nogen af de to rapportersom vi har defineret i vores subkriterier ("Rapport over fejlede test, Rapport over allekørte test"). Dermed opnås 0 point.

ScheduleringVærktøjet har ikke indbygget mulighed for Schedulering og det har end ikke væretmuligt at aktivere en sådan funktionalitet eksternt fra programmet. Dette kriterie kansåledes på ingen måde siges at være opfyldt. Dermed gives 0 point


Side 42 af 66

http://translate.google.com/

Point tildelt iMacro

Følgende tabel opsummerer pointene givet til iMacro:Kriterium Subkriterium Point

Let at lære
















Fleksibilitet

Testcase 4.5.1-4.5.4 (0-4p) 4


Pålidelighed

Stabilitet (0-1p) 1




Schedulering




Side 43 af 66


Radargraf for iMacro


Side 44 af 66

4.6.1.4 SeleniumHQ

SeleniumHQ er en suite af programmer til automatisering af test af webapplikationer.SeleniumHQ er startet af Jason Huggins fra ThoughtWorks i 2004 og bliver i dagvedligeholdt og videreudviklet af et comunity af udviklere, der er opstået omkringSeleniumHQ.

SeleniumHQ suiten består af tre værktøjer:

Selenium IDE, et Firefox plugin til optagelse af test.Selenium Remote Control, en server der starter og stopper browsere.Selenium Grid, styrer et antal instanser af Selenium Remote Control og fordeler testimellem instanserne.

Let at læreTil dette kriterium vil vi starte med at kigge på Selenium IDE værktøjet. Det gør vi, dadet er denne del af suiten, der har mest interaktion med brugeren, og det er her manstarter med at bruge suiten. Ud fra vores kriterier er Selenium nemt at bruge.SeleniumHQ IDE startes fra Firefox og åbner den simple og overskueligebrugergrænseflade, som ses nedenfor:

SeleniumHQ IDE brugergrænseflade

Brugergrænsefladen giver mulighed for at optage de handlinger som foretages i Firefox.Derudover er det muligt at tilføje egne kommandoer som f.eks. kontrol af tekst. Hvisman ikke kan huske hvilke kommandoer der er til rådighed, gør SeleniumHQ det let. Icomboboxen "Command" er det muligt at finde alle de kommandoer, der kendes afSeleniumHQ. Nedenunder "Command" findes "Target", hvor man kan indtaste hvilken


Side 45 af 66

HTML-element man ønsker at påvirke. Ved tryk på "Find" knappen vil HTML-elementetblinke på siden. Til sidst er det muligt at indtaste den værdi, man vil påvirke HTML-elementet med i "Value" feltet.På trods af at den tilsyneladende opfylder vores kriterier om at være enkel at bruge rentGUI mæssigt, så er der dog lidt mærkværdigheder. Ud fra en subjektiv vurdering er dertale om at det ikke er lige så enkelt at anvende som f.eks. iMacro. Dette kan til delstilskrives de yderligere valgmuligheder i værktøjet, men der er også en rækkedeciderede uhensigtsmæssigheder; F.eks. er det lidt omstændeligt at skifte mellem flereforskellige testcases i samme testsuite. Det kræver op til flere dobbeltklik og man erstadig ikke sikker på om der er skiftet testcase inden for suiten. Derfor har vi valgt kunat give SeleniumHQ 1 point i den subjektive vurdering.

Under dette kriterium har vi også valgt at kigge på den tilbudte hjælp. Hjælpen er iSeleniumHQ IDE meget god, også hjælpen på nettet. Det skal fremhæves, at der er enfin in-line dokumentation af de forskellige "kommandoer" i værktøjer; F.eks. kan derunder generering af testcases læses en fin beskrivelse af de enkelte kommandoer, eteksempel kan ses nedenunder:

altKeyDownAndWait()Generated from altKeyDown()Press the alt key and hold it down until doAltUp() is called or a new page is loaded.

Således opnås 3 point for den tilbudte hjælp.

Det skal være let at opsætte testI forhold til vores kriterium om at det skal være let at opsætte test, vil vi kun kigge påSeleniumHQ IDE, da det er i dette værktøj, man laver sine test. Som vi har nævnt før erSeleniumHQ IDE et plugin til Firefox, derfor vil vi i det følgende gå ud fra at det er iFirefox man vil lave sine test. I den kontekst lever værktøjet op til kriteriet.Selve installationen af værktøjet er problemfri. Fra forsiden af seleniumhq.org er derdownload link til en installer, der installerer SeleniumHQ IDE i Firefox. Der kræves etyderst begrænset antal skridt for at tilføje en ny testcase til en eksisterende testsuite:

1. Højreklik i området "Test case" og vælg "New Test Case"2. Herefter trykkes der på optage ikonet, hvorefter optagelsen starter3. Nu kan optage funktionen afsluttes - og dermed er testcasen defineret

Optagefunktion i SeleniumHQ IDE

Med baggrund i de yderst begrænsede antal steps gives 1 point.


Side 46 af 66

Understøtte "optage"Værktøjet understøtter delvist kriteriet om at optage. Som vi har nævnt før, er det enintegreret del af SeleniumHQ IDE værktøjet. Vi ser på to forskellige metoder tiloptagelse:

• Punktbaseret, hvor der registreres hvilket HTML-element der aktiveres ud fraposition

• Kontekstbaseret, hvor der registreres hvilket HTML-element der aktiveres ud fraHTML-id, navn eller hvilken tekst der er vist.

SeleniumHQ understøtter i modsætning til iMacro ikke mulighed for punktbaseretoptagelse men kun kontekstbaseret optagelse. Selve funktionen er rigtig god. Deroptages hvad der skrives i browseren, og det er også muligt at højreklikke på et HTML-element og vælge at få indsat et teststep, der f.eks. aflæser tekst. Man kan herigennemoptage de dele af en side der skal kontrolleres.Med hensyn til delkriteriet om automatisk generering af testcases, understøtter hellerikke dette værktøj denne funktionalitet. På baggrund af den kontekstbaserede optagningopnås her 1 point.

Understøtte et scriptlignende sprogSom alle de øvrige testede værktøjer understøtter SeleniumHQ IDE også etscriptlignende sprog. Det forekommer som værende et meget omfattende sprog medmange verifikationsmuligheder, som f.eks. at aflæse tekst i title-element. Det er ogsåmuligt at teste indholdet af cookies. Alle testcases optaget i SeleniumHQ IDE kangemmes. SeleniumHQ IDE har sit eget format, som bygger på et HTML dokument derindeholder en tabel. Det er et knapt så fornuftigt format som f.eks. Canoo's Ant-lignendeformat, men mulighederne i sproget er mangfoldige hvilket vurderes som vigtigere endselve formatet på sproget. SeleniumHQ IDE har mulighed for at omdanne en testcase tilflere forskellige sprog. En test kan f.eks. omdannes til Java, og derefter køres i Junit.Der bliver altså brugt Java som sprog og testcasene er opbygget som Junit test.Betragter vi selve det HTML baserede sprog som testcasene er defineret i (eksempelherunder) forekommer der umiddelbart en række "spild" information såsom definering afcellpadding og border. Disse elementer er forstyrrende under opsætning af test og haringen funktion i relation til de enkelte test, disse (cellpadding og border etc.) er såledesblot forstyrrende elementer i et ellers udmærket framework. Man kan selv definere etHTML format og dermed løse disse uhensigtsmæssigheder, men en ændring af dette vilbevirke at man ikke kan modtage testcases fra samarbejdspartnere, uden at havenøjagtig samme ændringer til fortolkningen af HTML formatet.

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd"><html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en" lang="en">

<head profile="http://selenium-ide.openqa.org/profiles/test-case"><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><link rel="selenium.base" href="http://translate.google.com/" /><title>house</title>

</head><body>

<table cellpadding="1" cellspacing="1" border="1"><thead>

<tr><td rowspan="1" colspan="3">house</td></tr></thead><tbody><tr>

<td>open</td>


Side 47 af 66

<td>http://translate.google.com</td><td></td>

</tr><tr>

<td>click</td><td>original_text</td><td></td>

</tr><tr>

<td>type</td><td>source</td><td>house</td>

</tr><tr>

<td>click</td><td>old_submit</td><td></td>

</tr><tr>

<td>verifyTextPresent</td><td>wohnung</td><td></td>

</tr></tbody></table>

</body></html>

Selve det scriptsprog som SeleniumHQ understøtter lever op til alle vores subkriterier idenne kategori. Dette gælder både indtastning, aktivering og tjek. Dermed opfylderværktøjet dette kriterium og får alle 3 point.

Let at revidere/modificere allerede beskrevne testKriteriet om det er muligt at revidere/modificere allerede beskrevne test hænger nøjesammen med det lidt uheldigt valgte HTML format. Som udgangspunkt burde detsåledes være meget nemt at rette i de allerede definerede testcases, men formatet erikke selvforklarende, som et veldefineret XML format kunne have været. Man skal derforaltid tænke på at første kolonne er kommando, anden er hvad der skal påvirkes ogtredje kolonne er hvad der skal påvirkes med. At kriteriet alligevel må betragtes somopfyldt af værktøjet skyldes, at der er en fin mulighed for at editere allerede beskrevnetest inde i SeleniumHQ IDE. Her gives der som beskrevet under kriteriet "Let at lære" enfin inline hjælp.En stærk feature ved SeleniumHQ IDE er at man kan få alle sine testcases oversat tilXunit. Så kan man rette og tilføje på sit favoritsprog. Desværre vil SeleniumHQ IDE ikkeåbne testcases skrevet i andet end sit eget format. Således opnås trodsbemærkningerne 1 point.

FleksibeltSeleniumHQ IDE må betragtes som meget fleksibelt. Idet det har været muligt atdefinere testcases til næsten alle vore eksempeltestcases. Den eneste test der har giverproblemer er "4.5.6 Testcase for test af HTML5". Årsagen til den manglende HTML5support er, som for iMacro, at den anvendte firefoxbrowser ikke understøtter dentestede HTML5 funktionalitet. Manglen på HTML5 understøttelse går igen, hvis manforsøger at skrive en test i hånden og køre den gennem SeleniumHQ RC. Kriteriet ersåledes ikke opfyldt som helhed men der opnås 4 point.


Side 48 af 66

PålidelighedVærktøjet må vurderes som meget pålideligt. Der har ikke været problemer med detunder vores anvendelse af værktøjerne. Ligeledes har der ingen fejl været ved testningmed testcase "4.5.7 Testcase for test pålidelighed". Således opnås 1 point

Enkelt at se om testen er fejletKriteriet om at det skal være enkelt at se om en test er fejlet er ikke opfyldt afSeleniumHQ IDE. Det til trods for at det er meget nemt inde i værktøjet at se status påkørte test. Der er ikke mulighed for at eksportere resultatet til noget egentligrapportformat. De testcases som defineres i SeleniumHQ IDE kan dog anvendes i deøvrige værktøjer i SeleniumHQ suiten og herfra er det muligt at generere en rapportover alle kørte test. Således kan kriteriet opfyldes under anvendelse af ekstra værktøjer.Således tildeles 1 point.

ScheduleringI forhold til schedulering er denne funktionalitet ikke understøttet af værktøjet. Det harheller ikke været muligt at starte testcasene under anvendelse af IDE versionen fra enekstern scheduler. Således kan det konkrete værktøj ikke understøtte dette kriterium ogder gives 0 point


Side 49 af 66

Point tildelt SeleniumHQ

Følgende tabel opsummerer pointene givet til SeleniumHQ:Kriterium Subkriterium Point

Let at lære
















Fleksibilitet

Testcase 4.5.1-4.5.4 (0-4p) 4


Pålidelighed

Stabilitet (0-1p) 1




Schedulering




Side 50 af 66


Radargraf for SeleniumHQ


Side 51 af 66

4.6.1.5 Watir

Der findes en hel del testværktøjer der alle er alternativer af den oprindelige Watir. Watirer den oprindelige Ruby variant - men der findes også andre i form af f.eks. Watij forJava etc. Vi har valgt at fokusere på Watir, da det er den oprindelige variant indenforwatiX familien. Desuden har Watir også understøttelse af bl.a. et Firefox plugin. Watirsynes umiddelbar interessant, da det anvendes af store virksomheder såsom Yahoo,Oracle og HP. Desuden påstår Watir på deres hjemmeside at "It supports your web appno matter what it is developed in.".

Let at læreHvis vi vurderer værktøjet op mod "Let at lære" kriteriet kan vi se at værktøjetumiddelbart kræver nogen viden for at kunne installeres. Dette er noget merekompliceret end f.eks. iMacro. Watir er som nævnt bygget på Ruby, hvilket medfører atdet installeres ved hjælp af et pakkesystem fra kommandopromten:

gem update --systemgem install watir

Systemet kan mod forventning ikke siges at være enkelt at bruge; F.eks. opstår der enrække problemstillinger hvis man bruger den officielle installationsvejledning (f.eks.manglende dll filer etc.). Ligeledes er installationen af Firefox plugin'et heller ikke heltlige til, og da dette værktøj ikke er beskrevet i større detaljer på Watirs hjemmeside oger inaktivt i svn7 vil vi ikke beskæftige os yderligere med dette plugin. Derfor giver vi 1point i den subjektive vurdering.Ser vi på underkriteriet "indbygget hjælp" er der ikke nogen i Watir da der er tale om etkommandopromt baseret system, der baserer sig på at brugeren har et fornuftigtkendskab til Ruby. Dermed kan dette kriterium ikke betragtes som opfyldt. Dermedopnås kun 1 point for online hjælp.

Det skal være let at opsætte testI forhold til opsætning af test må dette kriterium vurderes at være på samme niveausom de øvrige rene scripting værktøjer. Watir har dog en umiddelbar fordel i forhold tiløvrige rene kommandolinjebaserede testværktøjer såsom Canoo, dette ligger ianvendelsen af Ruby. Brugeren kan direkte fra Ruby konsollen affyre de enkelte linjer itesten. Dette kan bl.a. ses her:

C:\temp\watir>irbirb(main):001:0> require "watir"=> trueirb(main):002:0> ie = Watir::IE.new

Da test i et passende scriptingsprog således kan affyres direkte i konsollen, må detbetragtes som værende let at opsætte test. Disse test kan naturligvis også defineres ifiler til senere afvikling. Dette kan ske under integration til andre Ruby applikationer ogsåledes kan netop dette værktøj anvendes som integreret del af et allerede eksisterendeprogrammeringssprog.

7. Ingen opdateringer i 4 år jvf. http://svn.openqa.org/fisheye/viewrep/watir/branches/firefox


Side 52 af 66

http://svn.openqa.org/fisheye/viewrep/watir/branches/firefox

http://svn.openqa.org/fisheye/viewrep/watir/branches/firefox

Man kan sige, at det der kendetegner WatiX "familien" af testværktøjer er, at de udvidereksisterende programmeringssprog, så det fra dem direkte er muligt at håndteretestcases i deres eget sprog. Dette vil naturligt sikre at det, med et passende API, vilvære let at opsætte test, idet der anvendes et allerede eksisterendeprogrammeringssprog, og det må antages at personen der opsætter test selv vælger denWatiX variant der passer til vedkommendes præferencer inden forprogrammeringssprog.Der er dog den uhensigtsmæssighed at det ikke altid er tilfældet at testressourcer harprogrammerings-ekspertise, og at det således måske er en fordel at det bygger på etkendskab til allerede eksisterende og omfangsrige programmeringssprog. Dermed opnås1 point.

Understøtte "optage"Watir understøtter desværre ikke nogen form for optagning af test. Watir forsøger atafhjælpe dette ved at beskrive på deres hjemmeside hvordan man ved hjælp af en ikkeWatir relateret toolbar til Firefox kan aflæse DOM m.v. på de hjemmesider der ønskestestet. Men dette er ikke en optimal løsning, og denne manglende optagefunktion eressentiel idet det medfører at brugeren skal have et yderst intensivt kendskab til denapplikation der skal testes. Det er en naturlig del af den fremgangsmåde som WatiX harvalgt, at integrere testen ind i allerede eksisterende sprog. Således kan WatiX anvendestil meget avancerede testforløb som også i praksis ikke vil være mulige at "optage". Ikkedesto mindre er det dog uhensigtsmæssigt at det ikke er muligt.Da det ikke er muligt at optage opnås 0 point i denne kategori.

Understøtte et scriptlignende sprogDa Watir netop bygger på Ruby har den et scriptlignende sprog der følger Ruby-standarden. Således vil dette sprog formentlig være intuitivt opbygget set fra en person,der har Ruby kendskab. Sproget understøtter alle de elementer som vi har forudsat forat tilfredsstille de opstillede kriterier (dataindtastning, aktivering af kontroller ogverifikation af resultatet). Ydermere understøtter sproget funktioner til opstart af krævetbrowserinstans m.v., hvilket er krævet for at kunne komme i gang med de egentligetest. Om alle de sprog som WatiX varianterne understøtter er scriptlignende, er ikkenødvendigvis essentielt. Det vi har ønsket at afdække med dette kriterium er, om det ermuligt på en måde at definere test tekstuelt (og om brugeren har adgang til dette),hvilket er tilfældet. Da alle tre elementer i kategorien er opfyldt opnås de fulde 3 point.

Let at revidere/modificerer allerede beskrevne testWatir er ikke speciel i forhold til standarden mht. revidering og modificering af allerededefinerede test. Dette skyldes at test kan defineres i eksterne filer. Således kan manuden problemer åbne og editere disse allerede beskrevne testcases, og dermedmodificere en eksisterende test. Der opnås således 1 point.

FleksibilitetSom foreskrevet i vores kriterium er dette testet ved at afprøve testcase 4.5.1 til 4.5.4og 4.5.6. Alle disse testcases på nær "4.5.6 Testcase for test af HTML5" er gået godt.Der har kun været problemer med HTML5 aftestningen. Watir understøtter i dag kunInternet Explorer, Firefox, Chrome og Safari. Ingen af disse kan leve op til vores HTML5testcase, og dermed heller ikke Watir. Det kan dog bemærkes at det fremgår på Watir'shjemmeside at der findes en eksperimentel version til Opera. Da Opera > 9.5understøtter de elementer vi tester i denne testcase - vil testen muligvis lykkes når dettefrigives. Dermed opnås pt. 4 point i denne kategori.

PålidelighedVærktøjet har vist sig fint pålideligt i forhold til de gentagne afviklinger af teststeps fravores testcase "4.5.7 Testcase for test af pålidelighed". Der har som forventet ikkeværet pålidelighedsproblemer med værktøjet. Dermed tildeles 1 point.


Side 53 af 66

Enkelt at se om testen er fejletDet er ikke muligt ud fra Watir alene at generere en rapport over gennemførte test.Værktøjet kan således ikke siges at leve op til dette kriterium. Dog skal det bemærkesat værktøjet fungerer som integreret med Ruby, hvorfor der er mulighed for at afvikleanden rubykode i forbindelse med testscriptafviklingen. Således vil det være muligt atlave et rapportgenereringsværktøj selv (eller anvende et som andre har udviklet). Detteer positivt, men som alle andre eksterne "plugins" og løsninger afhænger dette af etsamspil mellem en 3. parts leverandør og Watir, hvorfor det således ikke er en optimalløsning. Men i en større organisation hvor man evt. selv kan stå for vedligeholdelsen afen sådan komponent, kan dette måske ligefrem være en fordel, idet man så i højeregrad end ellers vil kunne tilpasse rapporter til ens egne krav. Alligevel gives 0 point dasådanne tillægsprogrammer ikke er integreret i Watir.

ScheduleringDer er ikke i Watir indbygget værktøjer til schedulering af test, men da værktøjet erkommandolinjebaseret vil det være muligt at opsætte ekstern schedulering tilautomatisk afvikling af Watir test. Ligeledes kan en test være inkorporeret i en andenruby-applikation hvilket også kan være en fordel. Dette kriterium kan ikke siges at væreopfyldt for værktøjet, men delvist opfyldt da det kan startes eksternt. Dermed opnås 1point


Side 54 af 66

Point tildelt Watir

Følgende tabel opsummerer pointene givet til Watir:Kriterium Subkriterium Point

Let at lære
















Fleksibilitet

Testcase 4.5.1-4.5.4 (0-4p) 4


Pålidelighed

Stabilitet (0-1p) 1




Schedulering




Side 55 af 66


Radargraf for Watir


Side 56 af 66

4.6.2 Opsummering af fundne egenskaber

Nedenstående matrix angiver om de enkelte værktøjer lever op til de identificeredekriterier. Dette er tilfældet hvis kriterierne er helt opfyldt med maksimum point.

Værktøj/kriterium Sahi Canoo

webtest iMacro SeleniumHQ Watir

1. Let at lære Nej Nej Ja Nej Nej

2. Det skalvære let atopsætte test

Ja Ja Ja Ja Ja

3.Understøtte"optage"

Nej Nej Nej Nej Nej

4.Understøtteetscriptlignendesprog

Ja Ja Nej Ja Ja

5. Let atrevidere/modificerealleredebeskrevnetest

Ja Ja Ja Ja Ja

6.Fleksibilitet Nej Nej Nej Nej Nej

7.Pålidelighed Ja Ja Ja Ja Ja

8. Enkelt atse om testener fejlet

Ja Ja Nej Nej Nej

9.Schedulering Ja Nej Nej Nej Nej

For at kunne se i større detaljeniveau end ovenstående hvordan de enkelte værktøjerlever op til de enkelte subkriterier kan dette vurderes vha. en radargraf. Nedenståenderadargraf er således en samlet oversigt over hvordan de enkelte værktøjer evalueres iforhold til de enkelte subkriterier. Man kan anvende denne graf som hjælp til at afgørehvilket værktøj der er bedst egnet til en given opgave.


Side 57 af 66

Samlet radargraf

Som det fremgår af radargrafen er det ikke entydigt hvilket værktøj der er bedstegenerelt set. Dog scorer især Sahi med også iMacro og Watir generelt godt på de flestekriterier.

Ligeledes ses at ingen værktøjer opfylder kriterierne "Understøtte 'optage'" og"fleksibilitet". Med hensyn til at "Understøtte 'optage'" hænger det sammen med, atingen af værktøjerne opfylder delkriteriet "Autogenerering af testcases". Mht. kriterietfleksibilitet er der ingen af værktøjerne der opfylder delkriteriet om HTML5 og derforingen værktøjer der opfylder dette kriterium.

Alle værktøjer opfylder kriteriet om at det skal være let at opsætte test. Dette kan haveto årsager, enten er alle de valgte programmer stærke på dette område eller også har viikke fået kvantificeret dette kriterium tilstrækkeligt.

Alle programmer opfylder også kriteriet "Let at revidere/modificere allerede beskrevnetest" og man kunne bruge samme argumentation som med hensyn til ovenståendepunkt, men eftersom det netop er muligt at revidere/modificere test i de valgteprogrammer mener vi, at disse i hvert fald ikke har noget større problem med dettekriterium. Men derfor kan kriteriet godt være relevant, da der måske kan væreproblemer med andre ikke testede værktøjer.

Endelig opfylder alle de valgte programmer kriteriet om pålidelighed. Igen kan man stillespørgsmål om vores test for kriteriet er tilstrækkelig og vi kan bestemt ikke udelukke, atman kunne teste dette kriterium yderligere, men på den anden side set har alle deanvendte programmer været i udbredt anvendelse i længere tid, så man kan formentligtillade sig at antage, at dette ikke ville være sket, hvis de ikke opfyldte dette essentiellekriterium.

Man kan også vælge at se på, hvorledes de forskellige typer af værktøjer opfylder voreskriterier. Eftersom vi kun har beskæftiget os med 5 forskellige værktøjer, kan det væresvært at udtale sig om en eller flere af typerne er specielt stærke indenfor et eller flereaf kriterierne. Vi har dog kigget lidt på, om der ses tendenser dertil, men når man ser påSahi og Watir, har de på ingen måde ensartede profiler selv om disse begge tilhører


Side 58 af 66

”Standalone-typen”. Det samme gælder iMacro og SeleniumHQ, der begge tilhører”plugin-typen”. Vi mener således ikke, at man på baggrund af vores arbejde kan udtalesig om, hvorvidt valget af type af værktøj har nogen betydning.


Side 59 af 66

4.7 Det ideelle værktøj

Med baggrund i vores identificerede kriterier samt evaluerede værktøjer kan man gøresig nogle overvejelser om "Det ideelle værktøj". Man kan umiddelbart antage, at detideelle værktøj vil være et, der opfylder alle vores stillede kriterier. Dette forholder sigimidlertid ikke så enkelt. Hvad der er det ideelle værktøj må afhænge af, hvilke behovder er i det konkrete tilfælde, f.eks. kan det til en mindre opgave være vigtigt atfokusere på, at værktøjet er let at lære, mens schedulering har større betydning i størreopgaver hvor regressionstest anvendes.

Der kan argumenteres for at det ikke er interessant, om et givent testværktøjunderstøtter en bestemt HTML standard (HTML5), hvis der ikke anvendes HTML5 i detder skal testes. På den anden side forventes det, at HTML5 bliver mere udbredt ifremtiden, og derved kan dette delkriterium vise sig at være meget væsentligt.

Det er på den baggrund ikke trivielt at lave et entydigt beslutningstræ for hvilketværktøj der er mest optimalt i den enkelte situation. Det skyldes, at man vil have enforskellig vægtning af kriterier, som så efter en individuel vurdering kan fordre brugen afet eller flere værktøjer. Det er derimod mere rimeligt at angive, hvordan man finderfrem til det ideelle værktøj, frem for at angive en entydig angivelse af, hvilket værktøjder er ideelt.

Man er således nødt til at gå ind i detail-pointgivningen samt relateret litteratur. Det vilformentlig godt kunne betale sig at investere en rimelig mængde ressourcer i at findedet ideelle værktøj til en given opgave, da ingen af de testede værktøjer understøtter etgenerelt scriptformat/dataudvekslingsformat. Man vil derfor være låst til det valgteværktøj.


Side 60 af 66

5 Relateret arbejde

Følgende relaterede arbejde er blevet identificeret:

5.1 [CSTTE]

[CSTTE] har som tidligere omtalt udført relateret arbejde. De har vurderet på et brederesæt kriterier og på nogle andre applikationer end vi har, idet de evaluerer deres kriterierpå følgende tre værktøjer: Winrunner, Rationel Robot og HTTrace.For hvert af deres kriterier (tasks i deres terminologi) kommer [CSTTE] herefter med ensummarisk beskrivelse af i hvor høj grad de enkelte værktøjer lever op til disse.Hvis man sammenligner vores arbejde op imod [CSTTE] vil man se at vi kun harbeskæftiget os med deres tasks: "C Constructing Test Cases", "D Executing test cases","E Caputring and comparing test results" og ” F Reporting test results.”, og endda ikkealle kriterier i hver af disse.Hvis vi sammenligner [CSTTE]’s resultater med vores resultater ser man at [CSTTE],ligesom vi, finder at det er muligt at opstille nogle effektive kriterier til testværktøjer.Dette gør de da de ser forskellige resultater ved test med deres tre testprogrammer. Iforhold til vores arbejde nævner [CSTTE] at det kan være relevant at lave specifikketestkriterier til specifikke områder: Objekt orienteret testing, component baseret testingog sidst men ikke mindst GUI testning. Vores arbejde fortsætter således til dels meddette forslag til videre arbejde i [CSTTE], da vi netop har fokuseret på anvendelsen iforhold til GUI webapplikationer.

5.2 [GUILLEMOT]

Marc Guillemot har skrevet et indlæg på sin blog. Indlægget er en sammenligning afprogrammerne Canoo Webtest og SeleniumHQ.Marc Guillemot er en af udviklerne bag Canoo Webtest. Derfor er det sandsynligt atsammenligningen lider under at han har en bias for det program han selv udvikler ogkender bedst.

Marc Guillemot sammenligner de to programmer på de 17 følgende punkter :

• Browser fidelity• Reports• Speed• Integration in development process• Scalability• Capture JS errors• Testing AJAX• Beginner friendly• Documentation• Predictable behaiour• XPath• Support for badly formatted HTML code• Extensibility• Data driven tests• Multi-language• Internationalisation• Support for non HTML content.


Side 61 af 66

Af disse punkter er der ikke stort sammenfald med de kriterier vi har opstillet i dennerapport. Der er kun sammenfald på følgende tre punkter: "Reports", "Beginner friendly"og "Documentation". "Reports" sammenfalder direkte med "Enkelt at se om testen erfejlet". "Beginner friendly" og "Documentation" sammenfalder med vores kriterium "Letat lære". Dette kan antyde at Marc Guillemot's punkter er opstillet med tanke påudviklingen af værktøjet, frem for brugen af det.Marc Guillemot er nok også farvet af hvilke features han mener er vigtige og harimplementeret i det værktøj han udvikler på i forhold til hvilke der er implementeret iværktøjerne.Som nævnt ovenfor sammenfalder vores kriterium "Let at lære" med Marc Guillemot's topunkter "Beginner friendly" og "Documentation". Marc Guillemot mener ikke at CanooWebTest er let at lære, hvilket vi heller ikke er kommet frem til. I det andet punkt kiggerhan på den dokumetation der findes på værktøjet's hjemmeside og finder at denne forSeleniumHQ's tilfælde er meget mangelfuld. Dette er vi ikke enige i. Til de testcases vihar lavet med værktøjet, har vi fundet stor støtte i den dokumentation der findes påhjemmesiden.I punktet "Reports" kommer Marc Guillemot til den konklusion at Canoo WebTest har enbedre rapport generator end SeleniumHQ, samme konklusion kommer vi til under voreskriterium om "Enkelt at se om testen er fejlet".


Side 62 af 66

6 Konklusion

Med baggrund i vores arbejde med hypotesen er vi nået frem til at den overordnet harværet delvist opfyldt. For at beskrive dette nærmere, vil vi nedenfor betragte hvertdelelement af hypotesen, så vi for hvert element i arbejdshypotesen har mulighed for atvurdere i hvor høj grad den er valid.

Første del af hypotesen:

1. Der kan opstilles meningsfulde kriterier for valg af programmer til automatiseret GUItest af webapplikation

Vi har ud fra eksisterende litteratur opstillet og beskrevet en række kriterier for valg afprogrammer til automatiseret test af GUI i webapplikationer. De opstillede kriterier blev:

1. Let at lære2. Det skal være let at opsætte test3. Understøtte "optage"4. Understøtte et scriptlignende sprog5. Let at revidere/modificere allerede beskrevne test6. Fleksibilitet7. Pålidelighed8. Enkelt at se om testen er fejlet (inkl. rapport over udførte test)9. Schedulering

Derfor er denne del af hypotesen opfyldt.

I forhold til anden del af hypotesen:

2. Der findes gratis programmer, der kan vurderes ud fra disse kriterier.

Denne del af hypotesen er opfyldt, da vi har fundet gratisprogrammer som vi har kunnetvurdere op imod kriterierne.Man kan hævde at denne del af hypotesen er opfyldt såfremt der findes gratisprogrammer og såfremt del 1 i hypotesen er opfyldt, da programmerne nødvendigvis måkunne testes ud fra kriterierne, da kriterierne ellers ikke er anvendelige. Der er såledesen sammenhæng mellem hypotesens del 1 og 2.

I forhold til tredje del af hypotesen:

3. Der findes programmer der kan leve op til de opstillede kriterier.

Denne del af hypotesen kan kun delvis siges at være opfyldt.Vi har testet nogle udvalgte værktøjer op imod vores kriterier ved hjælp af noglewebapplikationer. Vi er nået frem til at ingen af værktøjerne opfylder alle kriterier.Vi har illustreret i hvor høj grad de enkelte værktøjer opfylder vores kriterier ved atafbilde dette på radargrafer.

Med baggrund i vores radargraf-sammenligning vil man kunne sige noget om, hvilketestværktøjer der i størst grad lever op til bestemte kriterier. Inden man vælger ettestværktøj, bør man vurdere, hvilke af vores identificerede kriterier der er vigtige for


Side 63 af 66

den opgave man arbejder på. Herefter vil man med baggrund i vores pointgivning kunnevælge det af vores testede værktøjer, der lever op til netop det delsæt af kriterier.

Hvis man f.eks. er i en situation, hvor man har behov for et værktøj der understøtterschedulering, vil Sahi være et godt valg. Hvorimod f.eks. iMacro er nemmere at lære ogdermed har lavere entrycost.Ser man på vores evaluerede værktøjer kan man dermed med rimelighed sige, at dehver har deres forcer.Man kan argumentere for, at visse af kriterierne i praksis kan være næsten essentielle.Der vil derfor være nogle bestemte elementer, det vil være meget væsentligt at et"ideelt" værktøj bør opfylde. Hvis vi tager udgangspunkt i vores analyse af værktøjerneville det ideelle værktøj have følgende elementer:

• Report generator fra Canoo Webtest• Lige så nemt at bruge og installere som iMacro• Så god opfyldelse af vores kriterier generelt som Sahi• Understøttelse af eksterne/eksisterende programmeringssprog til definering af

testcases som WatiX

Naturligvis kan der være en risiko for, at vores kriterier kan være gensidigt udelukkende- eller i det mindste have en tendens til det. Der kan f.eks. være en modstrid mellemønsket om et meget intuitivt værktøj, som iMacro, og et med mange muligheder såsomWatiX, afhængigt af hvilke behov der er i den konkrete situation, QA personaletsressourcer og kompetencer m.v.

Samlet set er hypotesen ikke helt opfyldt, men det har overordnet være muligt atopstille meningsfulde kriterier for valg af programmer til automatiseret GUI test afwebapplikationer og finde gratis programmer der kan vurderes ud fra disse kriterier. Meningen af de fundne værktøjer opfylder alle kriterierne.


Side 64 af 66

6.1 Fremtidigt arbejde

Gennem vores arbejde med emnet har det været åbenlyst at vi ikke umiddelbart harkunnet finde en industri-standard for hvad et testværktøj bør opfylde. Således findes derikke umiddelbart en certificering af testværktøjer, der sikrer at de lever op til etfornuftigt minimum sæt af anvendelsesmuligheder. Et fremtidigt arbejde kunne bestå i,med afsæt i dette arbejde, at lave et forslag til en industristandard for testværktøjer. Såde enkelte producenter kan få en uvildig instans til at afgøre om deres værktøj lever optil en form for modenhedsskala eller er specielt anvendeligt til bestemte cases.

Man vil kunne anvende vores kriterier 1-9 som udgangspunkt - og f.eks. lave flereversioner af dem, eller lave en suite af kriterier, man så kan angive som en form forfaktablad, således at ens værktøj lever op til visse bestemte kriterier.

Man vil også kunne arbejde med at definere visse af vore kriterier bedre. F.eks. harvores granulering af pålidelighedskravet ikke været særlig stor. Måske kan man udbyggedet med en vurdering af om værktøjet er pålidelig for passende små/store testsets ellermiljøer m.v.

Alternativt kan man i et fremtidigt arbejde forsøge at udvikle (eller deltage ividereudviklingen af et allerede eksisterende værktøj) så det i højere grad vil leve op tilvores foreslåede kriterier.

Endelig vil man måske kunne foreslå et generelt dataudvekslingsformat for testcases såman som bruger ikke er låst af sine allerede eksisterende testsuites.


Side 65 af 66

7 Referencer

Forkortelse Titel Forfatter År Forlag/Konferencetitel

[KAL] Effective GUI TestAutomation

Kanglin Liog MengqiWu

2005 SYBEX

[LJW96]Regression Testingof GUI EventInteractions

Lee J.White 1996 IEEE/Proceedings of the 1996

International Conference onSoftware Maintenance

[WOL92]

Automated GUIDisplay Testing ofa Large Networkmanagementsystem

WilliamWalters 1992 Quality Week June

[WIM92]

Catching BugsEarlier: TheUnexpectedBenefits ofAutomating GUItesting

NancyWinston 1992 Quality Week June

[CSTTE]

Criteria forSoftware TestingTool Evaluation – ATask Oriented View

T.Illes,A.Herrmannog B.Paech, J.Rückert

2005 Proceedings of the 3rd WorldCongress for Software Quality

[FRS]

Flexible, ReliableSoftware:Design PatternsandFrameworks—ToolsandProces

HenrikBærbakChristensen

2009 Chapmann Hall / CRC Press

[Burnstein] Practical softwaretesting

IleneBurnstein 2003 Springer

[GUILLEMOT]webtest vsselenium webtestwins 13-5

MarcGuillemot 2007

http://mguillem.wordpress.com/2007/10/29/webtest-vs-selenium-webtest-wins-13-5/

[BECK]Test-DrivenDevelopement byexample

Kent Beck 2003 Addison-Wesley


Side 66 af 66

hovedopgave - aarhus universitet · automatiseret test af gui i webapplikationer preben christensen...

Documents