我为何从开发转测试，并坚持了 16 年？

此文是由茹炳晟老师的直播整理文，主题为“去 QE 时代，测试开发者该如何迎难而上？”。简单介绍下茹炳晟老师，他是 eBay 中国研发中心测试基础架构技术主管，有着 16 年的测试经验，而且有着从开发转型测试的奇妙经历，算是国内第一批做自动化测试的工程师。现在他还在极客时间开始了一个专栏 -《软件测试 52 讲》，覆盖率测试、开发者所需要的知识点，让测试更加精通，让开发了解测试。

我为何从开发转测试，并坚持了 16 年？

茹炳晟：刚才我们聊到自动化测试，我们做 GUI 自动化测试的过程当中，以前就只要把这个自动化做起来就好了，但随着你的用例，用的数量越来越多之后，你不单单是把一个场景自动化就可以了。因为随着你的用例变多之后，你所有的用例设置，包括你的代码的结构，都要考虑这个东西的可维护性，因为可维护性一直是 GUI 自动化测试很大的一个痛点。我们在后面的 GUI 测试过程中，就会去考虑，怎么来做分成？怎么来做基于可重用的脚本？怎么来做基于页面的对象模型？甚至到后面还有 BDD，就完全是业务，用户行为驱动的这种测试。那么，从这些概念当中，可能你已经听出来了， 不管是你之前有没有接触过这些概念，你都能够发现一个很重要的信息点，自动化测试没你想的这么简单，也完全不是一个简单的录制，或者回放。

所以说，我自己当时在转型的过程中（从开发转向测试），我就是看到了这些点，觉得这里面的学问，或者说可以做得东西，尤其在当时的大环境下，是非常多的。因为当时没有人去做这块，而且当时是没有有开发经验背景的人会去专门做这一块的东西。我也是看中了这样一个机会，后来事实证明，转型并没有错。

随着时间的发展，后来就越来越证明整个自动化测试到后期的一些基于 API 测试，或者现在很多一些新的测试技术越来越多，而且整个测试地位也越来越高，从早年的并不受重视，或者是一些比较弱的开发去做测试，到现在一个优秀测试工程师可能是比一个开发人员更懂开发代码。因为如果他不懂代码，或者不懂开发是怎么来做得，你让他怎么去发现开发当中的一些问题？这个过程是相辅相成的。

其实我们很多测试已经分为了三大块。

一块是 所谓的传统意义上的基于业务功能的测试， 基于手动测试，或者现在非常流行的，基于探索式测试，也就是说基于一些错误猜测，以及基于一些你做了哪些测试，你假定哪些地方有可能会出错，而且做进一步测试，这样一个过程，所以说这是一部分做业务测试的同学。

那么 第二块是做自动化测试的同学， 自动化测试的同学对业务了解程度并不是很深入，但是他所做的事情是把一些手动的脚本，很方便得把它翻译成一些自动化的脚本，可以让机器去执行，那么他的主要技能是主流的一些 GUI 的 Framework，比如说现在主流的像 Mobile 端的可能就是 API，或者是不同框架的这种自动化开发技术，这是第二类。

第三块是很大的一块， 就是现在意义上的叫测试开发。 测试开发并不是传统去做自动化用例的开发，他会去做一些测试平台、测试服务，或者一些测试基础架构的开发。你可能会问，这些基础架构包含什么东西？我可能举两个例子，你可能就知道了，你现在要跑测试，你要跑一个 Web 端的，或者跑一个 API 手机上的一个 Mobile Native 的 app 测试，你肯定一定要有执行环境，你如果是手机端的，你一定要有手机，要有安卓的 Device，或者有 IOS 的 Device，去让你跑这些测试，那么这些手机你怎么来？单个来拿吗？你肯定会去建一些机群，甚至建一些私有云，像国外的 Lab 服务，其实包括国内的一些其他服务器，类似云测的服务，就是把这些设备集中在一起。

那么这部分工作是谁做的？就是现在的测试开发去做。

软件测试对于学历的要求高吗？

茹炳晟：反问下大家，你在学校里面学的东西是什么呢？你真正去看，学校里面出来，你上了工作岗位之后，学校里的东西立马能用的有多少？ 我觉得基本上是在 10% 以下的，所以说我觉得学校里面学的是什么呢？我个人认为更多学的是一些思想方法，就是说你面对一项新事物的时候，你会用什么样的方式，如何在很短的时间内用自己的方法，把整个这件事物的来龙去脉搞清楚，并且你能够接受它并且你能够运用它，这是个很重要的点。

所以说跟学历没有必然的关系。像乔布斯这种公司，它不注重你的出生，或者你是从哪个方面去做这个事情， 他看中的是你的思维方式，你的能力。 这又让我想到另外一个点，现在讲到面试， 我个人是十分反对刷题的。 因为我们碰到过一些同学，面试过程中，你给他一个算法去做一下，如果他能立马给出一个最优解，那这个肯定是有问题的。因为我的理解，正常的情况下，你不可能一下子就找到这么一个非常好的最优解，你能找到这个最优解的前提一定是你之前看到过这样的算法，或者是你看到过这样一个最优的解法。

我们想看到的是一个什么样情况呢？ 你不是给我一个最优解，而是你给了我一个方法，这个方法不一定完美，但在我们的引导下，你逐渐把它完善，逐渐发现你这个算法的问题在哪里，哪些地方可以去做更多的改进，然后把这个算法逐渐变完美。 这个是我们想看到的，我们是想看到的是你在面对一个有挑战事物的情况下，你是怎么把一个大问题化解成一个小问题，每个小问题又是如何去解决，最终解决这个大问题，解决了这个大问题之后，再去回顾一下，你在解决这个大问题的过程当中，有哪些地方是可以改进的，是可以优化的。我们是想看到的是这种过程，所以是这样一个情况。

去 QE 时代，测试工程师该如何修炼？

茹炳晟：首先我想先解释一下，什么是“去 QE”。“去 QE”这个概念在国内还是非常新，但是在一些像 Facebook、Google、Ebay 这样的公司，已经都在做这些事情，而且有很多都已经真正落地了。首先我先表明我的一个观点，我并不是“去测试”这样模式的推崇者，因为去不去测试根本的原因不在于说，你觉得能不能去， 而是完全取决于你的组织上下文、你的组织成熟度、你成员的水平、你 工具 的成熟度、你的体系、你的上下文、你生态的成熟度。

那为什么 Google 能做？

因为 Google 拉任何一个测试工程师出来，直接去做开发是没有任何问题的，但在国内，你让测试去做开发通常是比较难的，所以你面对的上下文、面对的环境，差异性就非常大。这种情况下，你说去 QE 一定好，或者去 QE 一定不好，都是没有一个定论的。

我的观点在于，并不是一定要说那个好，而是我们应该面对一个特定的项目，或者面对某一个组织，我们怎样去两边取各自的长处，两边去各自的短处，有机地结合在一起。这也就是现在所谓的“去 QE”，就是“没有测试工程师，开发自己做测试”这种架构。

那么哪些情况下是适合让开发自己去做测试的？哪些情况下还是需要一些专业的测试人员来做测试的？

传统的测试策略，更多的是一个金字塔模型，也就是说 UT 会做的比较多，中间层，像 API 的集成，或者是集成测试会做的相对少一点，最上层的 UI 一般是更少，是个轻量级。

但在现在互联网的时代，尤其是一些去 QE 的公司，他是怎么玩儿呢？他会把整个三角形变成一个类似于菱形这样的一个架构，也就是说 UT 这块是非常的少了，中间层，API 这一层，由于微服务化，这层会非常的厚，上层的 UI，会做的相对比较少，而且更会去做端到端的，面向对终端用户的这种测试。除此以外，这个菱形的顶上还飘了一朵小的云，这朵小的云就是现在非常流行的 ET，也就是所谓的探索式测试。

没去 QE 之前，整个架构是金字塔，底部 UT 是开发做，API 测试跟 UI 测试都是测试人员来做，但是在去 QE 之后，是什么样的一个架构呢？ UT 开发做，API 测试也是开发做，UI 测试还是开发做。 唯一是测试人员可以做的是哪里呢？ 是顶上飘的那块小云，也就上面那个 ET，探索式测试。 因为这一块需要更多的是一些发散性的思维，而且需要你对业务有非常好的理解。这还需要你除了理解业务外，还要明白产品内部的一些实现，以及它的架构，才能比较有针对性的去做一些探索性的测试。

面对这样一个大的变革，你可以看到有点类似于把测试上移了，就是你原来的测试工程师只是做上面的 ET 部分，但是原来的那些像下面的 API 测试，或者 UT，或者基于 UI 测试，这些测试谁做呢？由开发做，但是由开发做不表示这个活没有，测试这个活还是在的，只不过是换了一批人去做这个事情，本质上并没有根本性的变化。根本性的变化就在于可能从组织架构的角度来看，现在可能不再有集中的一个测试团队了，这些负责测试业务的测试工程师会打散到各个开发团队里面去，而且他承担的角色也不一定是全职的测试，他有可能会做一部分开发，也会去做一部分的测试

开发人员哪有那么多时间测试？

茹炳晟：这是个非常好的问题，也从两个点来讲，就是开发很忙，开发最大的价值在哪里？ 它是开发功能，这是它的核心价值，测试不是他的核心价值。 那么以前为什么说开发不做测试，没有问题？因为后面是有测试帮你做的，你的工作范围不包含测试，也就是说你在打分的时候，你所有的绩效是不把测试的工作量算进去的。测试的工作是由后期专门的测试人员去做的。那么现在开发去做测试，他就会把测试这部分工作量算到它的打分里面，也就是说测试的工作量是算在了开发上面，那么势必就会让开发的工作量就会变少了。

第二个点， 以前测试人员做测试的时候，测试有很多辅助的东西，其实开发人员并不知道，比如说测试执行环境，还有去搭建测试执行环境， 比如说你拿到一个包，这个包你要去部署，你怎么先把这个包部完，然后才开始测试，就简单来讲就装环境。当时这种模式下，这种协调都是测试人员自己去做的，因为测试人员天天在做这些事情，他对跨 demo 非常清楚，他知道这些数据怎么来，并且这些数据在每个团队里面是怎么来。但如果让开发人员去做，开发人员就不清楚了，他很难找到，或者说他要找到，需要花很多额外的精力才能去创建出这样一个 case，创建出这样一批测试数据出来，或者说他要花很长的精力去找到一个测试环境，或者去做一次测试包的部署，他都非常累。

正是因为这些问题，所以就会有后面我们想聊的 工程效能团队的概念，现在非常流行，包括 Google 现在也在运行的模式。 工程效能团队这批人，一般都是由当时的测试开发人员组成。刚才我谈到有三类人，通常只有第三种人，也就是说工具平台 Service，平台化正式开发的人，他会转到工程效能团队里去。这个 Team 做什么事情呢？ 他就是给开发赋能，赋给开发测试的能力。

那么他通过什么样的方式来给开发赋能？他提供非常简单的 Service，可以让开发去创造任何他想要的数据，他可以给开发人员提供一套部署好的测试执行的环境，他可以给让开发人员非常方便地去创建一个包，并且让它自动化的部署完成。这些都是工程效能团队为了提高开发本身的执行效率、提高它的工程效能，所做的一些平台化，服务化，工具化的东西。这个模式现在是非常的流行，目前像 eBay 就在运行这样的模式，Google 就是业内做的非常成功的一家公司。

Google 引起“去 QE”的故事

茹炳晟：做测试的同学肯定知道一件事情，Google 在业内有一个非常知名的大会，叫 GTAC，它是 Google 在全球的自动化测试大会，每年都会在伦敦、欧洲、亚洲等地方举行。但是到了去年，也就是 2017 年的时候，Google 突然把这个大会停掉了，并在官网上给出了这样一个说明，说了我们为什么会把这个大会停掉？我们的原因在哪里？

这个大会成立已经有十多年了，当时成立这第一届到现在第十几届的时候，他这个初衷是什么？Google 是想提高自动化，提高测试的创新，测试的高效方法，来提高整个工程效率。但到了 17 年的时候，Google 意识到，单靠测试已经不是最好的途径去提高整个企业研发的效能了，所以说，他在这时候把大会停掉，并且提出了 Google 在 2018 年会回归，但会把这个会的名字改掉，不再是一个测试大会，而会是变成一个工程效能 Topic 的大会。

那么 Google 官方的主页都去宣称了这样的一些策略，以及他的想法，对于工程效能的一个定位，并且提供了一篇很漂亮的文章，去解释 Google 的测试开发、测试工程师，及他们的定位，以及在工程效能团队之后，他们这帮人是怎么来定位的。大家可以在 Google 的会议官网首页里找到这篇文章的链接，大家可以去读一下，还是蛮有意思的。

针对初级测试人员，有没有什么建议的学习路线？

茹炳晟：这个是个非常好的问题，而且非常具有典型性。

首先作为一个初级测试人，我对初级的定义一般是在 0 到 5 年，或者 0 到 3 年。要回答这个问题，先明确的一点是，前面我们讲到测试已经不是以前传统的测试，是一个大的测试，是一个广义的测试，那么在这种情况下，测试分为三类人： 一类是做业务功能的测试；一类就是做自动化测试，把这些业务功能的测试转换成自动化的脚本；那么第三类人就是做测试平台、测试工具、测试服务开发的。

你首先需要明确的是，你想在这三块当中所做的是哪一块？明确了这个之后，我们再来看每一块怎么去做发展。

第一类，你想做一个业务的专家，也就是说你怎么来把业务做得非常的精通。这类人在将来应该还是比较吃香的，但是，这类人的数量应该是非常少。为什么？你会发现这类人他非常懂业务，它的业务可以懂到什么程度呢？他可能就变成了一个类似于产品经理的角色，他可以很好的定位这个产品，怎么使用，怎么提高转化率，怎么提高变成一个能够带来流量、带来用户活跃度这样一个角色。他会基于探索式测试的方式，基于对业务的理解，在业务的理解基础上去优化整个流程，提供 UX 这种测试，提高一整个产品的转化率。

那么对于这样一类人，他的成长路径，或者学习方法是什么呢？ 非常简单，他关注的就是业务，要把这个业务本身的来龙去脉，用户的用户场景，以及用户怎么来用你的产品，以及这个产品怎么样帮助用户去解决问题，并且整个业务流程是怎么来操作的，这些业务流程有哪些分支都要懂得清清楚楚。 但这个也是蛮寂寞的，而且劣势也是有的，一旦你离开了这个领域，你是很难找到更好的机会，除非你还在这个领域里跳槽，或者在这个领域找同样的类型。如果离开了这个领域，你的业务积累是没有用的，这是第一类人。

第二类人，开发测试工程师。这种就比较简单了，他的点在于他有些高效的 case 组织方法，或者对于不同测试框架的应用，或者对于不同的测试框架之间的差异、优势劣势有自己的理解，并且能够基于这些测试框架的优势、劣势来选择最适合目前自己产品，或者最适合目前项目的框架选型，并且基于这样的框架选型来定义它的测试的力度，测试用例的力度，测试封装层次，以及代码的结构，并且能够提供一个高稳定性、低维护成本的这种 case。那么这类人更多的是对工具的熟悉。

这个学习主要是一些工具的学习。这个工具学习当中，我认为有一个非常重要的点，因为我接触很多刚刚接触自动化测试，或者刚刚开始做测试的同学，他们对于这种工具的理解是有一个很大的短板，这个短板在哪里呢？他们过度地强调怎么去使用这个工具，也就是说他们拿到的工具，我举个例子来讲，早期的 selenium 1.0 或者现在 selenium 2.0，他就拿过来用，他就根据培训机构手把手交的步骤，把整个东西建立起来，把测试跑起来，然后就完了。自己做一些封装，做一些额外的操作，让这个脚本跑得漂亮就完了。 但实际上，我觉得欠缺了一个很重要的关键点，你必须搞清楚这个工具的原理，如果你不能搞清楚这个工具原理，一旦碰到任何问题，你就不知道怎么解决，你也不知道，你在做一些更深层次事情的时候，你怎么来去设计你的方案。

就比如我可能问在听课的大家，你用过 selenium 2.0？你知道 selenium 2.0 真正的原理吗？你能讲出它的原理是怎么实现的吗？你能讲出 selenium 1.0 的原理吗？1.0 和 2.0 是完全不同的事情，虽然看上去只是两个版本的差异，但它的实现原理，内部的机制是完全不同的。

那么现在非常流行 API，如果你把 selenium 原理搞得非常清楚的话，你就能很容易地理解 API 了，否则你可能觉得 API 又是另外一套新的东西。实际上不是，它还是基于 selenium 那套东西在走。 如果你能真正理解了它实现的原理，也就能够面对变化的时候，你能知道知其然，知其所以然，并且甚至能够开发自己的框架去应对，你可能想过 selenium 为什么可以支持各种各样的语言，有 Python，有 Java，有各种各样的语言支持，有 Ruby，它为什么能够支持？为什么能够做这么多支持？

如果你不懂它的原理，你是很难理解它为什么能支持这么多语言的，但如果你能够理解它的这个原理，你就豁然开朗，原来它是这样子做的，所以它能支持更多的语言。关于这些东西原理的理解，在我的《软件测试 52 讲》专栏里，我也会去做非常深入的讲解，我会讲到一些工具，比如 selenium、API，我可能不会太多的去讲你怎么来使用这个工具，因为我认为怎么来使用这个工具，官方文档永远是最好的一个教材。 官方文档永远是最权威，而且是最新的，如果通过文字的教材，或者通过这种手把手这种教程，它早晚是过时的，而且是跟不上变化的，我建议是这种工具的使用是通过官方的文档。

我的专栏更多的是会基于这些工具，它背后的原理，它怎么做得，它的来龙去脉，以及我们知道了来龙去脉之后怎么用好这些工具，更多的是会讲这样的东西。这样的东西会给你带来更多的价值，而且可以跟市面上现有的一些教材，或者书籍，或者跟官方文档体现出一些差异性，而且能够给你带来真正的一些价值，所以是这样一个状态。

第三类就是测试开发工程师，那么测试开发工程师可以不用讲太多，因为我说白了，他就是个开发，只不过他开发的产品不一样。他是为测试服务的产品，仅此而已。所以对第三类的成长路径，完全就是一个开发的成长路径，你必须作为一个开发人员的角度去做，去让你自己慢慢成长为比较好的开发人员。

但是跟开发又有一个小的不同点。你还是需要理解测试的上下文，你才能做得比较好，你才能真正知道你的产品怎么帮客户去解决测试问题，你还是需要一些对于这种测试的理解，或者是对于这个测试服务需求的这种抽象化的能力。

基于这个问题，聊得比较多，因为这个问题比较典刑，展开的就会比较多，希望不同的人都能，这三类人当中都能有各自的收获。

以上内容取自极客时间的《软件测试 52 讲》专栏，学习该专栏更多深度内容，请订阅： http://t.cn/EUC3kGQ