测试疏忽的可见成本

   我一直在想，测试在很多公司不被重视，甚至于被视为可有可无的角色，是不是因为测试工作不能产生看得见的经济效益？如果一个系统到了客户手里，很少出现问题，则所有的人会认为那是理所当然的，看不出测试有什么重要作用。而如果软件未完成测试就交给客户使用，通常的做法就是反馈—>修改—>升级，现在通讯方式发达，这个过程的可见成本也是很低的，测试的好坏似乎并没有直接的现金收入和损失。

    但那一次我却真实地看到了一起直接损失。我们给一个物业管理处开发了一套物业管理软件。老实说，这个软件还是通过了一定程度的测试，不过物业收费名目繁多，计算方式复杂，在有限的时间里，测试覆盖率值得怀疑。这个软件在管理处用了一个多月，也比较正常，没出现所谓的严重缺陷。然而，一个多月后，管理处反映说他们根据系统算出来的水电费少了1千多块。这问题有些难以置信，计费用例被划为重点用例，有点个位数上的误差是可能的，但差这么多就不是个小问题了。我们再对这个功能再反复测试，结合客户的真实数据，结果吓了所有人一跳：一个极为常用的功能，却漏掉一条十分正常的测试路径，而就在这条路径上，心存侥幸导致损失惨重。在当时的物业管理中，水费是按三段收费的，例如一段用水是1.9/吨，二段用水是2.85/吨，三段用水是3.8/吨，这个用水吨数分段值可以用系统设定，如第一段设成0-5，第二段5-15，第三段15以上，这个用例说起来还有些复杂，吨数在第一段、第二段、第三段分别是三个计算公式，然后考虑边界值和异常值。当吨数在第一段时，最容易计算，直接单价*数量，在第三段时比较麻烦，要把三段的值加起来。现在，第一段和第三段都没有错误，我们的系统在第二段出问题了：当吨数在第二段时，总金额是第一段和第二段的金额相加，而开发者写程序时，拷贝了第一段的公式，却没有加上第二段。测试者对这个功能也测试过，但是，她只看到系统得出了结果，刚好第一段和第三段的结果又都是正确的，就没有手工用计算器再算一次。当用户的吨数刚好落在第二段时，金额就算少了。

    管理处已经找业主收完水电费，在与水公司缴费时才发现这个问题，因怕业主会闹又不太可能补收，只好他们自己承担了这1千多块的损失，因为其他的原因，这个客户并未找我们公司赔偿，但是却让我看到了测试疏忽产生的可见损失， 在以后的软件缺陷分类中，“计算错误尤其是计费金额错误”列入了严重缺陷之列，虽然它看起来并不影响到系统功能的使用。

    题外话，最近看到几起因银行ATM机故障造成储户多取款的事情，最近一起，多取款的那个人被判无期，实在是天大的冤枉，他用人生替ATM的生产商承担了“莫须有”的责任。后来听说ATM的生产商赔付了银行的所有损失，这个也应该算是软件质量问题产生的可见成本吧。但是，银行，真黑！