作为芸芸众程序员的一员，我对软件开发中的一切都充满问题。今天是关于测试，作为一名唯物主义者，我相信众物都有其神，于是我找到了测试之神。

我问：神仙，为什么我们需要测试？

大神用怜悯的眼神看着我，说到：我可怜的孩子，之所以需要测试，都是上帝的错啊，上帝创造了你们，但是因为没有测试，所以你们都是不完美的、不理智的，你们会被情绪、环境左右，会犯错。

大神说这话的时候充满了怜悯，当然，他对任何事情都充满怜悯。我想，我该叫他怜悯之神。

我说：哦，这么说上帝也是不完美的，因为他也需要测试？

怜悯之神果然是神仙：咳咳，说到哪儿了，你吃饭了吗？

我问：我们需要测试，可是，为什么我看测试人员只是天天敲键盘而已啊？

怜悯之神说：你敲键盘是在写代码，测试人员敲键盘是在获取当前系统的信息，这两者真正的工作都是那些脑力活动，是在敲击键盘这个物理行为之前以及伴随这些物理行为的脑力活动。如果你敲击键盘的时候没有进行思考，那么你就不是在进行开发和测试；而且，如果你在思考但是没有敲击键盘，你还是可能在进行开发和测试。

我说：关键是思考。

怜悯之神说：是的。他显然对后半句犹豫了一下，但是还是说了，人类一思考，我们就发笑。

我想，一点都不好笑，连朝鲜都一比零小胜巴西了。我说，其实对软件开发人员来说，我们也应该通过使用自己的产品来对它进行测试。

怜悯之神点点头，说，这叫做“吃自己的狗食”，如果你都对自己的产品感到担心和鄙夷，别人为什么要买它？

我说，可是，除非我们开发的是开发工具，否则我们根本不可能用它。地球人都知道，做减肥药广告的从来不喝减肥药，买火腿肠的从来不吃火腿肠....人人都需要是化学家。

怜悯之神说：所以完全由开发人员构成的测试样本不太可能代表整个用户群。

我自言自语道，所以我们需要测试人员，需要另一个角度的思考。

我问：尽管测试人员测试了，但是为什么系统还是存在缺陷哩，难道他们不对所有可能性都进行测试的吗？

怜悯之神翻了我一个白眼，叹了口气。作为报复，在下面的叙述中，我将称他为白眼之神。

白眼之神说，对任何程序而言，可能进行的测试数据都是无限的。测试也许可以令人信服的表明存在缺陷，但是永远无法表明不存在缺陷。

我想了想，说，我们现在的系统需要导入客户的遗留数据，光报表就多达20万，如果一张张的校验报表内容和样式，那么一定会死人的。

白眼之神说，那你们是怎样测试的哩？

我说，抽取样本测试哈。我说，我明白了，由于我们无法测试所有的可能性，那么任何测试实际上都是某种程度的样本测试，这些样本以某种方式代表整个可能测试集合的一个部分或者片段。

白眼之神点点头，说，测试只是采样！

我说，正像我们去医院体检，所有化验单上都写着，本结果只对该样本负责。

白眼之神说，实际上，采样也是一个心理过程，而且是一个感性过程，令某人满意的样本也许会让另外一个觉得一点都不满意。

我说，由于不可能进行穷举测试，所以我们往往在两个目标间徘徊：希望测试能够覆盖所有令人感兴趣的条件，希望测试集减少到可以管理和承受的程度。就像吃自助餐，希望吃到所有东西，但是又要不把肚皮撑破。

白眼之神说，所以我们需要尽可能选择那些具有最强代表性的样本进行测试，而这是测试人员的优势。另外，多样化样本发现的问题可能超过大样本发现的问题，同样，测试团队多样化也可能发现更多的问题。

我说，是的，同样是抽血，一些人会要求早上不吃饭抽取静脉血，一些人则需要间隔取几次血。

我问：开发中，我们采用了TDD的方式，我们单元功能测试的覆盖率也很不错，这样，我想我们可以减少测试人员？减少系统测试？

神说，你会因为一架飞机保证它所有的部件在组装前都进行了测试而乘坐它的处女航吗？

我说，哦，罗老号发射失败了。

神说，但是，良好的单元功能测试能够为系统测试去除噪音。

我说，缺陷都不是自己钻进去的，而是开发人员放前去的。单元功能测试能够在一定程度上阻挡开发过程中缺陷的进入，同时阻挡一些简单的缺陷，系统测试不能捕获所有缺陷，相对单元功能测试，系统测试会花费更长的时间和成本，这些时间和成本能够通过单元功能测试得到部分节约。

神说，开发人员的测试保证了他对需求的理解和实现的一致，但是开发人员对需求的理解和真正的需求一定一致吗？

我说，所以需要测试人员即时验收。

神说，另外，关于TDD，从心理学的角度说，一个人是很难发现自己的错误的，所以TDD和结对编程一起实践会有比较好的效果。

我问：为什么很多项目最后的集成测试阶段会那么长哩？这总是导致我们的项目延期，而几乎所有的项目都会延期。

神说，说说你们的集成测试阶段都在做些什么？

我说，噢，我们拉出一个发布分支，冻结代码提交，开始进行测试，找出缺陷，查明缺陷原因，根据重要性修改缺陷，然后重新测试，以此循环。恩，问题在于此时总会发现大量缺陷，并且我们每修复一些缺陷总会引入新的缺陷，所以这个时间拉得很长。

神说，修复缺陷的同时引入新缺陷，这叫做故障反馈率（FFR），也就是一个修复让系统中产生了另一个缺陷的情况所占的百分比。这个数值如果在50%以下就很幸福了，另外，压力和试图提高缺陷修复速度都会提高FFR。

我说，也就是修复缺陷的同时引入新缺陷是个正常情况。恩，可是我的问题是为什么最后的测试阶段需要花费这么长时间？

神说，难道你不觉得是你们经理错误的估计了最后集成测试阶段所应该花费的时间？

我说，噢！

神说，此外，测试不等于除错。

我想了想，说，是的，说的是最后集成测试阶段，但实际上包含了两个行为：测试和除错，相比测试，除错占据了更多时间。恩，我们现在的一个项目特性，由于开发时没有考虑性能问题，导致上线前花费了大量时间进行调优。

神说，项目延期的主要问题在于测试推迟。

我说，是的，这个给我的印象很深，如果在开发阶段就进行大数据的测试，那么会节省很多时间。一个缺陷，发现的越晚，修复的成本就越高。

神说，要测试先行，并且测试往往在项目开始开发前都已经开始了，测试需要贯穿于整个开发过程，频繁进行，而是不推迟到最后的集成测试阶段。TDD和持续集成是很不错的实践，但是它们仅仅是测试中的一部分。

我说，那么，测试保证了质量。

神说，三鹿没有测试吗？

我说，....

神说，测试只是提供信息。至于这些信息的定义、重要性以及所要采取的反应都取决于人，而人做出的决定都是感性的，利益驱动的。

神说，如果开发的产品本身就质量低劣，进行测试你不觉得是浪费大家的时间吗？对低劣的代码测试得再好又有什么用呢？一段时间发现的缺陷越多，并不意味着剩下的缺陷越少，而总是意味着会出现更多的缺陷。

我说，我明白了，测试只是收集信息，除此之外，并不能做其他任何事情。正如我们去体检，体检报告只能反映出当时我们的身体状态，至于健不健康，则取决于我们平时的生活习惯，这是两个分开的事情，体检并不保证我的健康。

神说，很多大公司非常看重测试部门，原因其实是他们无法看清楚他们自己的开发过程，于是只能从测试里获取信息，而这些信息对整个软件开发来说只是一部分而已。我看到过有项目经理向测试人员询问是否可以交付，这根本上就是在推卸责任，信息和作出决定根本是两回事，更何况测试收集的信息只是部分信息呢，如果是这样，不如让测试人员来当经理好了。

我说，怪不得每次去检查身体问化验医师有没有问题正不正常，化验医师总是不耐烦的说去问医生呢。

我问：什么测试才是良好的测试呢？

神说，你觉得呢？

我说，测试的目的是发现缺陷，所以发现的缺陷越多，那么测试越好。

神说，然后呢？

我说，我会告诉测试人员，啊哈，你们发现的缺陷越多，我就发给你们越多的奖金。

神说，又是一个糟糕管理的绝佳范例。

我说，确实会有问题，这样对测试人员来说，一个低劣的系统对他们的价值最高，他们会爱上那些糟糕的开发人员，引发办公室恋情。这和整个团队的目标-交付高质量的系统矛盾，并会在开发部门和测试部门之间引起矛盾和争执。还有，发现的缺陷会增加，但是获得信息的质量却降低了。

神说，你混淆了测试的目的，测试的目的不是发现缺陷，而是获取我们所需要的信息。作为对比，如果你所有体检的项目都正常，你会觉得体检没有价值吗？

我说，恩，我会很高兴。

神说，测试只是采样，所以良好的测试需要能够根据上下文覆盖系统中最重要的部分，而且又不能膨胀到不可管理的地步。

我说，想起来了，我们在体检的时候往往会有不同的检查套餐，例如针对白领的，会着重检查胃和颈椎；针对40岁以上人群的，会增加癌症因子筛查。也就是测试并不是一个孤立的行为，它需要根据不同的情况采取不同的策略。而且，我们总希望体检时不用花太多的钱。

神说，“良好”并不是属于某个测试的属性，它只能是测试、实现、成本和应用场景四者之间关系的属性。

我说，无法衡量测试？

神说，作为比较，系统上线后用户的使用也可以看做是测试的继续。

我说，你的意思是我们可以对系统在使用中出现的缺陷加以追踪，然后进行统计和分析，例如测试比较典型的遗漏了哪种缺陷，而哪种测试实际上是没有太多必要的，因为用户根本都没有使用该功能。这样，以后我们就可以对测试加以改进。

我问：那么，我们需要对所有缺陷都跟踪记录？

神说，你们没有对所有缺陷都跟踪记录？

我说，有些缺陷太小了，例如拼写错误，有些缺陷很容易就修复，所以测试人员就直接和我们说了，没有填写缺陷记录。

神说，你怎么看？

我说，我觉得还不错，没有一个开发人员愿意自己的程序里出现错误，我们往往把程序看成了自己的扩展，指出程序有错误就是在指出我有错误，所以，对于一些很小、由于疏忽引起的错误，测试人员直接和我说而不记录让我感觉好一些。

神说，缺陷只有在系统交付后才成为错误。

我说，好吧，可是报告我的程序出现缺陷会让我受到批评。

神说，那是另外一个关于团队管理的问题了。如果一个人花在指责其他人上面的时间越多，那么解决该问题的可能性就越低。

我说，可是，我们应该反对文档，文档阻碍了交流，实际上没有太大的价值。

神说，文档在不使用的情况下才没有价值。一些人反对的不是文档，而是自己写文档。信息在文档化之后才能被追踪和统计，特别是作为项目信息一部分的缺陷信息，它反映了项目的状态，一定不能够被忽略，如果为了“节省时间”和“面子”而不记录缺陷，那么导致的结果就是项目状态的丢失，会给项目后续的判断带来影响，以后会浪费更多的时间和金钱。

我说，我想起来了，每次去取体检结果时，我都会看到本次体检指标与历次的对比，这次的结果提醒我胆固醇又提高了，颈椎则好了很多，所以要少吃肥肉多锻炼，同时晓庆教我的颈椎病锻炼要继续坚持。

我问：收集信息似乎只是第一步，信息的处理过程又是怎样的呢？

神说，你们是怎么做的呢？

我说，首先，测试人员会选择样本对系统进行测试。比如发现系统不能上传图片了，测试人员会报告一个缺陷，记录下详细的信息。

神说，这是第一步，摄取信息，此时，信息在被人确定含义之前是没有意义的。

我说，接着，我们会看到这个缺陷报告，并和测试人员进行交流。测试人员表示了担忧，因为上传图片对客户来说是一个很重要的功能，现在连它都不能正常工作是否意味着系统的其他部分也存在很多问题。

神说，测试人员在给信息赋予含义。

我说，我们和测试人员一起重现了这个缺陷，系统报出的问题是权限认证失败，我们认为这是一个权限方面的问题，上传图片的其余功能应该不受影响，也许是有人改动过当前测试用户的权限，也有可能是上一次提交破坏了什么东西，总之影响不会很大，因为这块有很多的单元功能测试，如果是提交破坏，也应该是页面上的代码，这段代码不多，错误能够很快定位和修复。

神说，你们在给信息赋予含义，不同的人会给信息确定不同的含义。

我说，接下来，我们会讨论这个缺陷的优先级。测试人员认为这个缺陷很重要，应该立刻修复；我们认为这个缺陷虽然重要，但是非常容易修复，并且此时有另外一个非常重要的缺陷需要修复；项目经理询问了我们各自对这个缺陷的理解，说，我们现在有一个特别重要的关于图片搜索的缺陷需要修复，我认为这个缺陷最重要，因为后天需要给客户的老板进行演示，上传图片的功能也很重要，但是不在演示的范围之内，但是既然很容易定位，我们也可以迅速的查明引起问题的原因，但是不修复。

神说，现在在确定信息的重要性，并做出反应。不同的人会给信息确定不同的重要性。

我说，那么完整的过程应该是：摄取信息->确定含义->确定重要性->做出反应。

神说，是的。

我说，等等，我看到问题了。因为不同的人会确定不同的含义，不同的人会确定不同的重要性，所以对做出决定的人来说，他一定要有自己的理解和权衡，并根据自己的重要性和其他信息最终做出决定。但是现实情况却并非如此，很多信息在提供给管理者之前已经被信息提供者赋予了他所定义的含义和重要性，而管理者由于不能获取其他信息或干脆就没有思考，所以就直接根据信息提供者所定义的含义和重要性做出决定了。

神说，你想到了什么？

我说，忠臣、奸臣和昏君。其实没有忠臣和奸臣，只有昏君。看似管理者高高在上，手握生杀大权，但其实权利早就被信息提供者瓜分殆尽了。

神说，你扯远了。

我问：好吧，下一个问题是如何避免测试困难呢？

神说，你觉得是大的系统容易测试还是小的系统容易测试？

我说，当然是小的系统容易测试。

神说，那么，让系统尽可能的小。

我说，现在一个普通游戏都要好几个G。

神说，第一，让需求受控。这是一项很重要的管理工作，如果没有很好的完成这项工作，那么就是管理上的失败。

我说，这似乎很困难，因为客户总是在要求我们加功能，而有些功能确实是很重要的。

神说，如果在项目后期要求增加功能，而这项功能又是必需的，那么实际上是在告诉我们需求分析出现了问题，出现了需求遗漏。而一项功能如果最终因为各种原因其实不能使用，那么也是需求分析出现了问题，出现了需求冒进，脱离了实际情况。

神说，要控制需求的增长，就需要决策者、需求分析人员和客户来区分某件事对客户来说真的是必需的，需要价值驱动。

我说，第二呢？

神说，第二，不要试图在软件中处理所有的可能情况。

我说，这个我有印象，我们需要向新系统中导入遗留报表，由于遗留数据跨越十年，所以存在很小一部分不规范的网页，如果在程序里包含对所有报表的处理，那么是相当困难的事情，最后我们选择了手动处理这部分数据。

神说，第三，代码质量。最好的实现永远是最简洁的代码，要尽量减少代码的复杂性。两个具有相同物理规模的程序在内部复杂性上可能有极大的不同，而这最终会是决定测试工作难度的主要因素。

我说，我们可以通过增量构建，不一次做所有事来控制代码的复杂性。

神说，此外要注意组件之间的分离，特别是多团队协作的项目。

我说，是这样的，对于大型项目，往往会划分以模块为单位的小组开发，小组之间、模块之间要尽量减少依赖和不必要的沟通，因此代码可以有冗余，每个开发小组都要各自独立，有自己的分析人员、开发人员和测试人员。

提到增量构建，我又有了新的问题。

我问：我们现在采用迭代式开发，那么每次迭代完成后对客户的演示能不能算是用户验收测试呢？

神说，演示不是测试。

我说，客户触摸到了真实的系统，直观了解到了系统的功能和使用方式，获取了系统信息，然后进行反馈，这可以看作是部分用户验收测试。

神说，对客户来说，如果没有真正的使用该系统，那么就没有进行测试。此外，客户获取的信息难道不是你们准备好的吗？

我说，是这样，演示之前我们会进行很多准备工作。

神说，实际上是在准备客户能够获取的信息。

我说，那么最理想的迭代开发应该是持续部署？

神说，持续部署和持续增量使用。