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

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

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

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

 有些问题，在技术上可能不能称之为缺陷，但确确实实是一种错误，这种错误对系统的运行也未必有多大影响，却让客户感觉到不专业，或者不仔细，对团队的实力产生怀疑。

 我们给客户做了一个财务结算功能，客户的财务人员试用后，提出一条意见：未收帐款记录用红色显示。乍一看，这条意见目的很明确：用颜色给相关人员一些业务操作提醒。 “给记录着色以起到提示作用”是我们做软件提醒功能时的一个常用手段，于是，我们的开发人员未加思索，便将未收帐款所有记录的底色都变成红色，没有人发现其中的问题，这问题似乎太容易了，所有人都未感觉到有什么不妥，然后就得意满满地给客户升级了。谁知紧接着客户就打来电话：“我们是想未收帐款用红色的字显示，不是红底显示，现在一打开界面就是一大片红色，更看不清了。”随后又问道：“你们以前没有做过财务功能吗？”。有财务知识的人应该都知道红字在财务帐面上的含义，而我们却就在是这么一个常识性问题上犯了一个啼笑皆非的错误，不得不再重新改过。

 无独有偶，我们做了一套英文版的系统，其中“已发送（Sent）”的按钮写成“Sending”，客户说：“这个过去分词你们也写错？”

       应该说软件功能测试是一个要求广度的行业，除了测试技术和正在测试的业务之外，还需要很多相关业务的常识，财务、法律、外语……虽不要求上知天文，下知地理，前后知上下五千年，左右知中外发展史，但类似的笑话还是少发生为好吧。

       那一年，我所在的公司是做掌上电脑的，一次有个客户订了两百台机器，这些机器他们预备在周年庆典上给来宾做礼品，因此要求在掌上电脑开启时显示的封面是他们公司的Logo及名称。这个功能并不难实现，因为我们的产品本来就有自定义封面的功能，只要把客户发过来的Logo图片及名称换掉就行了。时间原因，来不及用软件批量换掉再下到工厂生产，所以产品工程部就拿了两百台成品过来，希望我们协助逐台换掉封面再测试通过，直接就可以发给客户了。

      当时测试部门有4个人，机器拿过来时已经下午5点了，晚上大家都加班到10点钟，更换和测试都没有问题，第二天一早就把机器发走了。很简单的一件事情，但是，麻烦很快就来了，客户打电话来说我们把Logo图片弄错了，他们有换新的Logo，图片发给产品工程部了，而我们换上的图片是旧的。原因很快查明，原来客户一直是和产品工程部联系的，他们新的Logo也发给了产品工程部，当时这个任务安排下来时，经理一再交待负责此事的同事去找产品工程部拿图片，而这个同事在之前也给这个客户换过一次封面，因为数量少，之前那次是她一个人做的，所以她就有一个旧的Logo图。而机器拿过来时，产品工程部负责的同事正好出去了，测试部的这个同事就没再去拿图，自以为是的把以前的旧图发给大家了。

        后来我们和客户做了很多解释，客户还比较通情达理，谅解了我们，但内部的责任追究下来，当事人罚款200，经理连带罚款200，我至今还清楚地记得经理站在那个同事面前欲苦无泪的表情，最后只是很无奈地说了句：“我交待过很多次让你去***那里要Logo的”。

        后来我也做了测试负责人，也经常会和其他部门打交道，经常会给客户发布最终版本，“只有一个来源”成为我做版本控制的原则之一。这个来源最好的当然是用版本控制工具，方便且安全。如果团队的人少，也可以使用服务器共享目录。但我一直很反对开发和测试之间使用即时通讯工具，比如MSN、QQ之类的来传输软件更新的版本，哪怕开发和测试都各只是一个人在做。虽然在某种程度上这样更快，但隐患无穷。而且在发给客户之前，就算我手头上有最新的软件版本，也一定会再去来源地取一次版本，并用几小时的时间做最终的版本确定。如果有疑问，也要找到发布测试版本的开发同事问清楚，不让大家辛苦的成果毁在发布这个环节上。

        有一天，客户反馈了一个奇怪的问题：他们的系统上午、下午都是正常的，但是在中午的时候，数据就无法保存，总是提示“保存失败”，我们接到问题的第一个反应通常是：中午的网络或服务器出现故障导致无法保存，但事实上这个答复客户是不满意的，因为做为一个业务操作系统的网络和服务器不会总是在中午出问题，况且只是“保存失败”，查询的功能都可以使用，这说明客户端和数据库的连接是正常的。

        这现象有些怪异，客户的数据库异常日志中报出“字段长度被截断”的记录，但究竟是哪个字段只会在中午被截断呢？我们反复在测试环境中模拟，都没有出现类似的现象，有些一筹莫展，以至于都怀疑是客户的电脑神经了。

        但是问题一直是存在的，客户中午都不能正常做业务，情绪越来越大，于是我不得不重新配了一套新的测试环境，和客户的真实环境基本相仿。说来也怪，到中午的时候，现象真的出现了，因为是在开发环境中出现的，我们很容易跟踪到了被截断的字段，是一个时间控件。本来，如果使用数据库的日期时间类型，所有的时间字段都不会出错的。但数据库设计者为了查询的方便用了字符型，10位字符，按常理来说足够了，为什么出了长度溢出的错误呢？

        后来我想起这个问题出在操作系统上，我们刚开始的测试环境用的是中文版本的Windows2000，中文操作系统默认的时间格式如“10：10：10”，是八位。但是，我们的客户是一家做国际业务的公司，统一使用英文版本的Windows2000，而英文操作系统默认的时间格式是英国的12小时制表示方法如“10：10：10 AM”，加上空格有11位，而11位的情况只在10、11、12点这三个时间会出现，如果是“9：10：10 AM”，刚好是十位。这也正是只有在中午才会保存失败的真正原因。如果在控制面板中把时间的格式调回24小时制的，这个问题不用改就解决了。但是想到客户的每台客户端都要去调这个格式，我们还是升级了数据库，把字段长度放到12位，彻底解决此问题。

        这个问题出现后，我想起来以前读到过的一个“Impossible=I'm possible!”的小故事，这个故事印象深刻，大意是这样的：有一天美国通用汽车公司的庞帝雅克（Pontiac）部门收到一封客户抱怨信，上面是这样写的：“这是我为了同一件事第二次写信给你，我不会怪你们为什么没有回信给我，因为我也觉得这样别人会认为我疯了，但这的确是一个事实。 “我们家有一个传统的习惯，就是我们每天在吃完晚餐后，都会以冰淇淋来当我们的饭后甜点。由于冰淇淋的口味很多，所以我们家每天在饭后才投票决定要吃哪一种口味，等大家决定后我就开车去买。”“但自从最近我买了一部新的庞帝雅克后，在我去买冰淇淋的这段路程问题就发生了。“你知道吗？每当我买的冰淇淋是香草口味时，我从店里出来车子就发不动。但如果我买的是其他的口味，车子发动就顺得很。我要让你知道，我对这件事情是非常认真的，尽管这个问题听起来很猪头。“为什么这部庞帝雅克当我买了香草冰淇淋它就秀逗，而我不管什么时候买其它口味的冰淇淋，它就一尾活龙？为什么？为什么？”

事实上庞帝雅克的总经理对这封信还真的心存怀疑，但他还是派了一位工程师去查看究竟。当工程师去找这位仁兄时，很惊讶的发现这封信是出之于一位事业成功、乐观、且受了高等教育的人。

工程师安排与这位仁兄的见面时间刚好是在用完晚餐的时间，两人于是一个箭步跃上车，往冰淇淋店开去。那个晚上投票结果是香草口味，当买好香草冰淇淋回到车上后，车子又秀逗了。

这位工程师之后又依约来了三个晚上。

第一晚，巧克力冰淇淋，车子没事。

第二晚，草莓冰淇淋，车子也没事。

第三晚，香草冰淇淋，车子“秀逗”。

这位思考有逻辑的工程师，到目前还是死不相信这位仁兄的车子对香草过敏。因此，他仍然不放弃继续安排相同的行程，希望能够将这个问题解决。工程师开始记下从头到现在所发生的种种详细资料，如时间、车子使用油的种类、车子开出及开回的时间……，根据资料显示他有了一个结论，这位仁兄买香草冰淇淋所花的时间比其它口味的要少。为什么呢？

        原因是出在这家冰淇淋店的内部设置的问题。因为，香草冰淇淋是所有冰淇淋口味中最畅销的口味，店家为了让顾客每次都能很快的取拿，将香草口味特别分开陈列在单独的冰柜，并将冰柜放置在店的前端；至于其它口味则放置在距离收银台较远的后端。

现在，工程师所要知道的疑问是，为什么这部车会因为从熄火到重新激活的时间较短时就会秀逗？原因很清楚，绝对不是因为香草冰淇淋的关系，工程师很快地由心中浮现出，答案应该是“蒸气锁”。因为当这位仁兄买其它口味时，由于时间较久，引擎有足够的时间散热，重新发动时就没有太大的问题。但是买香草口味时，由于花的时间较短，引擎太热以至于还无法让“蒸气锁”有足够的散热时间。

即使有些问题看起来真的是疯狂，但有时候它还是真的存在；做为一个测试者，我们每次在看待任何问题都要秉持着宽量的思考并去寻找寻解决的方法，碰到问题时模拟不出现象时不要直接就说那是不可能的，而更应投入一些真诚的努力。而我从遇到那个问题以后，再次遇到在客户反馈回问题而测试环境中无法遇到的现象时，不再以“测试没有发现”为解决的理由，而是会进一步去搭建尽量接近真实操作环境的测试环境或者去客户现场看一看，因此抓住了不少隐蔽的BUG。