作者 | 孙敏

作为 APP 测试，工作中时时要与各种包打交道 (包：指代 Android 的 apk 安装包，iOS 的 ipa 安装包)。
从 RD 提交代码->QA 测试代码->最终将 apk 或 ipa 发到线上让用户看到，整个过程中涉及到多个用户角色，过程中我们能做的有很多，下面简单介绍一下。

打包过程自动化

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

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

上图是最基础的一个打包流程，每日重复的工作，首先考虑将其自动化。
1.开发提交代码后，自动触发编译打包任务;
2.编译打包生成结果自动通知用户（RD/QA）；
通知的方式可以根据各公司收消息场景去配置，例如我们的是邮件和企业消息两种方式。
通知的内容有两种，可识别的二维码以及可下载的安装包。

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

过程中数据收集

流程的自动化，也便于我们在过程中收集各种各样的数据
单次数据来说
目前我们 RD 交付给 QA 的代码，是通过打 TAG 的方式，过程中我们能拿到并不限于以下数据

• 提交的 TAG、提交人、提交时间
• 本次提交的 commit 信息以及修改的代码信息
• 本次提交内容与上次提交 TAG 间的代码对比，以及 commit 记录 通过 TAG 对比等，将对比信息打印出来，QA 能快速了解 RD 都改动了什么，而不仅仅依赖 RD 最后 TAG 提交时的 commit 信息

历史数据综合来看
代码提交的方式要有一定规范，才便于分析历史数据，比如将 TAG 名称变得更有意义。
通过对历史数据的数据综合分析，我们能拿到更多数据：

• 每个版本打 TAG 的次数；
• Android 和 iOS 横向对比频次与间隔时间；
• 每个版本打包的结果等。 除了收集打包过程中的信息，我们同时还可以针对当前提交代码以及安装包做一些自动化的测试。

针对包的自动化测试

这里的自动化测试可以是针对代码本身的，也可以针对最终产出包的。
目前测试项，有且不限于以下项：

• 代码静态扫描
• Monkey 测试
• UI 自动化测试
• 包大小检查
• 性能测试 自动化测试，能更快速发现问题，减少人工去测试的工作量；扩展的专项测试，则在更多方面保障 APP 质量。 最终每次执行的结果也会存储下来，便于分析对比。

发版、渠道管理

每个版本最后的环节，发版。
Android 主要是发到各个渠道，iOS 需要上传到 App Store。

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

iOS 比较简单，使用 xcode 提供的工具命令直接上传到 App Store 即可。
Android 涉及到渠道包的管理以及生产，这个又涉及到和渠道同学的沟通协作。包括渠道号的管理，渠道包的生成与上传等等。

历史包管理

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

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

历史包记录需要有以下功能

• 便于搜索，包含能够通过 TAG、版本号、终端等快速找到我们要的包。
• 标记每个包都是做什么的， 包含包描述信息（可用代码提交的 commit 信息），所属环境， 什么类型的包（尤其是 iOS 涉及多种证书的包，包生成的时间。
• 发版的 TAG 区分，记录哪个 TAG 是发版的以及发布的时间等信息。方便记录追踪。 当然一个公司可能有多款 APP，我们还需要针对多个 APP 做区分； 历史包的数据收集，也可以统计一下历史包的访问人数，次数，可以看下推行使用效果。

总结与规划

以上是目前我们在 APP 测试中做的一些事情。主要是流程的自动化、专项等自动化测试、测试数据和过程数据收集。
目前，人工部分，我们基本都完成了自动化。但是我们仍然有很多可优化的部分，比如下面三点：

• 渠道同学渠道包管理与我们渠道包管理的打通
• 有新 APP 时的快速接入
• 打包、历史包等各个工具的统一平台化 下半年我们也将针对并不限于以上几点，会进一步进行优化，让安装包的一生发挥更大的价值。

最后，欢迎关注公众号：转转 QA