这条规则没有产生太多的误报，而且发现了一些有趣的错误。下图就是一个例子。
对案例2与案例3的再分析
在案例2和案例3中，被测试对象有如下特点：
1、难以构造能够给出标准结果的测试Oracle。自动建议的计算是基于海量数据的模式匹配，行车路线的搜索是典型的人工智能算法。在技术上，很难准确预测它们的输出。从业务的角度，这两个问题在现实世界也不存在“标准答案”。
2、在这两个应用中，Web UI从Web Service API中获得数据。这意味着，测试程序可以忽略UI，直接调用Web Service API，以测试核心逻辑。良好的设计分层提供了可测试性，而可测试性简化了测试程序的构造。
3、测试输入使用真实数据，且相对容易构造。自动建议的测试输入来自必应的服务端日志，测试程序只需要遍历文本日志就可以构造测试输入。行车路线的测试输入是全美邮政编码的两两组合，测试程序只需要读取一个记录全美邮政编码的文本文件，就可以组合出所有的测试输入。
4、单个测试执行速度快，这有助于测试程序在较短的时间内完成大量的检查。自动建议的Web Service API的响应时间应该在毫秒级，行车路线的API可以慢一些，但也必须在1~2秒内返回结果。于是，Harry的程序能够检查2200万个输入，能够使用“全组合”策略提供充分的测试信心。
在案例2和案例3中，测试策略有如下特点：
1、充分利用计算机的运算能力，将（与人力成本相比非常廉价）机器资源使用到极致。
2、用简单的启发式规则构造测试Oracle。利用海量数据和启发式Oracle做数据驱动测试。
3、迭代地构造Oracle。从简单的规则开始，利用测试结果逐步增强、修改、完善Oracle。
4、Oracle的输出不是二值的通过或失败。它更像过滤器，其输出是需要进一步人工调查的案例。
5、与一些测试方法追求精简的测试用例集不同，测试程序运行尽可能多的测试用例。一方面，自动建议和行车路线的缺陷很难预测，需要大量的测试；另一方面，既然单个测试执行速度很快，为什么不多测试一些真实数据呢？
6、充分利用测试工程师的智力。当计算机完成了枯燥的计算，测试工程师可以专注于改进Oracle和调查问题案例，而这些任务是计算机所不能完成的。
7、性价比高。在微软总部雷蒙德，一个测试工程师的年薪大约是8万美元。花1万美元，就可以为他配备10台强劲的计算机，而这些计算机至少可以使用3年。因此，合理的测试策略应该是让机器全负荷运转，让人专注于富有智力挑战的任务。
推荐阅读：
