A.3 每次构建版本的基线测试
对每次持续构建的版本在开发人员的单元测试以外，还将通过构建机器人（Buildbot）执行以下测试：
" 冒烟测试（P0 自动化）
" 性能测试
A.4 最新可测试版本（Last Known Good，LKG）的每日测试
每天都会对持续构建的最新可测试版本（LKG）执行以下测试：
" 一系列功能验收测试的手工执行（可以限定每天在一种类型的硬件环境中执行）
" 功能回归测试自动执行
" 在每日构建版本上，滚动式地持续执行 Web 应用程序的测试（包括自动和手工测试）
" 滚动式执行压力测试、可靠性测试、稳定性测试等。在每日构建版本上反复执行这些测试，直到没有新问题出现，然后转为每周执行
" 持续地进行手工探索式测试和漫游式测试
A.5 发布版本测试
每个发布通道的"候选发布"版本。
" 站点兼容性：Chrome 浏览器测试团队负责对前 100 名站点（Top100）在 Chrome OS 上进行验证
" 场景验证：对 Chrome OS 对外展示或者向合作伙伴发布的示例性场景（可能最多有两到三个示例）进行验证
" P0 Bug 验证：验证所有已被修正的优先级为 P0的 bug。 验证80%的自上次发布版本以来记录的优先级为P1的 bug
" 全面压力和稳定性测试：执行一次压力和稳定性测试
" Chrome OS 手工测试用例：执行所有的 Chrome OS 手工测试用例（可以分派给不同的测试人员和不同的硬件环境）
A.6 手工测试与自动化测试
手工测试非常重要，特别是在项目的早期用户界面和其他功能特性经常变化、可测试性和自动化开发工作仍在进行的时候，手工测试有不可替代的作用。手工测试的重要性还体现在，由于 Chrome OS 的核心价值在于其简单性，用户界面和体验必须非常直观流畅，机器目前还不能做这些方面的测试。
自动化测试是项目取得长期成功的关键，也是测试团队高效检验回归问题的关键。浏览器自动化已经实现，因此很多高优先级和高回报率的手工测试用例也被自动化了。
A.7 开发和测试的质量关注点
开发团队相对来说大一些，而且更了解组件内部机制和代码级别的实现细节。我们需要开发人员能够提供丰富的单元测试集和通过 Autotest 加入重要的系统测试用例。
测试团队会更多地关注端到端（end-to-end）的测试和集成测试场景，着重于暴露给最终用户的功能特性、跨组件的交互操作、稳定性和可扩展性测试以及测试报告。
A.8 发布通道
我们应该学习 Chrome 浏览器团队使用不同的发布"通道"的成功经验，根据对痛苦的容忍程度和进行反馈的意愿来区分用户群体。这些发布通道根据对质量逐步严格的保证级别来进行维护。 这种机制模仿了在 google.com 的实验性属性，允许在大量部署前在真实环境中进行某种程度的试验，降低了整个产品的风险。
