一种安卓人机对战测试的框架及评价方法.docx

前言1第一章绪论2
1.1 研究背景以及意义2
1.2 框架概述3
1.3 本文主要工作以及创新点4
1.4 本文组织结构4第二章安卓UI测试技术5
2.1 安卓UI测试技术简介5
2.2 安卓UI测试的难点5
2.3 安卓UI测试的方法6人工测试6
2.3.1 自动化工具测试6
2.4 安卓UI测试的评价标准8
2.5 本章小结9第三章人机对战框架的需求分析与概要设计10
3.1 人机对战框架工程的整体概述10
3.2 系统需求分析11用例图11
3.2.1 用例描述11系统顺序图14
324非功能性需求描述14
3.3 系统概要设计15类图15
3.3.1 开发视图16
3.4 本章小结18第四章人机对战框架的详细设计与具体实现

第四章人机对战框架的详细设计与具体实现
19
框架子模块概述19
4.1.1 Execution 模块2023安卓UI测试的方法
安卓ui测试在现今主要有两种方式：人工编写代码测试与自动化工具测试。
2.3.1 人工测试
安卓UI测试的人工测试主要也可以分为两种方式：
(1)直接编写测试代码
现如今，安卓UI测试的代码编写都是基于框架编写的⑶，而最为流行的安卓UI 测试框架，有 UIAutomator、Robotium 与 Appium⑷。
这三者分别使用不同的代码规范，测试者需要按照这些规范编写测试代码并运行, 就可以模拟出正常用户使用安卓应用的行为。
(2)众包测试
众包测试⑶是一种比拟新型的测试方式，它会将待测的安卓应用分发给数百人即 进行测试，这些人会分别使用他们自己能想到的所有方法来测试该应用，并填写测试 报告。相较于编写测试代码而言，这种方式并没有太好的复现性，但是由于用户数量 巨大，而且测试者和编码者不同，可以完全将自己看为程序的使用者来提出意见，因 此也能得到好的反响。
2.3.2 自动化工具测试
为了节约人力与物力，研究人员们意图开发出能够自动进行安卓UI测试的工具， 并取得了不错的进展。现如今的自动化工具，主要可以根据其测试策略分为三类：随 机探索策略、基于模型的探索策略与系统的探索策略⑹。
(1)随机探索策略
随机探索策略⑸顾名思义，即所有的操作都是随机的，自动化工具会根据自己的 随机策略为安卓应用生成输入。并且，该策略几乎只能应用于UI测试。这种方法生 成测试用例的效率实际上并不高，因为随机性，经常会牛成重复的应用输入。同时， 由于安卓应用的层次性，即许多页面需要进行一定量的固定操作才能进入，随机探索 策略就难以进入这些页面了。但是，由于随机策略生成测试用例，即应用输入的效率 十分之高，该策略也常用来进行安卓应用的压力测试。
比拟有名的随机探索策略自动化测试工具有Monkey与Dynodroid,前者是由安 卓SDK (Software Development Kit)自身提供的命令行工具，可以说是官方工具了， 正如其名，它会像猴子一样随机的进行动作来测试。后者那么是一个年代较为久远的工 具，作为安卓自动化工具的开山鼻祖之一而常常被人提及。
(2)基于模型的探索策略
基于模型的探索策略⑺，是从一些网络爬虫中得到的灵感，这种策略的自动化工 具，会获取每个页面中，可以点击或进行其他操作的控件，将他们放入栈或队列中, 接着按照顺序一个个进行处理。当然，也可以通过配置文件来说明不需要进行操作的 活动的名称来加快进程。这种方法的优点是可以将所有的UI都测试到，无论深度有 多深，这是随机策略无法到达的。但是同样的，基于模型的探索策略也有缺点，就是 在不改变核心算法的情况下，每一次的测试路径是一样的，如果针对一款刚刚完成的 安卓应用进行测试的话，每当遇到让程序崩溃的错误，就需要重头测试一遍，较为消 耗时间。
比拟有名的基于模型的探索策略自动化测试工具有AppCrawler与PUMA,前者 是国人编写的一款工具，通过配置文件的输入，可以做到自动辨识登录界面，从而做 到能够测试绝大局部应用。而后者那么是一款基于Monkey编写的框架，他可以用来接 入安卓应用从进行动态分析。
(3)系统的探索策略
有一局部安卓应用的行为，只有在提供特定的输入的时候才会显现出来。而之前 的两种方法显然无法做到这一点，因此，一些安卓测试工具使用了更复杂的技术，比 如符号执行或进化算法来对尚未覆盖的代码进行探索，这就是系统的探索策略⑻⑼。
由于这一研究较为深奥，因此相关人员对于这局部工具也仍然只是处于研究中。 较为有名的系统的探索策略的自动化测试工具有ACTEve, 一种符号测试的工具。
1.1 UI测试工具的比照
2015年，Shauvik Roy Choudhary等人对局部著名的安卓自动化UI测试工具进行 了一次比照实验口叫实验的结果令人惊讶，测试完安卓应用后，代码覆盖率最高的工 具，居然是随机探索策略的Monkey,平均覆盖率到达了近50%。但这个数据相较于 人工编写代码而言，是很低的，因为人工编写代码的覆盖率，几乎是能覆盖整个应用 的。
不过，自动化测试工具也有他的优点，那就是速度快。他们到达代码覆盖率的时 间几乎都在5-10分钟内。而如果换成人类进行测试代码的编写，可能需要花上好几 个小时。
2.4 安卓UI测试的评价标准
安卓UI测试的结果评估指标很多，对于代码而言，有代码覆盖率、异常触发率、 变异杀死率等等。
(1)代码覆盖率
代码覆盖率应该是现如今最为常见的测试结果评估指标了，测试代码覆盖了整个 应用的多少，至少从数量上可以侧面反响这一次的测试是否全面。因为测试代码最主 要的目的就是通过输入来实现对程序功能以及代码的覆盖，来观察程序的反响以找到 程序的缺陷，从而才能对程序继续进行改进。代码覆盖率主要包括源代码的覆盖率与 中间代码的覆盖率，源代码覆盖率更为准确，但是大局部情况下，应用并不会开放源 代码，因此中间代码覆盖率的适用性会更强。
(2)异常触发率
异常触发率对于人工代码而言可能不是必须的，因为一般触发了异常会导致程序 退出，接下来的代码就无法继续执行了，可是对于自动化工具而言，这是一个比拟重 要的指标。工具触发了异常，说明工具找到了应用程序的问题，侧面就能说明自动化 工具到达了目的，因此也是一个重要的测试结果评判标准。
(3)变异杀死率他
变异是一个比拟不常见的概念，在通用的情况下，变异是指，源代码的某一处逻 辑发生改变，导致程序整体功能也因此而改变的情况，一般是在开发人员手误写错了 代码的时候发生。比方将大于号错写成小于号，就会使得程序的输出与预计不符。
在这种情况下，测试代码应当使用断言来对这些局部进行检测，断言是指，对某 一个输出或者某一个值做出一个固定的判断，如果程序执行导致断言处时，该值与我 们设定好的固定值不同，那么直接执行停止并报错，以便于发现错误。
目前的一些测试竞赛中，会加入故意注入变异的方式，来评判测试代码能否发现 这些变异。
在安卓UI测试中，由于测试过程与单元测试完全不同，本文认为变异能否杀死， 取决于运行同样的代码时，在无变异的情况下能成功执行的测试代码，在变异后的应
用下能够仍然执行成功，如果执行失败了，那么说明杀死了该变异，反之那么没有检查到 该变异。
2.5 本章小结
安卓UI测试相较于Java测试而言，还相对并不成熟。人工编写代码进行测试虽 然可以到达较高的代码覆盖率，但是相对而言耗时较长。而自动化测试工具虽然用时 很快，但是并不能够到达一个非常高的代码覆盖率值。
由于安卓本身的碎片化问题，测试这一过程就需要考虑到许多针对特定版本的情 况，这也就使得安卓测试比起其他测试而言更加复杂。
况且，安卓框架也在不断进行更新，这也就意味着，如果不对测试代码，或自动 化测试工具进行持续不断的维护，就会产生引版本更新而无法使用的情况。本文认为, 现在的安卓UI测试仍然有可以开展的空间。对于人工测试，我们可以制作将人手动 点击的过程录制下来并转换成代码的工具。这种工具据本文所调查，已经有人正在研 究。而对于自动化测试工具，更加全面的考虑可能发生的问题，如对于登录页面，我 们可以提供输入，如果遇到了让程序崩溃的问题，我们也可以通过工具复现来解决等 等。总而言之，安卓UI测试目前还并不完善，但是如果能结合上述所说的各种方式， 相信未来的安卓UI测试一定会变得简单而又高效。
第三章人机对战框架的需求分析与概要设计
本章通过UML绘图的方法，讲述了人机对战框架的需求分析与概要设计，经 由用例图、类图、时序图等内容，具体的描述了人机对战框架的设计思想与使用实 例。
3.1人机对战框架工程的整体概述
为了能够使得安卓应用测试结果得到一个标准化的评判，本文选择自己实现一个 框架来到达这样的效果。但是人机对战框架的功能不仅限于此，人机对战框架的功能 主要是为了慕测信息科技的主平台所用。慕测主平台主要分为教育版与企业 版，在教育版的安卓应用分项中，学生通过提交安卓应用测试脚本来获取分数，而通 过人机对战框架，可以简化原本的流程。同时，该框架也用来进行人机对战比赛这一 活动。在2017年全国大学生测试大赛的安卓人机对战分项赛中，已经使用过该框架 的雏形，接着将对框架进行了不断的改进以增加新的功能。
人机对战框架的具体实现由五个局部组成：源代码修改、接收待测应用与测试代 码并执行测试、反响测试中获得的数据、对数据进行分析并计算得分、将所有详细结 果以及得分输出。这五个局部会分别在第四章中进行详细说明。
同时，据我所调查的，本文所介绍的人机对战框架，不仅是第一款用来进行人机 对战的框架，也是第一款意图于将安卓应用测试结果规范化的框架。并且，最重要的 一点是，框架的使用方法十分简单，只需要提供规定好的输入并修改几句配置文件, 整个框架的流程就能一键完成了，也就是纯黑盒完成。
本章中，先进行框架的需求分析与概要设计的介绍。
3.2系统需求分析用例图
用例描述对于上述用例图而言，我们可以做出以下用例描述

表3.1用户使用人工脚本测试
用例编号
001
编制时间
2018/4/13
前置条件
用户环境下安装了 Appium框架并且进行了正确配置且模拟器
或实机正确的连接上了电脑
基本领件流描述
用户更改框架中相关配置文件
用户输入相应命令以开始测试
系统进行测试，反响信息并分析信息计算分数
系统返回分数与详细输出
扩展事件流
2a、用户提供了无效的命令
2al、系统返回相应的错误提示
后置条件
无
特殊要求
无
用例说明
用户使用人工脚本测试的流程
表3.2用户使用人工脚本变异测试
用例编号
002
编制时间
2018/4/13
前置条件
用户环境下安装了 Appium框架并且进行了正确配置且模拟器 或实机正确的连接上了电脑
基本领件流描述
用户更改框架中相关配置文件
用户输入相应命令以开始测试
系统生成变异apk
系统进行变异测试，反响信息并分析信息计算分数
系统返回分数与详细输出
扩展事件流
2a、用户提供了无效的命令
2al、系统返回相应的错误提示
3a、用户提供的应用源码无法变异
3al、系统停止执行，返回错误提示
后置条件
无
特殊要求
无
用例说明
用户使用人工脚本变异测试的流程
表3.3用户为框架接入新的工具
用例编号
003编制时间2018/4/13
前置条件
无
基本领件流描述
用户对想要接入的工具进行修改
用户将相应的工具使用代码加入框架代码中
扩展事件流
无
后置条件
无
特殊要求
无
用例说明
用户为人机对战框架添加新的自动化测试工具

表3.4用户使用自动化测试工具进行测试
用例编号
002编制时间2018/4/13
前置条件
用户环境下安装了相应工具所需的环境并且进行了正确配置且 模拟器或实机正确的连接上了电脑。
基本领件流描述
用户更改框架中相关配置文件
用户输入相应命令以开始测试
系统进行测试，反响信息并分析信息计算分数
系统返回分数与详细输出
扩展事件流
2a、用户提供了无效的命令
2al、系统返回相应的错误提示。
2b、用户选择的工具不存在
2bl、系统停止执行，返回错误提示。
后置条件
无
特殊要求
无
用例说明
用户使用自动化脚本进行测试的流程

323系统顺序图
由于系统本身与用户之间的交互较少，主要在于系统本身的运行上进行了相当多 的运算，因此仅附上用例01的顺序图，其他用例与此基本相似。
用户使用人工脚本浏试底序图
图3.2用例01的顺序图描述
非功能性需求描述
本节描述了框架所需要的环境与非功能性需求。
人机对战框架的非功能性需求如表3.5所示，要求系统具有良好的健壮性、兼容 性与易用性。
表3.5非功能性需求表
名称
内容
非功能性需求类别
系统兼容性
框架在Windows或Linux系统下应当都
可以正常使用
兼容性
使用简易型
所有操作都应当可以一键完成
易用性
低出错率
系统本身的逻辑正确，不应当在用户输入
正确指令的情况下出错
健壮性
用户交互良好
在系统运行时，应当有信息被不断地输 出，防止使用者误解为系统无响应
易用性
人机对战框架所需要的环境如表3.6所示。
表3.6系统所需环境
环境耍求
具体内容
人工脚本测试要求
运行系统内必须安装Appium
人工脚本变异测试要求
运行系统内必须安装Appium,且拥有可运 行的MDroid+工具
自动化工具测试要求
运行系统内必须可以正常运行相应的自动
化测试工具
3.3系统概要设计类图
人机对战框架的类从用例描述入手，可以找到候选类：自动化测试工具接口、自 动化工具、系统、进行测试、返回结果、计算得分、执行人工脚本变异测试。它们之 间的关系如图3.3所小：
1.1.2 Interface 模块20Mutant Manage 模块21
4.2 Execution子模块的详细设计与具体实现21插桩22
4.2.1 执行测试28反响数据30
4.2.2 分析数据并计算得分31输出得分与详细报告32
4.3 Interface模块的的详细设计与具体实现32
4.4 Mutant Manager模块的详细设计与具体实现34
4.5 本章小结36第五章框架的评分标准与功能测试37
5.1 框架评分标准37
5.2 框架功能测试38应用选择38
5.2.1 人工脚本测试38人工脚本变异测试39
5.2.2 自动化工具测试41
5.3 本章小结42第六章总结与展望43
6.1 本文总结43
6.2 后续工作展望43参考文献45
致 谢错误!未定义书签。
进行测试(ManualTest)
-测试代码位置:String
-输出彳: String
+ 开启 AppiumServer(String): String
计算得分(GetPoint)
-场出位置:String
+ getHTMLPointQ： double
+ getExceptionPoint(String): double
返回结果(Feedback)
-应用源码位置:String
+获取插桩信息0
自动化测试工具接口
系统
0-1 : 0...*
+运行0
-String
- iS^iD: String
- appPackage : String
- 而用E詈:String
- log线程:Process
- 输出位置:String
自动化测试工具
-运行脚本位置:String
-工具位置：String
变异测试(Mutant Ex ecution)
+ 创业异(String]) + 创立 APK(String[]) +变异执行，Stimg[]) + 结果图3.3类图
开发视图图3.4描述了人机对战框架开发中的静态视图，即包图。使得框架的构架能够清
晰的被使用者理解。
图3.4开发视图

3.4本章小结
本章分为三个局部，分别是人机对战框架工程的整体概述、人机对战框架的需求 分析局部和人机对战框架的系统概要设计局部。第一局部描述了人机对战框架的编写 目的，使用场景以及使用案例。第二局部从用例图、用例描述、系统顺序图以及非功 能性需求的角度讲述了人机对战框架的需求分析内容。第三局部那么从整体上描述了人 机对战框架的结构设计，通过类图和包图展现了框架的实现方式。
第四章人机对战框架的详细设计与具体实现
本章通过介绍具体代码的方法，讲述了人机对战框架的详细设计与具体实现， 通过对插桩、执行测试、计算数据等核心代码进行讲解来说明人机对战框架的具体 运行过程。
4」框架子模块概述人机对战框架的流程几乎是线性的，图4.1展示了人机对战框架的工作流程，编 写时将框架分为三个大模块，分别是：Execution> Interface和Mutant Manage.每一个 模块都分工管理框架的不同局部。接下来本文会先简略的介绍每个模块，而关于每个 模块的详细设计与实现会在4.2节中进行具体描述。

计算得分

图4.1人机对战框架流程图Execution 模块
Execution模块顾名思义，作用是执行人工脚本测试与自动化工具测试，获取返 回的覆盖率、异常触发率等数据并计算得分与给出最终结果。同时，该模块也是人机 对战框架的主要流程。模块会先接收用户输入的信息，接着使用函数：
public void MnualTest.run() 方法来开始人工脚本测试，或使用
public void AutomatorTools.start()方法来开始自动化工具测试，这两个方法会自动翻开所需的后台软件，接着在连接的 手机上开始测试,直到测试完毕或者测试因为某些情况而中断时结束。当测试完毕后, 框架会调用函数：
public void Feedback.getEC()来获得测试的覆盖率数据与异常触发情况，并直接生成到用户先前输入的输出文件夹 中，因此没有返回值。接着使用函数：
public void CulculatePoint.generate()方法，从之前获得的覆盖率数据生成清晰可见的HTML文件与XML文件，其中包含 了详细的代码覆盖率信息。最后使用GetPoint类中的函数：
public double GetPoint..getHTMLPoint()
public double GetPoint.getExceptionPoint()两个方法来分别获取覆盖率分数与异常触发分数，就可以作为最终得分的依据了。
4.1.1 Interface 模块
Interface模块主要与自动化测试工具相关，由于自动化工具的数量十分的多，我 们不可能做到一一去为它们进行配置来使其可用，因此,编写了两个抽象类作为接口: AutomatorToolsDriver作为自动化工具的管理器，AutomatorToolsTest作为自动化工具 的生成器。为了实现同时在多台手机上进行测试，AutomatorToolsTest继承了 Thread 类，并且包含一个抽象函数：
public abstract void run()
正是Thread类中的run()函数的覆盖，其他工具接入时，需要在该函数中编写代 码使得自己的工具能够启动。
AutomatorToolsDriver那么是AutomatorToolsTest的管理器，其中包含三个抽象函数：
public abstract void start()
public abstract AutomatorToolsTest startTestTask()
public abstract void dispatchTest()
作用分别是开始整个测试、启动一个AutomatorToolsTest与开始测试前所需要做 的环境和数据的处理。这样做可能在连接多台手机时，获取所有连接着的手机的信息, 并且可以做到同时在这些手机上开始测试。
4.1.2 Mutant Manage 模块
该模块主要与变异生成与变异覆盖率获取相关，由于变异的流程较长，因此将这 个模块别离出主流程并进行单独的处理。
在该模块的流程中，如图4.1中最右侧的流程所示，我们需要先将源代码复制一 份备用，接着调用MDroid+工具〔⑵来生成变异后的代码，这一步由函数
public void mdpAutoPull.entrance.createMutant()
方法来完成，但是由于MDroid+只会生成编译后的代码，因此我们还需要通过函 数
public void mdpAutoPull.entrance.createApk()
来将这些变异过的代码一个个的加入之前复制后的源代码中并进行编译来生成 变异apk。接着使用函数
public void mdpAutoPull.autoExecutio.exec()
就会自动将这些apk安装到手机上并根据用户输入的测试代码来进行测试了。测 试完毕后，会输出日志，最后，根据这些日志，框架会使用函数
public void mdpAutoPull.autoExecutio.logMerge()
来将这些日志整合，就可以获知本次测试中有多少变异被覆盖到了。
4.2Execution子模块的详细设计与具体实现
Execution子模块主要包含了五个局部，从图4.1上可以看出，分为插桩、执行、 反响执行数据、计算得分与数据输出。本节会对这五个局部的详细设计与具体实现进 行一一讲解。
4.2.1 插桩
在本框架中，代码覆盖率是最为主要的得分依据，因此，首先要得到安卓应用的 源代码才可以进行测试。但是，虽然现在在学术界有一些可以对安卓应用程序进行反 编译以获取源代码的程序，现如今仍然有许多安卓应用程序是加了外壳的，这也就导 致工具的不可使用，因此，我们需要用户本身输入源代码给框架进行各种操作。
综上所述，我们需要为程序进行插桩［⑶，插桩是指，对代码中注入一些叫做桩的 代码，这些代码被运行到了之后，会进行某些操作，在测试完毕后这些代码的状态会 被返回到一个新建的文件中，只要分析这个文件，我们就能了解到测试的执行经过了 哪些地方，甚至于知道测试的流程是怎样的。在人机对战框架中，我们选择对将安卓 程序编译好后生成的.class文件进行插桩，由于.class文件是被源文件生成且可以被覆 盖的，这样做可以防止源代码被修改导致的不可恢复的问题。
那么首先就要来介绍一下Java字节码「⑷是什么。
Java字节码是通过javac (javacompile)命令或者其他IDE工具，将Java源文件 编译后生成的.class文件中的内容，由于该文件是放在Java自己的JVM (Java虚拟 机)中执行的，因此它使得Java实现跨框架运行的功能。
比方有这样一个简单的Java方法：
public static void try(){a()；
if(b()){c()；
}else{d()；
e()；
将其转换为字节码后，会变成:
public static try()V
//V指该函数的返回值简写
INV0KESTAT1C a()V // INVOKESTATIC 指调用一个静态方法

INV0KESTAT1C a()V // INVOKESTATIC 指调用一个静态方法
INVOKESTATIC b()Z
IFEQ LI
INVOKESTATIC c()V
GOTO L2
//IFEQ指当且仅当值为。时成立，即b()==0 〃b()不为0,执行c()
//函数的结束，继续执行后面的命令
L1:INVOKESTATIC d()V
L2:INVOKESTATIC e()V

L1:INVOKESTATIC d()V
L2:INVOKESTATIC e()V
〃b()为0,执行d()
//if结束，执行最后的e()

RETURN
完整的Java字节码文件中还包含有魔数(magic number),版本(version)等信 息，和插桩本身无关因此暂时不作介绍。
而插桩那么是在这些指令中根据一个既定规那么加入指令，具体实现过程仍然以上述方法为例，如图4.2所示:
RETURN
图4.2java代码、字节码与插桩后比照
表4」探针注入的执行流程图
种类
汪入刖
注入后
备注
序列

在一个简单的序列 情况下，在所有语句 之中注入一个探针 即可。

语句A

语句A

语句B

P

语句B
无条件跳转

在无条件跳转中，和 序列一样，是一定会 执行的，因此在 GOTO指令前注入 一个探针即可。

GOTO
<—

P

语句A

GOTO
—

语也
<

有条件跳转
(ifA() >-
—

4

在有条件跳转中，由 于需要了解测试过 程究竟经历了哪一 侧，因此两边需要各 注入一个探针。

语句B
4-

P

语句C

语句B

P

f

语句C

具体的插桩方式通过Jacocot151, 一款已经存在多年且仍然在不断更新的著名代码 覆盖率检测工具来进行完成，该工具使用ASM3.0的接口来进行实现，ASM3O⑹是 一个专门对Java字节码进行操作的APL通过使用该APL我们可以做到对Java字 节码的增加、删除、修改等操作。Jacoco会在四种情况下进行插桩，如表4.1所示。
这四种情况包含了所有字节码中可能出现的情况，而且比每一句字节码都插桩要 节省空间，故而选择这种插桩方法。
在插桩的类文件中，会先设定好一个布尔数组，在P处放置与该数组对应的代 码，如果P处被执行到了，那么该布尔数组的对应位置那么会被设定为true。当测试指 定完毕后，只要检测该布尔数组，那么可以知道对应处的执行情况。
摘要
近年来，在互联网的带动下，使用智能手机的人数越发上涨，安卓与IOS也成为 了移动应用的主体。其中安卓平台的开展更为迅速，2017年11月1日，美国市场研 究机构NPD Group说明，安卓在美国智能手机市场上的销量份额首次超过IOS。也 正因如此，市场对安卓应用的要求不断提升，开发人员需要提供高品质的应用才能满 足用户的需求，对安卓应用的测试便成为了开发应用中的一个关键流程。
但是，测试结果本身的好坏，其实是难以判断的。所有的测试用例都通过了，并 不代表应用的所有问题都被发现了，更何况，使用不同的测试方法，由于他们的测试 过程不同，所得到的结果也会完全不同，这就使得这些结果相互之间不可比拟。因此， 为了使得安卓测试的结果有一定的可比性，本文提出了一种能够标准化安卓应用测试 结果的框架，主要用于在人机对战中能够给出一个可比的结果。本平台通过代码的各 种覆盖率、日志中的异常信息、变异的执行情况等方面进行结果的评判，最后给出所 有的详细生成结果与最终得分。与此同时，使用该框架中接入的工具对多个安卓应用 进行测试，得出的结果与己有论文中所述的结果基本相同，证明了框架的可靠性。
关键词：安卓测试；自动化测试；人机对战；安卓变异
该方法的具体实现，需要人工手动完成。首先要将Jacoco引入到待测应用的项 目中。Jacoco官方提供了一份生成覆盖率数据的代码，其中包含方法：
task jacocoTestReport(type: JacocoReport) {group = nJacocoReportn
description 二 H Generate Jacoco coverage reports after running tests.n reports { xml.enabled = true html.enabled = true)
classDirectories = fileTree( dir: *./build/intermediates/classes/debug1, excludes:
,**/*$InjectAdapter.class\
'**/*$ModuleAdapter.class', ‘**/*$ViewInjector*.class' ])sourceDirectories = files(coverageSourceDirs)
executionData = files，' $buildDir/outputs/code-coverage/coverage.ec'')doFirst {
new File(n$buildDir/intermediates/classes/n).eachFileRecurse { file -> if (file.name.contains(,$$,)) {
file.renameTo(61e.path.replace('$$', $)) ) ) ) )
该方法会扫描当前状态下，类中之前插入的布尔数组的信息，来判断有多少桩已 经被覆盖了，并生成一个.ec文件，其中包含了这些信息。该文件是二进制文件，在 查阅了 Jacoco官方文档后，本文将这些内容按一定规范输出，可以看到如图4.3所示 的内容：
1 version:e
2 id:unknownhost-a8bea922
3 6id:
7 name:com/white/bihudai1y/module/splash/SplashActivityprobes[0]:true
8 probes[1]:false
9 probes[2]:false liprobes[3]zfalse
12 probes[4]:false
13 probes[5]zfalse
14 probes[6]zfalse
15 probes[7]:false
16 probes[8]:false
17 probes[9]zfalse
18 probes[10]:false
19 probes[11]zfalse
20 probes[12]:false
21 probes[13]zfalse
22 probes[14]:false
23 probes[15]:false
24 probes[16]:false
25 probes [17]:false
26 probes[18]:false
27 probes[19]:false
28 probes[20]:false
29 probes[21]:false
so probes[22]zfalse
31 probes[23]:false
32 probes[24]zfalse
33 probes[25]zfalse
34 probes[26]zfalse
35i name:com/white/bihudaily/app/BihuDai1yApplication
36 probes[0]:trueprobes[1]zfalse
37 probes [2]:trueprobes[3]:true
图4.3 ec文件内容
而接下来的一步是需要手动完成插桩工作的原因。由于jacocoTestReport方法需 要被触发才能执行，因此我们必须将该方法加入到应用源代码的Acticity相关的类的 代码中。即当用户触发Activity中的某个方法时，Jacoco才能生成这样一份覆盖率信 息。但是单纯的将方法放入Activity中的Ondestry。方法，会因为某些未知的原因导 致该函数并不会被执行到。因此目前的方法是自动化的将jacocoTestReport方法加入 到每一个Activity文件中的每一个函数的开头。
这样做其实是有弊端的，如果每一个操作都会进行数据的生成，会导致交互速度 变慢，生成大量无用文件等问题。因此这是一个仍需解决的问题。
但是以目前的方法来看，将jacocoTestReport方法加入到每一个函数的开头确实 是有效的。只是因为弊端较大，因此没有将该过程的自动化加入到框架中。
执行测试
由图4.1可知，人机对战框架的执行可以分为人工代码执行和自动化测试工具执 行两局部。
为了保证框架使用的简易型，我们已经将测试代码的执行简化为输入一句代码即 可执行的一键化流程。
对于人工编写的测试代码，由于Java的自动化编译与执行需求工程的引入包的 固定，因此我们要求待测代码的工程格式与我们的要求相同，同时，使用Appium作 为自动化测试的框架，因此用户的电脑上必须将Appium环境配置完毕，准备完全后， 用户只需要提供测试代码的位置、待测Apk的源码位置、待测Apk的位置等相关信 息输入框架，框架就会自动执行本次测试并给出结果。
对于自动化工具而言，首先需要接入我们提供的接口，该接口允许代码编写者执 行一个脚本来启动相应的工具，所有的参数只需要在脚本中调整完毕即可。接着，使 用者只需要提供自己想选择的，且框架中已接入的工具的名称和待测Apk源码位置、 待测Apk的位置等信息，框架就会自动执行本次测试并给出结果。
执行的具体实现主要由类ManualTest与类AutomatorToolsDriver来完成，后者属 于Interface模块，因此暂时不作介绍。而前者主要分为三个局部，执行前置操作、执 行与执行后收尾处理。
appium -a 127.0.0.1 -p $1 -U $2 -log-level info:error -log $3 -session-override -bp $5 | tee $4
public void setupAppium(String outputdir ,String devicelD, String logCatPath, String appiumLogsPath, String exceptionLogsPath) throws InterruptedException {Process process = null;
int dp = (Integer研port) + 100);
String command = cmd + " Commands/linux/appium.sh " + port + ” “ + devicelD + ” ” + exceptionLogsPath+ n " + appiumLogsPath + " " + dp;System.owtprintln(command);
r.exec(command);
)
上述代码为启动Appium服务的一局部代码节选，人工脚本测试中，框架首先需 要自动启动Appium来保证测试可以执行，上述代码会启动Appium服务,并将Appium 输出的日志放置在用户输入的输出文件夹中。
接着，使用类似的方法，我们也会将手机的日志信息输入到输出文件夹中：
adb -s $1 logcat -c # clear buffer
## select the application pid and ActivityManager , ActivityThread
adb -s $1 logcat -v long > $2
public void startCaptureLog(String deviceTD){command=cmd+" "+"Commands/linux/logcat.sh "+deviceID + " " + logPath;
log