以前在业界经常会听到有测试人员抱怨说开发总是觉得他们的工作没有技术含量，鼠标点点就行了，小学生都会做。强势的测试会骂开发无知，导致双方对立。而弱势的测试人员只能黯然伤心。那么真的会鼠标点点的人就会做测试吗？
先引用一个很多人也许听过的故事，故事的内容是这样的：一个家伙因车子几乎不能驾驶而将车送到修理库，发动机突突地响而快不行了，血红色的排气正从消音器中泄漏出来，整个轿车摇动颤抖着。修理工盯着车子看了一会，打开车盖，用一支铅笔大小的螺丝刀快速地旋动一颗深深嵌入发动机箱中的螺丝。车子修好了，车主露出了满意的笑容。“请付800美元”。“什么？你旋拧一颗螺丝要800美元？”“哦，不。旋一颗螺丝只需要1美元。但是，我让你付799美元是因为我知道该旋哪个螺丝以及如何旋拧它。”
这下手工测试人员应该都清楚了，以后再碰到有人说你的工作就是鼠标点点的话，你可以讲这个故事并且理直气壮得承认:“没错，我的工作就是鼠标点点。但是这个工作只需要1美元，另外的799美元是因为我知道如何用鼠标点点来把Bug都找出来！”
的确，软件测试是一个技术活，不是拼人数的工作。
但是当一项技能只有少数人掌握的时候，这些人会很忙，因为他们是不可替代的。正如同蜘蛛侠和超人，他们都没有时间谈恋爱，甚至连陪家人的时间都没有，亲人都会对他们有很多误解，觉得这孩子无可救药了。
在淘宝有一个约定俗成的概念，开发人员和测试人员要成一定比例，这得到很多人的认同。这个比例是从哪里来的呢？从经验值。去年的项目投入多少开发工时、多少测试工时，于是今年也差不多这样。或者一个项目经理会认为我上一个项目投入的资源比例是多少，于是下一个也要这样。
但是随着我们系统的复杂度的增加，这个比例在逐渐的改变，变化的趋势是测试人员的比例在增多。有时候我们仰望一下微软，发现他们测试人员占了半壁江山，我们沾沾自喜的发现我们还不够多。
那有没有办法控制人员的增长呢？
我们以平台测试组的人员为例：
一开始我们是在做单元测试，这些工作以前是开发人员的任务，但他们没有做好，于是我们凭空出来干这件事了，我们每增加一个人员，相对于以前来说，都是测试人员的净增长。
随着我们的工作日益深入，我们总结出来一套架构、流程、工作方法、工具模板，我们做的这些工作比开发人员更加快速高效，而且我们能够节省其他测试人员的工作，这样下来，测试人员的增长趋势在下降（这有一个上升到下降的过程，类似抛物线）。
在不久的将来，平台测试的技术成熟之后，我们可以把这些知识传授给开发人员。这样，在一个项目中，我们出一个人来做整套测试方案，而测试的执行主要由开发人员来做（这类似一开始他们单元测试的工作内容，对开发人员来说没有多大难度）。这样下来，我们输出标准，得到结果，过程交给别人。看起来就会很和谐。
功能测试有没有类似的东西呢？
我听说冒烟测试已经开始尝试交给开发人员了，这是一个很好的开始。
当我们把越来越多的东西输出之后，我们就能够做更加高端的工作，例如理论的研究、模型的建设，我们工作中的知识含量就会远超过劳动含量。
“做测试的行业标准”，这不仅仅是一个梦想，这将使我们从“劳动密集型”产业走向“知识密集型”产业。
（这里没有提自动化测试，这是我们标准的一部分，它从另外一个维度增加我们的知识含量，解放我们的双手）
先引用一个很多人也许听过的故事，故事的内容是这样的：一个家伙因车子几乎不能驾驶而将车送到修理库，发动机突突地响而快不行了，血红色的排气正从消音器中泄漏出来，整个轿车摇动颤抖着。修理工盯着车子看了一会，打开车盖，用一支铅笔大小的螺丝刀快速地旋动一颗深深嵌入发动机箱中的螺丝。车子修好了，车主露出了满意的笑容。“请付800美元”。“什么？你旋拧一颗螺丝要800美元？”“哦，不。旋一颗螺丝只需要1美元。但是，我让你付799美元是因为我知道该旋哪个螺丝以及如何旋拧它。”
这下手工测试人员应该都清楚了，以后再碰到有人说你的工作就是鼠标点点的话，你可以讲这个故事并且理直气壮得承认:“没错，我的工作就是鼠标点点。但是这个工作只需要1美元，另外的799美元是因为我知道如何用鼠标点点来把Bug都找出来！”
的确，软件测试是一个技术活，不是拼人数的工作。
但是当一项技能只有少数人掌握的时候，这些人会很忙，因为他们是不可替代的。正如同蜘蛛侠和超人，他们都没有时间谈恋爱，甚至连陪家人的时间都没有，亲人都会对他们有很多误解，觉得这孩子无可救药了。
在淘宝有一个约定俗成的概念，开发人员和测试人员要成一定比例，这得到很多人的认同。这个比例是从哪里来的呢？从经验值。去年的项目投入多少开发工时、多少测试工时，于是今年也差不多这样。或者一个项目经理会认为我上一个项目投入的资源比例是多少，于是下一个也要这样。
但是随着我们系统的复杂度的增加，这个比例在逐渐的改变，变化的趋势是测试人员的比例在增多。有时候我们仰望一下微软，发现他们测试人员占了半壁江山，我们沾沾自喜的发现我们还不够多。
那有没有办法控制人员的增长呢？
我们以平台测试组的人员为例：
一开始我们是在做单元测试，这些工作以前是开发人员的任务，但他们没有做好，于是我们凭空出来干这件事了，我们每增加一个人员，相对于以前来说，都是测试人员的净增长。
随着我们的工作日益深入，我们总结出来一套架构、流程、工作方法、工具模板，我们做的这些工作比开发人员更加快速高效，而且我们能够节省其他测试人员的工作，这样下来，测试人员的增长趋势在下降（这有一个上升到下降的过程，类似抛物线）。
在不久的将来，平台测试的技术成熟之后，我们可以把这些知识传授给开发人员。这样，在一个项目中，我们出一个人来做整套测试方案，而测试的执行主要由开发人员来做（这类似一开始他们单元测试的工作内容，对开发人员来说没有多大难度）。这样下来，我们输出标准，得到结果，过程交给别人。看起来就会很和谐。
功能测试有没有类似的东西呢？
我听说冒烟测试已经开始尝试交给开发人员了，这是一个很好的开始。
当我们把越来越多的东西输出之后，我们就能够做更加高端的工作，例如理论的研究、模型的建设，我们工作中的知识含量就会远超过劳动含量。
“做测试的行业标准”，这不仅仅是一个梦想，这将使我们从“劳动密集型”产业走向“知识密集型”产业。
（这里没有提自动化测试，这是我们标准的一部分，它从另外一个维度增加我们的知识含量，解放我们的双手）
