Bejelentkezés

Kategória: Tesztelés

  • Lista az aktuális API tesztelői eszközökről

    Be kell vallanom, hogy alapvetően Postman fan vagyok. Szerintem irtó sok dolgot meg lehet benne valósítani, folyamatokat építeni, és mióta lehet AI-t kérdezni, egy-egy bonyolultabb feladat is játszi könnyedséggel megoldható vele. A gond – mármint nem nekem, hanem a cégeknek – hogy fizetni valahogy senki sem szeretne érte, illetve annyira féltik az adataikat, hogy a fizetős, felhős szolgáltatást kerülik. Nem mintha nem lenne más eszköz, ami simán adatszivárgásra adhatna okot. Na mindegy.

    Szóval megkértem az AI-t, hogy csináljon nekem egy listát az ismertebb eszközökről, ami segíthet választani a munkához, ha szükséges.

    Az API-tesztelő eszközök piaca az elmúlt években jelentősen átalakult. Míg korábban a Postman szinte egyeduralkodó volt, a kötelező felhős szinkronizáció és a szigorúbb ingyenes korlátok miatt előtérbe kerültek a pehelykönnyű, lokalitást és Git-alapú verziókövetést előnyben részesítő alternatívák (pl. Bruno, Thunder Client).

    Az alábbi összehasonlítás a legnépszerűbb eszközök előnyeit és hátrányait mutatja be.

    1. Postman

    Kinek ajánlott?Közepes és nagy csapatoknak, vállalati környezetbe, ahol teljes API életciklus-kezelésre és CI/CD automatizációra van szükség.

    • Pro (Előnyök):
      • Sokoldalú ökoszisztéma: Támogatja a REST, GraphQL, gRPC, WebSocket és SOAP protokollokat is.
      • Fejlett funkciók: Beépített Mock Serverek (szimulált végpontok), automatikus dokumentáció-generálás és API monitoring.
      • Newman CLI: Kiválóan integrálható CI/CD folyamatokba a tesztek automatikus futtatásához.
      • Erős csapatmunka: Megosztott munkaterek, szerepkörök (RBAC), kommentelés és változáskövetés.
    • Kontra (Hátrányok):
      • Erőforrás-igényes: Az Electron-alapú alkalmazás lassú lehet, és sok memóriát (RAM) fogyaszt.
      • Kötelező felhő / fiók: Az ingyenes verzióban a kollekciók jelentős része a cloudba kerül, a helyi (offline) használat erősen korlátozott.
      • Bonyolultság: A sok funkció miatt a felület túlzsúfolt lehet egyszerű napi feladatokhoz.

    2. Insomnia (by Kong)

    Kinek ajánlott?Fejlesztőknek és kisebb csapatoknak, akik letisztultabb UI-t és OpenAPI / GraphQL fókuszt keresnek.

    • Pro (Előnyök):
      • Letisztult UI: Gyorsabb és sokkal átláthatóbb felület, mint a Postmané.
      • Kiváló GraphQL támogatás: Elsőrangú intellisense, autokiegészítés és séma-feltérképezés.
      • Design-first megközelítés: Kiváló OpenAPI / Swagger specifikációk írására és tesztelésére egy helyen.
      • Native Git Sync: Közvetlenül szinkronizálható Git tárhelyekkel (GitHub, GitLab).
    • Kontra (Hátrányok):
      • Nincs beépített Mock Server: Hiányoznak a Postman-féle szimulált szerver funkciók.
      • Kisebb ökoszisztéma: Kevesebb beépített integráció és közösségi dokumentáció.
      • Változó üzleti modell: A korábbi kötelező regisztrációs döntéseik miatt a közösség egy része elvesztette benne a bizalmát (noha a local mode-ot azóta visszahozták).

    3. Bruno

    Kinek ajánlott?Git-központú fejlesztőknek, akik offline, gyors és teljesen helyi adattárolást szeretnének cloud kényszer nélkül.

    • Pro (Előnyök):
      • Git-native (Plain Text): A kollekciókat sima fájlokként (.bru formátum) tárolja a projekt saját mappa-struktúrájában, így a tesztek a kód mellett, Pull Request-ekben verziózhatók.
      • Teljesen offline & adatvédelem: Nincs cloud szinkronizáció, az adatok soha nem hagyják el a gépedet.
      • Rendkívül gyors és könnyű: Minimális erőforrást fogyaszt és pillanatok alatt elindul.
      • Open Source: Nyílt forráskódú, átlátható működésű eszköz.
    • Kontra (Hátrányok):
      • Hiányzó komplex szolgáltatások: Nincs hosted dokumentáció, mock server vagy felhős monitoring.
      • Grafikus csapatmunka hiánya: Nincsenek felhős kattintgatós workspace-ek (a csapatmunka a Git folyamatokra támaszkodik).

    4. Thunder Client (VS Code kiterjesztés)

    Kinek ajánlott?Azoknak a fejlesztőknek, akik VS Code-ban dolgoznak, és nem akarnak külön alkalmazást nyitni egy-egy API híváshoz.

    • Pro (Előnyök):
      • Beépül a szerkesztőbe: Közvetlenül a VS Code-on belül fut, nem kell váltgatni az ablakok között.
      • Gyors kontextus-váltás: Fejlesztés közben azonnal tesztelhető az épp megírt végpont.
      • Helyi tárolás: A tesztkollekciók a munkatér részeként elmenthetők JSON-ban.
    • Kontra (Hátrányok):
      • Korlátozott funkciók: Összetett scriptekre, bonyolult teszt-assert-ökre vagy terheléstesztre nem alkalmas.
      • Zárt ökoszisztéma: Csak VS Code alatt érhető el.
      • Fizetős korlátok: A haladóbb funkciókért már a Pro verzióra van szükség.

    5. HTTPie (GUI & CLI)

    Kinek ajánlott? Fejlesztőknek, akik szeretik a szintaxis-kiemeléssel ellátott, humán-barát terminálos vagy egyszerű felületes tesztelést.

    • Pro (Előnyök):
      • Emberi szintaxis: A curl-nál nagyságrendekkel egyszerűbb, olvashatóbb parancssori szintaxis.
      • Gyönyörű kimenet: Automatikus JSON formázás és színkiemelés a terminálban.
      • Asztali GUI is elérhető: Szép, modern grafikus felülettel is rendelkezik.
    • Kontra (Hátrányok):
      • Bonyolult automatizált teszt-suite-ok felépítésére és nagy vállalati projektekre kevésbé ideális.

    Összefoglaló összehasonlító táblázat

    EszközAdattárolásGit integrációBonyolultságLegfőbb erőség
    PostmanCloud-firstManuális / ExportMagasTeljes API életciklus & Mock-ok
    InsomniaHelyi + CloudNatív GitKözepesTisztaság & OpenAPI / GraphQL
    Bruno100% HelyiNatív (Plain text)AlacsonyAdatvédelem, sebesség, Git-alap
    Thunder ClientHelyi JSONProjekt fájlkéntAlacsonyVS Code-ba épített kényelem

    Összegzésként: Ha nagy csapatban dolgoztok és kell a Mock Server meg a felhős dokumentáció, a Postman a biztos választás. Ha a kód mellett szeretnétek tartani a teszteket felhős függőség nélkül, a Bruno a jelenlegi legnépszerűbb alternatíva. Ha pedig GraphQL-t használtok vagy a letisztult UI a fontos, az Insomnia a nyerő.

    És ha már itt tartunk, akkor megint egy típikus interjú kérdés az API téma.

    Az API-kat (Application Programming Interface) többféle szempont szerint csoportosíthatjuk: hozzáférhetőség, architekturális stílus/protokoll, valamint funkció/felhasználási terület alapján.

    Íme a legfontosabb kategóriák és típusaik:

    1. Hozzáférhetőség (Láthatóság) alapján

    Ez a csoportosítás azt határozza meg, hogy kik és hogyan érhetik el az API-t.

    • Privát (Belső / Internal) API-k:
      • Cél: Egy szervezet belső rendszereinek és microservice-einek egymás közötti kommunikációja.
      • Jellemzőjük: Rejtve vannak a külvilág elől, magasabb biztonsági zónában futnak (pl. vállalatirányítási rendszerek és a belső adatbázisok között).
    • Partner API-k:
      • Cél: Meghatározott üzleti partnerek közötti adatcserére szolgálnak.
      • Jellemzőjük: Nem nyilvánosak, egyedi regisztrációhoz, B2B megállapodásokhoz és szigorú hitelesítéshez (API kulcsok, OAuth) kötöttek (pl. logisztikai cégek csomagkövető rendszerei a webáruházak felé).
    • Nyilvános (Public / Open) API-k:
      • Cél: Bárki által elérhető végpontok külső fejlesztők számára.
      • Jellemzőjük: Gyakran ingyenesek vagy freemium modellben működnek (pl. időjárás-előrejelzések, OpenStreetMap).
    • Kompozit (Composite) API-k:
      • Cél: Több különböző szolgáltatás vagy adatforrás egyetlen hívásból történő elérése.
      • Jellemzőjük: Csökkentik a hálózati terhelést azzal, hogy a kliensnek nem kell 5 külön hívást indítania, hanem egyetlen összetett válaszban kapja meg az adatokat.

    2. Architekturális stílus és protokoll alapján

    Ez határozza meg az adatáramlás formátumát és a kommunikáció szabályait.

    • REST (Representational State Transfer):
      • Működés: A legelterjedtebb webes API architektúra. A meglévő HTTP metódusokra (GET, POST, PUT, DELETE) épül, leggyakrabban JSON formátumban kommunikál.
      • Előny: Skálázható, egyszerű, állapotmentes (stateless).
    • GraphQL:
      • Működés: A Facebook által kifejlesztett lekérdezőnyelv. A kliens hajszálpontosan meghatározza, milyen adatokra van szüksége egyetlen kérésben.
      • Előny: Megszünteti az under-fetching (kevés adat) és over-fetching (feleslegesen sok adat) problémáját.
    • SOAP (Simple Object Access Protocol):
      • Működés: Szigorú protokoll, amely kizárólag XML formátumot használ, és a WSDL leírófájlokra támaszkodik.
      • Előny: Magas szintű beépített biztonság (WS-Security) és tranzakciókezelés. Gyakran használják banki és vállalati környezetben.
    • gRPC (Google Remote Procedure Call):
      • Működés: A Google által fejlesztett, Protocol Buffers (Protobuf) bináris formátumot és HTTP/2-t használó keretrendszer.
      • Előny: Rendkívül gyors, kis méretű adatcsomagok, ideális microservice-ek közötti nagy sebességű kommunikációra.
    • WebSocket & Server-Sent Events (SSE):
      • Működés: Kétirányú (WebSocket) vagy egyirányú (SSE) valós idejű kommunikációs csatornák.
      • Előny: Nem kell folyamatosan újra lekérdezni a szervert (polling); tökéletes chat-alkalmazásokhoz, élő tőzsdei adatokhoz és sporteredményekhez.

    3. Funkció és felhasználási terület alapján

    • Web API-k: A fent részletezett HTTP-alapú interfészek (REST, GraphQL stb.).
    • Operációs rendszer (OS) API-k: Lehetővé teszik a szoftverek számára a hardver és az OS szolgáltatásainak elérését (pl. Windows Win32 API, POSIX, Android Camera API).
    • Könyvtár- és keretrendszer (Library) API-k: A kód szintjén biztosítanak interfészt egy adott nyelvhez vagy csomaghoz (pl. React API, Java Standard Library API).
    • Adatbázis API-k: Alkalmazások és adatbázis-kezelők közötti kommunikációra szolgálnak (pl. JDBC, ODBC).

  • Felfedező tesztelés AI-val

    Egyre lustább vagyok, és az idő is nagy ellenség lett a munkában, így sok esetben jól tud jönni az extra segítség, amit manapság AI formájában kaphatunk meg. Én személy szerint nagyon sok szakmai témában konzultálok vele, mielőbb neki kezdenek, de vannak olyan témák is, amiről kevés információm van, csak hallottam valahol, így időm engedtével rákeresek. Ilyen az AI-val történő exploratory tesztelés is.

    Az exploratory testing (magyarul felfedező tesztelés) a szoftvertesztelés egy olyan megközelítése, ahol a tesztek megtervezése, végrehajtása és a szoftver megismerése egyszerre, párhuzamosan történik.

    A hagyományos (szkriptelt) teszteléssel ellentétben – ahol a tesztelő előre megírt, lépésről lépésre követendő teszteseteket (test cases) hajt végre – a felfedező tesztelésnél a tesztelő a saját intuitív tudására, domain-ismeretére, tapasztalatára és kíváncsiságára támaszkodik.

    A felfedező tesztelés fő jellemzői:

    1. Szabadság és rugalmasság: Nincsenek szigorúan előre leírt tesztlépések. A tesztelő menet közben dönt arról, hogy az alkalmazás melyik részét milyen irányban vizsgálja tovább, reagálva a szoftver tényleges viselkedésére.
    2. Tanulás és alkalmazkodás: Ahogy a tesztelő használja a szoftvert, egyre jobban megérti annak működését és gyenge pontjait. Ha a szoftver egy ponton gyanúsan viselkedik, a tesztelő azonnal mélyebbre áshat abban a témában.
    3. Kreativitás és hibatalálgatás (Error Guessing): Olyan egyedi, nem szokványos felhasználói útvonalakat és szélsőséges eseteket (edge case-eket) igyekszik feltárni, amelyekre a fejlesztők vagy a specifikációt írók nem gondoltak.
    4. Alacsony előkészítési igény: Mivel nem kell előre bonyolult tesztdokumentációt írni, nagyon gyorsan elindítható, így ideális agilis (Agile/Scrum) környezetben.

    Mit nem jelent az exploratory tesztelés?

    • Nem ad-hoc kattintgatás („monkey testing”): A felfedező tesztelés nem céltalan próbálkozás. Bár nincs előre megírt forgatókönyv, a tesztelőnek világos célja és stratégiája van.
    • Célzott keretek (Session-Based Testing): A gyakorlatban a felfedező tesztelést gyakran strukturált keretek között végzik:
      • Charter (Küldetés): Meghatározzák a tesztelés célját (pl. „Fedezd fel a fizetési folyamatot a lejárt bankkártyák kezelésének szempontjából”).
      • Időkeret (Time-box): A tesztelést egy rögzített idősávra korlátozzák (pl. 60–90 perc).
      • Jegyzőkönyv / Összefoglaló: A tesztelő rögzíti, mit tapasztalt, milyen problémákat talált és merre érdemes tovább kutatni.

    Összességében a felfedező tesztelés nem a szkriptelt vagy automatizált tesztek helyettesítője, hanem azok kiegészítője: az automatizált tesztek ellenőrzik, hogy a már meglévő funkciók működnek-e, míg a felfedező tesztelés segít megtalálni az új, váratlan hibákat.

    Az exploratory (felfedező) tesztelés természeténél fogva egy ember-központú, kreatív folyamat, ahol a tesztelő intuíciója, domain-ismerete és kíváncsisága vezet. Az AI itt nem a tesztelőt váltja fel, hanem hihetetlenül hatékony asszisztensként (co-pilot) működik, amely leveszi a válláról a monoton feladatokat, és új, nem várt tesztforgatókönyveket javasol.

    Mivel hallottam róla, hogy vannak, akik AI segítéséggel csinálják ezt, megkérdeztem az AI-t, hogy mit tud róla, és kaptam is egy listát. Ahogy lesz időm, kedvem, bele fogom ásni magam a témába.

    Addig is itt a válasz a Gemini-től:

    Az AI-alapú exploratory tesztelés megközelítései és eszközei méret és cél szerint három fő kategóriába oszthatók:

    1. AI-alapú Böngésző- és Autonóm Tesztelő Ügynökök (Autonomous AI Testing Agents)

    Ezek az eszközök képesek önállóan „bejárni” a webalkalmazásokat, feltérképezni a felületet, hibákat keresni, és közben segítik a felfedezést.

    • Open-source / DIY megközelítés (Playwright + LLM-alapú keretrendszerek):
      • Stagehandvagy Browser-use / Explorbot: Ezek modern, nyílt forráskódú keretrendszerek, amelyek ráköthetők a nagyobb nyelvi modellekre (pl. Claude vagy GPT). Természetes nyelven vagy célok megadásával (pl. „Keresd meg az űrlapon a hiányzó validációkat”) képesek irányítani a böngészőt, elemezni a DOM-ot, és olyan edge case-eket (szélsőséges eseteket) is letesztelni, amiket egy hagyományos script nem érne el.
    • Kereskedelmi platformok (Mabl, Functionize, Testim):
      • Ezekben az AI-alapú platformokban van ún. Agentic vagy intelligens felfedező funkció is.Amikor új funkciót raksz ki, az AI képes önállóan „körbejárni” az oldalt, vizuális anomáliákat és hibaüzeneteket keresni a konzolon, így támogatva az exploratory tesztelési fázist.

    2. AI Asszisztensek és Teszttervező Co-pilotok (Ötleteléshez és Charterekhez)

    Ha hagyományos, session-based exploratory tesztelést (SBET) csinálsz, az AI kiválóan használható partnerré válik a tesztelési „charterek” és ötletek generálásában.

    • ChatGPT / Claude / Cursor (Prompt alapú teszttervezés):
      • Hogyan használd? Másold be egy új funkció specifikációját vagy user story-ját, és kérd meg az AI-t: „Készíts nekem 5 darab exploratory testing charter-t a Boundary Value Analysis (határérték-elemzés) és a Error Guessing (hibatalálgatás) heurisztikái alapján erre a funkcióra.”
      • Segít feltárni olyan logikai vakfoltokat, amikre fejlesztőként vagy tesztelőként nem gondoltál volna.

    3. Vizuális és Interaktív AI Eszközök

    • Applitools (Eyes):
      • Exploratory tesztelés közben a legnagyobb ellenség a vizuális hiba, ami elkerüli a figyelmet. Az Applitools AI-alapú vizuális motorja azonnal észleli a renderelési hibákat, elcsúszásokat bármilyen eszközön, miközben te szabadon kattintgatsz és tesztelsz.

    Mit érdemes választani?

    1. Ha gyorsan és olcsón akarsz egyedi megoldást: Használj LLM alapú szkripteket / open-source keretrendszereket (Stagehand vagy custom Playwright szkriptek AI integrációval), amikkel autonóm módon át tudod vizsgáltatni a felületet.
    2. Ha strukturált, emberi exploratory tesztelést végzel: Használj AI-t (Claude/GPT) ötletgenerálásra és kockázatelemzésre a tesztelés előtt (hová érdemes kaparni, milyen inputokat próbálj ki), majd a session végén rögzítsd a tapasztalatokat egy Test Management eszközben (pl. Xray vagy TestRail), ahol az AI összefoglalja a bug riportokat.
  • JMeter – 50.000 virtuális user

    JMeter – 50.000 virtuális user

    Megkérdeztem a Gemini-t, hogy megoldható-e, és ha igen, hogyan egy 50.000 useres performancia tesztelés az Apache JMeter-rel. A válasz itt következik:

    Igen, teljesen megoldható, de van egy kritikus technikai feltétel: egyetlen gépről (például egy laptopról vagy egyetlen virtuális gépről) nem lehet elindítani 50 000 egyidejű felhasználót, mert a hardveres korlátok (CPU, RAM, hálózati socketek kimerülése) miatt maga a tesztelő eszköz fog összeomlani. Ehhez elosztott (distributed) architektúrára vagy felhőalapú futtatásra lesz szükség.

    Így kezdenék neki lépésről lépésre:

    1. Célok és workload modell tisztázása

    • Pontosan mit jelent az 50 000 user? 50 000 egyidejűleg aktív felhasználó, akik folyamatosan kattintgatnak, vagy 50 000 egyidejű kapcsolat (session), de az aktivitásuk eloszlik?
    • Milyen a felhasználói útvonal (User Journey)? Nem mindegy, hogy csak a főoldalt hívják le (ez könnyű), vagy bejelentkeznek, keresnek, terméket raknak a kosárba és fizetnek (ez bonyolultabb, adatbázis- és tranzakcióigényes).
    • Milyen mérőszámokat vársz el? (pl. 95%-os válaszidő 2 másodperc alatt, 0% hibaarány mellett).

    2. A tesztinfrastruktúra felépítése (Distributed JMeter)

    Mivel egy átlagos JMeter worker gép maximum 1000–2000 szálat bír stabilan, 50 000 userhez 25-50 darab worker gépre lesz szükség:

    • Master-Worker (Slave) felállás: Egy központi JMeter Master irányítja a tesztet, és gyűjti az adatokat a worker gépekről (ezek lehetnek olcsó AWS EC2 instance-ok vagy Docker konténerek).
    • Alternatíva: Használhatsz dedikált terheléses felhőszolgáltatásokat is (pl. BlazeMeter), amelyek mögött ugyanez az elv fut, de nem kell manuálisan menedzselni a 30-40 szervert.

    3. A JMeter script megírása

    • Thread Group beállítások: A 50 000 szálat érdemes fokozatosan ráengedni a rendszerre (Ramp-up period, pl. 30–45 perc alatt), hogy látsd, hol kezd el lassulni a rendszer.
    • Valósághű viselkedés: Használj Think Time-ot (szüneteket a kérések között), különben a szkript robotként viselkedik, amit egy WAF (Web Application Firewall) vagy cache réteg azonnal blokkolhat.
    • Dinamikus adatok:CSV Data Set Config segítségével biztosítsd, hogy a felhasználók különböző nevekkel, jelszódal vagy tokenekkel jelentkezzenek be, ne ugyanazzal az egy fiókkal indítsa mind az 50k szál a kérést.

    4. Szerveroldali monitorozás bekötése (Monitoring)

    A JMeter csak azt mutatja meg, mit tapasztal a felhasználó (válaszidő, hiba), azt nem, hogy miért lassult be a szerver. Ehhez kell a backend monitoring:

    • Alkalmazásszerverek, adatbázisok, cache (Redis) CPU, RAM és I/O terhelésének figyelése (pl. Prometheus + Grafana vagy Datadog).
    • Adatbázis lassan futó lekérdezéseinek és connection pool telítettségének mérése.

    5. Tesztfutás és finomhangolás

    • Soha ne használd a JMeter GUI-t (grafikus felületet) terheléses teszt alatt! Csak parancssorból, non-gui módban futtasd a master gépet.
    • Fokozatosság elve: Ne 50 000 userrel kezdd. Először futtass le egy 1000 useres tesztet, javítsd ki az azonnal előjövő hibákat, majd skálázd fel 5000-re, 10 000-re, és így tovább, ambron eléred a célt.

    Milyen típusú rendszert (pl. webshop, REST API, banki backend) kell tesztelni, és milyen környezetben fut jelenleg?

    Egy REST API terheléses tesztelése 50 000 felhasználóval specifikus technikai kihívásokat rejt, amelyekre különösen figyelned kell a JMeter konfigurálása során:

    1. Hitelesítés és token-kezelés (Authentication)

    A REST API-k túlnyomó többsége token alapú (JWT vagy OAuth2).

    • Ne kérj le tokent minden egyes kérésnél: Ha mind az 50 000 szál a POST /api/login végponttal kezdi a tesztet, azzal azonnal túlterheled a hitelesítőszervert, még mielőtt a valódi API funkciókat tesztelnéd.
    • Megoldás: Előre generálj le egy token-készletet (pl. egy külön scripttel vagy adatbázis-lekérdezéssel), töltsd be egy CSV fájlba, és a JMeterben ezt olvastasd be. Így a felhasználók már eleve érvényes tokenekkel küldhetik a kéréseket.

    2. HTTP Request Defaults és Keep-Alive

    Magas koncurrencia esetén kritikus a hálózati kapcsolatok hatékonysága:

    • HTTP Request Defaults: Állítsd be a központi URL-t, portot és a Content-Type-ot (application/json), hogy ne kelljen minden egyes kérésnél megismételni.
    • Keep-Alive: A JMeter alapértelmezésben engedélyezi a Keep-Alive-ot. REST API-knál ez elengedhetetlen, mert így nem nyit és zár le TCP kapcsolatot minden egyes apró API híváshoz, ami drasztikusan csökkenti a hálózati terhelést a kliens oldalon, és valósághűbb képet ad a szerver teljesítményéről.

    3. Dinamikus adatok és JSON Extractor

    Egy REST API láncolt hívásokból áll (pl. létrehozol egy erőforrást POST-tal, majd annak az ID-jét lekéred GET-tel).

    • Használj JSON Extractor elemet a válaszokból (pl. létrehozott objektum ID-je, státusza) való adatkigyűjtésre.
    • Ezeket az értékeket mentsd el JMeter változókba (${id}), hogy a következő kérésben dinamikusan fel tudd használni.

    4. Payload (Adatcsomag) optimalizálás

    • Ha a tesztben nagy JSON payloadokat küldesz (pl. tömeges adatfeltöltés), kerüld a bonyolult, dinamikusan generált szövegeket a JMeter belső függvényeivel, mert az leterheli a JMeter saját CPU-ját.
    • A tesztadatokat (JSON törzseket) előre generált fájlokból (CSV vagy JSON file) olvasd be, így a worker gépek erőforrásai tisztán a hálózati kérésekre fognak fókuszálni.

    5. Válaszidő és aszinkronitás

    • Határozd meg, hogy az API-n belül vannak-e aszinkron műveletek (pl. üzenetssorba, RabbitMQ-ba vagy Kafka-ba küldött események). Ha igen, a válaszidő alacsony lehet (mert a szerver csak átvette az üzenetet), de a valódi feldolgozást a háttérben lévő worker service-eknek kell bírniuk, így a monitoringot kötelező kiterjeszteni a háttérfolyamatokra is.

    Szerintem elég jól megválaszolta a kérdést. Egy részével tisztában voltam, sejtettem, de akadt jó pár jó tanács is. Gondoltam megkérdezem, hogy JMeteren kívül milyen mást eszközt ajánlana ehhez.

    Ha a JMeter elosztott architektúrájának (a 25-50 worker gépnek a) manuális konfigurálása és karbantartása túl bonyolultnak tűnik, a modern teljesítménytesztelő eszköztárban kifejezetten REST API-khoz sokkal gördülékenyebb megoldások is léteznek:

    1. k6 (Grafana k6) – A legjobb választás REST API-khoz

    A k6 jelenleg a legnépszerűbb fejlesztőbarát alternatíva. C-ben íródott (Go runtime-mal), így nagyságrendekkel kevesebb memóriát és CPU-t fogyaszt, mint a Java-alapú JMeter.

    • Miért ideális 50k userhez? Egyetlen erősebb szerverről lényegesen több szálat (virtuális usert) tud futtatni, mint a JMeter, így kevesebb infrastruktúrára lesz szükséged.
    • Szkriptelés: JavaScriptben írod a teszteket, ami nagyon természetes a REST API JSON válaszok és dinamikus tokenek kezelésénél.
    • Integráció: Kiemelkedően jó Grafana, Prometheus és CI/CD (GitHub Actions, GitLab) támogatása van.

    2. Gatling – Ha elképesztő skálázhatóságra és szép riportokra van szükség

    A Gatling aszinkron (Netty-alapú) architektúrát használ, így nem rendel egy külön operációs rendszer szálat minden egyes felhasználóhoz.

    • Miért ideális 50k userhez? Brutálisan jó az erőforrás-kihasználása. Egyetlen közepes gépről képes több tízezer egyidejű kapcsolatot felépíteni és kezelni.
    • Szkriptelés: Scala, Java vagy Kotlin nyelven írhatsz szép, olvasható domain-specifikus kódot (DSL).
    • Riportok: Alapból nagyon részletes és vizuálisan tetszetős HTML riportokat generál a teszt végén.

    3. Locust – Ha Python-alapú veremből dolgozol

    A Locust egy nyílt forráskódú, Python-alapú tesztelőeszköz, ahol a felhasználói viselkedést tiszta Python kódban definiálod.

    • Miért ideális 50k userhez? Nagyon egyszerűen összefűzhető elosztott (distributed) módba (Master-Worker architektúra), és menet közben, a böngészős UI-ról is állítható a terhelés mértéke.
    • Előny: Ha a csapat már ismeri a Pythont, a tesztek megírása és karbantartása minimális időt vesz igénybe.

    Menedzselt felhős alternatívák (SaaS)

    Ha egyáltalán nem szeretnél szervereket bérelni és konfigurálni:

    • Grafana Cloud k6 / BlazeMeter / Loader.io / AWS Distributed Load Testing:Ezeknél a szolgáltatásoknál csak feltöltöd a k6, JMeter vagy saját konfigurációs scriptjeidet, kiválasztod a régiót és a 50 000 felhasználós terhelést, ők pedig a háttérben azonnal felhúzzák a szükséges infrastruktúrát, majd a teszt végén leállítják azt.

    Összegzés – Melyiket válaszd?

    • Ha kódból írnál teszteket és a legjobb erőforrás-kihasználást akarod minimalizált szerverköltséggel: k6 vagy Gatling.
    • Ha a csapat Pythonban erős: Locust.
    • Ha nulla infrastruktúra-üzemeltetést szeretnél: Grafana Cloud k6 vagy BlazeMeter.

  • Report Portal

    Hol is kezdjem? Ma is elégettem nem kevés tokent, bár szerencsére ezek ingyen vannak/voltak. Amit ki akartam próbálni, hogy telepítettem egy Rider-t, ami egy IDE, és nekem a .net miatt van rá szükség, majd pedig a Copilot-tal és Gemini-vel elkezdtem ebből egy Playwright, Nunit és .net projectet faragni. Aztán jött a szokásos nehézség, kell egy jelentést generáló eszköz, ami többet vagy épp másképpen tud, mint az Allure. Az AI azt mondta, hogy Report Portal.

    Nem volt mit tenni, elkezdtem belefaragni ezt, és az API kulcs generáláson kívül minden lépést az AI CLI-on keresztül csináltam meg. Szerintem elég pofás lett a végeredmény, de majd erről egy másik bejegyzésben írok részletesebben.

    Most inkább megmutatom, hogy mit tud a Report Portal.

    Mit mond a Gemini?

    A ReportPortal egy nyílt forráskódú (Open Source), AI-alapú tesztriportáló és analitikai platform. Elsősorban automatizált tesztek eredményeinek gyűjtésére, vizualizálására és elemzésére szolgál.

    Főbb jellemzők és előnyök

    • Központi dashboard: Egységes felületen gyűjti össze a különböző tesztkeretrendszerekből és CI/CD csatornákból származó teszteredményeket.
    • AI / Machine Learning alapú hibaelemzés: A korábbi futtatások alapján automatikusan felcímkézi a hibákat (pl. termékhiba, teszthiba, infrastruktúra-probléma), így drasztikusan csökkenti a manuális triázsolásra fordított időt.
    • Valós idejű analitika: A tesztek futása közben élőben láthatók az eredmények, trendek és statisztikák.
    • Integrációk: Szorosan együttműködik hibakövető rendszerekkel (Jira, Rally, Redmine) és CI/CD eszközökkel (Jenkins, GitLab CI, GitHub Actions).

    A ReportPortal architektúrája

    A ReportPortal mikroszolgáltatás-alapú architektúrát használ, amely több konténerből áll (API Service, UI, Index Service/AI Engine, PostgreSQL, RabbitMQ, OpenSearch/Elasticsearch). Ezért a legegyszerűbb és legajánlottabb módja a lokális futtatásnak a Docker / Docker Compose.

    Integráció lokális projektbe (Lépésről lépésre)

    1. Lokális ReportPortal szerver elindítása (Docker Compose)

    Helyi teszteléshez futtasd a ReportPortal szervert a saját gépeden:

    1. Töltsd le a hivatalos Docker Compose fájlt:
      Bash curl -LO https://raw.githubusercontent.com/reportportal/reportportal/master/docker-compose.yml
    2. Indítsd el a konténereket:
      Bashdocker compose up -d
    3. Nyisd meg a böngészőben a http://localhost:8080 címet.
    4. Lépj be az alapértelmezett adatokkal (User: superadmin, Jelszó: erebus).
    5. Hozz létre egy új Projectet, és a profilbeállításoknál másold ki az API Access Token-t.

    2. Tesztkeretrendszer integrálása a projektedbe

    A ReportPortal szinte minden népszerű nyelvhez és tesztkeretrendszerhez biztosít kliens könyvtárat (Agent):

    • Java: JUnit, TestNG, Cucumber
    • Python: Pytest, Robot Framework, Behave
    • JavaScript / TypeScript: Playwright, Cypress, Jest, Mocha
    • .NET: NUnit, xUnit, SpecFlow
    Példa: Pytest (Python) integráció
    1. Telepítsd a pytest agentet:
      Bash pip install pytest-reportportal
    2. Hozz létre egy pytest.ini fájlt a projekt gyökerében:
      Ini, TOML[pytest] rp_api_key = az_a_token_amit_a_profilodban_masoltal rp_endpoint = http://localhost:8080 rp_project = a_projekt_neve rp_launch = Helyi_Pytest_Futtatas rp_launch_attributes = 'Env:Local' 'Type:Smoke'
    3. Futtasd a teszteket a ReportPortal plugin aktiválásával:
      Bash pytest --reportportal
    Példa: Playwright (Node.js / TypeScript) integráció
    1. Telepítsd az agentet:
      Bash npm install --save-dev @reportportal/agent-js-playwright
    2. Add hozzá a playwright.config.ts fájlhoz a riportert:
      TypeScript const RPconfigFile = { apiKey: 'az_a_token_amit_a_profilodban_masoltal', endpoint: 'http://localhost:8080/api/v1', project: 'a_projekt_neve', launch: 'Playwright_Helyi_Futtatas', attributes: [{ key: 'Env', value: 'Local' }], }; export default defineConfig({ reporter: [['@reportportal/agent-js-playwright', RPconfigFile]], });
    3. Futtasd a teszteket a megszokott módon:Bash npx playwright test

  • Grafana K6 készítés Copilot-tal

    Mi is történt? Ismét a semmiből kezdtem, megkértem a Copilot-ot, hogy csináljon egy project-et. El is készült, futott, de a riportolásával nem voltam elégedett. Megkérdeztem, hogy mit ajánl rá, ő elsőre a Grafana felhős szolgáltatását ajánlotta, de mivel lokálból akartam megoldani, így kiegyeztünk a Grafana lokális verziójával. Telepített Grafanát, Dockert, InfluxDB-t. Még a Grafana dashboard-ot is vele csináltattam meg. Még koránt sincs kész, de majd megfelelő Token birtoklásával orvosolni fogom.

    Teszt kód:

    import http from 'k6/http';
import { check, sleep } from 'k6';

export const options = {
  stages: [
    { duration: '40s', target: 2 },
    { duration: '35s', target: 10 },
    { duration: '60s', target: 3 },
  ],
  thresholds: {
    http_req_failed: ['rate<0.01'],
    http_req_duration: ['p(95)<500'],
  },
};

const baseUrl = __ENV.BASE_URL || 'https://test.k6.io';

export default function () {
  const response = http.get(baseUrl);

  check(response, {
    'status is 200': (result) => result.status === 200,
    'response is HTML': (result) => result.headers['Content-Type'].includes('text/html'),
  });
}

    Futtatás:

    D:\Repositories\ai-k6> npm run test:grafana

> ai-k6@1.0.0 test:grafana
> npm run build && node scripts/run-grafana.mjs


> ai-k6@1.0.0 build
> esbuild src/smoke.ts --bundle --format=esm --platform=neutral --external:k6 --external:k6/http --outfile=dist/smoke.js


  dist\smoke.js  670b 

Done in 4ms

         /\      Grafana   /‾‾/  
    /\  /  \     |\  __   /  /   
   /  \/    \    | |/ /  /   ‾‾\ 
  /          \   |   (  |  (‾)  |
 / __________ \  |_|\_\  \_____/ 


     execution: local
        script: dist/smoke.js
        output: InfluxDBv1 (http://localhost:8086)

     scenarios: (100.00%) 1 scenario, 10 max VUs, 2m45s max duration (incl. graceful stop):
              * default: Up to 10 looping VUs for 2m15s over 3 stages (gracefulRampDown: 30s, gracefulStop: 30s)



  █ THRESHOLDS 

    http_req_duration
    ✓ 'p(95)<500' p(95)=135.05ms

    http_req_failed
    ✓ 'rate<0.01' rate=0.00%


  █ TOTAL RESULTS 

    checks_total.......: 1138    8.391855/s
    checks_succeeded...: 100.00% 1138 out of 1138
    checks_failed......: 0.00%   0 out of 1138

    ✓ status is 200
    ✓ response is HTML

    HTTP
    http_req_duration..............: avg=72.84ms min=184µs med=114.54ms max=1s    p(90)=132.88ms p(95)=135.05ms
      { expected_response:true }...: avg=72.84ms min=184µs med=114.54ms max=1s    p(90)=132.88ms p(95)=135.05ms
    http_req_failed................: 0.00%  0 out of 1138
    http_reqs......................: 1138   8.391855/s

    EXECUTION
    iteration_duration.............: avg=1.15s   min=1.12s med=1.14s    max=2.02s p(90)=1.15s    p(95)=1.16s   
    iterations.....................: 569    4.195928/s
    vus............................: 4      min=1         max=10
    vus_max........................: 10     min=10        max=10

    NETWORK
    data_received..................: 2.2 MB 16 kB/s
    data_sent......................: 86 kB  637 B/s




running (2m15.6s), 00/10 VUs, 569 complete and 0 interrupted iterations
default ✓ [======================================] 00/10 VUs  2m15s
PS D:\Repositories\ai-k6>

    Grafana

  • JMeter, változó terhelésű tesztelés

    JMeter, változó terhelésű tesztelés

    Mint már korábban talán írtam, nem vagyok egy JMeter guru. Így aztán ha felmerül valami kérdés, az AI-hoz fordulok, mintsem órákat töltsek azzal, hogy a Google segítségével talált linkeket végigolvassam.  Így történt ez most is, amikor egy váltakozó terhelésű tesztet szerettem volna előállítani. Az elmélet megvolt, hiszen csináltam már ilyen HP LoadRunnerrel réges régen, viszont a JMeter beállításaival és technikai adottságaival nem vagyok komfortos, mivel ez egy elég jól konfigurálható „műszer”.

    Nézzük, mint mondott a Gemini:

    Egyszerű eset

    JMeterben a változó terhelésű (ramping, lépcsőzetes vagy hullámzó) tesztelés megvalósítására három fő módszer létezik, a legegyszerűbb beépített megoldástól a legrugalmasabb pluginokig.

    1. Beépített megoldás: Standard Thread Group

    Ha nincs lehetőséged pluginokat telepíteni, a sima Thread Group beállításaival is elérhetsz alapvető terhelésnövekedést (Ramp-up).

    • Ramp-up Period (seconds): Megadja, hogy a virtuális felhasználók mennyi idő alatt induljanak el fokozatosan.
    • Példa beállítás:
      • Number of Threads (users):100
      • Ramp-up Period (seconds):50
      • Loop Count:Infinite (vagy adj meg egy fix időtartamot a Specify Thread lifetime opcióval)
    • Működés: 50 másodperc alatt másodpercenként 2 új virtuális felhasználó lép be, amíg el nem éri a 100-at.

    2. A legrugalmasabb módszer: Ultimate Thread Group (Ajánlott)

    A változó terhelés (pl. hullámzás, lépcsőzetes emelés, hirtelen tüskék/spike tesztek) grafikusan és precízen a JMeter Plugins Manager segítségével telepíthető Custom Thread Groups csomaggal valósítható meg.

    A telepítés után válaszd a jp@gc - Ultimate Thread Group elemet. Ebben egy táblázatban (Threads Schedule) tetszőleges számú terhelési szakaszt kombinálhatsz:

    Start Thread CountInitial Delay (sec)Startup Time (sec)Hold Load For (sec)Shutdown Time (sec)
    1000306010
    200903012020
    • Működés:
      1. Az első sor lefut: 30 mp alatt felmegy 100 felhasználóra, tartja 60 mp-ig, majd leáll.
      2. A második sor 90 mp várakozás után belép, és további 200 felhasználóval megemeli a terhelést (lépcsőzetes teszt).

    3. Kérés/másodperc (RPS/TPS) alapú szabályozás

    Ha nem a virtuális felhasználók száma, hanem a másodpercenkénti kérésszám (Throughput) változtatása a célod:

    1. Throughput Shaping Timer (Plugin):
      • Helyezd a kérések alá (vagy a Thread Group szintjére).
      • Egy táblázatban megadhatod a kívánt RPS-t időtartam alapján:
        • Start RPS:10$\rightarrow$End RPS:50 (Duration:60s) — lineáris emelkedés
        • Start RPS:50$\rightarrow$End RPS:50 (Duration:180s) — állandó terhelés tartása
    2. Concurrency Thread Group + Throughput Shaping Timer:
      • A két plugin összekapcsolható (a Concurrency Thread Group automatikusan beállítja a szükséges virtuális felhasználók számát a Throughput Shaping Timer által kért RPS eléréséhez).

    Gyors összefoglaló a megközelítés kiválasztásához

    • Lépcsőzetes / Hullámzó terhelés userekkel: Use jp@gc - Ultimate Thread Group
    • Fix Target RPS / Áteresztőképesség tesztelése: Use Throughput Shaping Timer
    • Egyszerű lineáris felfutás: Standard Thread Group (Ramp-Up Period)

    Több Thread Group esetén

    Ha több Thread Group-ot használsz egyetlen Test Planen belül, akkor összetett, valósághű terhelési profilokat építhetsz fel. Például szimulálhatsz különböző felhasználói viselkedéseket (pl. 70% vásárló, 30% böngésző) vagy egymásra csúsztatott terhelési hullámokat.

    A több Thread Group összehangolására két alapvető megközelítés létezik: Párhuzamos (egyszerre futnak) és Egymás utáni (szekvenciális).

    1. Párhuzamos futtatás (Alapértelmezett beállítás)

    Alapértelmezetten a JMeter az összes Thread Group-ot egyszerre, párhuzamosan kezdi el futtatni. A változó terhelést az határozza meg, hogy a csoportok időben hogyan vannak beidőzítve egymáshoz képest.

    Példa scenárió: Vásárlási csúcsforgalom szimulációja

    • Thread Group A (Állandó háttérterhelés – Cikkolvasók): Folyamatosan jelen lévő felhasználók.
    • Thread Group B (Lépcsőzetes terhelés – Vásárlók): Hullámokban érkező vásárlók.

    Beállítás Ultimate Thread Group pluginnal:

    Test Plan

    • ⚙️ Test Plan(a „Run Thread Groups consecutively” opció kivétele)
      • 👥 jp@gc - Ultimate Thread Group(Háttérterhelés – Böngészők)
      • 👥 jp@gc - Ultimate Thread Group(Csúcsforgalom – Vásárlók)

    A) Háttérterhelés csoport (Böngészők):

    Start Thread CountInitial Delay (sec)Startup Time (sec)Hold Load For (sec)Shutdown Time (sec)
    5001030010

    (Gyorsan feláll 50 felhasználóra, és végig fut 5 percig.)

    B) Csúcsforgalom csoport (Vásárlók):

    Start Thread CountInitial Delay (sec)Startup Time (sec)Hold Load For (sec)Shutdown Time (sec)
    10060306010
    200180306010

    (A teszt 1. percében belép 100 vásárló, majd a 3. percben egy újabb 200 fős tüske érkezik.)

    2. Szekvenciális (Egymás utáni) futtatás

    Ha a terhelési fázisokat szigorúan egymás után akarod futtatni (pl. Felfűtés $\rightarrow$ Terhelési teszt $\rightarrow$ Kiürülés), be kell kapcsolnod a JMeterben az egymás utáni futtatást.

    Beállítás lépései:

    1. Kattints a Test Plan gyökérelemre.
    2. Pipáld be a Run Thread Groups consecutively (i.e. run one at a time) opciót.

    Példa felépítés:

    Test Plan(Egymás utáni futtatás bekapcsolva)

    • 1️⃣ Thread Group - 1. Fázis (Bemelegítés)
      • Threads: 20, Ramp-Up: 20s, Duration: 60s
    • 2️⃣ Thread Group - 2. Fázis (Fő terhelés)
      • Threads: 200, Ramp-Up: 30s, Duration: 300s
    • 3️⃣ Thread Group - 3. Fázis (Lecsengés)
      • Threads: 10, Ramp-Up: 1s, Duration: 30s
    • Működés: A JMeter megvárja, amíg az 1. csoport teljesen leáll, és csak utána indítja el a 2. csoportot, majd végül a 3.-at.

    💡 Fontos tipp adatok megosztásához a Thread Groupok között

    Ha több Thread Groupot használsz, a sima JMeter változók (${var}) nem terjednek át az egyik csoportból a másikba, mert a változók szál-specifikusak.

    Ha az egyik csoportban (pl. Bejelentkezés) generált adatot akarod használni egy másik csoportban:

    • Használj JMeter Property-ket a megosztáshoz (pl. Groovy scriptben: props.put("token", "${extracted_token}") és a másik csoportban: ${__P(token)}).
    • Használj jp@gc - Inter-Thread Communication plugint az adatok átadására a csoportok között.

  • Apache JMeter és a Throughput Controller

    Mivel napo óta ezzel szórakoztatom magam, gondoltam íratok erről pár sort az AI-val, mint emlékeztető, ha újra elő kell vennem a témát. Röviden: vannak esetek, amikor százalékos arányban kell hívásokat eszközölni a performancia mérésben. Ebben tud segíteni a Throughput Controller.

    Nézzük, mint mond erről az AI:

    A Throughput Controller az Apache JMeter egyik legfontosabb eleme, amikor a valós felhasználói viselkedést szeretnénk szimulálni. Neve ellenére nem a másodpercenkénti kérések számát (RPS) korlátozza (arra a Constant Throughput Timer való), hanem azt határozza meg, hogy a teszt lépései milyen arányban vagy rögzített alkalommal fussanak le.

    Mire jó a Throughput Controller?

    Egy webáruháznál a látogatók nem egyforma arányban böngésznek és vásárolnak:

    • 80% csak böngészi a termékeket.
    • 15% kosárba tesz valamit.
    • 5% eljut a fizetésig.

    A Throughput Controller segítségével pontosan ezt a megoszlást képezhetjük le egyetlen Thread Group-on belül.

    A két fő működési mód (Based On)

    MódLeírásMikor használd?
    Percent ExecutionsA beállított százalékos arányban engedi lefutni a gyermek kéréseket a teszt során.Valós felhasználói eloszlás szimulálásához (pl. 80-15-5% szabály).
    Total ExecutionsLegfeljebb egy megadott fix alkalommal engedi lefutni a kérést, utána kihagyja.Egyszeri beállításokhoz vagy korlátozott műveletekhez (pl. adatbázis-feltöltés).

    Fontos beállítás (Per User): Ha be van pipálva, a számítás nem a teljes tesztre, hanem szálanként (felhasználónként) érvényesül.

    Gyakorlati példa: Webáruház forgalomszimuláció

    Tételezzük fel, hogy 100 szálat (felhasználót) indítunk egy hurokban (Loop Count: 100). A célunk a fent említett 80%-15%-5%-os megoszlás.

    Struktúra a JMeterben:

    Plaintext

    Test Plan
 └── Thread Group (100 Threads, Loop: 10)
      ├── Throughput Controller (Percent Executions: 80.0)
      │    └── HTTP Request: Termékoldal megtekintése
      ├── Throughput Controller (Percent Executions: 15.0)
      │    └── HTTP Request: Kosárba helyezés
      └── Throughput Controller (Percent Executions: 5.0)
           └── HTTP Request: Fizetés

    Működés:

    • A 1000 összes lefutásból nagyjából 800 alkalommal a termékoldal kérés fog lefutni.
    • 150 alkalommal a kosárba helyezés.
    • 50 alkalommal pedig a fizetés lép fel.

    Gyakori hibák és tippek

    1. Ne keverd a Constant Throughput Timer-rel: Ha az a célod, hogy a szervert pontosan 100 req/sec terhelés alatt tartsd, használj Timert. A Throughput Controller az arányokról szól, nem a sebességről.
    2. Keresztülfutás (Overhead): Ha a szabályok összege nem 100%, vagy egy szál egyik controllernek sem felel meg az adott iterációban, a szál kihagyja az adott részt és lép a következő hurokra.
    3. Egymásba ágyazás: Összetettebb scenárióknál Simple Controller-rel vagy Transaction Controller-rel kombinálva egész folyamatokat is elhelyezhetsz egy-egy Throughput Controller alá.