在巨人的肩膀上对软件测试的思考（一）

1 为什么需要测试？

1.1 软件测试之美

        无论是Glenford J. Myres的《软件测试的艺术》，Riley & Goucher的《测试之美》，还是朱少明的《完美测试：软件测试系列最佳实践》，都或多或少从某些角度来阐述了软件测试之中蕴含的美感，以期改变人们对测试一贯的“枯燥、重复、多余”的看法。

        《完美测试》的首章以黄金比例的金字塔结构来类比测试的1个中心、5个要素、5个工作面、8个关系等显示了空间之美；黑盒测试等模糊测试展现了距离之美；众多测试小技巧的技巧之美；软件测试方法的对应之美：白盒测试vs.黑盒测试、静态测试vs. 动态测试、被动测试 vs. 主动测试、手工测试 vs. 自动化测试、脚本测试vs. 探索式测试、新功能测试 vs. 回归测试；软件测试对质量与成本、质量与进度、效率与风险的平衡之美。

1.2 测试的心理学和经济学因素

        悲剧的感染力在于，把美好的东西打碎给你看。《软件测试的艺术》中曾说测试是一种“破坏”行为，如上节所说，它也的确具备了某些“感染力”，然而这并不能提供足够的证据令我们接受测试。

        Paul C. Jorgensen在《软件测试（2nd）》说，测试的两个主要原因是：对质量或者可接受性做出判断以及发现问题。

        究其根本，在于对人脑行为的研究以及对经济成本的考虑。如果人类是完美的思考者，我们就不需要对工作进行测试。如果我们是没有感情的机器人，就总可以通过合理的方式来使用测试降低我们做出的决定中蕴含的风险。如果我们是完全相同的克隆，就都会相同的方法来评估风险。但是，我们是不完美的、不理智的、价值驱动的、相互不同的人。因此，我们需要进行测试，并对测试（过程和方法）进行测试，同时考虑经济允许的范围。

2 测试可以带来什么？

2.1 测试与软件系统的内在特性

      Brooks在《没有银弹》提出软件系统的内在特性是：复杂性、不一致性、可变性和不可见性。那么测试对这几个特性的解决程度如何呢？

      一般来说，测试是获取项目信息的过程，是试图提高项目质量的一个途径，它落后于开发过程。对上述四个特性没有特别明显的改善，甚至可能增加了系统的复杂性。不过，敏捷中的TDD倒是可以有所贡献。良好运用的TDD有助于设计简单清晰而易用的接口，只有这样的接口才方便测试，或许可以缓解接口的不一致和复杂性；然后，它使模块切分的足够小并保持极低的耦合度，降低复杂性；再者，它可以支持频繁的“重构”，有了测试用例和测试代码，开发人员愿意尝试更多更好的实现和设计，从而适应可变性；最后，测试代码是“活”的软件文档，提供一定的可见性。

2.2 测试真的提高质量、降低成本、缩小进度了吗

      Dijkstra曾说：“测试也许可以令人信服地表明存在缺陷，但是无法永远无法表明不存在缺陷。”在《完美软件：对软件测试的若干幻想》也提到一个最常见的错误是：相信测试可以改进产品。

      测试是收集有关一个产品的信息，但测试本身并不会修复它发现的那些错误。测试并不会改进产品，改进是由那些修复测试发现的缺陷的人实现的。

      实际上，有些时候进行更多的测试会增加风险。测试不可能不花任何时间或者免费进行；同时对于发现的错误，需要修复的时间和成本，并可能造成对本来已经够有的部分的破坏；其中，可能牵扯到法律问题，对于已经发现的缺陷而因为种种原因不解决，很容易令消费者愤怒，有的时候，“无知”是一种幸福。

      还存在一种情况，付费测试的结果得到的信息与自己预期的不同或者觉得信息量不大导致不使用这些测试结果。也许有的时候并不是测试报告内容不丰富，而是可能连测试人员都无法安装或者很好的理解该软件（这种不理解也可能存在在开发人员中），这就需要去发掘测试报告字面隐含的信息，通常这是非常困难的。使用了测试而不采用测试收集的信息，这浪费了很多金钱、人力、物力。

      一种更普遍的现象是：并非所有人都喜欢并重视测试，因为不希望发现自己犯错。假设公司提出了2种奖励制度：

• 制度A：奖励出现缺陷数量低的团队，那么可能出现2种结果。一种是员工更认真工作、更小心测试，这可能提高了质量；而另一种则可能为了不被发现缺陷而使得软件难以测试，这增加测试的成本，同时也不能确保质量。

• 制度B：提拔按时交付的经理。在不顺利的情况下，经理可能会让测试人员去做别的项目，而开发人员赶进度（实际上永远赶不回进度）。

      还有很重要一点：不良测试也许比不测试更糟糕。误以为产品的质量高于实际，导致在就绪前被交付，误以为低于实际，导致推迟交付。