《Google软件测试之道》—第2章2.2节测试认证

本节书摘来自异步社区《Google软件测试之道》一书中的第2章2.2节测试认证，作者【美】James Whittaker , Jason Arbon , Jeff Carollo，更多章节

内容可以访问云栖社区“异步社区”公众号查看。

2.2　测试认证
Patrick Copeland在本书的序中强调了让开发人员参与测试的难度。招聘到技术能力强的测试人员只是刚刚开始的第一步，我们依然需要开发人员参与进来一起做测试。其中我们使用的一个

关键方法就是被称为“测试认证”（译注：Test Certified）的计划。现在回过头来再看，这个计划对开发人员做测试这个根深蒂固文化的形成有着巨大的帮助。

测试认证最初以竞赛的方式进行。如果我们把测试认证做成一个富有声望的事情，这会让开发对测试重视起来吗？如果开发人员遵循一些特定的测试实践，并拿到期望的结果，我们能说他们通过了认证吗？然后再给他们授予一个象征性的徽章（见图2.12），使得他们拥有炫耀的资本吗？

续通过水平考核，最终达到级别5，与外部的能力成熟度模型一样，例如CMM能力成熟度模型（译注：http://www.sei.cmu.edu/cmmi/start/faq/related-faq.cfm）。

测试认证级别摘要

级别1

使用测试覆盖率工具。
使用持续集成。
测试分级为小型、中型、大型。
明确标记哪些测试是非确定性的测试（译注：非确定性测试指测试结果不确定的用例）。
创建冒烟测试集合。
级别2

如果有测试运行结果为红色（译注：表示运行失败的用例）就不会做发布。
在每次代码提交之前都要求通过冒烟测试。
各种类型测试的整体增量覆盖率要大于50%。
小型测试的增量覆盖率要大于10%。
每一个功能特性至少有一个与之对应的集成测试用例。
级别3

所有重要的代码变更都要经过测试。
小型测试的增量覆盖率要大于50%。
新增的重要功能都要经过集成测试的验证。
级别4

在提交任何新代码之前都会自动运行冒烟测试。
冒烟测试必须在30分钟内运行完毕。
没有不确定性的测试。
总体测试覆盖率应该不小于40%。
小型测试的代码覆盖率应该不小于25%。
所有重要的功能都应该被集成测试验证到。
级别5

对每一个重要的缺陷修复都要增加一个测试用例与之对应。
积极使用可用的代码分析工具。
总体测试覆盖率不低于60%。
小型测试的代码覆盖率应该不小于40%。
最初这个计划在一些测试意识较高的团队中缓慢试水，这些团队成员热衷于改进他们的测试实践。经过在这几个团队的成功试验之后，一个规模更大的、公司级别的认证竞赛开始推行起来了

，然后在新加入的团队中再推行这个计划就变得容易的多。

这并不像一些人想象的那么难以被接受，开发团队也从中收益颇丰。

开发团队得到许多优秀测试人员的关注，这些测试人员一般都报名成为测试认证教练。在一个测试资源稀缺的文化氛围里，注册参加这个项目会吸引到比一般团队更多的测试人员的加入。
他们获得专家的指导，并学习到如何更好地编写小型测试。
他们知道哪个团队在测试上做的比较好，并向这个团队学习。
他们能够向其他的认证级别较低的团队进行炫耀。
经过公司级别的推进，绝大多数团队都在不断向前进步，并意识到这个计划的重要性。一些在这个计划中表现不错的开发总监会得到工程生产力团队的优秀反馈，而嘲笑这个计划的团队也会

置自身于危险之中。换句话说，在一个测试资源相对稀缺的公司里，哪个团队会舍得与工程生产力团队疏远呢？但并非哪里都是鲜花与掌声，让运行这个计划的负责人来给我们讲述完整的故

事吧。

2.2.1 与测试认证计划创始人的访谈
本访谈的作者和四名Google工程师坐在一起，他们曾为测试认证计划的开展起到了关键性的作用。Mark Striebeck是Gmail的开发经理；Neal Norwitz是关注开发速度工具的SWE；Tracy

Bialik和Russ Rufer是非管理角色的SET，他俩是公司级别最高的SET，也都是资深级的工程师。

HGTS：测试认证计划的起源是什么？最初测试认证团队试图去解决什么样的问题？现在这个计划尝试去解决的问题相比还是同样的问题吗？

Tracy：我们企图去改变Google的开发文化，想把测试工作也变成每个功能开发人员的职责。大家共享许多在测试方面有积极意义的经验，并鼓励整个团队都去做测试。有些团队比较感兴趣，

但不知道具体怎样去操作。另外的一些团队会把“提高测试”作为团队目标或绩效（译注：objectives and key results，简写OKRs，是个人、团队，甚至公司每个季度都要订制的目标。基

本上这些事情都需要个人或团队完成），这通常并没有什么实际的可操作性，有点像把“减肥”作为新的年度目标一样。那样其实也没什么不好，至少有崇高的目标。但是，如果这就是你要

说的一切，未来有朝一日发现并没有变成现实，你也千万不要感觉奇怪。

测试认证计划提供了小而清晰且可操作的步骤给团队去执行。级别1是做基本准备：建立测试运行的自动化机制、收集测试覆盖率、去除所有非确定性的测试、挑选冒烟测试集合（如果全部自

动化测试运行比较耗时的话）。级别越高就会变得越难，也需要越成熟的测试度。级别2开始着重提高增量覆盖率。级别3重点是测试新增代码。级别4的重点是测试历史遗留代码，通常情况下

需要针对可测试性做一些重构。级别5要求更好的整体覆盖率，针对每个缺陷都增加测试用例，并要求使用已有可用的静态与动态分析检查工具。

现在，所有Google的人都已经知道测试是功能开发人员的责任。虽然最早的问题已经得到了解决，但是我们依然需要为团队提供更高的测试成熟能力度而做一些事情。测试认证持续不断地在

为这个目标服务。

HGTS：测试认证团队最初从SWE那里收集到的反馈是怎样的？

Neal：测试认证计划太难了。他们认为我们把目标设定的过高，结果导致许多团队还在初级层里挣扎。我们需要重新设定认证级别，设定为使他们只要在空闲时间里努力就可以达到的级别。

当时Google的工具也有一些问题，而且我们当时要求的一些想法太过超前。对于参与的同事们来说的确难以去开展进行，因此我们不得不考虑提供一些容易达成的目标，使他们相信自己在不

断地进步中。

Mark：是的，我们不得不把目标向下做了几轮调整。我们设置了一些更加实际的目标，试图在半路上与他们相遇。当然最终还是要达成我们的终极目标，只是需要的时间更长。虽然我们并不

在意时间变长，但还是希望在某些地方可以加速。我们把第一个级别修改为“搭建持续集成环境，保证建成，并清楚自己的测试覆盖率”。这些是很容易达到的，但它建立起一些制度并使大

家的状态从无变到有，并产生积极向上的动力。

HGTS：有谁迫不及待地想参与进来？

Neal：最早参与的人通常是测试圈子里的人。这一小群人定期举行会议，多数是对测试非常热衷的人。我们慢慢地把其他认识的人也拉进来。当时有许多热心的积极参与者，这对我们来说是

个惊喜。我们通过ToTT（注：ToTT，是Testing on the Toilet的简写，直译为“马桶上的测试”。本书前面的内容也有所提及，在Google测试博客“http://googletesting. blogspot.com”

上经常出现）和其他的一些活动把测试搞得充满热情，更有趣味和吸引力，包括fixits（注：fixits是另外一个Google的文化活动，促使人们一起“修复”一些注定要损坏的东西。团队可能

会举行一个fixit来降低bug，另外一些团队或许会搞一个针对安全测试方面的fixit，也可以用来在c代码中增加 #include的使用或者用以重构。fixit可以跨越技术领域，可以用来增加咖啡

馆的食物或怎样让会议进行地更加平滑。任何一个活动，只要一起参与能够解决通用问题，都是一个fixit）、VP的邮件、海报、TGIF上的分享等活动。

Mark：一旦有的新的团队参与进来时（当时已经有许多团队对我们这个计划感兴趣），他们会意识到：① 需要提前做一些功课；② 不必有专业知识。那些专业知识会让初学者产生挫败感。

HGTS：有谁不愿意参与这个计划吗？

Neal：多数项目都不愿意参加。正如我上面提到的，这个计划难度非常大。给我们最初的勃勃野心迎面浇了一盆凉水。大概有两种类型的项目：压根儿没有测试的项目和测试非常糟糕的项目

。我们需要把计划调整的更容易一些，使他们能够利用一个下午的时间就把需要的测试任务完成（在我们的帮助下他们的确也做到了）。

Mark：还有，当时还处于另外一种状况，测试的价值和自动化测试在Google还没有被真正认可。与今日不同，甚至情况完全相反。那个时候，多数团队也认可这是一个非常酷的想法，但他们

还有更重要的事情要去完成（例如写产品的功能代码）。

HGTS：最初，一些参与团队必须要去克服的困难是什么？

Neal：惯性，糟糕的测试，没有测试时间。测试被当做其他开发人员的问题，或者测试是测试团队的问题，跟我没有关系。在写功能代码的时候，谁有时间去写测试代码啊？

Mark：尝试寻找下面的团队：① 足够感兴趣；② 没有太多的冗余代码；③ 在团队中有一个测试战神（对测试足够的了解的人）。这是我们测试认证计划在团队里的三大障碍，我们会一个一

个团队地去解决。

HGTS：是什么把测试认证计划推向了主流？是病毒性的爆发还是线性的增长？

Russ：首先是一批试点团队，他们对测试特别友好。早期的测试认证计划鼓吹者也和我们保持比较亲密的联系。初期很好地选择了参与者，基本上都是一些很容易成功的团队。

在2007年中期，我们宣布测试认证计划“正式启动”的时候，有15个试点团队在这个计划的不同级别上运行着。在正式宣布之前，我们在山景城、纽约和其他地点的所有办公大楼上张贴“神

秘的测试认证”的大海报，每个海报上用图片印着各个试点团队名字，使用的是内部项目名称，如Rubix、Bounty、Mondrian和Red Tape。海报上唯一的文字是“未来就是现在”和“至关重要

，莫被遗弃”，还有一个链接。从喜爱猜谜的Google同事那里，我们得到了大量点击访问，多数人想去一探究竟，还有一些人想去验证自己的猜测是否正确。同时我们也使用ToTT来宣传这个

新计划，并把读者指引到他们能够得到信息的地方。这是一个信息闪电战。

宣传网站上有一些信息，包括为什么测试认证对于团队很重要，以及用户可以得到怎样的帮助。里面强调指出，参与团队会从一个很大的测试专家社区里得到一个测试认证教练，同时还会得

到两个礼物——一个表示构建状态的发光魔法球，可以告诉团队他们的（一般是新的）持续集成是通过（绿色）还是失败（红色）；另外一个是一个漂亮的星球大战土豆头工具包。这个被称

为达斯土豆工具包里有三个逐渐变大的格子，每当团队达到新的测试认证级别时我们都会给予奖励。各个团队展示他们的魔法球和土豆头，为这个计划吸引来更多好奇的团队和带来更好的口

碑。

测试圈子里的成员是这个项目的第一批教练和发言人。随着越来越多团队的加入，有许多热情的工程师帮助造势，自己也成为其他团队的教练。

每次我们尝试说服更多的团队加入这个计划的时候，都会与他们逐一讨论理由和原因。一些团队是由于你能使他们信服每一个级别和教练都会帮助团队在这个领域有所提高而加入的。一些团

队认为他们会有所改善，并坚信这种“官方”级别评定会使他们因为当前正在做的工作得到好评。另外的一些团队，他们本身的测试成熟度已经很高了，但加入这个计划，会给其他的团队发

出一种信号，表示他们已经很重视测试了。

几个月之后，大约有50个团队参与进来，许多有魄力的测试工程师签约成为测试认证计划的教练。这是一个在团队工程师和工程生产力团队之间强大的合作关系的开始。

这是一个病毒爆发式的增长，通过许多一对一草根之间的对话发展起来。虽然我们有明确地要求一些团队参与进来，但也有另外的团队自己找上门来。

大概一年后，有一百多个团队通过测试认证，加入测试认证计划的速度开始慢慢地放慢。时任志愿者主管Bella Kazwell策划了一个活动——测试认证挑战。该挑战活动开发了一个积分系统，

新增测试、引入新团队参与计划、提高团队测试实践或提升测试认证级别等活动会被计算进来。同时，有一些个人奖项、全球的项目都参与进来，比拼谁是最高分获得者。志愿者被激励，随

之又激励了公司里更多的团队，使测试认证计划再次加速，并吸引了更多的志愿者教练。

参与测试认证的团队一般都使用每个级别的标准作为可度量的团队目标。到2008年后期，一些团队的经理开始使用这个作为他们的团队目标，而工程生产力团队使用一个团队在测试认证计划

里的级别，来评测这个团队在提高测试方面的重视程度，并在决定是否向一个团队投入有限测试资源时作为一个重要的参考指标。在某些限定的领域，一个团队是否达到特定的测试认证级别

已经成为管理上的期望或启动的标准。

在2011年，不断有新的志愿教练加入，也不断有新团队签约加入，测试认证已经在整个公司中运行起来。

HGTS：在最初的两年测试认证计划做了哪些变化？每个级别的要求有什么变化么？教练系统有变化么？对于参与者在体验方面有哪些改进？

Tracy：对认证级别的数量和一些级别要求做了调整，这是最大的变化。最初我们有四个级别。从级别0到级别1，有意地设计成比较容易就可以达到。许多团队，特别是一些可测试性比较差且

有遗留代码的团队，发现从级别1到级别2非常困难。这些团队会比较受挫，并有意向退出测试认证计划。我们在级别1和级别2之间增加了一个稍微简单的新级别。我们把这个新级别定义成为

“1.5”，但实际上还是决定把新增的级别设定为2，并把后面所有的级别+1。

我们同时发现有一些要求并不合适，例如小型测试、中型测试、大型测试的比例要求并不适用于所有团队。在我们增加了新级别之后，同时也更新了级别标准。我们在新增了“增量覆盖率”

的具体比例要求的同时，把各级别测试的比例也给去掉了。

辅导教练始终都在，但许多团队已经进入“自我调教”的模式。由于测试文化已经无处不在，许多团队已经不需要我们再提供建议了。他们希望跟踪自己的进度。对于这些团队，我们不再指

派教练，而是提供一个邮件列表用来回答他们的问题，这也是通过另一双眼睛来观察他们级别的转换。

Russ：值得注意的是，从一开始，我们就意识到测试认证标准必须要合理地制定。测试并像制作饼干，都是一个模子里出来的。在我们选择标准的时候会发现有一些团队的测试状况跟我们心

中的所想迥然不同，无论是用以记录测试覆盖率的工具还是用其他的度量方式，各有千秋。但每一个标准都有其背后的合理性。在这里我们比较开明的没有一刀切，而是定制化了一些多数团

队可以满足的标准。

HGTS：当前如果一个团队坚持参与测试认证计划会有什么收获？还需要投入什么？

Tracy：可以把这个作为炫耀吹牛的资本。清晰明确的步骤、外部的帮助、一个看起来很酷的发光球，但对于团队来说，真正的收获是质量方面的提升。

实际投入非常小，但团队需要专注于改善他们的测试成熟度。我们有一个定制化的工具，教练可以用此跟踪团队进度，检查每一步目标是否达成。在一个页面展现所有按照级别排列的团队数

据，可以通过鼠标点击查看指定团队的细节数据。

HGTS：在所有的认证级别里，哪个级别会给团队带来更多的麻烦？

Tracy：最困难的一步是“对于所有的重要代码变更，都需要经过测试”。这个要求在一个可测试性很好的项目中比较容易做到，但对于一个有遗留代码的项目，特别是之前写代码的时候并没

有测试意识，这就很困难。这可能需要写一个大的端到端测试并尝试通过测试验证系统的特殊代码路径，然后再自动化。从长远角度看，更好的办法是代码重构，从而获得良好的可测试性。

有一些团队，在写代码的时候没有考虑到可测试性，一样会发现很难去达到足够的测试覆盖率，不管是单元测试，还是端到端的测试。

HGTS：在Google一般的活动只会持续数周或一个季度，但是测试认证计划已经运行了近五年而且没有迹象表明会停止。是什么导致测试认证计划经过了时间的考验？测试认证之后会面临什么

挑战？

Russ：能够保持活力的原因，不是因为这是个体参与活动，而是因为这是一次公司文化的变迁。随着一系列活动，测试小团队、ToTT、支持邮件列表、技术交流、晋升贡献、代码风格文档，

常规的测试已经演变成为公司所有工程师必须要做的事情。不管一个团队是否参与了测试认证计划，这个团队总是希望有一个经过深思熟虑的自动化测试策略，这些策略来自于一部分测试专

家，不管是团队内部还是外部的专家。

能够持续至今也证明这个计划是可行的。只有很少一部分领域在使用手动测试。在这样的情况下，测试认证计划已经完成了它的使命。它会被作为伟大的历史遗产，即使这个官方的草根计划

某天真的结束了。

HGTS：有什么建议要给其他公司的同行？如果他也想在自己的组织里考虑类似的计划？

Tracy：从一些对测试比较认可且友好的团队开始，培养一批可以从你的计划中受益的核心团队。在激励和赞美方面不要害羞，甚至要求其他人也来说好话。良好的教练是测试认证计划成功的

一个重要原因。如果你想要求一个团队去尝试新的事物或者做某些改进，给他们提供一个联系人会更好一些，这个联系人来源于更大的社区，并可以从他那里得到帮助。一个工程师或团队如

果在一个邮件列表中问了一个很傻的问题，会感觉比较尴尬，但询问对象如果是一个可以信任的测试认证教练的话，这将会好很多。

同时，寻找一些让你的计划变得有趣的方法。为你的计划取一个好的名字，最好不要包含“认证”字样，这可能会引起见识短浅的官僚主义。或者像我们一样，就使用一个目光短浅的名字“

测试认证”，但要不断地提醒大家注意我们知道这是一个不好的名字，这只是一个反语，用以衬托你的计划其实并不是这样的。每一个步骤包含的内容要尽可能的少，这样大家可以看见自己

的进步。不要陷入尝试去创建一个包含独立指标的完美系统的陷阱中。对所有人都完美的事情是不存在的。在没有可替代的方案时，在合理的地方达成一致并勇往直前是很重要的。需要灵活

的时候就灵活一些，但一定要坚持你的原则底线。

到此本章已结束。后面是可选阅读部分，关于Google如何面试SET、与Google工程师Ted Mao的访谈，以