Detaljbeskrivelse av JMeter-komponenter

detail description jmeter components

Gjennomgang av Jmeter-komponenter (del II):

hvilken type test som brukes for å bekrefte at alle programmer i et program fungerer riktig

=> Dette er en del av JMeter-treningsserien. Se listen over alle opplæringene i denne serien her .

Håper dere alle må ha gått gjennom JMeter Introduksjon og installasjon nå. Når vi fortsetter med neste i serien, anbefales det at dere alle må installere JMeter og øve side om side.

I denne opplæringen vil leserne bli kjent med alle komponenter i JMeter og hvordan du bruker dem i testplanen for å dekke alle mulige ytelsestest scenarier for å teste AUT (Application Under Test).

Elementer av Jmeter hadde blitt listet opp i forrige artikkel.

Hva du vil lære:

• Komponenter av JMeter
  • Testplan
  • Trådgruppe
  • Prøver
  • HTTP-forespørsler
  • FTP-forespørsler
  • Lyttere
  • Arbeidsbenk
  • Påstander
    • Svarpåstand
    • Varighet påstand
  • Config Elements
    • CSV-datasettkonfig
    • Brukerdefinerte variabler
    • Standardinnstillinger for HTTP-forespørsel
  • Logikkontrollere og tidtakere
  • Konklusjon
  • Anbefalt lesing

Komponenter av JMeter

Penning ned igjen for din referanse:

• Testplan
• Trådgruppe
• Prøver
• Lyttere
• Arbeidsbenk
• Påstander
• Config Element
• Logikkontrollere
• Timer

Alle hovedkomponenter i Jmeter som trådgruppe, samplere, lyttere og konfigurasjonselementer blir forklart i detaljer senere i artikkelen.

Se flytskjemaet nedenfor for å forstå hver komponent og deres forhold til spesifikke moduler i JMeter.

Nå begynner vi å berøre hver komponent i Jmeter sammen med brukstilfeller bare for å vite hvordan det fungerer, og hvordan kan testere implementere disse i testingen. Vær oppmerksom på at vi ikke dekker alle samplere, lyttere i denne artikkelen. Vi vil jobbe med de mest brukte og vil hvile i neste artikkel når vi lager testplaner i sanntid.

Testplan

Akkurat som en enkel testplan i Software Testing består av alle trinn som utfører skriptet, har JMeters testplan samme formål. Alt som er inkludert i en testplan utføres i en sekvens som er topp til bunn eller i henhold til den definerte sekvensen i testplanen.

Testplan kan være så enkel som den kan være, med Just ThreadGroup, Sampler og Listener, og den begynner å bli mer kompleks så snart du begynner å legge til flere elementer som konfigurasjonselementer, forprosessorer eller kontrollere.

Som vi alle vet at JMeter måler ytelsen ved å generere virtuelle brukere eller tråder som treffer serveren under test som om virkelige brukere sender forespørsler til en server. Derfor bør alle testplaner ha virtuelle brukere eller trådgrupper som vi kaller dem i JMeters termer.

Viktige punkter om testplan:

• Testplanen skal lagres før du kjører
• Jmeter-filer eller testplaner lagres i form av. JMX filendelser
• Du kan også lagre deler av Testplan som det forskjellige utvalget. For eksempel, Hvis du vil lagre HTTP Request Sampler med Listener, kan du lagre den som Test Fragment slik at den også kan brukes i andre testscenarier.
• Elementer i WorkBench lagres ikke med testplan

Trådgruppe

Trådgruppe er en gruppe brukere som vil treffe serveren som testes enten samtidig eller i en forhåndsdefinert sekvens. Trådgruppen kan legges til i testplanen ved å høyreklikke på testplanen. JMeter er alt “Høyreklikk-ting”, du får alle alternativene med høyreklikk.

Du kan gi nytt navn til trådgruppen til ditt eget. Bare endre navnet og klikk hvor som helst utenfor testplanvinduet, du vil se navnet endres.

Se skjermbildet nedenfor for å legge til trådgrupper

(Merk: Klikk på et hvilket som helst bilde for forstørret visning)

Det er veldig viktig å konfigurere trådgruppen din i henhold til testforholdene.

For eksempel, Hvis du vil teste hvordan en webserver oppfører seg når 100 brukere treffer den samtidig, kan du angi trådgruppen som nedenfor:

I utgangspunktet er det tre hovedparametere som må konfigureres for å generere faktisk belastning eller virtuelle brukere:

• Antall tråder (brukere) - Den definerer antall virtuelle brukere. For testformål, bør vi generere bare en begrenset mengde belastning, da å generere stort volum på en gang vil bety å forbruke mange tråder som til slutt kan føre til høy CPU-utnyttelse.
• Opprampingsperiode - Dette feltet er veldig viktig for å kontrollere lastgenerering. Ramp up period definerte hvor lang tid den totale belastningen skal genereres.

Eksempel 1:

• Det betyr at alle 10 brukere vil treffe servere samtidig så snart en test er kjørt

Eksempel 2:

• Dere må alle ha lagt merke til avmerkingsboksen 'Planlegger' i skjermbildet ovenfor. I tilfelle du vil at testen skal kjøre på et bestemt tidspunkt senere, kan du stille timingene som du også kan se i skjermbildet nedenfor. Det betyr at en ny bruker treffer hvert eneste sekund. Belastningen vil ikke være samtidig, men vil være i trinn. Av 10^thfor det andre, ville alle brukere slått forespørselen.
• Loop Count - Den definerer antall ganger trådgruppen skal utføre. Hvis du merker av for evig avkrysningsruten, vil testen kjøre for alltid med mindre du stopper den manuelt. Dette kan brukes til å teste noe sånt som 'Hvis serveren din ikke krasjer ved kontinuerlig belastning i noen minutter'.

Prøver

Så hvordan vet en Jmeter hvilken type forespørsel som er sendt til serveren ???

• Det er gjennom samplere. Samplere er et must å legge til i en testplan, da bare den kan fortelle Jmeter hvilken type forespørsel som trengs for å gå til hvilken server og med eventuelle forhåndsdefinerte parametere eller ikke. Forespørsler kan være HTTP, HTTP (er), FTP, TCP, SMTP, SOAP etc.

Samplere kan bare legges til i trådgruppen, ikke direkte under testplan, da trådgrupper må bruke en sampler for å sende en forespørsel til server-URL under test. Sampleren kan legges til etter sti Trådgruppe -> Sampler -> HTTP-forespørsel.

HTTP-forespørsler

Dette er de vanligste forespørslene som sendes til serverne. Si, for eksempel, vi vil at 100 brukere skal treffe https://www.google.com samtidig kan dette gjøres som beskrevet i skjermbildet nedenfor:

• Stien er navigasjonen på hovednettstedet. Hvis vi for eksempel vil slå http://www.google.com/gmail, kan vi sette '/ Gmail' i bane, og resten forblir den samme
• Trenger ikke å skrive “www” i servernavnet
• Portnummer brukes hvis du bruker en proxy-server
• Tidsavbruddstilkobling og respons kan stilles inn hvis du vil ha en referanse på serverforbindelsestid og responstid. Forespørselen din mislykkes hvis serveren din tar mer tid å sende svar enn den konfigurerte
• Du kan også konfigurere parametere som skal sendes med forespørselen din. For eksempel: I noen tilfeller kan det hende du må sende autorisasjonstoken med forespørselen din, så du har lagt dem til i HTTP-forespørsel som nedenfor:

FTP-forespørsler

Sti-> Testplan-> Trådgruppe-> Sampler-> FTP-forespørsel

FTP står for File Transfer Protocol og brukes til å laste opp eller laste ned en fil fra serveren. JMeters tråder sender forespørsler til FTP-servere for å laste opp eller laste ned filer derfra og måler ytelsen.

• Lokal fil er stedet der du trenger å lagre den nedlastede filen
• Bruk GET-alternativet hvis du laster ned fra FTP-server
• Bruker POST-alternativ hvis du laster opp en fil på FTP-serveren

Vi har mange lyttere som vil bli dekket når vi går gjennom noen virkelige testplaner som består av samplere, lyttere, konfigurasjonselementer etc.

Lyttere

Så til nå har vi sett få prøvetakere som sender forespørsler til serveren, men har ikke analysert svaret ennå. Ytelsestesting handler om å analysere serverresponser i forskjellige former og deretter presentere det samme for klienten.

Lyttere brukes til å vise resultatene av testutførelse, slik at testere blir kjent med statistikken. Vi har rundt 15 lyttere i Jmeter, men mest brukte er bord, tre og graf.

Se resultatene i tabell:

Dette er den mest brukte og lett forståelige formen for lyttere. Det viser resultatet i form av tabell med noen viktige ytelsesparametere.

Lyttere kan legges til direkte under testplan eller under en sampler. Forskjellen er at når du legger til lytter under en sampler, vil den bare vise resultatene av den sampleren. Hvis vi legger til sampler direkte under testplanen, viser det resultatet for alle Sampler opp i hierarkiet.

Skjermbildet nedenfor for din referanse:

Du ser resultatene som vist nedenfor:

• Ventetid : Det er tiden da den første informasjonen mottas, dvs. den første databyen mottas
• Koble til tid : Det er tiden det tar å opprette forbindelse til serveren
• Eksempel tid : Det er tiden det tar å motta komplette data
• Prøve - Sekvens av prøvenummer
• Byte - Størrelse på mottatte data.

Se resultatene i treet:

Dette er en annen mest brukte lyttere og gir detaljert informasjon med forespørsel og svar. Man kan også vise HTML-siden som er gjengitt som svar bortsett fra å se Json, XML, Text, RegEx.

Det er veldig nyttig ettersom testere kan uttale seg om mottatt respons for å sikre at testen er bestått. Jmeter-resultatene viser fremdeles 'Pass' selv om responsen ikke er ønsket.

For eksempel: Si, vi treffer HTTP-forespørsel på ethvert nettsted www.xyz.com og som svar forventer vi XYZ eller med enkle ord når vi treffer denne siden, åpner selskapets hjemmeside med navnet. Hvis vi ikke har påstått, vil Jmeter fremdeles vise resultater siden treffet har gått til serveren.

Se nedenfor for å vite formatet på resultatene:

For å vise HTML-siden som svar, klikk på rullegardinmenyen i venstre rute og velg deretter 'HTML', naviger til svarfanen og sjekk siden som returneres som serverens svar.

Arbeidsbenk

En arbeidsbenk er et sted hvor du kan lagre elementene som ikke er i bruk i din nåværende testplan, men som senere kan kopieres inn i den. Når du lagrer JMeter-filen, lagres ikke komponentene som er tilstede i arbeidsbenken automatisk. Du må lagre dem separat ved å høyreklikke og velge alternativet 'Lagre som'.

Dere tenker kanskje alle hva er bruken av arbeidsbenk, uansett er det enkelt å legge til en hvilken som helst komponent direkte til en Jmeter’s Testplan.

Årsaken til å ha arbeidsbenk var at brukeren kunne gjøre noen eksperimenter og prøve ut nye scenarier. Som vi allerede vet, blir ikke elementer i arbeidsbenken lagret, slik at en bruker bokstavelig talt kan bruke hva som helst og deretter kaste bort. Men det er noen “ikke-testkomponenter” som bare er tilgjengelige i WorkBench.

De er oppført her:

• HTTP speilserver
• HTTP (s) Test Script Recorder
• Eiendomsvisning

HTTP (s) Test Script Recorder er det viktigste ikke-testelementet som brukes i JMeter. Det hjelper testere med å registrere skriptet og deretter konfigurere belastningen for hver transaksjon.

Jmeter registrerer bare forespørselen som er sendt til serveren. Ikke bli forvirret med 'Record and Play' -funksjonaliteten til QTP / Selen. Alle forespørslene blir registrert, og testere kan bruke ønsket belastning på dem for å se oppførselen.

Dette elementet er veldig viktig for scenarier der testere ikke vet hva alle forespørsler skjer fra applikasjonen deres. De kan bruke Http (s) skriptopptaker til å registrere applikasjonen som testes.

Ytelsestesting av mobilapplikasjoner kan også gjøres på denne måten ved å sette opp JMeter proxy og deretter registrere forespørslene som mobilappen vår sender til serveren. Trinn for trinn-prosedyre for mobil ytelsestesting vil bli forklart i neste artikkel.

Påstander

Til nå har vi dekket hvordan JMeter treffer serveren og hvordan svarene vises via lyttere. For å sikre at mottatt respons er riktig og som forventet, må vi legge til påstander. Påstander er ganske enkelt valideringer som vi trenger for å gi svar for å sammenligne resultatene.

Nedenfor er typene påstander som ofte brukes:

• Svarpåstand
• Varighet påstand
• Påstand om størrelse
• XML-påstand
• HTML-påstand

Svarpåstand

I Respons Assertion kan vi legge til våre egne mønsterstrenger og deretter sammenligne dem med svarene du mottar fra en server. For eksempel, alle vet at svarskoden er 200 når en forespørsel returnerer noe svar. Så hvis vi legger til mønsterstreng “Response Code = 202”, skal testsaken mislykkes.

Se skjermbilder nedenfor for å legge til påstand om svarskode.

Nå når testen kjører, viser det resultatet med rød farge som indikerer at påstandsresultatene mislyktes.

Varighet påstand

Varighet påstand er veldig viktig og validerer at serveren reagerte innen en gitt tidsperiode. Dette kan brukes i scenarier der vi trenger å prøve 100 forespørsler og sikre at hver gang svar mottas innenfor referansegrensen.

Sak : 10 brukere treffer samtidig “google.com” -tjeneren og varighetskrav er satt til 1000 ms. Se skjermbilder nedenfor:

XML Assertion validerer hvis responsdata har riktig XML-dokument i seg, og HTML Assertion verifiserer HTML-syntaksen for svaret som mottas fra en server.

Config Elements

Forespørsler sendt til serveren kan parametreres ytterligere ved hjelp av noen konfigurasjonselementer som utføres før selve forespørselen. Et enkelt eksempel på det kan være å lese verdier for en variabel fra en CSV-fil som CSV-datasettkonfig brukes for.

Nedenfor er noen av de viktige konfigurasjonselementene som brukes i ytelsestesting av nett- og mobilapplikasjoner

• CSV-datasettkonfig.
• Brukerdefinerte variabler
• HTTPS ber standard
• HTTPS Cache Manager
• HTTPS Cookie Manager

CSV-datasettkonfig

CSV-datasettkonfigurasjon hjelper Jmeter med å plukke verdier for noen parametere fra en CSV-fil i stedet for å sende forskjellige parametere i hver separate forespørsel. For eksempel, Hvis vi trenger å teste påloggingsfunksjonalitet med et annet sett med brukere og passord, kan vi opprette to kolonner i en CSV-fil og legge inn verdiene der, slik at JMeter kan velge en for hver forespørsel som sendes til serveren.

Nedenfor er strømmen av bruk av CSV-datasett konfigurasjonen for å teste vær-API for forskjellige byer i India.

• Legger til CSV-datasettkonfigurasjonselement til testplan

• Oppretter CSV-fil
• Passerer variabel i forespørselsparameteren. APPID-parameteren kan genereres dynamisk fra http://openweathermap.org/appid

• Kjører testen og viser resultatene.

Brukerdefinerte variabler

Det hjelper Jmeter å velge verdier fra en forhåndsdefinert variabel. For eksempel, støtte at du trenger å lage en testplan der du trenger å legge til mange HTTP-forespørsler på samme URL, og det kan være et scenario der klienten planlegger å migrere den senere til en annen URL, så for å unngå å oppdatere URL i hver forespørsel Vi kan be JMeter velge URL fra en UDV (User Defined Variable) som senere kan oppdateres for å håndtere alle forespørsler om oppdatert URL.

Så, for å unngå oppdatering av URL i hver forespørsel, kan vi be JMeter om å velge URL fra en UDV (User Defined Variable) som senere kan oppdateres for å håndtere alle forespørsler om oppdatert URL.

Standardinnstillinger for HTTP-forespørsel

Dette konfigurasjonselementet er veldig nyttig for å spesifisere standardverdiene for https-forespørsler. For å veilede deg mer, ta et eksempel der vi trenger å treffe 50 forskjellige forespørsler på google server. I dette scenariet, hvis vi legger til en HTTP-forespørselsstandard, trenger vi ikke spesifisere et servernavn, bane eller andre egenskaper som portnummer, tilkobling time out eiendommer. Uansett hva som er spesifisert i konfigurasjonselementet HTTP-forespørsel, arves alle HTTP-forespørsler.

I dette scenariet, hvis vi legger til en HTTP-forespørselsstandard, trenger vi ikke å spesifisere et servernavn, bane eller andre egenskaper som portnummer, egenskapene for tilkoblingstidsavbrudd. Uansett hva som er spesifisert i konfigurasjonselementet HTTP-forespørsel, arves alle HTTP-forespørsler.

Se nedenfor hvordan du legger til HTTP-forespørselsstandard og spesifiserer server og bane.

HTTP Cache Manager og HTTP Cookie Manager brukes til å få JMeter til å oppføre seg som en nettleser i sanntid. HTTP Cache manager kan tømme cache etter hver forespørsel, mens den andre kan administrere innstillingene for informasjonskapsler.

Logikkontrollere og tidtakere

Logikkontrollere og tidtakere hjelper Jmeter med å kontrollere flyten av transaksjoner. Timere sørger for forsinkelsen i hver tråd hvis det er behov for å teste en server. For eksempel, Hvis vi trenger FTP-forespørsel for å vente i 5 sekunder etter at HTTP-forespørsel er fullført, kan vi legge til timer der.

Logikkontrollere brukes til å definere flyten av forespørsler som sendes til serveren. Det kan også la deg lagre forespørsler for hver modul separat, for eksempel pålogging og utlogging.

Konklusjon

Nå må dere alle ha blitt kjent med komponentene i JMeter og har prøvd å bruke den og må møte noen problemer. I den neste artikkelen vil vi dekke noen sanntids ytelsestest-scenarier som dekker mobilitetsdomenet, slik at dere alle får mer praktisk kunnskap om JMeter.

Følg med! Neste artikkel vil hjelpe deg med å håndtere forespørslene dine, samt analysere resultater og sammenligne med referanseverdiene for ytelsestesting.

=>Fortsett å lese del III: JMeter-prosessorer og -kontrollere

beste gratis anti spyware for pc

=> Klikk her for JMeter Tutorials: Komplett gratis trening på JMeter (20+ videoer)

Anbefalt lesing

• Hvordan oppnå JMeter-korrelasjon med eksempel
• Jmeter Testplan og WorkBench
• Arbeide med FTP-forespørsel i JMeter
• Topp 5 JMeter-plugins og hvordan du bruker dem (med eksempler)
• JMeter Timers: Constant, BeanShell And Guassian Random Timer
• Arbeide med HTTP-forespørsler i JMeter
• Jmeter Controllers Del 1
• Jmeter Controllers Del 2