Android是一种流行的移动操作系统,具有最大的市场份额。Android OS不断发展,市场上存在各种Android版本。此外,设备制造商通常会定制原的Android OS来实现各种功能以吸引客户。这些现象使得Android生态系统严重碎片化,从而使Android开发人员很难测试其Android应用程序的兼容性。因此,现实生活中许多Android应用程序都存在各种兼容性问题,这可能会严重影响用户体验。兼容性问题已经引起了学术界广泛的关注。为了解决这个问题,研究人员提出了许多静态分析工具,例如Fic Finder和Ci D。但是,这些技术有一个共同的局限性:它们会生成许多错误警报。测试是一种为了检测程序错误而广泛使用的技术。但是,由于搜索空间爆炸问题,对Android应用程序执行兼容性测试具有不少挑战。首先,要测试的设备型号太多。市场上有来自1,200多个制造商的24,000多种不同的设备。其次,要测试的API版本太多。由于Android平台发展迅速,市场上的设备运行的API版本有十多种(从10到29)。第三,要测试的API调用点太多。我们分析了API版本28的Android SDK的源代码,结果显示,SDK中大约有220,000多个方法。自动兼容性测试的一个直观的方法是在一个设备(例如,具有Android原生OS的设备)上生成测试,并在具有各种API版本的其他设备上重复执行测试(重放),以识别不一致之处。不幸的是,由于上述挑战的存在,进行这种详尽的测试是不切实际的。在本文中,我们提出了一种适用于Android应用程序的实用兼容性测试技术。我们的基本想法是:Android应用程序中的兼容性问题通常是由Android平台演变和操作系统定制引起的;在测试期间,我们只需要执行可在不同设备型号和API版本触发定制的系统代码或演化的框架API的测试即可,其他测试几乎没有机会触发兼容性问题。为了自动测试Android应用的兼容性,我们首先需要确定两种类型的API,称为目标API。第一种与定制系统有关,我们通过对比具有代表性的三星手机系统和原生系统来找出手机厂商经常定制的文件的位置。我们通过分析SDK中的调用关系找出SDK中所有可以调用到定制代码的API,这些API作为第一种目标API。另一种与Android平台的演化有关,我们分析了API版本21到28之间的SDK,通过分析相邻版本之间的差异确定了由于SDK演化而引入和删除的API,我们把所有的这种API放入一个集合,作为第二种目标API。然后,我们设计并实现了第一个用于测试Android应用程序兼容性问题的框架,GTFC。GTFC将生成触发目标API的兼容性测试并且在不同的设备池中进行测试重放来检测是否存在兼容性问题。该框架包括四个阶段:(1)插桩阶段:此阶段的目标是确定应用程序运行测试时,测试是否触发目标API。在此阶段,GTFC将对应用程序进行静态分析。它将在调用目标API的位置之前插入特定的语句。在后续测试生成阶段中,该语句将在应用程序触发目标API时,将该API调用事件写入日志文件。(2)测试生成阶段:在此阶段,GTFC将通过驱动通用测试工具来生成测试。这些测试称为常规测试。后续的兼容性测试将通过对常规测试进行选择和优化来生成。在驱动通用测试工具时,我们可以通过设置参数来控制常规测试的数量及其其长度限制。可供选择的常规测试工具有很多,我们通过对不同测试工具进行对比研究,最终选择了使用Appium来生成常规测试。Appium是基于控件进行操作的,不同于其他基于坐标的工具,比如Monkey。这一特点能够保证生成的兼容性测试可以在其他设备上进行重放。(3)兼容性测试合成阶段:在此阶段,GTFC将通过分析第二阶段的日志文件来生成兼容性测试,具体包含两个步骤:测试用例选择,测试用例优化。在第一步中,GTFC将选择合适的测试用例。如果某一日志文件包含目标API调用事件的记录(在第一阶段中提到),这意味着这一测试会触发目标API。这一测试将会被选择。在后面的步骤中,选定的测试将被处理(剪切和添加事件)作为兼容性测试。这里,一个测试指的是一个序列的操作。剪切指的是只选取从第一个操作到触发目标API的操作这一段子序列。添加是指我们会在这一操作系列后面添加操作来获取操作序列完成之后的设备状态。这里的状态指的是当前的UI界面。在此阶段之后,我们可以获得对应于两种目标API的两种类型的兼容性测试。最后我们将对这些测试进行筛选。首先,我们会去掉那些长度太短的测试。其次,我们将第一步筛选剩下的测试在用于生成测试的机器上进行测试重放,重放失败的测试将会被移除。需要注意的是,在进行测试重放时,我们会将测试重放一定次数,如果在一定次数内重放不成功,则被视为重放失败。原因是重放过程会受到网络时延和其他环境因素的影响,一次重放不成功不能说明该兼容性测试是无效的。(4)测试重放和问题检测阶段:对于测试重放,GTFC有两个设备池可重放生成的兼容性测试。一个包含不同供应商的设备。另一个包含具有不同API版本的设备。上一阶段生成的兼容性测试将在相应的设备池上重放。最后,GTFC将比较不同供应商和不同API版本的重放结果,并检测是否存在兼容性问题。对于兼容性问题检测阶段,GTFC定义了一个两级的判断标准来确定是否发生了兼容性问题。第一级判断是检测是否存在崩溃(或闪退),如果存在应用直接崩溃的现象,就认定在该设备出现了兼容性的问题。没有出现应用崩溃现象的设备将进行第二级的判断。第二级判断是检测是否存在不同的UI布局。如果存在,则说明有兼容性问题出现。为了评估GTFC的可行性,我们首先开发了20个Android应用,并植入了一系列兼容性问题。具体来说,我们让其中10个应用程序调用Android版本演化而引入的API,但是不检查当前设备的API版本。这会造成向后的兼容性问题:当这些应用运行在拥有低版本的操作系统的设备上时,它们会直接崩溃退出,原因是在这些低版本的操作系统上不存在后续版本才引入的API。另外的10个应用程序则是分别触发了那些经常被厂商所定制的硬件,照相机,蓝牙,GPS,等等。随后,我们使用了GTFC对这20个应用进行兼容性测试。我们的预期结果是对前10个应用程序,GTFC会生成触发预先插入的目标API的兼容性测试,对后10个应用程序,我们的预期是GTFC会生成触发那些与定制化硬件有关的API的测试。实验结果符合我们的预期,对这20个应用程序,GTFC都可以生成兼容性测试用例触发到相应的API。为了验证GTFC的可用性,我们使用GTFC测试了766真实的Android应用程序,GTFC检测到了8个新的兼容性问题。其中的3个兼容性问题的表现是在某些设备上崩溃,剩下的5个兼容性问题表现为该应用程序在不同的设备上的UI界面有差别。具体表现为字体,图标大小,颜色,图标间距以及弹窗的不一致。这说明GTFC可以发现真实应用程序上的兼容性问题。此外,为了验证GTFC的高效性,我们统计了生成的兼容性测试用例所包含的事件数占常规测试事件的比例。结果表明兼容性测试用例所选择的事件的数量在每个应用上平均占比为10%,即平均减少了90%的事件。我们将本论文的贡献总结如下:(1):GTFC是第一个用于自动测试Android应用程序兼容性问题的框架。现在虽然存在许多针对Android应用的测试工具,但是它们都不不是专门针对兼容性问题的。GTFC可以很好地和通用测试工具进行整合,高效测试Android应用中潜藏的兼容性问题。(2):我们详细介绍了GTFC的四个阶段的工作原理和细节,并阐述了所涉及的算法。(3):我们开发了20个应用程序用于评估GTFC。结果表明,GTFC是测试Android应用程序兼容性的有效工具。我们在真实Android应用上的实验结果也说明GTFC可以帮助发现兼容性问题。