标签：预警 沟通 支持 软件应用 部门 好的 需求 编写 不同
《Google软件测试之道》，一直听朋友讲起这本书，出于琐事太多，一直没机会拜读，最近部门架构觉得我们IT部门的技术太low，就给我们挑选了一些书籍，让我们多看看。。。
个人的一种学习习惯吧，就做了笔记，将自己的学习理解感触写下来。。。
预计会分为五部分写这些学习笔记，分别是Google软件测试基础介绍、软件测试开发工程师、软件测试工程师、测试经理以及附录其他部分。。。
快乐阅读，快乐测试，祝愿你总能发现（并修复）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、大型测试
涵盖三个或更多的功能模块，使用真实用户场景和实际用户数据，其关注的是所有模块的集成，更倾向于结果驱动，验证软件是否满足最终用户的需求。
大型测试尝试去解决的问题是：产品的操作运行方式是否和用户期望相同，并产生预期的结果（端到端的使用场景以及整体产品或服务之上的操作）
测试的重点，应该注重测试的范畴、内容、结果，而不是这个阶段的术语；
专注，才是做技术该有的品质。。。
只有很努力，才能毫不费力。。。
转《Google软件测试之道》
标签：预警 沟通 支持 软件应用 部门 好的 需求 编写 不同
原文地址：http://www.cnblogs.com/zhujiliu/p/6430376.html
