APP测试，安装包走过的一生

作者 | 孙敏

作为APP测试，工作中时时要与各种包打交道(包：指代Android的apk安装包，iOS的ipa安装包)。

从RD提交代码->QA测试代码->最终将apk或ipa发到线上让用户看到，整个过程中涉及到多个用户角色，过程中我们能做的有很多，下面简单介绍一下。

---

01打包过程自动化

一件事情如果需要持续重复的人工投入，那就很有将其自动化的必要性，打包就是其中一种（打包：将代码变成安装包）。

版本测试中，RD每日都要多次交付新代码给QA。角色间的沟通，人工的编译打包，都是重复浪费人力的事情。

上图是最基础的一个打包流程，每日重复的工作，首先考虑将其自动化。

1. 开发提交代码后，自动触发编译打包任务;

2. 编译打包生成结果自动通知用户（RD/QA）；

通知的方式可以根据各公司收消息场景去配置，例如我们的是邮件和企业消息两种方式。

通知的内容有两种，可识别的二维码以及可下载的安装包。

流程的自动化，去除人工的介入、较少人工错误、释放人力，更高效、更可靠。

02过程中数据收集

流程的自动化，也便于我们在过程中收集各种各样的数据

单次数据来说：  

目前我们RD交付给QA的代码，是通过打TAG的方式，过程中我们能拿到并不限于以下数据

• 提交的TAG、提交人、提交时间

• 本次提交的commit信息以及修改的代码信息

• 本次提交内容与上次提交TAG间的代码对比，以及commit记录

通过TAG对比等，将对比信息打印出来，QA能快速了解RD都改动了什么，而不仅仅依赖RD最后TAG提交时的commit信息

历史数据综合来看：  

代码提交的方式要有一定规范，才便于分析历史数据，比如将TAG名称变得更有意义。 

通过对历史数据的数据综合分析，我们能拿到更多数据：

• 每个版本打TAG的次数；

• Android和iOS横向对比频次与间隔时间；

• 每个版本打包的结果等。

除了收集打包过程中的信息，我们同时还可以针对当前提交代码以及安装包做一些自动化的测试。

03针对包的自动化测试

这里的自动化测试可以是针对代码本身的，也可以针对最终产出包的。

目前测试项，有且不限于以下项：

• 代码静态扫描

• Monkey测试

• UI自动化测试

• 包大小检查

• 性能测试

自动化测试，能更快速发现问题，减少人工去测试的工作量；扩展的专项测试，则在更多方面保障APP质量。

最终每次执行的结果也会存储下来，便于分析对比。

04发版、渠道管理

每个版本最后的环节，发版。

Android主要是发到各个渠道，iOS需要上传到App Store。

怎么让人在整个流程中解放？优化思路不变，工具能自动实现的，就别人工做了。

iOS比较简单，使用xcode提供的工具命令直接上传到App Store即可。

Android涉及到渠道包的管理以及生产，这个又涉及到和渠道同学的沟通协作。包括渠道号的管理，渠道包的生成与上传等等。

05历史包管理

历史包对一个APP团队简单而重要。

通过它你能清晰看到APP的过程痕迹，什么时候发版的？每个版本我们提交了什么等等信息。同时通过历史包也可以让我们快速安装我们想要的版本包。

上面数据收集那里，已经收集了生成的APK或IPA包，将其所有历史数据汇总实际就是一个历史包列表。
历史包记录需要有以下功能

• 便于搜索

  包含能够通过TAG、版本号、终端等快速找到我们要的包。

• 标记每个包都是做什么的

  包含包描述信息（可用代码提交的commit信息）

      所属环境

      什么类型的包（尤其是iOS涉及多种证书的包

      包生成的时间。

• 发版的TAG区分

  记录哪个TAG是发版的以及发布的时间等信息。方便记录追踪。

当然一个公司可能有多款APP，我们还需要针对多个APP做区分；

历史包的数据收集，也可以统计一下历史包的访问人数，次数，可以看下推行使用效果。

---

总结与规划

以上是目前我们在APP测试中做的一些事情。主要是流程的自动化、专项等自动化测试、测试数据和过程数据收集。

目前，人工部分，我们基本都完成了自动化。但是我们仍然有很多可优化的部分，比如下面三点：

• 渠道同学渠道包管理与我们渠道包管理的打通

• 有新APP时的快速接入

• 打包、历史包等各个工具的统一平台化

下半年我们也将针对并不限于以上几点，会进一步进行优化，让安装包的一生发挥更大的价值。

往期精彩回顾