close
当前位置: 物联网在线 > 技术文库 > android >

专治时间长 —5分钟测试Android覆盖安装

专治时间长 —5分钟测试Android覆盖安装


覆盖安装测试,作为一项基本的测试类型是不可或缺的。它存在的主要价值:验证老版本覆盖升级到新版本,用户和系统数据能够正确迁移,以及保障用户升级后的功能可用性。

但是说他痛在什么地方呢?

需要测试的版本多

每个版本需要覆盖的用例多

二、解决方案 2.1 思路

从哲学上说,任何事物都是发展变化的。我们需要在“变化”中找寻“不变”的本质和规律。在覆盖安装过程中,我们也要找到“不变”的部分,那就是我们能够“减少工作量”的地方。

例如:某APP1.0版本覆盖升级到APP2.0版本。

专治时间长 —5分钟测试Android覆盖安装

在这个过程中哪些是不变的部分呢?

程序代码

了解Android覆盖安装的同学都知道,覆盖安装后,APP1.0版本的程序代码,完全更新为APP2.0版本的程序代码。但是,这种变化会在“迭代”测试中完全保证。因为“迭代”测试中“全新安装”APP2.0程序代码和“覆盖安装APP2.0程序代码”是相同的。

用户数据

用户数据—用户使用APP过程中产生的数据。例如:用户使用“浏览器”打开了, 那么浏览器访问历史中的就是用户数据。很显然,用户数据在覆盖升级的过程中不应该被改变。不仅如此,升级后的用户数据必须能够正常访问使用。这样才能保证用户在APP覆盖升级后使用的连贯与一致性。当然,这是理想的情况,在覆盖升级过程中用户数据也有可能发生变化。

专治时间长 —5分钟测试Android覆盖安装


很显然,(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为例子。

专治时间长 —5分钟测试Android覆盖安装


用户数据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表

专治时间长 —5分钟测试Android覆盖安装

C中的switch表

专治时间长 —5分钟测试Android覆盖安装


很明显是1.0升级到2.0的时候,对switch表升级代码漏掉了增加一列phone的操作。但是在2.0全新安装的时候, 在switch表确增加了phone字段。这就是我们要寻找的Bug。关于这里的数据表中的值, 都是应用启动后默认的值。

结构修改

例如:B中的switch表数据类型

专治时间长 —5分钟测试Android覆盖安装


(责任编辑:ioter)

用户喜欢...

Android获取图片拍照时间

为什么写这篇文章是因为今早有个需求需要获取图片拍照时的时间进行一些处理,有些方法参数名忘记了,所以谷歌百度了一下,Android 图片 时间,Android 图片 拍照 时间,这几个关键字居然...