在近期于纽约举办的一场Google技术讲座上，Google资深软件测试工程师LindsayPasricha介绍了ChromeiOS版的测试及发布流程，探讨了其产品开发策略、自动化测试框架以及手工测试流程等。本文对其中重要内容做个总结。
开发环境Xcode是GoogleiOS版产品的主要开发工具，与其它一些内部方案和工具结合使用。Pasricha说，其中有些工具也并非Google内部专用，如用于管理依赖的gyp和用于版本控制的git。“我们还使用了许多自动构建的解决方案让开发过程尽可能更快，”比如后面还会提到的Pulse和Waterfall。
iOS开发的挑战ChromeiOS版开发面临的最大挑战之一来自于Google本身是个Android导向的公司。比如他们很难在Google内部找到使用iPhone的工程师参与iOS版产品的内部测试。而且，想要与其它非iOS平台的开发团队之间达成共识也很不容易，因为他们并不了解iOS开发的局限性，例如你不可能在AppStore上发布Beta版产品。
除此之外，另一大挑战是AppStore审核流程强制规定了一个应用所允许提供的API和服务。这是所有iOS开发者面临的一个普遍问题，但对Chrome来说尤为严苛，因为苹果将所有浏览类应用限制在它们自己的UIWebView类里，它就是个黑盒子，Pasrica说，而且Bug很多。
还有一个例子是在所有Google应用之间实现的单点登录机制。为了简化用户体验、增强桌面Chrome应用和手机版之间的同步机制，ChromeiOS版于近期刚刚引入了单点登录。“这对苹果来说是件大事，因为他们认为这样存在潜在的安全威胁。最后，他们终于接受了我们的观点——为用户维护keychain其实正是强化了安全防护，最终Chrome拿到了许可。”
另外，AppStore不允许发布Beta版应用也增加了开发的难度。这一原则与Google的Chrome开发惯用策略相反——即通过分发金丝雀版本让数百万用户使用。这样一来，在iOS上的开发就不得不将之前的“开发-金丝雀版-beta版”流程放在公司内部完成，使得其测试用户数缩减到几百个——应用一旦发布，这些测试用户对应用的成熟度有很大影响。
发布流程在Google的计划里，Chrome遵循一个6到9周的发布流程——从为当前开发阶段的新特性取得开发许可开始。所有平台都遵循这一流程。在这几周里，主要任务是在该阶段的代码分支中开发新特性并修复Bug，在准备评审流程的同时，大部分测试也完成了。在这个过程中，既有自动化测试，又有手工测试，重点在回归测试和对新特性的测试。
一旦测试完成，应用就被提交上去做评审，“这可以说是‘一个有意思的过程’，”Pasricha说。苹果公司没有给Google什么特权，但是从Pasricha的解说来看，他们与评审小组有专线联系，并且他们通常不会收到以文字形式描述的关于某次评审不通过的理由和细节，而是被邀请过去“谈谈”，有时甚至邀请Google的VP。Pasricha说评审过程从未少于个星期，但导致被拒的原因总会被快速解决，“从没有哪个里程碑是被彻底拒绝的，往往只是误解而已。”
只要应用得到上线许可，它的使用范围就从“一小部分Google内部用户变为数百万普通用户”，有时也会产生新问题，这时Chrome团队就要做一次新构建。随之而来的Bug修复版本的评审时间往往短得多，因为他们可以在提交应用时附上说明，注明这个构建并没有引入新功能，只是修复了哪些Bug。
自动化测试Google的测试理念中很重要的一点是使用Bots——一种使用物理设备来运行app的软件架构。Pasricha说，虽然在iPhone6和6+问世之前，iOS开发领域没有设备的分裂问题，这个测试理念仍然十分重要，并且日后可能会变得越来越重要。
这些自动化解决方案无疑是能帮助我们尽早拿到关于代码质量反馈的最佳方式。
前文提到过，Google从3个渠道开展测试：开发，金丝雀版，beta版。这三个渠道的定义如下：
开发渠道：用于在新特性提交到里程碑之前的功能验证。
金丝雀渠道：包含了待合并到代码分支的所有更改集；在金丝雀版本构建上会运行自动化测试、单元测试和端到端测试。
Beta渠道：这是最接近AppStore发布版本的构建，其中包括了额外的端到端测试。
以下描述了需要完成的几种最主要的测试类型：
单元测试：传统的“用于检验在各种状态下的变量值是否与期望值相符的低级别测试”，在开发过程中进行。
端到端测试：由KIF框架管理，它借助iOS的易访问性功能来实现iOS上的测试自动化。Pasricha说，与苹果公司的自动化测试框架UIA相比，KIF“更为可靠一些”。
性能测试：通过Chrome访问一系列URL，之后可以比较每次运行的性能表现。这些测试只能用来比较同一个里程碑内的软件运行性能，而不能跨里程碑比较，因此运行这类测试的目的在于确保在每个发布周期内软件的运行时间没有变长。
截屏测试：这类测试也是用Chrome发送一系列URL，在访问的同时截屏。如果渲染的图像之间的差异低于预先设定的阈值则测试通过，否则需要人工检查。Pasricha说，这种测试的概念很好，但不幸的是，每次运行后许多页面之间的差异几乎达到80%，这是因为页面本身的改变和广告切换导致的，因此这类测试的误报率往往很高。
手工测试在Pasricha看来，尽管采用了自动化测试，手工测试仍然是必需且无可避免的。通常来说，总有一部分测试用例只能通过手工方式来测试，例如有些用户网速很慢，那么测试时执行速度就不能太快；还有需要在请求时加入限制条件的一类特殊的企业账户等等。而且有些功能的测试用例还没有实现自动化，此时也要执行手工测试，这种情况往往发生在那些很晚才被添加到开发流程里的新功能上。事实上，有时候有些功能直到最后都没能实现自动化测试。最后，还有些功能本来就没有必要实现自动化，比如Chrome的标签页切换功能。
Pasricha很希望看到ChromeiOS版团队在这个领域做出一些改变，尤其需要“软件工程师们承担起软件质量的责任”，这样的话某个功能只有在开发人员也亲自为它写了测试代码之后才能被发布上线，否则就不予发布。必须承认，这是一个很难在Stakeholder之间达成一致的问题，包括决策层和产品经理——这些人一点也不喜欢看到某些功能无法上线是由于缺少自动化测试这样的理由。
上文提到的开发渠道的测试中并不包括手工测试，而在金丝雀版本渠道内会进行两种形式的手工测试：对比测试和delta测试。它们的