Testovanie webových aplikácií použitím Canoo WebTest, časť V.

Roman Hesteric  /  03. 06. 2008, 00:00

Séria článkov o open-source nástroji na automatizované testovanie webových aplikácií - Canoo WebTest. Písanie ľahko udržiavateľných testov.

Canoo WebTest - ako písať udržiavateľné testy [prax]

 

Využívanie property a property-súborov zabezpečí vysokú flexibilitu testov. Uvedený testovací skript používa ANT-premenné na špecifikáciu rôznych url a názvov buttonov pre rôzne jazykové mutácie vyhľadávača Google.

google.xml:

<project name= "example" default= "test" >

   <target name= "test" >
        <webtest name= "is 'Webtest' Google's top result" >
          <steps>
                <invoke url= "${startUrl}" />
                <verifyTitle text= "Google" />
                <setInputField name= "q" value= "WebTest" />
                <clickButton label= "${luckyButton}" />
                <verifyTitle text= "Canoo WebTestHomepage" />
          </steps>
        </webtest>
   </target>
</project>

de.properties

startUrl =http://www.google.de/de

luckyButton =Auf gut Glück!

fr.properties

startUrl =http://www.google.fr/fr

luckyButton =J'ai de la chance

sk.properties

startUrl = http://www.google.sk/

luckyButton = Skúsim šťastie

build.xml - štart testu

<ant antfile= "google.xml" >

    <property file= "sk.properties" >

</ant>

Využitie XML-entity, alebo ANT-makrá pre spoločné bloky testov:

MyTest.xml

<!ENTITY     goToLoginPage      SYSTEM "../../includes/gotologin.xml" >
   <project>

    ....
    <steps>
        &goToLoginPage;
    ... 
    </steps>
    ...
</project>

gotologin.xml

<group description= "go to login" >

    <invoke url= "http://mysite.com" />
    <verifyTitle text= "My great Web Site" />
    <clickLink label= "login" />
    <verifyText text= "Restricted area" />
</group>

Využitie makra, jeho definícia ...

<macrodef name= "doLogin " />

<attribute name= "login" />
    <attribute name= "password" />
    <sequential>
            &goToLoginPage;
            <setInputField forLabel= "Login" value= "@{login}" />
            <setInputField forLabel= "Password" value= "@{password}" />
            <verifyText text= "Welcome to the restricted area" regex= "true" />
    </sequential>
</macrodef>

... a použitie

....

<steps>

    <doLogin login= "canoo" password= "webtest" />
    ...
</steps>


Ako príklad prispôsobenia testovacích krokov uvediem možnosť znovupoužiteľnosti testovacieho kódu. Prvý príklad ukazuje síce plne funkčný test navigačných liniek na stránke, je však na príliš nízkej úrovni zovšeobecnenia a jeho znovupoužiteľnosť preto nie je možná.

Navigácia na stránke:
Home > StresTest > SmokeTest


Test navigácie:

<verifyXPath xpath= "//*[@id='navPath1']” text=" Home" />
<verifyXPath xpath= "//*[@id='navPath2']” text=" StresTest" />
<verifyXPath xpath= "//*[@id='navPath3']” text=" SmokeTest" />

Použitie doplneného kódu s makrom umožní jeho všeobecné použitia aj na iných miestach testovacích skriptov

<macrodef name= "verifyNavPath" />

    <attribute name= "level1" />
    <attribute name= "level2" />
    <attribute name= "level3" />
    <sequential>
        <verifyXPath xpath= "//*[@id='navPath1']” text=" @{level1}" />
        <verifyXPath xpath= "//*[@id='navPath2']” text=" @{level2}" />
        <verifyXPath xpath= "//*[@id='navPath3']” text=" @{level3}" />
    </sequential>
</macrodef>

...

<verifyNavPath level1= "Home” level2= "StresTest” level3= "SmokeTest”/>

 

Použitie jazyka Groovy na prispôsobenie a tvorbu vlastných testovacích krokov si predvedieme na nasledovných ukážkach. Groovy [http://groovy.codehaus.org/ ] je skriptovací jazyk, ktorý sa vykonáva ako Java Byte Code. Nakoľko je WebTest obvyklý ANT-task a Groovy implementuje AntBuilder, pomocou tejto technológie je možné vykonávanie Groovy skriptov vrámci WebTestu.

Navigácia na stránke:
Povinné ručení > Povinné ručení 2008

Groovy skript, ktorý definuje nový testovací krok [verifyNavPath]

<groovyScript>

<![CDATA[    

       class VerifyNavigationPath extends com.canoo.webtest.steps.Step {

       String level1, level2, level3, level4

       void doExecute() {

       def ant = new AntBuilder(project)

        def levels = [0, level1, level2, level3, level4]

       for (i in 1..<levels.size()) {

       if (levels[i])

           ant.verifyXPath(xpath: "//a[${i}]/text()", text: levels[i],

           description: "Verify level ${i}")

        } } }

       project.addTaskDefinition('verifyNavPath' , VerifyNavigationPath)

   ]]>

</groovyScript>

 

Použitie Groovy [verifyNavPath] vrámci WebTestu

<target name= "test_uses_groovy" >

        &definition;
        < webtest name= "test_uses_groovy" >
            &config;
            <steps>
                <doLogin/>
                <echo message= "MTPL" />
                <clickLink label= "POVINNÉ RUČENÍ" />
                <clickLink label= "Povinné ručení 2008" />
                <verifyNavPath level1= "Povinné ručení"
                                       level2= "Povinné ručení 2008" />
                <echo message= "Test OK" />
            </steps>
        </webtest>
</target>


Ďalším dobrým príkladom využitia jazyka Groovy vrámci WebTest-u je jeho využitie na špecifické testy, nedosiahnuteľné štandardnými prostriedkami Canoo WebTest-u. Nasledujúci skript testuje správnosť triedenia výsledkov kalkulácie. Predpokladá sa vzostupné triedenie. V princípe sa načítajú čísla zo zobrazenej tabuľky, ktoré sa presortujú pomocou Groovy a oba vektory sa následne porovnajú.

...

<clickButton label= "Pokračovat >>" />

<echo message= "groovy nested sort test ..." />
  <groovy description= "test table sorted" >
    import com.canoo.webtest.engine.StepFailedException as SFE
    def table = step.context.currentResponse.getHtmlElementById('quotes')
    def tds = table.getByXPath('tbody/tr[position()>2]/td[5]')
    def texts = tds*.asText()
    def sorted = new ArrayList(texts).sort()
    if (sorted != texts)
        throw new SFE("Not correctly sorted!", "$sorted", "$texts")
  </groovy>
<echo message = "Test OK" />

 

Canoo WebTest - smoke-test, stres-test

 

Smoke-test je špeciálny druh testu, ktorý sa spúšťa spravidla hneď po úspešnom builde aplikácie a jeho hlavným účelom je otestovanie aplikácie po zmenách, ktoré nastali. Typickým príkladom nasadením smoke-testov je ich nasadenie pred vydaním novej verzie, keď si chceme byť istí zachovaním pôvodnej funkčnosti aplikácie aj po implementovaní nových zmien.

Smoke-test: Webtest Monitor vs. Webtest konzola konzola:

smoke

Stres-test [load test] je súbor testov bežiacich paralelne, ktoré sa aplikujú na smoke testom prejdenú aplikáciu. Ich účelom je testovanie správania sa a stability aplikácie. Stres-testy by mali v čo najväčšej miere kopírovať produkčné prostredie a to ako hardvérovým prostredím, tak aj obsahom jednotlivých paralelne bežiacich testov.


Paralelný beh viacerých testovacích skriptov [stres-test]:

stres

 

Výsledky už ukončených testov, posledný test stále beží [stres-test]:

vysledky stres testov

 

Z uvedeného vyplýva, že smoke test-om môžeme nazvať testy, o ktorých sme hovorili doteraz. Sú to sekvencie testovacích scenárov, ktoré sa vykonávajú postupne a pri testovaní beží na testovacom počítači vždy iba jeden testovací klient. Smoke test je OK, ak všetky testy dopadli dobre a funkčnosť aplikácie je teda zachovaná. Ako však spustiť viac testovacích klientov paralelne tak, aby po ukončení každého z nich vznikol report, ktorý by zobrazil výsledky každého ukončeného testu bežiaceho paralelne? Spustenie viac testovacích klientov nie je žiaden problém. Problém nastane, keď sa tí paralelní klienti pokúšajú zapisovať výsledky testov a vytvárať reporty. Pri spustením každého sa totiž vymaže obsah /target adresára a neskôr spustení testovací klienti premazávajú výsledky testov. Ako tomu predísť?

  • Nastavenie property „wt.deleteReports.skip” v súbore build.xml

<property  name ="wt.delete.reports.skip" value = "skip"/>

Týmto spôsobom sa vypne vymazávanie obsahu /target adresára a všetci testovací klienti budú aditívnym spôsobom zapisovať výsledky testov do reportov. Nevýhodou je, že vymazanie predchádzajúcich výsledkov je potrebné urobiť ručne.

  • Zabezpečenie, aby každý bežiaci testovací klient vytváral report do svojho adresára. V súbore build.xml zmeníme

<tstamp>  
    <format property = "savepath" pattern = "yyyyMMdd_HHmm" />
</tstamp>
<property name = "wt.config.resultpath" location = "${savepath}"/>

čím zabezpečíme, aby každý testovací klient vytváral reporty do vlastného adresára - ktorého meno bude zhodné s časom jeho spustenia.

 

Nabudúce:

  • Canoo WebTest - testovanie aplikácií cez SSL
  • Canoo WebTest - data driven test

 

Neprehliadnite: