A.20 浏览器的可测试性
浏览器为用户展现了很多 Chrome OS 的核心界面和功能。很多浏览器的界面是不可测试的，或者，只能通过浏览器以外更底层的 IPC 自动代理接口进行测试。在 Chrome OS 中，我们致力于统一 Web 应用、Chrome 用户界面和功能特性的测试，并且能够触发底层系统测试。我们还想让 Chrome 成为对于 Web 应用来说最可测试的浏览器，鼓励外部 Web 开发团队首先在 Chrome 平台上进行测试。为此，我们构建了下面的测试设施：
" 将Selenium 和 WebDriver移植到Chrome OS：这是当前最核心的 Web 应用测试框架。Chrome OS 和 Chrome 浏览器测试团队，很有可能肩负起 WebDriver 的 Chrome OS相关功能的实现，并进一步为应用团队和外部测试人员提供稳定、可测试的接口。
" 把 Chrome OS 的界面和功能通过 JavaScript DOM 暴露出来：这样就也可以通过 WebDriver 来驱动 Chrome OS 的界面和功能测试了。这部分功能通过与 ChromeView 里提供的 shutdown 、sleep 等辅助功能一样的方法暴露出来。
" 高阶脚本: 与 WebDriver 开发人员合作，将基本的 WebDriver API 扩展成为纯 JavaScript，并最终成为更高阶的录制/回放和参数化的脚本（例如"Google搜索<关键词>"）。这加速了内部和外部的测试开发，因为如果用 WebDriver 开发将需要相当大量的时间，用于获取元素以及处理当界面快速变化时的维护问题。
A.21 硬件
Chrome OS 有一整套的硬件需求和来自众多 OEM 厂商的变化。在主要的 OEM 厂商平台上需要进行特定的测试，以保证物理硬件和 Chrome OS 系统的紧密集成。 具体来说，这些测试包括：
" 电源管理：外接电源和电池电源循环操作，电源失效，硬件组件的电源管理，等等。
" 硬件故障：Chrome OS 如何检测硬件故障以及如何恢复？
A.22 时间线
2009年 Q4
" 定义手工验收测试，并在持续构建版本上执行
" 定义基础发布检验测试，并对每个主要发布版本执行
" 建立基础硬件实验环境
" 完成风险分析
" 持续构建版本的端到端自动化测试，在网络笔记本电脑的物理实验环境中运行
" 基于 Hive 的虚拟化和物理机镜像支持
" 移植 WebDriver 和 Selenium 到 Chrome OS
" 重要 Web 应用的部分自动化测试
" 决定实现团队使用的测试框架
" 推动 Google Feedback 与 Chrome OS 的集成
" 构建核心测试团队、人员和流程
" 自动化语音/视频测试
" 完成基于风险的测试计划
" 界面手工测试计划
2010年 Q1
" 质量计分板
" 自动化更新测试
" 在实验室环境支持自动性能测试
" 在 HYD、KIR 和 MTV 都建立实验室环境并开始执行测试
" Linux 和 Chrome OS 版本的 Chromebot
" 主要 Chrome OS 功能和界面的可测试性支持
" Chrome OS 功能回归自动化测试集
" 将 Chrome OS 加入 Web 应用的 Selenium 测试机群
" 支持浏览器和用户界面测试的录制回放的原型
" ChromeSync 的端到端测试用例的自动化
" 稳定性和故障注入测试
" 特定网络测试
" 能令 James 满意的日常的探索式手工测试和漫游
