JMeter – budowa planu testu aplikacji stworzonej przy użyciu JBoss Seam, część 2

Druga część wpisu poświęconemu tworzeniu przy użyciu JMeter planu testów aplikacji napisanej za pomocą szkieletu JBoss Seam.

• JMeter – budowa planu testu aplikacji stworzonej przy użyciu JBoss Seam, część 1 ^[1]
• JMeter – budowa planu testu aplikacji stworzonej przy użyciu JBoss Seam, część 2 ^[2]

Przygotowanie testu do obsługi aplikacji napisane w JBoss Seam

Można teraz spróbować uruchomić test. Jeżeli testujemy aplikację napisaną w JBoss Seam, prawdopodobnie żadna strona nie zostanie wczytana (można to potwierdzić np. patrząc na zawartość pliku localhost_access_log) a serwer aplikacji wyrzuci stos wyjątków mówiącymi, że nie można odzyskać widoku. Spowodowane jest to tym, że Seam zapisuje na stronach oraz często w URL lub w wysyłanych formularzach dodatkowe wartość, które określają nazwę danego widoku raz numer konwersacji. Można sobie z tym poradzić, ale wymaga to dodatkowej pracy nad testem.

Trzeba będzie sobie poradzić z dwoma elementami: widokiem oraz konwersacją.

• ViewState

  W przypadku widoku należy po kolej przejrzeć w aplikacji JMeter każde zapytanie, które zostanie wysłane do serwera aplikacji. Należy odszukać te strony, które zawierają w parametrach odwołanie do ciągu znakowego: javax.faces.ViewState. Powinna być tam określona wartość tego parametru, w moim przypadku było to j_id1:j_id2. W moim przypadku wywołanie to znajdowało się na drugiej stronie, w której następowało logowanie do aplikacji.

  ^[3]

  JMeter - ViewState

  Po identyfikacji właściwej strony należy należy teraz odszukać wywołanie poprzednie. Wartość dla parametru javax.faces.ViewState jest ustawiana w poprzednim wywołaniu, więc tam należy tę wartość przechwycić. Można to zrobić dodając do strony poprzedzającej to wywołanie komponent o nazwie Regular Expression Extractor, znajdujący się w menu Post Processors i go odpwiednio skonfigurować:

  • Name: ViewState Extractor – nazwa komponentu
  • Reference Name: VIEWSTATE – nazwa zmiennej, która będzie użyta do podstawienia wartości
  • Regular Expression: id="javax.faces.ViewState" value="([^"]*)" – wyrażenie regularne, które będzie użyte do pobranie właściwej wartości
  • Template: $1$
  • Match No.: 1
  ^[4]

  JMeter - ViewState Extractor

  Teraz jeszcze należy odpowiednio ustawić wartość dla parametru javax.faces.ViewState. Czyli trzeba otworzyć stronę na której występowało odwołanie do parametru i zmienić jego wartość na odwoła nie do zmiennej ${VIEWSTATE}.

  ^[5]

  JMeter - konfiguracja zmiennej VIEWSTATE

  Jeżeli odwołanie do parametru javax.faces.ViewState występuje także na innych stronach, to także trzeba będzie takie zmiany wprowadzić. W moim przypadku wywołanie występowało na 5 stronach.

• Konwersacje

  Konwersacje są jedną z włąściwości szkieletu JBoss Seam wyróżniającego go spośród innych rozwiązań (więcej na ten temat można znaleźć w manualu: Conversations and workspace management ^[6]). W aplikacji Seamowej można zauważyć, że duża część linków zawiera dodatkowy parametr o nazwie conversationId czy też cid. Określa on numer określonej konwersacji, i wymaga także odpowiedniego potraktowania przez narzędzie testujące.

  Sposób radzenia sobie z konwersacjami jest podobny jak przy problemie z ViewState: należy odszukać wszystkie wystąpienia danej konwersacji i odpowiednio zmienić je na wywołania zmiennej.

  • najpierw należy zidentyfikować nazwę parametru używanego przez aplikację, może to być np. conversationId lub cid
  • odszukać wystąpienia tego parametru, powinien być przekazywany przy użyciu linku, czyli metodą GET, w moim przypadku jest to czwarta strona, wyświetlająca produkt:
    ^[7]

    JMeter - wywołanie conversationId

  • należy do poprzedniej strony (analogicznie jak w przypadku ViewState) dodać komponent Regular Expression Extractor i go odpowiednio skonfigurować:
    • Name: ConversationID Extractor – nazwa komponentu
    • Reference Name: CID – nazwa zmiennej, która będzie użyta do podstawienia wartości
    • Regular Expression: conversationId=(\d+) – wyrażenie regularne, które będzie użyte do pobranie właściwej wartości
    • Template: $1$
    • Match No.: 1
    ^[8]

    JMeter - ConversationID Extractor

  • odszukać wystąpienia danej konwersacji na następnych stronach i za wartość podstawić zmienną ${CID}:
    ^[9]

    JMeter - konfiguracja zmiennej CID

  • powyższe kroki trzeba powtórzyć dla każdego numeru konwersacji (czyli jak zmienia się jej numer, to należy użyć wyrażenia regularnego do jego uzyskania, i następnie podstawiać tę wartość na następnych wywołaniach strony), w moim przykładzie należało użyć wyrażenia regularnego 3 razy i podmienić na zmienną 8 wartości

Po powyższych zmianach można uruchomić test i powinien już zadziałać bez problemów.

Uruchomienie testu

Ostatnim elementem testu będzie uruchomienie go w kilku wątkach oraz konfiguracja JMetera tak, aby używał do logowania kont różnych użytkowników.

Za zarządzanie użytkownikami odpowiada kontroler User Parameters. Pozwala on na zdefiniowanie użytkowników, jacy mogą zostać użyci w trakcie testu.

W ramach tego komponentu należy zdefiniować nazwę zmiennej która będzie używana do podstawienia za login oraz hasło użytkownika. W kolejnych kolumnach należy zdefiniować wartości dla tych zmiennych.

W przypadku aplikacji DVD Store występuje pięciu użytkowników o nazwach od user1 do user5, wszyscy z hasłem pasword. Definicja dla nich może wyglądać następująco:

Należy jeszcze zmodyfikować odpowiednio proces logowania do aplikacji, i zamiast wysyłania wartości w formularzu, wstawić odpowiednie zmienne JMeter:

Ostatnim elementem będzie uruchomienie większej ilości wątków i przetestowanie aplikacji. Można to zrobić w ramach komponentu Thread Group. W nim ustala się następujące parametry:

• Number of Threads – ilość jednocześnie uruchamianych wątków, jeden wątek odpowiada jednemu użytkownikowi, jeżeli wątków będzie więcej niż zdefiniowanych użytkowników, to od nowa brany jest do logowania pierwszy użytkownik i potem następni
• Ramp-Up Period – po jakim czasie wszystkie wątki mają działać, czyli ustawienie tu wartości na 5 sekund przy 5 wątkach spowoduje, że każdy wątek będzie uruchamiany co sekundę
• Loop Count – ilość powtórzeń testów

Przykładowa konfiguracja może wyglądać tak:

Pozostaje teraz zdefiniować obciążenie serwera, uruchomić test i oglądać jak wygląda obiciążenie i kiedy serwer przestanie odpowiadać na zapytania.

Na koniec przygotowany plan testów dla aplikacji: Plan testu DVD Store ^[14].

Źródła

• Load testing Seam application using JMeter ^[15]
• JMeter Seam cid problem ^[16]
• Injection not working with concurrent clients ^[17]
• Jmeter UDV User Defined Variable Tips and Help ^[18]