JMeter - JSF alkalmazások terheléses tesztelése 2.

Egy korábbi bejegyzésben már írtam a JMeter általános használatáról, most pedig az előző elméleti ismeretekre építve kifejezetten a JSF-es web-alkalmazások JMeter-es terheléses teszteléséről lesz szó. Kezdjünk is neki!

Először is felvettem a szükséges JMeter konfigurációs elemeket, majd a JMeter Proxy Server segítségével rögzítettem egy tesztesetet, ami két HTTP kéréses keresésből állt. Az első kérés egy HTTP GET volt amivel lekértem a /CustomerSearch/search.jsf oldalt. Ez volt a JSF terminológia szerint az initial request, amikor is a szerver oldalon felépül a JSF komponensfa. Ezután kitöltöttem keresés űrlap mezőit majd egy HTTP POST kéréssel átküldtem a szervernek az adatokat és válaszként megkaptam a keresési eredményeket. Ez a második kérés már egy JSF postback volt, amihez az űrlap rejtett mezőjébe generált JSF komponensfa azonosítója, a viewStateId is elküldésre került.

A szkriptelési feladatunk, hogy a teszt futtatásakor a viewStateId-t mindig aktualizáljuk, mivel az minden lefutáskor más értéket fog kapni!

Az első megoldás az alábbi ábrán is látható JMeter Post Processor, a Regular Expression Extractor használata lehetne, miszerint az initial kéréshez tartozó válasz forrásából kinyerjük a javax.faces.ViewState értékét, majd a JAVAX_FACES_VIEWSTATE változóba eltárolva, a postback kérésnél a ${JAVAX_FACES_VIEWSTATE} kifejezéssel passzoljuk tovább!

Ez így elsőnek jónak tűnik, de mi lehet ezzel a probléma? A tapasztalat azt mutatja, hogy a JSF-re épülő keretrendszerek néha több sorba is megtörik a viewStateId átadására használt rejtett input mezőt, pl. a következőképpen:

<input id="javax.faces.ViewState" 

name="javax.faces.ViewState" type="hidden" value="aCe2XnokY5W3qRKTuTgT12YSQ0gxrqOMV9PcIU3FrDsUykah
" />

Ez azért probléma, mivel a JMeter-es reguláris kifejezéseket nem tudunk több sorban elhelyezkedő inputra illeszteni. De akkor hogy szedjük ki a viewStateId? Aki ismeri a JMeter eszköztárát annak a válasz egyszerű, a reguláris kifejezés helyett használjuk az XPath Extractor Post Processor-t az alábbi ábra szerint.

Ezek után már tényleg nincs más dolgunk, mindössze annyi, hogy a második postback kérésnél cseréljük le a beégetett viewStateId-t, az XPath kifejezésnél megadott változóra.

A folytatásban pedig arról fogok írni, hogy milyen előnyökkel jár, ha a dynaTrace-t a szoftverfejlesztési folyamatainkba is beillesztjük, legyen szó a fejlesztői ill. teszt eszközökről vagy egy CI platformról!