开发与测试互不重视的现状思考

空闲的时候，我喜欢逛书店。上学的时候逛图书馆，工作的时候逛京东、当当、亚马逊。人们常说见识很重要，逛书店是拓宽见识的很好法门。现在电商的推荐算法有个很好的作用就是能推荐相关书籍，给我们寻找提升之路带来很大的便利。

一次逛当当的时候，看《Google软件测试之道》下面的评论，有一位很认真的评论者，题目叫旧式测试已死，评论了两千多字，这是一位想法很多的软件测试工程师。附在本文的最后。

谈一下我对测试的看法。去年的时候我做了一个问卷调查，选出你最想学习的3项知识，有深入理解计算机系统、DDD、设计模式；在具备一定水平的开发者内做了同样的调查，调查结果显示只是把设计模式换成了性能优化，软件测试没有一个人选。我把软件测试作为备选项是有我的理由的。我发现我们开发在做单元测试、组件测试、功能测试的时候，大多是靠直觉、经验在做事，缺少科学合理的测试理论支持；测试部门写的测试框架，除了应付交付的时候有点用，对于功能防护，甚至没有开发自己写的用例有用，原因首先在于场景过于复杂，一旦出了问题，开发会选择最简单的场景调试，其次在于功能交叉全靠想当然，实际上真正的波及影响一点没有防护到。

由此总结一下测试用例的作用：

1.保证功能正常；

2.保证波及影响可控；

3.出了Bug便于定位

关于波及影响，对于复杂系统是很难说的清楚的，这个更多地需要架构师、高级业务分析师的参与。

实际运作中，由于测试部门对用例有主要话语权，从人的角度，不同功能或特性由不同测试人员负责，他们为了各自的责任，必然会要求开发做重复劳动。

我认为应该打破开发和测试之间的壁垒，高级测试工程师不能靠经验工作（我原来认为，技术开发方向和业务分析方向都要通向架构师，现在我觉得测试工程师也要向架构师发展，即使不做架构决策，也要能理解架构、说清波及）；开发要有测试的基本理论支撑，做好单元测试、组件测试。一方面减轻工作量、提高工作效率，也能提高产品质量。

附旧式测试已死

（一） 看了20%之后写的 约在一年前，James Whittaker和Alberto Savoia在GTAC 2011上说Test is Dead，当时我的理解是，测试工程师这个角色没啥用了。但是看了这本书之后，才发现这样的理解有些偏差。Alberto的说法应该是，在敏捷以及互联网下，传统测试工程师已经没啥用了。 这边书前面几章是介绍google的测试现状的，最主要特点是： 1. 在一个几万人的组织里面，从事测试工作的工程师只有1千人左右。我查了一下这本书成书时google的人数，约在3万上下。假设从事feature开发的人有2万，那么这个测试开发配比将是十分夸张的。 2. Google在07年以前的代码都很混乱，很多该写测试的地方都没写。technical debt很多。 3. Google的迭代速度很快，并不像传统软件那样以几年为一个迭代周期。 这些特点很有趣。 我以前在不少网站上看到不少人在吵测试跟开发工程师的配比到底应该是1：1，1：5还是5：1，但甚少看到有人说1：20的。同时，我也很少看到有测试的人谈代码管理和单元测试的混乱状况的，一般测试的人谈的都是测试的事情，甚少说开发是怎么回事。最后，虽然经常听别人说敏捷，且说迭代速度快，但少有人说其迭代是weekly的。 针对这个现状，google的测试主管Patrick所做的并不是像一般组织那样搞人海战术，而是搞流程和工具。这点跟Lessons Learned in Software Testing所说的测试人员不要把自己当作过程改进人员完全相反。 为了把流程搞起来，Patrick 去弄了一个 CI 系统使得测试可以在每次check-in的时候做，让所有的SET(Software Engineer in Test)去辅助SWE(Software Engineer)写unit test，让所有的SWE感觉写 test 容易，且乐于写test。SET的职责反倒变成了Testing Service的提供者，而不是接受者。这点和我们公司不一样。 在传统公司（不幸的是，我的公司比传统公司还传统）里面，开发所做的测试最多最多就是到集成测试，且都做得很一般。所有的工具要么是公司买的，要么是开发自己造的。而测试和开发则是分离得相当远，测试工程师本身一定是测试者，而不是测试服务的提供者。 Patrick之所以这么弄，是因为他觉得，软件工程所交付的不是code，不是test，而是product，所以得让code和test集成在一起。 基于这个目的，在流程上，SWE才是所有测试脚本和测试的执行者，而SET是负责检查测试覆盖率，简化测试以及测试是否足够的保证者。 这点很颠覆。 Patrick把Testing当作产品的一项feature来做，这是很少有的。我当初在听James Whittaker的All that testing is getting in the way of quality时不懂的东西，在看了这书的前20%时突然明白过来。 因为我们把测试当作是某个人或者某个团队的工作，我们在开发产品的时候，就把quality认为是某个人或者某个团队的职责，从而使得开发者在写代码或者设计的时候就把质量给忘掉，毕竟还是有人可以接皮球的，何必费心呢。 在我从业的这3年里，这种开发不把质量当一回事，公司只知道交付feature的事情总是在发生，而我们的产品质量在这几年内基本没有任何变化。所谓的efficiency上的变化，也基本是公司印度那帮人吹出来的。是的，因为有人垫背，所以我们的开发不做单元测试；因为有人垫背，我们的开发写代码的时候可以直接透传而不必了解之前那一层的人写的是什么代码。 而某些测试工程师却费劲心思的想，某些bug在某些版本没测出来是所谓的“漏测”，但是从系统的角度来看，假设测试是一种测量，这不算是一种系统误差么？这种系统误差难道不是我们的流程所赋予的？ 这本书的前20%也很奇迹的少提到所谓发现bug的方法，在众多的书籍和众多的blog文章中，没有一本或一篇是不介绍怎么“多发现bug”的，但试想一下，这跟在田野边踩牛屎有啥区别？完全是运气问题。 为了让踩屎少出现，只能让测试就是产品本身，而不是附加的东西。 另外，这本书一直在提First Class Citizen，令我想起James在其演讲中问的一个问题：“在座的，有人的工资比开发高的不？一样的？低30%？”结果只有少数人说是差不多，大部分人都是低30%。 一个工种是不是First Class Citizen除了在工资上可以看得出来，在平时讨论时也可以看得出来。在我这个行业，讨论技术细节和如何实施，那一定是跟测试无关的，且很多人不屑于跟测试讨论。为啥呢，问code不懂code，问需求又不如需求人员。 为了让测试的人能够只能批判开发写的代码和需求的问题，Patrick在招聘人的时候，要求一定要懂代码，懂需求而不是随便会按电脑就算是会测试了。WTF，这个世界估计就google能干这种事情了。 看看测试的现状，有多少公司不是因为开发工资比较高，怕他们浪费时间在测试上而请测试工程师的？连Joel on Software的作者在n年前的文章( ，参见最后一条。文章虽是十几年前写的，但是现状区别不大，测试的工资是高了点，但还是比开发低不少。)都说了，这可是便宜一堆钱的选择啊！也难怪现在越来越多的测试被外包给印度人。唉。

（二） 看了70%之后写的 看了约70%时，看到豌豆荚写了篇文章：从 QA 到 EP ( )。这个世界遇到的问题总是相似了，我想所有公司的测试部门所遇到的问题都是相同的：看不到产出，做不了first class citizen。 最近在看这本书的时候，我又回去看了All that testing is getting in the way of quality这个视频，每次看的时候都觉得说得真他妈有道理。视频中，James说Quality的改变是因为有更好的工具，更好的语言，更好的软件重启恢复机制，更好的测试工具，而在这一路上，测试人员本身的贡献少得可怜。 说开发工具嘛，测试人员则少有使用这些工具的，少有测试人员开发这工具；说语言嘛，有多少测试人员开发过一款语言？说更好的软件重启恢复机制，这跟测试关系更小了；说到测试工具，则几乎只是测试人员在用而已。所以James觉得，测试人员并不是真的add value。 况且，实际上一家公司并不关心测试是谁做的怎么做的，他们只关心测试有没有做而已。既然如此，为啥不外包这些工作呢？ 在这本书里面，每次看到TE的工作描述，就觉得他们真的是往开发方向走的，而不是纯粹的测试。比如他们的TE会想办法开发一两款有用的测试工具，比如Quality Bots， 来把自己的测试思想融入到工具里面。而那些手工测试，这公司在google plus上面做得更加纯粹，把一堆测试外包，然后再把测试给众包了，一个纯粹的手工测试人员都没有。 我并不是说这样做，其质量会怎么样之类的，而是James做了一个假定，那就是专门请回来的测试人员不一定能找到一样多的Bug，其价格也不一定比这些众包和外包便宜，如果是这样，何必请那么多贵的人回来做这些没啥意义的事情呢。 是的，许多人都说，衡量测试人员的价值不应该从bug的数量入手，但是如果不从bug的数量入手，怎么去说明呢？如果是从bug的数量入手，何不找些可以找更多bug却要更少钱的方法呢？ 现在网上经常说有人帮google找Bug就有Money了，我每次看到那些新闻，然后看到那几千美金的奖励，我真觉得很便宜。 TE的职责有点相当于一个包工头，负责做dogfood，做crowd sourceing，负责给vendor找事情做，负责plan整个测试流程，偶尔去执行以下探索性测试，写一些测试脚本，写一下自动化工具，检查开发的流程有没有问题。 这不是一般公司对测试工程师的要求，所以这个职位跟我们说的测试职位不同。当然，很多公司那些便宜的测试人员，看起来更像是google请的vendor。 看这本书的时候，我跟我经理谈，说google的TE都不怎么做手工测试啊，也不搞什么重复劳动。我的经理说：“那是人家公司知道自己工程师的价值在哪里。”。难怪google可以做得那么好，人家的起点就跟我们不一样。 这本书有句话是经常讲的，那就是scarcity brings clarity，google做很多事情都尽量让资源稀缺一些，使得工程师不得不想怎么优化工作。但是在现实中，我的公司和我所知道的一些公司就不是如此了，都是在使劲堆人。测试没法完成是吧，我给你叫人上来；开发的东西写不完是吧，我给你加人；什么，单元测试写不完，那就不写了，我们再叫几个人上来写代码。到了最后，整个公司都是人，而做什么项目都好，几乎都是堆人。至于效率，呵呵。