机器学习测试：使用模拟器测试训练好的功能的见解和经验

• 测试机器学习（ML) 应用程序的思路就像是测试黑盒，就算你看过模型的内部结构，也很难理解和解释训练出来的模型功能所做出的决策。

• 训练和测试数据集的分布定义了模型的功能；你可以对数据分区，以表示所有已定义的有效测试场景以及功能所定义的场景。

• 你可以使用运行设计域（ODD）来定义 ML 功能的需求。当发现程序行为与你的期望不符时，你必须弄清楚自己是在 ODD 之内还是之外。

• 例如，模拟器通过识别和分离训练数据中一幅图像中的对象来支持注释能力。模拟器是一种工具驱动的辅助工具，用于测试那些我们无法生成“真实世界”数据的场景，并且可以通过控制环境（交通、天气、基础设施等）变量来加快测试执行速度。

• 在使用 ML 应用程序时，丛传统代码测试中获得的知识和经验非常有价值。在测试这些应用程序时，了解黑盒测试技术和相关的领域知识是非常有用的。

当新技术出现时，我们必须搞明白该怎样测试这些新东西。我对训练好的模型和机器学习功能的验证和认证过程做了很多研究，并将研究成果应用到了测试环节，从而在机器学习应用程序测试方面获得了很多见解和经验，并将在本文中分享它们。

对于机器学习应用程序来说，代码本身没什么意思。机器学习应用程序不是由复杂且庞大的代码库所构建的功能或函数，而是由几行代码组成，通过权重数据点组成的复杂网络来实现的应用。训练中使用的数据定义了最终的应用功能，也是你发现问题和错误的去处。数据是所有训练好的模型功能的关键所在。

在测试机器学习系统时，我们必须换一种方式来应用现有的测试流程和方法。测试应该是独立的，并且对任何代码或功能都采用全新的方法。我们还需要创建独立的测试集，而不是依赖训练过程中的验证部分来对付过去。

我们必须解决版本处理的问题。机器学习中有着名为 CACE（Change Anything，Change Everything）的概念和原理。机器学习程序的功能被认为是不透明的，因此在某种程度上，它是一个黑匣子。

这就意味着测试过程至少是非常耗时的，并且我们很难准确理解程序的结果是如何出来的。它可以追溯到训练数据和训练时使用的权重的分布，以及网络的类型上。从测试人员的角度来看，最好将这种功能视为超级黑匣子。这也意味着，如果我们出于某种原因决定重新训练，那么将新模型视为 2.0 而不是 1.2 版本是更合理的。

在测试机器学习 (ML) 时，模型的功能并不是那么有趣。代码变得有点无关紧要。对于老派测试人员来说，代码和函数就是“路子”。而对于机器学习来说，你验证或测试的功能很大程度上是基于训练数据的。当我们将焦点从代码转移到训练数据时，单元测试或“接近代码”的方法最后会变成测试那些用来训练功能的数据，而不是测试单个代码语句或函数。

继续往上走过各个传统的测试级别时，模拟器等工具可以帮助我们测试或验证程序功能。但是我们在这里（在模拟器中）或在生产中（你启动的系统或自动驾驶车辆之类）发现的任何问题都需要以某种结构化方式更改训练数据来解决。

在测试训练好的功能时，了解训练数据每次都是重点。对训练数据的分布和组成做检查可以代替单元测试。审查发行版（静态测试）可以被视为早期测试，就像审查需求的代码审查流程一样。尽早检查你的数据集以识别不需要的分布或偏差，这样就可以避免在后期阶段遇到功能表现不佳的问题。

在运行和测试训练好的功能时，它与“传统”代码和测试活动的另一点区别在于，每次更改或错误修复都会为你提供一个新功能。它与传统测试不同，在传统测试中，你可以把修复隔离开来并重新测试，并在附近的功能区域做一些回归。你需要将这个新功能视为该功能的全新版本，并且可能需要对它完整运行你的测试套件。当然，你可以通过巧妙的风险管理等办法来加快流程，并且在工具和模拟器的帮助下，这一流程可以更加高效。

在定义机器学习系统时，我们首先想到的一件事情就是需求。描述和指定需求的传统方法对于训练好的功能来说效果不怎么样。在我从事的项目中，我们使用操作设计域（ODD）来定义模型应有功能的上下文。

你可以将 ODD 视为定义 ML 功能需求的一种方式。以自动驾驶为例，我们可以分成几个类别：

场景

• 路口

• 农村或城市

• 公路 / 越野

动态

• 天气（雨、雾……）

• 照明（白天、夜晚......）

环境

• 交通（行人、汽车、自行车......）

• 你的汽车或者你在对应场景中开发的功能

当你发现程序行为与你的期望不符时，你必须弄清楚自己是在 ODD 之内还是之外。如果你发现该行为发生在外部，你可能需要将其视为错误或异常以做进一步调查。

训练数据的分布决定了训练好的功能的大部分性能。考虑到这一点，“错误修复”实际上指的是改变训练数据分布，而不是改变代码行。

训练和测试数据集的分布是非常重要的。程序的功能差不多就是在这里被定义的。那么，我们如何测试，并确认自己拥有所有重要的数据元素来训练具有正确性能的 ML 模型呢？

当然，我们需要考虑分布情况。这里比较困难的一个部分是背景（例如文化或国家差异）和偏见。作为独立参与者，QA 在这里就可以发挥他们的作用，提出对训练数据或其他数据集的担忧。外部视角是一件好事。对数据进行分区以确保它们能够代表所有的有效场景可能是一个好的开始。如果我们要训练一个分类器，那就需要表示所有的有效类（可能还有几个无效类）。这里我的习惯是确保所有等效分区均得到表示，要么有效要么无效。

拿一个水果分类器来说，我们必须涵盖苹果、梨、香蕉等类别。我们还需要考虑不同的水果熟度和形状。对于预训练的模型来说，独立训练集的重要性就更突出了。这里我们可以应用一个无偏见层来验证模型。做这种测试时，将任何已定义的 ODD 保留在循环中是非常重要的。ODD 将成为我们正在测试的边界，并帮助我们评判功能的正确性或识别不需要的行为。

另一个挑战是注释；如果注释都是主观的，这可能会成为一个大问题。这取决于你的模型的用途以及训练和验证数据的精确度，但准确是非常重要的，例如图像中道路的结束位置和人行道的开始位置。

假设你想使用计算机视觉模型来扫描或分类文档，那么区分瑞典字母表中的 Å 和 Ä 就会非常重要。训练模型时，我们必须在注释里写清楚 A 上方是否有一个或两个点。

我们考虑一下与自动驾驶相关的一个功能所处的交通场景。这里的图像需要注释，以便我们可以区分行人、道路、其他车辆等。

带注释的图像，其中所有对象均按颜色或对比度来分割。

从模拟器中获取的图像

来源：用于验证和认证基于机器学习的系统的数据合成

模拟器在注释方面很有帮助，无论是创建训练数据还是测试过程它都很好用。它们是一种工具驱动的辅助工具，用于生成那些我们无法生成“真实世界”数据和自动注释的场景。例如，我可能需要创造雨、雾、雪等气象来测试自动驾驶场景，模拟器可以在这些方面帮助我们。

如果需要，模拟器还可以在注释中为我们提供基本事实，以帮助加快测试速度。带注释的基本事实为我们提供了参照：图片中的哪些部分是天空，哪些是草地，图片的哪一部分是行人，等等。

大多数用于测试计算机视觉或自动驾驶的模拟器都有各种过滤器或模式。它们会自动注释你的场景，为不同组件提供基本事实或参照。使用除摄像头之外的其他传感器（例如雷达或激光雷达）来测试时，模拟器可以为你提供点云或语义信息以用作测试基础。

使用模拟器还可以帮助你更有效地寻找极端情况。例如，我们可以矢量化很多场景，然后自动搜索模型失败的场景。通过一些简单的自动化操作，我们可以为模拟器设定一个基本场景，然后对于每次测试稍微改变一下雨量或白天的光照量，以逐渐寻找各种变量条件的组合，找出导致模型做出错误预测的情况。在模拟器中，这样的流程很容易自动化；但到了真实的大街上就很难做到了。

本文提到的见解和经验来自多个研究项目。这些项目研究了如何测试机器学习程序的功能。欧盟委员会和瑞典政府为这些项目提供了资助。

与我合作的团队参加了三项主要研究，它们都与对训练好的功能的验证和认证有关系。

• FramTest 项目专注于识别当今行业面临的挑战。

• SMILE 项目重点关注定义和保护安全案例的流程和方法。

• Valu3s 项目专注于使用模拟器来测试训练好的功能。

FramTest 项目（瑞典语）研究了“当今公司如何解决机器学习问题”。我们做了一项文献研究，探索该领域的最新技术。研究发现，尽管有许多关于机器学习功能开发的论文，但很少有人考虑验证和认证过程。在研究学术论文的基础上，我们围绕该主题对瑞典的测试人员和领导者做了 12 次深度采访。

访谈结果可分为：

• 缺乏测试数据

• 无注释

• 文化问题

在 SMILE 研究项目中，我们研究了场景、架构，以及最重要的数据收集过程。我们研究了相关需求和 ODD 处理方法，将 ISO 26262 等标准与当时的新标准 ISO 21448（SOTIF）做了对比。此外，我们还评估了欧盟给出的值得信赖的人工智能技术名单，并将名单中的项目与上述标准做了对比。

我们了解到，如何收集数据以及如何设置需求都是非常重要的。如前所述，数据收集需要与 ODD 相关联。

在这个项目中，我们研究了当模型中发现极端情况或不需要的行为时，训练数据的分布和组成需要如何演变 / 改变这一主题。根据你的模型和功能的具体情况，重新训练模型的外层可能就足够了。但在大多数情况下，你需要重新训练模型来保证它能处理那些不需要的行为，这将触发更多的测试活动。

我们开展了一个为期 3.5 年的欧盟资助项目，名为 Valu3s，使用模拟器来加速 ML 功能的成熟过程。我的结论是，如果你想要进行任何类型的自动化、极端案例搜索或基于场景的测试，那么使用模拟测试环境都是非常重要的。

这里的图片是我们在自动化测试时使用的场景示例。左图描述了行人过马路的路线，右图显示了一辆连接自动驾驶模型的汽车。我们将场景矢量化为结构化文件，然后修改外部条件以找到那些导致汽车撞到行人的组合。因此，通过自动化迭代不同的参数，例如照明、降雨、一天中的时间等，我们可以发现那些不需要的行为。

Valu3s 的用例之一与交通监控有关；此外，我们还研究了车牌识别功能。为了测试这一点，我们开发了一个基于机器学习的工具来生成车牌并将其插入模拟器中的车辆上。

Valu3s 中的车牌测试示例
来源：基于机器学习的车牌检测算法的验证和认证

这些工具从一个文件中获取常用字符串，并将其转换为插入到已定义汽车的已定义场景中的图像。模拟器允许我们控制和更改感兴趣的环境参数，而车牌工具使我们能够尝试任何感兴趣的车牌组合。它在测试其他国家的车牌时也很有帮助。

作为测试人员，我们拥有一项技能，那就是对好结果和坏结果的判断能力，这项技能依旧非常有用。我们的方法可能会改变，但独立的眼光最后还是会有价值。如果现在定义程序功能的不是代码而是数据，那么我们作为软件测试人员的焦点必须以新的方式向左移动，并且我们的思维方式可能需要稍微改变。

修复错误或不需要的程序行为将带来对应功能的新版本，不是版本 1.2，而是新的功能。我意识到，想要修复错误，你需要更改训练模型所用的数据集，而不是编辑代码行。

我们可以通过稍微调整传统的软件测试方法来自动化机器学习功能的测试过程。这样测试 ML 功能的流程就可以简化了。

Martin Karsberg 担任软件测试员已有二十多年了。他在国防、电信和汽车等多个行业领域拥有丰富的经验。在过去的五年中，他将不同客户的合同工作与专注于软件测试的研究和讲座结合起来作出了很多成果。

原文链接：

Testing Machine Learning: Insight and Experience from Using Simulators to Test Trained Functionality （https://www.infoq.com/articles/testing-machine-learning-simulators/）

声明：本文为 InfoQ 翻译，未经许可禁止转载。