一、前言
Google的测试团队的历程，可以说是互联网测试的一个缩影，但是仍有很多的互联网公司仍在Google初始阶段中挣扎。 也许Google的做法否正确是一个值得商榷的事情，但不可否认的是，Google的测试模式很有可能会逐渐成为测试行业的主流模式。 通过了解Google的测试历程，可以让我们少走一些弯路，让我们更加向往 “别人家” 的测试，有了更多的期望。
二、背景
缘起，有前同事来深圳参加MTSC（Mobile Testing Summit China）中国互联网测试开发大会。
而后，参加过大会的人写的文章开始传播开来，有内部KM的《DevOps研发模式变革研究 | Google篇》，也有乔梁的 《测试人员在DevOps转型过程中的发展路径是…》。
紧接着，回忆起《Golang单元测试指引》评论里有人提到了《Google软件测试之道》，这本书一直有听说，一直未读过。
最后，看待自己转到EP岗位的历程，或是需要精神支柱或是需要一定的指引吧，才快速的走马观花读一下这本书，姑且 记录一下要点。
三、Google软件测试介绍
1. 质量不等于测试
Quality is not equal to test. Quality is achieved by putting development and test- ing into a blender and mixing them until one is indistinguishable from the other.
质量不等于测试。当你把开发过 程和测试放到一起，就像在搅拌机里 混合搅拌那样，直到不能区分彼此的 时候，你就得到了质量。
质量更像是一种预防行为，而不是检测。质量是开发过程的问题，而不是测试问题。
2. 角色
2.1 SWE(Software Engineer)
软件开发工程师，增加功能、提高性能
2.2 SET((Software Engineer in Test)
软件测试开发工程师，也是开发角色，重心在可测性测试和通用测试基础框架上。
- 更关注质量提升和测试覆盖度的增加。
- 写代码的目的是可以让SWE测试自己的功能。
2.3 TE(Test Engineer)
测试工程师，承担着产品专家、质量顾问、风险分析师的角色。
- 把用户放在第一位思考
- 组织整体质量实践、分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试
SWE负责功能的实现和这些独立功能的质量。SET让开发者可以很容易的编写测试代码， 从而达到独立功能模块的质量要求。TE则是专注于用户角度的测试，验证可执行的代码 与数据集成之后，是否可以满足最终用户的需求。
3. 组织结构
Google的组织汇报关系被划分为不同的专注领域（Focus Areas），所有的开发工程师 都汇报给这些专注领域的管理者，但是SET和TE并没有遵循这个模式。测试是独立存在的 部门，与专注领域部门平行，成为工程生产力团队（EP）。 测试人员基本以租借的方式进入产品团队，去做提高质量相关的事情，寻找测试不足的地方， 或者公开一些不可接受的缺陷率数据，EP团队会根据不同产品团队的优先级、复杂度，并与 其他产品实际比较之后，再来分配测试人员。
4. 爬走跑
一个产品在给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、beta版本 或正式发布版本。
5. 测试类型
Google并没有使用代码测试、集 成测试、系统测试等这些命名方式，而是使用 小型测试、中型测试、大型 测试这样的称谓，着重强调测试的范畴规模而非形式。
-
小型测试 一般来说都是自动化实现的，用于验证一个单独函数或者独立功能模块的 代码是否按照预期工作，着重于典型功能性问题、数据损坏、错误条件和大小差异错误 等方面的验证。通常是由SWE来实现。
-
中型测试 通常也都是自动化实现，一般会涉及到2个或2个以上模块的交互，重点在于 验证这些功能近邻区之间的交互，以及彼此调用时的功能是否正确。 SET会驱动这些测试的实现及运行，SWE会深度参与，一起编码、调试和维护 这些测试。在开发过程的后期，TE 会通过手动或自动化地执行这些用例。
-
大型测试 涵盖三个或以上(通常更多)的功能模块，使用真实用户使用场景和实际用户数据， 大型测试关注的是所有模块的集成，但更倾向于结果驱动，验证软件是否满足 最终用户的需求。 所有的三种工程师角色都会参与，或是通过自动化测试，或是探索式测试。
四、软件测试开发工程师
1. SET的工作
- 部分职责是在单元测试方面给予开发人员支持，另一部分职责是为开发人员提供测试框架， 以方便他们编写中小型测试，用以进行更多质量相关的测试工作。
- 是100%的编码角色，作为测试的开发工程师和功能的开发工程师处于同等的地位。
- 具有宽广的整体产品视野，而且在产品的整个生命周期里对产品及功能特性都有充分的理解。
- 在项目早期参与项目时，会协助项目形成良好的文档、不错的可测试性、运行稳定的自动化测试、清晰的代码提交流程。
- 通常来说，代码复用和模块交互方面的设计会由SET来做，而不是SWE。
- 在审阅设计文档时，预期要关注的要点有：完整性、正确性、一致性、设计、接口与协议、测试。
- 是第一个实现所有接口和协议的人，SET 针对各个模块的依赖提供了 mock 或 fake 的实现。
- 第一要务是可测试性，SET需要提供程序结构和代码风格方面的建议给开发人员，这样开发人员可以更好地做单元测试， 同时提供测试框架方面的建议，让开发人员可以在这些框架基础上自己写测试。
2. 测试认证
测试认证项目包含一系列递增的认证级别，每个级别定义了一个可衡量的测试目标。参与的团队达成的目标越多， 获得的级别越高，它是一个改进测试实践的项目。
测试认证级别摘要：
级别1
- 使用测试覆盖率工具。
- 使用持续集成。
- 测试分级为小型、中型、大型。
- 明确标记哪些测试是非确定性的测试（测试结果不确定的用例）。
- 创建冒烟测试集合。
级别2
- 如果有测试运行结果为红色（译注：表示运行失败的用例）就不会做发布。
- 在每次代码提交之前都要求通过冒烟测试。
- 各种类型测试的整体增量覆盖率要大于50%。
- 小型测试的增量覆盖率要大于10%。
- 每一个功能特性至少有一个与之对应的集成测试用例。
级别3
- 所有重要的代码变更都要经过测试。
- 小型测试的增量覆盖率要大于50%。
- 新增的重要功能都要经过集成测试的验证。
级别4
- 在提交任何新代码之前都会自动运行冒烟测试。
- 冒烟测试必须在30分钟内运行完毕。
- 没有不确定性的测试。
- 总体测试覆盖率应该不小于40%。
- 小型测试的代码覆盖率应该不小于25%。
- 所有重要的功能都应该被集成测试验证到。
级别5
- 对每一个重要的缺陷修复都要增加一个测试用例与之对应。
- 积极使用可用的代码分析工具。
- 总体测试覆盖率不低于60%。
- 小型测试的代码覆盖率应该不小于40%。
3. SET的招聘
-
SET是一个编码能力很强的程序员，可以写功能代码；也是一个能力很强的测试者，可以测试任何产品，有能力管理他们自己的工作和工具。
-
SET的面试，重点在考察候选人如何思索问题的解决方案，而不是解决问题方案本身的实现上有多高雅。
五、测试工程师
1. 一种面向用户的测试角色
在不同的项目阶段，SET和TE的重点不同，早期的工作涉及更多的面向SET的任务，而项目后期才是面向TE的任务。 还有一些情况是TE的个人选择，他们可以在不同的角色间切换。
2. 测试工程师的工作
TE在进入产品时，需要考虑以下一些问题：
- 当前软件的薄弱点在哪里？
- 有没有安全、隐私、性能、可靠性、可用性、兼容性、全球化和其他方面的问题？
- 主要用户场景是否功能正常？对于全世界不同国家的用户都是这样吗？
- 这个产品能与其他产品（软件和硬件）互操作吗？
- 当发生问题的时候，是否容易诊断问题所在？ 当然这只是一个不完全列表。所有这些加起来，构成发布待评估软件的风险概要。TE并不需要自己去解决所有这些问题， 但必须保证这些问题被解决掉。
关于TE职责的一般性描述：
- 测试计划和风险分析。
ACC原则
Attribute Component Capability，即特质、组件、能力，一种测试计划的替代方法。
特质是系统的形容词，代表了产品的品质和特色，是区别于竞争对手的关键，也是人们选择你的产品而不是竞争对手的产品的原因。
组件是构成待建系统的模块，是使一个软件之所以如此的核心要素和代码块。
能力是系统的动词，代表着系统在用户指令之下完成的动作。它们是对输入的响应、对查询的应答以及代表用户完成的活动。
- 评审需求、设计、代码和测试。
- 探索式测试。
- 用户场景。
- 编写测试用例。
- 执行测试用例。
- 众包（译注：crowdsourcing，是互联网带来的新的生产组织形式。一个公司或机构把过去由员工执行的工作任务， 以自由自愿的形式外包给非特定的（通常是大型的）大众网络的做法）。
- 使用统计。
- 用户反馈。
六、测试工程师经理
七、Google软件测试改进
八、思维导图
