《Google软件测试之道》简介
《Google软件测试之道》，一直听朋友讲起这本书，出于琐事太多，一直没机会拜读，最近部门架构觉得我们IT部门的技术太low，就给我们挑选了一些书籍，让我们多看看。。。
个人的一种学习习惯吧，就做了笔记，将自己的学习理解感触写下来。。。
快乐阅读，快乐测试，祝愿你总能发现（并修复）BUG。。。
————James Whittaker、Jason Arbon、Jeff Carollo（本书作者）
一、质量不等于测试
软件质量是所有人的事，而不仅仅只是测试团队的事！！！
质量不是被测试出来的，而应该从设计之初就考虑到软件应用的业务逻辑、代码code规范、测试流程安排方法、以及在开发过程中不断变更需求的应对方案。
但不经过测试的产品，也不可能拥有好的质量。
软件质量是一种预防行为，而不是测试行为。
测试是开发过程中必不可少的一部分。
开发也应该对自己编写的代码负责。
二、角色
1、软件开发工程师
software enginner，简称SWE，是一个传统上的开发角色，工作职责是实现最终用户所使用的功能代码。
开发工程师，创建设计文档、选择最优的数据结构和整体架构，并且进行代码实现和代码审核，开发工程师几乎所有时间花在代码实现上面。
2、软件测试开发工程师
software enginner in test，简称SET，也是一个开发角色，工作重心在可测试性（对开发工程师编写的代码质量和正确性的验证。
即：单元测试）和通用测试基础框架（为后续快速测试、持续集成以及自动化等测试设计测试框架、环境、工具等）。
开发测试工程师，参与设计评审，近距离观察代码质量和风险；为了增加可测试性，会对代码进行重构，并编写单元测试以及自动化测试框架。
开发测试工程师和开发工程师可以说是一体两面：SWE主要职责在于增加功能性代码或提高性能的代码，而SET更加关注质量提升和测试覆盖率增加。
相比于SWE更关注客户使用的功能的开发实现，SET更注重质量服务，其编写的代码是为了让SWE测试自己的功能。
3、测试工程师
test enginner，简称TE，和SET类似，但是把用户放在第一位，站在用户角度思考。
测试工程师把用户放在第一位来思考，将SWE和SET编写的代码分类组装，组织整体的质量实践、测试，分析解释测试运行结果，驱动测试执行，以及推动产品发布等。
4、三者的区别于关联
SWE：负责功能实现和这些独立功能的质量，对容错设计、故障恢复、测试驱动设计、单元测试负责，并和SET一起测试代码。
SET：也是开发人员，不过提供测试支持，主要是编写测试框架，将最新开发的代码隔离，在测试环境（或模拟用户真实环境）管理代码提交等；
SET编写代码，通过这些代码提供的功能让SWE能够自测；SET的目的是保证这些功能模块具有可测性，让SWE更多时间去完成代码编写。
TE： 专注用户角度的测试，由于单元测试的独立功能经过SWE和SET的测试，TE更多的是验证代码数据集成后是否可以满足最终用户需求；
其扮演一个双重确认角色：一方面确认开发人员早起的测试工作是否存在不足，另一方面参与到常见用户场景中，测试应用是否满足性能期望；
在安全性、国际化、易用性、访问权限等方面是否满足用户需求，以及和参与到软件各个阶段的人员沟通交流，讨论设计带来的风险、功能逻辑复杂性和错误避免的方法。
三、组织结构
一般情况下，开发和测试人员一般都隶属于一个部门、团队，工作汇报给同一个领导者，看起来做到了平等相处患难与共；
然而实际上，团队的领导者一般来自产品或者开发经理，在产品发布时，优先考虑的功能是否完整和易用性方面是否足够简单，缺很少考虑质量：测试总在为开发让路！！！
这就导致了市场上存在很多有缺陷的产品，出问题再发一个补丁包就行；还有就是，很多测试人员说的，公司不注重测试，测试没地位的原因！！！
在类似于Google等这样的大型互联网公司里面，测试团队是一个独立的部门，会根据不同软件产品的优先级、复杂度等因素决定分配测试人员；
测试人员对产品进行一系列提高软件质量的工作，但并不向产品开发团队汇报负责，而是对缺陷进行管理、发布，可以说测试和开发人员是相辅相成的一种并存关系。
这样的好处在于：产品质量能得到更有效控制，不用招聘更多测试人员去做一些本来应该开发应该做的事情，
做到较好的质量和成本控制（虽然会犯错，但会保持在一定的平衡范围内），还可以使测试人员保持项目产品新鲜感，以及新的有效的测试技术的推广。
个人感触：在国内的大部分互联网或者有IT部门的企业中，测试地位相对来说还是比较低，相比于产品和开发而言。原因就是：很多公司产品只要实现功能就会急于发布使用，
用户使用中出现问题，发布一个补丁包，解燃眉之急；以及产品从设计初始的业务逻辑不明确，开发测试时间紧急，需求变更频繁，开发测试人员的技术水平、整个生产流程、
管理以及上线发布的决定权等很多因素造成。
Google解决办法：在最初版本只包含基本功能，然后在后续快速迭代中通过各种途径得到内部和外部用户使用反馈，后续迭代每次都注重产品质量，一般软件应用正式与用户
见面之前都要经历下面几个版本。。。
四、版本
一个产品最终上线给予用户使用，一般都要经历一系列的内部各种验证，各版本如下：
1、每日构建版本
即金丝雀版本：对产品的代码每天都进行构建，用来排除一些不适宜的版本。
金丝雀：17世纪，英国人将金丝雀放到煤矿井中检测空气质量，如果金丝雀死了，则证明矿井中空气达到了令人中毒的水平；可以理解为一种预警机制。
如果每日构建代码失败，则表明流程的某个地方出问题了，需要进行复查，这个版本需要极强的容忍度。
2、开发版本
开发人员使用的版本，一般都是定期发布，让该产品下的所有工程师安装使用，一般它会包含一定的功能并通过了一定的测试，如果该版本不能满足日常真实工作需要，则需要打回
金丝雀版本，重新进行评估。
3、测试版本
通过了持续测试的版本，一般为一个阶段里面的最佳版本，可以作为内部评测的一个版本，如果这个版本有持续的良好表现，可以作为下一阶段的发布版本候选版本。
4、发布版本
即beta版本，是个非常稳定的测试版本，可以作为对外发布上线的版本。
上面的几种产品版本可以作为开发一款软件应用产品的参考，实际情况需要结合实际需求来界定！！！
五、测试类型
一般常说的测试阶段有代码测试（单元测试）、集成测试（接口测试）、系统测试等这些命名方式，而Google则采用小型测试、中型测试、大型测试等术语，其强调的是测试范畴而不是形式
1、小型测试
一般来说都是自动化实现的，其意味着涵盖叫少量的代码，用于验证一个单独函数或独立功能模块代码是否按照预期工作，着重于典型的功能性问题、数据损坏、错误条件和大小差异错误等验证。
小型测试一般由SWE实现，也会有少量的SET参与，小型测试主要尝试解决的问题是：这些代码是否会按照预期的方式进行。
2、中型测试
中型测试一般也是自动化实现的，一般会涉及两个或两个以上甚至更多模块之间的交互，测试重点在于验证有交互的模块之间彼此调用时的功能是否正确。
一般在独立功能模块开发完毕后，SET会驱动这些测试的实现及运行，SWE会参与，一起编码、调试和维护这些测试。
中型测试主要尝试解决的问题是：一系列有交互的模块互相调用时候，是否如我们预期的那样工作
3、大型测试
涵盖三个或更多的功能模块，使用真实用户场景和实际用户数据，其关注的是所有模块的集成，更倾向于结果驱动，验证软件是否满足最终用户的需求。
大型测试尝试去解决的问题是：产品的操作运行方式是否和用户期望相同，并产生预期的结果（端到端的使用场景以及整体产品或服务之上的操作）
测试的重点，应该注重测试的范畴、内容、结果，而不是这个阶段的术语；
专注，才是做技术该有的品质。。。
