“窥探”谷歌测试

一淘网测试架构师黄利在他的博客上发布了翻译的一个专题系列文章：《谷歌如何测试》，整个系列文章从全局到局部地介绍了谷歌有关测试的情况。

译者黄利在《译者序》中阐述了在软件开发模式（尤其是互联网）中，近几年的快速迭代发布，以 Beta 版本线上运行，让大家对测试产生了一些误解：

• 这些应用没有经过很好地测试，好多功能使用上都有问题；
• 测试水平比较有限，没有能及时的发现潜在问题；
• 测试本身没有太多的技术，基本上是功能确认，点点鼠标、搭建环境验证下就可以；
• 只要认真仔细，有责任心就可以做好测试；

这些误解让很多人特别是应届生，都不会把测试作为职业规划来考虑，黄利表示:“想通过这个系列的讨论，让大家清楚测试工作如果做好，方法其实并不是想象中的那么简单和表面上的肤浅，是非常好有挑战的。”

关于《谷歌如何测试》，黄利已经翻译了六篇：

• 第一篇：介绍谷歌工程生产力部门构成，以及这种测试人员的项目分离和汇报组织结构的优点与缺点。

谷歌没有真正的测试部门，测试依托在各个产品部门里，即“工程生产力”，这个部门由以下几个团队组成：工具产品团队（负责内部和外部开源的促进生产力的工具开发与维护）；服务团队（给产品部门提供一些专业的建议，包括一系列工具、文档、测试、发布管理、培训等方面，这些专家建议涵盖可靠性、安全、国际化等，甚至包括产品团队面对的功能问题）；嵌入式的工程师（在需要的时候被产品部门高效地“借”去使用）。

在测试人员的这种项目分离和汇报组织结构中，其优点是开发和测试将具有相同的地位，缺点则由于测试人员被看做外部资源，产品部门团队不能对测试人员有太多的依赖，他们自己必须要合理地控制产品质量。

• 第二篇：为了让开发人员效率提升，特别是在质量方面的提升，在传统的软件开发人员的之上，增加了几个角色，特别是需要工程技术方面的特殊角色。

将工程师的角色细分为：软件开发工程师【SWE，Software Engineer】， 就是传统的开发人员；软件测试开发工程师【SET or Software Engineer in Test】，和软件开发工程师一样是开发工程师，主要负责软件的可测试性；软件测试工程师【Test Engineer】，和软件测试开发工程师【SET】恰恰相反，主要工作是做测试而不是开发。

从质量的角度来看，软件开发工程师对功能开发和质量负有全责，软件测试开发工程师是提供测试支持的开发人员，软件测试工程师的职责就是最终用户级别的测试。

• 第三篇：质量不等于测试，“质量不是被测出来的”。

最简单的办法是不要区分开发和测试，不要把他们当成对立的活动。测试和开发【注，两种行为，不是人】最好能手牵手的并行，写一点代码就立刻进行测试，写的越多，测的就要越多。最好是，在编码的同时，甚至在编码之前，就考虑清楚这些代码将如何被测试。测试不是一个单独的工作，测试就是开发的一部分。所以，质量并不等同于测试，当把开发和测试混在一起，搅拌直到分不清他们彼此的时候，就得到了质量。

对于质量来说，预防问题比发现问题本身更重要。质量是开发人员的问题，而不是测试人员的问题。通过把测试工作融入到开发过程中，我们能降低那些富产 Bug 的人的出错机会，不仅可以避免了大量最终用户的使用问题，而且还可以极大地降低测试人员报无效 Bug 的数量。在谷歌软件测试工程师的工作目标就是检查这种预防措施是否有效，软件测试工程师不停地寻找一些证据来证明作为 bug 的作者和预防者的“软件开发工程师 - 软件测试开发工程师”组合是否存在问题，一旦发现任何不正常，就会拉响警笛。

•第四篇：从爬到走、走到跑的模式，在一个产品的核心模块被开发后，如果有一定数量的受益人群就立刻发布，然后不断的得到用户反馈再迭代开发新功能。

这样爬、走、跑的模式对分析也有益处。例如，发现了一个 bug，测试人员可以根据这个 bug 创建一个测试用例，并针对所有的每一个版本都运行这个测试用例，从而可以验证这个 bug fix 是否在所有的版本中都真正得到了修复。

• 第五篇：测试范围的定义，以及自动化测试和手动测试。

“哪些需要被测试及测试范围的确定，这是一个动态变化的过程，在不同的产品之间会有比较大的差异。谷歌更倾向于频繁发布，从产品的外面用户那里得到反馈之后再迭代开发。”

“自动化测试和手动测试，对于所有的三种类型测试【小规模、中等规模、大规模测试】来说当然更喜欢前者。如果能够被自动化，而且不需要任何人智力和直觉判断，那就应该把它变成自动化的。只有在特别需要人为判断的时候，例如用户的界面是否漂亮、或暴漏一些涉及用户隐私的内容时，在这些情况下应该保留手动测试。

对于谷歌来说非常重要的是仍然使用了大量的手动测试，不管是使用文本记录的方式还是使用探索性测试，虽然有些已经进入了自动化测试的视线。业界使用的录制技术将手动测试转变成自动化测试，可以在每个版本后自动地重复运行，这样保证了最少的回归工作，并把手动测试的重点放在新问题上。而且，谷歌已经将提交 BUG 的过程和一些手动测试的日常工作也自动化了。

人类智慧的最后一英寸”体现在测试设计上，谷歌的下一代测试工具也正在这个方向上努力尝试，将其自动化。

• 第六篇：软件测试开发工程师【SET】的生命

“软件测试开发工程师【Software Engineers in Test】是软件工程师，专注在测试实现。首先，软件测试开发工程师是开发角色”

“通常来说，软件测试开发工程师不会在早期设计阶段就介入。”

“当我说“测试”时，并不是仅仅意味着单纯的检查验证代码路径。测试人员不是从开始就参与进来的，但“测试”却至始至终都有。实际上，一个开发尝试去 check in 代码的时，测试人员的影响力在这个时刻可能就已经显现出来了。”

这个系列的文章还没有完结，也欢迎大家继续关注黄利的博客分享，并通过 InfoQ 网站及 InfoQ 微博等方式参与讨论。

感谢黄玲艳对本文的审校。

给InfoQ 中文站投稿或者参与内容翻译工作，请邮件至 editors@cn.infoq.com 。也欢迎大家通过新浪微博（ @InfoQ ）或者腾讯微博（ @InfoQ ）关注我们，并与我们的编辑和其他读者朋友交流。