Performance testing con Postman
Hai sviluppato la tua API e vuoi testarla? Ci sono moltissimi strumenti con cui farlo, tra cui Postman: questo strumento si rivela ottimale anche quando è necessario monitorare il comportamento di un’API sotto un carico di lavoro reale, o misurare i tempi di latenza delle risposte.
Vediamo come funziona il performance testing con Postman!
- Cosa vuol dire performance testing
- Come eseguire dei test di performance con Postman
- Alternative a Postman
Cosa vuol dire performance testing
- Come funzioneranno le mie API in situazioni reali?
- Come cambieranno i tempi di risposta quando più utenti inviano richieste contemporaneamente?
- I miei utenti avranno tempi di risposta accettabili quando il sistema è sotto carico o vedranno errori?
- Come posso identificare i colli di bottiglia che inficiano sulle prestazioni e che potrebbero trasformarsi in importanti problemi di produzione?
Se ti stai ponendo una di queste domande, allora troverai la risposta nei performance testing.
Il performance testing comporta la simulazione del traffico reale verso un’API e l’osservazione del comportamento risultante da queste richieste. Viene eseguito per valutare quanto bene un’API soddisfa le aspettative di prestazioni in termini di tempi di risposta, throughput e disponibilità sotto il carico simulato.
Come eseguire dei test di performance con Postman
Per eseguire un test di performance con Postman hai bisogno di una collezione (ossia un insieme di una o più request) con le request che ti interessano, eventuali variabili di ambiente configurate e le metriche che vuoi andare a misurare.
Puoi usare quello che si chiama Postman’s Collection Runner per configurare un test delle prestazioni in Postman seguendo questi passaggi: per prima cosa, seleziona una collezione, le variabili di ambiente da utilizzare (facoltativo) e fai clic su Run cliccando sui tre puntini a destra del nome della collezione:
Si aprirà un tab chiamato Runner tab: questo consente di configurare il test con tutte le sue variabili, come la modalità di esecuzione. Ci sono due sezioni per la configurazione: quella funzionale, che permette di definire variabili come il numero di iterazioni per cui eseguire il test o se dev’essere schedulato, e quella relativa al vero e proprio test di performance.
Per per simulare il traffico reale, è possibile specificare i seguenti input per simulare la condizione di carico:
- Utenti virtuali (VU): il numero massimo di utenti concorrenti.
- Durata del test: tempo in minuti per cui vuoi eseguire il test.
- Profilo di carico: l’intensità del carico durante la durata del test, che attualmente supporta due profili: uno “fisso”, che applicherà un numero fisso di utenti virtuali per tutta la durata del test, oppure uno ad “aumento graduale” (alias ramp up), che aumenterà lentamente il numero di utenti virtuali aggiungendoli man mano.
La parte più interessante sta nella dashboard di monitoraggio che è possibile visualizzare una volta lanciata l’esecuzione del test:
Questa riporta i tempi di risposta (alias response times), così come i tassi di errore nell’esecuzione delle request (alias error rate) in tempo reale.
Una volta terminata l’esecuzione del test, è possibile sfruttare i dati riportati per analizzare eventuali colli di bottiglia nelle request, così come nelle response:
Alternative a Postman
Una delle più note per il testing è JMeter: permette di creare quelli che si chiamano test plan inserendo manualmente le request che si vogliono chiamare, oppure consente la registrazione di un flusso di esempio sfruttando la registrazione della navigazione attraverso le pagine del browser tramite la funzionalità di recording.
Esempio di testing con JMeter
Post correlati
- SSR in Angular
- Come avviare e arrestare un'istanza Aurora in maniera automatica con AWS Lambda
- Cgroups e namespaces: cosa sono (in modo facile)
- Virtualization vs Container: Guida completa per scegliere l'approccio giusto
- Differenza tra Local Storage, Session Storage e Cookie in Angular: Una guida completa