wacc – Ett webb­acceptans­test­verktyg

Publicerad taggat , , , .

Jag har börjat skriva ett verktyg för att testa webbtjänster. Verktyget, wacc, är främst till för acceptanstest, men kan även vara användbart för lasttest och systemövervakning.

De krav som ska testas beskrivs programmatiskt i en textfil. Formatet är tänkt att kunna skrivas av ickeprogrammerare, kanske en produktägare eller en verksamhetsexpert i det agila teamet. När kraven väl är skrivna kan de köras helt automatiskt, gärna från integrationsverktyg som hudson eller maven, eller från systemövervaknings­verktyg som nagios.

Vi börjar med att titta på ett exempel på ett testscript:

: Sample wacc test script
get http://www.kth.se/
check "div#secondary a[title*=studenter]" Studentwebben
followLink "div#secondary a[title*=studenter]"

check "h1 a#headerText" Studentwebben
followLink "div#navigation a[.^=Kurs-]"

check title "Kurser per avdelning"
followLink a[.=Datalogi]

check title "Kurser, CSC/Datalogi"

Varje rad är något som ska utföras eller kontrolleras. Varje rad består av ett kommando och ett antal parametrar till det. Kommandot get följs av en url och kontrollerar att den urlen kan hämtas inom rimlig tid. När man har hämtat en sida kan man göra tester på innehållet på den sidan. Kommandot check kontrollerar att ett visst element finns på sidan och att dess innehåll är korrekt.

Kommandot followLink kontrollerar att en viss länk finns och följer den, vilket innebär att det kontrolleras att sidan kan hämtas på rimlig tid och följande tester utgår från nya sidan.

Filosofi och andra verktyg

Jag har tittat på httpunit och selenium. Båda verkar, var på sitt sätt, både kraftfulla och smidiga, men deras mål skiljer sig en del från mina.

Mina designkriterier är:

  • Testfallen ska beskrivas i ord. Dels för att testa just det man vill testa och inte en massa ovidkommande detaljer, och dels för att man ska kunna skriva testerna innan man skriver webbtjänsten som ska testas.
  • Man ska inte behöva vara programmerare för att skriva tester. Språket måste vara enkelt och överskådligt. Jag ser hellre att jag kompletterar med httpunit för de mer avancerade fallen än att det blir svårare att skriva testfall för wacc.
  • Det ska vara lätt att köra testerna. Testerna ska körs som ett ickeinteraktivt kommando, så de kan enkelt köras inifrån ett större testscript. Man ska inte behöva någon särskild testmiljö.

Såvitt jag kan se uppfyller selenium det andra och möjligen första kriteriet, men inte det tredje, medans httpunit uppfyller det första och tredje kriteriet, men inte det andra.

Testspråket

Ett testscript består av rader. Varje rad är ett test, som kan lyckas eller misslyckas. Om ett test misslyckas anses hela testscriptet ha misslyckats och och körningen av det testscriptet avbryts.

Varje rad består av ett kommando och ett antal parametrar till det. Parametrar skiljs med mellanrum, parametrar som innehåller mellanrum skrivs inom citattecken.

Kommandon

: text ...

  • Noop. Hela raden skrivs ut i testprotokollet.

    •  get url

  • Hämtar url, som måste anges absolut, och använder det som aktuellt testdokument.

    Om det tar för lång tid att hämta dokumentet anses testet ha misslyckats.

    •  check selektor text

  • Kontrollerar att det element, i det aktuella dokumentet, som anges av selektor har innehållet text. Om selektor matchar flera testas det första.

    •  followLink selektor

  • Kontrollerar att det element, i det aktuella dokumentet, som anges av selektor är en länk (dvs har ett attribut href) och följer den. Om selektor matchar flera testas det första.

    Det aktuella dokumentet ersätts med det länkade dokumentet.

    Om det tar för lång tid att hämta det länkade dokumentet anses testet ha misslyckats.

    •

    Selektorer

    En selektor identifierar ett visst element (eller attribut) i en webbsida (egentligen i det DOM-träd som beskrivs av htmlfilen, javascript och externa objekt ignoreras).

    För närvarande använder jag (ungefär) den syntax som beskrivs av CSS 3. Några exempel:

    title

  • Ett element som heter title.

    •  html head title

  • Ett element som heter title, som ligger i ett element som heter head, som ligger i ett element som heter html. I normala html­dokument är detta samma element som ovanstående.

    •  p.title

  • Ett element som heter p, där attributet class innehåller ordet title.

    •  p#title

  • Ett element som heter p, där attributet id har värdet title.

    •  a[href |= 'ftp:']

  • Ett element som heter a, där attributet href har ett värde som börjar på "ftp:" (dvs en länk till en ftp-server).

    •

    Jag hanterar också ett par egna utökningar av selektorsyntaxen, inspirerade av XPath:

    a @href div#foo @href

  • Matchar själva attributet href på ett element som heter a, eller på något element som ligger inuti elementet div#foo

    •  a[. |= 'foo']

  • Ett element som heter a, där textinnehållet (av element och dess underelement) börjar på "foo". Matchar afoobar/a lika väl som till exempel aemfbo/bo/embara.

    • Eventuellt kommer en framtida version av wacc att överge CSS-syntaxen och i stället använda XPath. Det är mer kraftfullt, men å andra sidan kanske mindre tillgängligt för en ickeprogrammerare.

    Rasmus Kaj rasmus@krats.se

    Skriv en kommentar

    Din epostadress kommer inte att visas. Du kan inte använda markup i kommentaren, men en dubbel radmating blir en styckesbrytning.