原创 需求验证测试中的100%置信度

保证测试有效性的方法

除了提供嵌入式领域最好的测试工具之一外，我们还为汽车行业的客户测试软件产品(包括驾驶辅助功能、驱动组件、充电和电池系统的控制软件)。

随着时间的推移，我们也遇到了测试过程中的错误。为了避免过程错误，我们制定了各种策略和方法。始终以快速为客户的开发模型提供高质量的报告为目标。

下面，我们将详细解释其中一种方法。它是由我们的测试工程师开发的，并在日常实践中使用。

此方法的目的是确保测试用例在任何时候都实际测试链接到它的需求。

这里有一个简单的例子来说明为什么这件事如此重要。

在用于控制车辆外灯的软件中，当灯开关处于on位置时，外灯应始终打开。在最坏的情况下，这个需求只与从未包含条件“灯开关处于ON位置”的测试用例相关联。如果这些测试用例成功地测试了另一个方面(例如，灯开关关闭，外部灯保持关闭)，那么可以认为链接的需求已经被充分测试了。

错误的链接会以不同的方式出现:

测试人员在测试用例和需求之间创建了一个错误的链接。

随着时间的推移，由于测试项的更改，现有链接将失去其意义

有一个简单且可快速实现的解决方案可以解决这个问题。

在我们的方法中，如果每个测试用例没有正确地测试链接的需求，那么它将被报告为“失败”。由于错误链接导致的失败在报告中有详细说明。我们的方法本质上是基于分别定义测试数据和期望值的可能性。

在TPT中，测试项的预期结果(在这里我们也说测试预言)可以在Assesslet的帮助下描述。Assesslets可以同时用于几个测试用例的评估。

该方法的实现分为5个步骤:

将需求导入TPT

根据单个需求创建1个Assesslet

创建检查脚本

创建测试用例

测试用例与导入需求的链接

步骤1:将需求导入到TPT

导入可以通过几种方式完成。对于这种方法，只有需求在TPT中可用才是有意义的。

步骤2:为每个需求创建一个Assesslet

一个Assesslet的目的是在定义的条件下指定测试对象的预期行为。这个单一数据源的定义可以用于多个测试用例。

如何做到这一点?

在Assesslet文件夹中为每个需求创建一个新的脚本Assesslet，相应地命名并实现它。

一个Assesslet的实现包含以下元素:

定义条件或情况区别(通常来自需求)

定义每个条件的期望值(有些简单，有些复杂)

添加一个注释，说明哪个期望值涵盖了哪个需求

对于上面的灯控制示例，这里是一个评估Assesslet的参考实现，它使用ID 2018检查需求“如果灯开关是打开的，那么大灯应该立即打开”:

Assesslet检查需求2018：条件“当灯开关位于位置1(3号线)”。我们的期望值记录在第4行:TPT.CheckAlways()检查大灯是否== true。使用REQUIREMENTS.checked()，附加到需求2018的属性将被结果覆盖(从第4行开始)。

其他请求的过程是相同的。

步骤3:创建检查脚本

然后使用另一个Assesslet脚本检查链接到测试用例的所有需求是否具有定义好的属性。对于Assesslet，这是在第5行中使用REQUIREMENTS.checked()函数完成的。当调用这个函数时，默认值将被更改。

换句话说，对于每个测试用例，对于链接到该测试用例的每个需求，我们检查默认值的属性。如果存在默认值，则要么没有测试Assesslet，要么是需求的测试Assesslet不正确。

下面是一个参考实现:

您需要将该脚本移动到报告部分。然后它将在Assesslet之后运行以检查需求。

步骤4:创建测试用例

点击链接查看如何创建一个测试用例：

TPT | Test modeling and design - Automatic test generation (TASMO) (piketec.com)

【北汇信息】TPT | 测试环境搭建及用例编辑_哔哩哔哩_bilibili

【北汇信息】TPT | 状态机测试用例的搭建_哔哩哔哩_bilibili

步骤5:将测试用例与导入的需求链接起来

需求与测试之间的链接或者测试与需求的链接，都可以通过拖拽来完成。选择一些测试用例并将它们拖到需求上即可。

优点是什么?

这个过程的优点是报告中不正确的链接可以立即和容易地看到。在报告中，每个错误链接的测试用例都被标识为失败的测试用例。

因此，该报告为用户提供了一个关于是否为所有需求创建了相关测试用例的快速概述。与此同时，这提高了生产率，因为可以省略对完成度的分析。

在应用这种方法时必须考虑什么?

应该检查Assesslet的正确性和与需求的一致性。只有当Assesslet是正确的，它们才有意义。这是测试过程中的实际工程工作。我们(目前)还不能从你们手中接过这个任务。

进一步的提示和建议:

在我们的一些项目中，我们没有将脚本Assesslet直接链接到需求。然而，映射是通过命名约定完成的:每个“需求-测试”脚本Assesslet都有以下结构“Ass_”& 。双向可追溯性的要求(例如来自ASPICE)在原则上得到了满足，因为配对可以在任何时候确定。

总结

我们确保测试重要性的方法符合ASPICE和ISO26262的要求。

在它的应用中，它需要使用测试自动化的基本功能，例如用于刺激的测试数据的分离和测试对象预期行为的单独定义。几年来，我们一直在安全关键型汽车项目中成功地使用这种方法。

我们的工程师被直观的程序所说服，不再想没有它，因为费时的手工检查链接正确性的工作可以省略。

编写脚本和检查Assesslets及需求的正确性的工作是可管理的，并且显著低于诸如审查和演练之类的替代指标。

更多相关信息，欢迎与我们联系获取~