原文： http://blog.sina.com.cn/s/blog_6cf812be0102viuh.html
上一次分享了google测试分享-分层测试，有很多自动化测试的策略和实施都要有一个重点和计划，那这次会把google是如何来对SUT制定测试计划的分享下。
为了让这些blog分享更有逻辑性，我打算分几个专题来分享google测试相关的测试理念。
google测试分享-GTA
google测试分享-测试经理
google测试分享-问题和挑战
google测试分享-未来测试
在讲GTA之前，必须先讲下测试计划，而测试计划对于很多人来说都不陌生，很多测试书籍里面都会描述如何编写一个好的测试计划，需要考虑多少内容，当然，这个也是测试工程师面试的必备题目。在这里，我只想引用某个大师说的话：测试计划本身的价值不是测试计划最后的文档，而是制作测试计划的过程。我还想让大家知道的是James bach有个很好的指导书，就是关于如何编写测试计划的。参考下面的图:
《测试计划图》
这里可以看到制定测试计划的过程很负责，需要考虑很多因素，某些因素都会影响着计划的有效性，虽然实际工作过程中，我们不可能一步步按照上面的方法去check这些因素，但是其思想和意识是值得大家思考的。相信各自团队都有自己的测试计划模板，里面会涉及到很多的内容。一般来说，测试计划包含：及时地更新、描述了软件的目标和卖点、描述了软件的结构、各种组件和功能特性的名称、功能和操作简介。而且测试计划还必须要避免散漫的文字，推荐使用简明的列表；不必推销；保持内容简洁；不要把不重要的、无法执行的东西放进测试计划；多采用渐进式的描述；真正的指导计划者的思路；当然最终结果应该还是测试用例。但是我这里还想强调三点：
第一点是这个看起来非常全面的测试计划模板是传统行业测试的测试模板，不适合互联网产品测试的特点，之前做完一个项目的测试计划需要2-3天，其中过程中就不说了，现在采用敏捷方式来做项目，测试计划只需要2-3个小时就完成了，更多的也是类似于one page plan。
第二点是真正体现价值的不是最后输出的测试计划结果，而是得出这样的计划的过程，其中有多少是融合了执行计划、策略、范围、风险以及项目上下文背景信息。
第三点是我们是否充分的了解测试计划的共享性、有效性、可变性、以及在测试阶段的引导性，这个说起来比较玄乎，其实这个是实时在在发生的，测试执行整个周期，我们的计划肯定是改变的，都是我们体现出来了吗；灵活变化的结果是否得到一致认可；怎样让计划和风险和范围灵活变化且受控制；怎样提前预估风险和计划的差异性等。
同样的，google也同样认为测试计划是最早出现、最先被遗忘的测试产物。但是google测试理念更加认为测试文档的作用不可扩大化，测试人员不应该对测试文档过于珍爱，大家最关心的是代码库，包括测试代码库。
为了充分的了解被测产品，google开发了一个测试计划工具GTA来展现被测产品和测试计划的关系。GTA：Google Test Analytics 来记录计划里面的ACC（特质、组件、能力），这也是个开源工具：https://code.google.com/p/test-analytics/。当测试人员完成一个被测系统的ACC设置后，有几个测试策略可以参考：
（1）使用10分钟编写测试计划：花费30分钟左右，80%的完整性
（2）分组展示产品能力，按照测试组进行bug bash，或帮助执行探索式测试执行的计划
（3）我们无法避免风险，但是我们首先需要进行风险分析，考虑两个要素：失败频率和影响。然后进行打分。风险分析的目标不是对一个风险给出一个精确的值，而是要识别一个可执行的有优先级的执行计划。
（4）邀请开发、PM、运营、PD、管理层一起review风险。
（5）TE是缓解风险活动的协调人，决定对风险较大的领域进行内部测试，要求SWE和SET增加回归测试。也可以借助dogfood用户、beta用户以及众包进行测试
（6）TE仔细思索高风险的区域，咨询可能的回滚和恢复机制。同时对风险最高的领域负有个人责任，必须编写测试指导。
（7）对于风险较低的区域，可以降低要求，为这些区域编写特定的测试用例是得不偿失的，我们更多的是选择探索式测试，或众包测试。
（8）按照风险顺序进行测试。原则：如果不能全测，就先测最重要的，也就是风险最大的。
补充一下，风险因子里面的失败频率包括：罕见、少见、偶尔、常见。影响包括：最小、一些、较大、最大。
（9）TE在了解了SET和SWE的测试后，评估这些测试对风险的影响，实时改变测试计划和策略。对于高风险区域的每个bug都应该有一个回归测试用例与之对应。
为了更多的引导开发自测以及团队质量意识的培养，google测试团队对一个开发团队进行测试认证，完成了一系列的测试任务。SET或TE可能会变成测试认证教练。
google的TE在编写测试用例时，需要对TC进行标签化，创建的时候设置name、content、public fables/ private fables。另外，对于用户反馈的bug，使用了聚类算法来自动识别充分记录并确定最频繁的问题。而测试人员自己发现bug后，应该花些时间细细品味。不仅仅是有权利享受自己劳动的果实，而且，理解此bug微妙的细小差别及其出现的条件是很重要的。还应该找同伴来分享他的发现。
现在再来了解下GTA，GTA是根据项目的ACC得到项目的风险热图，再进行内部数据库的绑定，比如bug数据库、代码树、测试用例的位置或查询，随着这些指标的变化，通过简单的线性代数来自动更新风险级别。GTA 包括这些内容：项目规格（项目介绍、ACC）；风险（总览）；导入数据（测试用例、bug、checkins）；数据设置（数据源、数据筛选）。
GTA 可以很快的把能力列表变成一次测试执行，包括了一个简单的概要测试用例列表。GTA可以帮忙TE根据测试执行背后的ACC矩阵来分配测试人员。GTA旨在使风险分析足够的简单和实用，以便人们能够真正的用起来。
为了最高效的做web产品测试，google设定了一个零成本测试流程：通过GTA进行测试计划；测试覆盖度，Quality Bot区分回归和新特性，区分手工和自动化测试；bug评审，利用BITE来快速判断；探索式测试，外包和早期用户执行；bug提交，SUT里面进行bug快速提交；Bug triage和调试；重新部署新版本回到第一步。
上面是大概说了下google是如何使用GTA来管理整个测试阶段，特别是测试计划的安排，总的说来，流程开放、简单、直接、有效。希望大家对google如何进行测试计划和测试管理有一定的了解。下期准备分享google测试经理是如何带领团队进行测试技术创新和团队管理的，google测试分享-测试经理。