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

笑哼 for 转转QA · 2019年08月01日 · 最后由 笑哼 回复于 2019年08月06日 · 208 次阅读

作者 | 孙敏

作为 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

共收到 5 条回复 时间 点赞

大型团队,RD 提交代码频繁,每次提交代码都打包,流水线会负载过大,你们在这方面有没有做控制?

KK 回复

正则匹配 commit 信息

e4rljia 回复

怎么区分出哪些提交是需要打包,哪些提交是不需要打包?有规则吗?

KK 回复

需要规范 RD 的 commit log 包含哪些 log 就进行打包

KK 回复

和 RD 规范起来,满足规范的提交的 tag 会自动打包

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册