深入探讨 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的意愿：如果他们不愿意，那么就没必要支持那些平台了。