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