新手并不满意。“如果操作系统不失效呢？”他问道。

    “没有不失效的操作系统。”行家说。“假如这样的操作系统存在，硬件终也会由于错误而失效。”

    新手仍然感到不满意。“如果硬件不失效呢？”他问道。

    行家长叹一口气。“不存在不失效的硬件。”他说。“假如存在这样的硬件，用户还会要程序做不同的事情。这也是一个错误。”

    没有错误的程序是荒唐可笑的，是不可能存在的。假如存在没有任何错误的程序，那么世界也会不复存在。

    这个故事给不负责任的程序员以借口。但事实是否真的如此严重？对于硬件来说，高密集度的电子元件集成使人们很容易理解它是不稳定的这样一个结论，但从现实情况来看，硬件的稳定性要远高于软件的稳定性。

    或许，软件规模的不断膨胀使其复杂度指数增长，个人能力已无法完成，团队成为必须。团队磨合也成了产生错误的隐患。但在传统行业里，这种情况也是屡见不鲜的。扬浦大桥，东方明珠，金贸大厦也不是一个人完成设计的。是缺乏经验没有磨合团队的良好方法？

    软件设计究竟有多复杂？是不是已经复杂到了不可能避免错误的程度？我想这不是一个很容易可以回答的问题。

    对于第三个问题，我认为也是一个主要的因素。虽然每个公司每个程序员都知道，减少错误可以博得用户的青睐，战胜竞争对手。但普遍来说，市场的认同纵容了公司和程序员不负责的心态，毕竟，减少错误是要付出代价的。

    在很多公司和程序员看来，bug和测试似乎是紧密关联而分不开的。程序员只顾编写代码，认为有没有bug有多少bug测测知道了。

    把软件质量依赖于测试，是不可能真正解决软件质量问题的。

    测试不是解决错误的根本举措，只是一种辅助手段。但又是必须的手段，我想现在已经不会有人再问出“如果程序员更仔细一点，测试会是不需要的吗？”这样的问题了吧。

    软件测试的首要任务是发现错误。发现错误也许要花很大的代价。因为测试是复杂的，不存在好的办法使每次测试都是有效的。有这么一句话：如果做某件事有两种或多种方法，其中有一种方法会导致一个灾难结局，那么也会有另一种方法导致同样的结局。

    测试的复杂性和软件的复杂性是一致的。也是说由于软件的复杂导致了测试的复杂。

    测试提出了基本的和令人困惑的难题。假使我们在测试时从来不希望检测被测系统所有可能的输入、路径和状态，那么应该选择什么？什么时候应该停止？如果我们必须依赖于测试来防止某种失败，那么我们怎么来设计既是可测试的又是有效的系统呢？我们怎样来编写一个测试包，它可以检测足够多的消息和状态的组合来说明没有失败的操作，但是从实用性来说它又足够的小？

第二个目的是对于给定的测试包，说明被测系统是符合规约所描述的需求。

    所以，我觉得测试活动与软件过程协调一致得好与坏，都对测试的有效性有很重要的影响。

    如果测试的开发是在一个项目开始时进行的，那么测试将是非常有效的。及早考虑可测试性，及早进行测试设计，和尽可能早地实现测试，提高了有力预防错误的方法。这些过程迫使设计人员更仔细地考虑需求和规约的实现，其结果可能改进应用设计。关于体系结构、详细设计和编码实践的及早决策，都能使测试变得更容易更经济。

    写到这里，我想应该停下来了，虽然我还有一些问题和想法，但无法固定它们，我觉得已经有些糊涂了。后，从脑海里跳出了一个问题：测试与对质量的承诺是一致的吗？