Software testing
Lezione 7 – Test Automation
Federica Spiga
[email protected]
A.A. 2010-2011
Autori: F.Spiga
1
"La prima regola di ogni tecnologia è che l'automazione
applicata ad un'operazione efficiente ne aumenterà
l'efficienza.
La seconda è che l'automazione applicata ad
un'operazione inefficiente ne aumenterà l'inefficienza".
Bill Gates
2
Test automation
 È l’insieme delle tecniche e delle tecnologie che consentono di automatizzare
(anche parzialmente) alcune attività del Processo di Testing.
 Alcune aree di intervento:
– Generazione dei Casi di Test;
– Preparazione ed Esecuzione del Test;
– Valutazione dell’efficacia di Test Suite.
 Potenzialmente utile a ridurre i costi
– esempio: capture and replay tools riduce i costi dovuti alla reesecuzione delle test suite
 Utile ad aumentare la produttività del team
3
Approaching Automation
 Negli approcci al testing fin qui analizzati, si è sempre considerato
il task di Test Case Design come un task svolto manualmente dal
tester;
 A causa dell’elevato numero di casi di test necessari per un
testing efficace, l’operazione di progettazione manuale dei casi di
test può essere molto onerosa.
 Tecniche per la generazione automatica dei casi di test possono
ridurre drasticamente i costi e i tempi legati alla fase di test
design;
 Può però essere necessaria una fase di valutazione dell’efficacia
dei casi di test e una fase di riduzione dei casi di test ridondanti.
4
Vantaggi dell’automazione
Efficienza
• Ridurre I costi del testing
• Ridurre il tempo speso nella fase di test
• Automatizzare smoke test e regressione test
• Aumentare il coverage dei test
5
Svantaggi dell’automazione
Non ci si deve aspettare che la produttività
aumenti immediatamente!!
– L’approccio all’automazione è un approccio strategico
– Nella realtà spesso I vantaggi per l’organizzazione dell’automation si
scoprono nel medio/lungo periodo
– Per creare un test automatico ci vuole da 3 a 10 volte l’effort rispetto ad un
test manuale
– E’ necessario spendere un maggiore effort per la gestione e la
manutenzione dei test automatici
6
I costi dell’automazione
 I costi dell’automazione possono variare enormemente.
 Alcuni tool possono essere molto semplici da sviluppare così che
sia giustificabile automatizzare anche se I benefici possono essere
modesti
 L’acquisto di alcuni tool di test automation potrebbe troppo
oneroso per il budget di un progetto solo
7
I costi possono dipendere dallo scope
 Spesso sviluppare un tool general-purpose tool è solo
marginalmente più difficile da realizzare che produrre un tool
specializzato per un progetto
 Investimenti per tool general purpose (svilupparli o acquistarli)
potrebbero essere ammortizzati tra più progetti
 In altri casi, per grossi progetti, potrebbe essere conveniente
sviluppare dei tool specifici
8
Focalizzarsi dove l’automazione è più conveniente
 Task semplici e ripetitivi sono quelli più convenienti e economici
da automatizzare
– Un uomo tende ad essere lento e fare errori nei task ripetitivi
 Utile quindi nel:
– Regression testing
– Smoke test
– Performance e load test
 Attività che richiedono creatività e attitudine al problem solving
restano fuori dal dominio dell’automazione
9
Generazione dei test automatici – User Session
 Tecnica per la generazione automatica di casi di test per il testing black box
partendo dall’analisi delle sessioni utente (User Session), ovvero delle
sequenze dei valori di input immessi e di output ottenuti in utilizzi reali del
software.
 In pratica, vengono installati strumenti che siano in grado di mantenere un log
di tutte le interazioni che avvengono tra gli utenti dell’applicazione da testare
e l’applicazione stessa (fase di Capture);
 A partire da tali dati vengono formalizzati casi di test che replichino le
interazioni “catturate” (fase di Replay)
– In questo modo è possibile ottenere casi di test che siano rappresentativi dei reali utilizzi
dell’applicazione da parte dei suoi utenti.
10
Test Mutazionale
 Il Testing Mutazionale è una tecnica per la generazione automatica di casi di
test.
 A partire da un sottoinsieme di casi di test, si applicano alcuni operatori di
mutazione che vadano a modificare/incrociare i dati dei test case esistenti, in
modo da ottenere nuovi test case.
 Es. Si cambia il segno degli input, si raddoppiano i valori di input, si combinano
sequenze di input in nuove sequenze, etc…
 Con tale tecnica si possono ottenere Test Suites
–
–
–
–
più piccole (meno test cases)
con maggiore copertura
con uno sforzo minore
rispetto a quelle ottenute semplicemente collezionando sessioni utente.
 Bisogna però eliminare tutti i test cases che risultano non applicabili. Questa
tecnica è spesso utilizzata per il testing di interfacce o di protocolli.
11
Test Tools
Lezione 8 – Test Tools
Federica Spiga
[email protected]
A.A. 2010-2011
Autori: F.Spiga/A.Di Toro
12
Test Management
 Un tool per la gestione dei test è Test Link
– http://www.teamst.org/
 Facilità di utilizzo / personalizzazione;
 Raggruppamento dei progetti per aree applicative;
 Creazione/Import/Export dei progetti;
 Gestione requisiti funzionali, test, script, piani di esecuzione e report;
 Gestione delle utenze e assegnazioni dei ruoli all’interno dei test plan;
 Salvataggio e riutilizzo delle sessioni di test;
 Controllo sullo stato di avanzamento dei test in corso;
 Gestione dei risultati dei test eseguiti;
 Metriche per la valutazione dello stato attuale del progetto di test nei confronti degli
obiettivi di qualità prefissati;
 Analisi del rischio in base alla priorità delle funzionalità / test;
13
Test Management
 Un tool per la gestione dei test è Test Link
– http://www.teamst.org/
14
Test Management
15
TestLink – Visione Generale
All’interno del singolo progetto, vengono associati i vari oggetti necessari a monitorare e
a gestire tutto il processo di test.
Principali Funzionalità:
 Requirement Management;
 Test Execution;
 Test Plan Management;
 Metrics Dashboard;
 Test Case Management;c
 Documentation;
16
TestLink – Amministrazione
TestLink permette di gestire le utenze e i ruoli e di assegnare determinati ruoli
per Progetto e per Test Plan.
17
TestLink – Requisiti Funzionali
Per i requisiti vengono messe a disposizione le seguenti funzionalità:
 Creazione/Modifica in base ad una struttura ad albero;
 Creazione della struttura dei Test Case a partire dai requisiti;
 Gestione e Analisi copertura requisiti funzionali / test;
 Import / Export nei formati CVS o XML;
 Stampa del documento dei requisiti.
18
TestLink – Test Plan
Per la gestione dei Test Plan vengono fornite le
funzionalità di controllo a diversi livelli:
 Test Plan;
 Build Management;
 Milestone per Test Plan.
19
TestLink – Test Execution
Creazione e gestione dei Test
Case associabili ai Test Plan per
la definizione delle sessioni di
test.
Possibilità di gestione e controllo delle sessioni di esecuzioni dei test.
20
Test Link - Gestione Reportistica
Possibilità di Export nei formati Excel, Word, HTML, OpenOffice
21
Test Automation – Unit Test
 Un tool per i test automation degli Unit test è Junit
– http://www.junit.org/
 E’un framework che permette la scrittura di test in maniera ripetibile.
 Fu sviluppato originariamente da Erich Gamma and Kent Beck, nell’ambito
degli strumenti a supporto dell’eXtreme Programming.
Modello delle classi
del framework JUnit
22
Junit – Le componenti
Test: É l’interfaccia che tutti I tipi di classi di test devono implementare. Attualmente il
framework JUnit contiene solo due classi di test, TestCase e TestSuite.
TestCase: É la classe fondamentale che deve essere estesa per scrivere nuovi test. Un
TestCase concreto (cioè una classe che estende TestCase) ha sia metodi che
implementano i veri e propri test, sia i metodi opzionali di setUp (che settano le precondizioni necessarie prima dell’esecuzione di un Test) e tearDown (che eseguono le
operazioni necessarie ad azzerare gli effetti prodotti dal test).
TestSuite: classe che implementa l’interfaccia di Test. Il suo scopo è di raggruppare
Tests di TestCases, o TestSuites.
Assert: superclasse di TestCase che fornisce tutti I metodi assert disponibili nel
framework per verificare l’esito del test.
TestFailure: classe che incapsula l’errore o la failure che si verificano durante
l’esecuzione del test. Essa tiene traccia del Test fallito e dell’eccezione responsabile
dell’errore o della failure.
TestResult: contiene tutti i risultati dell’esecuzione dei test.
TestListener: interfaccia che viene implementata da ogni classe che vuole tenere traccia
del progresso dell’esecuzione di un test. Dichiara I metodi per notificare l’inizio e la fine
di ciascun test, e l’occorrenza di errori e failures.
23
Junit – Plugin
 Alcuni ambienti di sviluppo software mettono a disposizione dei Plug-ins che
semplificano il processo di scrittura ed esecuzione dei test JUnit su classi Java.
 Ad esempio, Eclipse é dotato di un plug-in, di pubblico dominio, che supporta
tutte le operazioni legate al testing di unità con JUnit. In particolare, esso
fornisce dei wizard per:
– Creare classi contenenti test cases;
– Automatizzare l’esecuzione di tutti i test cases;
– Mostrare i risultati dell’esecuzione dei casi di test;
– Organizzare i test cases in test suites.
24
Test Automation – Functional Test
 Un tool per i test automation è Selenium
– http://seleniumhq.org/
 Compatibilità con i browser più diffusi (Firefox, IE, Safari);
 Gestione di Test Suite e Test Case;
 Robustezza del linguaggio di script;
 Personalizzazione degli script registrati;
 Gestione del repository dei test script;
 Pubblicazione delle API di interfaccia;
 Gestione dei risultati dei test eseguiti;
 Compatibilità con più linguaggi di programmazione;
 Funzionalità di record & playback;
 Buona documentazione
25
Automation Test – Selenium Suite Tool
Cosa comprende la Suite?
 Possibilità di registrare i test in Firefox, con
Selnium IDE;
 Possibilità di eseguire i test nei browser più
comuni, con Selenium RC;
 Personalizzazione degli script di test con
l’ausilio di molti linguaggi di programmazione
(C#, Java, Perl, PHP, Python, Ruby);
 Distribuzione dei test su server multipli,
Selenium GRID, risparmiando tempo con la
pianificazione in parallelo dei test.
26
Selenium IDE – Visione Generale
Add In di Firefox, permette la registrazione e l’esecuzione degli script, con
la possibilità di personalizzazione.
27
Selenium IDE – Personalizzazione Script
Tra le Options è possibile selezionare un formato
per poter personalizzare lo script. Ad esempio
selezionando “Java – Selenium RC”, lo script
registrato viene convertito in linguaggio Java, che
può essere importato e modificato in un IDE JAVA
per poi essere eseguito da Selenium Remote
Control.
28
Selenium – Test Runner
Gestione dell’esecuzione delle Suite di Test con la possibilità di avere un riscontro sui
risultati.
29
Selenium – Result Esecution Test
Visualizzazione runtime
dell’esecuzione dei test, con
un resoconto dell’esecuzione
rispetto al numero di test
eseguiti e ai comandi
sottomessi.
Viene messa a disposizione
una visualizzazione dei log di
esecuzione per il debug.
30
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.
31
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
32
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”
33
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,...
34
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
– ...
35
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
36
1: avvio di JMeter
TestPlan
Contiene TestPlan attivi
e pronti per essere eseguiti
WorkBench
Area di lavoro utile per costruire
e configurare tests.
37
2: aggiungere un Thread group
38
38
3: configurare un Thread group
39
39
4: aggiungere un sampler
40
40
5: aggiungere un timer
41
6: aggiungere un listener
42
42
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
43
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
44
Dove eseguire JMeter?
45
Bug tracking
 Per la gestione del processo di bug tracking si possono utilizzare
– Bugzilla http://www.bugzilla.org/
– Mantis http://www.mantisbt.org/
46
Bugzilla
 Bugzilla è un'applicazione per il monitoraggio e la gestione dei
bug.
 Bugzilla è un bugtracker (programma per tenere traccia di errori
di programmazione) general purpose (cioè non dedicato ad un
solo possibile utilizzo) inizialmente sviluppato e usato dalla
squadra che ha prodotto Mozilla.
 Rilasciato come software open source da Netscape
Communications nel 1998, Bugzilla è stato adottato da varie
organizzazioni per utilizzarlo come strumento per rintracciare
errori (bugs) per progetti di prodotti sia open source sia
proprietari
47
Bugzilla
 Principali funzionalità:
–
–
–
–
–
–
Schema di sicurezza granulare integrato per prodotto
Dipendenze tra i bug e grafici di dipendenza
Capacità avanzate di report
Un back-end RDBMS stabile e robusto
Configurabilità estesa
Un protocollo di risoluzione dei bug facilmente comprensibile e ampiamente
testato
– Interfacce di programmazione via e-mail, XML, console, e HTTP
– Possibilità di integrazione con software di CMS, inclusi Perforce e CVS (attraverso
l'interfaccia e-mail di Bugzilla e script di checkin/checkout)
48