如上一篇文章软件测试三大难题：我们必须面对和解决所说，今天我们往往拿不到详细、完整、清晰的设计规格说明书，而且大数据、海量用户的存在，输入的数据空间和用户的操作空间都很大，Test Oracle问题就更加突出。

哪有什么策略和方法应对呢？

1. 通过文档编写、评审、沟通和LLM技术等完善和澄清需求

如果没有详细、完整的需求规格说明书或设计规格说明书，那我们设法提高这方面文档的质量，例如参与需求文档的编写、需求文档的评审，甚至不让评审走过场，通过评审尽量消除模糊、二义性的问题，补充丢失的需求，为后续测试设计提供明确的预期结果和标准。

强化需求沟通：与相关方进行更深入、频繁的沟通，尽可能明确和细化需求，减少模糊地带，尽可能在需求内容上达成一致的理解。

甚至可以借助大模型（LLM），逐步细化需求、澄清需求和评审需求，降低这方面的工作量，迅速提升需求文档的质量：软件工程3.0实践之路(三)：LLM辅能需求定义和评审，结果很震撼

2. ATDD（验收测试驱动开发）：通过明确验收标准来澄清需求，而且是测试在前，确保100%可测，比较彻底解决Test Oracle问题。这类方法的实践还包括BDD（行为驱动开发，敏捷的一种开发框架）、需求实例化。

3.快速原型法：先构造一个原型（类似Mockup UI），基于这个原型来讨论用户需求，通过构建简单的原型，让各方对系统功能和操作有更直观的理解，有助于发现潜在问题和明确测试标准等。

4.参考竞品：例如，大家认为银行应用系统，招商银行的App是标杆，我们测试时就可以对照招商银行的App是如何实现的，包括UI界面、操作流程等。类似 “黄金程序（The Golden Program）”，使用一个已知正确的程序版本作为标准，来验证新版本或修改后的程序的正确性

5.A/B测试：像UI设计优化、推荐算法的验证，虽然有一些理论（包括心理学、行为学方面的）可以参考，但还不能按照这样的理论来验证，因为其UI或算法可能就基于类似的理论来设计的。我们知道“实践是检验真理的唯一标准”，采用A/B测试的方法，最终基于用户反馈数据做出客观的判断。可以参考：如何做A/B测试？

6.测试集验证（数据/样本验证）：像机器学习训练，一般会将一个数据集拆分为“训练集”（通常占70-80%）和“验证集”（通常占20-30%），但验证集还不等于测试集，虽然它也是验证模型训练的结果是否达到要求，即获取准确率（Accuracy）、召回率（Recall）、F1分数、AOC曲线等相关指标的结果。其实，我们完全可以超越原来数据集重新构造一个测试集，因为时间、范围等因素会影响原来的数据集，我们更看重“更为真实的、广泛的、现时的实际数据”来验证开发的模型。

7. 蜕变测试（ Metamorphic Oracles）：通过改变输入数据来获得额外的测试用例，并检查输出是否符合预期的模式，从而验证程序的正确性，详见：高效测试技术详解系列（4）：蜕变测试。

8. 使用启发式预言（Heuristic Oracles）：在没有明确预期输出的情况下，使用启发式方法来综合评估输出的正确性。这主要依赖探索式测试，详见：？究竟什么是敏捷测试和探索式测试？

关于AI应用的测试，一般会采用 上面第5、6方法，例如采用样本实验，这就取决于定义评测指标，然后基于评测指标来构造测试样本。指标定义的是否科学合理、样本构造的好坏直接影响测试的效果。能构造样本，说明Test Oracle还是比较明确的。多数情况下是不明确的，需要采用第8种对策，人（专家）直接参与批判，类似图灵测试（图灵测试，测的到底是什么？ ）、Delphi方法（专家评测法），让系统直接和人对抗，可以参考：如何测试人工智能软件？ 。