1 Software testing Lezione 5 Non functional Testing Federica Spiga federica_spiga@yahoo.it A.A. 2010-2011 Autori: F.Rabini/F.Spiga
2 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)
3 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
4 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
5 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
6 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
7 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.
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
10 Una metodologia di Performance Test Precondizioni: Test funzionali superati Ambiente di test adeguato in relazione a quello di produzione Step: 1. Stabilire l obiettivo del test 2. Identificare la strategia di test 3. Identificare le metriche da rilevare e configurare gli strumenti per acquisire dati 4. Progettare e implementare il workload(*) da applicare 5. Eseguire il test e produrre report 6. Interpretare i report per identificare azioni di performance tuning 7. 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
11 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
12 Cuncurrent Load & Active Users Libreria Libreria online 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) 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
13 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
14 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
15 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. All aumentare del carico il throughput rimane costante (il response time aumenta) Nella zona di carico leggero le richieste non sperimentano attese nell ottenimento di risorse (cpu, memoria,..). La crescita è lineare 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
16 Response Time Libreria Libreria online Response Time: Il tempo di attesa in coda + il tempo di servizio Response Time: è il tempo che va da quando un utente attiva una richiesta a quando riceve la risposta 16
17 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
18 Throughput & Response Time Graph 18
19 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
20 Steady State Steady State: carico concorrente costante (anche per lunghi periodi) Ramp-Up Ramp-Down 20
21 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
22 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
25 Performance Tool Performance Test Registration&Playback Load Generation Data Monitoring & Collection Tool CPU Network Memoria JVM Heap Application Profiling Es: JProfile 25
26 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
27 Performance Test Tool 27
28 Performance Test Tool (Master/Slave) Esecuzione degli script (Virtual User) ed invio dei dati Orchestrazione degli script (Virtual User) e raccolta dei dati 28
29 Test Environment 29
30 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
31 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
32 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
33 Sintomi di bottleneck Underutilization. Una o più risorse sature (memoria, database, rete, ) Serializzazione delle richieste a livello applicativo. (es: pochi thread listener) 33
34 Sintomi di bottleneck High CPU Utilization. L utilizzo di una delle CPU è prossimo al 100% 34
35 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
36 Analisi dei risultati Light Load Heavy Load Throughput VS # users Buckle Zone Light Load Response time VS # users Heavy Load Buckle Zone 36
37 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
38 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
39 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
40 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
41 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
42 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
43 1: avvio di JMeter TestPlan Contiene TestPlan attivi e pronti per essere eseguiti WorkBench Area di lavoro utile per costruire e configurare tests. 43
44 2: aggiungere un Thread group 44
45 3: configurare un Thread group 45
46 4: aggiungere un sampler 46
47 5: aggiungere un timer 47
48 6: aggiungere un listener 48
49 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
50 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
51 Dove eseguire JMeter? 51
52 Bibliografia Performance Analysis for Java(TM) Websites Stacy Joines, Ruth Willenborg, Ken Hygh JMeter User Manual http://jakarta.apache.org/jmeter/ 52