对于搜索用户，自动建议（AutoSuggest）是一项贴心的设计。但是对于测试工程师，这不是一项容易测试的功能。

　　1、手工探索式测试无法保证测试抽样可以覆盖用户输入。与必应搜索庞大的用户输入相比，手工测试的覆盖率接近于零。传统的等价类划分等测试抽样方法，对于如此海量的、无规则的输入，也无可奈何。

　　2、传统的自动化测试遇到的困难是无法构建测试Oracle。自动建议的核心实现是基于海量数据的人工智能算法。算法的输出受到多个因素的影响，如当前用户的查询、近期的相似查询、自动拼写更正、关键词过滤（如去除色情内容）等。对于特定的输入，很难构造自动建议的“预期结果”。

　　面对困难，Harry的测试思路是构造启发式测试Oracle（Heuristic Test Oracles）。所谓启发式Oracle，就是使用规则对测试结果进行一致性检查。开始时，Harry的规则非常简单：

　　Harry编写了一个简单的测试程序。它从必应的服务端日志中获得真实用户的查询，调用自动建议的Web Service API，以获得这些查询的自动建议结果，最后利用上述规则对结果进行检查。

　　很快，测试程序发现了不满足规则的案例。当输入是“nestb”，自动建议返回“bestbuy.com”（百思买，财富500强消费电子零售商）。这是自动建议的拼写更正（Spelling Correction）功能，它将用户的“疑似错误输入”，纠正为一个最可能的结果。该行为是可接受的。于是，Harry将规则修正为：

　　虽然不知道Harry的具体做法，我能想到若干“合理近似”的判定方法。

　　1、将单词看作向量，计算向量之间的距离。距离小于指定阈值的单词对，可以认为相互“近似”。

　　2、查询Office Word的拼写更正字典，获得指定单词的所有拼写更正建议。这些建议可以视为单词的“合理近似”。

　　3、调用必应的搜索API，获得搜索结果。搜索结果中的高亮关键词可以视作查询的“合理近似”。

　　Harry利用修正后的规则又发现了一些违规的案例。如输入“dond”，自动建议返回“nbc.com”。也许这符合某些文化上的约定，但值得进一步调查。再例如，输入“federal trust bank”，自动建议返回“floridalottery.com”。这个建议应该是错误的，需要开发者去调查哪里出了问题。在这个过程中，启发式Oracle更像一个过滤器，它处理海量的数据，过滤出需要测试者人工审查的潜在错误案例。

　　通过持续运行测试程序，Harry获得了以下成果。

　　1、测试运行了7天，覆盖了2200万个用户查询。

　　2、发现了1万个有问题的建议结果。

　　3、在建议词条数据库中，发现了1.9万个从未被返回的建议词条。它们应该被剔除。

　　当然，真实的测试过程比上述描述要复杂一些。但是，它们都拥有相同的核心：从简单的测试Oracle开始，利用测试反馈持续完善Oracle。Harry将这种迭代式的测试开发过程称作涌现式测试（Emergent Testing）。