关于测试的问与答（转载）

转自http://www.javaeye.com/topic/692657

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

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

大神用他那一贯充满怜悯的眼神看着我，说到：我可怜的孩子们啊，愿上帝保佑你们。之所以需要测试，都是上帝的错啊，上帝创造了你们，但是因为没有测试，所以你们都是不完美的、不理智的，你们会犯错。

我说：我明白了，因为我们每个人都各不相同，我们会被情绪、环境左右，不理智、价值驱动，而我们的大脑也是有限的，更糟糕的是那狭小的大脑只有该死的5%得到了开发，所以我们需要测试。

大神点点头，他对5%这个数字充满了怜悯，当然，他对任何事情都充满怜悯。我想，我该叫他怜悯之神。

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

怜悯之神说：你的工作难道不也是天天敲键盘吗？

我想了一下，说：那不一样，我敲键盘是在写代码，那些漂亮的页面、增删改查都是代码实现的。

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

我说：关键是思考。

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

我想，这有什么好笑的吗，连朝鲜昨晚都进球了。我说，其实对软件开发人员来说，我们也应该通过使用自己的产品来对他进行测试。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我说，好吧，测试很重要，可是为什么很多项目最后的集成测试阶段会那么长哩？这总是导致我们的项目延期。

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

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

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

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

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

我说，oh。

神说，测试不等于除错，把整个集成测试阶段归于测试是不公平的。

我说，是的，如果区分开，相比测试，除错占据了更多时间。恩，我们现在的一个项目特性，由于开发时没有考虑性

能问题，导致上线时花费了大量时间。

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

我说，是的，这个给我的印象很深，如果在开发阶段就进行大数据的测试，那么会节省很多时间。

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

我说，还好，我们还有测试，不像某些疫苗，直接上市。那么，测试保证了质量？

神说，你觉得蒙牛没有测试吗？

我说，....

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

我叹口气，说，测试能够保证软件质量。

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

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

神说，是的。

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

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

神说，你觉得呢？

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

神说，然后呢？

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

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

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

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

神说，测试只是采样，所以良好的测试需要能够根据上下文覆盖系统中最重要的部分，而且又不能膨胀到不可管理的地步。另外，多样化样本发现的问题可能超过大样本发现的问题，同样，测试团队多样化也可能发现更多的问题。

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

神说，“良好”并不是属于某个测试的属性，它只能是测试、实现、成本和应用场景四者之间关系的属性。作为比较，系统上线后用户的使用可以看做是测试的继续。

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

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

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

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

神说，你怎么看？

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

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

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

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

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

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

我问：好吧，如何避免测试困难呢？

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

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

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

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

我说，这似乎很困难，因为客户总是在要求我们加功能。

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

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

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

我说，我们需要向新系统中导入遗留数据，如果在程序里包含对所有数据的处理，非常复杂，最后我们选择了手动处理部分数据。

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

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

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

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

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

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

           神说，演示不是测试。

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

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

           我说，演示之前我们会进行准备工作。

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

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

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

我叹了口气，说，额滴神啊，看起来测试真不是一件容易的事。

神说，额滴上帝啊，测试就从来没有容易过。