由于Android系统自身的开放性，应用市场审核标准不一，导致一些开发者弱化对应用(App)安全性的考虑，为了获取用户数据申请不必要的敏感权限，调用敏感API，如读取手机IMEI码、读写联系人和通话记录等。这些敏感行为可能导致隐私泄露^[1]、诱骗欺诈等问题，给用户造成巨大损失。作为用户下载应用的来源，应用市场应该保证应用的安全性，测试应用是否存在敏感行为。此外，随着应用数量的快速增长，测试者对自动化测试方法的效率提出了更高的要求。目前已提出的自动化动态测试方法主要有两种：全覆盖测试和定向测试。在测试App的特定行为时，基于全覆盖方法的测试工具会造成大量的时间和资源浪费，而定向测试的方法由于更具目的性和方向性，能够极大地提高效率。

定向测试方法大多采用以静态分析辅助动态测试过程的方法，依靠对App代码静态分析得到的信息，以尽可能少的输入事件到达目标位置。目前，测试App敏感行为的相关工具主要有IntelliDrod^[2]、Brahmastra^[3]和SmartDroid^[4]等，但它们的目标各不相同。IntelliDrod依靠精确的静态分析在动态测试生成特定输入，提高动态测试工具测试操作的有效性。Brahmastra主要用于检测恶意应用的第三方方法调用，通过重写App代码控制App状态跳转，提高测试效率。SmartDroid能够自动化获取触发敏感API的条件集，动态测试工具与之结合后能够自动化测试App敏感行为。在进行定向行为测试时，这些方法存在一些限制：1)工具本身不能测试App敏感行为，需要结合其他动态测试工具；2)对静态分析结果的精确度要求过高或对App代码重写，导致使用工具测试时失败的可能性较大。

为解决上述问题，本文提出一种基于GUI的自动化测试方法，对App的特定行为进行定向触发。首先，将该行为对应的API设为目标API，对App进行静态控制流分析和污点分析，获取到达目标API调用位置的路径上的有效组件和控件事件处理方法，形成一条调用路径。当静态分析失败或有误差时，进入误差控制模块。然后，在动态测试过程中，通过实时检测当前页面状态，并实时读取系统日志输出，确保只访问有效组件和控件，使App沿着路径运行，直到抵达路径终点。

本文的方法在不需要对App进行任何修改的情况下实现自动化定向测试，同时不过于依赖静态分析结果，避免了测试失败率高的问题。在测试App特定行为时，能够排除大量Activity和控件，使自动化测试更具目标性和方向性。经实验验证，该方法到达目标API调用位置所需操作的控件数平均是全遍历和随机触发方法所操作控件数的30.7%和13.0%，有效地提高了测试效率。并对61个目标API进行测试，其中只有3个测试失败，失败率较低。

1 相关工作

Android平台上的App自动化测试工具主要分为全覆盖测试和定向测试两种。全覆盖自动化动态测试工具需要尽可能覆盖所有控件，在测试App特定行为时效率较低。由Google发布的Monkey^[5]可以随机向目标程序发送事件流和数据流，在其基础上开发的框架PUMA^[6]可用于压力测试。MonkeyRunner^[7]、Robotium^[8]与UiAutomator^[9]都是Android SDK工具包提供的辅助测试工具，但不能完全自动化。A3E^[10]、AppsPlayground^[11]、Sapienz^[12]、AndroidRipper^[13]等工具以及Dutia等^[14]设计的方法致力于通过构建GUI模型，设计自动化生成正确输入格式等方式来提高全遍历控件时的控件覆盖率。Amalfitano等^[15]提出的快速碰撞测试和回归测试方法，可自动建立GUI模型并生成自动执行的测试用例。赵耀宗等^[16]通过模拟用户行为的方法自动探测GUI，能够以较高的覆盖率遍历GUI控件。BugRocket^[17]建立分布式测试系统，能够自动化生成测试脚本，并将测试请求分发给测试云上的设备。PATS^[18]构建细粒度模型，并行化执行测试过程，极大地提高了测试效率。MobiGUITAR^[19]通过遍历App GUI创建状态机模型，并据此生成和执行测试用例。Dynodroid^[20]把App视为与运行环境交互的事件驱动程序，监控App对每个事件的反应，并据此生成下一个事件。它提供UI和系统事件输入，并能够把机器事件和人工事件无缝结合，提高了代码覆盖率。

定向测试App特定行为的工具大多使用静态分析与动态分析相结合的方法。SmartDroid首先利用静态分析得到运行至敏感API的Activity，遍历这些Activity上的所有控件时监控日志输出的GUI信息并进行分析，得到到达该敏感API的有效UI。Brahmaster通过静态分析获得到达第三方组件中的API调用路径，然后对App进行代码重写，控制App运行时的跳转，使其到达敏感API调用位置。然而对App代码重写存在重签名失败、App运行时崩溃等问题，可能导致测试失败。IntelliDroid在分析出目标API的调用路径后，提取控制目标API调用的条件，构造特定输入值，提高动态测试工具触发目标API的效率。由于IntelliDroid生成的输入会注入所有能够触发目标API的事件处理器，因此静态分析阶段的结果必须非常精确，否则生成的输入值会发生错误，导致最终无法到达目标API调用位置。

2 设计与实现

本文方法针对App特定行为进行定向测试，在分析过程中以目标API近似代表程序行为。如App打开设备摄像头这一特定行为，在代码中调用<android.hardware.Camera: open()>方法，在分析时把此方法定为目标API。

方法分为静态和动态2个分析模块。静态分析模块获取到达目标API调用位置可能经过的组件和控件事件处理方法，以引导动态过程，提高测试效率。当静态分析有误时，进入误差控制过程，减少组件排除量，防止动态测试失败。为了监控控件事件，对Android源码进行修改，使得每次调用回调方法都有日志输出。在动态模块中，操作控件并监控Activity跳转和系统日志输出，以尽可能少的控件操作驱动App运行至目标API位置。

2.1 静态分析模块

静态分析能够得到引导动态测试过程的信息，即从主Activity到目标API调用位置的组件跳转路径。编译过的源码文件——DEX文件是静态分析的对象。本文选择使用开源框架Soot^[21]对其进行静态分析，以及在Soot基础上开发出的FlowDroid^[22]对Android程序进行污点分析^[23]。FlowDroid在对App进行污点分析时先使用IFDS^[24]模型得到一个高效的虚拟main方法，使App中的所有组件的生命周期方法和回调方法可以按照任意顺序调用，用于生成调用图和进程间控制流图(ICFG)。污点分析的过程从检测到的污染源开始，通过遍历ICFG追踪被污染的数据，到达陷入点后污点分析结束，并输出从污染源到陷入点的路径。

App运行至目标API调用位置的过程中可能需要启动Activity、Service、BroadcastReceiver等组件。在用FlowDroid分析前将定义Intent的语句设为Source，并把表 1所示的启动新组件的方法设置为Sink。使用FlowDroid进行污点分析，得到组件间的启动关系，例如，Activity A中的一个回调方法onClick()调用startActivity()方法启动Activity B。这一过程只能得到通过调用表 1中的方法显式启动的组件，因此，还需要使用Soot解析APK文件，得到组件的隐式启动关系，如匹配Intent属性启动Activity。

由于一个Activity可能对应多个GUI界面，需要在动态分析阶段监控回调方法的调用以排除无关GUI控件，因此，还需解析得到调用组件启动方法的回调方法。将组件信息、回调方法以及启动的组件信息结合，形成路径节点，解析的关键程序代码和得到的节点信息举例如图 1所示。

通过解析DEX文件，还能够得到调用目标API的组件，即为最终组件。同时，最终组件调用目标API的方法也可获得。目标API可能被最终组件的3种方法调用：第1种，某控件绑定的监听方法调用的回调方法，操作该控件即可触发目标API，将该回调方法及其类名信息加入路径的终节点，由该类名可得到触发该回调方法的控件所在的Activity(但并不知道控件是哪一个)；第2种，组件的生命周期方法，启动该组件后即可触发目标API，则该组件即为终点；第3种，普通的方法，但此方法最终由前面两种中的某一种调用。

分析结束后，把静态分析得到的各组件间显式启动和隐式启动关系从最终组件开始进行逆向分析，得到一条从主Activity到目标API调用位置的路径。具体过程举例如图 2所示，图中字母表示组件，E为最终组件，A为主Activity，箭头表示启动关系。若路径终点只有Activity信息，表示终点Activity打开时就已触发目标API；若路径终节点含有回调方法信息，则说明目标API需要控件触发，那么在动态测试时，App跳转至终点Activity后仍需遍历GUI控件，直到系统输出的日志与路径终点的回调方法信息一致。

2.2 误差控制

由于存在少数静态分析阶段无法分析出路径或路径有误差的情况，导致按照既定方法无法触发目标API。为提高测试成功率，本文方法增加误差控制功能。在这种情况下，方法利用解析代码得到的Activity的信息把所有Activity分为3类：1)确定与目标API相关；2)确定与目标API无关，即此Activity不能跳转至其他Activity；3)其他。测试时，把除第2)类之外的Activity全部加入路径，在动态测试过程中作为监控对象，判断App运行状态，其他过程按照正常动态遍历过程进行，以降低控件排除比例的方式提高测试的成功率。

2.3 动态分析模块 2.3.1 App状态监控模块

由于静态分析不能得到当前GUI控件与回调方法的对应关系，因此，本文的动态分析过程需要自上而下触发当前GUI的可操作控件。方法采用修改Android源码的方法监控App状态。在遍历当前GUI的控件时，实时监控系统日志，并将其与路径中的回调方法信息匹配，以判断此次控件操作事件是否触发了路径中的回调方法。由于所有的Android App使用的回调机制都相同，本文的方法只需要修改1次Android源码即可。

App运行中启动的多个Activity按照启动顺序依次以栈结构存储在内存中。使用adb shell命令即可获取栈顶Activity，即当前与用户交互的Activity。比较控件操作前后的栈顶Activity即可判断Activity是否发生了跳转，并依此监控App是否沿路径运行。操作某控件后，如果检测到Activity跳转，且该Activity不在路径中，则此Activity中的控件均无需访问。

控件操作能够使GUI在Activity不变的情况下发生改变，可能是控件属性改变或转换至另一个GUI。只判断Activity的跳转可能导致控件操作无效或漏掉关键控件，影响测试效率。因此，必须在每次控件操作之后判断GUI是否发生改变。本文利用UiAutomatorViewer工具获取当前GUI的页面布局信息。首先，使用“adb shell sdkpath\\tools\\uiautomator name-compressed/path/name.xml”^[25]命令把当前用户页面中控件的结构关系和属性等布局信息存储在XML文件中。然后解析该XML文件获取控件的可操作性、位置、文本信息以及页面结构等信息，形成以控件为节点的树结构(本文中称为控件树)，并为每一个节点设置weight(权值)属性。从叶子节点到根节点的每个节点权值设置为其所有子节点权值与该节点初始权值之和。以图 3所示的页面布局的树结构为例说明自下而上计算权值的过程。用根节点权值代表该GUI权值。若控件操作前后根节点权值不变，说明GUI没有变化；反之，GUI发生了转换。

2.3.2 控件操作过程

由于Android App运行过程中的Activity跳转是不可预测的，在控件遍历过程中必须把已遍历过的GUI做标记，并记录在已标记队列中。若检测到此GUI已标记，则回退至上一界面，并触发下一未标记的可操作控件。若同级节点已全部标记，则将它们的父节点直接标记为已操作。自下而上进行标记，直到根节点标记为已操作，那么将被标记的根节点加入已标记队列，说明此GUI中控件已全部遍历。以图 3中的CheckBox为例说明对控件树的标记和操作过程，方框中的控件为已操作。首先，将CheckBox标记为已操作，可知它的同级节点全部为已操作，那么将其父节点LinearLayout标记为已操作；同理，将ListView也标记为已操作；此时第二级节点只有2个被标记，则不标记根节点, 且此GUI不加入已标记队列。

遍历控件树时采用深度优先遍历的方式，自上而下、自左至右地进行。对于控件树的某一节点，首先判断其是否有子节点，如果有，则对其子节点进行分析；若没有，将该控件标记为已操作，并按照算法1所示的过程对控件进行操作。当App运行至路径终点Activity时，若终节点不含回调方法，说明此时目标API已触发，测试结束；若路径终节点含有回调方法，则遍历此页面控件，直到系统输出含有此回调方法信息的日志，说明目标API已经被调用，测试结束。

3 实验

选取Android官方定义的危险权限^[26]和一些特殊权限对应的行为进行测试，验证本文方法对于排除无关Activity和控件的有效性。为评估本文方法的性能，将实验结果与全遍历和随机触发的效率进行比较，并与其他相关方法进行优劣对比。

3.1 测试环境及数据

本文实现的工具运行在Windows 7系统下、内存为8 G的PC平台上，测试的App运行在系统为Android 5.1.1、内存为2 G的测试机上。从Google Paly的流行应用中随机选取5个App的行为进行测试。这5个App普通且具有代表性，能够形象化地展示本文方法的效率和有效性。测试的App的特定行为主要有启动相机、读取IMEI码、NFC通信、读/写联系人、杀死后台进程、连接网络、发送短信、获取Wi-Fi状态等，并把与这些行为相关的API调用设定为目标API。

文献[10]中的数据表明，动态分析部分需要花费的时间平均是静态分析的84.3倍，因此，本实验忽略静态分析耗时对最终结果的影响，只分析动态部分的效率。实验结果如表 2所示，排除的Activity指在到达目标API调用位置前的动态测试过程中排除的无效Activity；排除的控件数包括无效Activity中的控件数和有效Activity中的无效控件数。动态点击的步数仅计算触发事件处理方法的点击事件次数，不考虑回退和滑动屏幕等操作，因此，到达目标API调用位置的步数即为本方法触发的控件数。对于不同App和同一App的不同目标行为，由于目标API的调用位置各不相同，需要操作的控件数可能差别很大，但总体而言，遍历过程中操作的控件数远少于App的控件总数。因此，本方法的组件和控件排除极大地提高了测试效率。实验测试61个目标API，16个不能动态触发。其中13个目标API在App使用的第三方库中，但由于App本身并未调用，能够分析出API所在位置，不能动态触发。另外，有3个目标API由于静态分析出错而不能触发。

3.2 方法性能分析

本文的方法在触发各个目标API调用前访问的控件数占总控件数的比例如图 4所示(图 4~图 6中横轴为表 2中的各目标API)。对于实验中所有的目标API，测试时点击的控件数平均是App中的所有控件数的16.4%。在测试目标API时，全遍历方法需要遍历所有组件，触发了路径外的组件和控件。对于随机控件触发方法，本文使用Monkey工具进行实验。测试结果的对比如图 5所示，到达目标API位置前，本文方法需要的步数比随机触发的方法平均减少87.0%。本文与全遍历方式对比的情况如图 6所示，本方法遍历的Activity与其相比平均减少69.3%，有效地避免了测试时间的浪费。由于动态测试的效率对整个测试过程影响最大，因此，大量无关Activity和控件的排除，使得本文提出的定向测试方法具有很高的效率。

3.3 与定向测试相关工作的对比

分别提取IntelliDroid、Brahmaster与SmartDroid 3个方法进行对比，结果如表 3所示。由表中可以看出，本文的方法有效规避了定向测试工具对静态分析的准确性依赖程度高、动态测试效率低等问题。Brahmaster直接修改App组件启动属性，改变App状态，控制App跳转至第三方代码，测试效率较高，由此导致的重签名失败、运行时崩溃等问题使得测试失败率较高。IntelliDroid用于自动生成能够驱动App运行的输入事件。为了快速触发目标API，每一个输入都必须准确，使得测试的成败依赖于静态分析结果的正确性，该方法的失败率为6.7%。由于App运行中Activity跳转的不确定性，本文方法的输入事件同时基于静态分析结果和App运行状态进行判断，使得方法失败率较低，仅为4.9%。但是，与IntelliDroid相比，本文方法对于App运行时的输入事件类型考虑较少。SmartDroid通过遍历有效Activity中的所有控件得到到达敏感API的UI控件集合，用以辅助动态分析工具进行App敏感行为测试。而本文方法通过排除无关组件以及标记关键回调方法，在动态分析阶段只需遍历部分GUI中关键控件之前的部分控件，即可测试App的特定行为，测试效率较高。

4 总结

本文提出一种针对Android应用特定行为进行自动化定向测试的方法。该方法将静态分析与动态分析相结合，使用静态解析APK文件得到的信息引导动态测试过程，以尽可能少的操作次数触发目标API。通过实验及与其他方法的对比，验证了此方法能够有效提高App定向行为测试的效率。

未来的工作主要针对静态和动态两个模块进行。静态分析方面：当App比较复杂时分析结果可能有误差，从而影响测试结果。考虑改进静态分析算法，提高结果的准确率。动态分析方面：动态分析过程中频繁地获取当前GUI的控件信息，并将其以XML文件的方式从手机端发送至计算机端进行解析。这一过程对动态分析的速度影响较大，考虑改进控件信息获取和解析算法，提高计算效率。