所以你现在已经测试了你的软件。但是你知道你测试得有多好吗?您如何衡量测试的有效性?汽车软件不断增长的数量和复杂性给开发人员带来了越来越重的负担,不仅要验证它的功能,还要确保它满足安全和安保的要求。从表面上看,这意味着基于需求的测试。这当然很重要,但在更深层次上,您需要确保此类关键代码已经过充分测试。您是否测试过是否可能存在异常情况,再加上代码中不常用的部分中隐藏的细微错误,可能会导致一些严重的故障?您必须衡量测试的有效性。
覆盖分析可以全部或有选择地应用,以满足 ISO 26262 指南
这听起来像是给开发人员又增加了一个沉重的负担。然而,它可以通过一套测试工具(例如,需求跟踪、静态和动态测试、单元和集成测试等)进行有效且具有成本效益的管理,这些工具包括评估测试范围和性质的能力。换句话说,重要的是要了解已经测试和未测试的内容、为什么以及这些测试如何与功能、安全和安保要求相关联。总体而言,这是通过覆盖分析来实现的,但是该分析具有不同的技术,更具体地说,具有不同的级别,可以应用于整个应用程序,或者更有选择性地应用于那些故障可能危及系统功能或导致受伤或死亡。
对于机动车辆,我们有用于汽车软件开发的 ISO 26262 标准指南,包括从 A 到 D 分类为汽车安全完整性等级 (ASIL) 的安全指南,其中 D 是最关键的。毫不奇怪,安全指南要求对制动系统进行比娱乐系统更深入的测试。使用一组分析工具,我们应该能够确认我们已经测试了要部署在车辆中的软件,以确保安全和安保的适当水平。
集成工具支持多个测试层
软件质量分析通常从检查源代码的静态分析开始。虽然它本身不执行覆盖分析,但静态分析可以分析代码的质量和结构,并在需要时检查是否符合编码标准。从根本上说,通过静态分析获得的代码知识和理解可以自动化并加速测试工具生成以及测试用例开发的输入生成。
动态分析与静态分析的不同之处在于,被测代码是经过编译、链接和执行的。系统测试和单元测试都是动态分析的例子,一般是结合使用。顾名思义,系统测试将系统作为一个整体进行练习,以表明功能、安全和安保要求得到了适当的解决。单元测试允许更早地验证功能,提供一种执行防御性代码的方法,并且可以通过组合有效和无效输入、范围测试和边界条件来测试稳健性,从而增加更多价值。
工具套件中的覆盖数据是通过轻量级代码检测生成的。该工具允许工具跟踪哪些代码已被执行,并生成有关使用的测试用例实现的覆盖范围和细节的信息。根据由 ASIL 驱动的所需覆盖分析的级别和深度,该工具套件报告语句、分支和修改的条件/决策覆盖等级别的覆盖率。有关所需内容的列表,请参见 ISO 26262 标准中的表 12 和 15。
Modified Condition/Decision Coverage (MC/DC) 是一种深入的覆盖分析技术,但并不总是很好理解。显然,通过在每个分支上执行所有可能的条件(分支条件组合覆盖,或 BCCC),可以实现非常完整的代码覆盖。但是,当一个分支依赖于四个或更多条件时,这会导致不切实际的测试数量。对于这些分支,MC/DC 将所需的测试数量减少到 N+1 条路径,而不是 BCCC 所暗示的 N2 条路径。MC/DC确保每个入口和出口点都参与;每一个决定都有每一个可能的结果;一个决策中的每个条件都包含每个可能的结果,并且一个决策中的每个条件都被证明独立地影响决策的结果。结果,以及需要额外注意的任何差距,
一个完整的工具套件还可以提供数据形式的分析和控制耦合覆盖。ISO 26262 要求存在“软件组件之间的受限耦合”,并且它是该原则的合理扩展,以确保已执行每个功能调用并且已执行对数据的每次访问。数据耦合分析通过源代码跟踪变量,并准确报告哪些值已用于发现可能的异常使用。
【图1 | LDRA 的 TBvision 工具显示了已分析的代码部分以及应用的不同测试级别的覆盖结果。]
在汽车行业,使用具有该架构图形表示的工具(即基于模型的开发)生成软件架构设计也越来越流行。其中包括 IBM Rational Rhapsody、Mathworks Simulink、ANSYS SCADE 等工具。一个软件测试和分析工具套件可以测试从这些工具自动生成的代码,然后将测试和覆盖结果映射回这个图形表示,这将有助于完成循环,以确保开发人员验证工作的有效性。
所以答案是:是的,要确保汽车应用程序的安全性,仅仅测试您的代码是不够的。您还必须衡量测试过程的完整性。但是使用集成的自动化工具套件,该过程是全面的、直接的和无痛的。
审核编辑:郭婷
全部0条评论
快来发表一下你的评论吧 !