《Google软件测试之道》- Google软件测试介绍

2015-05-21

1 质量与测试
2 角色
3 组织结构
4 爬、走、跑
5 测试类型
相关链接

与Microsoft相比，Google的测试团队并非雄兵百万，更象是小而精的特种部队，依靠的是出色的战术和高级武器。Google信奉“少则清晰”。

1 质量与测试

测试是开发过程中必不可少的一部分，当开发过程和测试一起携手联姻时，即是质量达成之时。

软件开发工程师（software engineer，简称SWE）：传统的开发角色，与测试相关的是：代码审核，编写与测试代码，包括测试驱动的设计、单元测试、参与构建各种大小规模的测试等。

软件测试开发工程师（software engineer in test，简称SET）：重心在可测试性和通用测试基础框架。参与设计评审，非常近距离的观察代码质量和风险。

注意：SET和SWE在代码库上的合作伙伴，与增加功能性代码或提高性能的代码SWE相比，SET更加专注质量的提升和测试覆盖率的增加。SET写代码的目的是可以让SWE测试自己的功能。

测试工程师：（test engineer，简称TE）：TE把用户放在第一位来考虑。TE组织整体质量实践，分析解释测试运行结果，驱动测试执行，构建端到端的自动化测试。

从质量角度来看：

Google的组织汇报关系被划分为不同的专注领域（Focus Area）。这些专注领域包括客户端（Chrome、Google工具栏等）、地理（地图、Google Earth等）等等。所有开发工程师都汇报给这些专注领域的管理者。

测试是独立存在的部门，是与专注领域部门平行的部门（横跨各个产品专注领域），我们称之为工程生产力团队。测试人员基本上是以租借的方式进入产品团队。生产力团队会根据不同的产品团队的优先级、复杂度、并与其他产品实际比较之后，在来分配测试人员。

在拥有如此少量测试人员的情况下，Google还能取得不错的成果，核心原因在于：Google从来不在一次产品发布中包含大量的功能。实际上，恰恰相反，在一个产品的基本核心功能实现之后，就立即对外发布使用，然后从用户那里得到真实反馈，再进行迭代开发。

例如Chrome，根据我们对产品的信心以及来自用户的反馈，我们在整个过程中使用了不同的版本，大致顺序如下：

这种爬、走、跑的模式，给我们的应用程序尽早的提供了一个测试验证的良好机会。与从自动化测试那里得到的反馈一样，我们每天都能从内部用户那里得到关于这些版本的质量反馈。

Google并没有使用代码测试、集成测试、系统测试这些命名方式，而是使用小型测试、中型测试、大型测试这样的称谓，着重强调测试的范畴规模而非形式。

表1 测试类型

名称	参与者	自动化	方式及任务	解决的问题
小型测试	主要由SWE，少量由SET，TE几乎不参与	绝大部分	用于验证单独函数或独立功能模块，着重于典型的功能性问题、数据损坏、错误条件和大小差一错误等方面的验证。一般需要使用mock和fake。	这些代码是否按照预期的方式运行。
中型测试	SET会驱动这些测试的实现及运行，SWE会深度参与,一起编码维护这些测试	绝大部分	一般会涉及两个或两个以上模块之间的交互。	一系列临近的模块互相交互的时候，是否如我们预期的那样工作。
大型测试	三种工程师角色都会参与到大型测试之中	大部分	涵盖三个或以上的功能模块，使用真实用户使用场景和实际用户数据,大型测试关注的是所有模块的集成,但更倾向于结果驱动,验证软件是否满足最终用户的需求。	这个产品操作方式是否和用户的期望相同，并产生预期的结果。

对于所有的三种类型测试,Google更倾向于做自动化测试,当然Google也有大量的手动测试.它更倾向于测试新功能,用户体验,隐私之类东西。