Enabling Testing of Android Apps

Linares‐Vásquez, Mario

doi:10.1109/icse.2015.242

Cited by 13 publications

(8 citation statements)

References 9 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…It was found that random exploration strategies by Monkey 5 or Dynodroid [29] were more effective than more sophisticated approaches. Although our work does not scope AIG tools, very often they use UI automation frameworks (e.g., UIAutomator and Robotium) underneath their systems [30], [31], [32], [33]. Results and insights about energy consumption in our study may also apply to tools that build on top of UI automation frameworks.…”

Section: Related Workmentioning

confidence: 91%

“…where N is the number of times experiments are repeated (30), E i is the measured energy consumption for execution i, IdleCost is the energy usage per second (i.e., power) of having the device in idle mode, expressed in watts (W), and ∆t i the duration of execution i. After removing idle cost, we compute overhead in a similar fashion as previous work [40]:…”

Section: Setup and Metricsmentioning

confidence: 99%

See 1 more Smart Citation

On the Energy Footprint of Mobile Testing Frameworks

Cruz

Abreu

2021

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

High energy consumption is a challenging issue that an ever increasing number of mobile applications face today. However, energy consumption is being tested in an ad hoc way, despite being an important non-functional requirement of an application. Such limitation becomes particularly disconcerting during software testing: on the one hand, developers do not really know how to measure energy; on the other hand, there is no knowledge as to what is the energy overhead imposed by the testing framework. In this paper, as we evaluate eight popular mobile UI automation frameworks, we have discovered that there are automation frameworks that increase energy consumption up to roughly 2200%. While limited in the interactions one can do, Espresso is the most energy efficient framework. However, depending on the needs of the tester, Appium, Monkeyrunner, or UIAutomator are good alternatives. In practice, results show that deciding which is the most suitable framework is vital. We provide a decision tree to help developers make an educated decision on which framework suits best their testing needs.

show abstract

Section: Related Workmentioning

confidence: 91%

Section: Setup and Metricsmentioning

confidence: 99%

On the Energy Footprint of Mobile Testing Frameworks

Cruz

Abreu

2021

IIEEE Trans. Software Eng.

View full text Add to dashboard Cite

show abstract

“…These coordinates are used to generate adb input commands to reproduce the GUI event. This approach relies on our previous work in replaying events of test sequences in Android apps [47], [50]. An example of a CRASHSCOPE replayable script can be seen in Fig.…”

Section: F Generating and Replaying Reproduction Scriptsmentioning

confidence: 99%

Automatically Discovering, Reporting and Reproducing Android Application Crashes

Moran

Linares‐Vásquez

Bernal-Cárdenas

et al. 2016

2016 IEEE International Conference on Software Testing, Verification and Validation (ICST)

Self Cite

151

123

View full text Add to dashboard Cite

Mobile developers face unique challenges when detecting and reporting crashes in apps due to their prevailing GUI event-driven nature and additional sources of inputs (e.g., sensor readings). To support developers in these tasks, we introduce a novel, automated approach called CRASHSCOPE. This tool explores a given Android app using systematic input generation, according to several strategies informed by static and dynamic analyses, with the intrinsic goal of triggering crashes. When a crash is detected, CRASHSCOPE generates an augmented crash report containing screenshots, detailed crash reproduction steps, the captured exception stack trace, and a fully replayable script that automatically reproduces the crash on a target device(s).We evaluated CRASHSCOPE's effectiveness in discovering crashes as compared to five state-of-the-art Android input generation tools on 61 applications. The results demonstrate that CRASHSCOPE performs about as well as current tools for detecting crashes and provides more detailed fault information. Additionally, in a study analyzing eight real-world Android app crashes, we found that CRASHSCOPE's reports are easily readable and allow for reliable reproduction of crashes by presenting more explicit information than human written reports.

show abstract

“…e approaches for automated GUI testing of Android applications can be classified as follows [22]: fuzzy (or random) testing, model-based testing techniques, capture and replay, white-box scripted testing. Most of them allow, in some cases without having any access to the source code (i.e., only the .apk package of the application is needed), to generate test scripts that can be therefore executed quickly and repeatedly.…”

Section: Testing Android Appsmentioning

confidence: 99%

“…Espresso [17] is an opensource automation framework that allows to test the UI of a single application, leveraging a gray-box approach (i.e., the developer has to know the internal disposition of elements inside the view tree of the app, to write scripts exercising them). UI Automator [6,22]adds some functionalities to those provided by Espresso: it allows to check the device status and performance, to perform testing on multiple applications at the same time, and operations on the system UI. Both tools can be used only to test native applications.…”

Section: Selected Testing Toolsmentioning

confidence: 99%

Scripted GUI Testing of Android Apps

Coppola

Morisio

Torchiano

2017

Proceedings of the 13th International Conference on Predictive Models and Data Analytics in Software Engineering

View full text Add to dashboard Cite

Background. Evidence suggests that mobile applications are not thoroughly tested as their desktop counterparts. In particular GUI testing is generally limited. Like web-based applications, mobile apps suffer from GUI test fragility, i.e. GUI test classes failing due to minor modifications in the GUI, without the application functionalities being altered.Aims. e objective of our study is to examine the diffusion of GUI testing on Android, and the amount of changes required to keep test classes up to date, and in particular the changes due to GUI test fragility. We define metrics to characterize the modifications and evolution of test classes and test methods, and proxies to estimate fragility-induced changes.Method. To perform our experiments, we selected six widely used open-source tools for scripted GUI testing of mobile applications previously described in the literature. We have mined the repositories on GitHub that used those tools, and computed our set of metrics.Results. We found that none of the considered GUI testing frameworks achieved a major diffusion among the open-source Android projects available on GitHub. For projects with GUI tests, we found that test suites have to be modified o en, specifically 5%-10% of developers' modified LOCs belong to tests, and that a relevant portion (60% on average) of such modifications are induced by fragility.Conclusions. Fragility of GUI test classes constitute a relevant concern, possibly being an obstacle for developers to adopt automated scripted GUI tests.is first evaluation and measure of fragility of Android scripted GUI testing can constitute a benchmark for developers, and the basis for the definition of a taxonomy of fragility causes, and actionable guidelines to mitigate the issue.

show abstract

Enabling Testing of Android Apps

Cited by 13 publications

References 9 publications

On the Energy Footprint of Mobile Testing Frameworks

On the Energy Footprint of Mobile Testing Frameworks

Automatically Discovering, Reporting and Reproducing Android Application Crashes

Scripted GUI Testing of Android Apps

Contact Info

Product

Resources

About