标签: 需求测试

保证 测试 有效性的方法 除了提供嵌入式领域最好的测试工具之一外，我们还 为 汽车行业的客户测试软件产品 ( 包括驾驶辅助功能、驱动组件、充电和电池系统的控制软件 ) 。 随着时间的推移，我们也 遇到 了测试过程中的错误。为了避免 过程 错误，我们制定了各种策略和方法。始终以快速为客户 的开发模型 提供高质量的 报告 为目标。 下面，我们将详细解释其中一种方法。它是由我们的测试工程师开发的，并在日常实践中使用。 此方法的目的是确保测试用例在任何时候都实际测试链接到它的需求。 这里有一个简单的例子来说明为什么这 件事 如此重要。 在用于控制车辆外灯的软件中，当灯开关处于 on 位置时，外灯应始终打开。在最坏的情况下，这个需求只与从未包含条件 “ 灯开关处于 ON 位置 ” 的测试用例相关联。如果这些测试用例成功地测试了另一个方面 ( 例如，灯开关关闭， 外部灯保持 关闭 ) ，那么可以认为链接的需求已经被充分测试了。 错误的链接会以不同的方式出现 : 测试人员在测试用例和需求之间创建了一个错误的链接。 随着时间的推移，由于测试项的更改，现有链接将失去其 意义 有一个简单且可快速实现的解决方案可以解决这个问题。 在我们的方法中，如果每个测试用例没有正确地测试链接的需求，那么它将被报告为 “ 失败 ” 。由于错误链接导致的失败在报告中有详细说明。我们的方法本质上是基于分别定义测试数据和期望值的可能性。 在 TPT 中，测试项的预期结果 ( 在这里我们也说测试预言 ) 可以在 A ssesslet 的帮助下描述。 Assess lets 可以同时用于几个测试用例的评估。 该方法的实现分为 5 个步骤 : 将需求导入 TPT 根据 单个 需求创建 1 个 Assesslet 创建检查脚本 创建 测试用例 测试用例与导入需求的链接 步骤 1: 将需求导入到 TPT 导入 可以通过几种方式完成。对于这种方法，只有需求在 TPT 中可用才是 有意义的 。 步骤 2: 为每个需求创建一个 Assesslet 一个 Assesslet 的目的是在定义的条件下指定测试对象的预期行为。这个单一 数据源的 定义可以用于多个测试用例。 如何做到这一点 ? 在 Assesslet 文件夹中为每个需求创建一个新的脚本 Assesslet ，相应地命名并实现它。 一个 Assesslet 的实现包含以下元素 : 定义条件或情况区别 ( 通常来自需求 ) 定义每个条件的期望值 ( 有些简单，有些复杂 ) 添加一个注释，说明哪个期望值涵盖了哪个需求 对于上面的 灯控制 示例，这里是一个评估 Assess let 的参考实现，它使用 ID 2018 检查需求 “ 如果灯开关是打开的，那么大灯应该立即打开 ”: Assesslet 检查需求 2 018 ： 条件 “ 当灯开关位于位置 1(3 号线 )” 。我们的期望值记录在第 4 行 : TPT.CheckAlways () 检查大灯是否 == true 。使用 REQUIREMENTS.checked () ，附加到需求 2018 的属性将 被结果 覆盖 ( 从第 4 行开始 ) 。 其他请求的过程是相同的。 步骤 3: 创建检查脚本 然后使用另一个 Assesslet 脚本检查链接到测试用例的所有需求是否具有定义好的属性。对于 Assesslet ，这是在第 5 行中使用 REQUIREMENTS.checked () 函数完成的。当调用这个函数时，默认值将被更改。 换句话说，对于每个测试用例，对于链接到该测试用例的每个需求，我们检查默认值 的属性 。如果存在默认值，则要么没有测试 Assess let ，要么是需求的测试 A ssess let 不正确。 下面是一个参考实现 : 您需要将该脚本移动到 报告 部分。然后它将在 A ssesslet 之后运行以检查需求。 步骤 4: 创建测试用例 点击链接 查看如何创建一个测试用例 ： TPT | Test modeling and design - Automatic test generation (TASMO) (piketec.com) 【北汇信息】TPT | 测试环境搭建及用例编辑_哔哩哔哩_bilibili 【北汇信息】TPT | 状态机测试用例的搭建_哔哩哔哩_bilibili 步骤 5: 将测试用例与导入的需求链接起来 需求与测试之间的链接或者 测试与需求的链接 ，都可以通过拖拽来完成。选择一些测试用例并将它们拖到需求上 即可 。 优点是什么 ? 这个过程的优点是报告中不正确的链接可以立即和容易地看到。在报告中，每个错误链接的测试用例都被标识为失败的测试用例。 因此，该报告为用户提供了一个关于是否为所有需求创建了相关测试用例的快速概述。与此同时，这提高了生产率，因为可以省略对完成度的分析。 在应用这种方法时必须考虑什么 ? 应该检查 Assesslet 的正确性和与需求的一致性。只有当 A ssesslet 是正确的，它们才有意义。这是 测试过程中的 实际工程工作。我们 ( 目前 ) 还不能从你们手中接过这个任务。 进一步的提示和建议 : 在我们的一些项目中，我们没有将脚本 A ssesslet 直接链接到需求。然而，映射是通过命名约定完成的 : 每个 “ 需求 - 测试 ” 脚本 Assesslet 都有以下结构 “Ass_”& 。双向可追溯性的要求 ( 例如来自 A SPICE) 在原则上得到了满足，因为配对可以在任何时候确定。 总结 我们确保测试重要性的方法符合 A SPICE 和 ISO26262 的要求。 在它的应用中，它需要使用测试自动化的基本功能，例如用于刺激的测试数据的分离和测试对象预期行为的单独定义。几年来，我们一直在安全关键型汽车项目中成功地使用这种方法。 我们的工程师被直观的程序所说服，不再想没有它，因为费时的手工检查链接正确性 的工作 可以省略。 编写脚本和检查 Assesslets 及需求 的正确性的工作是可管理的，并且显著低于诸如审查和演练之类的替代 指标。 更多相关信息，欢迎与我们联系获取~