标签：探索式测试 可靠性 软件开发 承担 场景 测试框架 失败 互联网 编码
1、在Google，软件测试团队归属于一个被称为“工程生产力”(Engineering Productivity，工程效率或工程生产率)的中心组织部门，这个部门的职责横跨开发测试人员使用工具的研发、产品发布和各种级别的测试，从单元级别的测试到探索性级别的测试。Google拥有大量针对互联网产品的共享工具与测试基础框架，服务于包括搜索、广告、Apps、YouTube视频和其他我们在Web上提供的产品。
2、Google是一家以创新和速度为基础的公司，快速地发布有用的代码(如果失败，也只有少数早期用户会失望)、迭代地增加早期用户希望使用的功能(最大化用户反馈)。在这样的环境下，测试不得不变得异常灵活，并且在技能上要做许多前期的规划，只是不停地简单维护并不能真正解决问题。有时，测试和开发互相交织在一起，达到了无法区分彼此的程度，而在另外一些时候，测试和开发又是完全分离，甚至开发人员都不知道测试在做些什么。
3、当有人来问我，Google成功的关键是什么，我的第一个建议就是，不要招聘太多的测试人员。
4、质量不等于测试，当你把开发过程和测试过程放到一起，就像在搅拌机里混合搅拌那样，知道不能区分彼此的时候，你就得到了质量。
5、测试时开发过程中必不可少的一部分，当开发过程和测试一起携手联姻时，既是质量达成之时。
6、角色
(1)软件开发工程师(SWE)：工作是实现最终用户所使用的功能代码。他们创建设计文档、选择最优的数据结构和整体架构，并且花费大量时间在代码实现与代码审核上。SWE需要编写与测试代码，包括测试驱动的设计、单元测试、参与构建各种大小规模的测试等。SWE会对他们编写、修复以及修改的代码承担质量责任。
(2)软件测试开发工程师(SET)：工作中心在ke‘ce‘shi‘xing 和通用测试基础框架上。他们参与设计评审，非常近距离的观察代码质量和风险。为了增加可测试性，他们甚至会对代码进行重构，并编写单元测试框架和自动化测试框架。SET是SWE在代码库上的合作伙伴，相比较SWE是在增加功能性代码或是提高性能的代码，SET更加关注于质量提升和测试覆盖率的增加。
(3)测试工程师(TE)：是一个和SET关系密切的角色，有自己不同的关注点——把用户放在第一位来思考，代表用户的利益。一些Google的TE会花费大量时间在模拟用户的使用场景和自动化脚本或代码的编写上。同时，他们会把SWE和SET编写的测试分门别类地组织起来，分析、解释、测试运行结果，驱动测试执行，特别是在项目的最后阶段，推进产品发布。TE是真正的产品专家、质量顾问和风险分析师。
7、组织结构
(1)Google的组织汇报关系被划分为不同的专注领域(Focus Areas)。这些专注领域包括客户端(Chrome、Google工具栏等、地理(地图，Google Earth等)、广告、Apps、移动等等。所有的开发工程师都汇报给这些专注领域的管理者、总监或副总裁。
(2)测试是独立存在的部门，是与专注领域部门平行的部门(横跨各个产品专注领域)，我们称为工程生产力团队。测试人员基本上以租借的方式进入产品团队，去做提高质量相关的事情，寻找一些测试不足的地方，或者公开一些不可接受的缺陷率数据。由于测试人员并不是直接向产品团队进行汇报，因此我们并不是简单地被告知某个项目急需发布就可以通过测试。我们有自己选择决定的优先级，在可靠性、安全性等问题上都不会妥协，除非碰到更重要的事情。工程生产力团队会根据不同产品团队的优先级、复杂度，并与其他产品实际比较之后，再来分配测试人员。
8、爬，走，跑
(1)Google经常在最初的版本里只包含最基本的可用功能，然后再后继的快速迭代的过程中得到内部和外部用户的反馈，而且在每次迭代地过程中都非常注重质量。一个产品在发布给用户使用之前，一般都要经历金丝雀版本、开发版本、测试版本、beta或正式发布版本。
(2)金丝雀版本：这是每日都要构建的版本，用来排除过滤一些明显不适宜的版本。一般来说，只有这个产品的工程师(开发或测试人员)和管理人员才会安装使用金丝雀版本。
(3)开发版本：这是开发人员日常使用的版本，一般是每周发布一个。该版本具有一定的功能并通过了一系列的测试。所有这个产品下的开发人员都会被要求去安装这个版本，并在日常工作中真正使用它，这样可以持续对这个版本进行测试。如果一个开发版本不能满足日常真实工作的需求，那么它将会被打回为金丝雀版本。
(4)测试版本：只是一个通过了持续测试的版本。这个版本基本上是最近一个月里的最佳版本了，也是工程师在日常生活中使用的最稳定最信任的一个版本。测试版本可以被挑选作为内部尝鲜版本，如果该版本有比较持续的优良表现，也是作为beta测试的候选版本。
(5)beta或发布版本：这个版本是由非常稳定的测试版本演变而来，并经历了内部使用和通过所有质量考核的一个版本，也是对外发布的第一个版本。
9、测试类型
(1)小型测试一般来说都是自动化实现的，用于验证一个单独函数或独立模块的代码是否按照预期工作，着重于典型功能性问题、数据损坏、错误条件和大小差一错误(off-by-one错误是一种常见的程序设计错误)等方面的验证。小型测试的运行时间一般较短，通常是在几秒或更短的时间内就可以运行完毕。通常，小型测试是由SWE实现，也会有少量的SET参与，TE几乎不参与小型测试。小型测试一般需要使用mock和fake(mock对象是指对外面以来系统的模拟，在运行时刻可以根据假设的需求提供期望的结果，fake对象是一种虚假的实现，内部使用了固定的数据或逻辑，只能返回特定的结果)才能运行。TE几乎不编写小型测试代码，但会参与运行这些测试，来诊断一些特定错误。小型测试主要尝试解决的问题是“这些代码是否按照预期的方式运行”。
(2)中性测试通常也都是自动化实现的。该测试一般会涉及两个或两个以上，甚至更多模块之间的交互。测试重点在于验证这些“功能近邻区”之间的交互，以及彼此调用时的功能是否正确(我们城功能交互区域为"功能近邻区")。在产品早期开发过程中，在独立模块功能被开发完毕之后，SET会驱动这些测试的实现及运行，SWE会深度参与，一起编码、调试和维护这些测试。如果一个中型测试运行失败，SWE会自觉地去查看分析原因。在开发过程的后期，TE会通过手动的方式(如果比较难去实现自动化或实现的代价较大时)，或者自动化地去执行这些用例。中型测试尝试去解决的问题是，一系列邻近的模块互相交互的时候，是否如我们预期的那样工作。
(3)大型测试涵盖三个或三个以上(通常更多)的功能模块，使用真实用户使用场景和实际用户数据，一般可能需要消耗数个小时或更长的时间才能运行完成。大型测试关注的是所有模块的集成，但更倾向于结果驱动，验收软件是否满足最终用户的需求。所有的三中工程师角色都会参与到大型测试之中，或是通过自动化测试，或是探索式测试。大型测试尝试去解决的问题是，这个产品操作运行方式是否和用户的期望相同，并产生预期的结果。这种端到端的使用场景以及在整体产品或服务之上的操作行为，即是大型测试关注的重点。
标签：探索式测试 可靠性 软件开发 承担 场景 测试框架 失败 互联网 编码
原文地址：https://www.cnblogs.com/JennyShen/p/9786987.html
