A.1 测试主题概述
"基于风险： Chrome OS 需要测试的方面相当庞杂，涵盖了定制化浏览器、应用管理器的用户体验（UX）、固件、硬件、网络、用户数据同步、自动更新、以及来自 OEM 厂商的定制化的物理硬件。要想合理地处理这些测试问题，必须采用基于风险的测试策略，就是说测试团队将优先关注系统中风险最高的区域，然后按风险次序依次处理。测试团队会严重依赖于开发团队全面的单元测试和代码质量，以此确保整个产品的质量基础。
"自动化硬件测试组合： 由于存在各种不同的硬件环境和操作系统版本，所以需要在每次构建的版本和整个硬件环境组合中运行测试，快速发现回归问题并辅助定位问题存在的具体软件、硬件或环境配置维度（例如，某个测试用例可能仅在 HP 硬件上的无线网络配置环境下版本 X 的网络浏览器上会失败）。
"支持快速迭代：Chrome OS 的发布时间表非常紧张，因此尽早发现 bug 并定位问题重现条件非常重要。所有的测试都要能在开发人员的本地工作机上运行，以减少 bug 进入代码库的可能性，并通过大规模的自动化测试用例组合，来加速定位导致回归问题的原因。
"开放测试用例和工具：考虑到 Chromium OS 的开放源码性质和 OEM 合作厂商的质量认证，测试团队将努力保证测试工具、用例、自动化代码等可被外界共享和执行。
"Chrome OS 的主要浏览器平台：Chrome 浏览器测试团队将把 Chrome OS 作为主要关注的平台。 Chrome 浏览器在 Chrome OS 中的可测试性、自动化等与其它平台相比将被得到更多的关注。这也反映出 Chrome 浏览器在 Chrome OS 中至关重要的地位；它是 Chrome OS 中唯一的用户界面，整个系统和硬件环境都用来支持它的功能。 Chrome OS 中 Chrome 浏览器的质量标准将会更高。
"测试提供数据： 测试团队的目标不是、也不可能是保证质量。产品质量的高低取决于所有参与者，包括外部 OEM 厂商、开源项目等。 测试团队的目标是降低风险，尽可能地发现问题和 bug，为大团队提供风险评估和度量指标。测试、开发、项目经理和其他第三方都对 Chrome OS 的质量有很大的发言权和影响力。
"可测试性和乘数效应： 对 Google 应用团队、外部的第三方团队、甚至是内部团队来说，可测试性在过去一直是一个问题。测试团队将联合 Accessibility、Android和 WebDriver 团队来增进可测试性，让 Chrome OS 中的 Chrome 浏览器能被正式支持。这将提高 Google 应用团队内部的自动化效率，也让 Chrome 成为测试其它第三方 Web 页面应用的理想平台。
A.2 风险分析
测试团队将推动功能性风险分析，以达成如下目标：
"保证产品的质量风险被周知
"保证测试团队始终仅关注最高投资回报率（ROI）的任务
"保证存在一个质量和数据评估框架，能够随着产品的演进和新数据的引入，对新的质量和风险数据进行评估
风险分析过程是将所有已知产品特性和能力简单罗列，然后测试团队根据每个方面的出现频次和失效可能性，以及失效产生后果（对用户和业务）的严重程度，评估每个方面的绝对内在风险。然后，把已经存在的能够降低这些风险的策略（如现有的测试用例、自动化测试、用户试用测试、OEM 测试，等等）从相应的已知风险中扣除。把所有组件根据剩余风险进行排序，然后通过开发测试用例、自动化和流程改进等措施来应对。
关键问题是要知道产品的风险集中在哪里，并总能善用手中的资源去降低这些风险。
