新能源汽车车载控制器软件功能测试标准.docx
《新能源汽车车载控制器软件功能测试标准.docx》由会员分享，可在线阅读，更多相关《新能源汽车车载控制器软件功能测试标准.docx（66页珍藏版）》请在冰点文库上搜索。
新能源汽车车载控制器软件功能测试标准
新能源汽车车载控制软件功能测试标准
1范围
本标准规定了新能源汽车车载控制器功能测试开展全过程的要求，包括：
——对测试测试准备阶段、测试实施阶段和测试结束阶段要求；——对测试问题管理的要求；
——对测试人员能力的要求；
——对供应商控制器管控的要求；
——自动化测试框架推荐。
本标准适用于新能源汽车车载控制器软件功能测试，其他类型控制器的测试可参照使用。
2规范性引用文件
下列文件对于本文件的应用是必不可少的。
凡是注日期的引用文件，仅所注日期的版本适用于本文件。
凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。
GB20263—2006导航电子地图安全处理技术基本要求
GB/T30290.3—2013卫星定位车辆信息服务系统第3部分：
信息安全规范
ISO26262道路车辆系统设计功能安全
ISO/IEC27001—2005Informationtechnology—Securitytechniques—Informationsecuritymanagementsystems—Requirements
ISO/IEC/IEEE29119-3—20S13oftwareandsystemsengineering—Softwaretesting
Part3:
Testdocumentation-
3术语和定义
ISO/IEC/IEEE29119-1-2013界定的以及下列术语和定义适用于本文件。
为了方便使用，以下重复列出了GB/T20000.1-2014中的某些术语和定义。
3.1
对需求文档的覆盖
测试成功testsuccess
达成事先设定的测试目标，该测试目标可以是发现既定数量的问题、情况等，而不是指被测控制器或软件通过测试。
3.2
静态测试statictesting
对组件/系统进行的不执行程序代码（软件）的一种测试。
例如，对代码评审或静态代码的分析。
3.3
动态测试dynamictesting通过运行软件的组件或系统测试软件。
3.4
冒烟测试smoketesting
所有定义的或计划的测试用例的一个子集。
它覆盖组件/系统的主要功能，以查明程序
的绝大部分关键功能是否正常工作，但忽略其细节部分。
3.5
再测试verifytesting
首次测试发现问题后，针对已修改程序进行的问题关闭验证测试，通常在回归测试之前完成。
3.6
回归测试regressiontesting对已测试已修改程序进行的测试，确保软件的更改没有对未改变的部分带来新的失效。
4测试过程
4.1概述
测试开展过程从便于行业理解上划分成测试准备阶段、测试实施阶段、测试结束阶段。
以保障测试开展时内容的完整性和测试的有效性。
4.2测试准备阶段要求
4.2.1概述
在该阶段会涉及多种文件信息导入，在开始前应建立流程或采用正式文件约定的方式与测试提出方确定上述文件的具体提供方式和格式类型。
测试准备阶段的主要活动如下：
a）制定测试计划；
b）收集测试依据；
c）设置准入条件；
d）入口质量要求；
e）设置出口准则；
f）测试环境准备。
4.2.3测试计划
测试计划中应包含测试范围、测试时间周期、测试依赖资源的确认信息。
4.2.3.1测试范围确定
根据测试目标确认测试范围。
测试目标按照项目不同阶段的质量要求划分为：
研发阶段新功能验证、研发阶段功能变
更验证、研发阶段功能调试、量产功能验证、量产后功能变更验证。
针对上述不同的测试目标，其测试范围不应少于以下要求:
a）研发阶段新功能验证，应对新功能本身开展完整功能需求覆盖测试和代码覆盖度测试，对上层驱动功能、下层受影响功能开展功能集成测试，针对控制器涉及整车上下电、快充、慢充、行车功能开展测试，并确保在测试期间无故障报出；
b）研发阶段功能变更验证，应对变更部分代码开展功能需求覆盖测试，对上层驱动功能、下层受影响功能开展功能集成测试，针对控制器涉及整车上下电、快充、慢充、行车功能开展测试，并确保在测试期间无故障报出；
c）研发阶段功能调试，对功能本身开展功能正向测试，对上层驱动功能、下层受影响功能开展集成功能的正向测试；
d）量产功能验证，应开展完整功能测试；
e）量产后功能变更验证，开展完整功能测试。
除了以上测试目标外，若有其他测试目标时，可根据被测对象期望的目标质量要求来设置测试范围。
4.2.3.2测试时间周期确定
测试时间周期需要考虑的内容有:
已经确定的测试范围、被测对象质量现状、人员能力
现状。
已确定的测试范围可参照4.2.3.1，被测对象质量现状要求可参照4.2.6。
人员能力现状是指在已确定被测对象质量的现状前提下，在测试资源无异常的情况下完
成既定测试范围内容所需的时间。
宜采用的方法有经验评估和专家评估等。
由于测试准备阶段与测试结束阶段通常都与项目开发的其他活动并行开展，对项目整体影响较小，本标准重点对测试实施阶段的时间周期进行要求。
另外测试时间周期是基于风险拟定的。
测试实施阶段时间严格按照以下规则进行划分，其中的再测试与回归测试可以单独进行时间计划排布，按以下方式拟定计划时，应将计划与工作内容细化到1天。
测试实施阶段时间宜参考一下公式进行计算：
测试实施阶段时间=Tp+Ts+Tf+Tv+Tr
（1）
式中:
Tp为测试环境搭建时间
Ts为冒烟测试时间
Tf为功能测试时间
Tv为再测试时间
Tr为回归测试时间
测试环境搭建：
为被测对象搭建一个保障测试目标有效的测试环境，可以是闭环的，也可以是开环的。
测试环境搭建时间主要需要考虑测试工具或软件使用的难易程度、模拟测试环境的难易程度以及此间所涉及的重复性工作量。
冒烟测试：
为了保障后续测试的有效性和测试的可实施性，在正式的功能测试开始之前应对被测控制器的基本功能以及对整体功能有影响的部分首先开展测试。
冒烟测试时间主要
需要考虑冒烟测试的范围大小、自动化程度以及被测对象的质量现状。
功能测试：
即既定的测试需求，由具体测试范围大小所决定。
再测试：
为了关闭功能测试中所报出的问题而开展的测试，在再测试中应对受影响的功能以及被修改驱动的功能开展集成测试，对该时间影响较大的有问题的数量、问题本身的复杂程度以及软件的集成过程。
回归测试：
为了确定问题修改完之后没有引入新的问题而开展的测试，时间上受回归测试范围所决定，而回归测试范围受软件的集成过程、开发的自动化程度以及受影响的代码范围所决定。
针对开发过程中的不同情况预设测试周期的构成方式，可在测试开始前对开发人员做出
有助于开发与测
测试周期的开放式承诺，使测试时间的制定对开发方面更加透明和可预测，
A给出的测试周
试的合作意愿和测试团队的能力提升。
使用者可根据需要按照本标准附录期构成方式进行测试。
4.2.3.3确定测试依赖资源
测试依赖资源包括测试活动所需要的外在输入与内在资源。
其中外在输入主要指测试提出方以及与本次测试成功与否相关的利益干系人，提供的用以支撑测试实施以及确定测试范围的输入信息、被测对象。
测试输入信息包含功能描述文档、接口描述文档、测试目标信息。
被测对象除代码外也泛指被测对象功能整体表现所依存的对象，如在硬件在环测试环境中为了实现风扇开启功能所需的控制器硬件与控制器硬件接插件及附带线束。
内在资源指与测试相关的人员、测试工具、测试软件本标准在测试准备阶段对功能描述文档、接口描述文档、测试目标信息、被测对象、内在资源进行要求。
a）功能描述文档；
1）功能描述文档应具备以下性质，并且提供方须通过含检查项表单在内的评审记录或可追溯的其他信息对测试内容进行承诺：
——一致性：
该文档的直接干系人之间就内容已达成一致意见，在使用上不存在理解偏差，直接干系人至少包括文档的编写人、文档依据信息提供人、文档使用人；
——统一性：
文档内容之间以及与其成套的文档间无相互矛盾；——可验证性：
有明确的访问或检查接口指引，同时有明确的判定指标；——可追溯性:
与其他文档有追溯关系，或有明确的文件信息表明其来源；——可理解性：
术语用词基于公司或测试开发团队共同约定，若文档依据信息提供方为非软件开发团队时，应由文档编写方创建术语表。
2）功能描述文档在内容描述时需要遵循以下原则：
——不可使用超过7条语句来描述同一功能情景；
——每条语句仅使用主动语态级用1个过程动词来明确表达需求，应避免错综复杂的语句描述；
——名词的指向应为某项具体的内容，而非指向某个类别的内容，比如不应
用“控制器”来替代“电机控制器”；
有”、每个”所有的”;
不可使用不确定的词汇对功能进行描述，比如“可能”、“有时”、“一
些”、“部分”；
不可存在非完整的规格说明条件，在对一个需求进行说明时，应确保涵
盖对所有数据范围的描述。
例如，当描述电压大于380V时所有电磁阀
打开”时，还应说明电压小于等于380V时电磁阀开启或关闭情况及其引发现象。
此外，只有一种情况可以不对全范围数据进行描述，即当接口输出值为布尔类型非A即B时，默认描述完合适输出A后，其他情况均
为B，即当描述温度大于20度时风扇开启（A）”则默认为当温度小于等于20度时风扇关闭（B），不完全说明时本标准默认为输出取值为相反状态；
推荐该文档提供者使用自然语言模板进行描述，或者为了使该文档的使
用程度更高，使用自然语言模板对编写者进行相应培训，以下推荐一种
的自然语言模板：
图1被测模板文件功能描述文件自然语言模板
注1：
过程动词是指描绘功能性、操作动作的词汇，如发送、断开、闭合。
注2：
目标文件是指“过程动词”作用的目标。
该文件在使用自然语言构成的同时，推荐在不同场合增加以下表达方式来清晰对功
能的描述：
1）用例图
2）UML类图
3）UML活动图
4）UML状态图
以上4类图例表达方式为公开技术，本标准不再进行复述。
b）接口描述文档；接口描述文档需要描述被测对象存在的物理状态以其接口形式。
该文件用以描述被测目标文件的测试接口，考虑到接口形式、类型并不相同，可通过多类文件进行描述，比控制器硬线接口定义、CAN通讯协议、诊断协议、标定协议文件、以太网协议等。
本标准要求接口名称应与该接口实际功能有匹配关系，接口描述的内容应包含其接口特性所应承载的内容，同时应描述该接口的传输方向。
物理状态为真实控制器的被测对象接口涉及内容广泛，为免疏漏以真实控制器情况下的接口描述为例，如在对数字和模拟通道接口描述时，应包含以下信息：
1）与数字和模拟通道相连的外围电气负载，可以原理图的形式呈现；
2）信号类型（模拟量、开关量、PWM等）、收发频率、门限值、准确度设计要求；
3）若该通道需要开展硬线信号故障注入，应确定接口外接属于执行器还是传感器；
4）若有外接传感器应给出关联传感器电气特性；
5）若有执行器应给出关联执行器电气特性。
通信协议用于仿真和接收被测目标文件总线通信信息，模拟与被测目标文件交互的虚拟
节点。
所有协议相关文件（如.dbc、.ldf）和通讯矩阵（至少包含：
ID、消息长度、信号、发送频率/周期、数据范围、数据分辨率）提供通讯矩阵每个信号的意义解释；对于状态信号，应在后续的功能描述文件中提供详细的状态转换逻辑说明；
如果协议文件中存在CRC校验（或CheckSum），应在后续的功能描述文件中提供详细的校验算法说明。
c）测试目标信息补充；
测试任务描述应包括测试任务目标来源信息，任务相关的主要利益干系人，任务的直接下发团体及人员，描述任务发起人及主要利益干系人要求开展本次测试的目的、软件用途。
在后续设计测试出口准则以及用例设计时应参考本部分内容。
推荐包括下述其中一个或多个测试目标信息在任务表述时被提出：
1）测试完成后期望达到的质量/性能目标（这个目标如果被提出则应是量化的）
2）测试未关闭问题的严重程度
3）测试功能覆盖范围与测试应完成的时间节点
d）被测对象；
被测对象为代码时，应提供完整的程序，包括其所依赖的库文件。
被测对象的载体若为控制器硬件，此时除了被测对象所搭载的控制器外，同时也应包含带有插针的接插件以及连接线束。
e）内在资源；需要确定在实施计划以内完成测试所需的人员及其能力是否匹配，包括其出勤情况等。
需要确定所需工具是否可用，数量是否充足，所需工具如万用表、示波器、HIL测试台架、充电桩、充电卡、手机APP等。
需要确定所需要的测试软件是否完成在测试电脑上的部署，并确认测试电脑对外信息接口状态是否符合公司或团队的要求。
4.2.4准入条件准入条件在设置时应考虑在一般外在压力情况下是否可执行，以及是否为测试实施的必要条件。
准入条件的设置可告知干系人测试实施的启动条件并对测试进行有效管理。
在以下情况时应考虑将其设置为准入条件：
a）测试所依存的信息、文件缺失导致测试无法实施，严重影响测试启动；
b）文件数量庞大，来源复杂，需要额外关注，实时审核测试提出方提供所需的文件和信息；
c）若同一测试提出方开展的测试，统计数据显示每次发生的问题数量随机性较大，导致测试计划时常无法按时完成，此时应按照4.2.5的要求设置准入条件。
4.2.5入口质量要求入口质量作为准入条件的一部分考虑到其重要程度在本部分单独进行要求。
a）应被描述和证明，证明文件由被测对象提供方提供，若没有相关文档或交付信息时，也应描述为无，此时代表开发前端未开展过任何调试或测试；
b）不单包含计划内测试内容应该达到的质量，还应包含在测试期间测试需求发生变化的部分应该达到的质量；
c）文档应描述被测对象在开展本次测试前所经历过的测试，内容应包括测试覆盖范围、测试级别、发现问题列表以及其整改情况。
若未开展过任何测试，则应描述其开展过的调试情况，包括调试时长、调试环境模拟情况以及调试发现的问题。
4.2.6出口准则出口准则为表明测试何时结束的条件。
设置出口准则时应按照如下实施：
a）测试在不可抗拒力的情况下无法实施应默认为出口准则，无需单独列出；
b）当4.2.3.1中的测试范围全部完成并通过时应默认为出口准则，无需单独列出；
c）可作为计划的时间节点应满足时的最低质量要求给出；
d）可作为因软件问题导致测试无法实施的最长时间要求。
4.2.7测试环境准备
所搭建的测试环境同时包含开环的部分与闭环的部分，测试环境中的被测对象输入的某个或多个信号与被测对象输出的某个或多个信号，在以下情况下应搭建闭环测试环境：
a）与被控对象存在关联关系；
b）输出信号至某个控制器（该控制器为被测对象以外的虚拟节点）的输入信号为同一控制器发送，且两信号间存在逻辑关系。
一般性要求：
a）测试环境的存在形式与被测对象相关，如被测对象为simulink模型文件，则测试环境也应为模型文件或其他可以与simulink模型文件进行交互的测试环境；
b）测试环境的运行步长应小于被测对象的程序运行最小步长；
c）测试环境与被测对象交互部分的仿真程度应符合测试目标的要求；同时本标准对硬件在环测试设备、测试工具软件进行如下要求。
4.2.7.1硬件在环测试设备的要求
硬件在环测试设备应包含以下要素：
a）PC上位机：
用于承载HIL测试系统中上位机软件的部署；
b）实时仿真处理器：
用于承载实时环境模型，处理实时模型数据，该处理器的选取应考虑需要被承载的环境模型在该处理器上运行时，被测控制器的程序运行时钟步长应为仿真环境模型实时运行最小步长时间的整数倍数，且该整数应大于2；
c）I/O板卡：
用于数字量/模拟量/频率量/电阻/电流信号的采集与输出，能够涵盖汽车动力系统、底盘系统等系统所需的所有I/O通道。
通道类型和数量可在实施前根据所需测试的控制器接口情况进行匹配，在对被测控制器进行调研时应关注其通道类型、信号范围、准确度要求，对于一些反复变化的信号还应考虑其采集/发送的频率
情况；
d）通讯板卡：
用于仿真器与各种总线系统的连接通讯，支持CAN、LIN、车载以太网和FlexRay总线系统，具体选用何种通讯可根据实施方的情况进行选择；
e）程控电源：
用于模拟车载蓄电池电压曲线，为系统供电，并提供安全保护等功能，由于该电源在模拟蓄电池电压的同时，还可能会给I/O板卡供电，为了获得车载蓄电池电压与控制器输入信号电压独立控制的测试效果，宜配备2块以上的程控电源；f）故障注入板卡：
可以与模拟和数字通道信号链接实现故障注入，通过电磁阀切换或者其他方式实现小电流与故障通道连接。
用于故障注入测试，应包含悬空、对地短接、对电源短接、通道与通道间短接。
对于具备不同属性的设备仪器选型宜参考以下要求：
a）对具有采样率指标的设备仪器，一般宜设备采样频率大于被测量信号的周期频率。
例如，电机控制器设备模拟信号采样率大于被测量信号周期频率的50倍；设备数
字信号采样率大于被测量信号周期频率的10倍。
例如，整车控制器设备模拟信号
采样率大于被测量信号周期频率的8倍，设备数字信号采样率大于被测量信号周期
频率的8倍；
b）对具有量程指标的设备仪器宜被测信号正向最大值不超过仪器量程正向最大值的
80%，且精度控制在土0.5%以内；被测信号负向最小值不超过仪器量程负向最小值的80%，且精度控制在土0.5%以内；
c）对具有功率等级的设备仪器宜所提供电压、电流及功率均能满足被测设备要求，且
具有不低于20%的功率余量，电流电压精度控制在土0.5%以内，10%负载时功率因素大于98%,阻性负载时纹波小于0.1%,10%〜90%电流上升时间小于2MS,当设备发生短路或故障时能够安全及时动作保护。
设备选型时应参考对应的设备说明书，结合被测软件的特点，还应考虑以下宜进行选型：
a）从自动化扩展方面考虑，PC上位机搭载上设备所需软件工具后，其发送指令开始
计时到该信号被实时处理器处理完成并回传截止的时间间隔为T1，应至少为被测
控制器中涉及时间控制描述中最小时间T2的0.5倍。
T1时间通常与操作系统、工
作站性能、软件工具相关，测量条件推荐为当前版本Matlab软件正在打开的同时开始测量；
b）I/O板卡的通道类型及总数根据被测软件的实际情况决定，模拟量大电压采样精度在土0.5%，模拟量小电压采样精度在±0.1%性能方面宜达到以下要求：
表2设备性能要求
通道类型
采样率
输入/输岀范围
精度
AI
10kS/s
大于等于系统设计最大电压
优于控制器的输岀精度
AO
10kS/s
大于等于系统设计最大电压
优于控制器的采样精度
DI
10kS/s
大于等于系统设计最大电压
/
DO
10kS/s
大于等于系统设计最大电压
/
c）对于CAN通讯通常宜要求如下：
独立高速CAN通道，波特率可配置，最高传输速
率1Mbps，可导入配置的dbc文件，通道数量满足被测控制器的网络数量；
d）程控电源配置宜：
电压范围大于被测控制器的最大额定电压，电流范围满足被测控制器的最大工作电流，具有程控功能。
由于车载控制器分类比较多，例如电机控制器、整车控制器、电池管理系统、DC-DC控
制器等，不同控制器台架的在环测试设备有所不同，可根据其具体情况及测试目的配备其他必要的测试设备。
4.2.7.2测试工具软件的要求测试工具软件分为两类，一是用于运行测试环境，二是用于测试执行。
a）运行测试环境的工具；
模型环境测试和软件集成环境测试在上位机平台上执行，测试工具软件选取可考虑以下因素：
1）自动代码生成，可将常用的软件搭建模型转换为高效、确定且简明易读的C语
言代码；
2）代码覆盖度分析，针对代码执行过程的动态分析，找出从未被执行的代码段。
要求自带代码覆盖度分析功能，或留有接口覆盖度分析的工具接入；
3）测试机制，能够使用多种测试机制、测试手段对代码进行测试，留有不同的接口可用于模型或代码进行信号连接，构成如MIL、SIL、PIL等测试环境；
4）代码生成效率，测试工具能够对模型或代码效率进行分析，简化模型和代码的
复杂度，通常一个5M大小的环境模型编译时间不应超过10分钟；
5）自动化程度，测试工具的选取应具有一定的通用性和自动化功能，提高测试的效率；
6）可扩展性，工具本身预留充足接口便于进行二次开发；
7）用于测试的代码情况。
由于上位机上开展测试的代码有可能并非完整代码，需
要考虑用于测试的这部分代码里是否含有服务层代码，若有则在选择测试软件
时应考虑是否应具备将服务层发送的数据转换为信号的功能；
8）符合相关的质量标准和功能标准。
这一项可根据实施方在这方面的要求进行考
虑，如开发流程需要开展或已经开了ISO26262的认证，那么需要考虑是否符合ISO26262标准对验证工具软件的要求，若开发上采用了AUTOSA架构，则
需要考虑是否支持AUTOSA标准软件部分的测试。
b）测试执行工具；
测试设备本身也需要依托于测试上位机的工具软件来开展测试，测试设备的工具软件应至少满足以下要求：
1）测试采用的软件应至少支持Windows,Mac,Linux等系统中的一种或多种操作系统，支持CC++、Python、.NET语言接口；
2）支持使用可视化的图形建模工具搭建环境模型；
3）具备数据分析和环境模型转换为运行代码的功能，具备标准的第三方软件接口。
能够满足多任务、多用户的测试开发需求；
4）测试软件应能支持实时测试和在线标定、配置和控制I/O接口，提供操作界面，实现测试自动化，出具测试报告的功能；
5）测试软件应具备多种数据类型格式的实时导入和存储功能，支持向量、数组、结构体等多种形式的数据写入和存储。
存储的数据可以进行格式转化和二次开发。
4.3测试实施阶段要求
测试实施阶段除了测试执行本身外，还包括对功能描述文档的前期处理以及测试设计方面的要求。
4.3.1对测试需求的分析要求
对测试需求的分析为可选内容，若测试准备阶段提供的描述文件，指向清晰，条目化清晰可不做测试需求的分析。
开展测试需求分析的目的是在于将测试需求条目化、识别测试接口、明确每条测试需求
的测试用例设计要求以及在有可能的情况下提取非功能性质量要求。
a）条目化；
根据功能描述文件进行条目化工作，从文档中将相对独立的功能描述内容提取出来构成一个单独的条目，同时明确该功能的前置条件。
b）测试接口；根据功能描述文件与接口描述文件识别条目化后的功能涉及的输入接口、输出接口。
若两份描述文件由不同部门编写，则可能遇到两份文件中接口描述名词不一致的情况，
若无法短时间内修正，那么应在描述测试接口时应明确注明该接口所接收的额外信息来源。
c）用例设计要求；
根据测试目的以及功能本身可能带来的影响，针对条目化的内容逐一编写用例设计要求，在设计时除了考虑对测试设计方法选用的要求外，还可参考4.3.3对不同等级进行要求
d）非功能性质量要求。
非功能性
升级会员 