In questo articolo vediamo cos’è un test plan in JMeter, come configurarlo e come visualizzare e analizzare i risultati prodotti!

JMeter è infatti un software in grado di eseguire test di carico, test funzionali e/o stress test che permettono di valutare le prestazioni di un’applicazione su diversi protocolli o tecnologie.

Non tutti lo sanno, ma è stato un italiano a portare avanti questo progetto: Stefano Mazzocchi della Apache Software Foundation è stato infatti lo sviluppatore originale di JMeter.

Lo scrisse principalmente per testare le prestazioni di Apache JServ, vecchio nome per Apache Tomcat, che nel 1998 lo scrisse come tool senza interfaccia grafica, mentre il progetto Apache lo ha poi riprogettato per migliorare la GUI e per nuove aggiungere funzionalità.

L’ultima versione attualmente disponibile è la 5.4.3: clicca qui per scaricarla!

Introduzione

Prima di entrare nei dettagli del funzionamento di un test plan con JMeter, comprendiamo innanzitutto alcuni gerghi associati al testing di qualsiasi applicazione.

Con JMeter possiamo effettuare diverse tipologie di test, con diverse finalità. Analizziamo le differenze velocemente, in modo tale da essere sicuri di prepararci per bene al test da configurare!

Il **test delle prestazioni (**o performance test) è un test che stabilisce le migliori aspettative di prestazioni possibili in una determinata configurazione dell’infrastruttura.

Evidenzia anche all’inizio del processo di test se è necessario apportare modifiche prima che l’applicazione entri in produzione, modificando l’architettura o rivedendo le configurazioni attuali.

Il test di carico (o load testing) è un tipo di test delle prestazioni che determina le prestazioni di un sistema, un prodotto software o un’applicazione software in condizioni di carico basate sull’utilizzo reale.

Il test di carico è quindi un test che viene fondamentalmente utilizzato per testare il sistema sotto il carico massimo con cui è stato progettato per funzionare e verificare se “regge”.

Infine, lo stress test è un tipo di test del software che verifica la stabilità e l’affidabilità del sistema e determina in particolare la sua robustezza e la relativa gestione degli errori in condizioni di carico estremamente pesanti.

In altre parole, lo stress test è un modo che abbiamo per verificare se la nostra infrastruttura, sotto stress e quindi sotto sovraccarico di risorse, riesce a resistere.

A questo punto vediamo in che modo JMeter ci permette di eseguire diverse tipologie di test come quelli appena menzionati sfruttando le risorse a disposizione, e cominciamo da qui: cos’è un test plan e come si configura!

Cos’è un test plan

È l’oggetto con cui è possibile specificare le impostazioni generali del test che andremo a effettuare in modo da delineare i passaggi che desideri che JMeter esegua.

Solitamente è composto da diversi componenti, che permettono di compiere diverse tipologie di attività: request HTTP o HTTPS, estrazione di informazioni da una response, misurazioni sui tempi di risposta, e molto altro.

Configurare un test plan

Segui questi step per configurare un test plan con JMeter: tieni presente di default, quando apri JMeter nella sua versione GUI, ti mostra Test Plan vuoto, che puoi utilizzare per iniziare a lavorare.

Aggiungi un Thread Group

Fai clic con il pulsante destro del mouse sul test plan e fai clic su Add-> Threads (Users) -> Thread Group.

Creazione del gruppo di thread

Il Thread Group è il contenitore che contiene la logica di come simulare l’utente o il thread.

Per rendere di più l’idea, al suo interno andremo a specificare come e in cosa consiste il nostro test: quali sono le request da eseguire, se ci sono delle variabili che dovremo passargli, se mostrare degli output e come salvarli.

Se ci clicchiamo sopra, noteremo che ci sono diversi campi che possiamo andare a riempire, e ognuno di questi ha un diverso scopo.

Configurazione del Thread Group

Parliamo delle impostazioni nel pannello Thread Group.

Action to be taken after a sample error.

Se si verifica un errore durante l’esecuzione del test, è possibile far sì che il test esegua una delle seguenti operazioni:

• Continue: porta avanti l’esecuzione;
• Start Next Thread Loop: passa al prossimo thread group (se presente);
• Stop Thread: interrompi l’esecuzione del thread;
• Stop Test: interrompi il test;
• Stop Test Now: interrompi il test in maniera forzata.

Number of Threads

Rappresenta il numero di thread simulati durante il test, o anche di utenti virtuali. Questo vuol dire che se specifichiamo un valore pari a 100, JMeter simulerà 100 utenti che eseguono le operazioni descritte all’interno del thread group come fossero persone reali.

Ramp-up period (seconds)

Quanto tempo occorre per raggiungere il numero di thread specificato. Ad esempio, se ho specificato 100 utenti virtuali (number of threads) e specifico 100 secondi come ramp-up, JMeter creerà un utente virtuale ogni secondo.

Loop Count

Il numero di iterazioni di cui JMeter andrà ad eseguire il thread group. Questo vuol dire che se inserisco un valore pari a 10, andrà ad eseguire tutto quello che è descritto all’interno del thread group per 10 volte!

Nella figura seguente viene mostrato un esempio.

In questo caso, il significato di questo thread è che se ci sono 100 thread (ovvero il numero di thread), verranno suddivisi per il periodo di ramp-up : ogni secondo, un nuovo utente invierà una richiesta e lo script completo verrà eseguito due volte.

Esempio di configurazione di un thread group

Oltre alle proprietà viste prima, abbiamo anche altre configurazioni che è possibile fare all’interno del thread group: ad esempio, possiamo scegliere di simulare uno stesso utente all’interno del thread group, oppure di usarne diversi.

In che modo? Quando selezioni la casella “Same user on each iteration” e utilizzi il componente di configurazione HTTP Cookie Manager, i cookie che ottieni nella prima risposta verranno utilizzati per le request seguenti.

Se la casella di controllo “Same user on each iteration” è deselezionata, i cookie non verranno utilizzati per le richieste successive, così da simulare utenti diversi!

Inoltre, possiamo definire i dettagli della durata temporale del test, se vogliamo che questo abbia una durata stabilita, e lo facciamo valorizzando i campi Duration e Startup delay, se vogliamo che il test inizi con un certo ritardo (in secondi) prima di ogni periodo di ramp-up.

Creare una request HTTP

A questo punto facciamo clic con il pulsante destro del mouse sul thread group e quindi selezioniamo Add -> Sampler -> HTTP Request.

Creazione della request HTTP

L’oggetto HTTP Request fa parte di quelli che si chiamano campionatori (o Sampler): questi consentono a JMeter di inviare tipi specifici di richieste a un server e simulano una richiesta dell’utente per una pagina dal server di destinazione.

Clicchiamo sull’oggetto appena aggiunto e proviamo a vederne il funzionamento con un esempio di una request GET a https://httpbin.org.

Configurazione della request HTTP

Come tutti gli oggetti presenti in JMeter, abbiamo la possibilità di specificare un nome per quella risorsa, di modo che sia più parlando: una buona convenzione può essere quella di rinominare la request HTTP usando una sintassi del tipo: [GET-POST-PUT-ecc.]-[REQUEST].

Abbiamo a disposizione anche una sezione per aggiungere dei commenti o una descrizione più parlando della nostra request in maniera testuale.

Notiamo poi due pannelli, chiamati Basic e Advanced: nel primo, abbiamo la possibilità di configurare una request HTTP/S di base, specificando il protocollo, l’hostname o l’indirizzo IP, la porta e altre informazioni visibili nella figura precedente.

In questo caso, è stato utilizzato il protocollo HTTPS per il sito https://httpbin.org, il quale utilizza la porta 443 (porta HTTPS predefinita, quindi può essere omessa).

Andiamo ad eseguire una semplice GET, ossia una richiesta che ci permette di ottenere la pagina principale del sito, dal momento che come_path_ specifichiamo semplicemente “/”.

Nella sezione sottostante abbiamo anche la possibilità di aggiungere parametri, un body o anche dei file, proprio come avverrebbe anche utilizzando un altro tool come Postman o il browser.

Aggiungere un listener

Per mostrare l’esecuzione del nostro test plan, possiamo andare ad aggiungere un componente chiamato listener.

Quando eseguiamo un test plan, la parte più importante consiste nell’analizzare le risposte del server in varie forme e quindi analizzare i dati forniti in output.

I Listener forniscono una rappresentazione grafica dei dati raccolti da JMeter su quei casi di test descritti all’interno del thread o del test plan.

Questo facilita l’utente nella visualizzazione dei risultati prodotti grazie ad una rappresentazione tramite tabelle, grafici, XML o testo semplice.

I listener possono essere aggiunti in qualsiasi punto del test, anche direttamente nel test plan come risorsa globale per uno o più thread.

Un listener raccoglierà solo dati dagli elementi al suo livello o al di sopra, e non da quelli che seguono. Questo vuol dire che se un listener viene aggiunto allo script come elemento figlio, mostrerà solo i dati relativi al suo genitore.

Se un listener viene aggiunto in un thread group di un test plan che ne ha diversi, quel listener visualizzerà i dati di tutte le risorse che appartengono a quel solo thread group.

Proviamo ad esempio ad utilizzare View Results Tree per vedere i risultati dopo aver eseguito la nostra richiesta al sito di httpbin.

Facciamo quindi clic con il pulsante destro del mouse sul thread group e quindi selezioniamo Add -> Listener ->View Results Tree.

Listener View Results Tree

A questo punto, possiamo andare ad eseguire il nostro primo test plan: clicchiamo sul tasto verde in alto e procediamo!

Esempio di visualizzazione dei risultati

I listener consentono di vedere i risultati e le richieste eseguite con una serie di informazioni molto importanti: intanto, notiamo come la request HTTP sia andata a buon fine grazie al simbolo di colore verde che ne indica il successo.

Se vi clicchiamo sopra, vedremo il dettaglio dei dati raccolti: oltre alle informazioni sulla request, come il codice HTTP di risposta, il messaggio e il tipo di content-type, abbiamo la possibilità di vedere la request (tramite il pannello request) e la risposta(tramite il pannello response).

Esempio di request del listener View Results Tree

All’interno della request possiamo, ad esempio, vedere il body della request e anche gli headers; questo ci torna particolamente utile se vogliamo controllare se eventuali headers o cookie siano stati impostati correttamente.

Esempio di response del listener View Results Tree

Nella sezione response possiamo vedere la risposta restituita, che in questo caso è una pagina HTML. Potremmo utilizzare lo stesso test plan anche per testare delle API che restituiscono dei JSON come risposta!

Tieni presente JMeter memorizza tutte le request e le response ricevute.

Se l’articolo ti è piaciuto o ti è tornato utile, condividi o lascia un commento!