机器学习的软件测试（机器测试的主要方法）

引用 MARIJAN, Dusica; GOTLIEB, Arnaud. Software Testing for Machine Learning. In: Proceedings of the AAAI Conference on Artificial Intelligence. 2020. p. 13576-13582.

摘要 机器学习已经在多样的应用中流行起来，但是机器学习会出现错误。这对机器学习能否在更广泛的领域进行应用提出了质疑，特别是在重视安全性的应用中，除非我们能够确保其正确性和可靠性。软件验证和测试是为了保证这些特性而建立的技术。然而机器学习的软件测试挑战是巨大的，这些困难需要我们去克服。本文讨论了机器学习的软件测试的最新进展，更具体地说，它讨论了机器学习系统的软件测试的六个关键挑战，测试了应对这些挑战的当前方法并强调了这些方法的局限性。本文提供了一个研究议程，详细阐述了推进机器学习测试的进展方向。

引言

机器学习(ML)技术的应用已经成为许多创新领域的关键。与此同时，ML 的脆弱性很明显，有时会引发灾难性的故障。为了确保 ML 的系统的正确性和可靠性，需要对 ML 进行全面的测试。与传统软件系统的测试相比，ML 系统的软件测试更容易受到影响。在本文中，我们所说的传统系统指的是未集成ML的软件系统，而ML系统指的是包含ML训练过组件的软件系统(如自动驾驶汽车、自动驾驶船舶或太空探索机器人)。传统的系统通常是预先编程并执行一组规则，而 ML 系统以概率的方式推理并表现出非确定性行为。这意味着对于恒定的测试输入和先决条件，经过 ML 训练的软件组件可以在连续运行中产生不同的输出。传统的测试方法通常无法充分解决 ML 测试的基本挑战，这些传统方法需要适应 ML 的新环境。

在本文中，我们:1)确定并讨论在 ML 软件测试中最具挑战性的领域;2)综合最有前途的方法来应对这些挑战;3)关注他们的局限性;4)对机器学习软件测试的进一步研究提出了建议。

Testing ML

解释“Testing ML”:两个不同的团体一直在研究Testing ML的概念，即 ML scientific community(MLC)和 software testing community (STC)。然而，由于这两个团体从不同的角度研究 ML 算法，他们对“Testing ML”一词的解释也不同。在 MLC 中，执行 ML 模型的测试以估计其预测准确性并提高其预测性能。测试发生在模型创建过程中，使用验证和测试数据集来评估模型在训练数据集上的拟合。在 STC 中，测试一个 ML 系统具有更广泛的范围，旨在评估一系列质量属性的系统行为。

Testing ML的挑战来自于潜在的随机推理的内在复杂性。与传统系统不同，传统系统的代码是演绎式构建的，而 ML 系统是归纳式生成的。定义系统行为的逻辑是从训练数据中推断出来的。因此，故障不仅可能源于错误的软件代码，还可能源于训练数据中的错误。然而，现有的方法通常假设高质量的数据集是有保证的，而不应用系统的质量评估。此外，ML 系统需要高级推理和学习能力，能够在之前未知正确答案的情况下给出答案。ML 系统具有固有的不确定性，这使得它们随着更多数据可用而不断改变行为。此外，对于包含多个 ML 模型的系统，模型会影响彼此的训练和调优，可能导致非单调误差传播。

缺少测试oracle

不像传统系统操作预先编程的确定性指令，ML 系统基于随机推理。这种基于随机或概率的推理在系统响应中引入了不确定性，从而导致不确定性行为，包括不可预测或不明确的行为。测试用例通常由被测试系统的特定输入和这些输入的预期输出指定，称为测试预言。然而，由于随机推理的原因，一个 ML 系统的输出不能预先指定，而是通过一个 ML 模型来学习和预测。这意味着 ML 系统没有定义可以在测试中与实际值进行比较的期望值。因此，测试 ML 时输出的正确性很难确定。

对不可测试系统考虑的一种方法是pseudo-oracles，运行多个系统以满足与原始测试系统相同的规格，然后向这些系统输入相同的输入，并观察它们的输出。输出的差异被认为是被测系统错误的指示。Metamorphic testing是另一种不可测试系统的软件测试方法，一个转换函数被用来修改现有的测试用例输入，并产生一个新的输出。如果修改后的输入的实际输出与预期输出不同，则表明被测试软件存在错误。

完全测试的不可行性

ML 系统通常部署在处理大量数据的应用领域，这就创建了巨大而多样的测试输入空间。不幸的是，测试很少能够覆盖所有有效的输入和它们的组合来检查被测试系统的正确性。

对于测试覆盖率的问题，有一种方法是名为神经元覆盖的度量，用于测试深度神经网络(DNN)。测量 DNN 中神经元总数中由一组输入激活的独特神经元的数量，但是把神经元覆盖率作为覆盖率指标可能过于粗略，网络仍然容易受到微不足道的对抗性示例。另一种方法是DeepCover，这是一种具有四个测试标准的 DNN 测试方法，包括测试用例生成算法，该算法使用线性规划扰乱给定的测试用例，目标是对测试需求和 DNN 的片段进行编码。

基于神经元覆盖的技术的一个常见局限性是它们很容易导致组合爆炸，目前有研究启动了组合测试技术的适应工作，以在 DNN 的不同层对大空间的神经元交互进行系统采样。鉴于其当前的局限性已得到克服，这种方法有望在基于 DNN 的系统测试中抑制组合爆炸。

由于 DNN 的输入空间通常是大的和高维的，选择 DNN 的测试数据可能是非常费力的。处理这一挑战的方法（1）模糊处理，它生成大量随机输入数据，用于检查失败；（2）使用由用户指定的约束组成的覆盖度量来随机改变输入。覆盖的度量采用快速近似最近邻算法；（3）运行变形变异以生成新的语义保留测试，并使用多个覆盖标准作为反馈从不同角度指导测试生成。

为了提供更有效的输入选择以增加测试覆盖率，concolic 测试方法通过一组覆盖将需求参数化。需求用于增量地生成一组测试输入，其目标是通过在具体执行(对特定输入进行测试)和符号执行之间的交替来提高需求的覆盖率。

ML模型测试数据集质量

在训练 ML 模型时，训练数据集的质量对学习模型的性能至关重要。性能是使用测试数据集评估的。

为了评估 DNN 测试数据集的质量，目前有两种主要评估指标。第一种受传统突变测试概念的启发，提出了初步工作，首先设计了一组变异算子，将故障注入到训练数据中。然后，利用突变的训练数据对模型进行再训练，生成突变模型，即将故障注入到模型中。然后，使用测试数据集测试变异模型。最后，通过分析注入故障的检测程度来评估测试数据集的质量。另一种检测方法是 MuNN，不同深度的神经网络需要不同的变异算子。

系统脆弱性

ML 分类器容易受到攻击，即对输入数据进行小修改，导致错误分类并使 ML 系统发生错误。对输入数据所做的修改，称为对抗性示例，是设计成与原始数据非常接近的小扰动，但可能导致错误分类和损害分类器的完整性(例如准确性)。

生成对抗性示例的方法包括快速梯度符号法、FGSM、RAND-FGSM、DeepFool等。此外，还有一种基于回合的双人随机博弈方法来生成对抗性示例，第一名玩家试图通过操纵功能来最小化与敌对例子的距离，而第二名玩家可以是合作的、敌对的或随机的。该方法已证明收敛到最优策略，代表了一个全球最小的对抗形象。同样，对抗性示例可以通过生成式对抗网络生成，如AdvGAN，但是该方法利用了分类器对协变量转移的脆弱性，并且对输入数据的不同分布很敏感。

为了应对对抗性攻击，人们提出了针对对手的反应性和前瞻性防御方法。包括Defensive distillation与 Automated verification。Defensive distillation是一种主动的方法，旨在降低 DNN 的对抗性扰动的有效性，但是这种防御机制通常无法防御一些新的攻击。Automated verification针对敌对扰动的反应性防御方法，它分析 DNN 的鲁棒性以提高其防御能力。包括验证 DNN 分类正确性的穷举搜索方法、Reluplex、基于自适应嵌套优化的全局优化，其复杂性都是 np 完备的。

评估 ML 模型的鲁棒性

神经网络缺乏鲁棒性引起了人们对依赖这些网络的系统安全性的关注。提高神经网络鲁棒性的一个典型方法是识别使神经网络失效的敌对例子，然后用这些例子增加训练数据集，训练另一个神经网络。另一种方法是用线性规划衡量 DNN 鲁棒性指标。

对于需要遵守安全法规和认证的安全关键领域，在对抗性输入扰动下提供 ML 性能的正式保证至关重要。提供这样的保证是大多数防御方法的真正挑战，包括上面讨论的方法。在这个方向上的现有尝试包括通过在训练中使用正则化通过更新训练目标以满足鲁棒性约束。虽然这些初始方法很有趣，但可以证明它们只能达到中等水平的稳健性，即提供近似保证。因此，需要进一步研究为 ML 模型提供鲁棒性保证。

伦理机器推理的验证

ML 系统可以部署在其行为具有道德影响的环境中，例如自动驾驶汽车，因此，它们需要有能力对这种影响进行推理。这一研究领域在很大程度上仍未得到解决。现有的努力是有限的，包括一个可以正式验证的自治系统伦理决策的理论框架。该框架假设系统控制与高阶决策分离，并使用模型检查来验证理性 agent(模型检查是验证伦理机器推理最广泛使用的方法)。然而，作为一个限制，所提出的方法要求伦理计划已被正确地诠释与伦理后果，这不能保证。第二，代理验证被证明是非常缓慢的。第三，由于传感器输入模型的不确定性，该方法对传感器数量和传感器值的伸缩性很差。

关于自主推理的认证，开发了概念证明方法，该方法用于使用正式验证和飞行仿真生成自主飞机的认证证据。然而，该方法依赖于一组假设，例如系统的需求是已知的，或者它们已经被准确地翻译成正式的规范语言，而正式的规范语言可能并不总是成立。最后，伦理机器推理应该是透明的，以允许检查潜在的推理。这些发现强调了在验证和证明伦理机器推理方面取得进一步进展的必要性。

总结与未来方向

机器学习的软件测试面临着一系列开放的研究挑战，需要进一步的研究工作来解决这些挑战。我们展望今后的工作将朝以下方向发展：自动化测试oracle、ML模型的覆盖度量、ML模型测试数据集的质量、对抗性示例的成本效益、对抗对策的成本效益、ML模型的鲁棒性评价、经过认证的ML模型的鲁棒性保证与机器伦理验证。

通过这篇论文，我们希望为研究人员提供有用的见解，了解 ML 测试尚未解决的挑战，并为推进这一研究领域的最新进展制定一个议程。

致谢

挪威研究理事会项目 T3AS No 287329 资助。

本文由南京大学 2021 级硕士曹智豪翻译转述。