Meny

Detaljbeskrivning av JMeter-komponenter

detail description jmeter components

Prova Vårt Instrument För Att Eliminera Problem

Granskning av Jmeter-komponenter (del II):

=> Detta är en del av JMeter-träningsserien. Se listan över alla handledning i denna serie här .

Hoppas att ni alla måste ha gått igenom JMeter Introduktion och installation vid det här laget. När vi fortsätter med nästa i serien rekommenderas det starkt att ni alla måste installera JMeter och öva sida vid sida.

I denna handledning skulle läsarna bli bekanta med alla komponenter i JMeter och hur man använder dem i testplanen för att täcka alla möjliga prestanda testscenarier för att testa AUT (Application Under Test).

intervjufrågor för helpdesk

JMeter

Element av Jmeter hade listats nere i föregående artikel.

Vad du kommer att lära dig:

Komponenter i JMeter

Penning ner igen för din referens:

  • Testplan
  • Trådgrupp
  • Provtagare
  • Lyssnare
  • WorkBench
  • Påståenden
  • Config Element
  • Logikstyrenheter
  • Timer

Alla huvudkomponenter i Jmeter som trådgrupp, samplers, lyssnare och konfigurationselement förklaras i detalj senare i artikeln.

Se nedanstående flödesschema för att förstå varje komponent och deras relation till specifika moduler i JMeter.

Jmeter flödesdiagram

Nu skulle vi börja röra vid varje komponent i Jmeter tillsammans med användningsfall för att veta hur det fungerar och hur testare kan implementera dessa i sin testning. Observera att vi inte kommer att täcka alla samplare, lyssnare i den här artikeln. Vi kommer att arbeta med de mest använda och kommer att ta vila i nästa artikel när vi skapar testplaner i realtid.

Testplan

Precis som en enkel testplan i Software Testing består av alla steg som kör scriptet, har JMeters testplan samma syfte. Allt som ingår i en testplan utförs i en sekvens som är uppifrån och ned eller enligt den definierade sekvensen i testplanen.

Testplan kan vara så enkelt som det kan vara, med Just ThreadGroup, Sampler och Listener och det börjar bli mer komplext så snart du börjar lägga till fler element som konfigurationselement, förprocessorer eller styrenheter.

Som vi alla vet att JMeter mäter prestanda genom att generera virtuella användare eller trådar som träffar servern under test som om riktiga användare skickar förfrågningar till en server. Därför bör varje testplan ha virtuella användare eller trådgrupp som vi kallar dem i JMeters termer.

Viktiga punkter om testplan:

  • Testplanen ska sparas innan den körs
  • Jmeter-filer eller testplaner sparas i form av. JMX förlängningsfiler
  • Du kan också spara delar av testplanen som det olika valet. Till exempel, Om du vill spara HTTP Request Sampler med Listener kan du spara det som testfragment så att det också kan användas i andra testscenarier.
  • Element i WorkBench sparas inte med testplanen

Trådgrupp

Trådgrupp är en grupp användare som kommer att träffa servern som testas antingen samtidigt eller i någon fördefinierad sekvens. Trådgruppen kan läggas till i testplanen genom att högerklicka på testplanen. JMeter är alla 'högerklick grejer', du får alla alternativ med högerklick.

Du kan byta namn på trådgruppens namn till ditt eget. Ändra bara namnet och klicka var som helst utanför testplanfönstret, du ser att namnet ändras.

Se skärmdumpen nedan för att lägga till trådgrupper

(Notera: Klicka på valfri bild för förstorad vy)

Lägger till trådgrupp

Det är mycket viktigt att konfigurera din trådgrupp enligt testförhållandena.

Till exempel, om du vill testa hur en webbserver beter sig när 100 användare träffar den samtidigt kan du ställa in trådgruppen enligt nedan:

Konfigurera trådgrupp

I grund och botten finns det tre huvudparametrar som måste konfigureras för att generera faktisk belastning eller virtuella användare:

  • Antal trådar (användare) - Det definierar antalet virtuella användare. För teständamål bör vi generera endast en begränsad mängd belastning eftersom att generera enorm volym på en gång skulle innebära att vi konsumerar många trådar som i slutändan kan leda till högt CPU-utnyttjande.
  • Ramp Up Period - Det här fältet är mycket viktigt för att styra lastgenerering. Upprampningsperiod definierade hur lång tid den totala belastningen genereras.

Exempel 1:

Exempel på antal användare

  • Det betyder att alla tio användare kommer att träffa servrar samtidigt så snart ett test körs

Exempel 2:

Exempel Ramp Up

  • Ni måste alla ha märkt kryssrutan 'Schemaläggare' i skärmbilden ovan. Om du vill att ditt test ska köras vid en viss tidpunkt senare kan du ställa in tiderna som du också kan se på skärmbilden nedan. Det betyder att var 1: e sekund kommer en ny användare att slå på servern. Belastningen kommer inte att ske samtidigt men i steg. Vid 10thför det andra skulle alla användare ha träffat begäran.
  • Loop Count - Det definierar hur många gånger trådgruppen ska köras. Om du markerar kryssrutan Forever kommer ditt test att köras för alltid såvida du inte stoppar det manuellt. Detta kan användas för att testa något som 'Om din server inte kraschar vid kontinuerlig belastning på några minuter'.

Trådgrupp för schemaläggare

Provtagare

Så, hur vet en Jmeter vilken typ av begäran som har skickats till servern ???

  • Det är genom samplers. Samplare är ett måste att lägga till i en testplan eftersom det bara kan låta Jmeter veta vilken typ av begäran som behövs för att gå till vilken server och med eventuella fördefinierade parametrar eller inte. Förfrågningar kan vara HTTP, HTTP (s), FTP, TCP, SMTP, SOAP etc.

Samplers kan bara läggas till i trådgruppen, inte direkt under testplanen, eftersom trådgrupper måste använda en sampler för att skicka en begäran till serverns URL under test. Samplaren kan läggas till med sökväg Trådgrupp -> Sampler -> HTTP-begäran.

HTTP-förfrågningar

Det här är de vanligaste förfrågningarna som skickas till servrarna. Säga, till exempel, vi vill att 100 användare ska slå https://www.google.com samtidigt kan detta göras enligt beskrivningen i skärmdumpen nedan:

Lägger till HTTP-begäran

  • Sökvägen är navigeringen på huvudwebbplatsen. Om vi ​​till exempel vill slå http://www.google.com/gmail kan vi ställa in '/ Gmail' i sökvägen och vila förblir densamma
  • Behöver inte skriva “www” i servernamnet
  • Portnummer används om du använder någon proxyserver
  • Timeout Connect och svar kan ställas in om du vill ha ett riktmärke för din serveranslutningstid och svarstid. Din begäran misslyckas om din server tar längre tid att skicka svar än den konfigurerade
  • Du kan också konfigurera parametrar som ska skickas med din begäran. Till exempel: I vissa fall kan du behöva skicka auktoriseringstoken med din begäran, så du har lagt till dem i HTTP-begäran enligt nedan:

Parametrering av HTTP-begäran

FTP-förfrågningar

Sökväg-> Testplan-> Trådgrupp-> Sampler-> FTP-begäran

FTP står för File Transfer Protocol och används för att ladda upp eller ladda ner en fil från servern. JMeters trådar skickar förfrågningar till FTP-servrar för att ladda upp eller ladda ner filer därifrån och mäter prestandan.

FTP-begäran

FTP-begäran

  • Lokal fil är den plats där du behöver spara den nedladdade filen
  • Använd alternativet GET om du laddar ner från FTP-servern
  • Användarens POST-alternativ om du laddar upp någon fil på FTP-servern

Vi har många lyssnare som kommer att täckas när vi går igenom några riktiga testplaner som består av samplers, lyssnare, konfigurationselement etc.

Lyssnare

Så hittills har vi sett få samplare som skickar förfrågningar till servern men har inte analyserat svaret ännu. Prestandatestning handlar om att analysera serversvar i olika former och sedan presentera samma för klienten.

Lyssnare används för att visa resultaten av testkörning så att testare lär sig statistiken. Vi har cirka 15 lyssnare i Jmeter men mest använda är bord, träd och diagram.

Visa resultat i tabell:

Detta är den mest använda och lättförståeliga formen av lyssnare. Resultatet visas i form av en tabell med några viktiga prestandaparametrar.

Lyssnare kan läggas till direkt under testplanen eller under en sampler. Skillnaden är att när du lägger till lyssnare under en sampler, visar den bara resultaten av den samplaren. Om vi ​​lägger till sampler direkt under testplanen visar det resultatet för alla Sampler upp i hierarkin.

Skärmdumpen nedan för din referens:

ALägg till avlyssningsresultat

Du ser resultaten ungefär som visas nedan:

Tabellresultat

  • Latens : Det är den tid då den första informationen tas emot, dvs. den första databyten tas emot
  • Anslut tid : Det är den tid det tar att upprätta anslutning till servern
  • Provtid : Det är den tid det tar att ta emot fullständiga uppgifter
  • Prov - Sekvens av provnummer
  • Byte - Storlek på mottagna data.

Visa resultat i träd:

Detta är en annan mest använda lyssnare och ger detaljerad information med begäran och svar. Man kan också visa HTML-sidan som återges som svar förutom att visa Json, XML, Text, RegEx.

Det är mycket användbart eftersom testare kan göra påståenden om det mottagna svaret för att säkerställa att testet klarat. Jmeter-resultat visar fortfarande 'Pass' även om svaret inte önskas.

Till exempel: Säg, vi träffar HTTP-begäran på vilken webbplats som helst www.xyz.com och som svar förväntar vi oss XYZ eller med enkla ord, när vi träffar den här sidan öppnas företagets hemsida med sitt namn. Om vi ​​inte har påstått kommer Jmeter fortfarande att visa resultat eftersom träffen har gått till servern.

Lägga till trädvisningslyssnare

Se nedan för att få reda på resultatet av resultaten:

Visa resultatträd

För att visa HTML-sidan som svar, klicka på rullgardinsmenyn i den vänstra rutan och välj sedan 'HTML', navigera till svarsfliken och kontrollera sidan som returneras som serverns svar.

HTML-trädresultat

Arbetsbänk

En arbetsbänk är en plats där du kan lagra de element som inte används i din nuvarande testplan men som senare kan klistras in i den. När du sparar JMeter-filen sparas inte komponenterna som finns i arbetsbänken automatiskt. Du måste spara dem separat genom att högerklicka och välja alternativet 'Spara som'.

Ni tänker kanske alla vad som är användningen av arbetsbänk, det är ändå enkelt att lägga till någon komponent direkt till en Jmets testplan.

Anledningen till att ha en arbetsbänk var att användaren kunde göra några experiment och testa nya scenarier. Som vi redan vet sparas inte element i arbetsbänken så att en användare bokstavligen kan använda vad som helst och sedan kasta bort. Men det finns några ”icke-testkomponenter” som endast finns i WorkBench.

De listas här:

  • HTTP-spegelserver
  • HTTP (s) Test Script Recorder
  • Fastighetsvisning

HTTP (s) Test Script Recorder är det viktigaste icke-testelementet som används i JMeter. Det hjälper testare att spela in skriptet och sedan konfigurera belastningen för varje transaktion.

Jmeter registrerar bara den begäran som skickats till servern. Bli inte förvirrad med 'Record and Play' -funktionaliteten i QTP / Selen. Alla förfrågningar registreras och testare kan applicera önskad belastning på dem för att se beteendet.

Lägga till skriptinspelare

Det här elementet är mycket viktigt för scenarier där testare inte vet vad alla förfrågningar pågår från deras applikation. De kan använda Http (s) skriptinspelare för att spela in applikationen som testas.

Prestandatestning av mobilapplikationer kan också göras på detta sätt genom att ställa in JMeter-proxy och sedan spela in de förfrågningar som vår mobilapp skickar till servern. Steg för steg-procedur för mobila prestandatester kommer att förklaras i nästa artikel.

Påståenden

Hittills har vi täckt hur JMeter träffar servern och hur svaren visas via lyssnare. För att säkerställa att det mottagna svaret är korrekt och enligt förväntningarna måste vi lägga till påståenden. Påståenden är helt enkelt valideringar som vi behöver för att svara för att jämföra resultaten.

Nedan följer de typer av påståenden som ofta används:

  • Svar påstående
  • Varaktighet påstående
  • Storlekspåstående
  • XML-påstående
  • HTML-påstående

Svar påstående

I Respons Assertion kan vi lägga till egna mönstersträngar och sedan jämföra dem med svaren från en server. Till exempel, ni vet alla att svarkoden är 200 när någon begäran returnerar något svar framgångsrikt. Så om vi lägger till mönstersträng “Response Code = 202” så ska testfallet misslyckas.

Se nedan skärmdumpar för att lägga till svarskod.

Lägger till svar påstående

Kontroll av svarkod

Nu när testet körs visar det resultatet med röd färg som indikerar att påståendens resultat misslyckades.

Visa påståenderesultat

Varaktighet påstående

Duration Assertion är mycket viktigt och validerar att servern svarade inom en viss tid. Detta kan användas i scenarier där vi behöver prova 100 förfrågningar och se till att varje gång svar tas emot inom riktmärket.

Fall : 10 användare trycker samtidigt på 'google.com' -servern och varaktighetspåståendet är inställt på 1000 ms. Se nedan skärmdumpar:

Lägger till varaktighetspåstående

Resultat för påstående om varaktighet

XML Assertion validerar om svarsdata har korrekt XML-dokument i sig och HTML Assertion verifierar HTML-syntaxen för svaret som tas emot från en server.

HTML-påstående

HTML nytt påstående

Config Elements

Förfrågningar som skickas till servern kan parametreras ytterligare med hjälp av vissa konfigurationselement som körs före den faktiska begäran. Ett enkelt exempel på det kan vara att läsa värden för en variabel från en CSV-fil som CSV-datauppsättningskonfiguration används för.

Nedan följer några av de viktiga konfigurationselementen som används vid prestandatest av webb- och mobilapplikationer

  • CSV-datauppsättningskonfiguration.
  • Användardefinierade variabler
  • HTTPS begär standard
  • HTTPS Cache Manager
  • HTTPS Cookie Manager

CSV-datauppsättningskonfiguration

CSV-datauppsättningskonfiguration hjälper Jmeter att välja värden för vissa parametrar från en CSV-fil snarare än att skicka olika parametrar i varje separat begäran. Till exempel, om vi behöver testa inloggningsfunktionaliteten med en annan uppsättning användare och lösenord kan vi skapa två kolumner i en CSV-fil och ange värdena där så att JMeter kan välja en för varje begäran som skickas till servern.

Nedan följer flödet av att använda CSV-data för att testa väder-API för olika städer i Indien.

  • Lägga till CSV-datakonfigurationselement i testplanen

Lägga till CSV-datakonfiguration

Laddar CSV-datafil

Passande variabel

  • Köra testet och visa resultat.

Användardefinierade variabler

Det hjälper Jmeter att välja värden från en fördefinierad variabel. Till exempel, stöd för att du behöver skapa en testplan där du måste lägga till många HTTP-förfrågningar på samma URL och det kan finnas ett scenario där klienten planerar att migrera den senare till någon annan URL. så, för att undvika att uppdatera URL i varje begäran vi kan be JMeter att välja URL från en UDV (användardefinierad variabel) som senare kan uppdateras för att hantera alla förfrågningar om uppdaterad URL.

Så för att undvika att uppdatera URL i varje begäran kan vi be JMeter att välja URL från en UDV (användardefinierad variabel) som senare kan uppdateras för att hantera alla förfrågningar om uppdaterad URL.

Användardefinierade variabler

HTTP-förfrågningsinställningar

Detta konfigurationselement är mycket användbart för att specificera standardvärdena för https-förfrågningar. För att vägleda dig mer, ta ett exempel där vi behöver träffa 50 olika förfrågningar på google-servern. I det här scenariot, om vi lägger till en HTTP-begäran som standard, behöver vi inte ange ett servernamn, sökväg eller andra egenskaper som portnummer, anslutning timeout-egenskaper. Vad som helst som anges i HTTP-begäran Standardkonfigurationselement ärvs av alla HTTP-förfrågningar.

I det här scenariot, om vi lägger till en HTTP-begäran som standard, behöver vi inte ange ett servernamn, sökväg eller andra egenskaper som portnummer, egenskap för anslutningstidsavbrott. Vad som helst som anges i HTTP-begäran Standardkonfigurationselement ärvs av alla HTTP-förfrågningar.

Se nedan hur du lägger till HTTP-förfrågningsstandard och anger server och sökväg.

Lägger till HTTP-begäran Standard

HTTP Cache Manager och HTTP Cookie Manager används för att JMeter ska fungera som en webbläsare i realtid. HTTP Cache Manager kan rensa cache efter varje begäran medan den andra kan hantera cookies-inställningarna.

Logikregulatorer och timers

Logiska kontroller och timers hjälper Jmeter att styra flödet av transaktioner. Timers säkerställer fördröjningen i varje tråd om det behövs testa någon server. Till exempel, om vi behöver FTP-begäran för att vänta i 5 sekunder efter att HTTP-begäran är klar kan vi lägga till timer där.

Logic Controllers används för att definiera flödet av förfrågningar som skickas till servern. Det kan också låta dig lagra förfrågningar för varje modul separat, t.ex. inloggning och utloggning.

Slutsats

Nu måste ni alla ha bekantat er med komponenterna i JMeter och försökt använda det och måste möta vissa problem. I nästa artikel kommer vi att behandla några realtidsprestationsscenarier som täcker mobilitetsdomänen så att ni alla får mer praktisk kunskap om JMeter.

Håll dig uppdaterad! Nästa artikel hjälper dig att hantera dina förfrågningar samt analysera resultat och jämföra med riktmärkena för prestandatestning.

=>Fortsätt läsa del III: JMeter-processorer och -kontroller

angularjs intervjufrågor och svar för erfaren pdf

=> Klicka här för JMeter-självstudier: Den kompletta kostnadsfria träningen på JMeter (20+ videor)

Rekommenderad läsning

^