标签: 测试评估

【引言】 自动驾驶功能的开发和评估在汽车行业内已经很常见了。尤其是自动泊车功能，其低速和小范围操作使得更容易用自动方式实现。但是，想要让使用者满意，这些功能必须能够顺畅地执行，至少要与人类驾驶员一样快。本文将介绍德国MdynamiX及其合作伙伴联合实现的适用于实验室开发的实车在环（ViL）方法，以支持自动驾驶功能一致性开发和评估。 【ViL方法的应用】 无论是部分自动化，还是全自动化，泊车功能自动化水平不断增加。尽管泊车时车速不高，但是测试自动泊车功能复杂且高成本，因为泊车场景种类众多。为了确保所有交通参与者的安全，不同车辆、不同环境、不同情况下的泊车，比如倒车入库、侧方停车，带来了诸多挑战。如果想要测试所有这些场景，测试将很复杂。比如儿童出现在视野盲区的测试场景，很难正常进行实际测试。 出于这些原因，有必要通过虚拟场景找到合适的解决方案，在所有开发阶段，以合理的经济成本，验证和评估相关功能。 实车在环（ViL）方法提供了可行的方案。ViL方法结合了实车测试和计算机仿真的优势。真实车辆的运动（被测车辆），包括所有子组件，被传输到仿真中，使得在虚拟世界中的被测车辆的驾驶能够模拟真实物理世界的驾驶，而不需要参数化复杂的车辆模型。仿真的虚拟环境将注入被测车辆的真实传感器，使得被测车辆能够感知并响应虚拟环境。从而全面测试自动泊车控制功能与车辆执行器之间的交互。由于ViL使用虚拟环境，设计场景具有很高的灵活性，利于关键安全场景的设计。 图1 使用ViL方法测试安全相关测试的场景展示 图2 本文ViL系统测试自动泊车功能的硬件配置 【MXeval——KPI评估】 为了全面比较手动和自动停车操作（部分自动或全自动），需要一种标准化的评估方法——阶段模型方法，将停车操作划分为独立部分。除了阶段模型之外，需要客观的关键性能指标（KPI）进行评估。MdynamiX的MXeval分析软件正是满足这样的要求，不仅能够用于车辆动力学和自动横向和纵向引导驾驶功能的评估，而且包含用于自动停车的测试库。可以确定具体的评价标准和要追求的目标值，并将其纳入评价程序。对测量数据的评估以全自动模式高效地进行，根据需求，可以在实车环境中或远程连接进行。除了评估图表之外，KPI也是一览无余。所有评估结果最终都会保存在报告中。整体的评估过程如下图所示。 图3 MXeval软件评估流程 【结果】 本测试中，被测车辆在真实和虚拟环境中都进行操作。在图4和图5中，展示了八组测量值的比较，每组测量值都是针对实际的停车位，及其对应的虚拟车位，进行侧方停车得到的。图4显示，各测量结果表现出一致的趋势。进一步比较可以看到，测量结果非常相似，尤其是在初始运动时刻，只有细微的差异。例如瞬时车速KPI，在实车和仿真中几乎相同。 此外，图4显示了初始运动后续时刻的速度曲线相似。初始运动的最大速度和瞬时速度都比较相近。真实环境中的平均速度为3.43公里/小时，虚拟环境中为3.49公里/小时。 图4 八组侧方停车车速对比 值得注意的是，在真实和虚拟环境，比较整个操纵过程中的方向盘转角输入，发现四组测量值，在初始移动（时间点0到16s）中几乎相同，如图5所示。然而在16s之后，方向盘转角输入出现显著差异。这些差异可归因于实车手动转方向盘没有转向机器人——手动转方向盘的基准差异很大是很常见的。特别是对于停车辅助系统，即使是同一车辆，起始位置起着决定性作用，导致不同停车策略和轨迹。此时，使用转向机器人可能是有利的。 图5 八组侧方停车方向盘转角输入对比 有多种KPI用于评估停车辅助系统。其中一些是决定性的，尤其是对于初始运动。表1展示了部分KPI。同样，实车和仿真两种环境的KPI非常相似是显而易见的。 表1 停车辅助系统部分KPI 总体而言，ViL方法，不仅是由于法规要求，出于验证目的仿真愈发重要，而且也为传统的实车测试提供了有效的补充和/或替代方案。 【总结与展望】 本文中MdynamiX及其合作伙伴共同呈现的这一测试方案，可作为大多数自动驾驶功能的基础，能够在所有开发阶段，评估功能开发的成熟度，验证功能目标的实现。它能够有效地比较不同实车和仿真的结果，并验证仿真质量。此方案使得真实和仿真车辆行为高度一致变为可能。 此外，ViL方法也适用于其他基于传感器的高级驾驶辅助系统。尤其是在安全相关测试中，例如NCAP测试，ViL方法显示出巨大的降本潜力。随着要求变得更加复杂，将出现新的、高风险操作，ViL方法的好处可能更加深远。 注：本文翻译摘自Consistent Evaluation of Automated Driving Function Based on Vehicle-in-the-Loop，ATZ Worldwide 01/2024

A ssesslet s 是一种测试文档 的新 方法，它定义了在单 一 位置 进行 测试的预期结果，允许它们在多个测试用例中被重用。这节省了大量的时间和精力，并提高了准确性。然而，创建 A ssesslet s 可能非常耗时，并且它们可能不适合每个测试场景。团队应该根据具体情况评估其潜在的好处和缺点。 Assesslets 还可以作为测试数据生成的推动者，允许自动生成测试数据和高效有效的测试。总的来说，与传统的预期结果文档方法相比， Assesslets 提供了显著的优势，并且可以提高复杂汽车系统的可靠性和安全性。 简介 随着汽车行业的不断发展，对更高效的测试方法的需求也在不断增加。测试的一个最重要的方面是文档，特别是当涉及到预期结果的计算时。在传统的测试方法中，这个过程可能很耗时，而且容易出错。然而，随着 Assesslets 的引入，出现了一种测试文档 的新 方法。在本文中，我们将深入 阐 述 A ssesslet s 是什么、它的优点和缺点、如何减轻它们的缺点，并将对传统方法和预期结果文档进行比较。 什么是 Assesslets ? Assesslets 是记录测试中预期结果的一种独特方式。与传统方法不同，传统方法需要手动计算预期结果，作为比较步骤实现，并与测试用例一起记录，而 Assesslets 本身包含预期结果的定义。这意味着不必为每个单独的测试用例计算预期的结果，它 只需 被定义一次，然后 可以 在所有相关的测试用例中使用。 Assesslets 的 优势 Assesslets 最大的 优势 之一是它的效率。因为预期的结果被定义一次 即可 跨多个测试用例重用，所以没有必要为每个测试用例重新计算预期结果。这可以节省大量的时间和精力，特别是在多个测试用例需要相同预期结果的测试场景中。 Assesslets 还提高了预期结果文档的准确性。通过在单 一 位置定义预期结果，可以更容易地识别和纠正错误和不一致。另外，由于 Assesslets 可以链接到需求，因此可以快速识别需求的 变更 ，以更新相应的 Assesslets 。 Assesslets 的潜在缺点 Assesslets 的一个潜在缺点是，创建它们可能很耗时。在需求复杂而广泛的情况下，可能需要将自然语言需求形式化为形式化符号。这可能是一项重要的任务，特别是对于不熟悉 形式化 符号的 团队 。 另一个潜在的缺点是， Assesslets 可能不适合每种类型的测试场景。例如，在预期结果简单且易于计算的情况下，与传统方法相比， Assesslets 可能无法提供显著的优势。 减轻 Assesslets 的缺点 减少创建 Assesslet s 耗时的一种方法是使用一种可以将自然语言需求形式化为形式化符号的工具。 TPT 18 和 TPT 19 提供了此功能，允许将自然语言需求形式化到 TPT 中并进行自动检查。此外，一旦创建了 Assesslet s ，就可以跨多个测试用例和场景重用，从而在长期运行 中节省时间和精力。 在 Assesslets 可能不适合特定测试场景的情况下，根据具体情况评估潜在的优点和缺点是很重要的。在某些情况下，传统方法可能更合适，而在其他情况下， Assesslets 可能 会 提供显著的优势。 Assesslets 与传统方法的比较 在传统的测试方法中，预期结果是手动计算的，作为比较步骤实现，并与测试用例一起记录。这种方法可能很耗时，容易出错，并且难以维护，特别是在具有大量测试用例和预期结果的测试场景中。 Assesslets 为预期结果文档提供了更有效 、更 准确的方法。通过在单 一 位置定义预期结果并跨多个测试用例重用它， Assesslets 可以节省大量的时间和精力。 测试数据生成的 促成器 除了 针 对测试文档的 优势 之外， Assesslets 还可以作为测试用例生成的推动者。通过 Assesslets 描述被测系统，自动生成测试数据成为可能。由于预期结果已经在 Assesslets 中定义了，因此可以将生成的测试数据与预期结果进行比较，从而实现高效和有效的测试。这不仅节省了测试用例生成的时间，而且还确保了测试用例覆盖场景的全面范围，提高整体的测试覆盖率。 总结 在测试自动化领域， Assesslets 是一个强大的工具，它提供了一种简化的方法来定义和管理测试数据的期望值。与记录期望值的传统方法相比，它们提供了许多优势，包括改进测试用例 的 可维护性、减少重复工作和更容易 的 更新需求。然而，像任何工具一样，它们也有一些潜在的缺点，包括创建和维护 Assesslets 的初 期 时间投资，以及需要清晰和明确的需求来确保准确的期望值。 为了克服这些挑战，我们建议团队采用系统的方法来创建和管理 Assesslet s 。这包括定义清晰和明确的需求，为 Assesslet s 的创建和使用建立最佳实践，并定期检查和更新 Assesslet s ，以确保它们保持准确和最新。 与记录期望值的传统方法相比， Assesslets 提供了许多 优势 ，可以 导向 更高效 更 有效的测试自动化。通过将 Assesslets 与强大的测试自动化工具 ( 如 TPT) 结合使用，团队可以实现更精简 更 有效的测试自动化工作流程，从而帮助确保复杂汽车系统的安全性和可靠性。 Assesslets 还可以作为测试数据生成的推动者，允许自动生成测试数据和高效有效的测试。总的来说，与传统的预期结果文档方法相比， Assesslets 提供了显著的优势。 如果您正在寻找一种方法来改进测试自动化工作流程，并确保对汽车系统进行更准确、更有效的测试，那么我们强烈建议 您探索 Assesslets 和 TPT 的功能。有了这些强大的工具，您可以将测试自动化提升到一个新的水平，并在汽车软件开发项目中实现可靠性和安全性的新高度。

上次我们分享了单元测试用例的复用（ 单元测试用例复用到集成测试？Testlet Library来助力！-面包板社区 (eet-china.com) ） ，单元测试的用例可以复用到集成测试，那单元测试的评估是否也可以复用到集成测试？答案是可以的。 TPT中提供了多种多样的评估方式，其中的脚本评估使我们复用测试评估成为可能。脚本评估，使用的是基于Python的类Python语言，能够实现筛选评估区间，评估输出，报告定制化等功能，是一种非常灵活，使用起来十分方便的评估方式。 通过脚本评估，在某些模型测试中，我们可以将单元测试的评估，也复用到集成测试中。 应用场景一：单元测试的测试评估复用到集成测试 针对上次用例篇中的demo模型，我们可以在单元测试时就使用脚本评估来评估整个模型，这里以Cruise Control介绍使用脚本评估来评估计算模块的方法。 一般情况下，对于计算模块我们使用定值来测试评估，为了保证测试的充分性，需要若干组数据，这会导致我们需要多次重复计算过程来得到预期的输出，以完成评估。这是我们在测试计算模块时的痛点，有没有可能通过一些方法来自动化这部分重复的过程？答案是有的！通过脚本评估，我们可以将需求中的计算逻辑复现，以此来实现计算模块的自动化评估。 图 1 集成级模型 1 . 声明评估变量 在脚本评估中声明需要的评估变量，将部分中间计算量赋值给这些评估变量，以方便在后续计算中使用。 图 2 在脚本评估中声明评估变量 2. 复现计算逻辑 TPT的脚本评估中内置了很多计算函数，也支持Python基本库中的数学函数，方便我们去复现整个计算逻辑。通过模型中的计算逻辑，使用脚本复现其计算过程。这里以其中一部分逻辑举例介绍， 图 3 模型计算逻辑及TPT中复现的逻辑 3 . 评估 使用一个CruiseControl _ output的评估变量，将TPT计算出的Cruise Control单元的理论输出值赋值给CruiseControl _ output。 图 4 模型理论输出值赋值给 CruiseControl _ output 4. 对输出进行验证 在最后使用TPT .assertAlways 和TPT .hose 两个函数的组合来实现验证模型实际输出是否和理论输出值相等，这样就能检查模型实际输出和需求是否一致，并且能够评估输入的所有组合。两个函数中前者检查表达式的返回值是否为真，后者检查目标信号和参考信号的值是否一致，若一致则返回值为0。所以使用TPT. assertAlways 检查TPT. hose 的返回值等于0，即可证明模型输出值和理论输出值相等。 图 5 评估输出 5. 将单元测试的评估复用到集成测试 应用上面的方法，将Vehicle这个单元也使用脚本进行评估。这样在进行集成测试时，单元测试阶段的 eng_torque 将变成Local量。可以将Cruise Control 的脚本评估和Vehicle的脚本评估使用这样的语句进行拼接，即可将单元测试的测试评估，复用集成测试。 1）将两个单元的脚本评估复制到集成测试的工程中。 图 6 将单元测试的脚本评估赋值到集成测试的工程 2 ）将CruiseControl脚本中的评估输出eng _torque 的语句注释掉，因为此时该信号变成了Local。 图 7 注释CruiseControl中的相关语句 3 ）对于Vehicle单元，输入信号e ng_trq 变成Local量，是由Cruise Control单元计算得到的。所以在Vehicle的脚本中，将CruiseControl脚本中计算出的en g_torque 的值赋值给eng _t rq，即可将两部分脚本评估拼接，完成评估的复用。 图 8 传递参数 4 ）运行测试用例得到测试结果。从下图中可以看到用例时间为1 0 s，评估区间也是1 0 s且测试通过。 图 9 集成测试用例的测试结果 应用场景二 自定义脚本库 TPT的脚本评估不仅提供了非常多方便我们评估的内置函数，还支持自定义函数库，方便我们自已定义一些个性化的评估函数。这里以饱和模块为例，简述TPT是如何自定义函数库的。 1 . 编写自定义函数 首先在一个新建的脚本评估中编写我们要定义的函数（主要是方便控制缩进），TPT脚本评估的语法和Python大体类似。 图 10 编写好自定义函数 2 . 保存文件并修改文件格式 新建t xt 文本，将编写好的自定义函数复制到该文件中保存，将文件后缀名修改为. tptp y。 图 1 1 保存自定义函数文件 3 . 在TPT中加载函数库 1）在Preference / General /Assessment Library中添加自定义函数文件的路径。 图 1 2 在Preference / General /Assessment Library添加自定义函数路径 2 ）在工程的Assessment Library中激活函数库。这样就可以在工程中使用我们刚刚编辑好的函数库中的函数了。 图 1 3 在工程 Assessment Library 中激活函数库 3 ）在脚本评估中使用“自定义函数的文件名+. + 函数名称”的语法即可调用刚刚自定义好的函数。 图 1 4 在脚本评估中是自定义函数 4 ）使用示例。 图 1 5 使用示例及结果 总结 本文主要介绍了测试评估从单元测试复用到集成测试和自定义脚本库，这两者同样能帮助我们提升测试时的效率。通过用例复用和评估复用不难发现，TPT在做模型测试时具备巨大的优势，可以通过多种方式提高测试的速度和效率，减少重复的工作。并且TPT支持测试的多个阶段——MiL，SiL，PiL等，能够将同一工程复用到不同的测试阶段，这同样也能提高我们测试的效率！感兴趣的小伙伴快动起来吧！

哪一种测试方法能更好地检测软件修改中的bug ？ 来看看 回归测试与背靠背测试的比较 吧 定义 ISTQB将回归测试定义为对已经测试过的程序或修改后的部分功能的重新测试。其目的是证明没有由于所做的更改而引入错误状态或以前掩盖的错误状态暴露。 ISTQB将背靠背测试定义为通过对所有变量执行相同的测试用例并比较结果来比较被测系统的两个或多个变量，或者相同被测系统的仿真模型。 这两种动态测试方法之间的主要区别是测试资料库的类型。测试资料库是测试用例成功的评估基础。 在回归测试中，评估基于从需求中得到的预期结果。在背靠背测试中，预期结果是与另一个软件版本相同的行为。 在我们看来，如果想要做出或确定关于函数行为的声明，那么回归测试是合适的。如果测试与需求联系在一起，那么功能和需求中的bug就可以被清晰明确地分配和评估。 持续集成和持续测试(CI/CT)环境代表了回归测试的自动化。在大多数配置中，基于更改执行每天的测试。通过CI/CT构建计划，只执行对产品有影响的测试。 当参考内容，例如软件的原始版本高度可信时，背靠背测试是非常适合的。当从模型生成代码时，就会出现这种情况。如果模型已经经通过了广泛的测试，则给出了较高的置信度。 在实践中，特别是对于浮点运算中的转换，背靠背的测试设置可能是具有挑战性的，例如，当将模型转换为C代码时 。 乍一看，设置公差似乎很简单。 当信号级联时，错误会传播，必须重新考虑将最小有效位(LSB)设置为容差值。如果选择的公差太小，测试将出现错误并失败。如果选择的公差太大，测试总是通过，背靠背测试就失去了意义。因此，正确的设置在技术上成为一项艰巨的工程任务。 总结 在TPT中，可以同时执行回归测试和背靠背测试，并且可以在一次执行中结合这两种测试方法。 我们建议测试经理在选择测试方法并做出一个有意识的决定之前，通过进行他们自己的调查，从努力和利益的角度检查操作的适宜性。