本故事纯属虚构，如有雷同，纯属巧合
好说歹说答应以后赔偿大家一顿饭，大毛请领导单独下了馆子。
“老大，你今天说的可把我以前学到的理论都颠覆了不少，我得向您好好请教请教。”
“哦？”领导眉毛一挑，“怎么说？”
“我发现每次遇到新的问题，您都不会使用常规的做法去解决，总是要修改这里修改那里的。虽然最后是能解决问题，但是我没办法找到支持那些做法的理论依据，因为这跟书上说的都不太一样。”
“啊哈，比如说？”
“为什么作为测试人员，我也得写单元测试用例呢？”
“单元测试是指开发人员写的测试吗？”
“这个倒不是，但是很多书和文章都说主要是开发人员写单元测试。”
“我们这边不也是大多数的单元测试是开发人员写的吗？目前测试这边也只有你在写单元测试而已。怎么，担心开发人员投诉你吗？”（见作者注1）
……
“为什么我们做性能测试的时候总是实际要做的测试比计划要做的多了很多呢？”
“有什么后果呢？”
“实际上没有，只是测试计划老是跟实际差别很大，这样不好吧。”（见作者注2）
“你看要是发现了bug之后开发人员在做什么？”
“调试啊。”
“这些事情也没写在开发计划里面。”
“呃，你想说多做的性能测试等同于调试？”
“是啊，改变条件，衡量关键指标的变化，找出导致现象的根本原因——这不就是调试吗？”（见作者注3）
“我是问测试怎么会等于调试。”
“你不要太纠结名字，目的和用途才是重要的。”
……
“为什么测试用例还要提供那么多调试信息？开发人员就是要做调试的，让他们再执行一次挂上debugger就好了嘛。”
“你为谁服务？”
“啥？哦，老大你嘛。”
“不是。你想想，我们整个团队发布产品交给客户，为客户服务；开发人员写代码，产生可执行代码，交给我们测试人员，为我们服务；我们提供测试及其结果，把bug交给开发人员，为他们服务；他们修复之后再交给我们，为我们服务。”
“这个说法我没想到过，不过听起来有道理。”
“那你说作为测试，让开发人员拿到bug之后更容易找到bug的根源，是不是优良的服务？”
“嗯，但为什么一定要让测试做呢？”
“并不是一定要。好比你去饭馆吃饭，服务员不一定需要帮你换盘子，但你会更愿意光顾提供这种服务的饭馆，这样为饭馆带来更多的生意。类似的，让开发人员更容易调试，他们就会修复得更快，让我们做更多的测试，发现更多的bug。这是一种双赢。”
“我明白了，老大，我们做了很多额外的事情。但我一直没有机会看到，如果不这么做，又会有什么后果呢？”
领导看了大毛一眼，慢慢的说，“总监也问过我这个问题，他一直认为现在的结果是理所当然的，并不赞同我们去做那么多额外的事情。我需要让他明白，各个项目中出现的不同问题，正是一味按教科书上说的办法去做所带来的，我们正在做额外的事情去解决这些问题。他需要经历不这么做所带来的后果之后，才能明白为什么要这么做。”
大毛不是太明白，“老大你要改变做法？”
“不”，领导把身子前倾，“我决定去一个创业公司，那边并不关心我怎么做，只需要结果。”
震惊之余，大毛硬生生把“为什么”这句话咽回去。
一阵沉默之后，大毛露出坚决的神情，“老大，我跟你走。”
作者注：感谢大家的回复、质疑和问题。从现在开始，我将借鉴美剧的拍摄模式，后边的文章内容取决于大家提出的质疑和问题。
作者注1：单元测试只是表明测试在哪个代码粒度上实施，并不表明谁来做和测试步骤应该怎样。单元测试与功能测试、性能测试等概念其实不是互斥的关系，他们是可以有交集的。所以，测试人员为测试产品而做一部分的单元测试，完全是解决问题的需要：有些测试如果能做成单元测试，它会相当简单和迅速。
作者注2：这里领导使用了一个技巧，设计比较少量的性能测试用例，分配较多的时间，所以实际上并没有延迟。当然要让总监通过这个计划，需要更多的技巧——说服非测试专家的技巧。
作者注3：不要认为依赖profiler就能找到一切性能问题的根源。随着条件的改变，有些指标会变成问题。一开始的若干测试用例可能证明某些指标没问题，而意外的发现另一些指标不对劲，那就需要改变条件——计划外的改变，沿着新发现的痕迹追踪下去。每次改变条件都会有新发现，这是profiler——本质上是一个快照——所无法提供的信息。有些性能问题仅靠profiler就能搞定，正如有些程序崩溃仅靠一个crash dump就能搞定一样，但是不代表任何情况下都是这样。