关于测试的问与答（下）

愚人

尊重作者只是产权，若转载请注明出处

http://www.javaeye.com/topic/778086

原文发表于《程序员》第9期。



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

神说，你觉得呢？

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

神说，然后呢？

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

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

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

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

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

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

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

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



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

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

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

神说，你怎么看？

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

            神说，演示不是测试。

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

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

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

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

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

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


[img][/img]


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

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

cain_1313

好吧，因为是神，所以他注定不会走下神的圣坛。
而职场中的“神”就是我们的客户，老板，领导....他们是实在的