《Google软件测试之道》 第一章google软件测试介绍
前段时间比较迷茫，没有明确的学习方向和内容。不过有一点应该是可以肯定的：迷茫的时候就把空闲的时间用来看书吧！
这本书，目前只是比较粗略的看了一遍，感触很大。以下是个人所作的笔记，与原文会有出入的地方。建议感兴趣的伙伴阅读原文书籍！
一、质量不等于测试
质量不是被测出来的：未经测试也不可能开发出有质量的软件。
保证质量：
测试开发同时开展：google目标。
开发对质量的责任：写一段代码后立刻测试，完成了更多的代码就做更多的测试；质量像是预防行为（质量是开发过程的问题，不是测试问题）。
测试：线上bug重重，就会回滚版本；判断预防工作做得怎么样（开发的测试，能不能确保不会出现回滚级别的bug发生）。
二、角色
1、软件开发工程师SWE：
实现最终用户所使用的功能代码：
创建设计文档、选择最优的数据结构和整体架构、代码实现和代码审核。
编写测试代码：
测试驱动的设计、单元测试、参与构建各种大小规模的测试。
增加功能性代码或是提高性能的代码。
质量责任：
对他们编写、修复以及修改的代码承担质量责任（容错设计、故障恢复、测试驱动设计、单元测试）。
2、软件测试开发工程师SET：
工作重心：
保证SWE开发的功能模块具有可测试性：参与设计评审，观察代码质量与风险；可能会重构代码，编写单元测试框架和自动化测试框架。
通用测试基础框架。
负责提供测试支持：
有个测试框架：可以把新开发的代码隔离，通过模拟真实的工作运行环境和代码提交队列来管理代码的提交。
关注：质量提升和测试覆盖率的增加。
写代码的目的：可以让SWE测试自己的功能。
3、测试工程师TE
专注用户角度的测试：
花大量时间模拟用户的使用场景和自动化脚本或代码的编写上。
是否满足性能期望，在安全性、国际化、访问权限等方面是否满足用户的要求。
工作：
组织整体质量实践（把SWE和SET编写的测试分类组织起来），分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试。
三、组织结构
大多数公司：
资深管理者一般来自产品经理或开发经理，而不是来自测试团队。
产品发布时，优先考虑的是功能是否完整和易用性方面是否足够简单，很少考虑质量。
作为同一个团队，测试总是在为开发让路：“行业充斥着各种有缺陷、早产的产品”的问题所在；质量不行就再发布一个补丁包。
Google组织汇报关系：
划分不同的专注领域：客户端、地理、广告等（开发工作汇报给这些专注领域的管理者）。
测试是独立存在的部门：工程生产力团队
- 以租借的方式进入产品团队：
1) 做提高质量的相关工作，或者公开一些不可接受的缺陷率数据；
2) 不是直接向产品团队进行汇报，不能因项目急需发布就能通过测试（可以事先协商。有自己选择决定的优先级，在可靠性、安全性上的问题不会妥协）；
3) 可以让SET和TE保持新鲜感和忙碌，一个好的想法可以快速在公司内部蔓延
- 会根据不同产品团队的优先级、复杂度，并与其他产品实际比较之后，再来分配测试人员(可能会搞错，但总体上来说会保持实际需求与不明确需求之间的某种平衡)。
四、爬走跑
1、Google产品经常在最初版本里只包含最基本的可用功能
在后续的快速迭代中得到内部和外部用户的反馈。
每次迭代都非常注重质量。
产品发布前，会经历金丝雀、开发、测试、beta或正式发布版本。
2、金丝雀版本
每日要构建的版本（核心开发团队成员都会安装）：
这个版本可能无法使用应有的基本功能；
安装了错误代码，手机甚至无法使用基本功能；
用来排除过滤明显不适宜的版本：
构建失败，意味着流程可能出现严重问题
3、开发版本
每周发布，该版本有一定功能并通过一系列测试：产品相关工程师会安装。
不能满足日常真实工作需求，会打回金丝雀版本：工程团队会花时间重新评估。
4、测试版本
通过了持续测试，近一月里的最佳版本。
有持续的优良表现，会作为beta测试的候选版本。
5、beta或发布版本
对外发布的第一个版本：经历了内部使用和通过所有质量考核。
五、测试类型
使用称谓：小型测试、中型测试、大型测试。
强调测试的范畴规模而非形式；规模越小，越可能被实现成自动化的测试。
1、小型测试
验证一个单独函数或独立功能模块的代码是否按预期工作。
一般是自动化实现：
几秒或更短的时间就能运行完毕。
SWE实现，也会有少量SET参与。
使用mock，在fake（虚假实现）环境中运行。
2、中型测试
验证功能模块间的交互和彼此调用时的功能是否正确。
通常也是自动化实现：
独立模块开发完后，SET会驱动这些测试的实现及运行，SWE会深度参与，一起编码、调试维护这些测试。
运行失败，SWE会自觉去查看分析原因。
开发后期，TE会通过手动的方式或自动化执行这些用例。
一般运行在虚假实现（fake）环境或真实环境中。
3、大型测试
涵盖多个模块，关注所有模块的集成，倾向于结果驱动，验证软件是否满足最终用户的需求。
或是通过自动化，或探索式测试：三种工程师都会参与；需要消耗数个小时或更长时间。
一般运行在真实环境中，并使用真正的用户数据和资源
