Sei sulla pagina 1di 21

Tesi di Laurea

Tecniche di GUI crawling per il testing automatico di applicazioni Android


Anno accademico: 2010/2011

relatore Ch.ma Prof.ssa Anna Rita Fasolino correlatore Ing. Domenico Amaltano candidato Salvatore De Carmine Matr. 41/2376

Scopo del lavoro di tesi

Contesto:
Processi di sviluppo e testing di applicazioni Android

Problema arontato:
Denizione di tecniche e di strumenti per il testing automatico di applicazioni Android

Contributo personale:
Sviluppo di un tool di crawling per il GUI testing di sistemi Android

Il sistema Android
Android uno stack software che comprende un sistema operativo basato su Linux e strumenti per utente e sviluppatore
installato, di solito, su dispositivi mobili equipaggiati con vari sensori e dispositivi di comunicazione ma risorse hardware (RAM, CPU, ...) ridotte

Android domina il mercato dei dispositivi mobili, avendo raggiunto il 52,5% delle vendite nel terzo quadrimestre del 2011 Applicazioni sviluppabili in linguaggio Java su qualsiasi sistema tradizionale e distribuibili tramite lAndroid Market
dieci miliardi di download raggiunti entro la ne del 2011

Applicazioni Android

Le applicazioni vengono realizzate componendo i quattro elementi fondamentali dellapplication framework: Activity, Broadcast Receiver, Content Provider e Service.
Le componenti di unapplicazione si scambiano messaggi chiamati Intent.

Il software per Android implementa un modello multi-threaded in cui:


il main thread gestisce la GUI come risorsa privata; i worker thread eseguono compiti esosi in termini di tempo o risorse, cos che la GUI resti pronta a rispondere allutente; se il main thread resta in stallo per un certo lasso di tempo, appare il dialog Application Not Responding.

Le Activity
Le activity hanno la responsabilit di gestire linterfaccia graca.
Ogni activity presenta allutente una schermata della GUI e pu richiamarne altre. Lutente interagisce con unactivity per volta, lactivity corrente. Ogni activity composta di oggetti, detti widget, con cui lutente interagisce scatenando eventi e fornendo input.

Lo sviluppatore pu progettare la GUI di unactivity tramite strumenti WYSIWYG ed esportarla in formato XML.
Ogni widget diventa una risorsa dotata di un ID numerico. Da codice, possibile accedere ai widget usando il loro ID. Il collegamento alle altre activity avviene gestendo gli eventi utente.

Gli eventi
Le applicazioni Android sono event-driven. Tre tipi di eventi:
1. eventi utente: interazioni (click, pinch, tap...) dellutente su widget (button, menu item...) della GUI 2. eventi di sistema: telefonata in arrivo, batteria quasi scarica, ... 3. eventi software: risposte a richieste dellapplicazione alla rete, al database, ai sensori...

Il passaggio da unactivity allaltra di solito innescato dagli eventi utente.


Lo sviluppatore, in risposta ad un evento scatenato sulla GUI di una certa activity, ne visualizza unaltra tramite invio di un intent.

Per la loro natura asincrona, gli eventi software e di sistema, se non gestiti, possono causare comportamenti imprevisti.

Testing event-driven
Tecniche di testing per sistemi event-driven si dividono in: tecniche basate su modello: lapplicazione viene esercitata in base ad un modello pre-esistente, che fornisce anche i criteri per valutare la correttezza dei risultati; tecniche random: lapplicazione viene esercitata con interazioni casuali alla ricerca di malfunzionamenti evidenti (crash, stallo, ...); tecniche basate su crawler: la GUI dellapplicazione viene esercitata in assenza di modello, con una strategia che punta ad esplorarne lintera gamma di activity ed eventi.
elaborando loutput di un crawler si pu ricostruire un modello dellapplicazione da usare in tecniche model-based.

Per tenere in conto le peculiarit della piattaforma Android, risulta necessario sviluppare tecniche ad hoc.

La tecnica di crawling proposta


Tecnica crawler based: un GUI crawler simula eventi utente sullapplicazione e ne registra le transizioni di stato. Lo stato descritto in termini di propriet della GUI:
lactivity corrente e le sue propriet; widget che la compongono e le loro propriet; solo un sottinsieme di queste informazioni sar ritenuto signicativo.

Lapplicazione modellata da un GUI Tree:


gli stati sono i nodi dellalbero; le transizioni (descritte dalle sequenze di input ed eventi che le inducono) sono gli archi; criteri di esplorazione ed equivalenza per gli stati limitano lesplosione del loro numero.

Un esempio di GUI Tree (1/2)

Calculate

Metric System

US Customary

Calculate

Imperial (UK)

Calculate

Un esempio di GUI Tree (2/2)

MAIN

MAIN

Input (Metric)

Input (USA)

Input (UK)

Input (Metric)

Input (USA)

Input (UK)

Output (Metric)

Output (USA)

Output (UK)

Output

GUI Tree

FSM

Aspetti strategici del crawler


la strategia di esplorazione (in profondit, in ampiezza, ...); le condizioni che determinano lequivalenza di due stati e di due widget; le condizioni di terminazione della sessione di crawling (tempo, numero di task eseguiti); le condizioni di esplorazione di uno stato (criterio di equivalenza, profondit) il tipo di eventi da scatenare; per ogni evento, linsieme dei widget su cui sar scatenato:
intensionale (propriet da vericare, come il tipo del widget) estensionale (elenco puntuale dei widget da esercitare) o una combinazione dei due;

la denizione degli input utente da generare;

Algoritmo di crawling
Analisi GUI stato corrente

Aggiungi eventi a task list

[esplora] [else] [lista vuota]

[else]
Estrazione task da task list

Esecuzione task

Descrizione stato della GUI

Valuta equivalenza stato

Gli output del crawler


Il crawler pu generare i seguenti artefatti: 1. una sequenza di tracce di esecuzione; 2. una test suite di test case JUnit automaticamente eseguibili; 3. un log che documenta i crash osservati durante il crawling;
un crash uninterruzione dellesecuzione dellapplicazione sotto test dovuta ad eccezioni non gestite;

4. un report di copertura del codice eseguito; 5. una serie di modelli dellapplicazione:


GUI Tree, Event Flow Graph, Event Flow Tree

6. statistiche sulla sessione di crawling


tracce eseguite, eventi scatenati, stati incontrati, widget osservati, tempo impiegato...

Il tool realizzato

Application Task Scheduler

Storage

Task List Robot

Automation : Instrumentation

Strategy Next Task Add Tasks Abstractor Extractor Persistence States List: Set<Activity State>

Comparator Save to disk Abstract

Engine Current Task: Task Current State: ActivityState State

Plan: List<Task>

Session: List<Trace>

Task Planner

Planned Tasks

Esperimenti
Scopo degli esperimenti:
valutare lecacia del crawler ai ni del GUI testing.

Misure di ecacia considerate:


1. difetti non documentati dellapplicazione scoperti dal crawler; 2. copertura del codice dellapplicazione.

Modalit operative degli esperimenti:


esecuzione del crawling su versioni successive dellapplicazione, usando diverse impostazioni per la tecnica di crawling.

Materiale sperimentale:
applicazioni Android open-source in fase di sviluppo, con strumenti di bug tracking.

Unapplicazione analizzata
Wordpress for Android

Wordpress for Android permette: la gestione dei propri blog, ed in particolare:


inserimento, modica e cancellazione degli elementi principali di un blog: post, pagine, tag e categorie; moderazione dei commenti; caricamento di immagini e foto tramite lutilizzo della videocamera; specica automatica della localit geograca (via GPS); salvataggio di bozze in database;

la visita dei blog preferiti. Si tratta di unapplicazione complessa: 10178 righe di codice; 1493 metodi; 331 classi.

Risultati del crawling (1/3)


Copertura del codice
Package
org.xmlrpc.android

Classi 50% (7/14)

Metodi 19% (19/98) 26% (12/46) 50% (12/24) 41% (70/170) 54% (445/827) 37% (120/328) 45% (678/1493)

Blocchi 12% (1051/8778) 14% (121/881) 39% (141/364) 41% (1150/2829) 48% (14550/30393) 61% (10369/17034) 45% (27382/60279)

Linee 24% (241,8/1012) 15% (29/190) 48% (36/75) 36% (234,2/655) 46% (2787,4/6094) 32% (698/2152) 40% (4026,3/10178)

com.commonsware. cwac.cache com.commonsware. cwac.thumbnail org.wordpress. android.models org.wordpress.android

36% (4/11) 71% (5/7) 80% (4/5) 58% (136/233)

org.wordpress. android.util

54% (33/61) 57% (189/331)

Overall Summary

Risultati del crawling (2/3)


Statistiche e crash individuati

Le sessioni di crawling sono composte da un numero di task compreso fra 150 e 300. stato coperto il 40% circa del codice.
Una parte non trascurabile del codice non coperta risultata non collegata al resto del codice.

Sono stati rilevati e segnalati allo sviluppatore 10 crash dovuti ad eccezioni diverse:
String Index Out of Bounds Exception Cursor Index Out Of Bounds Exception (x2) Bad Token Exception Activity Not Found Exception Null Pointer Exception (x2) Called From Wrong Thread Exception Runtime Exception: unable to start Activity (x2)

Risultati del crawling (3/3)


Bug Report

Altre applicazioni testate


Copertura del codice

Applicazione Mileage v2.2.5 Wordpress 2


alpHa

Classi 62% (74/119) 38% (126/332) 82% (469/572)

Metodi 52% (298/578) 32% (477/1506) 60% (1257/2087) 59% (443/754) 77% (184/238)

Blocchi 52% (7556/14463) 37% (21913/59100) 76% (45286/59975) 54% (11201/20701) 75% (3205/4286)

Linee 51% (1642,2/3212) 32% (3621,2/11492) 64% (5907/9231) 54% (2343,3/4315) 75% (754,5/1009)

Api Demos

Disk Usage v3.0 Tippy Tipper v1.2

64% (94/148) 78% (42/54)

Conclusioni
Abbiamo realizzato uno strumento per il GUI crawling di applicazioni Android che svolge funzioni di:
1. Crash testing; 2. GUI ripping.

Abbiamo dimostrato lecacia del crawler nel GUI testing su un insieme di applicazioni reali. Sviluppi futuri:
Estendere le funzionalit del crawler (supporto di pi tipi di eventi e widget, nuovi criteri, ...) Eseguire una sperimentazioni pi ampia per valutare lecacia della tecnica proposta al variare di impostazioni e caratteristiche dellapplicazione sotto test