《谷歌如何测试》续、一、二

转自：http://news.cnblogs.com/n/135787/

 

 

【续】

 

  吴军的《浪潮之巅》中有这么一章，他在里面历数了二十世纪五十年代以后的伟大的科技公司，无一例外，这些公司背后的驱动力都是技术，而技术的根本就 是人。无论是基因科技还是蓝色巨人，里面都有一批做技术的人，可能是在这个行业已经工作了 20 年，但还在一直坚持做技术的工作，也正是这些人，推动着浪潮不断地抛向更高。

在国内，多数刚刚开始工作的同学，特别是应届生或者刚刚转行到计算机工种的同学，都是非常崇敬技术的，特别是在软件公司，感觉如果做出一套优雅 的界面或者牛逼的系统，那将是一件非常�诺氖虑椤５�慢慢地随着时间的漂移，过了几年，随着一些年长的工程师的跳槽或者升迁，突然发现自己在项目组里已经是 做技术里比较厉害的一个了，于是乎，伴随着某个“机会”，从团队主管开始，慢慢地走上了“管理”的道路，与技术也渐行渐远，虽然偶尔回想起来心有不甘，有 心再去追逐，但也无能为力，技术领域日新月异的速度超过了你的想象，这仿佛变成了一个规律似的，像两千年的王朝，不断地迭代。至今，在多数国内科技公司， 很难找到工作 10 年以上技术老兵，看看一系列开发者大会上，嘉宾也多数是二三十岁的小伙。所以，对于那些坚持在一线做技术的人，非常欣赏和崇拜，相信这些人也将是推进国内 公司走向浪潮之巅的根本动力。如果有一天，你有机会站在 Career Path 的十字路口，不要犹豫，选择技术，大致原因，

 

    技术是推进社会、科技进步的根本原因；
    问下自己内心是否真的喜欢现在的状态，还是被迫上位；
    技术是了解一线问题的真正来源；听得见炮灰人，都是前线的工程师；
    管理工作主要是在做人的管理，相比较和机器与程序打交道，务虚一些，想做好比较难，特别是在当下国内的大环境，容易变形；
    招聘市场上的技术岗位远远比管理岗位多，人无远虑，必有近忧；
    薪资待遇上，技术人员越来越受重视；

好了，还是步入正题，讨论测试的事情吧。软件开发模式，特别是互联网，最近几年都在追求快速迭代发布，例如 Gmail 或者新浪微博，都是 Beta 版本线上运营，知道软件开发流程的人都清楚，Beta 版意味着潜在 Bug 和 Issue，离正式的 Release 还有一段距离，但还是会带着潜在风险上线。为什么这样，难道是没有经过系统的测试？真正的原因还是风险的控制，详细的几点原因以后再讲。但却造就了一些对 测试的误解，

 

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

等等诸如此类的误解，让许多不明真相的群众，特别是应届生，都不会把测试作为自己的职业规划来考虑，让我们的招聘 HR 也伤透了脑筋。也想通过这个系列的讨论，让大家清楚测试工作如果做好，方法其实并不是想象中的那么简单和表面上的肤浅，是非常好有挑战的。

 

谷歌是众所周知的互联网技术的圣地，其搜索和大规模数据存储和计算方面的技术领先业内，也是目前站在互联网浪潮之巅上最大的一朵浪花，其背后的 工程学技术也是工程师津津乐道的话题。James whittaker 是 Google 的测试总监，自 2011 年 1 月 25 号至 2011 年 5 月 4 号，在

Google Testing Blog

(可惜被墙)上持续发表了 7 篇<How Google Tests Software>系列文章来介绍谷歌是如何测试的。在 2011 年 10 月的 GTAC 大会期间，跟其有过一些交流，告诉了他将这系列文章翻译成中文的想法，他也非常支持，并要送我一本即将出版的《

 

How Google Tests Software

》纸制书。只可惜，2012年2.13日他已经从谷歌离职，这本书还没有出版（Amazon 上介绍是 April 8, 2012 出版，由于他的离职，不知是否还能按时出版）。 

总之，探求和揭示谷歌公司背后的测试方法也算是缓解测试工程师们在窥视癖方面某种程度的需求，但能力着实有限，翻译过程中会采用意译的方式，若有不同建议，还请指正。

另外一个想做《谷歌如何测试》翻译的原因，在各大搜索引擎上还没有搜索到这系列文章比较好的翻译，只找到“外刊 IT 评论”翻译的《谷歌如何测试》第三篇和“译言网”翻译的第一篇，内容有些不全，关键感觉翻译的质量感觉不是很好。总之，整个系列还没有人翻译，且我本人在 软件测试领域工作了也近 8 年，对技术还算比较感兴趣，在这里做个尝试吧

 

一、二 转自http://news.cnblogs.com/n/134822/

 

  By James Whittaker

 How Google Tests Software - Part One
How Google Tests Software - Part Two

【一】

   　　在所有我被问及的问题中，最多的就是关于谷歌是如何测试的。尽管在博客中（google testing blog）中有过零碎的解释说明，但还是需要更多的系统阐述。虽然谷歌的技术路线在执行的过程中不断地进化，但公司的测试策略却从来没有变化过。谷歌现在 是一家拥有搜索、应用、广告、移动、操作系统等产品的公司，我们在这些涉及到的产品领域里发挥着非常有意义的作用。当我们涉及到一些新的领域或者在旧领域 里快速成长的时候，必须要求我们的测试也在同步的扩张和改进。在这个系列文章中提及的测试技术，多数是我们当前正在使用的，还有一些是希望以后在不久的将 来可以用到。

   　　首先，先介绍一下组织结构，这一部分也可能会让你感到惊奇。其实在谷歌没有真正的测试部门，测试依托在各个产品领域部门里，我们称之为“工程生 产力”（Engineering Productivity）。工程生产力部门拥有数量不等的水平或者垂直的工程学科，测试是其中的大头。简单地说，工程生产力部门由以下几部分构成：

   　　1. 一个工具产品团队（a product team），负责内部和外部开源的促进生产力的工具开发与维护，这些工具会被公司范围内的各种工程师使用。这些工具包括代码分析工具、IDE、测试用例管 理系统、自动化测试工具、Build 系统、源码管理系统、代码审核调度系统、缺陷管理系统等等。 这些工具的都是为了提高工程师效率的，并且这些工具在策略上的目标多数是为了防止问题的发生，而不是发现问题本身。

  　　2. 一个服务团队（a services team），给产品部门（注：这里的产品部门团队是和工程生产力部门平级的，例如 Search、Gamil、Chrome 等产品部门）提供一些专业的建议，包括一系列工具、文档、测试、发布管理、培训等方面，这些专家建议涵盖可靠性、安全、国际化等，甚至包括产品团队面对的 功能问题。所有的其他产品领域也都会得到这样的建议指导。
  　　
      3. 嵌入式的工程师（Embedded engineers），在需要的时候被产品部门高效地“借”去使用，这些工程师有些会和产品部门的团队坐在一起工作数年，另外一些当他们被需要的时候会被 借调到其他的产品团队。谷歌鼓励所有他们的工程师更换产品团队，用以保持团队忙绿且不断有新面孔，并如实地不带有任何偏见与政治。测试人员也是这样，但是 可以有节奏地选择更换产品团队的频率。我的下属里，有测试人员已经在 Chrome 团队工作了好几年，也有一些待了一年半后就换到了其他团队。对于测试经理来说，必须在团队的产品经验和新鲜度上做出很好的平衡。

  　　所以这意味着测试同学向工程生产力部门的经理汇报，但是他们会把自己看成产品部门团队的一员，像搜索、邮箱、和 Chrome 部门。从组织架构上看， 测试都是两个团队的一部分。测试和产品团队坐在一起，参与计划，一起吃饭，共享奖金，享受像全职的产品团队成员一样的待遇。这种单独的组织汇报关系的好处 是可以给测试人员之间提供良好的共享信息的讨论机会，好的测试思路可以很容易的在工程生产力部门内部蔓延，无论公司内的哪条产品线，都可以很快地使用这些 最好的测试技术。

  　　测试人员的这种项目分离和汇报组织结构也有它的缺点，目前来看，最大的问题是测试人员被看做外部资源。产品部门团队不能对测试人员有太多的依 赖，他们自己必须要合理地控制产品质量。是的，没错，在谷歌，是产品部门团队对产品质量负责，而不是测试人员。每个产品部门的开发人员都需要做测试工作， 测试人员的任务是为产品部门团队搭建自动化测试基础设施和流程，测试人员让开发可以自给自足地、独立地做完成测试工作。

  　　在这种模式下，我比较喜欢的是，开发和测试将有相同的地位。在质量方面，开发和测试成为了真正的伙伴，最大的质量重担交给本应属于的开发人员， 开发的职责就是正确地实现产品功能。另外这样可以保持多对一的开发测试比率，开发人员在数量上远超测试人员，并且测试工作做的越多，开发测试比率就会越 大。产品部门团队也会对这样的高开发测试比率而感到骄傲。
  　　
    好，现在好像大家都是好朋友了，对吧？ 相信你已经看到这种模式的一个问题，开发人员不能很好地驱动缺陷（Bug）的运转，开发不会测试。难道我要否认这一点么？不管怎样，我都不会否认，特别是 去年在 GTAC talk （GTAC 2010: Turning Quality on its Head，link http://www.youtube.com/watch?v=cqwXUTjcabs） 上做了一个开发和测试对抗的游戏后。（友情提示：测试赢了游戏）（这里感觉翻译的不好，原文是： No amount of corporate kool-aid could get me to deny it, especially coming off my GTAC talk last year where I pretty much made a game of developer vs. tester (spoiler alert: the tester wins).）

  　　在谷歌，解决这个问题的办法是将角色再细分，我们通过设立不同的测试角色来解决这两种不同的测试问题。在下一篇文章里，我将详细阐述这些测试角色和谷歌是怎样将测试问题分成两部分来分别解决的。

  【二】

  　　为了实现”谁的屁股谁自己擦”这句名言所说的那样，在传统的软件开发人员的之上，有必要增加了几个角色，特别是需要工程技术方面的特殊角色，这 种角色可以让开发更高效低做测试。在谷歌，这样角色的职责是让其他人工作的更有效率，这样的工程师通常会把自己当做测试人员，但他们真正的使命是提高生产 力/ 生产率。他们的存在是为了让开发人员效率提升，特别是在质量方面的提升，因为产品质量是生产率中最重要的一部分。这里是这些角色的总结：

  　　（注，“you build it, you break it”， you build it ，you break it ， you fix it, 原意指在 Build Lab 的人永远不会去修复 build break 的问题，只有开发人员自己才能修复。这里的意思是开发人员自己要对自己写的代码负责，比专职的测试人员更适合做测试工作。这里意译为”谁拉的 shi，谁的屁股谁自己擦”）

  　　软件开发工程师（SWE，Software Engineer）， 就是传统的开发人员。软件工程师实现一些功能代码并把最终产品提供给用户使用，他们创建设计文档、设计数据结构和总体的架构搭建，他们大多数时间都在写代 码和评审代码。同时，他们也会写很多的测试代码，包括测试驱动设计，单元测试，并参与后面的文章会讲到的小、中、大型测试的创建工作。软件工程师需要对他 们自己写的代码、修复缺陷的代码、改进的代码，只要是他们接触过的代码的质量负责。

  　　软件测试开发工程师（SET or Software Engineer in Test），和软件开发工程师一样是开发工程师，主要负责软件的可测试性。他们参与设计评审，近距离地关注代码质量和风险，对代码做重构为了系统有更好的 可测试性，同时他们负责写单元测试框架和自动化测试的框架。在代码级别上他们和软件开发工程师是合作伙伴，但如果和增加新功能或提升性能相比较，他们更关 心产品的质量和测试覆盖率的提升。

  　　软件测试工程师（Test Engineer），和软件测试开发工程师（SET）恰恰相反，他得主要工作是做测试而不是开发。许多谷歌的软件测试工程师会花很多的时间在写测试代码 上，包括自动化脚本、使用场景的代码、甚至模拟最终用户的操作方面的代码。他们对软件开发工程师和软件测试开发工程师的测试工作做一些组织安排，解释测试 结果、驱动测试的执行，特别是在项目即将发布的后期将起到非常重要的作用。软件测试工程师既是产品专家也是质量顾问更是风险分析师。

  　　从质量的角度来看，软件开发工程师对功能开发和质量负有全责。同时，他们还负责容错设计、故障恢复、TDD、单元测试、和在软件测试开发工程师的帮助下写测试代码，这些测试代码会验证开发的功能。

  　　软件测试开发工程师是提供测试支持的开发人员。他们提供一种能够将新添加的代码通过模拟其依赖的方式做功能验证的技术框架，并应用在代码提交之 前的提交队列管理之中（注，这样可以在代码 check in 的时候保证新代码的功能完备）。可以这样说，软件测试开发工程师就是为了让软件工程师可以测试他们的功能代码，所有真正的测试都是软件开发工程师完成的， 软件测试开发工程师是保证这些功能有很好的可测试性，这样可以让软件开发工程师很积极地参与到测试用例代码的编写中去。

  　　现在所有的一切很清楚了，软件测试开发工程师就是服务人员，他们的主要职责就让开发人员很方便简单的做测试并保证模块级别的产品质量。读者可能已经意识到一个问题，在这样的研发流程下，使用软件的最终用户会怎样？

 　　在谷歌，软件测试工程师的职责就是最终用户级别的测试。如果软件开发工程师和软件测试开发工程师很好地做了模块级别的功能测试，下一个工作就是 看许多功能集成和数据的组合是否能够满足最终用户的使用需求。软件测试工程师在这里就是扮演一个双重确认开发工程师测试工作的角色，任何明显的缺陷都会说 明之前一轮的开发自测不够或比较草率，如果没有出现这种情况之后，软件测试工程师会将注意力转移到普通用户的使用场景测试上，保证性能、安全、国际化等方 面没有问题。软件测试工程师们需要做大量的测试工作，并在测试工程师、测试合同工、吃狗粮的尝鲜者、beta 测试用户、早期最终用户之间做很多沟通交流的工作，他们会和基础设计、功能复杂度、避免错误的方法等方面遇到问题的人做确认。一旦软件测试工程师开始介 入，总是会没完没了。