xPath performance-problem

Euforisk ser jag selenium-automattesterna köras igång och börja verifiera saker på siten. Men varför i all sin dar går det så långsamt? Det kan ju inte ta 7 sekunder att hitta ett element som jag pekat ut med namn!

Efter lite googlande har jag förstått att Internet Explorer inte hanterar xpath så vidare kvickt. I testfallen har jag använt xpath för att peka ut element och attribut. För att ange ett element med id left_column_index ser xpathen ut såhär;

//div[@id=’left_column_index’]

Ett förslag jag kommer över är att istället ange xpathen enligt:

xpath=id(’left_column_index’)

och visst blir det lite bättre men det är marginellt och dessutom klurigt att skriva.

Vissa hävdar att xpath är jätteenkelt om man bara använder ett verktyg som hjälper till att skapa den. Visst är det det, men nackdelen är att de verktygen inte har en aning om hur man gör xpathen generell. Jag vill inte peka ut en länk genom att ange exakt sökväg genom hela trädet:

\\div\div[2]\span[1]\span\div\div[4]\a

Vad händer då om länken byter plats? Merjobb!!

Åter till poängen: selenium har stöd för att peka ut element med hjälp av CSS. Mycket enkelt:

css=#left_column_index

Metoden är dessutom extremt snabbare än xpath-metoden.

Efter att ha bytt alla xPath-pekare mot CSS-selektorer ökade hastigheten, men inte så mycket som jag hoppats. Bara att leta vidare..

Ett tredje sätt som Selenium-ramverket erbjuder är att peka ut element med hjälp av namn. Helt enkelt genom att bara skicka in elementets namn som parameter. Mina testfall var nerlusade men den metoden eftersom de är så enkla att använda.

Man kan ju ana att även denna metod är riktigt seg. Snabbt byter jag även dessa mot CSS-selektorer och startar upp testfallen som nu springer på rejält fort! Från drygt 5 min i exekveringstid till under 1 min!

Slutsats: css-selektorer regerar!

4 reaktioner på ”xPath performance-problem

  1. Allt man gör som ska fråga en browser efter information blir mer eller mindre långsamt. Det finns en annan snabbare väg och det är att ladda ner hela sidan till ett objekt och sen använda en html-parser för att hämta/verifiera information.

    Jag hade samma problem som dig och eftersom jag använde Ruby som programspråk så använde jag Hpricot, http://wiki.github.com/hpricot/hpricot. Det är en bra och snabb HTML/XML parser. En sida där en html-tabell skulle gås igenom och hämta information tog runt 20 sekunder att testa med Selenium-metoder, under en sekund med Hpricot.

  2. En annan sak, xpaths blir betydligt bättre om sidan är ”ordentligt” uppbyggd med t.ex. id:n på div element:

    \\div\div[2]\span[1]\span\div\div[4]\a

    kanske då blir
    \\div[@id=’nice_id’]\a

  3. Jupp, så kan det vara. Bättre, men inte snabbare. Dessutom genereras inte snygg HTML från MOSS… surprise!

    För att testfallen ska vara hyfsat flexibla använder jag id så lite som möjligt. ASP.net hittar ju på sina egna id:n beroende på kontrollstrukturen vilket innebär att minsta ändrig i koden gör att alla id:n måste refaktoreras.

    Använder ganska mycket xPath:s contains-funktion;
    //div[contains(@id, 'del_av_idt')]

    Det fungerar bra men är inte snabbt.

Kommentarer inaktiverade.