Meniu

Descriere detaliată a componentelor JMeter

detail description jmeter components

Încercați Instrumentul Nostru Pentru Eliminarea Problemelor

Revizuirea componentelor Jmeter (partea II):

=> Aceasta face parte din seria de formare JMeter. Vedeți lista tuturor tutorialelor din această serie aici .

Sper că toți trebuie să fi trecut prin Introducere și instalare JMeter pana acum. Pe măsură ce continuăm cu următorul din serie, este foarte recomandat ca toți să instalați JMeter și să practicați unul lângă altul.

În acest tutorial, cititorii se vor familiariza cu toate componentele JMeter și modul de utilizare a acestora în planul de testare pentru a acoperi toate scenariile posibile de testare a performanței pentru a testa AUT (Application Under Test).

JMeter

Elementele lui Jmeter fuseseră enumerate în articolul anterior.

Ce veți învăța:

Componentele JMeter

Penning din nou pentru referință:

  • Planul de testare
  • ThreadGroup
  • Probele
  • Ascultători
  • Banc de lucru
  • Afirmații
  • Element de configurare
  • Controlere logice
  • Temporizator

Toate componentele majore ale Jmeter, cum ar fi Thread Group, Samplers, Listeners și Config Elements, sunt explicate în detalii mai târziu în articol.

Vă rugăm să consultați diagrama de flux de mai jos pentru a înțelege fiecare componentă și relația lor cu module specifice JMeter.

Diagrama fluxului Jmeter

Acum am începe să atingem fiecare componentă a Jmeter împreună cu cazurile de utilizare doar pentru a cunoaște cum funcționează și cum pot implementa testerii acesteia în testarea lor. Vă rugăm să rețineți că nu vom acoperi toți Samplerii, ascultătorii din acest articol. Vom lucra la cele mai utilizate și ne vom odihni în articolul următor atunci când vom crea planuri de testare în timp real.

Planul de testare

Așa cum un simplu plan de testare în Testarea software-ului constă din toți pașii care execută scriptul, planul de testare al JMeter are același scop. Tot ceea ce este inclus într-un plan de testare este executat într-o secvență de sus în jos sau conform secvenței definite în planul de testare.

Planul de testare poate fi cât se poate de simplu, cu Just ThreadGroup, Sampler și Listener și începe să devină mai complex de îndată ce începeți să adăugați mai multe elemente precum elemente de configurare, preprocesoare sau controlere.

După cum știm cu toții că JMeter măsoară performanța generând utilizatori virtuali sau fire care ating serverul testat ca și cum utilizatorii reali trimit cereri către un server. Prin urmare, fiecare plan de testare ar trebui să aibă utilizatori virtuali sau grup de fire așa cum îi numim noi în termenii JMeter.

cum se implementează graficul în java

Puncte importante despre planul de testare:

  • Planul de testare trebuie salvat înainte de a rula
  • Fișierele Jmeter sau planurile de testare sunt salvate sub formă de. Fișiere de extensie JMX
  • De asemenea, puteți salva părți din Planul de testare ca selecție diferită. De exemplu, Dacă doriți să salvați HTTP Request Sampler cu Listener, îl puteți salva ca Fragment de test, astfel încât să poată fi folosit și în alte scenarii de testare
  • Elementele din WorkBench nu sunt salvate cu Test Plan

Grup de fire

Grupul de fire este un grup de utilizatori care vor lovi serverul testat fie simultan, fie într-o anumită secvență predefinită. Grupul de fire poate fi adăugat la Planul de testare făcând clic dreapta pe planul de testare. JMeter este toate „lucruri cu clic dreapta”, veți obține toate opțiunile cu clic dreapta.

Puteți redenumi numele grupului de fire în propriul dvs. nume. Trebuie doar să schimbați numele și să faceți clic oriunde în afara ferestrei Planului de testare, veți vedea numele schimbându-se.

Vedeți mai jos captura de ecran pentru adăugarea grupurilor de fire

(Notă: Faceți clic pe orice imagine pentru vizualizare mărită)

Adăugarea grupului de fire

Este foarte important să vă configurați grupul de fire conform condițiilor de testare.

De exemplu, dacă doriți să testați cum se comportă un server web atunci când 100 de utilizatori îl accesează simultan, puteți seta Grupul de fire după cum urmează:

Configurați grupul de fire

Practic, există trei parametri principali care trebuie să fie configurați pentru a genera încărcare reală sau utilizatori virtuali:

  • Număr de fire (utilizatori) - Definește numărul de utilizatori virtuali. În scopul testării, ar trebui să generăm doar o cantitate limitată de încărcare, deoarece generarea unui volum imens simultan ar însemna consumarea multor fire care pot duce în cele din urmă la o utilizare ridicată a procesorului.
  • Perioada Ramp Up - Acest câmp este foarte important în controlul generării de sarcină. Perioada de rampa a definit perioada de timp în care va fi generată încărcarea totală.

Exemplul 1:

Exemplu nr de utilizatori

  • Înseamnă că toți cei 10 utilizatori vor accesa simultan serverele imediat ce se execută un test

Exemplul 2:

Exemplu Ramp Up

  • Trebuie să fi observat cu toții căsuța „Scheduler” din captura de ecran de mai sus. În cazul în care doriți ca testul dvs. să ruleze la un anumit moment mai târziu, puteți seta temporizările, după cum puteți vedea și în captura de ecran de mai jos. Înseamnă că la fiecare 1 sec, un nou utilizator va atinge serverul. Încărcarea nu va fi concurentă, dar va fi în trepte. Prin 10aîn al doilea rând, toți utilizatorii ar fi atins solicitarea.
  • Numărul de bucle - Definește de câte ori va executa Thread Group. Dacă bifați caseta de selectare Forever, testul dvs. va rula definitiv dacă nu îl opriți manual. Acest lucru poate fi folosit pentru a testa ceva de genul „Dacă serverul dvs. nu se blochează la încărcare continuă timp de câteva minute”.

Grup de fire de programare

Probele

Deci, de unde știe un Jmeter ce tip de cerere a fost trimisă către server ???

  • Este prin Samplers. Eșantioanele sunt obligatorii pentru a fi adăugate la un plan de testare, deoarece numai acesta îi poate informa lui Jmeter ce tip de cerere trebuie să meargă la ce server și cu orice parametri predefiniți sau nu. Solicitările ar putea fi HTTP, HTTP (s), FTP, TCP, SMTP, SOAP etc.

Eșantioanele pot fi adăugate numai la grupul de fire, nu direct sub Planul de testare, deoarece grupurile de fire trebuie să utilizeze un eșantionator pentru a trimite o cerere la adresa URL a serverului testat. Eșantionatorul poate fi adăugat prin cale Grup de fire -> Sampler -> Cerere HTTP.

Solicitări HTTP

Acestea sunt cele mai frecvente solicitări trimise către servere. Spune, de exemplu, vrem să atingă 100 de utilizatori https://www.google.com simultan, acest lucru se poate face așa cum este descris în captura de ecran de mai jos:

Adăugarea cererii HTTP

  • Calea este navigarea în interiorul site-ului principal. De exemplu, dacă dorim să accesăm http://www.google.com/gmail, atunci putem seta „/ Gmail” în cale și odihna rămâne aceeași
  • Nu este necesar să tastați „www” în numele serverului
  • Numărul portului este utilizat dacă utilizați orice server proxy
  • Timeout Connect și Response pot fi setate dacă doriți să aveți un punct de referință pentru timpul de conectare la server și timpul de răspuns. Solicitarea dvs. va eșua dacă serverul dvs. are nevoie de mai mult timp pentru a trimite răspuns decât cel configurat
  • De asemenea, puteți configura parametrii de trimis împreună cu solicitarea dvs. De exemplu: În unele cazuri, poate fi necesar să trimiteți jeton de autorizare împreună cu solicitarea dvs., așa că ați făcut adăugarea acestora în cererea HTTP după cum urmează:

Parametrizarea cererii HTTP

Solicitări FTP

Căi-> Plan de testare> Grup de fire-> Sampler-> Cerere FTP

FTP înseamnă Protocol de transfer de fișiere și este folosit pentru a încărca sau descărca un fișier de pe server. Firele JMeter trimit cereri către serverele FTP pentru a încărca sau descărca fișiere de acolo și măsoară performanța.

Solicitare FTP

Solicitare FTP

  • Fișier local este locația în care trebuie să salvați fișierul descărcat
  • Utilizați opțiunea GET dacă descărcați de pe serverul FTP
  • Opțiunea POST utilizator dacă încărcați orice fișier pe serverul FTP

Avem mulți ascultători care vor fi acoperiți atunci când vom trece prin niște planuri de testare reale, care constau în samplere, ascultători, elemente de configurare etc.

Ascultători

Deci, până acum am văzut puțini eșantionatori care trimiteau cereri către server, dar nu am analizat încă răspunsul. Testarea performanței se referă la analizarea răspunsurilor serverului sub diferite forme și apoi prezentarea acelorași pentru client.

Ascultătorii sunt folosiți pentru a afișa rezultatele execuției testului, astfel încât testerii să cunoască statisticile. Avem în jur de 15 ascultători în Jmeter, dar cei mai des folosiți sunt table, copac și Graph.

Vizualizați rezultatele în tabel:

Aceasta este cea mai frecvent utilizată și ușor de înțeles forma de ascultători. Afișează rezultatul sub formă de tabel cu câțiva parametri de performanță importanți.

Ascultătorii pot fi adăugați direct în planul de testare sau sub un eșantionator. Diferența este că, atunci când adăugați ascultător sub un eșantionator, acesta va afișa doar rezultatele eșantionatorului respectiv. Dacă adăugăm sampler direct sub planul de testare, acesta afișează rezultatul pentru toate Sampler-ul din ierarhie.

Captura de ecran de mai jos pentru referință:

AAdăugarea Ascultătorului de rezultate

Rezultatele sunt afișate mai jos:

Rezultatele tabelului

  • Latență : Este momentul în care se primește prima informație, adică se primește primul octet de date
  • Conectați timpul : Este timpul necesar pentru stabilirea conexiunii cu serverul
  • Timp de probă : Este timpul necesar pentru a primi date complete
  • Probă - Secvența numărului eșantionului
  • Octet - Dimensiunea datelor primite.

Vizualizați rezultatele în arbore:

Acesta este un alt ascultător cel mai frecvent utilizat și oferă informații detaliate cu cerere și răspuns. Se poate vizualiza și pagina HTML redată ca răspuns în afară de vizualizarea Json, XML, Text, RegEx.

Este foarte util, deoarece testerii pot face afirmații cu privire la răspunsul primit pentru a se asigura că testul a trecut. Rezultatele Jmeter arată în continuare „Pass” chiar dacă răspunsul nu este dorit.

De exemplu: Spuneți, am accesat cererea HTTP pe orice site web www.xyz.com și, ca răspuns, ne așteptăm la XYZ sau în cuvinte simple, când accesăm această pagină, pagina de pornire a companiei se deschide cu numele său. Dacă nu am făcut o afirmație, Jmeter va afișa în continuare rezultate, deoarece accesarea a fost trimisă pe server.

Adăugarea unui ascultător de vizualizare în arbore

Vă rugăm să consultați mai jos pentru a afla formatul rezultatelor:

Vizualizați Arborele Rezultatelor

Pentru vizualizarea paginii HTML ca răspuns, faceți clic pe meniul derulant din panoul din stânga și apoi selectați „HTML”, Navigați la fila de răspuns și verificați pagina care este returnată ca răspuns al serverului.

Rezultatele arborelui HTML

Banc de lucru

Un banc de lucru este un loc unde puteți stoca acele elemente care nu sunt utilizate în planul dvs. de test curent, dar care pot fi copiate ulterior lipite în el. Când salvați fișierul JMeter, componentele care sunt prezente în bancul de lucru nu sunt salvate automat. Trebuie să le salvați separat făcând clic dreapta și să alegeți opțiunea „Salvare ca”.

S-ar putea să vă gândiți cu toții la ce folosește bancul de lucru, oricum este ușor să adăugați orice componentă direct la Planul de testare Jmeter.

Motivul de a avea un banc de lucru a fost că utilizatorul ar putea face unele experimente și să încerce noi scenarii. După cum știm deja, elementele din bancul de lucru nu sunt salvate, astfel încât un utilizator poate folosi literalmente orice și apoi arunca. Dar, există unele „Componente non-test” care sunt disponibile numai în WorkBench.

Acestea sunt enumerate aici:

  • Server Mirror HTTP
  • HTTP (s) Test Script Recorder
  • Afișarea proprietății

HTTP (s) Test Script Recorder este cel mai important element non-test utilizat în JMeter. Ajută testerii să înregistreze scriptul și apoi să configureze sarcina pentru fiecare tranzacție.

Jmeter înregistrează numai cererea trimisă la server. Nu vă confundați cu funcționalitatea „Înregistrați și redați” a QTP / Selenium. Toate cererile sunt înregistrate, iar testerii pot aplica sarcina dorită asupra acestora pentru a vedea comportamentul.

Adăugarea Script Recorder

Acest element este foarte important pentru scenariile în care testerii nu știu ce se întâmplă cu toate cererile din aplicația lor. Aceștia pot folosi înregistratorul de scripturi Http (s) pentru a înregistra aplicația în curs de testare.

Testarea performanței aplicațiilor mobile se poate face și în acest mod prin configurarea proxy-ului JMeter și apoi înregistrarea solicitărilor pe care aplicația noastră mobilă le trimite serverului. Procedura pas cu pas pentru testarea performanței mobile va fi explicată în articolul următor.

Afirmații

Până acum, am prezentat modul în care JMeter lovește serverul și modul în care răspunsurile sunt afișate prin intermediul ascultătorilor. Pentru a ne asigura că răspunsul primit este corect și conform așteptărilor, trebuie să adăugăm afirmații. Afirmațiile sunt pur și simplu validări pe care trebuie să le punem pe răspunsuri pentru a compara rezultatele.

Mai jos sunt tipurile de afirmații utilizate în mod obișnuit:

  • Afirmație de răspuns
  • Afirmarea duratei
  • Afirmarea mărimii
  • Afirmare XML
  • Afirmare HTML

Afirmație de răspuns

În Response Assertion, putem adăuga propriile noastre șiruri de modele și apoi le putem compara cu răspunsurile primite de la un server. De exemplu, știți cu toții că codul de răspuns este 200 atunci când orice solicitare returnează un răspuns cu succes. Deci, dacă adăugăm șirul de model „Response Code = 202”, atunci testul ar trebui să eșueze.

Vă rugăm să consultați mai jos capturile de ecran pentru a adăuga afirmarea Codului de răspuns.

Adăugarea afirmației de răspuns

Verificarea codului de răspuns

Acum, când rulează testul, acesta arată rezultatul cu Culoare roșie, indicând faptul că rezultatele afirmării nu au reușit.

Vizualizarea rezultatelor afirmării

Afirmarea duratei

Afirmarea duratei este foarte importantă și confirmă faptul că serverul a răspuns într-un anumit timp. Acest lucru poate fi utilizat în scenarii în care trebuie să prelevăm 100 de solicitări și să ne asigurăm că de fiecare dată când răspunsul este primit în limita de referință.

Caz : 10 utilizatori accesează simultan serverul „google.com”, iar afirmația duratei este setată la 1000 ms. Vă rugăm să vedeți mai jos capturile de ecran:

Adăugarea afirmării duratei

Rezultatele afirmării duratei

XML Assertion validează dacă datele de răspuns conțin un document XML corect și HTML Assertion verifică sintaxa HTML a răspunsului primit de la un server.

Afirmare HTML

Afirmare nouă HTML

Elemente de configurare

Solicitările trimise către server pot fi parametrizate suplimentar folosind unele elemente de configurare care sunt executate înainte de cererea reală. Un exemplu simplu al acestuia ar putea fi citirea valorilor unei variabile dintr-un fișier CSV pentru care este utilizat CSV Data Set Config.

Mai jos sunt câteva dintre elementele importante de configurare utilizate în testarea performanței aplicațiilor web și mobile

  • Configurare set de date CSV.
  • Variabile definite de utilizator
  • Solicitări HTTPS implicite
  • Manager cache cache HTTPS
  • Administrator de cookie-uri HTTPS

Configurare set de date CSV

Configurarea setului de date CSV îl ajută pe Jmeter să aleagă valorile unor parametri dintr-un fișier CSV, mai degrabă decât să transmită parametri diferiți în fiecare cerere separată. De exemplu, dacă trebuie să testăm funcționalitatea de conectare cu un set diferit de utilizatori și parole, atunci putem crea două coloane într-un fișier CSV și putem introduce valorile acolo, astfel încât JMeter să poată alege una pentru fiecare cerere trimisă la server.

Mai jos este fluxul de utilizare a datelor CSV setat config pentru a testa API meteo pentru diferite orașe din India.

  • Adăugarea elementului de configurare a setului de date CSV la planul de testare

Adăugarea configurației de date CSV

Se încarcă fișierul de date CSV

Variabila de trecere

  • Rularea testului și vizualizarea rezultatelor.

Variabile definite de utilizator

Ajută Jmeter să aleagă valori dintr-o variabilă predefinită. De exemplu, susțineți că trebuie să creați un plan de test în care trebuie să adăugați multe solicitări HTTP pe aceeași adresă URL și ar putea exista un scenariu în care clientul intenționează să-l migreze ulterior către o adresă URL diferită. Deci, pentru a evita actualizarea URL-ului în fiecare solicitare îi putem spune lui JMeter să aleagă adresa URL dintr-o UDV (Variabilă definită de utilizator) care poate fi actualizată ulterior pentru a gestiona toate cererile către adresa URL actualizată.

Deci, pentru a evita actualizarea URL-ului în fiecare solicitare, putem spune JMeter să aleagă URL-ul dintr-o UDV (Variabilă definită de utilizator), care poate fi actualizată ulterior pentru a gestiona toate cererile către adresa URL actualizată.

Variabile definite de utilizator

Implicit solicitare HTTP

Acest element de configurare este foarte util pentru specificarea valorilor implicite ale cererilor https. Pentru a vă ghida mai mult, luați un exemplu în care trebuie să atingem 50 de cereri diferite pe serverul google. În acest scenariu, dacă adăugăm o cerere implicită HTTP, atunci nu trebuie să specificăm un nume de server, o cale sau alte proprietăți precum numărul portului, conexiunea expirarea proprietăților. Orice este specificat în elementul de configurare implicit HTTP Request este moștenit de toate cererile HTTP.

În acest scenariu, dacă adăugăm o cerere implicită HTTP, atunci nu trebuie să specificăm un nume de server, o cale sau alte proprietăți precum numărul portului, proprietățile de expirare a conexiunii. Orice este specificat în elementul de configurare implicit HTTP Request este moștenit de toate cererile HTTP.

Vedeți mai jos cum să adăugați HTTP Request Default și să specificați serverul și calea.

Adăugarea implicită a cererii HTTP

Manager cache cache HTTP și HTTP Cookie Manager sunt folosite pentru a face JMeter să se comporte ca un browser în timp real. Managerul de cache HTTP poate șterge memoria cache după fiecare cerere, în timp ce cealaltă poate gestiona setările cookie-urilor.

Controlere și temporizatoare logice

Controlerele și cronometrele logice îl ajută pe Jmeter să controleze fluxul de tranzacții. Cronometrele asigură întârzierea fiecărui thread dacă este necesar să testați orice server. De exemplu, dacă avem nevoie de o solicitare FTP pentru a aștepta 5 secunde după finalizarea cererii HTTP, putem adăuga temporizator acolo.

Controlerele logice sunt utilizate pentru a defini fluxul de cereri care sunt trimise către server. De asemenea, vă poate permite să stocați separat cererile pentru fiecare modul, cum ar fi autentificarea și deconectarea.

Concluzie

Până acum, trebuie să vă familiarizați cu componentele JMeter și ați încercat să îl utilizați și trebuie să vă confruntați cu anumite probleme. În articolul următor, vom acoperi câteva scenarii de testare a performanței în timp real care acoperă domeniul mobilității, astfel încât să obțineți cu toții mai multe cunoștințe practice despre JMeter.

Rămâneți aproape! Următorul articol vă va ajuta să gestionați solicitările dvs., precum și să analizați rezultatele și să comparați cu criteriile de testare a performanței.

=>Continuați să citiți partea III: Procesoare și controlere JMeter

ce rulează dbms pe un computer

=> Faceți clic aici pentru tutoriale JMeter: Instruirea gratuită completă pe JMeter (peste 20 de videoclipuri)

Lectură recomandată

^