第3章测试工程师
3.1 一种面向用户的测试角色
Google的TE综合了开发者仰慕的技术能力和以用户为中心检查软件质量而对开发者产生一定制约的能力。
TE的职位描述是最难定义的，因为其职责范围很广而且不确定。
3.2 测试工程师的工作
在研发的早期阶段，功能还在不断变化，最终功能列表和范畴还没有确定，TE通常没有太多的工作可做。
TE的根本使命是保护用户和业务的利益，使之不受到糟糕的设计、令人困惑的用户体验、功能bug、安全和隐私等问题的困扰。这个角色需要敏锐的洞察力和领导力。
TE职责：
测试计划和风险分析
评审需求、设计、代码和测试
探索式测试
用户场景
编写测试用例
执行测试用例
外包
使用统计
用户反馈
3.2.1 测试计划
测试计划需要具有如下特性：
及时地更新
描述了软件的目标和卖点
描述了软件的结构、各种组件和功能特性的名称
描述了软件的功能和操作简介
不必花过多的时间去撰写，必须随时可以被修改
描述必测点
能在测试中提供有用的信息，从而帮助确定进展以及覆盖率上的不足。
ACC（Attribute Componet Capability，特质、组件、能力） P82
Google使用ACC作为一种测试计划的替代方法。
A代表特质：
代表产品的品质和特色，是区别竞争对手的关键。产品经理或者开发人员已经确定了产品的特质，测试人员只需将特质记录下来，以备使用。
C代表组件：
组件是构成待建系统的模块。组件容易识别，经常出现在设计文档中。
对于特质和组件来说，花几分钟的时间来理清就足够了。
C代表能力：
组件（Componet）执行某种功能（function）来满足产品的一个特质（Attribute），这个活动的结果是向用户提供某种能力（Capability）。P86
能力最重要的一个特点是它的可测试性。
TE需要将能力转化为测试用例。
ACC的完成，意味着所有可测试的特性都被定义好了。
P90，Google+的案例分析
3.2.2 风险
风险的要素：发生频率和影响。
发生频率：罕见、少见、偶尔、常见
3.2.3 测试用例的生命周期
Google管理测试用例的工具，初期用Test Scribe。后期被GTCM（Google Test CaseManager）取代。这个小章节介绍了GTCM的特点。
3.2.4 bug的生命周期
介绍Google管理bug的工具——Buganizer。
许多团队在bug到达的速度超过了其修复能力的时候，干脆不再进行新功能的开发。强烈推荐这种实践，反对那种只盯着特性或者代码完成的里程碑的做法。
3.2.5 TE的招聘
TE的招聘非常困难，因为他们需要擅长很多事情。
面试TE的意图：
对事物结构、对于变量和配置的组合的各种可能性和意义的好奇心。关于事物应该如何工作的强烈感觉，以及清晰表达的能力。很强的人格魅力。
3.2.6 Google的测试领导和管理工作
Google的测试管理更多的是激励，而非强悍的管理；更多的是战略指引，而非频繁的督促检查（每天、每周等）。
通常，过度的管理和组织会带来紧张的气氛。
作为测试领导层，经常需要妥协，并能尊重个体SET和TE的聪明才智。Google领导和管理的一个标志是辅导和指导下属工作，而不是直接下命令。
3.2.7 维护模式的测试
尽量淘汰手工测试，使用自动化测试。
3.2.8 BITE实验
问题：测试人员花了很多时间在上下文切换和分析大量数据上，经常需要切换多种工具，影响效率。
解决方法：使用BITE工具，将尽可能多的测试活动、测试工具和测试数据集中到浏览器和云里，并在上下文中呈现相关信息，从而减少分散操作的麻烦，使得工作更加高效。
本节介绍了BITE（Browser Integrated Test Enviroment）的由来、功能以及如何使用。
BITE的逆天功能：
1、在网页上提bug时，自动获取浏览器信息；
2、打开页面，自动显示此页面的bug；
3、可以进行录制和回放；
4、自动分配任务，做得快的会自动收到更多的测试任务，暂停的人的任务会自动分给其他人；
3.2.9 零成本测试流程
免费测试特征的想法：
成本几乎为零；
瞬间可得的测试结果；
极少或者无需人工干预；
非常灵活。
Google的免费测试模型——bot流程：
1）通过GTA进行测试计划；
2）测试覆盖度：bot自动抓取网站内容，发现有所变化立刻提交人工去判断；
3）bug评审：BITE提供现有的bug和丰富的测试上下文信息；
4）探索式测试
5）bug提交：基于BITE，很容易提交bug
6）bug查看和调试：开发或测试经理可以看到实时的bug趋势图。
7）部署新版本并回到步骤1）。
价值在于：测试人员无需为了少数几个可能发生回归的特性变化，而去手工执行成百上千的回归测试。bot可以几分钟内完成一个测试周期，从产品新版本的部署到bug的发现之间的间隔很短。