AI w JMeterze? Tak ale nie każ mu pisać XML-a

JMeter od lat jest jednym z najpopularniejszych narzędzi do testów wydajnościowych. Dla wielu zespołów QA to nadal podstawowe narzędzie do sprawdzania, czy aplikacja wytrzyma większy ruch, czy API nie zacznie się dławić i czy system zachowa stabilność pod obciążeniem. Sprawdźmy jak to najbardziej dojrzałe narzędzie pracuje z AI.

No i teraz wchodzi AI.

Naturalne pytanie brzmi: czy sztuczna inteligencja może tworzyć testy wydajnościowe w JMeterze?

Może.

Ale jest jedno duże „ale”.

Nie powinniśmy zaczynać od tego, żeby AI generowało cały plik .jmx.

Problem z JMeterem jest taki, że pod spodem jest XML

Każdy, kto pracował z JMeterem trochę dłużej, wie, że plik .jmx to tak naprawdę XML. Teoretycznie brzmi to dobrze, bo skoro to XML, to AI powinno sobie poradzić.

W praktyce bywa różnie.

JMX ma swoją specyficzną strukturę. Są tam elementy test planu, Thread Group, samplery HTTP, headery, asercje, listenery, extractory, konfiguracje CSV i cała masa elementów powiązanych ze sobą przez hashTree.

I właśnie tu zaczyna się problem.

AI potrafi wygenerować XML, który wygląda sensownie. Tylko że „wygląda sensownie” nie znaczy, że JMeter go poprawnie otworzy, uruchomi i wykona zgodnie z intencją.

Najczęstsze problemy to:

• popsuta struktura hashTree,
• brakujące elementy konfiguracyjne,
• niepoprawna kolejność elementów,
• błędne referencje do zmiennych,
• źle zbudowane extractory,
• niepoprawne asercje,
• konfiguracja, która działa w teorii, ale nie działa w JMeterze,
• test, który się uruchamia, ale nie testuje tego, co powinien.

Dlatego podejście „AI, wygeneruj mi cały JMX” jest kuszące, ale ryzykowne.

AI nie powinno generować całego JMX-a

Największy błąd to traktowanie AI jako generatora gotowego pliku .jmx.

To trochę tak, jakbyśmy prosili AI o wygenerowanie całego projektu test automation bez architektury, bez standardu, bez review i bez walidacji.

Da się? Da się.

Czy będzie stabilne? Niekoniecznie.

W przypadku JMetera lepsze podejście jest proste:

• AI nie generuje pliku JMX,
• AI generuje specyfikację testu,
• generator zamienia specyfikację na poprawny plik JMX,
• JMeter uruchamia test,
• człowiek analizuje wynik.

Czyli zamiast prosić:

Wygeneruj mi plik JMX do testu logowania.

Lepiej poprosić:

Przygotuj specyfikację testu wydajnościowego w YAML zgodnie z ustalonym schematem.

Przykład:

test_name: login_load_test
base_url: https://example.com

load_profile:
  users: 50
  ramp_up_seconds: 60
  duration_seconds: 300

requests:
  - name: Open login page
    method: GET
    path: /login
    assertions:
      - status_code: 200

  - name: Login
    method: POST
    path: /api/login
    headers:
      Content-Type: application/json
    body:
      username: ${username}
      password: ${password}
    assertions:
      - status_code: 200
      - response_time_ms_less_than: 1500

To jest dużo prostsze do kontroli.

YAML możemy zwalidować. Możemy sprawdzić, czy ma wymagane pola. Ponadto możemy wymusić standard. Możemy zablokować niepoprawne wartości.

A dopiero potem wygenerować JMX z szablonu.

Najlepsze podejście: AI + standard + generator

Jeżeli chcemy sensownie wykorzystać AI do tworzenia testów wydajnościowych w JMeterze, to potrzebujemy procesu.

Nie wystarczy sam prompt.

Proponowałbym taki model:

Wymagania / OpenAPI / HAR / opis biznesowy
        ↓
AI generuje specyfikację testu
        ↓
Walidator sprawdza jakość specyfikacji
        ↓
Generator tworzy JMX z szablonu
        ↓
Smoke test w JMeterze
        ↓
Raport i poprawki

To jest zdecydowanie bezpieczniejsze niż generowanie surowego XML-a.

AI może pomóc w wielu miejscach:

• analizie endpointów,
• przygotowaniu scenariuszy,
• rozpisaniu profilu obciążenia,
• wykryciu brakujących asercji,
• przygotowaniu danych testowych,
• zaproponowaniu korelacji tokenów,
• stworzeniu wariantów testów,
• przygotowaniu opisu testu,
• analizie wyników,
• wygenerowaniu raportu dla biznesu.

Ale AI nie powinno być jedynym źródłem prawdy.

JMeter powinien być generowany ze sprawdzonych szablonów

Najbardziej praktyczny model to szablony.

Tworzymy kilka poprawnych plików bazowych:

• prosty test HTTP GET,
• test API z POST,
• test z CSV Data Set Config,
• test z tokenem,
• test z logowaniem,
• test z korelacją danych,
• test z asercjami,
• test z raportem HTML.

Te szablony są raz przygotowane, sprawdzone i zatwierdzone.

AI nie dotyka całej struktury XML-a. AI podaje tylko dane:

• nazwę testu,
• adres bazowy,
• liczbę użytkowników,
• ramp-up,
• czas trwania,
• endpointy,
• metody HTTP,
• nagłówki,
• body,
• asercje,
• zmienne,
• extractory,
• dane CSV.

Generator bierze te dane i podstawia je do gotowego szablonu.

Dzięki temu mamy kontrolę.

I to jest kluczowe słowo: kontrola.

AI powinno pracować na kontrakcie, nie na chaosie

Jeżeli chcemy, żeby AI pomagało w testach wydajnościowych, musimy dać mu kontrakt.

Czyli na przykład:

• schemat YAML,
• przykładowe poprawne testy,
• listę dozwolonych elementów,
• zasady nazewnictwa,
• wymagane asercje,
• wymagane metryki,
• standard raportowania,
• ograniczenia techniczne.

Bez tego AI będzie „kreatywne”.

A w testach wydajnościowych nie zawsze chcemy kreatywności. Częściej chcemy powtarzalności, stabilności i porównywalnych wyników.

Dobry prompt powinien mówić jasno:

Nie generuj pliku JMX.
Nie generuj XML.
Zwróć wyłącznie YAML zgodny ze schematem.
Nie wymyślaj endpointów.
Jeżeli brakuje danych, oznacz je jako TODO.
Każdy request musi mieć asercję statusu HTTP.
Każdy krytyczny request musi mieć limit czasu odpowiedzi.
Jeżeli endpoint wymaga tokenu, dodaj extractor i użyj zmiennej w kolejnych requestach.

To zmienia sposób pracy.

AI nie jest wtedy magicznym generatorem. Jest asystentem, który działa w naszych ramach.

Co powinno być w dobrej specyfikacji testu?

Dobra specyfikacja testu wydajnościowego powinna zawierać przynajmniej:

• cel testu,
• typ testu,
• środowisko,
• adres bazowy,
• model obciążenia,
• listę scenariuszy,
• dane testowe,
• endpointy,
• korelacje,
• asercje,
• kryteria akceptacji,
• metryki do obserwacji,
• warunki przerwania testu,
• sposób raportowania.

Czyli nie tylko:

odpal 100 użytkowników.

Bo to nie jest strategia testu.

To jest tylko liczba.

Dużo ważniejsze pytania to:

• co testujemy?
• po co testujemy?
• jaki ruch symulujemy?
• jakie są scenariusze biznesowe?
• jakie są dane testowe?
• co oznacza sukces?
• co oznacza porażka?
• jakie SLA/SLO nas interesuje?
• jakie błędy są akceptowalne?
• jakie metryki zbieramy z infrastruktury?
• kto analizuje wyniki?

AI może pomóc to uporządkować, ale nie powinna zgadywać za nas kontekstu biznesowego.

Opcja alternatywna: JMeter as Code

Jest też druga droga.

Zamiast generować JMX, można pójść w kierunku JMeter as Code, na przykład z użyciem jmeter-java-dsl.

Wtedy test nie jest budowany przez ręczne klikanie w GUI ani przez generowanie XML-a, tylko przez kod.

Przykładowo:

import static us.abstracta.jmeter.javadsl.JmeterDsl.*;

public class LoginLoadTest {

    public static void main(String[] args) throws Exception {
        testPlan(
            threadGroup(50, 60,
                httpSampler("Open login page", "https://example.com/login"),
                httpSampler("Login", "https://example.com/api/login")
                    .post("{\"username\":\"${username}\",\"password\":\"${password}\"}", "application/json")
            ),
            htmlReporter("target/jmeter-report")
        ).run();
    }
}

Dla AI taki kod jest często łatwiejszy do wygenerowania niż poprawny JMX.

Mamy składnię języka. Mamy kompilację. Następnie mamy review. Mamy repozytorium. Dodatkowo mamy pull requesty. Mamy CI/CD.

To jest dużo bliższe nowoczesnemu podejściu do testów.

I tu pojawia się ciekawy kierunek:

• AI generuje kod testu,
• kod przechodzi review,
• test uruchamia się w pipeline,
• wynik trafia do raportu,
• zespół analizuje rezultat.

To jest zdecydowanie bezpieczniejsze niż losowo wygenerowany XML.

A co z GUI JMetera?

GUI nadal ma sens.

Ale nie jako docelowe miejsce uruchamiania testów obciążeniowych.

GUI jest dobre do:

• szybkiego prototypowania,
• debugowania,
• sprawdzania struktury testu,
• analizy pojedynczych requestów,
• pracy warsztatowej,
• nauki JMetera.

Natomiast realne testy powinny być uruchamiane w trybie non-GUI.

Czyli na przykład:

jmeter -n \
  -t output/login.performance.jmx \
  -l results/login.jtl \
  -e \
  -o reports/login

A wcześniej warto odpalić smoke test:

jmeter -n \
  -t output/login.performance.jmx \
  -l results/smoke.jtl \
  -Jusers=1 \
  -Jduration=30

To powinien być stały element procesu.

Najpierw mały test techniczny. Dopiero potem większy test wydajnościowy.

AI może też pomagać po teście

Bardzo często skupiamy się na generowaniu testów, a zapominamy, że AI może być bardzo pomocne również po wykonaniu testu.

Może pomóc w analizie:

• błędów HTTP,
• percentyli,
• czasu odpowiedzi,
• throughputu,
• liczby requestów,
• anomalii,
• trendów między testami,
• regresji wydajnościowej,
• różnic między środowiskami.

Może też przygotować różne wersje raportu:

• techniczną dla zespołu,
• menedżerską dla liderów,
• biznesową dla klienta,
• krótkie podsumowanie do Jiry,
• rekomendacje do backlogu.

I tu AI może dać dużą wartość, bo analiza wyników często jest trudniejsza niż samo uruchomienie testu.

Gdzie AI może realnie przyspieszyć pracę?

Największy sens widzę w kilku obszarach:

• generowanie scenariuszy testowych,
• analiza OpenAPI,
• analiza HAR,
• przygotowanie danych testowych,
• korelacja,
• asercje,
• raportowanie.

Generowanie scenariuszy testowych

Na podstawie opisu biznesowego AI może zaproponować scenariusze:

• logowanie,
• wyszukiwanie,
• dodanie produktu do koszyka,
• płatność,
• pobranie listy danych,
• zapis formularza,
• generowanie raportu.

Oczywiście człowiek musi to zweryfikować.

Analiza OpenAPI

Jeżeli mamy dokumentację OpenAPI, AI może pomóc wykryć endpointy krytyczne i zaproponować scenariusze API.

To może być bardzo dobry punkt startowy, szczególnie wtedy, gdy zespół ma dużo endpointów i nie wie, od czego zacząć.

Ale nadal trzeba pamiętać, że nie każdy endpoint z OpenAPI powinien trafić do testu wydajnościowego.

Nie testujemy wszystkiego tylko dlatego, że istnieje.

Testujemy to, co ma znaczenie dla użytkownika, procesu biznesowego i stabilności systemu.

Analiza HAR

Możemy nagrać ścieżkę użytkownika w przeglądarce, wyeksportować HAR i użyć AI do opisania scenariusza.

Ale znowu – nie chodzi o bezmyślne przepisanie wszystkich requestów.

Chodzi o wybranie tego, co ma sens w teście wydajnościowym.

W HAR znajdziemy dużo zasobów statycznych, requestów pomocniczych, analyticsów i rzeczy, które nie zawsze powinny być częścią scenariusza w JMeterze. Ja zawszę mówię, że takie pliki trzeba bardzo mocno oczyścić by były zdatne do użycia.

AI może pomóc w selekcji, ale ktoś musi zadać pytanie:

Czy ten request naprawdę jest istotny dla scenariusza?

Dane testowe

AI może pomóc przygotować strukturę danych CSV:

username,password
user1,password1
user2,password2
user3,password3

Może też wskazać, gdzie dane muszą być unikalne, a gdzie mogą być współdzielone.

To ważne, bo źle przygotowane dane potrafią zepsuć cały test.

Możemy myśleć, że testujemy wydajność systemu, a tak naprawdę testujemy blokady na danych, konflikty użytkowników albo walidacje biznesowe.

Korelacja

AI może pomóc wskazać, że token z odpowiedzi logowania powinien zostać wyciągnięty i użyty w kolejnych requestach.

Na przykład:

Z odpowiedzi POST /login pobierz $.token i zapisz jako authToken.
W kolejnych requestach użyj nagłówka Authorization: Bearer ${authToken}.

To jest jeden z tych obszarów, gdzie początkujący użytkownicy JMetera często mają problem.

Test działa dla jednego requestu.

Ale kiedy trzeba obsłużyć token, session id, csrf, dynamiczne id obiektu albo dane z poprzedniej odpowiedzi, zaczyna się realna zabawa.

AI może pomóc to opisać i zaproponować kierunek, ale sam mechanizm nadal trzeba dobrze rozumieć.

Asercje

AI może podpowiedzieć, że nie wystarczy sprawdzić status 200.

Warto też sprawdzać:

• czas odpowiedzi,
• obecność konkretnego pola,
• brak błędów,
• poprawność response body,
• wartość biznesową,
• brak komunikatu błędu.

Bo status 200 nie zawsze oznacza, że wszystko działa.

Aplikacja może zwrócić 200 i jednocześnie pokazać błąd biznesowy, pustą listę, niepoprawny komunikat albo odpowiedź, która nie ma żadnej wartości dla użytkownika.

Dlatego asercje w testach wydajnościowych są tak samo ważne jak w testach funkcjonalnych.

Raportowanie

AI może pomóc przygotować zrozumiałe podsumowanie wyników, na przykład:

Test wykazał wzrost czasu odpowiedzi dla endpointu /api/orders przy obciążeniu 100 użytkowników. Percentyl 95 przekroczył ustalony próg 1500 ms. Rekomendowana jest analiza zapytań bazodanowych oraz cache dla listy zamówień.

To jest dużo bardziej wartościowe niż samo wrzucenie wykresów bez interpretacji.

W testach wydajnościowych raport bez wniosków jest tylko zbiorem obrazków.

Dobry raport powinien odpowiadać na pytania:

• czy system spełnił założenia?
• gdzie pojawiły się problemy?
• przy jakim obciążeniu wystąpiła degradacja?
• które endpointy były najwolniejsze?
• czy błędy były incydentalne, czy systemowe?
• co rekomendujemy dalej?

AI może pomóc w przygotowaniu takiego opisu, ale dane wejściowe muszą być dobre.

Jak bym to wdrożył w organizacji?

Nie zaczynałbym od wielkiego frameworka.

Zacząłbym od małego standardu.

Na przykład:

performance-tests/
│
├── specs/
│   └── login.performance.yaml
│
├── templates/
│   ├── basic-api.jmx.tpl
│   ├── api-with-auth.jmx.tpl
│   └── api-with-csv.jmx.tpl
│
├── schemas/
│   └── performance-test.schema.json
│
├── output/
│   └── login.performance.jmx
│
├── results/
│   └── login.jtl
│
├── reports/
│   └── login/
│
└── prompts/
    └── jmeter-ai-generation.md

Gdzie w tym wszystkim jest człowiek?

To jest bardzo ważny temat.

Bo kiedy mówimy o AI w testach, łatwo wpaść w narrację, że teraz narzędzie zrobi wszystko.

Nie zrobi.

AI może wygenerować propozycję testu, ale człowiek musi zadać właściwe pytania:

• czy ten test ma sens?
• czy profil obciążenia jest realistyczny?
• czy środowisko testowe nadaje się do pomiaru?
• czy dane są poprawne?
• czy wyniki są wiarygodne?
• czy system naprawdę ma problem, czy problem jest w samym teście?
• czy mierzymy to, co chcemy mierzyć?

I właśnie tutaj doświadczenie testera wydajnościowego jest nadal kluczowe.

AI może przyspieszyć pracę, ale nie zastąpi myślenia.

Może pomóc w tworzeniu, ale nie zdejmie z nas odpowiedzialności za jakość testu.

Kurs JMeter PRO

Jeżeli ktoś chce dobrze korzystać z AI w JMeterze, to najpierw musi rozumieć samego JMetera.

Dlatego powstał mój kurs JMeter PRO.

Kurs premium JMeter i testy wydajnościowe od podstaw – ponad 160 lekcji

To nie jest kurs o samym klikaniu po narzędziu. To kurs o tym, jak projektować testy wydajnościowe, które mają sens techniczny i biznesowy.

W kursie pokazuję między innymi:

• jak budować scenariusze testów,
• jak pracować z danymi testowymi,
• jak obsługiwać logowanie i tokeny,
• jak tworzyć asercje,
• jak uruchamiać testy w trybie non-GUI,
• jak generować i analizować raporty,
• jak unikać typowych błędów w JMeterze.

W kontekście AI to szczególnie ważne.

AI może wygenerować propozycję testu, ale ktoś musi ocenić, czy ten test jest poprawny. Czy model obciążenia ma sens. Czy dane są dobrze przygotowane. Ponadto czy asercje faktycznie coś sprawdzają. Czy wynikowi można zaufać.

JMeter PRO traktuję więc jako fundament.

Najpierw warto zrozumieć narzędzie i dobre praktyki testów wydajnościowych. Dopiero potem dokładać AI, generatory, szablony i automatyzację.

Kurs premium JMeter i testy wydajnościowe od podstaw – ponad 160 lekcji

Najważniejsza zasada

AI w testach wydajnościowych z JMeterem ma sens, ale tylko wtedy, kiedy działa w ramach procesu.

Bez procesu dostaniemy losowy XML, który raz zadziała, a raz nie.

Z procesem dostajemy coś dużo lepszego:

• szybsze tworzenie testów,
• spójny standard,
• mniej błędów technicznych,
• lepszą jakość scenariuszy,
• łatwiejsze utrzymanie,
• większą powtarzalność,
• możliwość pracy w CI/CD,
• lepsze raportowanie.

Dlatego moja rekomendacja jest prosta:

Nie używaj AI do generowania JMX-a od zera. Używaj AI do generowania specyfikacji testu, a JMX buduj z walidowanych szablonów.

To jest podejście, które łączy szybkość AI z kontrolą inżynierską.

A w testach wydajnościowych kontrola jest ważniejsza niż magia.

Realna klasa testowa

Na kanwie tej klasy testowej (wygenerowanej przez AI) – dokonałem uruchomienia testów i mamy rezultat.

Podsumowanie

AI może bardzo mocno pomóc przy tworzeniu testów wydajnościowych w JMeterze. W standardowym podejściu – nadaje się do tworzenia skryptów w Groovie. Teraz wchodzi JMeter – DSL.

Ale nie powinniśmy oddawać mu całego procesu.

Najlepszy model to:

AI przygotowuje specyfikację.
Walidator sprawdza poprawność.
Generator tworzy JMX.
JMeter wykonuje test.
Człowiek analizuje wynik.
AI pomaga przygotować raport.

To jest rozsądny kompromis między automatyzacją a jakością.

Bo celem nie jest to, żeby AI wygenerowało nam cokolwiek.

Celem jest to, żeby szybciej tworzyć dobre, powtarzalne i wartościowe testy wydajnościowe.

A jeżeli chcesz wejść w ten temat porządnie, to zacznij od fundamentów.

Naucz się JMetera.

Zrozum scenariusze. Posiadaj dane testowe. Zrozum asercje. Wiedz jak interpretować raporty. Zrozum, co oznacza dobry wynik testu.

I dopiero wtedy wykorzystuj AI jako przyspieszenie, a nie jako zamiennik myślenia.

Właśnie po to powstał JMeter PRO — żeby pomagać budować testy wydajnościowe świadomie, praktycznie i z sensem.