Performance Testing: cos’è e perché è necessario

Performance testing: cos’è, le diverse tipologie, gli obiettivi, le fasi ed i software utilizzati. Tutto ciò che devi sapere!

---

In un’era in cui tutto è sempre più interconnesso e operativo 24 ore su 24, l’affidabilità costituisce una qualità essenziale per qualsiasi componente IT, dall’hardware al software, considerato soprattutto come è cambiato lo sviluppo di quest’ultimo negli ultimi anni, con la rapida diffusione delle metodologie DevOps, delle architetture a microservizi e delle applicazioni cloud native.

Sviluppare agile comporta una serie di vantaggi non indifferenti, in quanto il disaccoppiamento dei singoli moduli che compongono un software consente di implementare una pipeline di integrazione e distribuzione continua (CI/CD) per cui il ciclo di vita di un’applicazione diventa un continuo ed interminabile succedersi di test e deploy.

Per garantire il corretto funzionamento e la stabilità di un’applicazione moderna è assolutamente necessaria una solida strategia di performance testing, in grado di assicurare soprattutto due condizioni essenziali: che un sistema funzioni e che funzioni nelle situazioni di picco, quando si registra il massimo stress sull’applicazione.

Performance testing: cos’è

Il performance testing, o test delle prestazioni, è un insieme di prove atte a valutare una serie di parametri, quali la velocità, la reattività e la stabilità di un sistema: un server, una rete, un software, piuttosto che qualsiasi infrastruttura IT in una situazione operativa. Come approfondiremo in seguito, l’obiettivo principale del performance testing consiste nell’assicurarsi che il sistema funzioni, ma soprattutto garantire agli utilizzatori la miglior esperienza utente possibile. A tal fine risulta essenziale individuare i cosiddetti bottleneck, i colli di bottiglia che possono condizionare il rendimento e l’efficienza dell’intero sistema.

Per una ragione di sintesi divulgativa, faremo riferimento al performance testing di un’applicazione software ma gli stessi principi sono validi anche in altre circostanze, ad esempio quando si tratta di testare la stabilità di un sistema hardware in condizioni di pieno carico, accertandosi che tutti i suoi componenti siano strutturalmente rispondenti alle specifiche di funzionamento dichiarate e il sistema nel suo complesso sia configurato in maniera corretta.

Nel caso di un’applicazione è importante valutare molti aspetti, che riguardano sia l’infrastrutturaIT chiamata ad eseguirla (es. server, networking, sicurezza, sistema operativo, ambiente di esecuzione, ecc.), oltre al corretto funzionamento dei moduli software che la compongono. Sia nel caso che si tratti di un’applicazione on-premises piuttosto che in cloud.

Il performance testing è pertanto composto da una serie di test specifici che consentono di limitare il numero di variabili da considerare, per confrontarle nell’ottica di una strategia di miglioramento continuo. Il progressivo incremento delle performance ottenute nei test consente di eliminare i colli di bottiglia che penalizzano la user experience, rendendo di fatto un’applicazione migliore, più apprezzata dagli utilizzatori finali e, nella maggior parte dei casi, più efficiente da gestire e mantenere per gli sviluppatori.

Le diverse tipologie

Il performance testing è composto da due metodi di riferimento: il test di carico (load testing) e il test di picco (stress testing), che a loro volta si articolano in ulteriori sotto test, unitamente alle valutazioni orientate nello specifico ad osservare aspetti come la scalabilità e la capacità di carico complessiva dell’applicazione stessa.

Un performance testing è soggetto alla definizione a monte di alcune metriche, i key performance indicator (KPI), indispensabili per poter avere dei riferimenti utili per confrontare i risultati ottenuti. Le metriche delle prestazioni includono comunemente:

• Throughput: indica quante unità di informazioni un sistema elabora in un dato tempo e rappresenta pertanto un parametro indicativo della produttività;
• Memoria: indica lo spazio di archiviazione disponibile per una CPU o un carico di lavoro a livello hardware;
• Larghezza di banda: indica il volume dei che può spostarsi tra i carichi di lavoro utilizzando una rete;
• Interrupt CPU: esprime il numero di interrupt hardware che un processo riceve in un dato tempo.

In termini generali, i KPI più ricorrenti sono misurati in funzione della variabile tempo espressa in secondi, in quanto consente di oggettivare in maniera piuttosto semplice i risultati dei test. A titolo esemplificativo potremmo citare:

• Tempo medio di risposta: consiste nel tempo medio impiegato per eseguire le transazioni nello scenario simulato;
• Transazioni totali al secondo: si riferisce al numero totale di transazioni di successo, al numero totale di transazioni non riuscite e al numero totale di transazioni interrotte durante l’esecuzione del performance testing;
• Transazioni al secondo: come nel caso precedente, ma riferite ad ogni transazione, per rilevare il numero di volte in cui è andata a buon fine, non è riuscita o è stata interrotta durante ogni secondo di esecuzione del performance testing;
• Tempo di risposta della transazione (nel caso di uno stress test): considera i tempi di transazione relativi al continuo incremento degli utenti attivi simultaneamente durante il performance testing;
• Errori al secondo: con riferimento al numero medio di errori che si verificano durante ogni secondo del performance testing;
• Accessi al secondo: sulla base del numero di richieste effettuate dagli utenti al server che esegue l’applicazione, durante ogni secondo del performance testing.

Dopo aver prospettato un quadro generale di un possibile set di KPI, vediamo ora quali sono le principali tipologie di valutazioni che compongono nel suo complesso una pipeline di performance testing.

Load testing

Il load testing è finalizzato alla comprensione del comportamento di un sistema in relazione ad una o più condizioni di carico. Un processo di load testing può simulare l’incidenza di una serie di variabili che comprendono ad esempio l’accesso di un determinato numero di utenti, che comporta una serie di azioni simultanee in un determinato intervallo di tempo.

Il test si riferisce ad una condizione di funzionamento normale, in cui si prevede lo scenario tipo: la situazione ricorrente, che vede l’applicazione nelle condizioni operative di riferimento.

Se eseguite durante le fasi di sviluppo, tali prove consentono di prevedere le situazioni che potrebbero verificarsi in produzione. La valutazione dei tempi di risposta dell’applicazione sono indicative per individuare i possibili colli di bottiglia, in funzione del numero di utenti che l’applicazione può reggere senza andare in sovraccarico. La possibilità di condurre un load test è fondamentale nei cicli CI/CD quando vengono implementate continuamente modifiche alle funzioni esistenti o vengono introdotte nuove feature che devono dialogare funzionalmente in con il resto dell’applicazione.

In generale un corretto load testing mira a conoscere due aspetti essenziali:

• Determinare i limiti operativi di tutti i componenti di un’applicazione (hardware, database, rete, ecc.). Il test consente di verificare che le condizioni di utilizzo standard siano conformi ai carichi di lavoro previsti;
• Rilevare i possibili difetti nelle applicazioni, relativi a buffer overflow, cattiva gestione o perdite di memoria. È alquanto frequente che i test di carico, soprattutto i primi che vengono eseguiti, facciano emergere una serie di problemi in merito alla larghezza di banda, al load balancing dei task e alla capacità di carico del sistema.

Gli strumenti utilizzati per svolgere il load test generalmente valuta il comportamento del sistema simulando la presenza simultanea di un determinato quantitativo di utenti. La ripetizione della procedura con valori differenti consente di raccogliere, monitorare e generare report in merito ad una serie di variabili, ad esempio il carico della CPU, gli accessi al disco e alla memoria di sistema, vale a dire le componenti hardware basilari per eseguire un software su una macchina, reale o virtuale che sia.

I test riguardano ovviamente anche il tempo di risposta e il throughput del sistema, insieme ad altri KPI (key performance indicator). Dopo aver svolto un’analisi descrittiva, gli strumenti di load testing generano in automatico un rapporto generalmente comprensibile da un pubblico non esclusivamente tecnico, in modo che qualsiasi figura decisionale possa avere la percezione delle performance del sistema e poterle confrontare con gli obiettivi attesi dai benchmark.

Stress testing

Lo stress testing completa le valutazioni del load testing in quanto, oltre alle condizioni operative ordinarie, consente di valutare gli effetti delle condizioni di carico eccezionale, per capire fino a che punto un sistema può resistere e reagire alle criticità che possono interessare il suo funzionamento. Che si tratti di un numero di utenti inaspettatamente elevato, piuttosto che un attacco DDoS, per citare due delle situazioni più ricorrenti, lo stress test deve offrire agli sviluppatori i valori limite cui l’applicazione può arrivare prima il sistema vada in sovraccarico.

Sulla base dei dati ottenuti da uno stress test, il team di sviluppo può comprendere al meglio la scalabilità di un carico di lavoro, a prescindere dal suo livello di criticità. L’obiettivo di un test di questo genere mira esclusivamente a conoscere il punto di rottura almeno per quanto concerne l’utilizzo di CPU, memoria e dischi di sistema, senza trascurare i rallentamenti generali e le situazioni che potrebbero comportare la perdita o la corruzione dei dati, piuttosto che problemi legati a possibili incidenti di sicurezza informatica.

Lo stress test è al tempo stesso utile per conoscere il tempo che il sistema, dopo il verificarsi di un evento di carico eccezionale, impiega per tornare alla normalità operativa. Per tali motivi gli stress test vengono eseguiti anche monitorando il sistema in produzione, quando oltre alla limpida natura teorica della prova di laboratorio è possibile svolgere un’effettiva prova sul campo.

Per quanto una simulazione possa essere accurata nelle valutazioni di scenario, nel mondo reale non è possibile prevedere la totalità delle condizioni cui l’applicazione può essere soggetta, in quanto intervengono una serie di variabili esogene che non dipendono nello specifico soltanto dalle qualità del sistema.

A seconda dell’applicazione o della tecnologia utilizzata, le variabili misurate attraverso l’esecuzione di uno stress test possono variare anche in maniera piuttosto significativa, ma le metriche correntemente utilizzate comprendono problemi legati alle prestazioni complessive, picchi di carico imprevisti a livello di traffico, perdite o cattiva gestione della memoria, almeno per quanto riguarda i seguenti componenti:

            • Tempi di risposta: quantità di tempo necessaria per ricevere una risposta dopo l’invio di una richiesta in condizioni di particolare criticità;

            • Colli di bottiglia a livello hardware: attraverso la misurazione dell’utilizzo di CPU, RAM e I/O del disco. Se i tempi di risposta e le performance generali sono poco soddisfacenti è possibile richiedere al sistema la disponibilità di ulteriori risorse hardware, per incrementare la capacità di carico del sistema;

            • Throughput: per conoscere la quantità di dati inviati o ricevuti durante lo stress test, in base ai livelli di larghezza di banda misurati nelle situazioni di picco;

            • Lettura e scrittura di database: molto utile nel caso in cui si utilizzino più sistemi di sintesi dei dati, per indicare quale unità può generare in maniera più o meno evidente un collo di bottiglia in grado di condizionare negativamente l’intera applicazione. I database di grandi dimensioni possono influire in maniera molto significativa sulle prestazioni generali del sistema ed è fondamentale avere una percezione concreta dei loro limiti per ottenere un adeguato bilanciamento delle risorse impiegate;

            • Plugin e estensioni: le applicazioni moderne, soprattutto quelle web e/o mobile contemplano l’impiego di vari moduli addizionali, il più delle volte sviluppati da terze parti. Uno stress test deve pertanto fornire elementi utili a rilevare quelle criticità che potrebbero compromettere le prestazioni generali a causa di uno di questi elementi, anche qualora l’applicazione generale non riscontrasse alcun tipo di problema. Una volta individuato il collo di bottiglia a livello di un componente fornito da terze parti, è possibile inoltrare le indicazioni utili a risolvere il problema, piuttosto che escludere temporaneamente l’estensione stessa.

Lo storico dei dati ottenuti consente pertanto agli strumenti utilizzati per eseguire uno stress test di generare una reportistica automatica, utile per svolgere tutte le analisi che il team di sviluppo intende adoperare per migliorare le condizioni limite dell’applicazione, ai fini di incrementare la resilienza generale del sistema.

Soak testing

Altrimenti noto come endurance testing, è una tipologia di stress test utile a simulare in maniera specifica il costante aumento degli utenti nel tempo, in modo da comprendere la sostenibilità di un sistema anche in un’ottica di lungo periodo. Misurando i KPI già descritti in precedenza, gli esecutori dei test devono monitorare tutti gli aspetti che influiscono a livello hardware, avendo cura di rilevare i tempi di risposta nell’ottica di capire se dopo un periodo più o meno lungo di esercizio le metriche sono ancora coerente con quelle previste dallo stato iniziale del test.

Il soak testing rileva pertanto le seguenti criticità:

• Un costante degrado del tempo di risposta quando il sistema viene eseguito per un periodo prolungato;
• Deterioramento delle risorse di sistema che emerge soltanto quando un test viene eseguito per un lungo periodo, in particolare per quanto riguarda la quantità di memoria utilizzata, lo spazio libero su disco e tutte le condizioni operative che sono in grado di influenzare negativamente le performance generali del sistema, con un riflesso negativo sulla user experience complessiva;
• Qualsiasi processo che possa influire sulle prestazioni del sistema, rilevabile soltanto durante un’esecuzione prolungata del sistema, ad esempio un sistema di backup, che viene eseguito soltanto in determinati periodi. Un soak test potrebbe fornire indicazioni utili alla sua pianificazione, suggerendo l’esecuzione di una procedura di backup durante le ore notturne o di minor carico da parte degli utenti, in modo da non rallentare gli altri processi attivi sul sistema.

Gli endurance test cercano di rilevare i trend e le variazioni sostanziali che avvengono nel comportamento del sistema. Potrebbe ad esempio accadere che per un’ora non ci siano variazioni, ma successivamente si verifichi un improvviso incremento della memoria di sistema utilizzato, che potrebbe penalizzare in maniera evidente il throughput complessivo. Perché si verifica tale circostanza? Probabilmente a causa di un processo periodico in background che inizia a funzionare da quel momento in avanti. La durata di un soak test è dunque non segue regole assolute ma si configura in maniera estremamente variabile, spaziando da un monitoraggio di poche ore a diverse settimane.

Spike testing

Lo spike testing costituisce una tipologia di stress test orientata a misurare le prestazioni del sistema quando si verifica un improvviso e significativo aumento degli utenti simultaneamente attivi, con l’obiettivo di comprendere se il sistema è in grado di gestirlo e fino a che punto è in grado di tollerare una situazione di carico decisamente più gravosa rispetto alle condizioni ordinarie.

A differenza del soak testing, lo spike testing è generalmente riferito a periodi di esercizio piuttosto brevi, proprio perché si ipotizza che una condizione limite si verifichi soltanto in coincidenza di un picco di attività, molto intenso e concentrato nella durata. Lo spike testing è molto utile per simulare le condizioni di carico cui il sistema potrebbe essere soggetto in particolari occasioni. Si pensi al lancio di un nuovo prodotto sul web, piuttosto che allo streaming di un evento sportivo per cui si prevede una quantità di pubblico molto elevata.

In tali circostanze è evidente che possa verificarsi un volume di traffico superiore alla norma, pertanto sarebbe decisamente utile conoscere a priori come il sistema è in grado di reagire, in modo da integrare, se necessario, ulteriori risorse utili alla sua esecuzione. Anche nel caso dello spike testing non è utile conoscere la condizione di picco, ma anche i tempi di ripristino necessari per riportare il sistema alla normalità tra un picco e l’altro, con una visione dettagliata dell’improvviso aumento e diminuzione del traffico.

Data la sua criticità è decisamente auspicabile predisporre un ambiente di test il più possibile isolato rispetto a quello di produzione, in quanto l’obiettivo dello spike test è quello di cercare di conoscere in anticipo le condizioni limite e gli eventuali incidenti da ripristinare nel caso in cui una situazione di sovraccarico dovesse causare un guasto.

I software di monitoraggio utilizzati per eseguire lo spike testing di un’applicazione consentono di simulare improvvisi e consistenti carichi di lavoro, capaci di crescere e decrescere in periodi anche estremamente brevi, per generare una reportistica utile a descrivere il comportamento dettagliato di ogni componente del sistema, in modo da rilevare in maniera puntuale i possibili anelli deboli della catena.

Volume testing

Il volume testing è orientato alla valutazione delle performance di un’applicazione quando è chiamata ad elaborare una grande quantità di dati e pertanto può essere considerato un caso particolare del load testing, che è predisposto per valutare le performance del sistema in condizioni di carico normali. Tali prerogative si riflettono nell’esecuzione di test differenti.

A volte il volume testing parte sulla base delle condizioni previste per il load testing, incrementando progressivamente la quantità di dati contenuta all’interno di un sistema di sintesi dei dati, come un database, piuttosto che un data mart o un data warehouse, ai fini di verificare il comportamento del sistema nel breve e nel lungo periodo, a seconda delle esigenze operative.

I test di volume devono quindi evidenziare quanto accade in tutti i componenti dell’infrastruttura interessati dalle attività sui dati per soddisfare una serie di obiettivi estremamente pratici:

• Conoscere la capacità del sistema, attraverso informazioni dettagliate utili a valutare la quantità di dati che il sistema può elaborare senza che si verifichino errori di alcun genere;
• Rilevare gli errori sui vari componenti di sistema, quando iniziano a verificarsi situazioni penalizzanti, come tempi di risposta più elevati, errori di sistema o, nella peggiore delle ipotesi, degli eventi exploit di sicurezza;
• Fornire elementi utili per pianificare le situazioni di emergenza che potrebbero verificarsi qualora il sistema si ritrovi sottodimensionato rispetto ai carichi di lavoro previsti;
• Conoscere nel dettaglio i tempi di risposta, per fare sì che le prestazioni dell’applicazione non risultino penalizzate in maniera significativa anche qualora i dati elaborati dovessero raggiungere quantità importanti, in modo da configurare delle soglie di esercizio adeguate;
• Evitare possibili perdite di dati quando aumenta la pressione sul sistema;
• Ridurre i costi operativi derivanti da possibili down e disservizi causati da arresti anomali che possono interessare il sistema nel caso in cui l’aumento del volume dei dati elaborati superi una soglia critica. Grazie al volume testing è infatti possibile conoscere nel dettaglio le situazioni critiche e agire di conseguenza, ad esempio per ottenere più risorse in maniera automatizzata e proattiva, progettando dei veri e propri piani di scalabilità, sia verticale (aumento dimensioni e velocità risorse hardware disponibili) che orizzontale (aggiunta di ulteriori componenti di sistema).

Capacity testing

Il capacity testing differisce dal tradizionale stress testing in quanto la sua azione è concentrata a valutare se un’applicazione è in grado di gestire la quantità di traffico per cui è stata originariamente progettata.

Il capacity testing mira a conoscere la cosiddetta security zone, entro cui è possibile garantire le massime prestazioni del sistema senza penalizzare in alcun modo la user experience dell’utente finale. I dati ottenuti mediante l’esecuzione di un capacity testing consentono alle aziende di evitare i fenomeni di abbandono che si verificano quando i tempi di caricamento superano una certa soglia temporale.

Nel caso delle applicazioni web e-commerce, molti studi dimostrano come un aumento dei tempi di caricamento di una pagina oltre i tre secondi, anche se estremamente contenuto, possa generare perdite economiche importanti a causa degli abbandoni e del fatto che un utente deluso dalla performance di un sito ben difficilmente sarà orientato a riprovare in un secondo momento, optando più probabilmente per una soluzione concorrente.

Scalability testing

Coincide in molti casi con il capacity testing ma è focalizzato in maniera specifica sulla capacità dell’applicazione di scalare le performance in funzione dei carichi di lavoro che si verificano, come nel caso di una variazione del numero degli utenti connessi al simultaneamente al sistema.

Non è raro vedere accomunati lo scalability testing e il capacity testing, ma mentre il primo è focalizzato nel capire come un sistema può adattarsi per soddisfare l’aumento e la diminuzione del numero di utenti, il secondo è riferito a garantire un determinato livello di servizio, cercando di capire il limite di utenti massimo che può sopportare. In entrambi i casi l’obiettivo è quello di garantire un’esperienza utente per lo meno accettabile, evitando situazioni di abbandono dovuti a performance scadenti.

Gli obiettivi del performance testing

Attraverso la descrizione delle varie tipologie che costituiscono la sua pipeline, appare evidente come un’azienda possa utilizzare il performance testing per individuare tutti i colli di bottiglia e i limiti prestazionali che potrebbero comportare dei problemi di comunicazione all’interno di un’applicazione e un condizionamento negativo della sua user experience.

È infatti molto frequente, soprattutto nelle prime fasi di testing, che un’applicazione ben progettata e supportata da un’infrastruttura IT di tutto rispetto finisca per offrire risultati poco soddisfacenti a causa di un singolo punto critico, talvolta costituito da una problema banalmente risolvibile, che va tuttavia identificato e compreso in tutti i suoi dettagli, in particolar modo per quanto concerne tutte le comunicazioni interne che si instaurano tra i vari componenti.

Nel caso delle applicazioni web due colli di bottiglia ricorrenti sono l’utilizzo di una banda troppo limitata in funzione degli utenti che accedono al servizio o la presenza di uno o più moduli le cui performance sono ottimizzate in maniera insoddisfacente. Tale condizione potrebbe ad esempio verificarsi soltanto quando si verificano determinati eventi o dopo un periodo di esercizio particolarmente prolungato.

Per queste e tante altre buone ragioni, il performance testing dovrebbe seguire la logica ciclica delle pipeline CI/CD su cui si sviluppa il ciclo di vita di un’applicazione, in modo da supportare tutte le fasi di testing e deploy per fornire elementi utili a risolvere qualsiasi problematica possa essere legata alle prestazioni, sia nelle condizioni di esercizio ordinarie (load testing) che nei picchi eccezionali che potrebbero verificarsi (stress testing).

Soprattutto quando gli strumenti utilizzati iniziano a diventare il pane quotidiano dei tester, è possibile attuare strategie particolarmente raffinate, come il confronto tra più applicazioni, come differenti versioni dello stesso software. È inoltre possibile verificare che il sistema soddisfi le specifiche richieste da un fornitore, anche nelle situazioni che prevedono il coinvolgimento di parti di software sviluppate da terze parti, si cui non si ha di fatto un controllo diretto.

Il campionario delle possibilità offerte dal performance testing è dunque molto ampio e grazie alle competenze e all’esperienza dei team chiamati ad implementarli e gestirli è possibile raggiungere risultati anche decisive per le sorti di un business.

Il performance testing on-premises e in cloud

Nati in origine per supportare lo sviluppo delle applicazioni on-premises, le metodologie e gli strumenti di performance testing si sono ben presto evoluti per soddisfare anche le esigenze delle applicazioni cloud native e garantire ad aziende e sviluppatori frequenti vantaggi in termini di riduzione del time to market e dei costi generali. Tali obiettivi sono raggiungibili sfruttando le qualità che caratterizzano i servizi in cloud, come i modelli pay-per-use e la scalabilità delle risorse disponibili.

Tuttavia, non sarebbe saggio dare per scontato che un’applicazione in locale funzioni come una in cloud, e l’esecuzione del performance testing non si profila in maniera speculare in queste due condizioni, dovendosi per forza adattare a tutte le caratteristiche proprie delle rispettive infrastrutture IT. Il cloud non è la panacea di tutti i mali, ma una grande opportunità per modernizzare le applicazioni e godere dei relativi vantaggi. Questa condizione comporta inevitabilmente dei sacrifici.

Se una configurazione hardware in locale è nota e continuamente aggiornata dal reparto IT aziendale, in cloud le applicazioni girano su sistemi virtualizzati di cui è sempre semplice, o quanto meno immediato, godere del totale controllo anche soltanto a livello amministrativo. I team che si occupano di testare le applicazioni devono quindi prestare un’attenzione specifica nel verificare una serie di situazioni che vanno dalla valutazione delle latenze operative e alla risoluzione delle possibilità vulnerabilità a livello di sicurezza informatica, considerando una fisiologica estensione della superficie di attacco.

Occorre infatti tenere sempre presente che le comunicazioni interne tra i microservizi che compongono un’applicazione in cloud potrebbero essere soggetti a controlli di sicurezza che potrebbero influire in maniera più o meno sensibile in termini prestazionali. Tali aspetti sono oltremodo rilevanti sia nel definire le operazioni da eseguire per svolgere un performance testing che per ottimizzare il software ai fini di raggiungere l’obiettivo più importante: rendere la user experience performante a tutti i livelli ed in grado di soddisfare tutti gli utenti potenziali ed acquisiti.

Le principali criticità del performance testing

Per quanto la corretta esecuzione di un performance testing possa generare una serie di vantaggi durevoli per le applicazioni aziendali, è bene valutare alcuni aspetti di criticità, soprattutto quando si tratta di operare sulle applicazioni in cloud. Tali fattori sono soprattutto relativi alle caratteristiche e alla scelta delle piattaforme software di performance testing. Anche se si tratta, come vedremo, di strumenti assolutamente maturi, la loro azione potrebbe almeno nelle configurazioni standard non soddisfare tutte le esigenze di un team di sviluppo.

In particolare, alcuni software sono concepiti per testare soltanto le applicazioni web/mobile e presentare in tali casi anche evidenti problemi di compatibilità, piuttosto che limiti oggettivi nel performance testing di applicazioni complesse. Esiste inoltre una notevole differenza tra l’impiego di soluzioni open source e soluzioni commerciali, in quanto i costi medi sono tutt’altro che trascurabili, ma il software libero potrebbe richiedere delle attività di personalizzazione che incidono in termini di disponibilità di competenze, tempi e costi di implementazione.

È dunque auspicabile precedere l’avvio dei test con una fase utile ad esplorare ed analizzare le effettive esigenze dei progetti di sviluppo, implementando la soluzione più ragionevole in funzione dei requisiti da soddisfare e dei budget effettivamente disponibili. Per acquisire tali conoscenze è spesso utile avvalersi di una consulenza qualificata, il cui costo può essere facilmente riassorbito dal disporre di procedure di performance testing capaci di ridurre significativamente i costi e il time to market delle applicazioni.

Le fasi di un performance testing efficace

Nel corso degli anni sono stati sviluppati molti framework per orientare una strategia di performance testing. Prendendo spunto dalle disposizioni del Microsoft Developer Network e di alcune altre fonti possiamo sintetizzare un ciclo composto da sette differenti fasi.

Definire l’ambiente di test per il performance testing

Consiste nell’identificare nel dettaglio l’ambiente di test e l’ambiente di produzione, oltre agli strumenti e alle risorse disponibili per eseguire il performance testing. Non si può infatti prescindere dalla conoscenza puntuale delle risorse hardware, software e di rete che caratterizzano l’infrastruttura IT. Tale know how consente di progettare e pianificare i test in maniera molto specifica, a tutto vantaggio della qualità delle informazioni ottenute. La conoscenza approfondita degli ambienti di test e produzione consente inoltre di valutare monte del progetto le criticità da risolvere, senza incappare in inutili lungaggini dopo l’avvio dei cicli di performance testing. Investire nella conoscenza degli ambienti di test costituisce solitamente una scelta molto ben ponderata, considerando che il ciclo va progressivamente affinato e migliorato per tutto il ciclo di vita di un progetto di sviluppo software.

Definire i KPI e i criteri di accettazione delle prestazioni

Si tratta molto semplicemente di capire quando un test produce un risultato soddisfacente o richiede azioni migliorative. Per raggiungere questo obiettivo, estremamente pratico è necessario definire i KPI desiderati e verificare se le misurazioni effettuate rientrano all’interno delle soglie preimpostate.

Come abbiamo visto, i principali KPI sono legati ai tempi risposta, alle velocità effettiva e alle condizioni di utilizzo di tutte le risorse disponibili nel sistema chiamato ad eseguire l’applicazione. In tale ottica, è interessante valutare come il tempo di risposta sia riferito all’utente (user experience), la velocità sia riferita all’azienda (infrastruttura IT), mentre l’utilizzo delle risorse sia invece una questione che riguarda l’intero sistema e la condizione ottimale vada ricercata a lungo, attraverso l’esecuzione ciclica di performance testing a cui associare le azioni correttive necessarie per raggiungere almeno i KPI prefissati.

Pianificazione dei processi di test

Consiste nella definizione degli scenari e le variabili in gioco, causate dalle varie interazioni che si generano tra i componenti di un’applicazione e gli utenti simulati in fase di testing. La pianificazione deve in particolar modo entrare nel merito di come eseguire e monitorare tutti i test che vengono eseguiti sulle variabili, per acquisire i dati relativi alle metriche da osservare ed analizzare. Si tratta di un’operazione che in molti casi richiede l’avvio di procedure distinti, applicando modelli differenti per capire quale possa adattarsi al meglio allo scenario ipotizzato.

Configurazione dell’ambiente di test (test environment)

La configurazione dell’ambiente di test coincide con la messa a punto degli strumenti necessari per operare sulle componenti e sulle feature dell’applicazione, avendo soprattutto cura di verificare il corretto funzionamento dei tool dedicati al monitoraggio delle risorse;

Progettazione dei test

Si tratta di una fase cui va prestata una particolare attenzione per garantire la rispondenza nell’acquisizione dei parametri relativi alle metriche previste, rispettando al tempo stesso le caratteristiche funzionali dell’applicazione, ricordando sempre che il test deve essere funzionale a quest’ultima, mai il contrario;

Performance testing: esecuzione dei test

Oltre alle fasi puramente strumentali, per cui sono richieste competenze specifiche, riguarda tutti gli aspetti legati al monitoraggio e alla convalida dei risultati raccolti. È importante non variare le condizioni dell’ambiente di test, in modo da garantire nel tempo una situazione di facile confronto tra i risultati ottenuti dai vari cicli eseguiti, qualora questi venissero eseguiti in periodi sensibilmente differiti. La perdita dell’ambiente di test comporterebbe un’evidente criticità nella lettura dei risultati e nella verifica di coerenza con i KPI preimpostati;

Analisi dei risultati acquisiti durante i test e ottimizzazione dell’applicazione

Se le fasi precedenti sono state svolte in maniera adeguata, i sistemi di performance testing restituiranno una reportistica attendibile dello stato del sistema, che costituisce la base per tutti gli approfondimenti analitici. Tali risultati consentono al team di sviluppo di acquisire una conoscenza più elevata in merito alle performance, per ottimizzare l’applicazione e contribuire al suo miglioramento continuo.

In un’ottica di CI/CD a questo punto diventa essenziale predisporre le condizioni per l’avvio del test successivo, nella continuità di un loop fisiologicamente chiamato ad accompagnare l’applicazione lungo tutto il suo ciclo di vita, che comprende lo sviluppo iniziale e la successiva manutenzione.

L’esecuzione di un numero di test sempre più elevato consente agli sviluppatori di confrontare su base oggettivi i risultati ottenuti e procedere ai progressivi affinamenti al sistema. Se i primi test consentono di apportare miglioramenti molto consistenti, mediamente a lungo andare sono necessari molti sforzi per aggiungere poche migliorie.

È dunque necessario capire quanto investire in termini di tempo e risorse sul performance testing, in quanto gli obiettivi sono specifici di ogni progetto e dovrebbero coincidere, per quanto riguarda la misura minima, con i KPI inizialmente definitivi. Molto dipende dalla natura dei colli di bottiglia che emergono dai test, anche per valutare se abbia più senso investire nell’ottimizzazione del codice del software, piuttosto che aumentare le risorse hardware e renderlo di conseguenza più performante in questo modo.

I software utilizzati

Il mercato del performance testing si è incredibilmente evoluto nel corso degli ultimi trent’anni, considerando che una soluzione come LoadRunner è ormai attiva dal 1994. Strada facendo sono apparse numerose alternative, al punto che oggi si contano decine di opzioni su cui puntare, sia in funzione della tipologia di progetto da testare che delle risorse a disposizione.

La comodità di queste soluzioni software è garantita soprattutto dal fatto che sono in grado di gestire end-to-end tutto il processo ed acquisire uno storico di dati che sarebbe molto difficile implementare manualmente, anche a patto di possedere le competenze utili per scriptare tutte le fasi di automatizzazione previste. Per quanto riguarda lo sviluppo cloud native, i principali CSP (Cloud Service Provider) come Microsoft Azure, AWS, Google Cloud, Oracle Cloud Infrastructure ecc. offrono soluzioni integrate nelle loro piattaforme, in grado di automatizzare almeno le funzioni basilari.

Le soluzioni standalone consentono di personalizzare moltissimo la pianificazione e l’esecuzione dei testi. Tornando a LoadRunner, esso costituisce lo strumento di test più maturo tra quelli attualmente presenti sul mercato. Dopo essere stato forgiato da Mercury Interactive, tale azienda è stata acquisita nel 2006 da HP, che ha successivamente venduto la propria divisione software a Micro Focus, che tuttora si occupa del suo sviluppo. LoadRunner costituisce una suite molto completa che si articola su varie installazioni (VuGen, Controller, Generator, Agent Process e Analysis) anche se la sua conformazione classica si adatta probabilmente meglio al contesto on-premises piuttosto che al cloud, anche se tale ambito pare attualmente oggetto di una solida implementazione. Uno degli storici punti di forza di LoadRunner risiede nel fatto di saper simulare un numero di utenti molto elevato.

Parallelamente a LoadRunner si è diffuso un progetto open source sviluppato da Apache nel 1999, vale a dire JMeter e diventato ben presto popolare tra chi cercava una soluzione alternativa, maggiormente personalizzabile e soprattutto gratuita rispetto a LoadRunner, anche se la sua customizzazione non risulta probabilmente tra le più semplici. Ad oggi JMeter rimane una soluzione particolamente diffusa per il load testing, con un buon supporto per quanto concerne il test delle funzionalità FTP, LDAP, dei Web Service e delle connessioni dei database. Rispetto a LoadRunner appare più spartano anche nella redazione dei report ma la sua disponibilità su tutti i sistemi operativi e la sua completezza lo ha reso uno strumento polivalente in grado di formare nel tempo una community decisamente estesa.

Sulla scia dei due capostipiti, è stato intrapreso lo sviluppo di soluzioni che hanno preso spunto da LoadRunner per dare luogo a strumenti di performance testing più moderni a livello di funzionalità ed interfacce, con una netta preferenza per soluzioni no-code o low-code e logiche self-service in grado di gestire tutte le fasi del processo in maniera il più possibile automatizzata, anche per quanto concerne la reportistica.

Dal 2005 Microsoft ha implementato Visual Studio Load Tests, una soluzione presente in tutte le release di Visual Studio con vari update che sono successivamente confluiti in Cloud Load Generation, che attualmente figura tra i servizi in forza al catalogo di Microsoft Azure.

Tra le applicazioni più moderne ritroviamo ad esempio NeoLoad, ad opera di Neotys. Efficiente tanto nei load test quanto negli stress test per il software web / mobile, database e application server. È tagliato su misura per DevOps e il continous delivery, può simulare milioni di utenti sia in ambito on-premise che in cloud.

Un’altra applicazione di performance testing piuttosto nota e diffusa è WebLOAD, sviluppata da RadView, soluzione molto completa che si è sin dalle proprie origini distinta per un costo inferiore rispetto a LoadRunner, rispetto al quale è piuttosto simile a livello di funzionalità. Per questa ragione è stato il suo principale competitor commerciale per diversi anni.

Un altro nome noto nell’ambito dei software per il performance testing è rappresentato da Silk Performer, originariamente sviluppato da Segue e finito, grazie ad una serie di acquisizioni successive, proprio in capo a Micro Focus, che lo ha affiancato a LoadRunner per consolidare la propria egemonia soprattutto nell’ambito del comparto dedicato al load testing, dove impiega le due soluzioni per coprire un ampio segmento di mercato.

Tra le alternative che animano attualmente il mercato dei performance tester possiamo citare una pluralità di nomi, quali LoadUI (SmartBear), LoadNinja (SmartBear), ReadyAPI (SmartBear), SOASTA, Rational Performance Tester (IBM), StresStimulus (Stimulus Technology), Kobiton, LoadView (Dotcom Monitor), Stormforge, Eggplant (Keysight Technologies), K6 (Grafaba Labs), AppvanceIQ (Appvance.ai), Apica, LoadStorm (CustomerCentrix), Httperf (HP), OpenSTA, Predator, smartmeter.io e molti altri.