移动应用GUI模型生成及其测试研究文献综述

文献综述（或调研报告）：

Android应用自动化测试有许多方法，根据测试用例的生成方式不同，我们可以将Android应用的自动化测试方法分为基于随机策略的测试方法、记录重放的测试方法以及基于模型的测试方法。在此着重说明基于模型的测试方法。

基于模型的测试方法可以将Android应用抽象的状态空间转为具体的应用GUI模型，就可以由对Android应用程序的测试转为对GUI模型的测试。GUI模型可以通过静态代码分析或动态搜索Android应用状态空间生成，生成的模型可用于构建一组测试用例来测试Android应用。

Amalfitan等人提出了一种通过GUI自动测试Android应用程序的替代方法，该方法利用树模型来描述Android应用状态空间，树的节点表示Android 应用中的各个用户界面，节点之间的连线表示界面间进行跳转的触发事件。在模型生成过程中通过对比事件执行前后界面中的控件属性、控件注册的动作处理函数是否相同来更新模型。虽然树模型结构清晰，但该模型展现的界面变迁关系比较单一，无法全面地描述现今 Android 应用的复杂行为。因此人们提出利用有向图描述 Android 应用状态空间，使用动态搜索方法对 Android 应用进行建模。动态搜索方法可以自动触发界面控件，并使用不同的搜索策略构建 GUI 模型。其中，使用最广泛的是基于深度优先的模型搜索策略。

Yang W 等人开发的工具 ORBIT 首先通过对 Android 应用源码进行静态分析来标记界面中所有可触发控件，然后使用深度优先搜索策略生成 GUI 模型，并采用 Amalfitano D 等人提出的界面相等判定方法更新GUI模型。Amalfitano D 等人开发的工具 MobiGUITAR 利用深度优先搜索策略动态地从Android 应用的入口 Activity 进行搜索，通过对当前界面控件的模拟执行来生成 GUI 模型。当界面中的所有事件均已执行时，MobiGUITAR 会重启应用回退到入口界面进行搜索。

Azim T 等人开发的工具 A3E 使用两种完全不同的搜索策略生成 GUI 模型：目标优先策略以及深度优先策略。目标优先策略首先对应用的配置文件 AndroidManifest.xml 进行分析得到所有的入口 Activity，并以这些入口 Activity 为初始节点对应用进行建模，达到快速覆盖应用状态空间的目的。 深度优先策略则直接通过执行界面中的事件生成模型，建模过程虽然较慢但是可以实现较高的代码覆盖率。

除基于深度优先的模型搜索策略外，人们也提出了其他不同的策略构建 GUI 模型。Tianxiao Gu 等人开发的工具 AIMDROID 首先以 Activity 为节点，使用广度优先搜索策略对 Android 应用进行搜索，并生成简单的 GUI 模型。然后针对模型中的每一个 Activity 进行深度拓展，搜索出 Activity 中不同的子界面，同时完善 GUI 模型。

Su T 等人开发的工具Stoat通过动态分析与静态分析相结合的方法来生成 GUI 模型。在动态分析阶段获取界面中可执行的事件，并根据事件类型和事件执行次数计算事件权重。在静态分析阶段解析应用程序源码来获取界面控件中其他未被检测到的可执行事件，以此确保生成初始 GUI 模型的完整性。然后对初始GUI模型进行迭代更新，在每次迭代过程中会随机挑选目标界面，对目标界面中的事件权重进行修改，并根据修改后的模型生成测试用例，执行这些测试用例并统计测试数据， 并使用马尔科夫链蒙特卡罗算法，根据每次迭代生成的 GUI 模型实现的代码覆盖率得到一个近似最优的 GUI 模型作为最终结果。

Y.M.Baek等人提出的多级GUI比较标准，其中C-Lv1以package为判定标准，C-Lv2以activity为判定标准，C-Lv3以layout为判定标准，C-Lv4以控件为判定标准，C-Lv5以控件内容为判定标准。不同级别的比较标准可以生成复杂程度不同的GUI模型，比较级别高，生成的GUI模型更详细，代码覆盖率更高。但级别过高的比较标准可能或导致无用的GUI模型节点，并且可能会造成GUI模型爆炸问题。测试人员需要根据不同的应用程序确定最合适的比较级别

四、方案（设计方案、或研究方案、研制方案）论证：

现有工具FectDroid提供了处理相似控件、如何解决界面回路、判断两个界面状态是否一致的方法，以下简述其方法的大致思路

1.如何判断相似控件

在 Android 应用界面中，如果若干控件具有相似的属性值并且注册了相同的动作处理函数，那么这些控件称为相似控件。如果直接处理界面相似控件，将搜索到大量重复路径，且不会发现新的界面状态。FectDroid提出了相似控件判定准则：如果若干控件属性 resource-id、class、 package、clickable、long-clickable 的值以及根据 bounds 属性计算出的控件大小相同时，则认为这些控件是相似的。对于这些相似控件，只选择其中一个进行处理，而无需处理全部。

2.解决界面回路

对于模型中存在回路问题，在搜索过程中使用一个记录栈，栈中保存了从初始界面状态到当前界面状态的访问序列，若搜索到的界面状态已存在于记录栈时，则表明模型中存在一个回路，此时搜索策略会通过判断记录栈中的栈顶界面状态是否还存在未执行的事件，若存在则返回至栈顶界面状态继续搜索，这样便可以解决界面回路导致界面状态丢失的问题。

3.判断界面相等

对于界面相等的判定，考虑兼顾界面ActivityName和界面控件来对界面进行相等判定。首先通过比较界面ActivityName对不同Activity中的界面进行区分。对于在同一 Activity中的界面，文本编辑控件对界面布局结构影响较大，因此首先通过比较界面中的文本编辑控件对界面进行区分，如果两个界面文本编辑控件相同，那么计算两个界面中相同的可触发控件的占比，并与预设的阈值比较，若占比不小于阈值，则说明两个界面相同。

对于GUI五级比较标准（GUICC）的设计方案举例论述如下：

如图1所示，假设现有一待测试的Android应用程序（APP），该app含有两个包，每个包下有数个activity，activity中有数个layout以及多个控件。以不同级别的比较标准生成的GUI模型见图2-5。

图1某待测Android应用程序的模拟结构实例

当比较级别为1（C-Lv1）时，GUI节点以Android应用程序的包名为基础,生成模型时不断遍历应用程序的GUI，不同的包名创建GUI节点，并记录产生新节点的触发事件e1作为边。

图2 C-Lv1生成的GUI模型

当比较级别为2（C-Lv1）时，GUI节点以activityName为基础，生成模型时比较新界面与先前界面的activity是否为同一个activity（通过比较activityName），记录新生成的GUI节点，并记录触发事件。

图3 C-Lv2生成的GUI模型

当比较级别为3（C-Lv1）时，GUI节点以layoutID为基础，生成模型时，以当前界面下的所有布局ID生成GUI模型节点，注意同一个界面状态中的layout节点要以ε边为连接。以ε边连接的节点表示这两个节点同级，处于同一个界面状态下。若不以ε边连接同级节点，有可能导致生成的GUI模型不连通，如图4中Layout C1和Layout C2同在activity C下，并属于一个界面状态，若不以ε边连接，则会造成该GUI模型不连通。在记录引起界面变迁的事件时，要注意记录该事件所属的控件ID，判断该控件位于哪个layout中，才可以准确生成GUI模型。

图4 C-Lv3生成的GUI模型

当比较级别为4（C-Lv4）时，GUI节点以当前界面状态下控件的可触发事件为基础，判断是否生成新节点：界面状态、LayoutID、可触发事件类别，只要任一条件不同，均视为新节点。同样，以ε边连接处于同一界面状态下的控件，每次跳转到新的界面状态都要记录触发事件的源控件以保存边。

图5 C-Lv4生成的GUI模型

当比较级别为5（C-Lv5）时，GUI节点以控件的内容为基础，情况类似C-Lv4。在判断是否为新节点时比较界面状态、LayoutID、可触发事件类别、控件的内容长度，在此不再累述。

由于C-Lv2相比C-Lv1、C-Lv4相比C-Lv3更为详尽，而C-Lv5过于详尽容易导致GUI模型爆炸问题，因此，本课题选择实现C-Lv2和C-Lv4，即基于activity的判定标准和基于控件的判定标准。在GUI模型生成的过程中，支持用户以C-Lv4的节点替换某些C-Lv2的节点，以形成更加详细的GUI模型。为此，需要记录每个触发activity跳转的事件以及源控件信息，记录控件与activity的从属关系。在实现C-Lv2时，判断两个GUI节点是否相同，只需要比较两个节点的activityName是否相同；在实现C-Lv4时，需要比较界面状态、控件类别以及控件的可出发事件，三者均相同才可认为属于同一GUI节点。

整体方案有以下三种：

①对应用程序进行二次探索，先以C-Lv2为判断标准进行GUI模型生成，再以C-Lv4为判断标准进行第二次GUI模型生成。两次GUI信息生成后再根据测试人员的需求进行模型构建。

②仅对应用程序进行C-Lv4的探索，当GUI信息生成完毕后，再根据各节点所记录的从属activityName，来生成C-Lv2的GUI模型信息。

③仅对应用程序进行C-Lv2的探索，当GUI信息生成完毕后，再根据测试人员的需求，对某些activity进行针对性的探索。

方案一对应用程序某些activity进行的没必要的二次探索，方案二和方案三均可选。而方案二相对于方案三来说实现相对方便，因此选择了方案二作为本次开发的整体方案。

由上对GUICC五级的设计方案所述，并且获取界面状态、获取控件信息、触发控件事件、记录触发事件等核心操作均在工具FectDroid以及uiAutomator有参考，因此，认为上述讨论方案理论可行。

五、进度安排：

起止日期 工作内容

2018-12-20至2019-01-24 课题选择和确定

2019-01-18至2019-03-04 阅读相关文献，同时熟悉开发工具和技术

2019-03-04至2019-03-28 确定开发范围和主要内容，完成开题报告

2019-03-28至2019-05-01 设计完成和实现，主要完成文档和代码编写及测试

2019-05-01至2019-05-30 完善实验，撰写论文