在近期于纽约举办的一场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。