测试先知是什么

264 2023-07-18

如果你有去看测试相关的英文资料，会看到一个比较有意思的词：test oracle。非常的常见。这个词是什么意思呢？肯定不是数据库测试。多数情况下，会翻译成：测试先知。这是个什么东西？

在设计测试用例的时候，测试人员都会指定输入项和预期值。测试先知,指的就是这个预期值，也就是你认为正确的输出应该是什么，或者你判断测试用例执行通过的标准是什么。所有测试都离不开测试先知，它是应用任何测试技术都需要考虑的环节。它是一种识别潜在问题的启发式原则或机制。测试人员需要从不同关系人角度，设计多个测试先知来考察软件的行为。

测试人员需要非常清楚自己的情况，也就是自己所拥有的知识，包括产品知识、行业知识、测试技术、开发技术和计算机基础等。检查这些知识是为了在测试时能够快速和有效地确定所发现的问题是否是缺陷。即测试人员需要综合各种知识以构造一组测试先知，从而高效地识别产品缺陷。

很多人说，测试判定一个测试结果是否是缺陷，最可靠的依据不就是需求文档么？如果需求文档有明确的定义，那么这样的测试先知就是明确的，没什么好讨论的。仅仅靠需求文档，是否足够呢？

测试专家Michael Bolton和James Bach提出的识别和运用测试先知的想法列表，一共有七种，简称HICCUPPS。

History(历史)：软件的功能与它的历史行为一致，以保证用户的数据、技能、经验持续有效

笔者注：个人的经验是，在迭代测试前期，对于那些流程红结构发生变化的环节，要特别注意数据和功能的兼容性。例如某个功能需要去掉某个元素，那么历史数据如何处理，如何显示？如果增加一个字段，那么是否需要给个默认值？在业务数据流转的过程中，如果某个环节被取消了，那么前后的数据如何做好衔接？这都依赖于测试人员对业务的熟悉和深度的思考。

Image(愿景)：软件的表现符合开发团队设定的期望，将精力集中在产品最有价值的属性上。

笔者注：这个对于传统模式下的研发测试人员，可能会有点陌生，但是对于熟悉敏捷研发和测试的人员，应该会非常熟悉，每个迭代的功能是否在原来的故事地图或者旅程地图上能够找到对应的规划？是否有些功能偏离了预期？这个也是需要测试人员关注的。

Comparable Products(可对比的产品)：使用相似产品作为测试先知来评测当前产品。

笔者注：笔者曾经组织过团队内的测试对象竞品分析，获益匪浅，在同类竞品的测试过程中，我们可以提高对自身产品的认知，知道哪些功能或者操作能够获得用户的认可。如果你对某些测试对象不熟悉（特别是偏底层的技术型应用测试，例如网关、基础服务、流量跟踪等技术底层应用），找一款同类产品来验证和学习，是非常有效的方法。

Claims(声明)：产品满足项目文档关于其功能和质量的论述，包含需求说明书、用户手册之类的文档

笔者注：这个就是测试先知的主要来源，在敏捷的环境下，我们需要更早的参与需求讨论，并且实例化，以便快速构造验证方案。

Users's Expecations(用户期望)：测试人员站在用户的角度思考，以检查软件是否真正地为用户服务并达到了他们的期望

笔者注：产品经理很多时候并不会很高频的使用自己的系统，对功能的理解也不会特别深刻（我相信大部分测试都会比产品经理更熟悉产品本身，不论是操作还是流程），所以测试人员更应该从使用者的角度去尝试提出一些问题，并有能力去验证这些问题。

Product itself(产品本身)：产品所拥有的功能和使用模式彼此一致

笔者注：这个更多的是关注产品的交互方式是否一致、风格是否一致。

Purpose(意图)：产品能够体察并服务于用户的意图

笔者注：关注产品身本主要解决什么用户痛点。可以结合KANO模型对需求进行分类。

Statutes and Standards(法规和标准)：建议测试人员研究产品相关的法令法规、行业标准、合同约定、技术标准等强制性法规，用它们作为测试先知来指导测试设计和评估。

笔者注：笔者有做海外项目经验，也协助过团队认证国家安全等保。所以有过相关的经验，特别是当你的产品需要出海，或者部署到特定区域，需要适当关注下。

通过了解HICCUPPS，确认测试先知，有助到我们提前识别潜在问题，测试人员并不能依靠单一的测试先知去判断测试是否通过。测试先知本质是一种启发式方法，它提供了有效的检查策略，但不能发现所检查领域内的所有缺陷。

尽管我们有很多方式去丰富测试先知，但不支付足够的时间成本很难达到非常完美的程度（所有预期输出都在测试之前明确下来是需要很多时间成本投入的）。所以，我们可以结合之前提到的启发式测试策略，综合应用这些技巧，在测试活动正式开始前，做好准备工作，为测试活动的正式开展，做好准备。