大家好，我是讯享网，很高兴认识大家。



讯享网

提示：“汽车嵌入式软件功能测试的系统方法”为系列文章，本篇章为系列“二”，在系列“一”中已经介绍了保证完整性的所有测试级别及提出的方法，接下来，在本篇章中我们将解析汽车行业软件测试的结构和规划。

“汽车嵌入式软件功能测试的系统方法”系列“一”、“二”已同期发布，可依次阅读，系列“三”将后续发布。

05.汽车行业软件测试的结构和规划

由于电子系统日益复杂，这项工作的第一个建议是提出一种方法，基于V模型方法构建功能、组件和系统的接口，促进活动和职责的定义。

车辆的一般电气系统可以定义为一组系统，其中每个系统负责对与其主题相关的一组功能进行分组，该组功能具有多个负责执行功能的组件，如图6所示。

图6.系统、组件、功能及其集成的整体愿景

分析该系列“一”中图3的V模型，所有测试级别都与项目规范步骤直接相关。在此基础上，定义了一种测试执行策略，可以识别冗余和差距。考虑到测试计划直接影响项目成本，测试策略必须从项目开始就自信和客观。四个层次是应用该方法来组织和构建汽车系统复杂性的基础：

1）功能描述；

2）系统规范；

3）系统、组件和功能映射；

4）定义影响汽车行业软件测试的应用基本因素，如图7所示。

图7.系统、组件、功能及其集成的整体愿景

它们将在下一小节中描述。然后综合了定义每个功能测试级别的策略（第5.E节）。第5.F节显示测试活动的结构化可以实现对测试活动的跟踪、管理和控制。

从OEM的角度来看，所提出的方法使用来自车辆电气/电子系统的最少可用信息来定义测试软件的策略。这是一种理想的方法，允许在很早的时候测试项目范围，控制整个项目测试计划，涵盖车辆的所有功能、系统和ECU。下面将更详细地描述功能层。

A. 功能描述

车辆具有多种功能，这些功能以车辆功能用户易于理解的方式编写，尤其是在项目的初始阶段。在这种情况下，目标用户可以是乘客、司机、操作员、维修人员或生产车间等。

在项目的初始阶段，功能的描述独立于硬件或软件。在工业中，这是用自然语言记录的，非专业人士也可以理解。它的描述没有考虑如何实现该功能以及它在车辆内的相互依赖性。表1显示了用于指定功能的建议模型。车辆的所有功能都应获得标识(Fn)、名称和基本描述。

表1.车辆功能规格示例

B.系统规范

车辆包含多个系统，每个系统都捆绑一组功能。不同公司对系统的定义不同，通常是一个与一组功能相关的名称。这里，建议使用一个基本模型来描述系统，根据表2，其中包含基本信息，每个系统都会收到一个标识、一个名称、系统与特定功能关系的简短描述，最后两列是系统所代表的功能的名称。

每个功能都有一个系统作为所有者，即使其他系统也可以参与该功能，例如，燃油液位有动力系统(S3)的贡献，以测量和检查燃油液位失效。

表2.系统规格

C.系统、组件和功能映射

在这种情况下，映射使用架构的电子系统概念，它定义了组件和系统的组织方式。这包括在系统架构内映射功能、在其系统内呈现每个组件以及显示组件之间每个功能的相关性。映射重点关注车辆电气系统、功能、系统、组件和功能贡献等重要数据的交互。该方法中最低级别的信息是功能贡献的规范，它表示组件负责的功能部分。

在此步骤中，功能在每个组件和系统内进行映射，由连接参与执行功能的每个组件的线表示。在图8所示的示例中，我们使用了文献中报告的相同功能。功能架构包含三个系统，即驾驶舱、动力传动系和外部灯光。驾驶舱系统表示靠近驾驶员位置的一组功能，其组件包括：仪表板、点火控制器和前照灯开关。动力传动系统表示与车辆驱动力相关的功能，外部灯光系统表示与车辆外部灯光相关的所有功能。绿线连接参与外部自动灯光功能的组件，蓝线连接燃油液位显示功能。

图8.基于系统和组件贡献的功能架构示例

这是系统的一个规范步骤，其中每个组件都有其定义的功能贡献列表。在操作上，表3是定义表示此系统映射的基础。在动力传动系统的情况下，它有助于燃油液位检测功能，但负责显示燃油液位功能的系统是驾驶舱系统。

表3.功能贡献及其与系统、功能和组件级别的关系

除了表3之外，表4还提出了一个矩阵来映射整个车辆系统，结合之前定义的所有信息来指出每个功能中有多少组件和系统参与。该表中的附加点之一是功能贡献ID FnSnCn，它代表每个功能贡献的唯一代码，并成为“DNA”功能的一部分。

表4.ISO 26262测试建议

在这里，功能规范的最低级别是功能贡献和标识FnSnCn，这样该代码就可以识别负责该贡献的组件和系统。如果组件对功能有多个贡献，则Fn会获得一个点，贡献编号可以添加到点后。例如，功能F3有组件C5、C7和C9的三个贡献。此方法将功能映射到系统和组件中，其中每个贡献都有一个唯一的编号。这个编号可以轻松跟踪，从而为车辆功能可视化提供系统而完整的方式。这种映射方法可以支持任何管理活动，不仅用于测试，还用于完整的开发、生产和售后生命周期。例如，如果现场的车辆出现某些功能失效，则可以轻松跟踪规范历史、测试和报告。从左到右，我们将层视为从用户到组件的自上而下。然后，我们可以将其分类为系统、功能和组件。为了确保完整性，适合在所有级别定义测试模式。

考虑到标识具有功能的“DNA”，此方法还有助于开发一种工具来管理和组织软件开发过程。这为开发一个框架来记录每个功能、与组件和系统相连的功能以及它们的接口提供了参考。

D. 汽车特性

如该系列“一”中的第2节所述，汽车行业在产品开发过程中具有特定的特性和挑战，必须在测试策略中加以考虑。其中，可以强调应用、安全性和质量标准的特性，以及一些测试要求、客户视角的相关性、系统的复杂程度和测试执行的复杂性。

安全关键型嵌入式系统具有此处提出并可能评估的因素：安全级别、不同复杂程度、外部环境或操作员对系统功能的影响，以及在某些情况下客户的参与。如表4所示。

1) 功能安全

定义与功能安全因素有关的测试策略的主要要素是在项目生命周期开始时进行风险分析和评估，其中为每个系统确定汽车安全完整性等级(ASIL)。基于此分类（识别具有事故风险的系统），定义了避免剩余风险的需求，并推荐了测试方法来验证和确保系统批准。

软件对风险没有直接影响，但同时，在许多情况下，它可以被视为负责系统级安全，因为软件可以通过系统元素传递故障。了解应用软件功能的整个生态系统至关重要。这些信息会影响并有助于软件测试策略的定义，是定义测试计划的因素之一。

每个功能的ASIL识别都从危害分析开始，其中在功能安全重点中识别所有危害事件。文献中有几种使用ASIL概念进行风险分析的方法。根据损伤的潜在严重程度(S)对每个危害事件进行分类，根据暴露(E)（可能发生伤害的工作条件的预期相对频率）和控制©（控制器可以采取行动避免伤害的相对概率）的组合进一步对受伤风险的可能性进行分类。

使用ISO 26262推荐的ASIL方法进行风险分类用于评估车辆的每个功能。如表4所述，有五种可能的结果：QM、A、B、C和D。当级别为A、B、C或D时，系统或组件功能具有功能安全相关性。QM级别意味着与危害事件相关的风险与安全无关，不需要符合ISO 26262的安全措施。

一旦定义了功能、系统和映射的规范，就应该针对每个功能单独应用遵循ASIL方法的风险级别评估。此分类是定义测试策略的参数之一。

ISO 26262中有一些建议，根据表4定义了应从每个ASIL级别执行的测试。ASIL级别由以下公式给出：“++”表示该方法是针对所识别的ASIL强烈推荐的，“+”表示该方法是针对所识别的ASIL推荐的，并且(∗)表示网络环境可以是部分或完全与车辆系统集成的测试台。

根据ISO 26262建议，当ASIL为A、B、C或D时，必须在车辆的实际条件下测试软件。但是，在A和B情况下，如果在测试台或HiL中执行组件和系统级测试，则可以省去车辆测试。在这种情况下，目标是提供证据，证明测试可以在模拟真实车辆条件的代表性情况下进行。但是，这应该有很好的记录，因为如果发生现场事故，OEM应该准备好解释测试的细节。在我们的建议中，为了避免在如此相关的主题中出现解释错误，如果功能是ASIL、A、B、C或D，则必须进行车辆上的真实测试。对于这种方法，无论测试策略规划的初始定义是什么，重要的是该功能是否与功能安全相关。

2)客户相关性

客户必须参与软件测试策略，将共同设计方面引入所提出的方法。在实践中，应该指出的是，在过去的几十年里，软件已经成为从电信和医疗设备到汽车系统等各种领域的嵌入式系统功能和创新的一部分。许多包含嵌入式软件的产品已经在多个领域得到开发，增加了利益相关者参与产品开发（包括软件验证）的相关性。这些变化导致了这样一种情况：软件工程已成为嵌入式系统中的一个重要主题，是创新和市场竞争的重要参与者。它直接影响车辆功能的可用性。在软件测试中，必须考虑这个因素。

文献中的大多数方法在测试策略中都没有考虑客户验证。这种验证是V模型中最高级别之一，这里称为验收测试。为了规划和定义测试策略，需要评估验收测试的必要性，并提前回答一个问题：该功能在投入生产之前是否需要客户批准？

3)系统复杂性

汽车行业的嵌入式系统是组件和功能方面值得探讨的一个例子。图9显示必须开发和测试多个对象，从最低级别到最高级别：模型、软件单元、嵌入式软件、硬件和软件组件、系统以及车辆本身。测试可以在不同的级别执行，必须开发一种系统的方法来促进对测试的理解和定义。

图9.电子车辆系统结构

这项工作侧重于软件测试的最高级别，因此对象（模块、软件单元和集成软件）不属于上下文，因为在大多数情况下，这些低级测试的复杂性较低，通常由供应商自己管理，最终报告交给OEM。

在这里，复杂性分析基于每个功能具有的接口数量、有多少组件和系统参与该功能的功能，以及每个组件或系统有多少功能。必须提出一些问题来构建组件、系统和车辆层面的测试定义。

表5. 功能矩阵及其在组件和系统级别的分布示例

4)驾驶员对系统的影响

车辆中有许多功能类型，从非常简单和被动的功能到影响功能安全的主动功能。其中一些功能的行为受到驾驶员的影响。如果无法在实验室中模拟驾驶员行为的干扰，则需要进行车辆测试。

为了便于在所提出的方法中应用这一因素，包括两个问题来评估每个功能：

5)外部环境对系统的影响

新技术与外部环境有更多的互动，这会在车辆系统内产生多个变量，而且并不总是可以在实验室中进行模拟。

可以提及交通要素、不同类型的用户行为和反应，以及更具动态性的驾驶情况，主要是针对自动驾驶汽车。另一个例子与连接性或电动汽车功能有关，其中城市是车辆生态系统的一部分。例如，物联网(IoT)的结构或电池充电的系统基础设施，这需要在真实环境中与车辆一起进行验证才能获得最终产品批准，并且应在测试规划中加以考虑。

大多数新车都具有强大的网络、通信和数据处理能力，能够与其他车辆通信或通过各种协议（如Wi-Fi和蓝牙）与外部环境交换信息。因此，许多创新的远程信息处理服务（如远程安全以禁用发动机和远程诊断）已经开发出来，以提高驾驶员的安全性、效率和舒适度。这一演变的下一步是自动驾驶汽车解决方案的激增。

在这种情况下，车辆功能的接口在许多情况下超越了嵌入式系统，需要车辆在真实环境中验证软件功能，因为在实验室中进行模拟并不总是可行的。同样，对于驾驶员影响，必须回答一些问题来定义测试策略：

E.对每个功能所需测试的评估

前面几节介绍了汽车行业中影响测试计划定义的重要因素、功能和系统的规范模型以及在系统内映射功能的方式。图10总结了本系列文提出的方法结构。

图10.汽车行业多级测试计划和策略参数

本节根据前面几节的信息介绍了多级测试策略的定义。图11中描述的第一个流程图评估了因素1，即功能与功能安全的相关性。

图11.检查安全相关性的工作流程

这是汽车应用中最重要的因素之一，因为当电子系统失效导致事故时可能会产生法律和经济后果。ISO 26262对与功能安全相关的功能有具体要求，测试计划必须遵循这些建议。这里提出的方法将多级测试的策略和计划分为两部分：相关功能安全功能（ASIL A、B、C和D）的测试策略和与功能安全不相关的功能（QM）的测试策略，如表6所述。

表6.功能分类因素

1)定义安全相关功能测试策略的流程

与功能安全相关的功能应使用图12的流程图。流程图的第一步评估因素4（系统复杂性）。如果功能与同一系统的多个组件交互，则必须应用系统级。在功能与不同系统交互的情况下，功能仅在车辆测试级别完成，但可能存在组件具有系统级交互的功能。在这种情况下，系统级测试是相关的，应予以考虑，否则可以消除系统级测试。

要评估的最后一个参数是图12流程图中的因素2，即功能中的客户相关性。如果相关，应考虑验收测试以计划客户参与功能验证。

图12. 安全相关功能测试策略定义的工作流程

2)定义非安全相关功能测试策略的流程

结合第5.D节中定义的参数并使用第5.E.1节和5.E.2节中的工作流程，可产生八种可能的测试场景，如表7所示。车辆级别可能由三个不同的参数驱动：安全性、复杂性或外部和驾驶员影响。表中的问号表示如果设置了行中的一个参数，则足以定义车辆测试的需要。总之，进行测试级别定义的活动顺序为：

• 指定功能；

• 指定系统；

• 定义系统架构和车辆系统内功能的映射；

• 填写应用程序的四个参数（第5.D节）；

• 使用第1和2节中提出的流程图定义测试级别；

• 将结果填写到模板（表7）中。

表7.测试级别决策表

当表7中填写了所有功能参数和定义的测试级别场景时，可以轻松显示每个组件、系统车辆和验收级别的测试量视图，如图13所示。测试顺序从组件、系统、车辆和验收开始。目标是在项目开始时进行尽可能多的测试，以降低后期风险。所提出的方法采用分类因素（表7）定义的标准，可以在项目的开始阶段进行广泛的测试，以提高质量并满足需求和规范。以一般形式相对化每个条的级别可以承担每个测试阶段的一定风险级别。这用于项目管理，例如，在模拟技术上投入更多资金以降低风险和项目时间表。

这种方法提供了一种组织和控制活动的系统方法，即使是非专业人士也可以轻松使用。这为嵌入式系统项目带来了更大的灵活性和组织性。

图13.每个级别的功能测试量

F. 测试可追溯性

术语“可追溯性”在此专门用于管理测试活动并控制测试用例的对齐。它分为两个部分：

a) 测试活动的识别；

b) 测试用例的对齐。

1) 测试活动的识别

为了建立有效的可追溯性，重要的是映射功能，识别每个测试步骤和流程。在汽车系统的情况下，通常存在多个抽象级别的需求，组件级别仅代表其他级别的测试活动的一部分，必须定义其范围和职责。

一旦每个功能定义了批准其功能所需的测试级别，就必须定义一种方法来组织测试级别之间的职责和可追溯性，消除差距并避免测试冗余。

每个测试级别都有一个预定义的步骤序列来执行功能测试，每个级别单独定义，无需与其他级别互连或它们之间结果的可追溯性。图14展示了功能在组件和系统之间可以具有的各种交互。在这种情况下，系统S1中的两个组件C1和C2相互连接，系统S2的组件C3有另一部分对功能有贡献，S1和S2的组合完全代表功能F1。

图14.从功能上看系统和组件之间的交互示例

通过分析此示例的测试计划，尤其是因素4（复杂性），应呈现功能测试的以下阶段：

• 第一阶段：组件测试。每个组件的单独测试在组件级别验证功能的贡献，组件C1用于测试功能F1S1C1的贡献，组件C2用于测试功能F1S1C2的贡献，组件C3用于测试功能F1S1C3的贡献。

• 第二阶段：系统测试。测试功能F1S1C1和F1S1C2的组合，这些组件是同一系统S1的一部分。系统级可能存在两种情况：系统级不相互作用的功能贡献，即组件级和系统级测试场景中没有任何变化；或有相互作用的场景。例如，它可以是C1组件级的模拟信号，而系统级直接通过C2的CAN总线接收。

• 第三阶段：车辆测试，在这种情况下仅涉及S1和S2，它们具有代表F1功能的所有功能贡献的组合。

• 第四阶段：客户对功能进行验收测试。

该系列“一”中第3.C节中定义的映射提供了一种使用唯一代码来标识每个系统、组件和功能贡献的方法。同样，我们在本系列文中描述了功能的每个测试阶段的唯一标识，从而可以按级别跟踪活动。考虑到每个活动的文档和历史记录都是必要的，主要是为了构建汽车嵌入式系统软件测试活动的复杂性。

测试级别由两个字母标识：组件测试(CT)；系统测试(ST)、车辆测试(VT)和验收测试(AT)。

每个功能与测试级别的标识必须符合测试的特征，如表8和图15中所述。在组件级别，每个活动仅将字母CT添加到功能贡献代码(CTFnSnCn)。在系统测试中，此阶段的主要标识与功能测试的组件有关。此步骤的标识在代码中可能有多个组件(STFnSnCnCn)。在车辆级别，重点是哪些系统代表该功能，并且此步骤的识别可能在代码组成中具有多个系统（VTFnSnSn）。

表8.测试级别的功能识别结构

图15.各级别的功能识别说明

表9显示了代码模型以及所有测试级别中每个活动之间的互连。在组件级别，当每个组件有多个功能贡献时，使用功能贡献CTFnSnCn的第二列。第一列定义次要贡献，即主要部分CTFn.SnCn的细分。“Fn”后的索引“n”指的是子组件。

表9.每个测试活动的代码模型

2)测试用例的对齐

测试用例是一系列特定的测试步骤，用于检查系统或组件的所有方面，包括输入和输出，详细描述必须考虑的步骤和必须实现的结果。通常，每个功能测试级别都有一个特定的测试用例，与其他级别的内容没有对齐。

在汽车行业，大多数组件都是由供应商开发的。在这种情况下，OEM收到经过全面测试的组件作为黑匣子是理想的，只需进行集成即可。然而，目前，这些组件是车辆功能组合的一部分，很难隔离组件，因此集成测试必不可少。为了提高所有级别的效率和利用率，测试步骤需要提供一个模型，即在更高级别上利用某一级别的测试，避免测试重复甚至测试中的空白。

在组件测试级别，大部分工作由供应商执行，由于专注于组件行为、源代码失效以及与组件硬件的集成，测试环境的复杂性降低。将大部分测试保持在组件级别可以提前识别失效，而将组件之间接口的集成和验证测试留给系统和车辆等其他级别。另一个重要点是，如果在开发过程的后期发现错误，纠正错误的成本会急剧增加。图16显示了汽车行业测试的时间顺序，将大部分测试保持在最低级别，这在组件级别非常有益。

优化每个级别测试结果的策略之一是在测试级别之间创建测试用例链接，这里的建议是使用多级测试模型，其中最高测试级别的测试序列被定义为所有级别的通用测试核心。

图16.按时间顺序排列的车辆组件和系统的测试类型

该提案认为，一个功能的测试用例由一个通用的核心部分组成，称为测试用例核心(TCC)，它被定义为测试功能最高级别的测试脚本。对于最低级别的测试，在需要时，会添加一些适配器：输出接口测试适配器(OTA)、输入接口测试适配器(ITA)和参数测试适配器(PTA)，如图2所示。TCC与所有测试级别共享，并且高级测试路线图被重用。只有每个测试级别使用的适配器是特定的。

TCC在系统级别描述了给定功能的测试步骤。TCC是OEM定义的测试例程的基础。较低级别将通过在需要时添加OTA、ITA和PTA来重用此测试例程以定制接口和参数。ITA和OTA都必须模拟给定测试级别上不可用的组件的行为，以达到TCC所期望的功能。PTA必须映射适用于测试对象的任何测试参数。

在这里，TCC的使用仅适用于组件、系统和车辆的测试级别之间。在验收测试级别的情况下，不使用此概念，因为此测试没有可以轻松重用于其他级别的标准化序列。当需要验收测试时，它会收到特定的测试序列。

如前所述，汽车领域的大多数嵌入式系统都有供应商开发的组件，但最终责任在于OEM。最大的挑战在于将组件与通用电子车辆系统集成在一起，其中许多功能相互作用以获得车辆中的其他功能。采用这种方法，功能测试（此处的重点）在所有级别都受到控制和对齐，如图17所示。最高级别的测试序列设计成为所有其他级别的参考。这支持使较低级别的核心组件的所有序列保持一致并与OEM在最高级别定义的序列保持一致的目标。

该模型的应用提供了一种在所有级别对齐功能测试的方法。该代码添加到从另一级别重用测试用例的测试活动中，重用TCC的组件或系统在其标识代码RE的末尾接收，以标识该活动与该功能的TCC一致。组件测试活动的代码为TCFnSnCnRE，在系统的情况下为TSFnS2CnCnRE。

图17.测试用例方法可重用并适应其他测试级别

在了解了汽车行业软件测试的结构和规划之后，请持续关注后续发布的系列“三”：模型应用及结论。

END

提示：“汽车嵌入式软件功能测试的系统方法”为系列文章，本篇章为系列“三”，在系列“二”中已经对汽车行业软件测试的结构和规划进行了解析，那么，在本系列的最后一篇中我们将实践应用所提的模型。

系列“一、二”均已发布，可依次阅读：

汽车嵌入式软件功能测试的系统方法（一）：背景知识及方法论

汽车嵌入式软件功能测试的系统方法（二）:软件测试的结构和规划

06.所提模型的应用

为了验证多级测试的规划和构建方法，在逐步执行本系列文所提方法的实际功能中研究了该方法的应用。所选功能是“自动灯光控制”，它可以展示我们方法的整个示例，其中存在系统和组件的交互。可以选择任何其他功能，只要知道系统和组件交互的数量以及每个组件的贡献。然后，该序列的工作流程如下：

• 基本功能规范；

• 系统规范；

• 系统架构定义和系统内的功能映射；

• 功能参数定义（系列“一”的第3.D节）；

• 功能所需测试级别的定义；

• 具有建议可追溯性的测试序列定义。

A. 功能规范

描述必须处于高抽象级别，无需任何技术知识即可理解功能是什么。实际上，这种类型的描述由与客户直接联系的销售和营销团队执行。该模型需要有关功能ID、名称和描述的信息，如表10所示。

为防止重复切换，自动灯光控制功能具有10%的滞后。当外部照明低于60%的限值时，检测到黑暗，前照灯打开并保持，直到照明增加到70%以上（10%滞后），前照灯关闭并保持关闭状态，直到照明降低到60%的值。这包括在功能测试用例中。

表10.功能描述

B.功能描述

在此步骤中，识别参与该功能的系统，在ALC功能中，需要两个系统：

1) S1表示使功能环境的驱动器接口、点火信号以及读取灯开关的状态以检测何时选择自动灯模式的系统；2) S2识别外部光度并控制外部灯的驱动器，如表11所述。

表11.参与ALC功能的系统描述

C.系统架构和功能映射

系统规范中有两个主要点需要定义：车辆电子系统内的功能架构以及每个组件对功能的贡献。图18显示了功能的架构，表12显示了每个系统和组件的贡献细节。在此步骤中，信息仍处于抽象级别，但需要一些有关车辆系统和组件的基本信息，这通常是产品开发部门技术团队的活动。

图18.功能架构

表12.功能贡献

S1系统有两个参与功能的组件：C5点火控制组件和灯光控制旋钮的C9控制组件。S2系统有一个参与功能的组件，即负责控制外部灯光的C8组件。

在表12中，系统的每个部分都用代码标识，遵循功能的交互逻辑，系统的每个部分都会收到其参与的描述，称为功能贡献。

每个贡献的功能编码定义都是唯一的，并且可以轻松跟踪和识别，可以总结出代码具有功能贡献的“DNA”。表13显示了每个系统内功能的映射。

表13. 车辆系统中的ALC功能图

D.测试级别定义

使用表13中定义的所有参数，考虑到该功能与功能安全相关，可以执行图12中的工作流程，从而规划测试，其中评估该功能对每个测试级别的需求。如图19所示，结果流向ALC功能以红色虚线突出显示。流程图中评估的第一点是功能的复杂性，在这种情况下，复杂性很高，因为该功能由多个系统（S1和S2）执行。在第二点中，评估系统级别的贡献。对于ALC功能的情况，每个系统组件之间的组合与车辆级别的结果相同。因此，可以取消系统级评估，只在车辆级进行评估，无论如何，这都是强制性的，因为我们正在处理ASIL A分类。流程图的最后一部分评估客户测试的必要性。对于ALC功能，没有来自客户的复杂性或干扰需要验证，因此不计划验收测试。

ALC研讨会的结果定义了批准该功能所需的组件级别和车辆级别，如表14所示。

表14. ALC功能所需的测试级别

图19. ALC功能的测试级工作流程

E. 测试可追溯性

测试的可追溯性分为两个部分：

a) 测试活动的识别；

b) V模型测试级别之间的测试用例对齐。

1) AL功能测试活动的识别

在提出的方法中，每个测试活动必须根据第6.D节中执行的评估结果获得唯一标识。ALC功能需要两个测试级别：组件和车辆。

对于组件测试活动，需要考虑功能中涉及的三个组件。根据系列“二”中第5 F1节中介绍的方法，必须执行三项主要活动。组件测试级别的每项活动都会收到一个首字母为CT的代码，添加到功能贡献代码中，从而生成CTFnSnCn代码。使用表11中定义的信息，ALC功能组件的测试活动包括：

• 在C5 - CTF3S2C5组件中；

• 在C9- CTF3S1C9组件中；

• 对于C8组件，对功能的贡献不止一个，即F3.1S2C8和F3.2S2C8，在这种情况下，主要活动定义为组件CTF3S2C8的总参与。

在车辆级别，两个系统参与功能S1和S2。第6.D节定义的识别从将VT代码添加到功能和所涉及系统的编号开始，从而生成代码VTFnSnSn。使用表11中定义的信息，ALC功能组件的测试活动为VTF3S1S2。

表15显示了ALC (F3)功能的所有活动的代码。ALC功能有四个测试活动，三个在组件级别，一个在车辆级别。

表15.重新使用TCC之前ALC功能所需的测试级别

2) 对所有测试级别的测试用例进行对齐

如系列“二”中的第5.F.2节所述，最高级别的测试用例用作所有其他级别的基础。在ALC功能的情况下，最高级别的测试顺序是车辆测试。在表16中，ALC功能的一个测试用例用作此应用的车辆级别的TCC。

表16. 在车辆级别用作TCC的ALC功能的测试用例

在车辆级别，通常使用所有真实传感器和执行器进行测试。只有外部环境（在本例中为灯光）可以在测试台或真实环境应用中进行模拟。组件级测试可分为三个部分，测试的核心部分来自C8组件，其他部分称为辅助组件(AC) C9和C5。选择C8组件作为TCC的基础，添加ITA和OTA。

ITA和OTA通过为测试对象配置测试用例，将TCC接口适配到测试接口，在本例中为C8组件。在ALC功能的情况下，图20显示了组件级测试用例重用的图示，其中有ITA和OTA的描述。

图20. ALC功能测试中测试用例的重用

需要OTA来模拟C5辅助组件，通过CAN刺激CAN总线点火和C9部件信号、灯光开关信号。适配器必须遵循辅助组件规范来模拟正确的值，例如，何时在CAN总线上发送CAN消息。在定义ITA和OTA之后，可以按照表15中提出的测试用例执行组件测试，而无需修改其顺序。

此外，必须在C5和C9上执行特定测试以验证此功能的完整组件级测试。只有当所有组件在组件级别获得批准后，才应执行车辆测试，以避免在更高的测试级别识别基本组件失效。在此应用中，目标是展示可追溯性的方法，而不是定义和讨论测试用例的内容。

表17列出了所有ALC测试活动的最终代码，考虑到C8组件中测试用例的重用，即仅在C8组件测试中添加了字母RE，表示此测试用例与TCC对齐。

应用文献中关于可追溯性结构的建议，在代码CTF3S2C8RE中解释了测试用例重用的标识，定义了与更高级别的测试的对齐，并建立了级别之间测试的程序模式和系统连接，如系列“二”的第5.F.2节所定义。

表17.考虑重用TCC的ALC功能所需的测试级别

F.方法应用分析

在ALC功能的情况下应用所提出的方法允许规范相当快地启动测试的规划和结构化活动，而无需技术深化。所有阶段都可以在没有每个组件级别的详细规范的情况下进行，这清楚地显示了如何描述系统和组件的交互，可以部署在任何其他车辆功能中，采用模块化和可移植性的概念，考虑到任何功能都有两个交互级别，具有系统和组件级别的明确定义的接口，无论其复杂性如何。

用于识别功能每个部分的方法以系统的方式构建，以映射嵌入式系统中的功能，从而促进车辆系统所有部分的可视化。

汽车因素在每个功能的测试级别的定义中添加了一个限定符，包括定义测试策略的程序化、结构化和推理形式。这有助于丢弃ALC功能中多余的系统级测试。

ALC功能中应用的可追溯性改变了结构化和映射组件与系统之间互连的复杂性，提供了控制、管理、测试执行和结果记录。在第一步中，ALC功能被划分为功能的三个主要贡献，其中每个部分都有一个唯一的代码：F3S1C5；F3S1C9；F3S1C8。代码的组成决定了角色贡献属于哪个功能、组件和系统。在第二步中，使用参考文献中的方法重用测试用例，以及对此处提出的活动进行编码的方法，对测试活动进行了系统性的协调。

07.最后的考虑

这项工作提出了一种构建和规划汽车嵌入式软件测试的方法。我们定义了测试和设计系统方法的相关因素。该方法旨在为整车的开发定义功能测试计划，并协调测试活动。我们根据汽车领域的特点提出了该方法。然而，它可以扩展到其他应用程序，遵循相同的理由，详细说明每个应用程序和环境要求。在建议的方法中，应强调两个要点：

1）测试的结构和规划；

2）测试的可追溯性。

A. 软件测试的结构和规划

我们开发了一种识别车辆系统和组件的所有电气和电子功能接口的方法。从高级功能开始，该方法允许映射和构建所有车辆功能。每个功能都分为其贡献，为功能的每个部分创建标识。它为每个组件分配了适当的角色，显示了组件和系统之间的相关性。所提出的结构组织了嵌入式系统，便于可视化和理解系统，即使系统很复杂，组件和系统之间有许多交互。

这项工作的贡献之一是确定影响决策的因素，以确定验证每个车辆功能所需的测试级别。这些因素的识别允许创建正式策略来定义所有测试级别。此程序提高了产品开发的效率，同时评估所有测试级别，消除了差距和冗余，允许确定每个功能的确切测试计划，并为每个车辆功能定制应用程序。

其中一个亮点是功能安全，这是汽车行业的ISO 26262所标准化的，它插入了对每个功能事故风险等级的结构化定义，并应用适当的测试级别来减轻或识别每个软件功能可能出现的失效。

这种方法提供了一种结构化的先进方法，可以识别系统的每个部分，将复杂的系统转变为完全识别和组织的系统。按系统和组件映射功能为规划测试策略和系统地定义每个功能所需的级别奠定了基础。

该框架有助于记录ISO 26262所要求的开发活动，展示产品开发中应用的所有测试步骤的稳健性和透明度。

提出的确定每个功能所需测试级别的方法包括一种程序化、结构化和合理的形式来定义测试策略，有助于识别测试规划中的重复和差距。

在这个方法的测试级别中，验收测试被系统地纳入其中，从而创建了一个程序，用于在适当的时候讨论客户参与软件功能的测试。

这里提出的所有规划和结构都可以在项目开始时定义。它只需要最少的信息，而不需要对组件进行详细的规范。这样就可以进行早期规划并量化测试成本。这样，项目批准决策过程就会变得更加稳健和自信。

由于测试每个项目所需的成本和时间更加精确，因此当软件测试所需的成本和时间是开发过程中的关键因素时，这有助于决策。

B. 可追溯性

在讨论软件开发时，可追溯性是一个复杂的话题。在这里，我们将讨论带到了更实际的层面。我们逐步组织了系统视图。我们提供了一个系统的过程来唯一地识别每个系统、组件和功能。这有助于分配每个功能角色的任务。嵌入式系统的所有高级对象都已收到结构化代码，该代码成为系统每个部分的DNA，使复杂的嵌入式系统可追溯。

提出了两个主要贡献：一种识别所有功能的方法，即系统和组件的功能贡献；一种链接组件、系统、车辆和验收测试级别的测试用例的方法。在这两种情况下，该提案都定义了一个独特的代码模型，其结构中包含嵌入式复杂系统的配置标识。此外，所提出的编码方法为识别可以轻松跟踪的软件测试活动的文档和注册奠定了基础，可用于未来的项目或现场失效排除。

08.结论和进一步工作

汽车领域已经相当复杂，但挑战应该会增加，重点是自动驾驶汽车、日益电气化的汽车以及物联网等连接解决方案的集成等创新。在这种情况下，车辆系统中的“激活成功教程者/黑客”等外部行为可能对未来系统构成挑战，并可能影响软件测试的规划，有必要研究并将这一脆弱性因素纳入系统批准所需测试级别规划的方法定义中。

所提出的方法为嵌入式系统识别和映射提供了一个结构化基础，汽车系统的每个部分都有唯一的编码。这可以用作跟踪和建模未来嵌入式系统开发和文档工具的基础，并且该框架也可以用作创建SW开发数据库的基础，其中可以存储所有车辆开发以及此处提出的识别。

END