Descrizione dettagliata dei componenti JMeter

detail description jmeter components

Revisione dei componenti Jmeter (Parte II):

=> Questo fa parte della serie di formazione JMeter. Vedi l'elenco di tutti i tutorial di questa serie qui .

Spero che tutti voi abbiate passato il Introduzione e installazione di JMeter da adesso. Mentre continuiamo con il prossimo della serie, si consiglia vivamente a tutti voi di installare JMeter e di esercitarvi fianco a fianco.

In questo tutorial, i lettori avrebbero familiarizzato con tutti i componenti di JMeter e come utilizzarli nel piano di test per coprire tutti i possibili scenari di test delle prestazioni per testare l'AUT (Application Under Test).

Elementi di Jmeter erano stati elencati nell'articolo precedente.

Cosa imparerai:

• Componenti di JMeter
  • Piano di test
  • Gruppo thread
  • Campionatori
  • Richieste HTTP
  • Richieste FTP
  • Ascoltatori
  • Banco di lavoro
  • Asserzioni
    • Asserzione di risposta
    • Asserzione di durata
  • Elementi di configurazione
    • Config. Set di dati CSV
    • Variabili definite dall'utente
    • Default richiesta HTTP
  • Controller logici e timer
  • Conclusione
  • Lettura consigliata

Componenti di JMeter

Ancora una volta per riferimento:

• Piano di test
• ThreadGroup
• Campionatori
• Ascoltatori
• Banco di lavoro
• Asserzioni
• Elemento di configurazione
• Controller logici
• Timer

Tutti i componenti principali di Jmeter come Thread Group, Samplers, Listeners e Config Elements sono spiegati in dettaglio più avanti nell'articolo.

Fare riferimento al diagramma di flusso seguente per comprendere ogni componente e la loro relazione con moduli specifici di JMeter.

Ora inizieremo a toccare ogni componente di Jmeter insieme ai casi d'uso solo per sapere come funziona e come i tester possono implementarli nei loro test. Tieni presente che in questo articolo non copriremo tutti i campionatori, ascoltatori. Lavoreremo su quelli più utilizzati e ci prenderemo una pausa nel prossimo articolo quando creeremo Piani di Test in tempo reale.

Piano di test

Proprio come un semplice piano di test in Software Testing è costituito da tutti i passaggi che eseguono lo script, il piano di test di JMeter ha lo stesso scopo. Tutto ciò che è incluso in un piano di test viene eseguito in una sequenza dall'alto verso il basso o secondo la sequenza definita nel piano di test.

Il piano di test può essere il più semplice possibile, con Just ThreadGroup, Sampler e Listener e inizia a diventare più complesso non appena inizi ad aggiungere più elementi come elementi di configurazione, preprocessori o controller.

Come tutti sappiamo, JMeter misura le prestazioni generando utenti virtuali o thread che colpiscono il server sotto test come se gli utenti reali stessero inviando richieste a un server. Pertanto, ogni piano di test dovrebbe avere utenti virtuali o gruppi di thread, come li chiamiamo nei termini di JMeter.

Punti importanti sul piano di test:

• Il piano di test deve essere salvato prima di essere eseguito
• I file Jmeter o i piani di test vengono salvati in formato. File di estensione JMX
• È inoltre possibile salvare parti del piano di test come selezione diversa. Per esempio, Se vuoi salvare HTTP Request Sampler con Listener, puoi salvarlo come Test Fragment in modo che possa essere utilizzato anche in altri scenari di test
• Gli elementi di WorkBench non vengono salvati con Test Plan

Gruppo thread

Il gruppo thread è un gruppo di utenti che raggiungeranno il server sottoposto a test contemporaneamente o in una sequenza predefinita. Il gruppo thread può essere aggiunto al piano di test facendo clic con il pulsante destro del mouse sul piano di test. JMeter è tutto 'roba del clic destro', ottieni tutte le opzioni con il clic destro.

Puoi rinominare il nome del gruppo thread con il tuo. Basta cambiare il nome e fare clic in un punto qualsiasi al di fuori della finestra del piano di test, vedrai che il nome viene modificato.

Si prega di vedere la schermata sottostante per l'aggiunta di gruppi di thread

(Nota: Fare clic su qualsiasi immagine per ingrandirla)

È molto importante configurare il gruppo di thread in base alle condizioni di test.

Per esempio, se vuoi testare come si comporta un server web quando 100 utenti lo raggiungono contemporaneamente, puoi impostare Thread Group come di seguito:

Fondamentalmente, ci sono tre parametri principali che devono essere configurati per generare carico effettivo o utenti virtuali:

• Numero di thread (utenti) - Definisce il numero di utenti virtuali. A scopo di test, dovremmo generare solo una quantità limitata di carico poiché generare un volume enorme in una volta significherebbe consumare molti thread che alla fine possono portare a un elevato utilizzo della CPU.
• Periodo di accelerazione - Questo campo è molto importante per controllare la generazione del carico. Il periodo di accelerazione ha definito la quantità di tempo in cui verrà generato il carico totale.

Esempio 1:

• Significa che tutti e 10 gli utenti raggiungeranno i server contemporaneamente non appena verrà eseguito un test

Esempio 2:

• Avrete tutti notato la casella di controllo 'Scheduler' nello screenshot qui sopra. Nel caso in cui desideri che il tuo test venga eseguito in un momento specifico in un secondo momento, puoi impostare i tempi come puoi anche vedere nello screenshot qui sotto. Significa che ogni 1 secondo un nuovo utente raggiungerà il server. Il carico non sarà simultaneo ma sarà in incrementi. Entro il 10^thsecondo, tutti gli utenti avrebbero risposto alla richiesta.
• Conteggio loop - Definisce il numero di volte in cui il gruppo di thread verrà eseguito. Se si seleziona la casella di controllo Per sempre, il test verrà eseguito per sempre a meno che non lo si interrompa manualmente. Questo può essere utilizzato per testare qualcosa come 'Se il tuo server non si arresta in modo anomalo con caricamento continuo per pochi minuti'.

Campionatori

Quindi, come fa un Jmeter a sapere che tipo di richiesta è stata inviata al server ???

• È tramite Samplers. I campionatori sono un must da aggiungere a un piano di test poiché solo può far sapere a Jmeter quale tipo di richiesta deve andare a quale server e con qualsiasi parametro predefinito o meno. Le richieste possono essere HTTP, HTTP (s), FTP, TCP, SMTP, SOAP ecc.

I campionatori possono essere aggiunti solo al gruppo di thread non direttamente nel piano di test poiché i gruppi di thread devono utilizzare un campionatore per inviare una richiesta all'URL del server in prova. Il campionatore può essere aggiunto tramite percorso Gruppo thread -> Campionatore -> Richiesta HTTP.

Richieste HTTP

Queste sono le richieste più comuni inviate ai server. Dire, per esempio, vogliamo che vengano colpiti 100 utenti https://www.google.com contemporaneamente, questo può essere fatto come descritto nello screenshot sottostante:

• Il percorso è la navigazione all'interno del sito principale. Ad esempio, se vogliamo premere http://www.google.com/gmail, possiamo impostare '/ Gmail' nel percorso e il resto rimane lo stesso
• Non è necessario digitare 'www' nel nome del server
• Il numero di porta viene utilizzato se si utilizza un server proxy
• È possibile impostare Timeout Connect and Response se si desidera avere un benchmark sul tempo di connessione del server e sui tempi di risposta. La tua richiesta fallirà se il tuo server impiega più tempo per inviare la risposta di quella configurata
• È inoltre possibile configurare i parametri da inviare con la richiesta. Per esempio: In alcuni casi, potresti dover inviare il token di autorizzazione con la tua richiesta, quindi li hai aggiunti nella richiesta HTTP come di seguito:

Richieste FTP

Percorso-> Piano di test-> Gruppo thread-> Campionatore-> Richiesta FTP

FTP sta per File Transfer Protocol e viene utilizzato per caricare o scaricare un file dal server. I thread di JMeter inviano richieste ai server FTP per caricare o scaricare file da lì e misurano le prestazioni.

• File locale è la posizione in cui è necessario salvare il file scaricato
• Usa l'opzione GET se stai scaricando da un server FTP
• Opzione POST utente se stai caricando qualsiasi file sul server FTP

Abbiamo molti ascoltatori che saranno trattati quando passeremo attraverso alcuni piani di test reali che consistono in campionatori, ascoltatori, elementi di configurazione ecc.

Ascoltatori

Quindi, fino ad ora abbiamo visto pochi campionatori inviare richieste al server ma non abbiamo ancora analizzato la risposta. Il test delle prestazioni consiste nell'analisi delle risposte del server in varie forme e quindi nella presentazione delle stesse al client.

le 10 migliori app spia per Android

Gli ascoltatori vengono utilizzati per visualizzare i risultati dell'esecuzione del test in modo che i tester conoscano le statistiche. Abbiamo circa 15 ascoltatori in Jmeter, ma quelli maggiormente utilizzati sono table, tree e Graph.

Visualizza i risultati nella tabella:

Questa è la forma di ascoltatore più comunemente usata e facilmente comprensibile. Visualizza il risultato sotto forma di tabella con alcuni importanti parametri di prestazione.

Gli ascoltatori possono essere aggiunti direttamente in Piano di test o in un campionatore. La differenza è che, quando aggiungi un listener sotto un campionatore, verranno visualizzati solo i risultati di quel campionatore. Se aggiungiamo il campionatore direttamente sotto il piano di test, viene visualizzato il risultato per tutti i campionatori in alto nella gerarchia.

Lo screenshot qui sotto come riferimento:

Vedi i risultati qualcosa di simile a quello mostrato di seguito:

• Latenza : È il momento in cui viene ricevuta la prima informazione, cioè il primo byte di dati viene ricevuto
• Connetti il ​​tempo : È il tempo necessario per stabilire la connessione con il server
• Tempo di campionamento : È il tempo necessario per ricevere i dati completi
• Campione - Sequenza del numero del campione
• Byte - Dimensioni dei dati ricevuti.

Visualizza i risultati nella struttura ad albero:

Questo è un altro listener più comunemente usato e fornisce informazioni dettagliate con richiesta e risposta. Si può anche visualizzare la pagina HTML resa in risposta oltre a visualizzare Json, XML, Text, RegEx.

È molto utile in quanto i tester possono fare affermazioni sulla risposta ricevuta per assicurarsi che il test sia passato. I risultati di Jmeter mostrano ancora 'Pass' anche se la risposta non è desiderata.

Per esempio: Diciamo, abbiamo raggiunto la richiesta HTTP su qualsiasi sito web www.xyz.com e in risposta ci aspettiamo XYZ o in parole semplici, quando tocchiamo questa pagina, la home page dell'azienda si apre con il suo nome. Se non inseriamo l'asserzione, Jmeter visualizzerà comunque i risultati poiché l'hit è andato al server.

Vedere di seguito per conoscere il formato dei risultati:

Per visualizzare la pagina HTML in risposta, fare clic sul menu a discesa nel riquadro di sinistra e quindi selezionare 'HTML', accedere alla scheda della risposta e controllare la pagina che viene restituita come risposta del server.

Banco di lavoro

Un banco di lavoro è un luogo in cui è possibile memorizzare quegli elementi che non sono in uso nel piano di test corrente ma che possono essere successivamente copiati e incollati al suo interno. Quando si salva il file JMeter, i componenti presenti in workbench non vengono salvati automaticamente. È necessario salvarli separatamente facendo clic con il pulsante destro del mouse e scegliere l'opzione 'Salva con nome'.

Potreste pensare tutti allora a cosa serve il workbench, in ogni caso è facile aggiungere qualsiasi componente direttamente al piano di prova di Jmeter.

Il motivo per avere workbench era che l'utente poteva fare alcuni esperimenti e provare nuovi scenari. Come già sappiamo, gli elementi nel workbench non vengono salvati, quindi un utente può letteralmente usare qualsiasi cosa e poi buttare via. Tuttavia, ci sono alcuni 'componenti non di prova' disponibili solo in WorkBench.

Sono elencati qui:

• HTTP Mirror Server
• HTTP (s) Test Script Recorder
• Visualizzazione delle proprietà

HTTP (s) Test Script Recorder è il più importante elemento non di test utilizzato in JMeter. Aiuta i tester a registrare lo script e quindi a configurare il carico per ogni transazione.

Jmeter registra solo la richiesta inviata al server. Non farti confondere con la funzionalità 'Registra e riproduci' di QTP / Selenium. Tutte le richieste vengono registrate ei tester possono applicare su di esse il carico desiderato per vedere il comportamento.

Questo elemento è molto importante per gli scenari in cui i tester non sanno a cosa stanno andando incontro tutte le richieste dalla loro applicazione. Possono utilizzare il registratore di script Http (s) per registrare l'applicazione in fase di test.

Anche il test delle prestazioni delle applicazioni mobili può essere eseguito in questo modo configurando il proxy JMeter e quindi registrando le richieste che la nostra app mobile invia al server. La procedura passo passo per il test delle prestazioni dei dispositivi mobili verrà spiegata nel prossimo articolo.

Asserzioni

Fino ad ora, abbiamo coperto come JMeter colpisce il server e come le risposte vengono visualizzate tramite gli ascoltatori. Per garantire che la risposta ricevuta sia corretta e come previsto, è necessario aggiungere affermazioni. Le asserzioni sono semplicemente convalide che dobbiamo inserire nelle risposte per confrontare i risultati.

Di seguito sono riportati i tipi di asserzioni comunemente utilizzati:

• Asserzione di risposta
• Asserzione di durata
• Asserzione di dimensioni
• Asserzione XML
• Asserzione HTML

Asserzione di risposta

In Response Assertion, possiamo aggiungere le nostre stringhe di pattern e quindi confrontarle con le risposte ricevute da un server. Per esempio, sapete tutti che il codice di risposta è 200 quando qualsiasi richiesta restituisce una risposta con successo. Quindi, se aggiungiamo la stringa di pattern 'Codice di risposta = 202', il test case dovrebbe fallire.

Fare riferimento agli screenshot seguenti per aggiungere l'asserzione del codice di risposta.

Ora, quando viene eseguito il test, mostra il risultato con il colore rosso che indica che i risultati dell'asserzione non sono riusciti.

Asserzione di durata

L'asserzione della durata è molto importante e convalida che il server abbia risposto entro un determinato periodo di tempo. Questo può essere utilizzato in scenari in cui è necessario campionare 100 richieste e garantire che ogni volta che la risposta venga ricevuta entro il limite di benchmark.

Astuccio : 10 utenti stanno visitando contemporaneamente il server 'google.com' e l'asserzione della durata è impostata su 1000 ms. Vedi gli screenshot seguenti:

L'asserzione XML convalida se i dati della risposta contengono un documento XML corretto e l'asserzione HTML verifica la sintassi HTML della risposta ricevuta da un server.

Elementi di configurazione

Le richieste inviate al server possono essere ulteriormente parametrizzate utilizzando alcuni elementi di configurazione che vengono eseguiti prima della richiesta effettiva. Un semplice esempio potrebbe essere la lettura dei valori di una variabile da un file CSV per il quale viene utilizzato CSV Data Set Config.

Di seguito sono riportati alcuni degli elementi di configurazione importanti utilizzati nei test delle prestazioni delle applicazioni web e mobili

• Config. Set di dati CSV
• Variabili definite dall'utente
• Richieste HTTPS predefinite
• HTTPS Cache Manager
• Gestione cookie HTTPS

Config. Set di dati CSV

La configurazione del set di dati CSV aiuta Jmeter a scegliere i valori di alcuni parametri da un file CSV piuttosto che passare parametri diversi in ogni richiesta separata. Per esempio, se abbiamo bisogno di testare la funzionalità di accesso con un diverso set di utenti e password, allora possiamo creare due colonne in un file CSV e inserire i valori lì in modo che JMeter possa sceglierne uno per ogni richiesta inviata al server.

Di seguito è riportato il flusso di utilizzo dei dati CSV che impostano la configurazione per testare l'API meteo per diverse città in India.

• Aggiunta dell'elemento di configurazione del set di dati CSV al piano di test

• Creazione di file CSV
• Passaggio di una variabile nel parametro di richiesta. Il parametro APPID può essere generato dinamicamente da http://openweathermap.org/appid

• Esecuzione del test e visualizzazione dei risultati.

Variabili definite dall'utente

Aiuta Jmeter a scegliere i valori da una variabile predefinita. Per esempio, supporto necessario per creare un piano di test in cui è necessario aggiungere molte richieste HTTP sullo stesso URL e potrebbe esserci uno scenario in cui il client pianifica di migrarlo in un secondo momento su un URL diverso.Quindi, per evitare di aggiornare l'URL in ogni richiesta possiamo dire a JMeter di scegliere l'URL da un UDV (variabile definita dall'utente) che può essere successivamente aggiornato per gestire tutte le richieste all'URL aggiornato.

Quindi, per evitare di aggiornare l'URL in ogni richiesta, possiamo dire a JMeter di scegliere l'URL da una UDV (variabile definita dall'utente) che può essere successivamente aggiornata per gestire tutte le richieste all'URL aggiornato.

Default richiesta HTTP

Questo elemento di configurazione è molto utile per specificare i valori predefiniti delle richieste https. Per guidarti di più, prendi un esempio in cui dobbiamo soddisfare 50 richieste diverse sul server di Google.In questo scenario, se aggiungiamo un valore predefinito di richiesta HTTP, non è necessario specificare un nome del server, un percorso o altre proprietà come numero di porta, connessione proprietà time out. Tutto ciò che è specificato nell'elemento di configurazione predefinito della richiesta HTTP viene ereditato da tutte le richieste HTTP.

In questo scenario, se aggiungiamo una richiesta HTTP predefinita, non è necessario specificare un nome server, un percorso o altre proprietà come il numero di porta, le proprietà di timeout della connessione. Tutto ciò che è specificato nell'elemento di configurazione predefinito della richiesta HTTP viene ereditato da tutte le richieste HTTP.

Vedere di seguito come aggiungere il valore predefinito della richiesta HTTP e specificare il server e il percorso.

HTTP Cache Manager e HTTP Cookie Manager vengono utilizzati per far funzionare JMeter come un browser in tempo reale. Il gestore della cache HTTP può svuotare la cache dopo ogni richiesta mentre l'altro può gestire le impostazioni dei cookie.

Controller logici e timer

I controller logici ei timer aiutano Jmeter a controllare il flusso delle transazioni. I timer assicurano il ritardo in ogni thread se è necessario testare qualsiasi server. Per esempio, se abbiamo bisogno che la richiesta FTP attenda 5 secondi dopo che la richiesta HTTP è stata completata, possiamo aggiungere il timer lì.

I controller logici vengono utilizzati per definire il flusso di richieste che vengono inviate al server. Può anche consentire di memorizzare le richieste per ogni modulo separatamente, come login e logout.

Conclusione

A questo punto, tutti voi dovete aver familiarizzato con i componenti di JMeter e aver provato a usarlo e dovete affrontare alcuni problemi. Nel prossimo articolo, tratteremo alcuni scenari di test delle prestazioni in tempo reale che coprono il dominio della mobilità in modo che tutti possiate acquisire una conoscenza più pratica su JMeter.

Rimanete sintonizzati! Il prossimo articolo ti aiuterà a gestire le tue richieste, nonché ad analizzare i risultati e confrontarli con i benchmark dei test delle prestazioni.

=>Continua a leggere la parte III: Processori e controller JMeter

come aprire un file .apk

=> Fare clic qui per i tutorial di JMeter: La formazione gratuita completa su JMeter (oltre 20 video)

Lettura consigliata

• Come ottenere la correlazione JMeter con l'esempio
• Piano di test Jmeter e WorkBench
• Lavorare con la richiesta FTP in JMeter
• I 5 migliori plugin JMeter e come usarli (con esempi)
• Timer JMeter: timer casuale costante, BeanShell e Guassian
• Lavorare con le richieste HTTP in JMeter
• Controller Jmeter Parte 1
• Controller Jmeter Parte 2