Non-Functional Testing of Runtime Enforcers in Android Oliviero Riganelli10000000321202894 Daniela Micucci10000000312612234

2025-05-02 0 0 1.61MB 16 页 10玖币

侵权投诉

Non-Functional Testing of Runtime Enforcers in

Android

Oliviero Riganelli1[0000−0003−2120−2894], Daniela Micucci1[0000−0003−1261−2234],

and Leonardo Mariani1[0000−0001−9527−7042]

University of Milano-Bicocca, Milan 20126, Italy

{oliviero.riganelli,daniela.micucci,leonardo.mariani}@unimib.it

Abstract. Runtime enforcers can be used to ensure that running appli-

cations satisfy desired correctness properties. Although runtime enforcers

that are correct-by-construction with respect to abstract behavioral mod-

els are relatively easy to specify, the concrete software enforcers generated

from these speciﬁcations may easily introduce issues in the target appli-

cation. Indeed developers can generate test suites to verify the functional

behavior of the enforcers, for instance exploiting the same models used

to specify them. However, it remains challenging and tedious to verify

the behavior of enforcers in terms of non-functional performance char-

acteristics. This paper describes a practical approach to reveal runtime

enforcers that may introduce ineﬃciencies in the target application. The

approach relies on a combination of automatic test generation and run-

time monitoring of multiple key performance indicators. We designed our

approach to reveal issues in four indicators for mobile systems: respon-

siveness, launch time, memory, and energy consumption. Experimental

results show that our approach can detect performance issues that might

be introduced by automatically generated enforcers.

Keywords: Runtime Enforcement ·Testing enforcers ·Non-functional

testing ·Android apps.

1 Introduction

Mobile applications are extremely popular. Indeed, there are applications to

support virtually any task, as witnessed by the more than 3 million applications

available for download in Google Play in the ﬁrst quarter of 2022 [36].

Mobile applications interact with the hosting device, exploiting the available

resources, such as the camera, memory, battery, and Wi-Fi antenna. Unfortu-

nately, mobile applications may easily misuse resources, causing issues to the

underlying system and the rest of the applications running in the device. For

instance, an application may acquire the camera without releasing it, preventing

the access to the camera to the other applications.

To prevent these problems, users of mobile applications can install and acti-

vate software enforcers [12,15,32,11,10] that guarantee that speciﬁc correctness

arXiv:2210.12155v1 [cs.SE] 14 Sep 2022

2 Riganelli et al.

policies are satisﬁed (e.g., the camera is always released after it has been ac-

quired). These enforcers can be typically generated automatically from a model-

based representation of the processes involved in the policy that must be en-

forced. For instance, I/O automata can model the behavior of apps and services

running in a mobile device, and edit automata [20] can be used to specify en-

forcers that can correct executions to avoid policy violations. Software enforcers

derived from these models are guaranteed to ﬁx the execution since they are

correct-by-construction, as long as both the speciﬁed models and the code gen-

eration process are correct.

However, models are abstractions of the behavior of the software and its envi-

ronment, and often miss many relevant details that might aﬀect the correctness

of the enforcers. For this reason, software enforcers, even when generated auto-

matically, have to be tested. In previous work [13], we addressed the challenge

of automatically generating test cases that cover the functional speciﬁcation

used to generated the enforcers, and to ensure correctness-by-construction be-

fore the enforcers are deployed. However, correctness-by-construction is limited

to the functional aspect of the enforcers. In this paper, we address the challenge

of enriching the testing strategy with the capability to collect and analyze non-

functional indicators to ensure non-functional properties, speciﬁcally through the

detection of performance problems that might be introduced into the target sys-

tem in an attempt to apply (functional) policy. We experimented our approach

with several enforcers, indicators, and faults, demonstrating the usefulness of ad-

dressing both the functional and non-functional aspects when verifying software

enforcers.

The paper is organized as follows. Section 2 provides background information

about software enforcement. Section 3 describes the test case generation strategy

for software enforcers, augmented to deal with performance problems. Section 4

reports the results that we obtained with the evaluation of the approach. Sec-

tion 5 discusses related work. Finally, Section 6 provides ﬁnal remarks.

2 Background

In this section we introduce the notion of runtime policy and policy enforcement.

2.1 Runtime Policy

A runtime policy is a predicate over a set of executions. More formally, let Σbe

a ﬁnite set of observable program actions a. An execution σis a ﬁnite or inﬁnite

non-empty sequence of actions a1;a2;. . . ;an.Σ∗is the set of all ﬁnite sequences,

Σωis the set of inﬁnite sequences, and Σ∞=Σ∗∪Σωis the set of all sequences.

Given a set of executions χ⊆Σ∞, a policy is a predicate Pon χ. A policy Pis

satisﬁed by a set of executions χif and only if P(χ)evaluates to true.

A policy may concern any behavior of an application, including resource

usage and security. For example, an Android policy [1] requires that anytime an

Android app stops using the camera, it explicitly releases the camera to make it

Non-Functional Testing of Runtime Enforcers in Android 3

available to the other apps. More in details, “if an activity1is using the camera

and the activity receives an invocation to the callback method onPause()2, the

activity must release the camera.” We refer to this policy throughout the paper

to describe our approach.

2.2 Policy Enforcement Models

A policy enforcement model speciﬁes how executions must be changed to make

them satisfy a given policy. Policy enforcers can be represented with ﬁnite-state

models, such as edit and input/output automata. For instance, Figure 1 shows

an input/output automaton that speciﬁes an enforcement model that can enforce

a faulty activity that does not release the camera to release it.

The inputs are the events intercepted by the enforcer (represented with the

req subscript in the model) while the outputs (represented with the api subscript)

are the events emitted by the enforcer in response to the intercepted events.

When the input and the output in a same transition match (regardless of the

subscript), the enforcer is not changing the execution. If the output diﬀers from

the input, the enforcer is changing the execution suppressing and/or adding

events.

Referring to the example model in Figure 1, state s0represents the case

the camera has not been acquired yet, and the enforcer is ready to intercept

events without altering the execution. In fact, both pausing the current activity

(event activity.onPause()) and acquiring the camera (event camera.open())

are events compatible with the policy related to the access to the camera. Once

the camera is acquired (event camera.open() from state s0), the camera must

be released before the activity can be paused. In state s1, the enforcer is thus

ready to accept the camera.release() event. On the contrary, if the activ-

ity is paused, the activity.onPause() event would violate the policy (i.e.,

the activity would be paused without releasing the camera), and thus the en-

forcer modiﬁes the execution emitting the sequence of events camera.release()

activity.onPause(), which guarantees the satisfaction of the policy.

Enforcement strategies must be translated into software components (i.e.,

software enforcers) that enforce the speciﬁed strategies at runtime. This trans-

lation could be done manually, semi-automatically, or automatically. In all the

cases, the resulting components may include bugs, due to issues in the transla-

tion process and the extra code added by developers to obtain fully functional

components, and must be tested extensively before they can be deployed and

used.

To detect functional bugs, we developed Test4Enforcers [13], a tool that auto-

matically generates test cases that cover the functional speciﬁcation used to gen-

erate the enforcers. In this paper, we describe how we extended Test4Enforcers

1Activities are the entry point of interactions between users and apps

https://developer.android.com/guide/components/activities

2onPause() is a callback method that is invoked by the Android framework every

time an activity is paused.

4 Riganelli et al.

start s1

camera.open()r eq ?/camera.open()api!

activity.onP ause()req ?/activity.onP ause()api!

camera.release()req ?/camera.release()api!

activity.onP ause()req ?/camera.release()api!; activity.onP ause()api!

Fig. 1: Enforcer for systematically releasing the camera when the activity is

paused.

with the capability to detect performance bugs by collecting and analyzing non-

functional indicators.

3 Test4Enforcers

Test4Enforcers detects bugs by implementing a two-step detection strategy. The

ﬁrst step, test case generation, generates test cases that cover the behavior of the

enforcer, considering both the case the enforcer has to modify the execution to

enforce the policy and the enforcer does not need to change the execution since

it already satisﬁes the policy. The second step, test case execution, executes the

generated test cases in the target environment both with and without the policy

enforcer by collecting the Key Performance Indicators (KPIs) that are analyzed

to detect any non-functional bug.

3.1 Test Case Generation

Test case generation consists of 3 activities, as shown in Figure 2.

i) The Generation of the Test Sequences activity generates the test sequences

that must be covered to thoroughly test the behavior of the enforcer according

with the enforcement model.

ii) The GUI Ripping with Tracing activity runs a GUI Ripping process that

explores the GUI of the app under test while tracing the events that are in the

alphabet of the enforcement model. The output of this activity is an augmented

GUI model with states representing the GUI states visited during the ripping

process and the transitions representing the GUI actions that caused the state

change. The model is augmented since each transition is annotated with the

events in the alphabet of the enforcement model that have been executed as a

consequence of the state change.

iii) The Concrete Test Case Generation activity uses the augmented GUI

model to identify the sequences of UI interactions that exercise the test sequences

文档加载中……请稍候！
如果长时间未打开，您也可以点击刷新试试。

下载文档到电脑，查找使用更方便

10 玖币 0人已下载

立即下载

摘要：

Non-FunctionalTestingofRuntimeEnforcersinAndroidOlivieroRiganelli1[0000000321202894],DanielaMicucci1[0000000312612234],andLeonardoMariani1[0000000195277042]UniversityofMilano-Bicocca,Milan20126,Italy{oliviero.riganelli,daniela.micucci,leonardo.mariani}@unimib.itAbstract.Runtimeenforcerscanbeusedtoen...

展开>> 收起<<

Non-Functional Testing of Runtime Enforcers in Android Oliviero Riganelli10000000321202894 Daniela Micucci10000000312612234.pdf

共16页,预览4页

还剩页未读，继续阅读

声明：本站为文档C2C交易模式，即用户上传的文档直接被用户下载，本站只是中间服务平台，本站所有文档下载所得的收益归上传人(含作者)所有。玖贝云文库仅提供信息存储空间，仅对用户上传内容的表现方式做保护处理，对上载内容本身不做任何修改或编辑。若文档所含内容侵犯了您的版权或隐私，请立即通知玖贝云文库，我们立即给予删除！

Non-Functional Testing of Runtime Enforcers in Android Oliviero Riganelli10000000321202894 Daniela Micucci10000000312612234

相关推荐

开通VIP享超值会员特权

作者详情

相关内容

热门标签

举报选择: