Techniques and Tools for Mobile Testing Automation

Techniques and Tools for
Mobile Testing Automation
Porfirio Tramontana
Assistant Professor at
Department of Electrical Engineering and
Information Technology
University of Naples Federico II, Italy
ptramont@unina.it

 A mobile software application or mobile app is a
software application designed to run on a mobile device
such as a smartphone or tablet computer.
 Mobile apps often stand in contrast to desktop
applications that run on desktop computers, and with
web applications which run in mobile web browsers
rather than directly on the mobile device.
 From Wikipedia
2
Mobile applications
Porfirio Tramontana – Tarot 2017 - Napoli- 30/06/2017

 Apps are often developed with a very rapid lifecycle to reach the
market earlier possible
 Apps are developed for environments having a rapid (e.g. iPhone)
or very rapid evolution (e.g. Android), both in terms of hardware
features (e.g. sensors, …), software (libraries) and infrastructures
(virtual machine, development environment)
 Apps failures discovered by real users may reduce the reputation of
the app causing a dramatic lose of users
Testing is a very critical activity in the
lifecycle of an app!
Porfirio Tramontana – Tarot 2017 - Napoli- 30/06/2017 3
Are Mobile Applications different from
Desktop or Web Applications?

 An app has to be tested on thousands of different
devices, with different characteristics
 Testing on emulators can be mixed to testing on real devices
 Apps are object of continuous maintenance intervention
 Corrective, at each discovery of a failure
 Adaptive, for each new hardware / software combination
 Evolutive, for each new feature
There are many repetitive testing activities
Testing automation is able to dramatically reduce testing
costs and to reduce the occurrence of failures
4
Some issues of mobile app testing

 Main benefits expected from testing automation:
 Automatic generation of test cases
 Automatic execution of test cases
 Automatic evaluation of test results
 Automation can be applied to the evaluation of
each quality aspect of mobile apps
 In this talk I will restrict the focus to functional
testing automation of Android applications
5
Testing Automation

 Apps can be the client side of client-server architectures
 Users directly operate on them
 Apps run on Android devices in the context of a virtual machine
(e.g. Dalvik or ART)
 Most of the tests can be executed on emulated devices
 The virtual machine may influence the behavior of the app
 Apps have a Graphical User Interface centered on Activity classes
 The widget model is somewhat similar to the one of traditional GUI
applications, with some restrictions
 Apps have specific restrictions to the communications between
components
 Similar to the limitations of the client side of Web applications running on a
browser
 Apps may communicate with sensors, system resources, web
resources, …
6
Peculiarities of Android apps

 The first tools supporting testing
automation have been directly provided by
Google into the first releases of the
Android framework
 InstrumentationTestCase library
 Monkey
7
Android test architecture

 A test package including Junit
test cases is able to control the
application under test by means
of Instrumentation classes able
to provide a reflective access to
the application components in
the context of the test case
 Testing tools such as
MonkeyRunner and Monkey are
able to directly inject events to
the execution environment
8
Android basic test architecture

 Test cases can be seen as alternative entry points of the
application
 Test cases can be executed in a completely automated
environment
 Test cases may emulate the behavior of users and the
external stimuli with a good level of fidelity
 Writing a test case is quite “simple”
 The scope of the test case is limited to the world of the
app under test, without the possibility to monitor its
relationships with the rest of the system
 The execution of test cases is not so fast
9
Junit based test cases

 Industry has provided:
 Libraries supporting test writing (e.g. Robotium, Espresso)
 Tools supporting automatic testing (e.g. Monkey, Robo, Fuzz)
 Tools supporting test generation (Robotium Recorder, Espresso
Test Recorder)
 Scientific community has provided:
 Testing techniques adapting the ones proposed in other
software domains (random exploration, model learning, model
based testing, …)
 Free tools for automatic test case generation and execution
(Android Ripper, Dynodroid, Sapienz, A3E, Swifthand)
10
Testing Automation Evolution in
Literature and Industry

 A strategy for the exploration of contributions in literature
11
Systematic Mapping of Functional
Testing of Mobile Application

 What testing activities are automated?
 What testing levels are addressed?
 What inputs are used by the proposed testing techniques to derive test artifacts?
 What kinds of techniques are proposed for test case generation?
 Is test case execution automatic or manual?
 What kinds of test oracles are considered?
 What kinds of test artifacts are generated?
 What are the characteristics of the proposed testing tools?
 Which mobile frameworks are the targets of the proposed techniques and tools?
 Are the proposed techniques and tools usable on emulators or real devices?
 What are the characteristics of the performed evaluation studies?
 What are the characteristics of the sets of applications objects of the evaluation
experiments?
 What are the characteristics of the performed comparative studies?
12
Some research questions

( ( ( ”mobile applications” OR ”Android applications” OR
apps OR ”Windows Phone applications” OR ”Symbian
applications” OR ”iOS applications”)
AND testing
AND ( technique OR approach OR method OR tool OR
framework )
AND ( automation OR automated OR automatic ) ) )
 Applied on Scopus, IEEE, ACM, Springer, ISI, ScienceDirect, Google Scholar
13
Query String

 119 relevant papers about techniques and
tools for mobile testing automation
14
Results

15
Testing Automation Evolution in
Literature and Industry
Monkey InstrumentationTestCase
Robotium
TestDroid
Firebase Test Lab
Android Ripper
Sapienz
Dynodroid
Espresso
A3E Swifthand

16
Contributions map

17
Support to automation

 User Session based
 Capture & Replay
 Model Based
 Active Learning
 Random
 Search Based
 Mutation based
18
Test case generation techniques

 Capture & Replay solutions allow the
automatic generation of executable test
cases reproducing real usages of the
application under test
 Robotium Recorder
 Espresso Test Recorder
 RERAN
 Lorenzo Gomez, Iulian Neamtiu, Tanzirul Azim, and Todd Millstein. 2013. RERAN: timing- and touch-sensitive record
and replay for Android. In Proceedings of the 2013 International Conference on Software Engineering (ICSE '13)
19
Capture And Replay

 Android
Espresso
Test
Recorder
20
Android Espresso Test Recorder
https://developer.android.com/studio/test/espresso-test-recorder.html

 Points of strength:
 Test cases can be generated by testers without great
programming skills
 Limitations:
 Need for continuous adaptation of tools
 Need of continuous maintenance of the generated
tests due to the evolution of the application under
test and of the execution environment
 Replicability issues due to time constraints
 Only the interactions between the user with the
application under test can be captured
21
Points of strength and Limitations

 Model Based testing consists of the automatic
generation of test cases on the basis of
structural or behavioral models of the
application under test
 What models are able to describe a mobile
application?
 Event Flow Graphs
 GUI Trees
 Finite State Machines
 …
22
Model Based

 Each node is a
screenshot / activity
 Each edge is an event
executable on the app
 Each path is a sequence
of activities obtained by
the execution of a
sequence of events on
the app
23
GUI Tree
Problem: this model is potentially unlimited

 Each node is an event
executed on the app
 Each edge represent the
sequence between two
consecutive events
 Each path of length k is a test
case composed of a sequence
of k consecutive events
24
Event Flow Graph
Problems: this model is potentially unlimited
Not all cycles correspond to actually executable test cases
Amalfitano, D., Fasolino, A.R., Tramontana, P., Ta, B.D., Memon, A.M. MobiGUITAR: Automated Model-Based Testing of Mobile Apps
(2015) IEEE Software, 32 (5), art. no. 6786194, pp. 53-59.

 Nodes are activity states – Edges are events
 All the paths on the graph may be test cases
26
Finite State Machines
 Problems: how to distinguish between different states?
 How to recognize the obtained states?
 Not all the paths on the FSM are executable

 Often accurate design models allowing the automatic
generation of test cases are not available
 Or the effort needed to formalize them is considered too high
 Models can be automatically generated by dynamically
exploring the execution of the application under test
 Active Learning strategies allow :
 To perform a first testing of the application able to find crashes
or exceptions during the exploration itself
 To generate a test suite reproducing the performed explorations
 To generate a model that can be the base for the generation of
tests with model based techniques
27
Active Learning

 Inferred Model
 Which model is generated?
 Abstraction Strategy
 Which subset of information of the application under test is
taken into account?
 Extraction Criterion
 Which events are triggered?
 Scheduling Strategy
 In which order the events are triggered?
 Termination Criterion
 When the exploration is stopped?
28
Parameters of an Active Learning
technique

 In order to limit the exploration, we can hypothesize that a node
that have been already explored does not need further explorations
 How can we recognize if a node has been already explored?
 How can we recognize that an equivalent node has been already
explored?
 Two nodes are equivalent if they have the same values for all the
relevant properties
 Which properties of the node are considered relevant?
 The set of relevant properties influences the number of equivalent
nodes
 If no abstraction strategies are taken into account, then the
exploration continues indefinitely
 E.g. random strategies with no memory of already visited nodes
29
Abstraction Strategy

 Possible information providing an abstraction of a GUI
interface:
 The name of the instantiated activity class
 The number and type of the included widgets
 The values of the text fields
 The properties of the widgets
 More information generate larger models
 The size of the models may become too large to be completely
explored
30
Relevant Information

 If the bill amount is taken into
account, there are 10^15
possible states
 Values with 15 ciphers can be
entered
 If the bill amount is not taken
into account, these two GUIs
are equivalent
 And we may not explore the
overflow condition and the
division by zero condition
31
Examples
Equivalent or different?
Amalfitano, D., Amatucci, N., Memon, A.M., Tramontana, P., Fasolino, A.R. A general framework for comparing automatic testing techniques of
Android mobile apps (2017) Journal of Systems and Software, 125, pp. 322-343.

 If the counters values are not
taken into account, these
GUIs are equivalent
 And the conditions correponding
to the reaching of the maximum
values and some specific
combinations of the counters are
not explored
 Instead, we have to test for
all the events executable in
about 1000 states differing
only for the values of the
counters
32
Examples
Equivalent or different?

 The selection of the events to be executed strongly
influences the effectiveness and the efficiency of the
testing technique
 Possible types of events:
 User events
 On each point of the screen (Monkey)
 Corresponding to the events having specific handlers (Android
Ripper, Dynodroid, …)
 Corresponding to a fixed set of events and a fixed set of widget
types
 System events
 Application close/restart, volume controls, sensor events, …
33
Extraction Strategy

 Possible values
 Constant values / values from a limited set
 Each possible value
 The extraction strategy strongly influences the
number of the edges of the model (in FSM, EFG,
GUI Tree)
 Most of the available tools considers only a little
set of user events executable on a little set of
widgets, with constant values
34
Extraction Strategy

 Influences the order of execution of the events
 Breadth First
 Minimize the length of
the visited paths
 Depth First
 Find longer test paths
 None of the two is generally able to
provide a larger coverage
 Random First
 The exploration strategy influences the depth of
the model
35
Scheduling Strategy

 Randomness can be a valid solution for both the
selection of the event to be triggered and for the
scheduling strategy
 Randomness can lead to an effective discovery
of faults
 Random testing techniques may find complex faults
 It may be very inefficient:
 Redundant tests
 Generate long tests that do not provide useful
information for the debugger
36
Random Testing
http://web.cecs.pdx.edu/~hamlet/random.pdf

 Intelligent Random testing techniques may lead to the
generation of more efficient test cases
 But they can bias the explration reducing the obtained coverage
 Search based techniques have been recently applied in the
context of Android applications
 Automatic termination criteria can reduce the execution
of redundant test cases
 But they can prevent the reaching of the
maximum possible coverage
37
Random Testing
Zhifang Liu, Xiaopeng Gao and X. Long, "Adaptive random testing of mobile application," 2010 2nd International Conference on Computer Engineering and
Technology, Chengdu, 2010
Mao, K., Harman, M., Jia, Y. Sapienz: Multi-objective automated testing for android applications (2016) ISSTA 2016 - Proceedings of the 25th International
Symposium on Software Testing and Analysis, pp. 94-105.

 If there are sufficient resources and the
model is finite, then the exploration can
be executed until all the possible nodes
and edges have been visited
 Elsewhere, heuristic termination criteria
have to be considered
38
Termination Criteria

39
Termination Criteria
 Time criteria: tests stop after a fixed time
 Cost/Effort criteria: tests stop when a fixed cost or effort is reached
 Objective criteria: tests stop when a fixed testing objective is
reached
 E.g. a fixed number of bugs is found, when a fixed percentage of code coverage
is reached, when all the model states have been explored
 Statistical criteria: when the temporal frequency of fault discovery
goes under a fixed value
 For example, when no new faults have been found in the last set of n test cases
 Saturation criteria: when a set of different testing executions give
exactly the same results
 Applicable, for example, in problems involving randomness

The coincidence
of the coverage
of several testing
sessions may be
an indicator of a
good point to
terminate testing
40
Example of Saturation Termination
Criteria
Amalfitano, D., Amatucci, N., Fasolino, A.R., Tramontana, P., Kowalczyk, E., Memon, A.M. Exploiting the Saturation Effect in Automatic Random Testing of
Android Applications (2015) Proceedings - 2nd ACM International Conference on Mobile Software Engineering and Systems, MOBILESoft 2015

 Test cases generated / developed in scripting languages
should be automatically executable and repeatable
 Unfortunately, many factors may impact the fidelity of
the re-execution:
 Test Execution Platform
 Emulator / Device version and configuration
 Timing
 Machine state
 Application preconditions
 Other concurrent processes / services
“Making System User Interactive Tests Repeatable: When and What Should we Control?” by Zebao Gao, Yalan Liang, Myra
B. Cohen, Atif M. Memon, and Zhen Wang, in The Proceedings of The 37th International Conference on Software Engineering (ICSE
2015), 2015.
42
Test case automatic execution

 Test cases at unit testing level can be
executed in the context of the virtual
machine
 Sometimes an equivalent Java Virtual Machine
can been used to execute test cases fastly
 Nariman Mirzaei, Sam Malek, Corina S. Păsăreanu, Naeem Esfahani, and Riyadh Mahmood. 2012. Testing android
apps through symbolic execution. SIGSOFT Softw. Eng. Notes 37, 6 (November 2012)
 Test cases at system level have to be
executed in the context of a real device or
of an emulator
43
Test case automatic execution

 The cost and the time of the execution of System Level tests are not
negligible
 Tests have to be executed on many different devices / emulators with
different versions of Android and associated libraries
 Test cases have to be executed with realistic time constraints
 The state of the device/emulator should be restored at each execution
 The adoption of cloud architectures can provide
valid solutions (but at a remarkable cost)
 Not less than 1$ for hour for emulated device with
Firebase (5$ for real devices)
44
Issues and costs

 Manually written assertions
 Crashes / unhandled
exceptions
 Invariants
 Comparison of screenshot
bitmaps (e.g. sikuli)
 The effectiveness of testing techniques can be evaluated
in terms of the number of failures found
 As an alternative, code coverage or other coverage measures
are often used in literature
 A porting of the Emma coverage framework is natively provided by Android
45
Automatic evaluation of test results

 Inferred Model
 GUITree, FSM
 Widgets and some properties (length, id) (SAV)
 Also text values (MAV)
 Only a subset of events having specific defined event handlers
 Breadth First / Depth First / Random First
 Exploration completed / Saturation
 Ref: https://github.com/reverse-unina/AndroidRipper
 https://www.youtube.com/watch?v=Xy0py1dBGZE
46
Tools : Android Ripper

1.
Task List Initialization;
2.
while (Task List Is Not Empty) {
3.
Extract a Task From The Task List;
4.
Execute the Task;
5.
Abstract the Current GUI Abstract
State;
6.
Update the GUI Tree Model;
7.
if (GUI Exploration Criterion) then {
8.
Define New Tasks ;
9.
Add New Tasks To The Task
List;
10.
}
11.
}
47
Rotate
Press MenuClick Refresh
Click
New Post
Click Pages
Click About
Click Add
Account
≡
≡
Click
Edit
Crash
…
…
Click Save
……
Ripping
Algorithm
1. Task List Initialization;
2.
while (Task List Is Not
Empty) {
3. Extract a Task From The
Task List;
4. Execute the Task;
5. Abstract the Current GUI
Abstract State;
6. Update the GUI Tree
Model;
7.
if (GUI Exploration
Criterion) then {
8.
Define New Tasks ;
9.
Add New Tasks To
The Task List;
10.
}
11.
}

 Widgets and some properties (length, id) (SAV)
 Also text values (MAV)
 Random (Uniform / Frequency based / Biased)
 Fixed number of events
 Ref: https://bitbucket.org/pag-lab/dynodroid
https://www.youtube.com/watch?v=5LSrWRhz0Do
48
Tools : Dynodroid
Machiry, A., Tahiliani, R., Naik, M. Dynodroid: An input generation system for android apps (2013) 2013 9th Joint Meeting of the European Software
Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering, ESEC/FSE 2013

 Inferred Model
 Activity Transition Graphs
 Activity names
 Depth First / Targeted
 Exploration completed
 Ref: https://github.com/tanzirul/a3e
 https://www.youtube.com/watch?v=5zQlP3Ch50A
49
Tools : A3E
Azim, T., Neamtiu, I. Targeted and depth-first exploration for systematic testing of android apps (2013) Proceedings of the Conference on Object-Oriented
Programming Systems, Languages, and Applications, OOPSLA

 Inferred Model
 Extended Deterministic Labeled Transition System
 Widgets, properties and text values (MAV)
 L* (optimizes the number of restart operations) / Random
 Exploration completed / Maximum Number of Events
 Ref: https://github.com/wtchoi/SwiftHand
 https://www.youtube.com/watch?v=2VuzLN7ithQ
50
Tools : SwiftHand
Choi, W., Necula, G., Sen, K. Guided GUI testing of android apps with minimal restart and approximate learning (2013) Proceedings of the Conference on
Object-Oriented Programming Systems, Languages, and Applications, OOPSLA

 Inferred Model
 Activity Map
 Unknown
 Unknown: probably a subset of events having specific defined event
handlers, with predefined text values
 Unknown: probably a mixed breadth first / depth first strategy
 Maximum Depth / Maximum Time
 The tests are executed on cloud distributed devices or emulators
 Ref: https://firebase.google.com/docs/test-lab/robo-ux-test
 https://www.youtube.com/watch?v=xAsvwy1-oxE
51
Tools : Firebase Robo

 A subset of user and system events, with randomized
parameters (e.g. the position of a click event)
 Random, influenced by the fixed frequency of event types
 Maximum Number of Events
 The events are injected at system level
 Ref: https://developer.android.com/studio/test/monkey.html
 https://www.youtube.com/watch?v=dfPNF-6RXVc
52
Tools : Monkey

 A search based testing technique
 Starts from a set of test cases generated by a hybrid
systematic/random test generation technique
 Automatically generates test cases by applying mutation and
crossover operators
 Evolves the test suites by considering a multiobjective fitness
function taking into account failure detection, code overage and
test length
 The termination technique is related to the reaching of an
arbitrary fixed number of iterations
 Ref: https://github.com/Rhapsod/sapienz
https://www.youtube.com/watch?v=j3eV8NiWLg4
53
Tools : Sapienz
Mao, K., Harman, M., Jia, Y. Sapienz: Multi-objective automated testing for android applications (2016) ISSTA 2016 - Proceedings of the 25th International
Symposium on Software Testing and Analysis, pp. 94-105.

 A great limitation of the current techniques for
Android testing is the set of considered inputs
 Most of the existing approaches are limited to user
events and simple system events
 Testing against sensor events presents many
issues:
 Simulation / emulation / execution of sensor events
 Generation of input values
 Timing of sensor events
54
Sensor Based Testing

 The state of the art of context-aware testing for mobile applications
has been recently reported in :
 I. de Sousa Santos, R. M. de Castro Andrade, L. S. Rocha, S. Matalonga, K. M. de Oliveira, G. H. Travassos, Test case
design for context-aware applications: Are we there yet?, Information and Software Technology (2017)
 A basic solution consists is the application of mutant operators ito
existing test cases reproducing:
 Resume/restart of the application
 Caused, for example, by a double screen rotation
 Loss / Resume of GPS signal
 Loss / Resume of Internet connection
 …
 Christoffer Quist Adamsen, Gianluca Mezzetti, and Anders Møller. 2015. Systematic execution of Android test suites in adverse
conditions. In Proceedings of the 2015 International Symposium on Software Testing and Analysis (ISSTA 2015). ACM
 D. Amalfitano, A. Fasolino, P. Tramontana, N. Amatucci, Considering context events in event-based testing of mobile applications,
in: Software Testing, Verification and Validation Workshops (ICSTW), 2013 IEEE Sixth International Conference on, 2013,
55
Context-aware testing

 D. Amalfitano, A. Fasolino, P. Tramontana, N. Amatucci, Considering context events in event-based testing of
mobile applications, in: Software Testing, Verification and Validation Workshops (ICSTW), 2013 IEEE Sixth
International Conference on, 2013,
 C.-J.M. Liang, N. D. Lane, N. Brouwers, L. Zhang, B. F. Karlsson, H. Liu, Y. Liu, J. Tang, X. Shan, R. Chandra, F.
Zhao, Caiipa: Automated large-scale mobile app testing through contextual fuzzing, in: Proceedings of the 20th
Annual International Conference on Mobile Computing and Networking, MobiCom ’14, ACM,
 T. Griebe, V. Gruhn, A model-based approach to test automation for context-aware mobile applications, in:
Proceedings of the 29th Annual ACM Symposium on Applied Computing, SAC ’14, ACM,
 T. Griebe, M. Hesenius, V. Gruhn, Towards automated ui-tests for sensor-based mobile applications,
Communications in Computer and Information Science 532 (2015)
 C. Q. Adamsen, G. Mezzetti, A. Møller, Systematic execution of android test suites in adverse conditions, in:
Proceedings of the 2015 International Symposium on Software Testing and Analysis, ISSTA 2015, ACM,
 S. Yu, S. Takada, Mobile application test case generation focusing on external events, in: Proceedings of the 1st
International Workshop on Mobile Development, Mobile! 2016, ACM,
 I. de Sousa Santos, R. M. de Castro Andrade, L. S. Rocha, S. Matalonga, K. M. de Oliveira, G. H. Travassos, Test
case design for context-aware applications: Are we there yet?, Information and Software Technology (2017)
56
Other resources on context-aware
testing

 Comparisons of techniques
 More general and useful for the developers of
new tools
 Domenico Amalfitano, Nicola Amatucci, Atif M. Memon, Porfirio Tramontana, Anna Rita Fasolino: A general
framework for comparing automatic testing techniques of Android mobile apps. Journal of Systems and
Software
 Comparisons of tools
 More useful for the final user, with respect to
the current state of the art
 Shauvik Roy Choudhary, Alessandra Gorla, and Alessandro Orso. 2015. Automated Test Input Generation
for Android: Are We There Yet? (E). In Proceedings of the 2015 30th IEEE/ACM International Conference
on Automated Software Engineering (ASE)
58
Comparative studies

With the same tool and the same configuration of the device / emulator
59
Comparisons between techniques
• The scheduling
strategy (BF or DF) has
not a great influence
on the performance
• Abstraction strategies
with a coarse grained
level of details bring to
less effective but more
efficient tests
• Abstraction strategies
with a fine grained
level of details may
bring to more effective
but they may also
bring to infinite tests
• Random testing
techniques are
generally more
effective but less
efficient than active
learning techniques
Domenico Amalfitano, Nicola Amatucci, Atif M. Memon, Porfirio Tramontana, Anna Rita Fasolino: A general
framework for comparing automatic testing techniques of Android mobile apps. Journal of Systems and Software

 With different tools and
configurations arbitrary provided by
the experimenters
 Active Learning appears to be less
effective but more efficient
 Their effectiveness could be improved by
setting them properly
61
Comparisons between tools
Shauvik Roy Choudhary, Alessandra Gorla, and Alessandro
Orso. 2015. Automated Test Input Generation for
Android: Are We There Yet? (E). In Proceedings of the
2015 30th IEEE/ACM International Conference on
Automated Software Engineering (ASE)

 An initial comparison between the performance of test cases
generated by:
 2 Tools proposed in literature (Android Ripper / Sapienz)
 1 Free industrial tools (Monkey from Android)
 2 Cloud available tools (Robo from Google Firebase / Fuzz from
Amazon)
 20 Software Engineering students using a Capture & Replay tool
(Robotium Recorder) for black box testing purposes (for about three
hours)
 The same 20 students trying to improve the coverage of the previously
coded black box test cases by means of white box structural testing
strategies (as an homework of the course)
 4 different small Android applications
 Coverage measures related to specific testing targets
63
Another comparison

64
Obtained coverages
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
70,00%
80,00%
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
70,00%
80,00%
90,00%
100,00%
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
70,00%
80,00%
90,00%
0,00%
10,00%
20,00%
30,00%
40,00%
50,00%
60,00%
70,00%

 Most of the techniques and tools in literature are focused on GUI testing of Android
applications
 Few contributions about testing of system and sensor events
 Few contributions about testing of interactions between different apps
 Few contributions about automatic fault finding
 Distance between academy and industry
 Few contributions from industry
 Few contributions about the evaluation of industrial tools
 Few contributions about concurrency testing
 Lacks of contributions related testing of C++ based components of mobile
applications.
 Lacks of venues or journals focused on Mobile Testing Automation
 An active tentative:
 https://www.hindawi.com/journals/misy/si/279098/cfp/
65
Some research trends and gaps

https://www.hindawi.com/jou
rnals/misy/si/279098/cfp/
66Porfirio Tramontana – Tarot 2017 - Napoli- 30/06/2017

 In collaboration with the Reverse Group at
the University of Naples Federico II
 Anna Rita Fasolino, Domenico Amalfitano, Nicola Amatucci, Vincenzo De Simone, Vincenzo Riccio
67
Acknowledgements

Techniques and Tools for Mobile Testing Automation

Recommended

Recommended

More Related Content

What's hot

What's hot (15)

Similar to Techniques and Tools for Mobile Testing Automation

Similar to Techniques and Tools for Mobile Testing Automation (20)

More from Porfirio Tramontana

More from Porfirio Tramontana (20)

Recently uploaded

Recently uploaded (20)

Techniques and Tools for Mobile Testing Automation