深入探讨 Chrome iOS 版测试及发布流程

在近期于纽约举办的一场 Google 技术讲座上，Google 资深软件测试工程师 Lindsay Pasricha介绍了Chrome iOS 版的测试及发布流程，探讨了其产品开发策略、自动化测试框架以及手工测试流程等。本文对其中重要内容做个总结。

开发环境

Xcode 是 Google iOS 版产品的主要开发工具，与其它一些内部方案和工具结合使用。Pasricha 说，其中有些工具也并非 Google 内部专用，如用于管理依赖的 gyp 和用于版本控制的 git。“我们还使用了许多自动构建的解决方案让开发过程尽可能更快，” 比如后面还会提到的 Pulse 和 Waterfall 。

iOS 开发的挑战

Chrome iOS 版开发面临的最大挑战之一来自于 Google 本身是个 Android 导向的公司。比如他们很难在 Google 内部找到使用 iPhone 的工程师参与 iOS 版产品的内部测试。而且，想要与其它非 iOS 平台的开发团队之间达成共识也很不容易，因为他们并不了解 iOS 开发的局限性，例如你不可能在 App Store 上发布 Beta 版产品。

除此之外，另一大挑战是 App Store 审核流程强制规定了一个应用所允许提供的 API 和服务。这是所有 iOS 开发者面临的一个普遍问题，但对 Chrome 来说尤为严苛，因为苹果将所有浏览类应用限制在它们自己的 UIWebView 类里，它就是个黑盒子，Pasrica 说，而且 Bug 很多。

还有一个例子是在所有 Google 应用之间实现的单点登录机制。为了简化用户体验、增强桌面 Chrome 应用和手机版之间的同步机制，Chrome iOS 版于近期刚刚引入了单点登录。“这对苹果来说是件大事，因为他们认为这样存在潜在的安全威胁。最后，他们终于接受了我们的观点——为用户维护 keychain 其实正是强化了安全防护，最终 Chrome 拿到了许可。”

另外，App Store 不允许发布 Beta 版应用也增加了开发的难度。这一原则与 Google 的 Chrome 开发惯用策略相反——即通过分发金丝雀版本让数百万用户使用。这样一来，在 iOS 上的开发就不得不将之前的“开发 - 金丝雀版 -beta 版”流程放在公司内部完成，使得其测试用户数缩减到几百个——应用一旦发布，这些测试用户对应用的成熟度有很大影响。

发布流程

在 Google 的计划里，Chrome 遵循一个 6 到 9 周的发布流程——从为当前开发阶段的新特性取得开发许可开始。所有平台都遵循这一流程。在这几周里，主要任务是在该阶段的代码分支中开发新特性并修复 Bug，在准备评审流程的同时，大部分测试也完成了。在这个过程中，既有自动化测试，又有手工测试，重点在回归测试和对新特性的测试。

一旦测试完成，应用就被提交上去做评审，“这可以说是‘一个有意思的过程’，” Pasricha 说。苹果公司没有给 Google 什么特权，但是从 Pasricha 的解说来看，他们与评审小组有专线联系，并且他们通常不会收到以文字形式描述的关于某次评审不通过的理由和细节，而是被邀请过去“谈谈”，有时甚至邀请 Google 的 VP。Pasricha 说评审过程从未少于 2 个星期，但导致被拒的原因总会被快速解决，“从没有哪个里程碑是被彻底拒绝的，往往只是误解而已。”

只要应用得到上线许可，它的使用范围就从“一小部分 Google 内部用户变为数百万普通用户”，有时也会产生新问题，这时 Chrome 团队就要做一次新构建。随之而来的 Bug 修复版本的评审时间往往短得多，因为他们可以在提交应用时附上说明，注明这个构建并没有引入新功能，只是修复了哪些 Bug。

自动化测试

Google 的测试理念中很重要的一点是使用 Bots——一种使用物理设备来运行 app 的软件架构。Pasricha 说，虽然在 iPhone6 和 6+ 问世之前，iOS 开发领域没有设备的分裂问题，这个测试理念仍然十分重要，并且日后可能会变得越来越重要。

这些自动化解决方案无疑是能帮助我们尽早拿到关于代码质量反馈的最佳方式。

前文提到过，Google 从 3 个渠道开展测试：开发，金丝雀版，beta 版。这三个渠道的定义如下：

• 开发渠道：用于在新特性提交到里程碑之前的功能验证。
• 金丝雀渠道：包含了待合并到代码分支的所有更改集；在金丝雀版本构建上会运行自动化测试、单元测试和端到端测试。
• Beta 渠道：这是最接近 App Store 发布版本的构建，其中包括了额外的端到端测试。

以下描述了需要完成的几种最主要的测试类型：

• 单元测试：传统的“用于检验在各种状态下的变量值是否与期望值相符的低级别测试”，在开发过程中进行。
• 端到端测试：由 KIF 框架管理，它借助 iOS 的易访问性功能来实现 iOS 上的测试自动化。Pasricha 说，与苹果公司的自动化测试框架 UIA 相比，KIF“更为可靠一些”。
• 性能测试：通过 Chrome 访问一系列 URL，之后可以比较每次运行的性能表现。这些测试只能用来比较同一个里程碑内的软件运行性能，而不能跨里程碑比较，因此运行这类测试的目的在于确保在每个发布周期内软件的运行时间没有变长。
• 截屏测试：这类测试也是用 Chrome 发送一系列 URL，在访问的同时截屏。如果渲染的图像之间的差异低于预先设定的阈值则测试通过，否则需要人工检查。Pasricha 说，这种测试的概念很好，但不幸的是，每次运行后许多页面之间的差异几乎达到 80%，这是因为页面本身的改变和广告切换导致的，因此这类测试的误报率往往很高。

手工测试

在 Pasricha 看来，尽管采用了自动化测试，手工测试仍然是必需且无可避免的。通常来说，总有一部分测试用例只能通过手工方式来测试，例如有些用户网速很慢，那么测试时执行速度就不能太快；还有需要在请求时加入限制条件的一类特殊的企业账户等等。而且有些功能的测试用例还没有实现自动化，此时也要执行手工测试，这种情况往往发生在那些很晚才被添加到开发流程里的新功能上。事实上，有时候有些功能直到最后都没能实现自动化测试。最后，还有些功能本来就没有必要实现自动化，比如 Chrome 的标签页切换功能。

Pasricha 很希望看到 Chrome iOS 版团队在这个领域做出一些改变，尤其需要“软件工程师们承担起软件质量的责任”，这样的话某个功能只有在开发人员也亲自为它写了测试代码之后才能被发布上线，否则就不予发布。必须承认，这是一个很难在 Stakeholder 之间达成一致的问题，包括决策层和产品经理——这些人一点也不喜欢看到某些功能无法上线是由于缺少自动化测试这样的理由。

上文提到的开发渠道的测试中并不包括手工测试，而在金丝雀版本渠道内会进行两种形式的手工测试：对比测试和 delta 测试。它们的关注点都在功能的变更上，因为众所周知的，一幅热点图或者风险矩阵就能够标示出所有发生变更的组件。Pasricha 补充道，在进行这类测试时，详细的发布文档十分重要，因为它们提供了变更的位置以及哪些功能可能会因此受到影响等信息。同样的，开发人员并不太乐意提供那么详尽的发布文档，那么在这种情况下还需要做一些额外的工作以达成一致。

其它测试

需要进行的其它类型测试还有：

• 升级测试：app 发布之后，首先要做的测试就是“升级”测试，也就是从 App Store 更新已安装的 app。在这个阶段，所有新功能也会被快速地过一遍。
• 可访问性测试及国际化测试：这两种测试不会在每个里程碑阶段都全量进行，其完整测试每年执行两次。
• 安全测试：每个功能都必须经过整个安全小组的安全评审，除非是很小的功能才会只指派一位安全工程师来做评审。
• 地理位置测试：这类测试也很重要，因为曾经发现过一些只在某些国家的网站上才会出现的 Bug。

持续集成

Pasricha 解释道，Chrome iOS 版团队搭建了一套在 Google 内部使用的持续集成系统，叫做 Pulse。在此之前，Pasricha 使用的是 Jenkins，但最后他们改用了 Pulse。Pulse 被用来创建构建并为其签名，以使得 iOS Instrumentation 能够在这些构建上运行，而 Pulse 本身并不是用来运行测试的。用在 Pulse 之后的是 Waterfall ，它被用于所有的 Chrome 平台，并不仅仅是 iOS，它负责运行测试并收集测试结果，这些测试结果用一个由红绿格子组成的矩阵表示。

所有测试既要在模拟器中的 OS X 环境运行，也要在真实的设备上运行。Pasricha 警告说，使用模拟器有一个问题：它的内存比真实的设备多，因此不能用于定位与内存相关的问题。

对老版本 iOS 的支持

关于是否支持某个 iOS 版本的问题，Pasricha 的建议是，设定一个最小用户数阈值，基于这个值来决定一旦发现了 Bug 是否要为此将当前开发阶段重新开始。这个值可以是 5%，3% 或 1%，也就是成千上万的用户。有时候你也可以选择支持一小部分用户的需求，尽管他们的群体在短期看来是很小的。这种情况就发生在 iOS 越狱社区，Pasricha 说，他们对 Chrome iOS 版尤为重要，因为只有他们才可能选择 Chrome 作为默认浏览器。但是一般来说，如果一个老平台上只有很少量的用户，比如 iOS 5 或 iOS 6，那么还是有必要仔细考虑你愿意为支持这些用户投入多少成本。如果要支持，后续还会有设备和配置项增多的问题，从而导致测试矩阵变大。同时也增加了未来的开发成本，因为到时候可能还需要解决在这些平台上功能缺失的问题。另一个需要考虑的方面在于开发人员为一个旧 iOS 平台解决 Bug 的意愿：如果他们不愿意，那么就没必要支持那些平台了。

查看英文原文： Insights into the Testing and Release Processes for Chrome for iOS

感谢崔康对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ， @丁晓昀），微信（微信号： InfoQChina ）关注我们，并与我们的编辑和其他读者朋友交流。