“你在测什么”，我现在耳边总是回响着那句话。因为无论我们现在做得多么深入，总是无法摆脱我们实际面临的问题，我们到底要测些什么，才能保证软件的质量。想想小时候我们做数学考卷，我们是如何保证答案的正确性的，无非是要么每一步再算一遍，要么是换种方法再求证一遍。如果换到软件开发的话，似乎开发只要做好足够的单元测试便能控制质量了。其实事实也正是如此，随着敏捷开发，测试驱动等等的这么一大堆新颖概念的出现，单纯的系统手工测试将越来越少了。你甚至能看到很多关于测试将死的文章。

  于是开始引出测试的一个悖论，即测试就是要消灭自己。

  因为随着我自己的经验不断的积累，越发深入之后，我会发觉，一般正常的程序员总是能满足需求实现功能的，然而很多问题则出在异常处理，条件出错等等。所以很多时候，我会直接看代码，需求部分的逻辑判断只要写对就不再会有问题，剩下的就是看对可能的异常情况是否做判断和处理 。如果这部分欠缺，那直接给个用例便能验证。可是，对于我这种金牛座的人来说，问题来了，如果我知道该怎么写，为什么我不去写代码，我完全可以替代掉开发写出高质量的代码，因为我能有测试的思维，我知道该处理哪些异常情况。想到这里，你便能明白，开发是能够做得更好的，他们拥有技术，缺的只是一种质疑的态度。如果他们有测试的思维，代码既能满足需求又能控制异常，那测试做什么。

  测试开始专注业务吗，找到业务隐藏的缺陷？那我觉得请几个业务专家或者产品更合适，他们才是业务的开发者，他们真正了解业务背后的盈利模式和整个市场的动向，你只不过知道那简单的业务流程而已，有时你还甚至为此高兴觉得好像知道很多似的。好了，其实对于公司而言，你的角色是有点尴尬的，你不创造价值，反而你还消耗资源。于是你发现，完全可以不需要测试这个角色啊。这时我又想起过去老大招人的一个条件，认可测试这份工作。

  认可测试，多么简单的一句话，却道出了所有事情的真相。我们的存在便是要消灭自己，在控制成本的前提下，越来愈多的公司都没有单纯的手工测试了，随着人力成本的提高，这是一个必然趋势。但目前来说还是会有很大需求，因为中国人便宜嘛，花点小钱请人来点点控制一下风险，产品也就能上线赚钱了，多好，你说呢？ 

  但是如果文章写到这里就结束，似乎话还只说了一半。因为我否定掉了大部分人的工作却没有指明一条路，未免有点刻薄。

  不过我也不想告诉你去搞自动化，去搞性能才是正道。正如还是那句话，你在测什么，同样的问法，你在做什么，你为何选择测试，你就会知道你的方向了。 这个真得要扪心自问了。