标签: 需求覆盖度

保证 测试 有效性的方法 除了提供嵌入式领域最好的测试工具之一外，我们还 为 汽车行业的客户测试软件产品 ( 包括驾驶辅助功能、驱动组件、充电和电池系统的控制软件 ) 。 随着时间的推移，我们也 遇到 了测试过程中的错误。为了避免 过程 错误，我们制定了各种策略和方法。始终以快速为客户 的开发模型 提供高质量的 报告 为目标。 下面，我们将详细解释其中一种方法。它是由我们的测试工程师开发的，并在日常实践中使用。 此方法的目的是确保测试用例在任何时候都实际测试链接到它的需求。 这里有一个简单的例子来说明为什么这 件事 如此重要。 在用于控制车辆外灯的软件中，当灯开关处于 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 及需求 的正确性的工作是可管理的，并且显著低于诸如审查和演练之类的替代 指标。 更多相关信息，欢迎与我们联系获取~

基于需求的测试，是在汽车电控单元软件测试中的基本要求，也是ISO26262中的动态测试的强烈推荐的测试方法。 为了保证整个测试过程的正确高效，需要对测试需求和测试用例进行有效管理 ， 例如能够从需求管理工具中将需求导入，再将测试用例和需求链接起来，并且实现数据的双向同步等。 汽车行业常用需求管理工具中，主流的产品包括DOORS及Reqtify 等，对 产品 整个生命 周期进行 需求 管理 。借助需求管理工具DOORS/ Reqtify ，TPT可以实现对测试需求导入、测试用例创建、测试需求与测试用例链接 ，实现 整个测试过程追踪追溯，以满足ISO26262的要求。 德国PIKETEC公司的 TPT 软件作为汽车行业著名的针对嵌入式系统基于模型的测试工具，几乎 包含了所有常见嵌入式软件的支持平台，适用于整个电控开发测试过程， 可以实现测试用例的复用，并且实现了测试执行、测试评估和测试报告生成的整个过程自动化。针对 MATLAB/Simulink/Stateflow 、ASCET以及 TargetLink 等， TPT 提供了全方位的支持进行模型测试。北汇信息作为PKETEC公司的 合作 伙伴，将为客户提供相应的产品支持和测试服务。 TPT 对需求管理的支持 支持创建和管理需求与测试用例之间的关联 支持需求变更后的冲突分析 支持在TPT中对需求进行浏览 支持IBM Rational DOORS 、 Reqtify 支持从需求管理工具导入测试需求 支持测试用例导出到需求管理工具 支持从需求管理工具导入测试用例 支持在需求管理工具和TPT之间同步测试用例 支持 需求覆盖报告 下面 以DOORS为例，来介绍TPT 对需求管理 的支持。 从DOORS 导入 测试需求 TPT可以很好 地 实现与需求管理工具DOORS的交互。在TPT安装目录下， 带有 与 DOORS交互的接口程序，将该程序拷贝到DOORS的安装目录相对应的文件夹下，即可在DOORS的菜单栏 下 找到TPT选项。 通过 TPT 选项 ，可以实现向TPT导出测试用例、测试需求以及导入TPT创建的测试用例等。 可以在TPT里，加载DOORS导出的测试需求。 如 Fig. 1 所示。 Fig. 1 需求链接 在TPT里，将导入的测试需求与构建的测试用例进行关联（Link）。如Fig.2所示的Test Case对应Requirement里边的ID为 1/3/4三个测试需求。每一个测试需求都会在Linked Objects显示。 Fig.2 测试追踪 每一个测试测试需求下边都注明了关联的测试用例。双击该测试用例，TPT会自动跳转到该测试用例，方便测试人员进行追溯。如Fig.3所示。 Fig.3 冲突分析 如果在DOORS 对测试需求进行更新 ，在TPT 里 进行同步化之后 ，则变化的测试需求以及与 该测试需求 相关的测试用例都可 以直观 体现 ，相关的test case会有颜色变化 。 可以在Modification s 查看 更改前后的测试需求内容 。 如Fig.4所示 。 Fig.4 需求 覆盖报告 在测试完成后， 可以 查阅测试需求报告 ，报告支持 HTML 以及PDF版本 。在报告中，可以查阅每个测试需求动态 覆盖 情况以及 对应的测试用例的执行 结果 。 在 TPT里，可以通过添加脚本评估条件， 得到 测试需求的动态覆盖报告 。 如Fig. 5 所示 ， 可以 查阅 每个 测试需求的动态覆盖情况，比如 TestCase 3 里边关联 的测试用例的执行情况 。 Fig.5