Nota dell'editore: Benvenuti alla serie Leadership In Test, realizzata dal guru e consulente del testing software Paul Gerrard. La serie è progettata per aiutare i tester con alcuni anni di esperienza—soprattutto quelli inseriti in team agili—a eccellere nei loro ruoli di test lead e manageriali.
Nell'articolo precedente abbiamo esplorato il service testing e i suoi componenti principali: test delle prestazioni, failover/soak testing e gestibilità. Come promesso, qui approfondiremo ulteriormente il test delle prestazioni.
Iscriviti alla newsletter di The QA Lead per essere avvisato quando saranno pubblicate le nuove parti della serie. Questi post sono estratti dal corso Leadership In Test di Paul che consigliamo vivamente per approfondire questo e altri argomenti. Se decidi di acquistarlo, usa il nostro esclusivo codice coupon QALEADOFFER per ottenere $60 di sconto sul prezzo intero del corso!
Ciao e benvenuto nella serie Leadership In Test. Nell'ultimo articolo, abbiamo esaminato il service testing per le applicazioni web.
Lo scopo di questo capitolo è fornire alcuni consigli e best practice per la gestione di un componente critico del service testing menzionato in quell'articolo, ovvero, rullo di tamburi... il test delle prestazioni!
Vedremo:
- Obiettivi del test delle prestazioni
- Quattro prerequisiti per un test delle prestazioni
- Strumenti per il test delle prestazioni
- Il processo di test delle prestazioni
Iniziamo.
Obiettivi del test delle prestazioni
Per un rapido riepilogo, possiamo definire l'obiettivo principale del test delle prestazioni come segue:
“Dimostrare che il sistema funziona secondo le specifiche, con tempi di risposta accettabili, mentre elabora i volumi di transazioni richiesti su un database di dimensioni produttive.”
L’ambiente di test delle prestazioni è un banco di prova che può essere utilizzato anche per altri test, con obiettivi più ampi, che possiamo riassumere come segue:
- Valutare la capacità del sistema di crescere (Se non sei sicuro su quale software possa soddisfare le tue esigenze, la nostra lista dei migliori software di gestione database può aiutarti.)
- Identificare i punti deboli dell’architettura
- Ottimizzare il sistema
- Individuare bug poco evidenti nel software
- Verificare la resilienza e l'affidabilità.
La tua strategia di test dovrebbe definire i requisiti per un'infrastruttura di test che permetta di raggiungere tutti questi obiettivi.
Quattro prerequisiti per un test delle prestazioni
"Se dovesse mancare uno di questi prerequisiti, procedi con molta cautela prima di eseguire i test e pubblicare i risultati. Utilizzare strumenti di automazione quality assurance può aiutare a garantire che questi prerequisiti siano soddisfatti. I test potrebbero essere difficili o impossibili da eseguire, o la credibilità di eventuali risultati pubblicati potrebbe essere seriamente compromessa e facilmente contestata.
1. Requisiti quantitativi, pertinenti, misurabili, realistici e raggiungibili
Come base per tutti i test, i requisiti (obiettivi) di prestazione devono essere concordati prima del test in modo da poter stabilire se il sistema soddisfa tali requisiti.
I requisiti relativi alla capacità di throughput del sistema o ai tempi di risposta, per essere utili come riferimento con cui confrontare i risultati di prestazione, dovrebbero avere le seguenti caratteristiche. Devono essere:
- Espressi in termini quantitativi.
- Pertinenti rispetto all’attività che un utente desidera svolgere.
- Misurabili tramite uno strumento (o cronometro) e a un costo ragionevole.
- Realistici rispetto alle durate delle attività utente.
- Raggiungibili a un costo ragionevole.
Spesso, i requisiti di prestazione sono vaghi o inesistenti. Se possibile, cerca qualsiasi requisito documentato. Se ci sono lacune, potresti doverli documentare a posteriori.
Prima che un test delle prestazioni possa essere specificato e progettato, è necessario concordare i requisiti.
- Tempi di risposta delle transazioni.
- Profili di carico (il numero di utenti e i volumi di transazioni da simulare).
- Volumi di database (il numero di record presenti nelle tabelle del database previsti in produzione).
È comune che i requisiti di performance vengano definiti in termini vaghi. Tali requisiti sono spesso basati su volumi aziendali stimati e previsti; potrebbe essere necessario coinvolgere gli utenti aziendali affinché riflettano in modo realistico sui requisiti di performance.
Potresti anche dover effettuare tu stesso un'analisi dei requisiti e documentare tali requisiti come obiettivi di performance da raggiungere.
2. Un Sistema Stabile
Se il sistema è pieno di bug e inaffidabile, non andrai lontano con un test di performance. I test di performance mettono sotto stress tutti i componenti architetturali a un certo livello. Tuttavia, affinché i test di performance producano risultati utili, il sistema e l'infrastruttura tecnica devono essere ragionevolmente affidabili e resilienti fin dall'inizio.
3. Ambiente di Test Realistico
L'ambiente di test dovrebbe essere configurato affinché il test sia significativo. Probabilmente non potrai replicare il sistema di destinazione o di produzione, ma l'ambiente di test dovrebbe essere comparabile, in tutto o in parte, all'ambiente di produzione finale. Dovrai concordare con l'architetto del sistema quali compromessi siano accettabili e quali no, o quantomeno quale interpretazione utile si possa dare ai risultati dei test.
Creare un ambiente di test realistico è essenziale per eseguire test di performance significativi. Per strumenti che possono aiutarti a simulare condizioni reali, dai un'occhiata alla nostra selezione di piattaforme di testing software accuratamente scelta.
4. Ambiente di Test Controllato
I tester delle performance necessitano di stabilità. Non solo in termini di affidabilità e resilienza di hardware e software, ma anche nella minimizzazione dei cambiamenti nell’ambiente o nel software in fase di test. Ad esempio, se l’interfaccia viene modificata anche solo leggermente, gli script di test progettati per pilotare le interfacce utente rischiano di fallire immediatamente.
Qualsiasi modifica nell’ambiente dovrebbe essere strettamente controllata. Se la modifica corregge errori che difficilmente influenzano la performance, potresti anche valutare di non accettare la release. Devono essere accettate solo le modifiche pensate per migliorare le performance o l’affidabilità.
Kit di Strumenti per il Performance Testing
Il tuo kit per il performance testing si compone di cinque strumenti principali:
- Creazione e Gestione Dati di Test - per creare i grandi volumi di dati sul database necessari alla prova. Ci si aspetta che questo sia un tool basato su SQL, o forse un software per PC come Microsoft Access, collegato al tuo database di test.
- Generazione del carico – gli strumenti comuni usano driver di test che simulano utenti virtuali inviando messaggi HTTP ai web server.
- Strumento di Esecuzione Applicativa – questo pilota una o più istanze dell’applicazione tramite l’interfaccia browser e registra le misurazioni dei tempi di risposta. (Di solito è lo stesso strumento utilizzato per la generazione del carico, ma non è obbligatorio).
- Monitoraggio delle Risorse - utility che monitorano e registrano le risorse di sistema di client e server, il traffico di rete, l’attività del database ecc.
- Analisi e Reporting dei Risultati - gli strumenti di esecuzione test e monitoraggio risorse generano grandi volumi di dati per l’analisi.
Lettura correlata: I 10 MIGLIORI SERVIZI DI ANALISI SQL PER I TEAM DI QA
Il Processo di Performance Test
Qui sotto una figura mostra un processo generico per il testing e l’ottimizzazione delle performance. L’ottimizzazione non fa davvero parte del processo di test ma è parte inscindibile della fase di miglioramento di performance e affidabilità. L’ottimizzazione può comportare modifiche all’infrastruttura architetturale ma non dovrebbe incidere sulla funzionalità del sistema in test.

Ora vedremo come sviluppare, eseguire, analizzare e riportare i risultati di un performance test.
Sviluppo Incrementale dei Test
Lo sviluppo dei test di norma viene eseguito in modo incrementale in quattro fasi:
- Ogni script di test viene preparato e testato in isolamento per essere sottoposto a debug.
- Gli script vengono integrati nella versione di sviluppo del carico di lavoro e viene eseguito il carico di lavoro per verificare la compatibilità del nuovo script.
- Man mano che il carico di lavoro cresce, il framework di test in sviluppo viene costantemente affinato, sottoposto a debug e reso più affidabile. Anche l’esperienza e la familiarità con gli strumenti crescono.
- Quando l’ultimo script viene integrato nel carico di lavoro, il test viene eseguito come una "prova generale" per assicurarsi che sia completamente ripetibile e affidabile e pronto per i test formali.
I test intermedi possono fornire risultati utili
L'esecuzione di una parte del carico di lavoro e delle transazioni di test può mettere in luce problemi di performance. Test a basso volume di carico possono anche offrire un’indicazione precoce sul traffico di rete e sui potenziali colli di bottiglia quando il test viene ampliato.
Tempi di risposta scadenti possono essere causati da una scarsa progettazione dell’applicazione e possono essere indagati e risolti dagli sviluppatori precocemente. I primi test possono anche essere eseguiti per lunghi periodi come soak test.
Esecuzione dei Test
L’esecuzione dei test richiede una certa organizzazione e coordinamento. Dovresti collaborare con i partecipanti che supporteranno e monitoreranno il sistema durante l’esecuzione dei test. Il team di "monitoraggio dei test" potrebbe essere distribuito, quindi è importante mantenerli aggiornati per assicurare che il test si svolga senza intoppi e i risultati siano raccolti correttamente.
Oltre al coordinamento tra i vari membri del team, l’esecuzione dei test di performance segue tipicamente una routine standard.
- Preparazione del database (ripristino da tape, se necessario).
- Preparare l’ambiente di test secondo necessità e verificarne lo stato.
- Avviare i processi di monitoraggio (rete, client e server, database).
- Avviare la simulazione di carico e osservare i monitor di sistema.
- Se si utilizza uno strumento separato, quando il carico si è stabilizzato, avviare lo strumento di esecuzione del test applicativo e la misurazione dei tempi di risposta.
- Monitorare attentamente il test durante tutta la sua durata.
- Se gli strumenti di esecuzione del test non si interrompono automaticamente, terminare il test al termine del periodo previsto.
- Interrompere gli strumenti di monitoraggio e salvare i risultati.
- Archiviare tutti i risultati raccolti e assicurarsi che tutti i dati dei risultati siano adeguatamente salvati in backup.
- Produrre report intermedi; consultarsi con gli altri membri del team riguardo eventuali anomalie.
- Preparare analisi e report.
Coordinare i vari membri del team durante l’esecuzione dei test può essere impegnativo. Semplifica questo processo integrando strumenti avanzati di gestione dei test progettati per Jira, che offrono funzionalità come collaborazione in tempo reale e reportistica.
La fase di tuning segue generalmente i test quando si rilevano problemi o quando sono possibili ottimizzazioni note. Se un test viene ripetuto, è fondamentale che tutte le modifiche dell’ambiente vengano registrate, in modo da associare eventuali differenze di comportamento e di performance alle modifiche di configurazione apportate.
Quando si tratta di gestire i casi di test per il performance testing, un software di gestione dei test può fare davvero la differenza. Permette una migliore organizzazione, tracciamento e persino automazione dei casi di test.
In generale è consigliabile cambiare una sola variabile alla volta, in modo che eventuali differenze di comportamento siano riconducibili alle modifiche effettuate.
Analisi dei Risultati e Reportistica
Il report più tipico per un’esecuzione di test riassumerà queste misurazioni e, per ciascuna misurazione, riporterà i seguenti dati:
- Il numero totale delle misurazioni.
- Tempo minimo di risposta.
- Tempo massimo di risposta.
- Tempo medio di risposta.
- Tempo di risposta all’ennesimo percentile (tipicamente il 95mo percentile).
Lo strumento di generazione del carico presente nella tua toolkit dovrebbe registrare il conteggio di ciascun tipo di transazione durante l’esecuzione del test. Dividendo questi valori per la durata del test si ottiene il tasso di transazione o throughput effettivamente raggiunto.
Il conteggio delle transazioni rappresenta il carico applicato al sistema. Questo presuppone che le proporzioni delle transazioni eseguite corrispondano al profilo di carico che si desidera applicare.
Il carico applicato dovrebbe corrispondere al profilo di carico simulato - ma potrebbe non essere così se il sistema risponde lentamente e le transazioni vengono eseguite a velocità variabili.
Di solito eseguirai una serie di test con carichi variabili. Utilizzando i risultati di queste prove, traccia un grafico del tempo di risposta di una transazione rispetto al carico applicato.
Gli strumenti di monitoraggio delle risorse di solito dispongono di funzionalità di reportistica statistica o grafica che mostrano l’utilizzo delle risorse nel tempo. Rapporti avanzati sull’utilizzo delle risorse rispetto al carico applicato sono molto utili e possono aiutare nell’identificazione dei colli di bottiglia nell’architettura di un sistema.
In bocca al lupo!
Iscriviti alla newsletter di The QA Lead per ricevere una notifica quando nuove parti della serie saranno pubblicate. Questi post sono estratti dal corso Leadership In Test di Paul che raccomandiamo vivamente per approfondire questo e altri argomenti. Se decidi di seguirlo, usa il nostro codice sconto esclusivo QALEADOFFER per ottenere $60 di sconto sul prezzo completo del corso!
Lettura correlata: METRICHE DI MONITORAGGIO SERVER DA TENERE D’OCCHIO PER SALUTE E PRESTAZIONI DEL SISTEMA
