[关闭]
@zhouyy 2017-07-24T06:07:16.000000Z 字数 2278 阅读 607

第一章 google软件测试介绍

book


核心内容:

 作为一个google测试人员究竟意味着什么,同时也包含google如何解决软件在扩展性、复杂性和大并发方面的问题。

1.1质量不等于测试

把开发过程和测试融合在一起:开发和测试必须同时开展。开发对质量负责。质量更像是一种预防行为,而不是检测。

1.2 角色

1.2.1 软件开发工程师(SWE)

实现最终用户所使用的代码。他们创建设计文档、选择最优的数据结构和整体结构,并且花费大量时间在代码实现与代码审核上。SWE需要编写和测试代码,包括测试驱动的设计、单元测试、参与构建以及修改的代码承担质量责任。

1.2.2 软件测试开发工程师(SET software engineer in test)

工作重心在可测试性和通用测试基础框架上。为了增加可测试性,他们甚至会对代码进行重构,并编写单元测试框架

1.23 测试工程师(TE)

关注点:把用户放在第一位来思考,代表用户的利益。一些google的TE会花费大量的时间在模拟用户的使用场景和自动化脚本或代码的编写上。同时,他们会把开发工程师和SET编写的测试分门别类地组织起来,分析、解释、测试运行结果,驱动测试执行,特别是在项目的最后阶段
SET也是开发人员,负责提供测试支持。有这样一个测试框架,可以把新开发的代码隔离,通过模拟一个真实的工作运行环境和代码的提交。SET编写代码,通过这些代码提供的功能让SWE能够自己测试他们的功能。多数测试代码是由SWE完成,SET存在的目的是保证这些功能模块具有可测试性,并且相应的SWE还可以积极参与到测试代码的编写中去。
SET的主要关注对象是开发人员。SWE和SET已经做了足够多的模块级别与功能级别的测试,下一步要考虑的是要验证这些可执行的代码与数据集成在一起之后,是否可以满足最终用户的需求。
TE扮演一个双重确认的角色,确认开发人员在测试方面的工作是否到位,当明显的bug变少时,TE会把注意力转移到常见的用户场景中去

1.3 组织结构

资深管理者一般都来自产品经理或开发经理,而不是来自于测试团队。在产品发布时,有限考虑的是功能的完备性和易用性方面是否足够简单,却很少考虑质量问题。作为一个团队,测试总是在为开发让路。
开发工程师汇报给专业领域的管理者。但SET和TE是与专注领域平行(横跨各个产品专业领域)的部门。测试人员基本上以租借的形式进入产品团队,但并不向产品团队进行汇报。工程生产力团队会根据不同产品团队的优先级、复杂度,并与其他产品实际比较后,再来分配测试人员。但总体上,这样会保持实际的需求与不明确需求之间的某种平衡

1.4 爬、走、跑

Google经常在最初的版本里只包含最基本的可用功能,然后在后继的快速迭代的过程中得到内部和外部用户的反馈,而且在每次的过程中都非常注重质量。一个产品在发布给用户之前,一般都要经历金丝雀版本、开发版本、测试版本、beta或正式发布版本

这是每日都要构建的版本,用来过滤一些明显不适宜的版本。如果构建失败,意味着我们的流程可能在哪里出了严重的问题。

这是开发人员日常使用的版本,一般是每周发布一个。该版本具有一定的功能并通过一系列的测试。这个产品下的工程师都会被要求安装这个版本,并在日常生活中真正使用它。如果不能满足日常需求,将被打回金丝雀版本。

这是通过了持续测试的版本。基本上是最近一个月里的最佳版本,也是工程师使用最稳定最信任的一个版本

这个版本是由非常稳定的测试版本演变而来,并经历了内部使用和通过所有质量考核。

1.5 测试类型

小型测试、中型测试、大型测试着重强调测试的范畴规模而非形式

小型测试 一般都是自动化实现,用于一个单独的函数或者独立功能模块的代码是否按照预期工作,着重于典型功能性问题、数据损坏、错误条件和撒小差一(off-by-one)等方面的验证。小型测试的运行时间一般比较短,通常在几秒或者更短的时间内就可以运行完毕。一般由SWE来实现,也会有少量SET,TE几乎不参与。小型测试一般需要使用mock和fake(mock是指对外界依赖系统的模拟,在运行时可以根据假设的需求提供期望的结果。Fake对象是一种虚假的实现,内部使用了固定数据或逻辑,只能返回特定的结果)才能运行。TE几乎不编写小型测试代码,但会参与运行这些测试,来诊断一些特定错误。小型测试主要尝试解决的问题是“这些代码是否按照预期的方式运行”

中型测试 通常也是自动化实现的。该测试一般会涉及两个或两个以上,甚至更多模块之间的交互。测试的重点在于验证这些“功能近邻区”之间的交互,以及彼此调用时的功能是否正确。产品开发早期,在独立模块被开发完毕后,SET会驱动这些测试的实现及运行,SWE会深度参与,一起编码、调试和维护这些测试。在开发后期,TE会通过手动的方式,或者自动化地执行这些用例。中型测试尝试去解决的问题是,一系列临近的模块互相交互的时候,是否会如我们预期那样

大型测试 涵盖三个或以上(通常更多)的功能模块,使用真实用户场景和实际用户数据,一般可能需要消耗数个小时或更长的时间运行完成。大型测试关注的模块的集成,但更倾向于结果驱动,验证软件是否满足最终用户的需求。所有的三种角色都会参与到大型测试中,或是通过自动化测试,或是探索式测试。

小型测试涵盖单一的代码段,一般运行在完全虚假实现(fake)的环境里。中型测试涵盖多个模块且重点关注模块之间的交互上,一般运行在虚假实现(fake)环境或真实环境之中。大型测试涵盖任意多个模块,一般运行在真实的环境中,并使用真正的用户数据与资源

添加新批注
在作者公开此批注前,只有你和作者可见。
回复批注