Boso Consulting

Verificare la qualità delle
applicazioni Web e Client/Server:
i test di carico
Cos'è un test di carico
È una verifica delle prestazioni di una determinata un'applicazione Web
in condizioni di carico. Idealmente, questa verifica dovrebbe essere fatta al
momento di andare in produzione, per verificare la effettiva capacità del
sistema complessivo (composto dalle applicazioni, dal middleware e
dall'hardware su cui queste sono installate) di servire gli utenti previsti.
Perché fare un test di carico: le esigenze
Molteplici sono le situazioni che richiedono un test di carico:
➢“Sto preparando il nuovo portale, ora gli utenti vorranno usare le nuove
funzioni molto più spesso: quanti server devo prevedere?”
➢“I miei clienti potranno vedere le consegne via web, ma l'applicazione di
magazzino che le gestisce riuscirà a soddisfare le richieste?”
➢“Come si comporterà il mio gestore documentale con l'introduzione della
nuova applicazione intranet?”
➢“La nuova applicazione riuscirà a gestire il traffico previsto?”
➢“Devo verificare che le prestazioni attuali siano costanti nel tempo!”
➢“Riuscirà il mio CRM a gestire i tablet in dotazione alla forza vendita?
Si potrebbero aggiungere molti altri casi....
Importanza delle performances applicative
Tutti questi scenari hanno in comune l'importanza fondamentale del buon
funzionamento e della facilità d'uso dell'applicazione:
Load Generator
Generatore
di traffico
Application server
DataBase server
Sistema sotto test
Concretamente, il test si svolge utilizzando appositi software che sono in
grado di simulare il comportamento di molti utenti in modo parallelo, raccogliendo i dati sulle risposte ricevute.
Chiaramente, l'utilità è massima quando gli utenti sono molti, dispersi e non
facilmente coordinabili: in questo caso infatti non è possibile dire semplicemente: ”domani a quest'ora, tutti devono fare delle prove sul nuovo
sistema”: generalmente, si ha un'interazione ed un controllo molto “debole”
nei confronti degli utenti di applicazioni web, ed ancora meno su quelli che
fanno uso di dispositivi mobili (smartphone e tablet).
Fortunatamente, esistono strumenti open source potenti ed efficienti per
risolvere questo problema:
➢la potenza è necessaria per simulare un numero di utenti molto elevato,
senza incorrere in limitazioni pratiche: se necessario, è possibile utilizzare
più server per eseguire uno stesso script;
➢l'efficienza invece consente di scrivere e provare velocemente i test in
modo rapido, partendo dalla registrazione del comportamento dell'utente
“reale”.
L'efficienza di questa attività dipende molto dallo strumento utilizzato. I più
diffusi pacchetti commerciali hanno costi di licenza molto alti, tipicamente
legati al numero di utenti simulati. Inoltre, trattandosi di prodotti di nicchia, il
supporto che si riceve è abbastanza lento e tipicamente in lingua inglese.
Jmeter invece è un prodotto open source, quindi gratuito, è completamente scritto in Java e riceve supporto da una comunità di utenti molto
attiva. Inoltre, sulla base delle esperienze precedenti, si propone una
metodologia, una documentazione e dei template che riducono tempi e
costi; in questo modo si elimina l'impegno richiesto ai clienti finali per
effettuare il test. La soluzione proposta consente di effettuare test si
applicazione Web.
➢se l'utente è un cliente esterno, esiste un ampia letteratura1 che dimostra
che una lentezza anche minima, si traduce in disaffezione e perdita di
fatturato;
➢se l'utente è un dipendente o un interno invece, il danno si misura in
termini di perdita di produttività; anche in questo caso esistono studi 2 ben
documentati;
➢in tutti i casi, l'introduzione di una nuova applicazione è un momento
molto critico: se gli utenti, che hanno sempre una naturale resistenza al
cambiamento, incontrano dei problemi tecnici anche marginali, diventa
poi molto difficile recuperare la loro fiducia.
Per tutti questi motivi, una verifica delle prestazioni preliminare al lancio in
produzione costituisce un necessità imprescindibile, esattamente quanto
il test funzionale.
Scopo e interlocutori
L'obbiettivo del test quindi è chiaro: garantire che l'insieme costituito
dall'applicazione e dall'infrastruttura) offra le performance corrette. Può
essere utile riflettere sui ruoli che hanno maggiormente l'esigenza di
effettuare questi test: il primo interlocutore di solito è il responsabile
dell'esercizio che usa il test di carico per:
➢validare una nuova infrastruttura/ installazione
➢validare un nuovo rilascio
➢analizzare e ottimizzare l'infrastruttura esistente
➢individuare problemi che si manifestano sotto carico (tipicamente come
malfunzionamenti casuali)
Dal punto di vista della tipologia di azienda, l'interesse è massimo per i
centri servizi (per esempio bancari, o internet service provider), i system
integrator, e le software house che rilasciano un nuovo software di base
e devono fornire una sizing guide e le indicazioni per il tuning.
1
2
http://glinden.blogspot.it/2006/11/marissa-mayer-at-web-20.html
http://www.websiteoptimization.com/speed/tweak/psychology-webperformance/
http://www.vm.ibm.com/devpages/jelliott/evrrt.html
Standard di riferimento
Non esistono al momento degli standard specifici in questo settore, sia a
causa della rapida evoluzione delle tecnologie connesse, che della obbiettiva difficoltà di normare esigenze ed applicazioni molto diverse.
Le normative di interesse si esprimono in termini generali e sono raccolte
nella seguente tabella.
Standard
Note
ISO 27001 (SGSI),
Prescrivono “capacity control and management” e
“service validation”
ITIL
Due aree fanno riferimento ai test di carico:
• Capacity management (part of Service Design)
• Service validation (part of Service Transition)
ll test di carico verifica la rispondenza del servizio
implementato rispetto ai requisiti richiesti.
ISTQB
L'International Software Testing Qualifications Board
si occupa delle metodologie di test software, e dedica
un breve paragrafo del suo silllabo al “Testing di
caratteristiche software non funzionali (testing non
funzionale)”
Metodologia e contenuti dei test
La metodologia ISTQB adottata è relativamente semplice si struttura in 5
punti:
1. Pianificazione e controllo
2. Analisi e progettazione, che comprende:
a) Verifica Tecnica e funzionale
b) Individuazione delle misure da effettuare
c) Definizione degli obbiettivi di prestazione
3. Implementazione ed esecuzione, che comprende:
a) Predisposizione dell'infrastruttura necessaria al test
b) Preparazione degli script
c) Esecuzione baseline (valori di riferimento)
d) Esecuzione del test
4. Analisi dei risultati e stesura del report, con feedback e
raccomandazioni sull'infrastruttura.
5. Attività di conclusione dei test (verbalizzazione wrap-up)
Il seguente diagramma di Gantt presenta una distribuzione “tipica” dei
tempi tra le diverse fasi.
1
2
3
4
5
6
7
8
9
10
11
12
Pianificazione e controllo
Analisi e progettazione
Implementazione script
Esecuzione baseline
Esecuzione del test
Stesura di un rapporto
Attività di conclusione
Spesso si ripete un ciclo tra le operazioni di test (3D) e l'analisi dei risultati
(4), per verificare l'efficacia delle azioni di ottimizzazione, tuning e potenziamento intraprese. Nel dettaglio, le fasi più significative comprendono:
1) Pianificazione e controllo:
Garantiscono che le attività di test siano attivate e condotte in modo
tempestivo e coerenterispetto al progetto globale.
2) Analisi e progettazione,
Anche se l'analisi iniziale talvolta viene trascurata,iI realtà un buon piano di
test deve porsi degli obbiettivi significativi (stimando le funzionalità maggiormente utilizzate) e realistici (approssimando al meglio le condizioni
reali del carico). Un test di carico ha una copertura molto più ridotta del test
funzionale: è comune il caso di testare solo un 20% delle funzioni previste,
che spesso rappresentano oltre il 90% delle operazioni effettuate.
Di solito, si parte da una valutazione delle statistiche attuali, considerando:
•
le pagine /funzioni più utilizzate (volume)
•
le funzioni più “pesanti” o di maggior valore
•
i momenti di maggior traffico (quarto d'ora di picco)
L'individuazione delle funzioni “di valore” è molto importante, e richiede una
conoscenza ed una comprensione degli aspetti di business, ma anche degli
impatti sull'usabilità: gli utenti sono più disponibili ad un'attesa per ricevere
informazioni per loro importanti.
Vanno considerate anche le evoluzioni future. La stima di queste variazioni
è spesso difficile perché non può basarsi su dati storici e deve essere
condivisa con le linee di business.
Infine, come sintesi di tutti le considerazioni su riportate, vengono definiti gli
obbiettivi:
➢
➢
➢
Volumi da erogare (volume target)
Mix di operazioni
Tempi di risposta richiesti
Durante la fase di analisi vengono stesi anche i requisiti materiali per
l'esecuzione del test: il numero di macchine per generare il traffico, le
utenze necessarie (con le relative credenziali ) ed eventualmente i dati che
devono essere pre-caricati.
È importante ricordare che lo scopo dei test non è quello di individuare il
punto di rottura, ma di verificare che il sistema regga il carico per cui è
stato progettato.
3B) Preparazione degli script
Spesso questa è la fase temporalmente più lunga e laboriosa.
Normalmente, partendo dai percorsi di navigazione definiti nella fase di
analisi si registrano le transazioni web e quindi si procede ad una
parametrizzazione di questi percorsi, variando i parametri (si pensi alle
query, al caricamento di dati e di files, ecc.).
3C) esecuzione della baseline
Una volta realizzato lo script, si esegue un primo test, creando il minor
impatto possibile sul sistema sotto test. In questo modo si verifica il corretto
funzionamento dello script e contemporaneamente si raccolgono i tempi di
risposta in una situazione ottimale: si verifica quindi se il sistema è in grado
di eseguire il Mix di operazioni previsto con i tempi di risposta richiesti,
con carico ridotto.
La baseline costituisce il riferimento per tutti i test successivi.
3D) Esecuzione
A questo punto si esegue il test vero e proprio, imponendo carichi via via
crescenti. Spesso il carico viene espresso in rapporto al volume target:
tipicamente si fanno prove al 60%, 80%, 100% e 120% del target, monitorando le prestazioni (tempi di risposta) e lo stato dei sistemi sotto test
(CPU, RAM, traffico verso i dischi e verso la LAN). Si ottengono pertanto
dei test “a gradini”, con carico crescente.
In altri casi si eseguono dei test di endurance, verificando il comportamento sotto carico per periodi prolungati.
5) Analisi dei risultati e stesura del report,
Man mano che si eseguono i test, i dati più significativi vengono raccolti ed
inseriti nel rapporto finale.
Talvolta, nei casi più complessi, può essere necessario eseguire più cicli di
analisi-realizzazione-esecuzione, particolarmente in quei casi in cui il
contesto non è ancora definito: per esempio se l'applicazione è ancora in
sviluppo o il modello di utilizzo non è noto, o l'infrastruttura finale non è
disponibile.
I dati ottenuti e presentati possono essere di vario tipo:
➢ Analisi dei tempi di risposta al crescere del carico;
➢ Analisi dei tempi di risposta nel tempo
➢ Analisi dei tasso di errore
➢ Analisi per scenario, in cui si analizzano le performance a carico
costante, variando alcune caratteristiche del sistema sotto test.
➢ Analisi delle risorse impiegate: la figura seguente evidenzia il
carico di CPU rilevato durante un test a gradini
120,00%
800
700
100,00%
600
80,00%
500
60,00%
400
300
40,00%
200
20,00%
100
0,00%
0
Costi
Ogni test ha una forte componente progettuale: ogni caso è storia a sé
per le esigenze ed i risultati che si pone.
La valutazione economica viene definita solo dopo una breve analisi
preliminare, che richiede un accesso al sito per una verifica tecnica.
Contatti
Web
Mail
Mob
www.bosoconsulting.it
[email protected]
+39 335 7243 445
boso_wload_v1.3.odt