在给企业的测试工程师上课时，问：“知道test oracle吗？”
有的同学首先想到的是“甲骨文”——一家数据库公司的名字（现在更被称为“全球最大的企业软件公司”），最近“Oracle中国”裁员900人闹得沸沸扬扬，即使没有这裁员风波，了解“甲骨文”的IT人要比了解“test oracle”人要多得多。
Oracle，在古希腊还有“神谕、神示”的含义，甚至包含传达神谕的“牧师、女祭司”。
详见：https://en.wikipedia.org/wiki/Oracle
那什么是Test Oracle呢？
Test Oracle就是一种决定一项测试是否通过的（判断）机制，常被翻译为“测试预言”，也可以翻译为“测试判断准则”。Test Oracle的使用会要求将被测试系统的实际输出与我们所期望的输出进行比较，从而判断是否有差异。如果有差异，可能就存在缺陷。这是软件测试过程中最基本的环节。所以，test oracle（测试预言）至关重要，如果不明确测试预言，就无法判断测试结果是否正确，也就意味着无法进行测试。虽然许多测试人员不清楚这个概念，但还一直从事着测试工作，似乎还做得不错，没有什么影响。那也许就是“神谕”，借助神谕来判断测试结果是否正确。
只要你设计测试用例或执行测试，就需要明确“test oracle（测试预言）”，这绝不含糊，不管是潜意识行为还是有意识去做。test oracle（测试预言）一般有下列几种：
- 需求规格说明书和其它需求、设计规范文档
- 竞争对手的产品
- 启发式测试预言（Heuristic oracle）
- 统计测试预言（Statistical oracle）
- 一致性测试预言（Consistency oracle）
- 基于模型的测试预言（Model-based oracle）
- 人类预言（Human oracle）
测试过程中，判断测试结果是否通过，我们就需要明确Test Oracle。对于已知的检测，我们会用到测试预言 第1、2、5、6项 （如清晰的Spec、竞品参照、一致性要求、确定性模型等），如图所示，其中基于模型的预言，也只能是确定性的模型。如果是随机模型、模糊模型，就属于不确定模型。
对已知的输入／输出进行检测示意图
当我们开始一个软件项目，测试工作也随之开始——进行测试需求分析。这时，我们就可以将测试的范围（测试项）分为两部分：相对稳定的、明确的测试项和不确定的、容易变更的测试内容。针对已知的测试项，比较容易设计测试用例，理论上也基本能百分之百实现自动化。而针对未知的部分，就需要试验、需要探索。只是这种试验或探索，可以由手工来做，也可以由工具来做。测试的风险也往往来自这部分——不确定的测试内容，值得我们特别关注，测试需求分析时分为这两部分就更加有意义。
- 当Test Oracle属于启发式的，需要综合判断的，这时候就需要手工测试——测试人员的试验，不断质疑系统，根据系统的反馈来做出判断，这就是探索式测试。探索式测试也有测试场景、测试思路的设计，但没有详细的设计——测试用例的设计，但探索式测试能发挥人的创造性、分析能力和思维能力，不断设计、执行、分析、学习、再设计、再执行、再分析、再学习……这样持续改进的测试过程，使测试不断优化，测试的效力不断得到提升，能更快、更多地发现问题。
- 对于工具的实验，例如一些系统出现崩溃的原因不明，只知道很有可能是异常数据造成的，这时就可以有工具来进行测试，包括产生随机数据来实现测试，或建立一个初步的数据模型，由模糊控制器产生数据、或对正常输入数据直接进行变异数来完成测试，如图1-6所示，这就是自动的随机测试、模糊测试、变异测试等。这时，可以基于统计准则、或系统异常的表现，来做出判断：是否发现了缺陷，这些方法常常用于系统的安全性测试、稳定性测试等。
过去，我们可以常常能拿到清晰完整的功能设计规格说明书（Functional Specification），有可以参照的Spec，测试结果是否正确容易判断。今天我们常常拿不到这样的Spec，而且面临一些新的软件字体——大数据应用、AI应用等，test oracle问题就更突出，值得大家关注和思考。
上面主要内容节选自《全程软件测试（第3版）》第一章1.8小节：
http://product.dangdang.com/26271857.html
还可以参考：软件测试的一个新公式引起的思考
