测试先知和启发式方法

测试人员拿到测试任务时，需要考察两类基本情况。第一类是测试人员的情况：

n  测试人员的测试经验怎么样，丰富还是欠缺？

n  测试人员对被测产品的行业经验怎么样，熟悉还是了解？

n  测试人员对被测产品的需求了解怎么样，熟悉还是了解？

第二类是被测产品的情况：

n  产品开发目前处于什么阶段？

n  产品是否经过了测试，使用了哪些类型的测试，覆盖了哪些功能和属性？

n  产品目前的风险或潜在问题有哪些？

测试人员应该仔细分析和理解这些情况。在时间压力和业务质量压力下，测试人员需要根据正确的信息来驱动测试活动，这样才会取得较好的效果。

首先测试人员需要非常清楚自己的情况，也就是自己所拥有的知识（Knowledge），包括产品知识、行业知识、测试技术、开发技术和计算机基础等。

检查这些知识是为了在测试时能够快速和有效地确定所发现的问题是否是差评缺陷。即测试人员需要综合各种知识以构造一组测试先知，从而高效地识别产品缺陷。一种构造测试先知的可行方法是参考HICCUPPS（F）启发式规则[Bolton05]，它们通过一致性检查来识别产品缺陷。

n  历史（History）：目前所做的产品的版本是否与过去的版本相一致。

n  愿景（Image）：产品是否与开发组织的愿景相一致。

n  相似产品（Comparable Products）：产品是否与类似的产品相一致。

n  声明（Claims）：产品是否与重要人物的声明相一致。

n  用户期望（User’s Expectations）：产品是否与用户期望相一致。

n  产品自身（Product）：产品中可比较的各个功能是否一致。

n  目的（Purpose）：产品是否与其（明确的或隐含的）目的相一致。

n  法规（Statutes）：产品是否与适用的法律相一致。

n  常识（Familiarity）：产品是否与常识相一致。

尽管我们有很多方式去丰富测试先知，但不支付足够的时间成本很难达到非常完美的程度（所有预期输出都在测试之前明确下来是需要很多时间成本投入的），因此我们在探索式测试过程中往往会遇到以下问题：

n  没有测试先知可以使测试人员提前确定所观察到的系统行为必定是正确或错误的。

n  没有一个单独的测试先知可以说明某个功能在任何时间或任何情况下都是正确工作的。

n  有些功能看上去是正常工作的，但在某些情况下会失败，且会影响其他测试先知的正确性和适用性。

可见，测试人员构造测试先知时，肯定会遇到很多困难，那么该如何解决呢？以下是三个可能的思路。

n  忽略这个问题（也许这个信息的价值从成本角度考虑不值得）。

n  简单化这个问题（改善可测试性以获得更多的信息、分析需求、规约和代码，从而获得更简单的检查规则）。

n  转移这个问题（考虑问题的相关性，从类似问题下手）。

在测试设计过程中，测试人员还可以使用启发式方法（Heuristics）来产生更多更好的测试思路，例如[Bach11]：

n  引导词启发法（Guideword Heuristics）：一些词语或标签能引导测试人员发掘自身的知识和经验，产生新的测试思路。。

n  触发器启发法（Trigger Heuristics）：一些存在于事件或条件中的想法，能提醒测试人员采用另外一种方式来进行试验，就像思维的闹钟一样。

n  副标题启发法（Subtitle Heuristics）：能帮助测试人员重构测试想法并获得更多的选择点。

n  启发式模型（Heuristics Model）：一组系统性的想法能帮助测试人员控制、管理和挖掘更多的想法。

实际上，人们在日常生活中也经常使用启发式方法，例如，我们常用如下简单的规则处理复杂的现实问题：

n  酒后驾驶非常危险。

n  一鸟在手要强于二鸟在林。

n  不入虎穴，焉得虎子。

n  人们有时在计算机旁边隐藏自己的密码，尝试从那里寻找。

n  假期商店一般较晚开门。

n  如果你的计算机出现了莫名其妙的行为，重启。如果还是有问题，重装操作系统。

n  如果这是个真正重要的任务，你的老板会跟踪它，否则，你可以忽略它。

由这些例子可知，启发式方法是一种经验方法，它针对复杂的问题提出了一种简单的、较可能成功的解决思路。使用启发式方法，人们可以快速地采取行动，在实践中去探索答案，从而避免陷于无止境的问题分析，毫无进展。然而，启发式方法只是一种“捷径”，它不保证提供了“最佳答案”，也不能确保总是提供“正确答案”。因此，明智的测试人员不会依赖特定的、单一的启发式方法，他会综合运用多个启发式方法，并根据实践结果调整测试方法和测试先知。

本文节选自《探索式测试实践之路》一书

史亮，高翔著

电子工业出版社出版