detail description jmeter components
Herziening van Jmeter-componenten (deel II):
=> Dit maakt deel uit van de JMeter-trainingsreeks. Bekijk hier de lijst met alle tutorials in deze serie
Ik hoop dat jullie allemaal door de JMeter Introductie en installatie tegen deze tijd. Terwijl we doorgaan met de volgende in de serie, wordt het ten zeerste aanbevolen dat u allemaal JMeter installeert en zij aan zij oefent.
In deze tutorial zouden lezers zichzelf vertrouwd maken met alle componenten van JMeter en hoe deze in het testplan te gebruiken om alle mogelijke scenario's voor het testen van prestaties te dekken om de AUT (Application Under Test) te testen.
Elementen van Jmeter waren opgesomd in het vorige artikel.
Wat je leert:
- Onderdelen van JMeter
Onderdelen van JMeter
Nogmaals noteren voor uw referentie:
- Testplan
- ThreadGroup
- Monsternemers
- Luisteraars
- Werkbank
- Beweringen
- Config Element
- Logische controllers
- Timer
Alle belangrijke componenten van Jmeter zoals Thread Group, Samplers, Listeners en Config Elements worden later in het artikel in detail uitgelegd.
Raadpleeg het onderstaande stroomdiagram om elk onderdeel en hun relatie met specifieke modules van JMeter te begrijpen.
Nu zouden we beginnen met het aanraken van elk onderdeel van Jmeter, samen met use cases, gewoon om te weten hoe het werkt en hoe testers deze kunnen implementeren in hun tests. Houd er rekening mee dat we in dit artikel niet alle samplers, luisteraars, behandelen. We zullen aan de meest gebruikte werken en rusten in het volgende artikel wanneer we realtime testplannen maken.
Testplan
Net zoals een eenvoudig testplan in Software Testing bestaat uit alle stappen die het script uitvoeren, zo heeft het testplan van JMeter hetzelfde doel. Alles wat in een testplan is opgenomen, wordt uitgevoerd in een volgorde die van boven naar beneden is of volgens de gedefinieerde volgorde in het testplan.
Testplan kan zo eenvoudig zijn als het zou kunnen zijn, met Just ThreadGroup, Sampler en Listener en het wordt complexer zodra je meer elementen toevoegt, zoals configuratie-elementen, preprocessors of controllers.
Zoals we allemaal weten, meet JMeter de prestaties door virtuele gebruikers of threads te genereren die de geteste server raken alsof echte gebruikers verzoeken naar een server sturen. Daarom zou elk testplan virtuele gebruikers of Thread Group moeten hebben, zoals we ze in de termen van JMeter noemen.
Belangrijke punten over testplan:
- Het testplan moet worden opgeslagen voordat het wordt uitgevoerd
- Jmeter-bestanden of testplannen worden opgeslagen in de vorm van. JMX-extensiebestanden
- U kunt ook delen van het testplan opslaan als de andere selectie. Bijvoorbeeld, Als u HTTP Request Sampler met Listener wilt opslaan, kunt u het opslaan als Test Fragment zodat het ook in andere testscenario's kan worden gebruikt
- Elementen van WorkBench worden niet opgeslagen met Testplan
Discussiegroep
Thread Group is een groep gebruikers die de te testen server tegelijkertijd of in een vooraf gedefinieerde volgorde zal raken. Thread Group kan aan het testplan worden toegevoegd door met de rechtermuisknop op het testplan te klikken. JMeter is allemaal 'Right Click-dingen', u krijgt alle opties met de rechtermuisknop.
U kunt de naam van de discussiegroep naar uw eigen naam wijzigen. Wijzig gewoon de naam en klik ergens buiten het venster Testplan, u zou zien dat de naam wordt gewijzigd.
Zie onderstaande screenshot voor het toevoegen van discussiegroepen
Opmerking: Klik op een afbeelding voor een vergrote weergave)
Het is erg belangrijk om uw threadgroep te configureren volgens de testvoorwaarden.
Bijvoorbeeld, als je wilt testen hoe een webserver zich gedraagt wanneer 100 gebruikers hem tegelijkertijd raken, kun je Thread Group instellen zoals hieronder:
In principe zijn er drie hoofdparameters die moeten worden geconfigureerd om werkelijke belasting of virtuele gebruikers te genereren:
- Aantal discussies (gebruikers) - Het definieert het aantal virtuele gebruikers. Voor testdoeleinden zouden we slechts een beperkte hoeveelheid belasting moeten genereren, omdat het genereren van een enorm volume in één keer zou betekenen dat veel threads worden verbruikt, wat uiteindelijk kan leiden tot een hoog CPU-gebruik.
- Aanloopperiode - Dit veld is erg belangrijk bij het regelen van de belastinggeneratie. De aanloopperiode definieerde de hoeveelheid tijd waarin de totale belasting wordt gegenereerd.
voorbeeld 1
- Het betekent dat alle 10 gebruikers gelijktijdig servers zullen raken zodra een test wordt uitgevoerd
Voorbeeld 2
- Jullie moeten allemaal het selectievakje 'Scheduler' hebben opgemerkt in de bovenstaande schermafbeelding. Als u wilt dat uw test later op een specifiek tijdstip wordt uitgevoerd, kunt u de timing instellen zoals u ook kunt zien in de onderstaande schermafbeelding. Het betekent dat elke seconde een nieuwe gebruiker op de server komt. De belasting zal niet gelijktijdig zijn, maar in stappen. Bij de 10thten tweede zouden alle gebruikers het verzoek hebben geraakt.
- Loop Count - Het definieert het aantal keren dat Thread Group zal worden uitgevoerd. Als u het selectievakje Voor altijd aanvinkt, wordt uw test voor altijd uitgevoerd, tenzij u deze handmatig stopt. Dit kan worden gebruikt om iets te testen als 'Als uw server niet crasht bij continue belasting gedurende enkele minuten'.
Monsternemers
Dus, hoe weet een Jmeter welk type verzoek naar de server is verzonden ???
- Het is via Samplers. Samplers zijn een must om toe te voegen aan een testplan, omdat alleen het Jmeter kan laten weten welk type verzoek naar welke server moet gaan en met vooraf gedefinieerde parameters of niet. Verzoeken kunnen HTTP, HTTP (s), FTP, TCP, SMTP, SOAP enz. Zijn.
Samplers kunnen alleen worden toegevoegd aan Thread Group, niet direct onder Test Plan, aangezien Thread Groups een sampler nodig hebben om een verzoek te sturen naar de server-URL die wordt getest. De sampler kan via pad worden toegevoegd Thread Group -> Sampler -> HTTP-verzoek.
HTTP-verzoeken
Dit zijn de meest voorkomende verzoeken die naar de servers worden gestuurd. Zeggen, bijvoorbeeld, we willen dat 100 gebruikers raken https://www.google.com gelijktijdig kan dit worden gedaan zoals beschreven in onderstaande schermafbeelding:
hoe svn-plug-in in eclipse te installeren
- Het pad is de navigatie binnen de hoofdwebsite. Als we bijvoorbeeld http://www.google.com/gmail willen raken, kunnen we ‘/ Gmail’ als pad instellen en blijft de rest hetzelfde
- U hoeft geen 'www' in de servernaam te typen
- Poortnummer wordt gebruikt als u een proxyserver gebruikt
- Time-out Verbinding en respons kunnen worden ingesteld als u een benchmark wilt hebben voor de verbindingstijd en responstijd van uw server. Uw verzoek zal mislukken als uw server meer tijd nodig heeft om een antwoord te verzenden dan geconfigureerd
- U kunt ook parameters configureren om met uw verzoek te verzenden. Bijvoorbeeld: In sommige gevallen moet u mogelijk een autorisatietoken met uw verzoek verzenden, dus u heeft deze in HTTP-verzoek toegevoegd, zoals hieronder:
FTP-verzoeken
Pad-> Testplan-> Discussiegroep-> Sampler-> FTP-aanvraag
FTP staat voor File Transfer Protocol en wordt gebruikt om een bestand van de server te uploaden of downloaden. De threads van JMeter sturen verzoeken naar FTP-servers om van daaruit bestanden te uploaden of downloaden en meten de prestaties.
- Lokaal bestand is de locatie waar u het gedownloade bestand moet opslaan
- Gebruik de optie GET als u downloadt van een FTP-server
- Gebruiker POST-optie als u een bestand uploadt naar een FTP-server
We hebben veel luisteraars die aan bod komen als we enkele echte testplannen doorlopen die bestaan uit samplers, luisteraars, configuratie-elementen enz.
Luisteraars
Tot nu toe hebben we dus maar weinig samplers verzoeken naar de server zien sturen, maar hebben de respons nog niet geanalyseerd. Bij prestatietests gaat het erom de serverreacties in verschillende vormen te analyseren en deze vervolgens aan de klant te presenteren.
Luisteraars worden gebruikt om de resultaten van de testuitvoering weer te geven, zodat testers de statistieken leren kennen. We hebben ongeveer 15 luisteraars in Jmeter, maar de meest gebruikte zijn table, tree en Graph.
Bekijk resultaten in tabel:
Dit is de meest gebruikte en gemakkelijk te begrijpen vorm van luisteraars. Het geeft het resultaat weer in de vorm van een tabel met enkele belangrijke prestatieparameters.
Luisteraars kunnen direct onder Testplan of onder een sampler worden toegevoegd. Het verschil is dat wanneer u listener onder een sampler toevoegt, deze alleen de resultaten van die sampler laat zien. Als we een sampler direct onder het testplan toevoegen, wordt het resultaat voor alle samplers in de hiërarchie weergegeven.
De onderstaande schermafbeelding ter referentie:
U ziet de resultaten zoals hieronder weergegeven:
- Latentie : Het is het tijdstip waarop het eerste stuk informatie wordt ontvangen, d.w.z. de eerste byte aan gegevens wordt ontvangen
- Verbind tijd : Het is de tijd die nodig is om verbinding te maken met de server
- Proeftijd : Het is de tijd die nodig is om volledige gegevens te ontvangen
- Monster - Volgorde van monsternummer
- Bytes - Grootte van ontvangen gegevens.
Bekijk resultaten in structuur:
Dit is een andere meest gebruikte luisteraar en biedt gedetailleerde informatie met verzoek en antwoord. Men kan ook de HTML-pagina bekijken die als reactie wordt weergegeven, afgezien van het bekijken van Json, XML, Text, RegEx.
Het is erg handig omdat testers beweringen kunnen doen over de ontvangen respons om er zeker van te zijn dat de test geslaagd is. De resultaten van de Jmeter laten nog steeds 'Pass' zien, zelfs als het antwoord niet gewenst is.
Bijvoorbeeld: Stel dat we op elke website een HTTP-verzoek krijgen www.xyz.com en als reactie verwachten we XYZ of in eenvoudige bewoordingen, wanneer we op deze pagina klikken, wordt de startpagina van het bedrijf geopend met zijn naam. Als we geen bewering hebben gedaan, zal Jmeter nog steeds resultaten weergeven sinds de hit naar de server is gegaan.
Zie hieronder om het formaat van de resultaten te kennen:
Om de HTML-pagina als reactie te bekijken, klikt u op de vervolgkeuzelijst in het linkerdeelvenster en selecteert u 'HTML', navigeert u naar het reactietabblad en controleert u de pagina die wordt geretourneerd als reactie van de server.
Werkbank
Een werkbank is een plek waar u die elementen kunt opslaan die niet in uw huidige testplan worden gebruikt, maar die er later in kunnen worden gekopieerd. Wanneer u het JMeter-bestand opslaat, worden de componenten die aanwezig zijn in de workbench niet automatisch opgeslagen. U moet ze afzonderlijk opslaan door met de rechtermuisknop te klikken en de optie 'Opslaan als' te kiezen.
Jullie denken allemaal misschien wat het nut is van een werkbank, het is sowieso gemakkelijk om elk onderdeel rechtstreeks aan het testplan van een Jmeter toe te voegen.
De reden om een werkbank te hebben, was dat de gebruiker enkele experimenten kon doen en nieuwe scenario's kon uitproberen. Zoals we al weten, worden elementen in de werkbank niet opgeslagen, zodat een gebruiker letterlijk alles kan gebruiken en vervolgens kan weggooien. Maar er zijn enkele 'niet-testcomponenten' die alleen beschikbaar zijn in WorkBench.
Ze worden hier vermeld:
- HTTP-mirrorserver
- HTTP ('s) Test Script Recorder
- Eigenschapweergave
HTTP (s) Test Script Recorder is het belangrijkste niet-testelement dat in JMeter wordt gebruikt. Het helpt testers bij het opnemen van het script en het configureren van de belasting voor elke transactie.
Jmeter neemt alleen het verzoek op dat naar de server is verzonden. Laat u niet verwarren met de 'Record and Play'-functionaliteit van QTP / Selenium. Alle verzoeken worden geregistreerd en testers kunnen er de gewenste belasting op toepassen om het gedrag te zien.
Dit element is erg belangrijk voor scenario's waarin testers niet weten wat alle verzoeken van hun app binnenkomen. Ze kunnen Http (s) scriptrecorder gebruiken om de te testen applicatie op te nemen.
Prestatietests van mobiele applicaties kunnen ook op deze manier worden gedaan door JMeter-proxy in te stellen en vervolgens de verzoeken op te nemen die onze mobiele app naar de server stuurt. De stapsgewijze procedure voor het testen van mobiele prestaties wordt in het volgende artikel uitgelegd.
Beweringen
Tot nu toe hebben we besproken hoe JMeter de server raakt en hoe de reacties worden weergegeven via luisteraars. Om ervoor te zorgen dat het ontvangen antwoord correct is en volgens verwachting, moeten we beweringen toevoegen. Beweringen zijn eenvoudigweg validaties die we op reacties moeten aanbrengen om de resultaten te vergelijken.
Hieronder staan de soorten beweringen die vaak worden gebruikt:
- Reactie bewering
- Duur Bewering
- Grootte bewering
- XML-bewering
- HTML-bewering
Reactie bewering
In Response Assertion kunnen we onze eigen patroonreeksen toevoegen en deze vervolgens vergelijken met de reacties die we van een server hebben ontvangen. Bijvoorbeeld, jullie weten allemaal dat de antwoordcode 200 is wanneer een verzoek een antwoord met succes retourneert. Dus als we de patroontekenreeks 'Response Code = 202' toevoegen, zou de testcase moeten mislukken.
Raadpleeg onderstaande schermafbeeldingen om een bewering over de antwoordcode toe te voegen.
Als de test nu wordt uitgevoerd, wordt het resultaat weergegeven met een rode kleur, wat aangeeft dat de Assertion-resultaten zijn mislukt.
Duur Bewering
Duration Assertion is erg belangrijk en bevestigt dat de server binnen een bepaalde tijd reageerde. Dit kan worden gebruikt in scenario's waarin we 100 verzoeken moeten bemonsteren en ervoor moeten zorgen dat elke keer dat een reactie wordt ontvangen binnen de gebenchmarkte limiet.
Geval : 10 gebruikers raken gelijktijdig de 'google.com' -server en de duurbevestiging is ingesteld op 1000 ms. Zie onderstaande schermafbeeldingen:
XML Assertion valideert of responsgegevens het juiste XML-document bevatten en HTML Assertion verifieert de HTML-syntaxis van de respons die van een server wordt ontvangen.
Config Elements
Verzoeken die naar de server worden verzonden, kunnen verder worden geparametriseerd met behulp van enkele configuratie-elementen die worden uitgevoerd vóór het daadwerkelijke verzoek. Een eenvoudig voorbeeld hiervan is het lezen van waarden van een variabele uit een CSV-bestand waarvoor CSV Data Set Config wordt gebruikt.
Hieronder staan enkele van de belangrijke configuratie-elementen die worden gebruikt bij het testen van de prestaties van het web en mobiele applicaties
- CSV-datasetconfig.
- Door de gebruiker gedefinieerde variabelen
- HTTPS-verzoeken standaard
- HTTPS-cachebeheer
- HTTPS Cookie Manager
CSV-datasetconfig
CSV-gegevenssetconfiguratie helpt Jmeter bij het kiezen van waarden van sommige parameters uit een CSV-bestand in plaats van verschillende parameters door te geven in elk afzonderlijk verzoek. Bijvoorbeeld, als we de inlogfunctionaliteit moeten testen met een andere set gebruikers en wachtwoorden, dan kunnen we twee kolommen in een CSV-bestand maken en de waarden daar invoeren, zodat JMeter er een kan kiezen voor elk verzoek dat naar de server wordt verzonden.
Hieronder ziet u de stroom van het gebruik van CSV-gegevensset de configuratie om de weer-API voor verschillende steden in India te testen.
- CSV-gegevenssetconfiguratie-element toevoegen aan testplan
- CSV-bestand maken
- Variabele doorgeven in de verzoekparameter. APPID-parameter kan dynamisch worden gegenereerd vanuit http://openweathermap.org/appid
- De test uitvoeren en de resultaten bekijken.
Door de gebruiker gedefinieerde variabelen
Het helpt Jmeter om waarden te kiezen uit een vooraf gedefinieerde variabele. Bijvoorbeeld, ondersteuning die u nodig hebt om een testplan te maken waarin u veel HTTP-verzoeken op dezelfde URL moet toevoegen en er kan een scenario zijn waarin de klant van plan is om het later naar een andere URL te migreren. dus om te voorkomen dat de URL in elk verzoek wordt bijgewerkt we kunnen JMeter vertellen om de URL te kiezen uit een UDV (User Defined Variable) die later kan worden bijgewerkt om alle verzoeken naar bijgewerkte URL te behandelen.
Dus om te voorkomen dat de URL in elk verzoek wordt bijgewerkt, kunnen we JMeter vertellen om de URL te kiezen uit een UDV (User Defined Variable) die later kan worden bijgewerkt om alle verzoeken naar een bijgewerkte URL af te handelen.
Standaardwaarden HTTP-verzoek
Dit configuratie-element is erg handig voor het specificeren van de standaardwaarden van https-verzoeken. Om u meer te begeleiden, neemt u een voorbeeld waarbij we 50 verschillende verzoeken op de Google-server moeten behandelen. Als we in dit scenario een HTTP-verzoekstandaard toevoegen, hoeven we geen servernaam, pad of andere eigenschappen zoals poortnummer, verbinding time-out eigenschappen. Alles wat is gespecificeerd in het HTTP Request Default-configuratie-element wordt overgenomen door alle HTTP-verzoeken.
Als we in dit scenario een HTTP-verzoekstandaard toevoegen, hoeven we geen servernaam, pad of andere eigenschappen op te geven, zoals poortnummer en time-out voor verbinding. Alles wat is gespecificeerd in het HTTP Request Default-configuratie-element wordt overgenomen door alle HTTP-verzoeken.
Zie hieronder hoe u HTTP Request Default toevoegt en de server en het pad specificeert.
HTTP-cachebeheer en HTTP Cookie Manager worden gebruikt om ervoor te zorgen dat JMeter zich gedraagt als een real-time browser. HTTP Cache Manager kan de cache na elk verzoek wissen, terwijl de andere de cookie-instellingen kan beheren.
Logische controllers en timers
Logische controllers en timers helpen Jmeter de transactiestroom te beheersen. Timers zorgen voor de vertraging in elke thread als een server moet worden getest. Bijvoorbeeld, als we een FTP-verzoek nodig hebben om 5 seconden te wachten nadat het HTTP-verzoek is voltooid, kunnen we daar een timer toevoegen.
Logische controllers worden gebruikt om de stroom verzoeken te definiëren die naar de server worden verzonden. Het kan u ook verzoeken voor elke module afzonderlijk opslaan, zoals inloggen en uitloggen.
Gevolgtrekking
Inmiddels moeten jullie allemaal vertrouwd zijn geraakt met de componenten van JMeter en geprobeerd hebben het te gebruiken, en je moet een aantal problemen tegenkomen. In het volgende artikel zullen we enkele real-time scenario's voor prestatietests behandelen die het mobiliteitsdomein bestrijken, zodat jullie allemaal meer praktische kennis opdoen over JMeter.
Blijf kijken! Het volgende artikel helpt u bij het beheren van uw verzoeken, het analyseren van resultaten en het vergelijken met de benchmarks van prestatietests.
Lees verder deel III JMeter-processors en controllers
=> Klik hier voor JMeter Tutorials: De complete gratis training op JMeter (20+ video's)
Aanbevolen literatuur
- Hoe JMeter-correlatie met voorbeeld te bereiken
- Jmeter Testplan en WorkBench
- Werken met FTP-verzoek in JMeter
- Top 5 JMeter-plug-ins en hoe ze te gebruiken (met voorbeelden)
- JMeter Timers: Constant, BeanShell en Guassian Random Timer
- Werken met HTTP-verzoeken in JMeter
- Jmeter Controllers Deel 1
- Jmeter Controllers Deel 2