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

笑哼 for 转转QA · 2019年08月01日 · 最后由醋味柠檬回复于 2023年05月30日 · 4024 次阅读

作者 | 孙敏

作为 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 做区分；历史包的数据收集，也可以统计一下历史包的访问人数，次数，可以看下推行使用效果。