今天学习Chrome OS测试计划，也就是作者的一个实例。
A.1 测试主题概述
1）基于风险：Chrome OS需要测试的地方很多，必须采用基于风险的测试策略，即测试团队优先关注系统中风险最高的区域，然后按风险次序依次处理。
2）自动化硬件测试组合：由于存在各种不同的硬件和操作系统环境，因此需要在每次build的版本和整个硬件环境组合中运行测试。
3）支持快速迭代：所有的测试都能在开发的本地工作机运行，通过大规模的自动化测试，加速定位导致回归问题的原因，以减少bug进入代码库的可能性。
4）开发测试用例和工具：考虑到开源性，测试团队将努力保证测试工具、用例、自动化代码等可被外界共享和执行。
5）Chrome OS的主要浏览器平台：Chrome浏览器测试团队将把Chrome OS作为主要关注的平台。
6）测试提供数据：测试团队的目标不是保证质量，而是降低风险，尽可能地发现问题和bug，为大团队提供风险评估和度量指标。
7）可测试性和乘数效应。
A.2 风险分析
风险分析主要为达到以下目标：
1）保证产品的质量风险被周知
2）保证测试团队始终仅关注最高投资回报率的任务
3）保证存在一个质量和数据评估框架，能够随着产品的演进和新数据的引入，对新的质量和风险数据进行评估。
风险分析过程是将所有已知产品特性和能力简单罗列，然后测试团队根据每个方面的出现频次和失效可能性，以及失效产生后果的严重程度，评估每个方面的绝对内在风险。然后，把已经存在的能够降低这些风险策略从相应的风险中扣除。把所有组件根据剩余风险进行排序，然后通过开发测试用例、自动化和流程改进等措施来应对。
A.3 每次构建版本的基线测试
每日build的版本除了单元测试外，还有BuildBot的冒烟自动化测试和性能测试。
A.4 最新可测试版本的每日测试
包括：一系列功能验收测试的手工执行；功能回归自动化测试；滚动式持续执行Web应用程序的测试；滚动式执行压力测试、可靠性测试和稳定性测试；持续进行手工探索式测试和漫游式测试。
A.5 发布版本测试
1）站点兼容性：对前100名站点进行验证
2）场景验证：对示例性场景进行验证
3）P0 bug验证：验证所有已被修正的P0 bug和80%的P1 bug
4）全面压力和稳定性测试
5）Chrome OS手工测试用例：执行所有的手工用例
A.6 手工测试与自动化测试
项目早期主要是手工测试，后期，很多高优先级和高回报率的手工测试用例会被自动化。
A.7 开发和测试的质量关注点
开发着重于代码级别的测试，测试更多关注于端到端的测试和集成测试场景。
A.8 发布通道
在大量部署前在真实环境中进行某种程度的试验，感觉类似于灰度发布，不过它是根据对痛苦的容忍程度和进行反馈的意愿来区分用户群体。
A.9 用户输入
A.10 测试用例库
手工测试用例被存储在TestScribe中，自动化测试用例存储在Autotest中。
A.11 测试仪表盘
一个专用的质量度量数据仪表盘，它提供了宏观的质量评估数据，聚合包括手工和自动化测试在内的执行结果。
A.12 虚拟化
虚拟化降低了对物理硬件的依赖，加速镜像的创建。
A.13 性能
测试团队的目标是辅助性能指标测量的执行、报告和趋势总结，而不是直接开发性能测试。
A.14 压力、长时运行和稳定性测试
测试团队负责长时间运行用例。
A.15 测试执行框架（Autotest）
Autotest是开源项目，Chrome OS使用Autotest作为核心自动化测试框架。目前，Autotest已支持Windows和Mac。
A.16 OEM厂商
OEM厂商负责检测构建版本和硬件的质量。测试团队还会在每日测试中囊括各种不同的硬件。
A.17 硬件试验田
硬件实验田被构建来支持一系列广泛的网络笔记本电脑和一些具备通用服务组件的设备。
A.18 端到端测试自动化集群
测试团队建立了一套一系列网络笔记本电脑组成的集群，负责测试执行和报告，涵盖了大量硬件和软件的组合。
A.19 测试浏览器的应用管理器
A.20 浏览器的可测试性
A.21 硬件
主要包括电源管理和硬件故障。
A.22 时间线
2009 Q4~2010 Q4这期间进行的工作
A.23 主要的测试驱动力
A.24 相关文档
风险分析、手工验收测试、Chrome OS手工/功能测试计划等。
至此，整个测试计划的内容看完了。总的来说，风险分析和发布版本测试印象很深刻。
