自动化测试
　　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的意愿：如果他们不愿意，那么没必要支持那些平台了。