Performance test

Software testing
Lezione 5 – Non functional Testing
Federica Spiga
[email protected]
A.A. 2010-2011
Autori: F.Rabini/F.Spiga
1
Test non funzionali


Sono quei test che non sono correlati direttamente alle
funzionalità, ma ad altri requisiti non strettamente funzionali,
come per esempio di usabilità, performance, sicurezza, portabilità
ecc
I più comuni sono:

Regression test

Security test

Usability test

Performance test

Stress test .

Volume test (o load test, test di carico)
2
Regression test




Il regression test è effettuato immediatamente dopo che sono stati
effettuati dei cambiamenti
Lo scopo è assicurare che le modifiche al codice non abbiano avuto
conseguenze inattese
Il regression testing sia durante la fase di sviluppo sia durante la
maintenance del sistema
Il regression test è importante per il monitoraggio degli effetti delle
modifiche al codice
3
Perchè il Regression test??




Il Bug fixing spesso crea problemi in altre aree dove gli
sviluppatori non si sono concentrati
Spesso le attività di bug fixing non risolvono i problemi
Serve a verificare che il prodotto continui a funzionare dopo
delle modifiche all’infrastruttura
Verifica la compliance verso standard e regolamenti
4
Regression testing



Bug regression testing: verifica che il bug fixig ha rimosso i
sintomi del bug che è stato identificato
Old fix regression: verifica che le nuove fix non hanno creato
problemi alle vecchie fix
Functional regression: verifica che il nuovo codice o fix non
hanno creato problemi alla precedente versione di codice
funzionante
5
Regression testing – come effettuarlo??


Si ripetono gli stessi test che hanno scoperto il bug per
verificare che i bug siano stati effettivamente fissati
Si scelgono un set di test, per verificare che i change non
abbiano introdotto altri errori in altre aree del codice
•
Questo set di test può essere:
»
»
Unico e avere uno o più test per ogni area del prodotto
sotto test
Uno per ogni areea del prodotto
6
Security test
 Cercando di accedere a dati o a funzionalità che dovrebbero essere riservate, si
controlla l’efficacia dei meccanismi di sicurezza del sistema
 Molto critico nel caso di applicazioni web
 Si presta all’utilizzo di tool automatici
 Per la scelta degli strumenti automatici da adoperare è necessario identificare le
tecnologie utilizzate e scegliere i tool più adatti al contesto applicativo;
 Ci sono anche aspetti che si allontanano dalle considerazioni puramente
tecniche come la disponibilità o meno del codice sorgente, l'assoluta necessità
di testare il software sull'ambiente finale di deploy, di effettuare la revisione in
diverse fasi del processo produttivo dell'applicativo stesso e così via.
 Le considerazioni appena fatte sono uno dei principali motivi per cui spesso non
risulta possibile utilizzare un singolo prodotto per evidenziare tutte le tipologie
di problematiche presenti in un software online.
7
Usability test
 Sotto la definizione di usability (usabilità) possiamo identificare
differenti aspetti:
– Efficacia: gli utenti riescono a completare i loro trask con il sistema sotto
test?
– Efficienza: con che facilità o problemi gli utenti riescono a completare i
loro task?
– Soddisfazione: che cosa pensano gli utenti quando utilizzano il sistema?
– Facilità di comprensione
– Facilità di apprendimento all’uso
– Attratività
– Robustezza: permette di fare errori e di restare in uno stato consistente?
Scopo del test di usability è cercare di verificare tutti questi aspetti
Rischia di essere soggettivo, ma il Word Wide Web Consortium ha creato
delle linee guida per l’usability
8
Performance, stress, load test



Performance test. È un controllo mirato a valutare l’efficienza di un sistema soprattutto
rispetto ai tempi di elaborazione e ai tempi di risposta. È un tipo di controllo critico per
quelle categorie di prodotti, come ad esempio i sistemi in tempo reale, per le quali ai
requisiti funzionali si aggiungono rigorosi vincoli temporali. Il sistema viene testato a
diversi livelli di carico
Volume test (o load test, test di carico). Durante questo tipo di controllo il sistema è
sottoposto al carico di lavoro massimo previsto dai requisiti e le sue funzionalità sono
controllate in queste condizioni. Lo scopo è sia individuare malfunzionamenti che non si
presentano in condizioni normali, quali difetti nella gestione della memoria, buffer
overflows, etc., sia garantire un’efficienza base anche in condizioni di massimo carico. Le
tecniche e gli strumenti del volume test sono di fatto usato anche per il performance
test: vengono fissati alcuni livelli di carico, e su questi sono valutate le prestazioni del
sistema. Sicuramente, però, i due tipi di test hanno scopi molto differenti, da un lato
valutare le prestazioni a vari livelli di carico, non limite, dall’altro valutare il
comportamento del sistema sui valori limite.
Stress test. Il sistema è sottoposto a carichi di lavoro superiori a quelli previsti dai
requisiti o è portato in condizioni operative eccezionali – in genere sottraendogli risorse
di memoria e di calcolo. Non è da confondere con il volume test da cui differisce per
l’esplicito superamento dei limiti operativi previsti dai requisiti. Lo scopo è quello di
controllare la capacità di “recovery” (recupero) del sistema dopo un fallimento.
9
Una metodologia di Performance Test
 Precondizioni:
 Test funzionali superati
 Ambiente di test adeguato in relazione a quello di produzione
 Step:
1.
2.
3.
4.
5.
6.
7.
Stabilire l’obiettivo del test
Identificare la strategia di test
Identificare le metriche da rilevare e configurare gli strumenti per acquisire dati
Progettare e implementare il workload(*) da applicare
Eseguire il test e produrre report
Interpretare i report per identificare azioni di performance tuning
Eseguire azioni di performance tuning e ritornare al pto 5 fino a che i risultati
non sono soddisfacenti
Workload(*) = profilo di carico F(n utenti, transazioni effettuate, tempo
di esecuzione del test)
10
10
Obiettivi tipici del performance Test
 Identificare il massimo carico sostenibile
 Identificare la presenza di colli di bottiglia
 Identificare eventuali difetti legati all’accesso concorrente di utenti
(gestione errata della transazionalità, ….)
 Verificare la stabilità complessiva dell’applicazione rispetto ad un carico
continuo e prolungato (es: presenza di memory leak)
11
11
Cuncurrent Load & Active Users
Libreria
Concurrent Load (o Users): Tutti gli utenti
presenti in un dato istante nella libreria (11)
Active Users: Tutti gli utenti che stanno
richiedendo un servizio (6)
Libreria online
Concurrent Load (o Users): Tutti gli utenti
presenti in un dato istante sul sito (11)
Active Users: Tutti gli utenti che stanno
richiedendo un servizio (6)
12
12
Peak Load
Peak Load: il numero massimo di utenti
concorrenti nel periodo di riferimento
(nell’esempio della libreria il peakload è di
50 utenti dalle 16 alle 17)
13
13
Throughput
Throughput: il numero di utenti serviti rispetto
all’unità di tempo
Throughput: il numero di utenti serviti rispetto
all’unità di tempo
Throughput Curve: mostra come varia il
throughput rispetto al variare del Cuncurrent
Load
14
14
Web Throughput Curve
All’umentare del carico la
la pendenza diminuisce fino
ad arrivare ad un upperbound ( punto di
saturazione. )
Si raggiunge un bottleneck
(collo di bottiglia) su qualche
risorsa (es. CPU=100% di
utilizzo). E’ equivalente al
numero massimo di
commessi nella libreria.
Nella zona di “carico leggero” le
richieste non sperimentano
attese nell’ottenimento di
risorse (cpu, memoria, ..).
La crescita è lineare
All’aumentare del carico il throughput
rimane costante (il response time
aumenta)
Throughput Curve: mostra come
varia il throughput rispetto al
Cuncurrent Load
Qualche risorsa arriva al
limite di gestione delle
richieste. (es: newtork
adapter). Il throughput
diminuisce
15
15
Response Time
Libreria
Response Time: Il tempo di attesa in coda + il
tempo di servizio
Libreria online
Response Time: è il tempo che va da quando
un utente attiva una richiesta a quando
riceve la risposta
16
16
Response Time Graph
Dopo il raggiungimento del punto
di saturazione del throughput la
crescita del tempo di risposta è
lineare
Dopo la buckle zone la
crescita del tempo
di risposta non è lineare
Fino al raggiungimento del punto di s
aturazione del throughput (es: 5 req/sec)
il tempo di risposta è costante
17
17
Throughput & Response Time Graph
18
18
ThinkingTime
Thinking Time: è il tempo che intercorre tra una risposta e la richiesta
successiva. E’utilizzato dall’utente per leggere,interpretare il risultato di
una risposta (ed altro … break, pranzo, …)
19
19
Steady State
Steady State: carico
concorrente costante (anche
per lunghi periodi)
Ramp-Up
Ramp-Down
20
20
Optimization
 Ottimizzazione





Eliminare codice inutile
Eliminare memory leak
Identificazione e rimozione dei bottleneck (attesa di risorse indisponibili perchè occupate
a servire altre richieste).
Ottimizzazione degli algoritmi (ottimizzare la complessità computazionale)
Performance Tuning del codice. Ad esempio in java




Tuning Java (es: Usare StringBuffer invece di String per la manipolazione di stringhe)
Tuning Servlet (es: evitare il single thread model, evitare System.out.println,...)
Tuning EJB (es usare Local Interfaces invece di Remote Interface)
Performance Tuning delle piattaforme (JVM, Application Server, Web Server, Database,…)
 Scalare (aggiungere risorse per aumentare le performance)

Verticale


Aumento delle risorse di calcolo e di memoria su un singolo server
Orizzontale

Clustering
21
21
Clustering
Esegue il dispatch delle
richieste su server A e
su server B secondo
politiche definite
(es:50%/50%).
Il clustering completo (tutte le risorse ridondate) consente una crescita lineare
del throughput. Se Server A = Server B, il throughput massimo sperimentato
nel punto indicato dalla freccia equivale = 2* throughput del Server A)
22
22
Performance Tool
 Performance Test
Registration&Playback
 Load Generation

 Data Monitoring & Collection Tool




CPU
Network
Memoria
JVM Heap
 Application Profiling

Es: JProfile
25
25
Performance Test Tool
script
I tool di performance test registrano il comportamento reale dell’utente
frapponendosi tra il client ed il sito web e creano così una prima versione
dello script che eseguito simulerà un singolo utente (Virtual User).
Successivamente sarà possibile simulare più utenti concorrenti eseguendo
Simultaneamente più Virtual User
26
26
Performance Test Tool
27
27
Performance Test Tool (Master/Slave)
Esecuzione degli script
(Virtual User) ed invio dei
dati
Orchestrazione degli script
(Virtual User) e raccolta dei
dati
28
28
Test Environment
29
29
Alcune strategie di Performance Test
 Stress Test
Workload Test (Ramp UP) >> Workload Esercizio
 Una sola funzionalità o sequenza limitata
 Goal: Valutare il comportamento in situazioni di picco, raggiungere
il punto di rottura

 Load Test
Workload Test (Ramp Up) ≈ Workload Esercizio
 Transazioni di Business
 Goal: Valutare il comportamento in situazioni di carico reale

 Stability Test
Workload Test < Workload di Esercizio
 Transazioni di Business o singole funzionalità
 Goal: Evidenziare problemi di stabilità con un carico ridotto per un
lungo periodo di utilizzo (24x7). E’ importante per evidenziare
fenomeni di “accumulo” che portano a saturazione (con
conseguente degrado delle performance e crash) di alcuni tipi di
risorse (memoria, pool di connessioni, ecc.)

30
30
Metriche
 Network-specific metrics. Forniscono informazioni sull’efficienza
della rete, includono routers, switches e gateways.
 System-related metrics. Forniscono informazioni sull’utilizzo delle
risorse del server come processore, memoria, disk I/O, and network
I/O.
 Platform-specific metrics. Forniscono informazioni sulla piattaforma
su cui viene effettuato il deploy della applicazione (es: jvm, tomcat,
glassfish, jboss)
 Application-specific metrics. Forniscono informazioni di performance
relative alla applicazione (contatori e time-stamp custom inseriti nel
codice, profiler probe…)
 Service-level metrics. Forniscono informazioni circa il throughput e
la il response time complessivo
 Business metrics. Forniscono informazioni sulle performance a livello
di business (es: il numero degli ordini in un dato timeframe) 31
31
Monitoring Tool (example)
Application Specific metrics
Profile (es: JProfiler)
System-related metrics
Windows System Monitor
(CPU, Network, Memoria)
Platform Specific metrics
JVM Heap Monitor (Heap
allocation)
32
32
Sintomi di bottleneck
 Underutilization.
Una o più risorse sature (memoria, database, rete, …)
 Serializzazione delle richieste a livello applicativo. (es: pochi thread listener)

33
33
Sintomi di bottleneck
 High CPU Utilization.

L’utilizzo di una delle CPU è prossimo al 100%
34
34
Workload modeling
 Modellare Thinking Time (es: dist. gaussiana)
 Modellare le sessioni
– Record & Playback di scenari
significativi
– Modelli stocastici
 Modellare la concorrenza
delle sessioni
– A rampa
– Simultanei
–…
35
35
Analisi dei risultati
Throughput VS #
users
Light
Load
Heavy
Load
Buckle
Zone
Light
Load
Response time VS #
users
Heavy
Load
Buckle
Zone
36
36
Apache JMeter
 Applicazione Java stand-alone utile per l'esecuzione di test di performance e per la
misura delle metriche di performance (service-level)
 Originariamente progettato per testare applicazioni Web (http) è stato esteso per:
– FTP
– RDBMS (JDBC)
– etc.
37
37
JMeter: concetti di base (1/3)
 TestPlan:
– consiste in uno o più ThreadGroups
 ThreadGroup:
– insieme di utenti simulati
 Thread
Ogni thread rappresenta un Virtual User. 1000
Thread rappresentrano 1000 VU concorrenti
38
38
JMeter: concetti di base (2/3)
 Timer:
– elemento che caratterizza il comportamento di un ThreadGroup
 Constant timer
 Gaussian random timer
 Uniform random timer
– Nota: senza un timer si simulerebbero degli “iper-utenti”
39
39
JMeter: concetti di base (3/3)
 Sampler
– Interagiscono con l’applicazione testata.
– Esistono diversi Sampler per diversi protocolli (JDBC, HTTP, FTP, ecc.)
– Per le applicazioni web si può utilizzare il Sampler “HTTP Request”
 Logic controller
– Determina l’ordine con cui i Sampler vengono eseguiti.
 Listener:
– L’informazione prodotta dai Sampler è consumata dai Listener
– Esistono listener per rappresentare i risultati in modo diverso: Graph, TreeView,...
40
40
JMeter: ciclo di vita di un TestPlan
 Definizione del TestPlan
 Avvio del Test:
–
–
–
–
JMeter compila gli elementi di test;
Viene istanziato un oggetto TestPlan;
Viene configurato il JMeterEngine;
Vengono avviati i vari threads.
 “Stampa” dei risultati del test:
– grafici
– xml
– ...
41
41
Un esempio di utilizzo…
 Obiettivo: testare una Web application.
 Strategia:
–
–
–
–
settare un ThreadGroup
aggiungere dei HTTP request sampler al ThreadGroup
settare un timer
settare alcuni listener
42
42
1: avvio di JMeter
TestPlan
Contiene TestPlan attivi
e pronti per essere eseguiti
WorkBench
Area di lavoro utile per costruire
e configurare tests.
43
43
2: aggiungere un Thread group
44
44
3: configurare un Thread group
45
45
4: aggiungere un sampler
46
46
5: aggiungere un timer
47
47
6: aggiungere un listener
48
48
7: aggiungere altri listener
 View result tree (il listener appena inserito).
– Utile in fase di creazione del test plan per verificare le risposte del server.
 Graph results e Splin visualizer.
– Mostrano i risultati della simulazione sotto forma di grafici.
 Simple data writer.
– Memorizza i dati della simulazione su un file XML
49
49
Dove eseguire JMeter?
 Sulla stessa macchina che esegue il server web?
– pro: non ci sono ritardi introdotti dalla rete
– contro: Jmeter entra in competizione per le risorse del server.
 Su una macchina remota?
– pro: Jmeter non influisce sulle prestazioni del server
– contro: possibili ritardi introdotti dal traffico del segmento di rete utilizzato
 Su più macchine remote?
– pro: si minimizza il problema dei colli di bottiglia di rete
– contro: configurazione e avvio un po' più laborioso
50
50
Dove eseguire JMeter?
51
51
Bibliografia
 Performance Analysis for Java(TM) Websites
– Stacy Joines , Ruth Willenborg, Ken Hygh
 JMeter User Manual
– http://jakarta.apache.org/jmeter/
52
52