Descripció detallada dels components de JMeter

detail description jmeter components

Revisió de components Jmeter (part II):

=> Això forma part de la sèrie d'entrenaments de JMeter. Vegeu la llista de tots els tutorials d’aquesta sèrie aquí .

Espero que tots hagueu passat pel Introducció i instal·lació de JMeter per ara. A mesura que continuem amb el següent de la sèrie, és molt recomanable que tots hagueu d'instal·lar JMeter i practicar-lo un al costat de l'altre.

llista d’adjacència de gràfics c ++

En aquest tutorial, els lectors es familiaritzaran tots els components de JMeter i com utilitzar-los al pla de prova per cobrir tots els possibles escenaris de proves de rendiment per provar el AUT (Application Under Test).

Els elements de Jmeter havien estat llistats a l'article anterior.

Què aprendreu:

• Components de JMeter
  • Pla de proves
  • Grup de fils
  • Mostrejadors
  • Sol·licituds HTTP
  • Sol·licituds FTP
  • Oients
  • Banc de treball
  • Afirmacions
    • Afirmació de resposta
    • Afirmació de la durada
  • Elements de configuració
    • Configuració del conjunt de dades CSV
    • Variables definides per l'usuari
    • Valors predeterminats de sol·licitud HTTP
  • Controladors i temporitzadors lògics
  • Conclusió
  • Lectura recomanada

Components de JMeter

Tornant a penetrar com a referència:

• Pla de proves
• Grup de fils
• Mostrejadors
• Oients
• WorkBench
• Afirmacions
• Element de configuració
• Controladors lògics
• Temporitzador

Tots els components principals de Jmeter, com ara Thread Group, Samplers, Listeners i Config Elements, s’expliquen amb més detalls a l’article.

Consulteu el diagrama de flux següent per comprendre cada component i la seva relació amb mòduls específics de JMeter.

Ara començaríem a tocar cada component de Jmeter juntament amb casos d’ús només per saber com funciona i com poden els provadors implementar-los en les seves proves. Tingueu en compte que en aquest article no cobrirem tots els oients de mostra. Treballarem sobre els més usats i descansarem en el proper article quan creem plans de prova en temps real.

Pla de proves

De la mateixa manera que un pla de prova simple a la prova de programari consisteix en tots els passos que executen el script, el pla de prova de JMeter té el mateix propòsit. Tot el que s'inclou en un pla de prova s'executa en una seqüència que va de dalt a baix o segons la seqüència definida al pla de prova.

El pla de prova pot ser tan senzill com podria ser, amb Just ThreadGroup, Sampler i Listener i comença a ser més complex tan bon punt comenceu a afegir més elements com ara elements de configuració, preprocessadors o controladors.

Com tots sabem, JMeter mesura el rendiment generant usuaris virtuals o fils que arriben al servidor en proves com si els usuaris reals estiguessin enviant sol·licituds a un servidor. Per tant, cada pla de prova hauria de tenir usuaris virtuals o grup de fils tal com els anomenem en termes de JMeter.

Punts importants sobre el pla de proves:

• El pla de prova s'ha de desar abans d'executar-lo
• Els fitxers Jmeter o els plans de prova es guarden en forma de. Fitxers d'extensió JMX
• També podeu desar parts del pla de prova com a selecció diferent. Per exemple, Si voleu desar el Sampler de sol·licitud HTTP amb Listener, podeu desar-lo com a Fragment de prova perquè es pugui utilitzar també en altres escenaris de prova.
• Els elements de WorkBench no es desen amb el pla de prova

Grup de fils

Thread Group és un grup d'usuaris que copejaran el servidor en proves simultàniament o en una seqüència predefinida. El grup de fils es pot afegir al pla de prova fent clic amb el botó dret al pla de prova. JMeter és tot 'Feu clic amb el botó dret', obteniu totes les opcions amb el clic dret.

Podeu canviar el nom del grup de fils pel vostre. Només heu de canviar el nom i fer clic a qualsevol lloc que hi hagi fora de la finestra del pla de prova. Veureu que el nom canvia.

Consulteu la captura de pantalla següent per afegir grups de fils

(Nota: Feu clic a qualsevol imatge per ampliar-la)

És molt important configurar el vostre grup de fils segons les condicions de prova.

Per exemple, si voleu provar el comportament d'un servidor web quan 100 usuaris el copeguen simultàniament, podeu configurar el grup de fils de la manera següent:

Bàsicament, hi ha tres paràmetres principals que s'han de configurar per generar usuaris de càrrega reals o virtuals:

• Nombre de fils (usuaris) - Defineix el nombre d'usuaris virtuals. A efectes de proves, hauríem de generar només una quantitat limitada de càrrega, ja que generar un volum enorme alhora suposaria consumir molts fils que en última instància poden conduir a una elevada utilització de la CPU.
• Període de pujada - Aquest camp és molt important per controlar la generació de càrrega. El període de pujada va definir la quantitat de temps durant la qual es generarà la càrrega total.

Exemple 1:

• Significa que els 10 usuaris estaran tocant servidors simultàniament tan bon punt s’executi una prova

Exemple 2:

• Tots heu d'haver notat la casella de selecció 'Planificador' a la captura de pantalla superior. En cas que vulgueu que la prova s'executi en un moment concret més tard, podeu definir els temps, tal com també podeu veure a la captura de pantalla següent. Vol dir que cada 1 s, un nou usuari estarà tocant el servidor. La càrrega no serà simultània, però serà en increments. Cap al 10^then segon lloc, tots els usuaris haurien atès la sol·licitud.
• Recompte de bucles - Defineix el nombre de vegades que s'executarà el grup de fils. Si marqueu la casella de selecció Forever, la prova s’executarà per sempre, tret que la pareu manualment. Es pot utilitzar per provar alguna cosa com 'Si el servidor no es bloqueja en càrrega contínua durant uns minuts'.

Mostrejadors

Llavors, com sap un Jmeter quin tipus de sol·licitud s’ha enviat al servidor ???

• És a través de Samplers. Els mostrejadors són imprescindibles per afegir-los a un pla de prova, ja que només pot fer saber a Jmeter quin tipus de sol·licitud ha d’anar a quin servidor i amb qualsevol paràmetre predefinit o no. Les sol·licituds podrien ser HTTP, HTTP (s), FTP, TCP, SMTP, SOAP, etc.

Els mostrejadors només es poden afegir al grup de fils no directament al pla de prova, ja que els grups de fils han d’utilitzar un mostrejador per enviar una sol·licitud a l’URL del servidor que es prova. El mostreig es pot afegir per ruta Grup de fils -> Sampler -> Sol·licitud HTTP.

Sol·licituds HTTP

Aquestes són les sol·licituds més habituals enviades als servidors. Digues, per exemple, volem que arribin a 100 usuaris https://www.google.com simultàniament, es pot fer tal com es descriu a la captura de pantalla següent:

com configurar els fitxers jar per obrir-los amb Java

• El camí és la navegació dins del lloc web principal. Per exemple, si volem accedir a http://www.google.com/gmail, podem establir '/ Gmail' al camí i la resta segueix sent la mateixa
• No cal que escriviu “www” al nom del servidor
• El número de port s’utilitza si utilitzeu qualsevol servidor intermediari
• Es pot configurar el temps d'espera de connexió i resposta si voleu tenir un punt de referència sobre el temps de connexió i el temps de resposta del servidor. La vostra sol·licitud fallarà si el vostre servidor triga més temps a enviar la resposta que la configurada
• També podeu configurar paràmetres per enviar amb la vostra sol·licitud. Per exemple: En alguns casos, és possible que hàgiu d’enviar el testimoni d’autorització amb la vostra sol·licitud, de manera que heu fet afegir-los a la sol·licitud HTTP de la manera següent:

Sol·licituds FTP

Camí-> Pla de prova-> Grup de fils-> Sampler-> Sol·licitud FTP

FTP significa Protocol de transferència de fitxers i s’utilitza per carregar o descarregar un fitxer des del servidor. Els fils de JMeter envien sol·licituds als servidors FTP per penjar o descarregar fitxers des d’allà i mesurar el rendiment.

• El fitxer local és la ubicació on heu de desar el fitxer descarregat
• Utilitzeu l'opció GET si esteu baixant del servidor FTP
• Opció POST d'usuari si esteu penjant algun fitxer al servidor FTP

Tenim molts oients que es cobriran quan passem per alguns plans de prova reals que consisteixen en mostrejadors, oients, elements de configuració, etc.

Oients

Per tant, fins ara hem vist pocs mostrejadors enviant sol·licituds al servidor, però encara no hem analitzat la resposta. Les proves de rendiment consisteixen a analitzar les respostes del servidor en diverses formes i, després, a presentar-les al client.

Els oients s’utilitzen per mostrar els resultats de l’execució de la prova perquè els verificadors coneguin les estadístiques. Tenim al voltant de 15 oients a Jmeter, però els més utilitzats són els de taula, arbre i gràfic.

Mostra els resultats a la taula:

Aquesta és la forma d’oients més utilitzada i fàcilment comprensible. Mostra el resultat en forma de taula amb alguns paràmetres de rendiment importants.

Els oients es poden afegir directament al pla de proves o al mostreig. La diferència és que, quan afegiu un oient a un sampler, només es mostraran els resultats d’aquest sampler. Si afegim sampler directament sota el pla de prova, es mostrarà el resultat de tots els Sampler de la jerarquia.

La captura de pantalla següent per a la vostra referència:

Els resultats es mostren a continuació:

• Latència : És el moment en què es rep la primera informació, és a dir, es rep el primer byte de dades
• Hora de connexió : És el temps necessari per establir la connexió amb el servidor
• Temps de mostra : És el temps que es triga a rebre dades completes
• Mostra - Seqüència del número de mostra
• bytes - Mida de les dades rebudes.

Veure resultats a l'arbre:

Aquest és un altre oient més utilitzat i proporciona informació detallada amb sol·licituds i respostes. També es pot veure la pàgina HTML representada en resposta a part de visualitzar Json, XML, Text, RegEx.

És molt útil, ja que els verificadors poden fer afirmacions sobre la resposta rebuda per assegurar-se que la prova ha passat. Els resultats de Jmeter segueixen mostrant 'Passa' encara que no es desitgi la resposta.

Per exemple: Per exemple, arribem a la sol·licitud HTTP en qualsevol lloc web www.xyz.com i, com a resposta, esperem XYZ o amb paraules simples, quan accedim a aquesta pàgina, la pàgina principal de l'empresa s'obre amb el seu nom. Si no hem fet cap afirmació, Jmeter continuarà mostrant els resultats, ja que la petició de fitxer ha anat al servidor.

Vegeu a continuació per conèixer el format dels resultats:

Per veure la pàgina HTML com a resposta, feu clic al menú desplegable del tauler esquerre i seleccioneu 'HTML', aneu a la pestanya de resposta i comproveu la pàgina que es retorna com a resposta del servidor.

Banc de treball

Un banc de treball és un lloc on podeu emmagatzemar aquells elements que no s’utilitzen al pla de proves actual però que es poden copiar posteriorment. Quan deseu el fitxer JMeter, els components que hi ha al banc de treball no es desen automàticament. Heu de desar-los per separat fent clic amb el botó dret i escollir l'opció 'Desa com a'.

Podríeu estar pensant, doncs, en què serveix el banc de treball, de tota manera és fàcil afegir qualsevol component directament al pla de proves de Jmeter.

La raó de tenir un banc de treball era que l'usuari podia fer experiments i provar nous escenaris. Com ja sabem, els elements del banc de treball no es guarden, de manera que l'usuari pot utilitzar literalment qualsevol cosa i després llençar-los. Però hi ha alguns 'components que no són de prova' que només estan disponibles a WorkBench.

Es detallen aquí:

• Servidor mirall HTTP
• HTTP (s) Test Script Recorder
• Visualització de propietats

HTTP (s) Test Script Recorder és l’element no test més important que s’utilitza a JMeter. Ajuda els verificadors a enregistrar l'script i després a configurar la càrrega de cada transacció.

Jmeter només registra la sol·licitud enviada al servidor. No us confongueu amb la funcionalitat 'Gravar i reproduir' de QTP / Selenium. Es registren totes les sol·licituds i els verificadors poden aplicar-hi la càrrega desitjada per veure el comportament.

Aquest element és molt important per als escenaris en què els verificadors no saben què passen totes les sol·licituds de la seva aplicació. Poden utilitzar el gravador de scripts Http (s) per gravar l'aplicació en proves.

La prova de rendiment de les aplicacions mòbils també es pot fer d’aquesta manera configurant el servidor intermediari JMeter i després enregistrant les sol·licituds que la nostra aplicació mòbil envia al servidor. El procediment pas a pas per a les proves de rendiment del mòbil s’explicarà al següent article.

Afirmacions

Fins ara hem explicat com JMeter arriba al servidor i com es mostren les respostes a través dels oients. Per assegurar-nos que la resposta rebuda sigui correcta i segons les expectatives, hem d’afegir afirmacions. Les afirmacions són simplement validacions que hem de donar a les respostes per comparar els resultats.

A continuació es mostren els tipus d’afirmacions que s’utilitzen habitualment:

• Afirmació de resposta
• Afirmació de la durada
• Afirmació de mida
• Asserció XML
• Asserció HTML

Afirmació de resposta

A Response Assertion, podem afegir les nostres pròpies cadenes de patrons i després comparar-les amb les respostes rebudes d’un servidor. Per exemple, tots sabeu que el codi de resposta és 200 quan qualsevol sol·licitud retorna alguna resposta amb èxit. Per tant, si afegim la cadena de patró 'Response Code = 202', el cas de prova hauria de fallar.

Consulteu a continuació les captures de pantalla per afegir l'afirmació del codi de resposta.

Ara, quan s’executa la prova, mostra el resultat amb Color vermell que indica que els resultats de l’asserció han fallat.

Afirmació de la durada

L’asserció de durada és molt important i valida que el servidor hagi respost en un període de temps determinat. Això es pot utilitzar en escenaris en què hem de provar 100 sol·licituds i assegurar-nos que cada vegada que es rep resposta dins del límit de referència.

Caixa : 10 usuaris concorren simultàniament al servidor 'google.com' i l'afirmació de durada s'estableix en 1000 ms. Vegeu les captures de pantalla següents:

XML Assertion es valida si les dades de resposta contenen un document XML correcte i HTML Assertion verifica la sintaxi HTML de la resposta rebuda d'un servidor.

Elements de configuració

Les sol·licituds enviades al servidor es poden parametritzar encara més mitjançant alguns elements de configuració que s’executen abans de la sol·licitud real. Un exemple senzill d’això podria ser la lectura de valors d’una variable d’un fitxer CSV per al qual s’utilitza la configuració del conjunt de dades CSV.

A continuació es mostren alguns dels elements de configuració importants utilitzats en les proves de rendiment de les aplicacions web i mòbil

• Configuració del conjunt de dades CSV.
• Variables definides per l'usuari
• Sol·licitud HTTPS per defecte
• Administrador de memòria cau HTTPS
• Administrador de cookies HTTPS

Configuració del conjunt de dades CSV

La configuració del conjunt de dades CSV ajuda Jmeter a seleccionar valors d'alguns paràmetres d'un fitxer CSV en lloc de passar paràmetres diferents a cada sol·licitud independent. Per exemple, si hem de provar la funcionalitat d’inici de sessió amb un conjunt d’usuaris i contrasenyes diferents, podem crear dues columnes en un fitxer CSV i introduir-hi els valors perquè JMeter en pugui escollir una per cada sol·licitud enviada al servidor.

A continuació es mostra el flux d’ús de dades CSV que defineix la configuració per provar l’API meteorològica de diferents ciutats de l’Índia.

• Afegir un element de configuració del conjunt de dades CSV al pla de prova

• S'està creant un fitxer CSV
• S'està passant la variable al paràmetre de sol·licitud. Es pot generar dinàmicament el paràmetre APPID http://openweathermap.org/appid

• Execució de la prova i visualització dels resultats.

Variables definides per l'usuari

Ajuda a Jmeter a triar valors d’una variable predefinida. Per exemple, admet que heu de crear un pla de prova en què hàgiu d'afegir moltes sol·licituds HTTP al mateix URL i que hi pugui haver un escenari en què el client planeja migrar-lo més endavant a un URL diferent. Per tant, per evitar actualitzar l'URL en cada sol·licitud podem dir a JMeter que triï l'URL d'una UDV (variable definida per l'usuari) que es pot actualitzar posteriorment per gestionar totes les sol·licituds d'URL actualitzat.

Per tant, per evitar actualitzar l'URL a cada sol·licitud, podem dir a JMeter que triï l'URL d'una UDV (Variable definida per l'usuari) que es pot actualitzar posteriorment per gestionar totes les sol·licituds a l'URL actualitzat.

Valors predeterminats de sol·licitud HTTP

Aquest element de configuració és molt útil per especificar els valors predeterminats de les sol·licituds https. Per orientar-vos més, agafeu un exemple en què hem d’atendre 50 sol·licituds diferents al servidor de google. En aquest cas, si afegim una sol·licitud predeterminada HTTP, no hem d’especificar un nom de servidor, un camí d'accés ni cap altra propietat com el número de port, la connexió temps d'espera de propietats. Tot el que s'especifiqui a l'element de configuració per defecte de la sol·licitud HTTP és heretat per totes les sol·licituds HTTP.

En aquest escenari, si afegim una sol·licitud per defecte HTTP, no cal especificar un nom de servidor, un camí d'accés o cap altra propietat, com ara el número de port, les propietats de temps d'espera de connexió. Tot el que s'especifiqui a l'element de configuració per defecte de la sol·licitud HTTP és heretat per totes les sol·licituds HTTP.

Vegeu a continuació com afegir la sol·licitud HTTP per defecte i especificar el servidor i el camí d'accés.

Gestor de memòria cau HTTP i Gestor de galetes HTTP s’utilitzen per fer que JMeter es comporti com un navegador en temps real. El gestor de memòria cau HTTP pot esborrar la memòria cau després de cada sol·licitud, mentre que l’altre pot gestionar la configuració de les cookies.

Controladors i temporitzadors lògics

Els controladors i temporitzadors lògics ajuden Jmeter a controlar el flux de transaccions. Els temporitzadors asseguren el retard en cada fil conductor si cal provar qualsevol servidor. Per exemple, si necessitem una sol·licitud FTP per esperar 5 segons després de completar la sol·licitud HTTP, hi podem afegir temporitzador.

Els controladors lògics s’utilitzen per definir el flux de sol·licituds que s’envien al servidor. També us permet emmagatzemar sol·licituds per a cada mòdul per separat, com ara iniciar sessió i tancar sessió.

Conclusió

A hores d'ara, tots us heu familiaritzat amb els components de JMeter i heu provat d'utilitzar-lo i heu d'afrontar alguns problemes. En el proper article, tractarem alguns escenaris de proves de rendiment en temps real que cobreixen el domini de la mobilitat, de manera que tots tingueu més coneixement pràctic sobre JMeter.

Estigueu atents! El següent article us ajudarà a gestionar les vostres sol·licituds, així com a analitzar els resultats i comparar-los amb els punts de referència de les proves de rendiment.

com puc obrir fitxers eps

=>Continueu llegint la part III: Processadors i controladors JMeter

=> Feu clic aquí per obtenir tutorials sobre JMeter: La formació gratuïta completa a JMeter (més de 20 vídeos)

Lectura recomanada

• Com s'aconsegueix la correlació de JMeter amb l'exemple
• Pla de proves de Jmeter i WorkBench
• Treballar amb sol·licitud FTP a JMeter
• Top 5 dels connectors JMeter i com utilitzar-los (amb exemples)
• Temporitzadors JMeter: temporitzador aleatori constant, BeanShell i guassià
• Treballar amb sol·licituds HTTP a JMeter
• Controladors Jmeter part 1
• Controladors Jmeter Part 2