本文主要是介绍【腾讯TMQ】专治时间长 —5分钟测试Android覆盖安装，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
专治时间长 —5分钟测试Android覆盖安装
作者：TMQ 邓曦
一、痛点
覆盖安装测试，作为一项基本的测试类型是不可或缺的。它存在的主要价值：验证老版本覆盖升级到新版本，用户和系统数据能够正确迁移，以及保障用户升级后的功能可用性。
但是说他痛在什么地方呢？
需要测试的版本多
每个版本需要覆盖的用例多
二、解决方案
2.1 思路
从哲学上说，任何事物都是发展变化的。我们需要在“变化”中找寻“不变”的本质和规律。在覆盖安装过程中，我们也要找到“不变”的部分，那就是我们能够“减少工作量”的地方。
例如：某APP1.0版本覆盖升级到APP2.0版本。
在这个过程中哪些是不变的部分呢？
- 程序代码
了解Android覆盖安装的同学都知道，覆盖安装后，APP1.0版本的程序代码，完全更新为APP2.0版本的程序代码。但是，这种变化会在“迭代”测试中完全保证。因为“迭代”测试中“全新安装”APP2.0程序代码和“覆盖安装APP2.0程序代码”是相同的。
- 用户数据
用户数据—用户使用APP过程中产生的数据。例如：用户使用“浏览器”打开了www.qq.com, 那么浏览器访问历史中的www.qq.com就是用户数据。很显然，用户数据在覆盖升级的过程中不应该被改变。不仅如此，升级后的用户数据必须能够正常访问使用。这样才能保证用户在APP覆盖升级后使用的连贯与一致性。当然，这是理想的情况，在覆盖升级过程中用户数据也有可能发生变化。
很显然，（1）如果“用户数据（不变部分）”，能够保证在覆盖升级后正常访问使用，这部分测试工作量就能被释放。（2）针对“用户数据（变化部分）”，测试人员需要人工介入确认是否是问题。
现在的主要问题就变成了：如何保证“用户数据（不变部分）”的功能正确性？
【论据1】APP1.0覆盖升级为APP2.0后程序代码=全新安装APP2.0的程序代码。（成立）
【论据2】APP2.0在全新安装状态下，“迭代测试”需要对主要功能进行“地毯式”的功能测试。只要使用“用户数据（不变部分）”作为测试数据，功能正确性就已经得到了保证。而在很多测试组，也确实就是这样做的。（成立）
【结论】“用户数据（不变部分）”在覆盖升级后，不需要测试。（成立）
有了这个结论，我们就能把主要精力放在区分“用户数据”的变化和不变部分。要找到用户数据变化，那就需要进行对比。例如：覆盖升级前用户数据是[1、2、3],覆盖升级后用户数据变为[1、2、5、6]，那么变化的用户数据就是[5、6]。下面将要介绍三个测试维度对比。
2.2 三个测试维度
在上节思路指导下，我们采用了如下三个维度的对比用户数据。 我们还是以某APP1.0覆盖升级到APP2.0为例子。
用户数据A/B/C中都分别包含了：
Sqlite数据库文件
Shared preference配置XML文件
文本和二进制文件
那么通过对用户数据A/B/C进行不同的对比，可以得到不同的结论。从覆盖类型上看，我们可以分为Struct、Data、Scale三个维度类型。
2.2.1 Struct对比（校验升级代码）
Struct对比数据B（1.0升级到2.0版本后data目录）和C（全新安装2.0后data目录），来验证“验证升级代码逻辑”正确性。正常情况下，B和C中所有sqlite数据表结构、配置XML文件结构、文本和二进制文件应该保持一致。如果不一致，就证明在1.0升级到2.0的升级代码中有bug， 使得1.0升级到2.0后结构，无法和2.0全新安装保持一致。这种不一致可能存在三种情况：
- 结构新增
例如：B中的switch表
C中的switch表
很明显是1.0升级到2.0的时候，对switch表升级代码漏掉了增加一列phone的操作。但是在2.0全新安装的时候， 在switch表确增加了phone字段。这就是我们要寻找的Bug。关于这里的数据表中的值， 都是应用启动后默认的值。
- 结构修改
例如：B中的switch表数据类型
C中的switch表数据类型
很明显是1.0升级到2.0的时候，对switch表升级代码漏掉了更改name字段类型的操作。但是在2.0全新安装的时候， 在switch表确name字段修改为了Text类型。这也是我们要寻找的Bug。
- 结构删除
例如：B中的switch表
C中的switch表
很明显是1.0升级到2.0的时候，对switch表升级代码漏掉了删除列name的操作。但是在2.0全新安装的时候， 在switch表确没有name字段。这种删除表的情况比较少，一般来说都是增加和修改。
2.2.2 Data类型（数据内容对比）
Data数据对比A（1.0全新安装并且插入数据后data目录）和B（1.0全新安装并且插入数据后升级到2.0版本后data目录），来验证“升级过程中数据变化”。这里的“插入数据”是指应用启动后插入样本数据。例如：浏览器的访问Bookmark表中制造一些样本数据，方便检验数据迁移的过程。
制造样本数据主要有两种方法：
- 数据导出法
通过手工操作应用，先制造样本数据。例如上例中，手动打开浏览器点击“新浪网”。然后通过sqlite工具导出访问历史表中的数据保存。在下一次测试的时候， 在进行导入。
- API调用法
通过应用预留的API接口，可以直接进行数据插入。当然，这个和具体应用的可测性结构有关。
- 自动化脚本法
通过GUI自动化脚本，在应用界面模拟人工操作制造数据，也是一种不错的方法。
当数据A和B对比完全一致
我们基本可以认为数据迁移是正确的。为什么呢？因为如果A和B数据完全一致，那么在从1.0覆盖升级到2.0数据也应该是可用的。但是，如果出现2.0使用数据失败，那么这种问题在2.0版本的“迭代”测试中可以发现，而不属于“覆盖安装”的范畴。所以可以认为只要A和B数据完全一致，数据迁移就是正确的。
在数据A和B对比不一致
这种不一致并不能完全认为是错误的，这个需要测试人员同开发人员共同确认是否是Bug。分为三种情况：
- 数据修改
这是我们首先要搞清楚的问题，如何判定是数据修改，而不是数据删除和新增呢？例如：
A中的Bookmark表
B中的Bookmark表
从数据库数据分析角度，可以认为id=1,id=2,id=3的数据被删除，然后从新插入了id=4,id=5,id=6的数据。这种情况从业务上看，显然url字段保持不变，id发生了变化，我们可以认为是修改。最后，我们采纳了这是修改的建议。因为，这样更符合业务情况，使测试人员对结果的判断上更加简单。
但是，修改的判断规则是如何定的呢？我们来看一下Bookmark表中的结构。
一般来说，Unique Constraint约束的字段在表中都是联合主键。所以我们判断修改的算法是：
“主键”或者“联合主键”其中二者满足其一，就认为是修改的数据。
- 数据新增
有了判断数据修改的规则， 数据新增判断就很简单了。
- 数据删除
有了判断数据修改的规则， 数据删除判断就很简单了。
2.2.3 Scale类型（测试关注点对比）
Scale类型对比A(全新安装1.0版本data目录）和C（全新安装2.0版本data目录），目的“从数据层面观察两个版本差异， 给系统测试人员以指导”。例如：1.0版本没有bookmark表，但是2.0版本中出现了bookmark表，就证明2.0新增了bookmark相关功能，需要提醒测试人员注意。
那么以上三个维度测试是如何实现的呢？请继续往下看。
2.3 自动化实现
体验地址: http://10.20.73.81:8080/OverrideTest/testAction!login
体验用户：ciro
体验密码：123
Note： 要创建测试任务，请注册自己的专用帐号。
步骤说明：
1.用户输入APP的“最近N个历史版本APK包”和“最新版本APK包”。例如：N=2
历史包：1.0、2.0
最新包：3.0
循环2次：
第一次：1.0->3.0
第二次：2.0->3.0
2.系统将用户上传的APK包下发到测试手机。
3.虽然可以一次上传多个“历史版本APK包”，但是系统中一个任务只包含：一个“历史版本APK包”和一个“目标版本APK包”。很显然，N个历史版本就会建立N个测试任务。在测试手机上“全新安装”一个任务的历史版本APK包。
4.启动APP。
5.如果有样本数据的自动化脚本，这里将会进行样本数据插入。
6.拉取APP的Data目录下所有内容A。
7.不卸载“历史版本APK”， 直接覆盖安装后的“最新版本APK”。
8.启动覆盖安装后的APP。
9.APP启动后，需要激活升级逻辑（参考：升级逻辑触发）。
10.拉取APP的Data目录下所有内容B。
11.将用户上传的APK包下发到手机。
12.卸载已经安装的APP，然后全新安装“最新版本APK”。
13.启动全新安装“最新版本APK”。
14.拉取APP的Data目录下所有内容C。
15.将Data目录A和B输入文件对比模块进行对比（参考：Data类型对比）。
16.将Data目录C和B输入文件对比模块进行对比（参考：Struct类型对比）。
17.将Data目录A和C输入文件对比模块进行对比（参考：Scale类型对比）。
18.文件对比模块，将输入的sqlite文件、xml文件、文本文件和二进制文件进行对比。
19.保存对比的结果到DB。
20.用户收到测试报告。
三、项目实战
3.1 经典实例
应用宝
历史版本：4.1、4.1.1、4.2、4.4、4.5、4.6、5.0、5.1
最新版本：5.2
测试类型：struct对比（验证升级代码）
发现问题：
“全新安装5.2版本”和“任意1个历史版本升级到最新5.2版本”对比，数据库新增了一张表switch_phone_table。也就是说，升级逻辑代码漏掉了生成switch_phone_table表代码。
经过和测试人员沟通，发现这个表是应用宝“换机助手”的数据表。由于缺少了switch_phone_table，“面对面换机”在完成资料发送后，不会出现“换机报告”几个字，也无法点击。
最后测试人员确认是覆盖安装Bug。这个Bug其实隐藏的很深，普通测试路径不容易覆盖到，但通过数据层来看，就很容发现。
腾讯地图
历史版本：3.1、4.0、4.1、4.7、4.8
最新版本：4.9
测试类型：struct对比（验证升级代码）
发现问题：
腾讯地图 从4.0 升级到 4.9版本， 数据库中少生成一张favorite.db/FavoriteStreetEntity表。 这会导致 在4.9版本中收藏“街景”后， 数据无法写入数据库。如果重新启动腾讯地图， 刚才收藏的“街景”就会消失掉。
如果历史版本多，覆盖安装工作量大，人工测试就容易遗漏这样的测试路径。通过自动化观察数据层的迁移，就很容易发现问题，提高覆盖安装测试效率。
3.2 收益统计
本方案的主要收益，源于减少覆盖安装的测试关注点，缩短测试时间。通过在手机QQ浏览器项目实践，我们得到如下数据：
- 成本
自动化建设时间:4周=160小时*人
样本数据采集时间:6（版本）x0.5（小时/版本）=3小时\人
固定成本共计: 163小时*人
由于自动化建设属于固定投入, 这部分收益通过长期多版本测试摊薄,可以忽略不计.样本数据采集时间是个主要耗时, 平均每个版本需要0.5小时*人. 一旦历史版本准备过一次样本数据，以后就不用再准备了，所以这部分耗时长期摊薄，也可以忽略。
- 收益
自动化以后，平均每个版本覆盖安装测试关注点数量减少50%。关注点的减少也直接导致测试时间的降低。
手机QQ浏览器项目组每次发布，关注最近6个版本的覆盖安装情况。从上图统计可以看出，通过自动化以后“上线前覆盖安装测试时间”缩短60%，“集成覆盖安装测试时间”缩短60%。
其他腾讯产品试用后，得到以下数据：
通过数据表明经过本方案过滤后，覆盖安装测试验证点减少50%左右。
四、总结思考
4.1 样本数据插入
从项目结果中， 我们可以发现通过Data类型（数据内容对比），让我们更有可能发现问题。但是，这需要提前插入样本数据。有这样一些方法：
- 手工导出和自动化导入用户数据
针对每个历史版本：测试人员通过手工操作构造用户数据。这个可以在迭代测试中就完成，不占用额外时间。
优点：操作简单；运行时间短。
缺点：手工操作耗时长；每个历史版本需要一份样本数据。
我们就采取的这种方案。
- 界面自动化脚本创建用户数据
通过界面自动化，模拟用户操作创建用户数据。
优点：模拟用户操作，构造数据更准确。
缺点：界面自动化运行时间较长；每个版本需要维护一个自动化脚本（版本之间存在界面差别）。
- 界面控件遍历操作创建用户数据
这是一种GUI自动化的随机遍历操作。类似于monkey测试，但是点击是以界面控件为单位。参考：http://km.oa.com/group/18017/articles/show/150352?kmref=search
优点：不用写任何脚本和输入数据。
缺点：随机遍历创建用户数据可能存在不全面；界面控件随机操作运行时间较长。
4.2 升级逻辑激活
通过我们在多个项目实践，我们发现APP的升级逻辑触发时间点：
- APP启动时触发
这种情况比较便于自动化处理，直接启动APP即可。
- APP启动后某功能激活时触发
部分模块升级逻辑要推迟到模块启动才能触发，这就要求我们要有一套模块触发机制。这部分工作可以通过UI自动化工具完成，本项目中采用QQDriver自动化脚本完成。
4.3 与精准测试结合
理论上说，如果覆盖安装函数入口规范, 调用地点集中。例如：所有升级操作都在这样的函数中。
通过代码梳理，能够找到应用覆盖安装的函数入口。通过对比“当前版本”和“历史版本”覆盖安装函数代码差异，覆盖安装逻辑变化的功能模块，进行覆盖安装测试。从而缩短覆盖安装测试的时间。
但是经过手机QQ浏览器项目实际操作发现，覆盖安装代码都位置分散，而且函数写法不规范。跨大版本的svn代码对比，发现几乎所有功能模块的覆盖安装逻辑都有改动。这样就无法缩小测试范围，达到精准测试的目的。所以如果要实现精准化覆盖安装测试，覆盖安装函数入口函写法规范和调用地点统一是前提，这个可以给项目组提可测性需求实现。
本章完~~
本文连接：http://tmq.qq.com/2016/07/specialist-in-a-long-time-5-minutes-test-android-cover-installation/
TMQ（腾讯移动品质中心）是腾讯最早专注在移动APP测试的团队
我们专注于移动测试技术精华，饱含腾讯多款亿级APP的品质秘密，文章皆独家原创，我们不谈虚的，只谈干货！
扫码关注我们
扫一扫 关注TMQ
精彩分享不断
这篇关于【腾讯TMQ】专治时间长 —5分钟测试Android覆盖安装的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
