Detaljeret beskrivelse af JMeter-komponenter

detail description jmeter components

Gennemgang af Jmeter-komponenter (del II):

=> Dette er en del af JMeter-træningsserien. Se listen over alle tutorials i denne serie her .

Håber I alle skal have gennemgået JMeter Introduktion og installation nu. Da vi fortsætter med den næste i serien, anbefales det stærkt, at I alle skal installere JMeter og øve side om side.

I denne vejledning vil læsere blive fortrolige med alle komponenter i JMeter og hvordan man bruger dem i testplanen for at dække alle mulige præstations testscenarier for at teste AUT (Application Under Test).

Elementer af Jmeter var blevet anført i den foregående artikel.

Hvad du vil lære:

• Komponenter i JMeter
  • Testplan
  • Trådgruppe
  • Prøver
  • HTTP-anmodninger
  • FTP-anmodninger
  • Lyttere
  • Arbejdsbænk
  • Påstande
    • Påstand om svar
    • Påstand om varighed
  • Config Elements
    • CSV-datasætkonfig
    • Brugerdefinerede variabler
    • HTTP-anmodningsstandarder
  • Logiske controllere og timere
  • Konklusion
  • Anbefalet læsning

Komponenter i JMeter

Penning ned igen for din reference:

• Testplan
• Trådgruppe
• Prøver
• Lyttere
• WorkBench
• Påstande
• Config Element
• Logiske controllere
• Timer

Alle hovedkomponenter i Jmeter som trådgruppe, samplere, lyttere og konfigurationselementer forklares detaljeret senere i artiklen.

Se nedenstående flowdiagram for at forstå hver komponent og deres relation til specifikke moduler i JMeter.

Nu vil vi begynde at røre ved hver komponent i Jmeter sammen med brugssager bare for at vide, hvordan det fungerer, og hvordan kan testere implementere disse i deres test. Bemærk, at vi ikke dækker alle samplere, lyttere i denne artikel. Vi arbejder på de mest anvendte og vil hvile i den næste artikel, når vi opretter testplaner i realtid.

Testplan

Ligesom en simpel testplan i softwaretest består af alle trin, der udfører scriptet, har JMeters testplan det samme formål. Alt, hvad der er inkluderet i en testplan, udføres i en sekvens, der er top til bund eller i henhold til den definerede sekvens i testplanen.

Testplan kan være så enkel som den kunne være med Just ThreadGroup, Sampler og Listener, og den begynder at blive mere kompleks, så snart du begynder at tilføje flere elementer som konfigurationselementer, præprocessorer eller controllere.

sql server interview spørgsmål og svar til erfaren pdf

Som vi alle ved, at JMeter måler ydeevne ved at generere virtuelle brugere eller tråde, der rammer serveren under test, som om rigtige brugere sender anmodninger til en server. Derfor bør hver testplan have virtuelle brugere eller trådgrupper, som vi kalder dem i JMeters udtryk.

Vigtige punkter om testplan:

• Testplanen skal gemmes, før den kører
• Jmeter-filer eller testplaner gemmes i form af. JMX udvidelsesfiler
• Du kan også gemme dele af testplanen som det forskellige valg. For eksempel, Hvis du vil gemme HTTP Request Sampler med Listener, kan du gemme den som testfragment, så den også kan bruges i andre testscenarier.
• Elementer af WorkBench gemmes ikke med testplan

Trådgruppe

Trådgruppe er en gruppe brugere, der vil ramme den server, der testes, enten samtidigt eller i en foruddefineret rækkefølge. Trådgruppe kan føjes til testplanen ved at højreklikke på testplanen. JMeter er alle 'højreklik-ting', du får alle mulighederne med højre klik.

Du kan omdøbe trådgruppenavnet til dit eget. Skift bare navnet og klik et vilkårligt sted uden for vinduet Testplan, du vil se navnet blive ændret.

Se nedenstående skærmbillede for at tilføje trådgrupper

(Bemærk: Klik på et hvilket som helst billede for at se et forstørret billede)

Det er meget vigtigt at konfigurere din trådgruppe i henhold til testbetingelserne.

For eksempel, Hvis du vil teste, hvordan en webserver opfører sig, når 100 brugere rammer den samtidigt, kan du indstille trådgruppe som nedenfor:

Dybest set er der tre hovedparametre, der skal konfigureres til at generere faktisk belastning eller virtuelle brugere:

• Antal tråd (brugere) - Det definerer antallet af virtuelle brugere. Til testformål bør vi kun generere en begrænset mængde belastning, da generering af stort volumen på én gang ville betyde at forbruge mange tråde, som i sidste ende kan føre til høj CPU-udnyttelse.
• Opkørselsperiode - Dette felt er meget vigtigt for at kontrollere belastningen. Opkørselsperiode definerede det tidsrum, hvor den samlede belastning genereres.

Eksempel 1:

• Det betyder, at alle 10 brugere rammer servere samtidigt, så snart en test er kørt

Eksempel 2:

• I skal alle have bemærket afkrydsningsfeltet 'Planlægning' i ovenstående skærmbillede. Hvis du vil have din test til at køre på et bestemt tidspunkt senere, kan du indstille timingen, som du også kan se i nedenstående skærmbillede. Det betyder, at hver nye sekund rammer en ny bruger serveren. Belastningen vil ikke være samtidig, men vil være i trin. Ved 10^thfor det andet ville alle brugere have ramt anmodningen.
• Loop Count - Det definerer antallet af gange, trådgruppen udfører. Hvis du markerer afkrydsningsfeltet Forever, kører din test for evigt, medmindre du manuelt stopper den. Dette kan bruges til at teste noget som 'Hvis din server ikke går ned ved kontinuerlig belastning i få minutter'.

Prøver

Så hvordan ved en Jmeter, hvilken type anmodning der er sendt til serveren ???

• Det er gennem samplere. Samplere er et must at tilføje til en testplan, da det kun kan lade Jmeter vide, hvilken type anmodning der skal til hvilken server og med eventuelle foruddefinerede parametre eller ej. Anmodninger kan være HTTP, HTTP (s), FTP, TCP, SMTP, SOAP osv.

Samplere kan kun føjes til trådgruppen ikke direkte under testplan, da trådgrupper skal bruge en sampler til at sende en anmodning til server-URL under test. Sampleren kan tilføjes ad stien Trådgruppe -> Sampler -> HTTP-anmodning.

HTTP-anmodninger

Dette er de mest almindelige anmodninger sendt til serverne. Sige, for eksempel, vi ønsker, at 100 brugere skal ramme https://www.google.com samtidigt kan dette gøres som beskrevet i nedenstående skærmbillede:

• Stien er navigationen på hovedwebstedet. For eksempel, hvis vi ønsker at ramme http://www.google.com/gmail så kan vi indstille “/ Gmail” i sti og hvile forbliver den samme
• Behøver ikke at skrive “www” i servernavnet
• Portnummer bruges, hvis du bruger en proxyserver
• Timeout Connect og Response kan indstilles, hvis du vil have et benchmark på din serverforbindelsestid og responstid. Din anmodning mislykkes, hvis din server tager mere tid at sende svar end den konfigurerede
• Du kan også konfigurere parametre, der skal sendes med din anmodning. For eksempel: I nogle tilfælde skal du muligvis sende autorisationstoken med din anmodning, så du har tilføjet dem i HTTP-anmodning som nedenfor:

FTP-anmodninger

Sti-> Testplan-> Trådgruppe-> Sampler-> FTP-anmodning

FTP står for File Transfer Protocol, og det bruges til at uploade eller downloade en fil fra serveren. JMeters tråde sender anmodninger til FTP-servere for at uploade eller downloade filer derfra og måler ydeevnen.

• Lokal fil er det sted, hvor du skal gemme den downloadede fil
• Brug indstillingen GET, hvis du downloader fra FTP-serveren
• Bruger-POST-mulighed, hvis du uploader en fil til FTP-serveren

Vi har mange lyttere, som vil blive dækket, når vi gennemgår nogle rigtige testplaner, der består af samplere, lyttere, konfigurationselementer osv.

Lyttere

Så indtil nu har vi set få samplere, der sender anmodninger til serveren, men har ikke analyseret svaret endnu. Performance test handler om at analysere serversvar i forskellige former og derefter præsentere det samme for klienten.

Lyttere bruges til at vise resultaterne af testudførelse, så testere lærer statistikken at kende. Vi har omkring 15 lyttere i Jmeter, men de mest anvendte er bord, træ og graf.

Se resultater i tabel:

Dette er den mest anvendte og let forståelige form for lyttere. Det viser resultatet i form af en tabel med nogle vigtige præstationsparametre.

Lyttere kan tilføjes direkte under testplan eller under en sampler. Forskellen er, at når du tilføjer lytter under en sampler, viser den kun resultaterne af denne sampler. Hvis vi tilføjer sampler direkte under testplanen, viser det resultatet for alle Sampler op i hierarkiet.

Skærmbilledet nedenfor til din reference:

Du ser resultaterne som vist nedenfor:

• Reaktionstid : Det er det tidspunkt, hvor det første stykke information modtages, dvs. den første byte af data modtages
• Forbind tid : Det er tid, det tager at oprette forbindelse til serveren
• Prøve tid : Det er tid, det tager at modtage komplette data
• Prøve - Sekvens af prøve nummer
• Bytes - Størrelse på de modtagne data.

Se resultater i træ:

Dette er en anden mest almindeligt anvendte lyttere og giver detaljerede oplysninger med anmodning og svar. Man kan også se HTML-siden, der gengives som svar, bortset fra at se Json, XML, Text, RegEx.

Det er meget nyttigt, da testere kan komme med påstande om det modtagne svar for at sikre, at testen er bestået. Jmeter-resultater viser stadig 'Pass', selvom svaret ikke ønskes.

For eksempel: Sig, vi rammer HTTP-anmodning på ethvert websted www.xyz.com og som svar forventer vi XYZ eller med enkle ord, når vi rammer denne side, åbner virksomhedens startside med sit navn. Hvis vi ikke har påstået, vil Jmeter stadig vise resultater, da hit er gået til serveren.

Se nedenfor for at kende formatet på resultaterne:

For at se HTML-siden som svar, skal du klikke på rullemenuen i venstre rude og derefter vælge 'HTML', Naviger til svarfanen og kontrollere den side, der returneres som serversvar.

Arbejdsbænk

En arbejdsbænk er et sted, hvor du kan gemme de elementer, der ikke er i brug i din nuværende testplan, men som senere kan kopieres og indsættes i den. Når du gemmer JMeter-filen, gemmes de komponenter, der findes på arbejdsbænken, ikke automatisk. Du skal gemme dem separat ved at højreklikke og vælge 'Gem som'.

I tænker måske alle sammen, hvad er brugen af ​​arbejdsbænk, alligevel er det let at tilføje en hvilken som helst komponent direkte til en Jmeters testplan.

Årsagen til at have arbejdsbænken var, at brugeren kunne lave nogle eksperimenter og prøve nye scenarier. Som vi allerede ved, gemmes ikke elementer i arbejdsbænken, så en bruger kan bogstaveligt talt bruge noget og derefter smide væk. Men der er nogle “ikke-testkomponenter”, som kun er tilgængelige i WorkBench.

De er anført her:

• HTTP Mirror Server
• HTTP (s) Test Script Recorder
• Ejendomsvisning

HTTP (s) Test Script Recorder er det vigtigste ikke-testelement, der bruges i JMeter. Det hjælper testere med at optage scriptet og derefter konfigurere belastningen for hver transaktion.

Jmeter registrerer kun den anmodning, der er sendt til serveren. Bliv ikke forvirret med 'Record and Play' -funktionaliteten i QTP / Selen. Alle anmodninger registreres, og testere kan anvende den ønskede belastning på dem for at se adfærd.

Dette element er meget vigtigt for scenarier, hvor testere ikke ved, hvad alle anmodninger foregår fra deres applikation. De kan bruge Http (s) scriptoptager til at optage applikationen under test.

Ydeevne Test af mobilapplikationer kan også udføres på denne måde ved at indstille JMeter proxy og derefter registrere de anmodninger, som vores mobilapp sender til serveren. Trin for trin-procedure til test af mobil ydeevne vil blive forklaret i næste artikel.

Påstande

Indtil nu har vi dækket, hvordan JMeter rammer serveren, og hvordan svarene vises via lyttere. For at sikre, at det modtagne svar er korrekt og som forventet, er vi nødt til at tilføje påstande. Påstande er simpelthen valideringer, som vi har brug for til at svare for at sammenligne resultaterne.

Nedenfor er de typer påstande, der ofte bruges:

• Påstand om svar
• Påstand om varighed
• Påstand om størrelse
• XML-påstand
• HTML-påstand

Påstand om svar

I svarpåstand kan vi tilføje vores egne mønsterstrenge og derefter sammenligne dem med svarene modtaget fra en server. For eksempel, I ved alle, at svarkoden er 200, når enhver anmodning returnerer noget svar med succes. Så hvis vi tilføjer mønsterstreng 'Response Code = 202', skal testtilfældet mislykkes.

Se nedenstående skærmbilleder for at tilføje svarskodepåstand.

Nu, når testen kører, viser den resultatet med rød farve, der angiver, at påstandsresultaterne mislykkedes.

Påstand om varighed

Varighedskrav er meget vigtigt og validerer, at serveren reagerede inden for en given tid. Dette kan bruges i scenarier, hvor vi skal prøve 100 anmodninger og sikre, at hver gang svar modtages inden for den benchmarkede grænse.

Sag : 10 brugere rammer samtidig “google.com” -serveren, og varighedskrav er indstillet til 1000 ms. Se nedenstående skærmbilleder:

XML Assertion valideres, hvis svardata har korrekt XML-dokument i sig, og HTML Assertion verificerer HTML-syntaksen for svaret, der modtages fra en server.

Config Elements

Anmodninger, der sendes til serveren, kan parametriseres yderligere ved hjælp af nogle konfigurationselementer, der udføres før den aktuelle anmodning. Et simpelt eksempel på det kan være at læse værdier for en variabel fra en CSV-fil, som CSV-datasætkonfig bruges til.

Nedenfor er nogle af de vigtige konfigurationselementer, der bruges i performance test af web- og mobilapplikationer

• CSV-datasætkonfig.
• Brugerdefinerede variabler
• HTTPS anmoder om standard
• HTTPS Cache Manager
• HTTPS Cookie Manager

CSV-datasætkonfig

CSV-datasætkonfiguration hjælper Jmeter med at vælge værdier for nogle parametre fra en CSV-fil i stedet for at videregive forskellige parametre i hver separat anmodning. For eksempel, hvis vi har brug for at teste loginfunktionalitet med et andet sæt brugere og adgangskoder, kan vi oprette to kolonner i en CSV-fil og indtaste værdierne der, så JMeter kan vælge en for hver anmodning, der sendes til serveren.

Nedenfor er strømmen af ​​brug af CSV-datasæt konfigurationen til at teste vejr-API for forskellige byer i Indien.

• Tilføjelse af CSV-datasætkonfigurationselement til testplan

• Opretter CSV-fil
• Videregive variabel i anmodningsparameteren. APPID-parameteren kan genereres dynamisk fra http://openweathermap.org/appid

• Kører testen og ser resultaterne.

Brugerdefinerede variabler

Det hjælper Jmeter med at vælge værdier fra en foruddefineret variabel. For eksempel, understøtter, at du har brug for at oprette en testplan, hvor du skal tilføje mange HTTP-anmodninger på den samme URL, og der kan være et scenarie, hvor klienten planlægger at migrere den senere til en anden URL. Så for at undgå at opdatere URL i hver anmodning Vi kan fortælle JMeter at vælge URL'en fra en UDV (brugerdefineret variabel), som senere kan opdateres til at håndtere alle anmodninger om opdateret URL.

Så for at undgå opdatering af URL i hver anmodning kan vi bede JMeter om at vælge URL'en fra en UDV (brugerdefineret variabel), som senere kan opdateres for at håndtere alle anmodninger om opdateret URL.

HTTP-anmodningsstandarder

Dette konfigurationselement er meget nyttigt til at specificere standardværdierne for https-anmodninger. For at guide dig mere, tag et eksempel, hvor vi har brug for at ramme 50 forskellige anmodninger på google server. I dette scenarie, hvis vi tilføjer en HTTP-anmodningsstandard, behøver vi ikke angive et servernavn, sti eller andre egenskaber som portnummer, forbindelse timeout egenskaber. Uanset hvad der er specificeret i HTTP-anmodningens standardkonfigurationselement, arves alle HTTP-anmodninger.

I dette scenarie, hvis vi tilføjer en HTTP-anmodningsstandard, behøver vi ikke angive et servernavn, sti eller andre egenskaber som portnummer, forbindelses timeout-egenskaber. Uanset hvad der er specificeret i HTTP-anmodningens standardkonfigurationselement, arves alle HTTP-anmodninger.

Se nedenfor, hvordan du tilføjer HTTP-anmodningsstandard og angiver server og sti.

HTTP Cache Manager og HTTP Cookie Manager bruges til at få JMeter til at opføre sig som en browser i realtid. HTTP Cache-manager kan rydde cache efter hver anmodning, mens den anden kan administrere cookiesindstillingerne.

Logiske controllere og timere

Logiske controllere og timere hjælper Jmeter med at kontrollere strømmen af ​​transaktioner. Timere sikrer forsinkelsen i hver tråd, hvis det er nødvendigt at teste en server. For eksempel, hvis vi har brug for FTP-anmodning for at vente i 5 sekunder efter HTTP-anmodning er afsluttet, kan vi tilføje timer der.

Logiske controllere bruges til at definere strømmen af ​​anmodninger, der sendes til serveren. Det kan også lade dig gemme anmodninger om hvert modul separat, såsom login og logout.

Konklusion

Nu skal du alle have gjort dig bekendt med komponenterne i JMeter og har prøvet at bruge det og skal stå over for nogle problemer. I den næste artikel dækker vi nogle realtidspræstationsscenarier, der dækker mobilitetsdomæne, så du alle får mere praktisk viden om JMeter.

Bliv hængende! Næste artikel hjælper dig med at styre dine anmodninger samt analysere resultater og sammenligne med benchmarks for præstationstest.

=>Fortsæt med at læse del III: JMeter-processorer og -controllere

bedste mp3-afspiller downloader til android

=> Klik her for JMeter Tutorials: Den komplette gratis træning på JMeter (20+ videoer)

Anbefalet læsning

• Sådan opnås JMeter-korrelation med eksempel
• Jmeter testplan og WorkBench
• Arbejde med FTP-anmodning i JMeter
• Top 5 JMeter-plugins og hvordan man bruger dem (med eksempler)
• JMeter Timers: Konstant, BeanShell og Guassian tilfældig timer
• Arbejde med HTTP-anmodninger i JMeter
• Jmeter-controllere del 1
• Jmeter-controllere del 2