第 1 部分

引　　子

测试工作是否有价值，这似乎是一个不值得讨论的问题，因为几乎所有

的软件公司都有测试团队，既然一个以盈利为目的的组织，舍得为了测试进

行投资，那么测试工作就一定是有价值的。

但是另一方面，无论是从业界了解的情况，还是从我们测试团队自身

看，测试工程师转行的比例都高于同级别的开发工程师和系统工程师，这些

转行的测试工程师在新的职业道路上大多获得了更高职位、更好的发展。这

说明他们在测试岗位上的发展受阻，并非由于自身的素质和能力造成的，很

可能是由于工作的价值没有得到肯定。

测试的工作大多数是属于破坏性的，通过对产品的各种攻击操作，检验

产品是否符合需要。而软件设计、开发工作是建设性的，主导了产品从无到

有的生产过程。公司的盈利最直接的原因就是建设性的工作成果—产品，

能成功销售。因此，由于这种工作性质，测试确实是一个相对难以做出价值

的职业。

一方面研发对测试的投资期望得到价值回报，另一方面测试已经做出的

工作价值没有得到充分认可。这个局如何破？这就是本书接下来将要讨论的

内容。

P a r t 1

第 1 章

Chapter 1

他山之石

测试这个职业从诞生之日起，对于其价值的探索就从未停止过，随着软件技术的

发展和软件应用范围的扩展，一方面，测试实现传统的价值遇到了新的挑战；另一方

面，研发对测试价值也有了新的期望。

他山之石可以攻玉，在讨论测试存在的价值之前，先看看测试价值走过的路，以

及在优秀的软件公司里，测试人员都承担哪些职责，他们的做法可以给接下来的价值

讨论带来哪些启示。

1.1　测试困局

在我的工作中，经常会听到测试经理诉苦说工作难做。测试经理经常面对来自客

户、产品经理、研发经理，甚至测试内部的质疑：

● 产品在客户那里出了问题，客户问：测试究竟能不能保证质量？

● 产品上市延迟了，研发经理问：究竟要花多少时间做测试？

● 产品架构优化、改变开发模式、采用新技术提升了开发效率，系统工程师问：

测试难道就没有新方法同步提高效率？

● 项目做完了，发现项目中打杂的事情多数是测试顶上，决策的时候测试没有话

语权？

● 职位评定时，测试工程师问：好像每年递交的任职申请中改变的只有项目清

单，难道这些年就是不断的重复？

测试工作看上去就是：看不到产出、说不清投入、显不出能力（或者说是能力没

有进化）。

测试面对来自各方的对工作价值的质疑时，常常这样“反击”：

第 1 章 他山之石　　3

测试不是产出 bug 吗？对不起，测试产出的 bug 已经改掉了，我曾经和几个测试

的同事合作开发过自动化工具，我负责开发的模块中有一个是通信模块，有一次一位

同事说：hi，你做的通信模块好牛啊，从来没有出过问题。当我回忆起这个场景时，

我理解了为什么发现 bug 不容易被记住。如果开发工程师写的代码被调用、被拷贝，

做的功能被使用时，他们在设计、实现上精心的考虑，是会被人反复看到、赞叹的。

bug 呢？如果发现的 bug 是考虑了新的要素，并且和一些陈年顽疾有关；或者发现的

一个特别的 bug，在后来的特性中又出现了，那么测试工程师对测试设计的精心考虑

才会被赞叹。但是这样的机会显然不多。

这个版本发现了 1452 个缺陷？对不起，这个数字意味着什么？是表示产品质量

差？测试水平高？测试做得太多了？或者其他什么意思？

那测试提升了质量啊？其实现在针对质量的提升，通常的共识是，因为有更好的

开发工具、更好的编程语言、更好的软件重启和恢复机制、更好的分层隔离架构、更

好的测试工具……而在这一路上，测试工程师本身的贡献少得可怜。说到开发工具，

测试工程师很少使用这些工具，与这些工具的开发和测试就更没有关系了；说到开

发语言，大部分测试工程师甚至做不到精通一门编程语言，更不要说开发过一款语言

了；说到更好的软件重启和恢复机制，这主要是架构和设计模式的演进，跟测试关系

很小；说到测试工具，大部分测试工程师在使用这些工具，但是并不参与工具的开发

和推广。所以很少有公司把质量的改善归功于测试的价值。

为什么要测试有产出？测试不是蓝军吗？不是把红军攻下来就是成绩吗？随着软

件架构的演进、软件应用的普及，对开发和测试的这个红蓝军的隐喻已经过时了，过

去主流的软件是用于军工、航天、通信核心层、工业设计（autoCAD）、管理、财务

等，这些软件是针对企业的需要，一旦出问题影响也比较大，常常伴随无法承担的经

济或人身损失。现在的软件已经渗透到各行各业，渗透到日常生活，用户也是老幼妇

孺都有，由于基础架构的改变以及产品成本结构的变化，软件中的很多缺陷不再会造

成无法挽回的损失。这时候测试还死守蓝军的定位已经不合时宜。

不仅仅是对于 bug 价值的理解和红蓝军的隐喻不合时宜，一些测试领域认为理所

当然的“准则”也一样不合时宜：

● 能证明有问题，不能证明没问题。测试可以显示缺陷的存在，可以减少产品中

存在未被发现缺陷的可能性，但由于穷尽测试是不可能的，因此即使在测试中

没有发现缺陷，也不能证明产品已经没有缺陷。这是一句完全正确的“废话”，

4　　第 1 部分 引　　子

即使客户同意这个观点，他也会质疑：为什么这个缺陷没有被发现，明明是在

正常使用情况下就暴露出的缺陷，并不需要“穷尽”测试。

● 质量是设计出来的，不是测试出来的：产品能够达到什么样的质量，在架构、

设计方案确定后，就已经决定了，不可能通过测试活动，让产品质量有本质的

提升。这句话虽然道出了一个事实，但是听起来更像一个逃避责任的借口。测

试之所以存在，就是因为人是会犯错的，研发团队更希望测试能够在错误发生

的时候就被发现并证实这个错误，而不是到了最后一切都已经定型了才说这个

产品不行。

所以，测试之所以遭遇到当下的困境和质疑，很大一部分原因，就是测试的价值

定位，以及在这个价值之下的思维逻辑需要跟上软件发展的步伐。

为解决这个困局人们采取的做法大概有 2 类：

1）老板说什么我做什么。研发经理说客户缺陷太多了，你们要加强测试设计能

力啊，于是测试工程师把测试方案越写越细，用例越积越多，尽管知道这些手段根

本就没法保证缺陷必然被发现，但是多走点路大概踩到牛屎的几率高一些吧。研发经

理说测试周期太长了，要搞自动化啊，于是测试工程师引进工具，把自动化率越做越

高，尽管早已发现，自动化对测试效率其实没啥贡献。研发经理说为啥缺陷那么晚发

现，你们要参与到前端去啊 ，于是测试工程师参与需求和设计评审，尽管大部分人

是打着评审的旗号提前学习了一下特性。测试只知道按研发经理支的招去做了，却根

本没有关心研发经理想解决什么问题。这种思路会是什么结果呢？问题依旧，因为这

些意见根本就是外行指挥内行，最后在困局中越陷越深。

2）主动寻求新的测试价值。通过在产品测试过程中获得的数据，利用对产品的

深入掌握，对测试的深入理解，来拓展新的职能，例如：主导产品的指标改进，在代

码管理和发布平台（CI、沙箱、灰度）中内建质量标准，主导产品集成，主导用户体

验分析，用验收用例实例化客户需求，主管验收测试活动等。

我认为后者是更有前途的思路，但是现在走在这条路上的还是一些先锋，属于个

别人的英雄主义冒险。我希望用我的绵薄之力，使这方面的创见越来越多，最后实现

对测试这个职业的新的价值定位。

1.2　测试价值的发展

对于测试价值的认识曾经经历过以下阶段：

第 1 章 他山之石　　5

证实。测试就是证明在哪些情况下，产品可以正常使用，这个价值是对测试价值

的最早认识。现在这个价值已经属于生产环节的质检了。

证伪。测试就是发现产品在哪些情况下存在缺陷，这个价值是测试这个职业目前

得到最广泛认同的价值，但也是这个价值正在局限测试的发展。

缺陷预防。测试就是防止在研发的各个环节引入缺陷，最终使产品质量得到提升

的活动。这个价值的提出大概始于 20 世纪 90 年代，是目前测试的主流核心价值之

一，但由于这个价值的实现对研发能力有非常高的要求，很少有测试团队或者个人能

够真正发挥这个价值。

综上所述，测试的价值定位，本身就是一步步发展到今天的。同样，测试价值还

会继续发展下去，而且很有可能，缺陷预防只是测试价值的一个分支，今后测试价值

的发展会是多样化的。

1.3　谷歌的软件测试

谷歌的软件研发特征是：典型的互联网企业，产品完全是自运营，以周或者更短

的周期发布版本。有创新型、实验性质的新业务，也有平台性质的搜索引擎。需求的

提出并非客户主导。

开发测试比是 20∶1。这个数据从很多渠道都可以看到，曾有产品研发经理用这

个数据“鞭策”测试经理，说测试应该提升能力。但是测试最应该提升的是能力吗？

不是，是定位。

测试职位的名称：SDET（软件开发工程师，测试方向）。在谷歌，这些人的主要

职责不是功能测试设计、执行以及自动化实现，而是以下几点：

1）帮助开发更快更好的测试。谷歌有一个“吃自己的狗粮”的文化，自己开发

的功能自己测试。专职的测试工程师主要是根据软件的功能和测试内容，设计测试方

法，并提供测试工具，典型的例子是谷歌地图的测试工具。测试工程师还负责探索和

引入新型的测试思路，帮助更有效地发现缺陷，典型的例子是探索式测试的引入。

2）帮助产品更好地采集使用信息和用户反馈。采集使用信息是对用户操作过程

的数据进行性能和易用性分析，目的是帮助分析业务达成目标的瓶颈是什么，比如分

析用户放弃操作的比例和原因。更好地采集用户反馈，典型案例是谷歌地图的用户问

题报告功能，用户发现地图错误时，用几个非常简单的步骤就可以进行缺陷报告。为

什么谷歌的测试会有这个职责？我认为主要因为产品是自运营的，这使得研发需要主

6　　第 1 部分 引　　子

动发现产品缺陷，同时产品的发展、新需求的发现需要从产品应用中得到启发。

3）安全性、可靠性、性能等专项测试。这些测试内容非常专业，在谷歌也是由

一个集中的专项测试团队进行测试的。

谷歌应该说是一个非常成熟的互联网公司，互联网的业务特征决定了这个组织对

一般功能性缺陷不敏感，但是对商业目标是否达成十分敏感，自运营决定了产品的缺

陷非常容易更正，文化决定了测试工程师不做功能测试（其实，除了狗粮文化，还有

一个组织机制也许更关键，谷歌的研发团队在做完一个产品后，会自由重组，信誉不

好的开发者很快就会被组织淘汰）。

1.4　微软的软件测试

微软的软件研发特征是：典型的大型传统软件企业，软件完成后完全部署在用户

的环境中使用（微软还有必应、Skype、OneDrive 等自运营产品，这些不在本节考虑

之内），版本发布周期半年甚至更长，产品有非常好的继承性，十分注重在发布前排

除软件缺陷。属于领域老大，开发内容不由客户需求主导。

开发测试比是 1∶2（裁员之前），这个比例在测试领域家喻户晓，也常常成为很

多测试经理艳羡微软测试的主要原因。但这个比例真正的含义是，微软的测试工程师

一定承担了很大的责任，因为开发测试比完全取决于公司认为有多少事情需要测试团

队去做。

测试职位的名称：SDET（软件开发工程师，测试方向），这个叫法是微软首先提

出的，现在似乎已经成为北美软件测试工程师的标准称谓。在微软，SDET 的主要职

责和大多数软件公司的测试工程师的职责类似，包括：

1）保障质量。和谷歌不同，微软的 SDET 的主要职责就是保障质量。因此他们

会做各种类型的测试及其自动化。既包括传统的结构化测试、MBT、自动化、DFX，

也包括以找 bug 为乐趣的探索式测试。微软非常强调自动化，这个对于继承性强的产

品是很自然的要求。在微软，开发对测试的交付有点像“抛过墙”的方式，只要开发

的东西通过了 happy path，接下来就主要是测试的工作了，当然微软的开发工程师也

是非常重视声誉的，不会因为有人做后续的测试就不对自己开发的代码质量负责。

2）提升研发效率。和谷歌一样，微软的 SDET 也致力于开发各种工具，从全流

程质量管理工具，自动化工具，到辅助手工 DFX 测试的工具，他们都会开发。在软

件研发领域广为人知的每日构建（Daily Build，每日自动对代码库的新增代码完成单

第 1 章 他山之石　　7

元测试、编译，并构建生成可执行文件，自动用新构建的可执行文件更新测试环境，

用基本功能的系统测试用例进行冒烟测试），微软就是早期的实践者。这些工具由普

通测试工程师开发，内部也有平台支撑他们去分享和推广。微软的工具总体说来是贴

近业务需要，以提升自己的效率和质量为目的，因此百花齐放，据说光 MBT 的工具

就有 20 多个。

微软是一个非常成熟的传统软件公司，由于软件的生产者和使用者之间的联系比

较弱，因此质量是非常重要的，但是这并非是说不能容忍任何的缺陷，事实上微软对

软件特性有质量分级，不同级别的质量要求和覆盖要求非常不同。 1

1.5　腾讯的软件测试

腾讯的软件研发特征是：典型的互联网企业，产品完全是自运营，以周或者更短

的周期发布版本。有追求快的新业务，也有平台性质的 QQ。需求的提出并非客户主

导。属于领域的领先者但并非先驱，所以快是首要要求。

开发测试比是 3∶1。这是电商产品线的比例情况，其他产品的测试团队以前也类

似，但近年收缩，外包的比例加大。

测试职位的名称：TE。TE 既做测试也做工具，主要职责如下：

1）在业务上线之前尽可能地发现导致商业目标无法达成的缺陷。比如业务不能

正确工作，正常完成操作很困难，性能极差等，如果在计划发布时间点上没有足以致

命的缺陷，那么业务就会进入灰度发布。灰度发布是真正质量兜底的措施，这个机制

能将缺陷的影响控制在非常有限的范围内，最大限度地让真实用户参与测试。这确实

是最经济的做法，包括安全性方面，腾讯给白帽子群设置安全大奖的做法绝对是四两

拨千斤。而维持灰度发布机制的正常运作，包括获得灰度发布后的使用信息以决策是

否进行下一步的切换部署，这个不是测试的职责。

2）在业务测试团队之外，还有一个独立的体验测试团队。这个团队由非常资深

的测试工程师组成，专门对业务的体验进行评估并促进改进。由于业务变化非常快，

很多团队在尝试了不同层次、不同方式的 UI 自动化后基本上放弃了这个技术方向。

腾讯各个产品线的测试团队也自己开发工具，用来提升自己的效率。

3）QQ 平台很传统。在腾讯内部称 QQ 为平台，QQ 平台有传统软件的特征，测

　这是 Win10 之前的情况，Win10 开始测试团队大量裁撤，情况已经不同。

8　　第 1 部分 引　　子

试的价值也和传统软件一样，侧重质量保障，也强调自动化和 DFX。

腾讯是典型的互联网公司，测试组织的变革和职责定位也还在探索过程中，电商

和 QQ 平台的测试比较传统，游戏则完全不同。

1.6　华为的软件测试

华为的软件研发特征是：典型的传统软件企业，软件完成后完全部署在用户的环

境中使用，有按月交付的业务版本，也有半年甚至更长时间才交付的基础版本或平台

版本，产品有一定的继承性，但架构重构也不是小概率事件（这主要是因为华为还是

电信领域的新人，对这个领域的把握还不十分老道），十分注重在发布前排除软件缺

陷。属于领域跟随者，开发内容绝大部分由客户需求主导。

开发测试比是 2∶1～10∶1，2∶1 是比较核心的平台部门的比例；10∶1 是大量

测试外包的业务部门的比例。如果加上外包一起计算，比例大概都在 2∶1～4∶1。这

个比例意味着测试主要精力是在黑盒测试上，如果需要做灰盒测试，基本需要 1∶1

才能搞定。

测试职位的名称：TE、TSE（测试系统工程师）。TSE 是比较具有华为特色的角

色，这个角色的定位历经很多变化，目前也还在变化的路上，详细内容参见 5.4.4 节

“从任职资格标准的演变看测试价值”。基本上，在重要的项目、技术更新和提升、团

队能力建设中都可以找到 TSE 的身影。在华为，测试工程师的职责如下：

1）保障质量。这是华为测试最基本的职责，因此非常强调结构化测试，对自动

化也非常推崇，即使是界面自动化也从未放弃。可靠性和性能的技术积累比较丰富，

其他 DFX 维度的实践也比较多，但还没有牛人出现。MBT 的实践在部分继承性好的

产品取得了成功。

2）交付。面向客户交付的验收测试活动，是测试工程师晋升的摇篮之一。如果

一个产品质量好，那多半得益于专项整改、架构优化、开发工具优化，以及 CI 标准

严格执行。如果一个产品质量不好，测试多半是有连带、甚至是主要责任的。所以只

有部分测试工程师的晋升，是由于在保障质量上做得出色。而针对验收一次性通过采

取的实例化需求、现场测试自动化、现场测试流程优化等也得到了比较广泛的认可，

成就了一些测试工程师。华为研发对测试还有其他要求，比如：代表客户进行同类产

品质量和体验的评估（竞品分析），从问题出发驱动产品质量改进（产品商用的瓶颈分

析），提升研发效率（全面提升自动化，并用于研发各环节，提升整体效率）等，这些

第 1 章 他山之石　　9

方面的成功实践还是少数案例，并不普遍。

3）公司大平台（公司级工具开发和研发能力提升团队）“搞定”流程、工具、技

术更新。华为非常强调集团作战和经验传承，认为固化为流程、模板、工具就能减少

对人的依赖，因此有一个非常重量级的公司大平台，流程基本上是公司层面定义的，

产品只能在规定的范围内定制，定期会进行流程合规的审计。测试工具的大框架、

支撑流程、管理（缺陷、用例、实验室、CI）和度量的工具基本上是大平台开发的；

而自动化、性能、可靠性和 MBT 工具则是由产品线或者产品测试团队开发的。大

平台也试图统一这些工具，但是目前没有成功。这种大平台在同业中基本上没有见

到过。

华为测试的组织和定位不断变革，至今仍然不断变化，由于开始“折腾”的早一

些，今天才能有些许经验来分享。后面关于测试应有的价值的思考，是测试经理们和

产品研发的领导们不断沟通、实践后的结果。

1.7　优秀软件公司测试团队职责的启示

总结以上典型软件公司的测试团队职责见表 1-1。

表1-1　典型软件公司的测试团队职责

公司 测试工程师职位 开发测试比 测试团队职责 产品特点 行业地位

谷歌

　SDET—软件

开 发 工 程 师， 测

试方向

20∶1

　1）帮助开发更快更好的测试；

　2）帮助产品更好地采集使用

信息和用户反馈；

　3）安全性、可靠性、性能等

专项测试

自运营 行业领导者

微软

　SDET—软件

开 发 工 程 师， 测

试方向

1∶2（裁员之前）　1）保障质量；

　2）提升研发效率客户运营 行业领导者

腾讯 　TE 3∶1

　1）尽可能地发现导致商业目

标无法达成的缺陷；

　2）体验测试；

　3）QQ 平台测试侧重质量保障

自运营跟随者

领先者

华为 　TE、TSE 2∶1～4∶1

　1）保障质量；

　2）面向客户交付的验收测试；

　3）多级工具开发团队共同完

成流程、工具、技术更新

客户运营跟随者

领先者

10　　第 1 部分 引　　子

通过这些软件公司的测试团队职责，可以看出以下几点：

1）产品的特点和测试的职责有关：如果产品是自运营的，首先，用户使用问题

可以第一时间反馈到研发团队；其次，研发团队可以通过灰度发布、沙箱等手段控制

缺陷的影响范围，降低缺陷的风险；最后，修改缺陷以后，上线的过程不会太繁琐。

缺陷生存的时间较短，可以容忍一部分缺陷在产品上线之后被客户发现。因此自运营

的产品研发团队对功能缺陷并不十分敏感，也没有强调测试应该保障质量。这些测试

团队通常具有较强的工程能力，能够帮助产品在保证基本功能正确的前提下，尽可能

快速地发布产品，有些团队还在“更快获知客户的问题和体验”上进行创新，帮助提

升运营维护的效率。

如果产品是客户运营的，研发团队和产品用户之间的联系比较弱，产品缺陷的反

馈、确认和修改的链条比较长，产品发布后发现的缺陷，其修复成本会很高。因此研

发团队强调测试应该保障质量，尽可能减少发布产品的缺陷，降低研发和维护的成本。

2）测试团队规模和测试的职责有关：以产品日常的功能测试为主要职责的团队，

无论是否肩负了“保障质量”的职责，都会需要比较多的测试工程师。而只要做产

品日常的测试，无论能覆盖的范围、能达到的深度是什么，都或多或少地承担了质量

目标。

3）测试工具开发测试是测试团队绕不过去的工作：并非所有的测试团队都以产

品日常的测试为主要职责，但几乎所有的测试团队都进行工具的开发，无论是为了解

决测试手段，还是为了提升效率。在测试的工作中总是会发现：要不就是没有合适的

工具；要不就是现有的工具还需要一些二次开发，总之，每个测试工程师都需要一定

的工具开发能力。