《电动汽车车载控制器软件功能测试规范(T-CSAE 177—2021).pdf》由会员分享，可在线阅读，更多相关《电动汽车车载控制器软件功能测试规范(T-CSAE 177—2021).pdf（39页珍藏版）》请在taowenge.com淘文阁网|工程机械CAD图纸|机械工程制图|CAD装配图下载|SolidWorks_CaTia_CAD_UG_PROE_设计图分享下载上搜索。
1、ICS 43.120 CCS T 40 团 体 标 准 T/CSAE 1772021 电动汽车车载控制器软件功能测试规范 Test specification for software function of vehicle controller for electric vehicles 2021-04-15 发布 2021-04-15 实施 中国汽车工程学会 发布 T/CSAE 1772021 I 目 次 前言.IV 引言.V 1 范围.1 2 规范性引用文件.1 3 术语和定义.1 4 测试过程要求.2 4.1 测试准备阶段要求.2 4.1.1 主要活动.2 4.1.2 测试计划.2 4
2、.1.3 准入条件.6 4.1.4 入口质量要求.6 4.1.5 出口准则.6 4.1.6 测试环境准备.7 4.2 测试实施阶段要求.9 4.2.1 对测试需求的分析要求.9 4.2.2 基于需求的测试用例设计要求.9 4.2.3 基于经验的测试设计要求.15 4.2.4 基于安全的测试设计要求.15 4.2.5 测试执行要求.19 4.3 测试结束阶段要求.20 5 测试问题管理要求.21 5.1 问题状态.21 5.2 问题确认.21 5.3 测试问题修改.22 5.4 测试问题关闭验证.22 5.5 测试问题评审.22 5.6 测试问题跟踪.23 5.7 测试问题总结.23 5.8 测
3、试问题分析.23 6 测试人员能力要求.23 6.1 汽车业软件测试知识基础框架体系概述.23 6.2 体系的基础.24 6.3 体系的内容.24 6.3.1 概述.24 6.3.2 汽车软件测试助理.24 T/CSAE 1772021 II 6.3.3 汽车软件基础级测试员.24 6.3.4 汽车软件测试工程师.24 7 供应商控制器管控要求.25 7.1 控制器供应商测试实施方法.25 7.1.1 委托第三方测试机构进行测试.25 7.1.2 委托第三方测试机构审查.25 7.2 第三方测试机构资质要求.25 7.2.1 第三方测试机构企业定位.25 7.2.2 人员团队要求.25 7.2
4、.3 测试环境要求.25 7.2.4 测试设计与执行能力要求.26 7.3 控制器供应商第三方委托测试的要求.26 7.3.1 控制器供应商样件管理要求.26 7.3.2 控制器供应商测试输入物的要求.27 7.3.3 控制器供应商项目时间要求.27 7.3.4 控制器供应商项目测试计划要求.27 7.3.5 控制器供应商测试问题管理要求.27 7.3.6 控制器供应商测试整改要求.27 7.4 委托第三方测试机构测试流程.27 7.4.1 第三方测试机构定点.28 7.4.2 项目启动.28 7.4.3 测试输入物交付及审核.28 7.4.4 测试用例开发.28 7.4.5 测试环境开发.2
5、8 7.4.6 测试执行.29 7.4.7 测试报告交付.29 7.4.8 回归测试.29 7.4.9 测试结束.29 7.5 委托第三方测试机构审查流程.29 7.5.1 第三方测试机构定点.29 7.5.2 第三方测试机构审查计划制定.29 7.5.3 测试输入物交付.29 7.5.4 第三方测试机构审查测试用例.30 7.5.5 第三方测试机构测试环境开发.30 7.5.6 第三方测试机构抽查测试.30 7.5.7 第三方测试机构审查结项.30 8 自动化测试.30 8.1 自动化测试的实施背景.30 8.1.1 回归测试与工程变更.30 8.1.2 具有与时间相关的非功能性要求.30
6、8.2 自动化测试脚本要求.31 8.2.1 测试环境配置与初始化.31 T/CSAE 1772021 III 8.2.2 信号访问路径.31 8.2.3 测试语言.31 附录 A（资料性）测试周期构成方式示例.32 附录 B（资料性）问题记录模板.33 T/CSAE 1772021 IV 前 言 本文件按照GB/T 1.12020标准化工作导则 第1部分：标准化文件的结构和起草规则的规定起草。请注意本文件的某些内容可能涉及专利，本文件的发布机构不承担识别这些专利的责任。本文件由电动汽车产业技术创新战略联盟提出。本文件起草单位：北京新能源汽车股份有限公司、中汽研(天津)汽车工程研究院有限公司、
7、上海滔瑞信息技术有限公司、工业和信息化部计算机与微电子发展研究中心（中国软件评测中心）、合肥工业大学、南京越博动力系统股份有限公司、上汽海外出行科技有限公司、威马汽车成都研究院。本文件主要起草人：黄颍华、代康伟、刘全周、周震漪、晏江华、闫书磊、李丹、陈一帆、李麟、郭盈、朱科屹、叶璐、贺林、王劲伟、王星、邵桂欣、欧俊。T/CSAE 1772021 V 引 言 本文件根据国内现有电动汽车控制器软件功能测试的需求而编写。测试是控制器软件开发的关键环节，目前国内控制器测试工作不仅在原有的验收检验领域不断深化发展，而且也越来越多的渗透入上游控制器开发的工作进程中。这些功能的验证和检测工作将为控制器软件开
8、发需求的实现提供有效证明，并且为产品的质量、潜在风险包括产品后期优化升级的方向提供专业的信息。随着控制器产品需求的高速迭代扩展，测试工作的体量和复杂度也在不断增加，本文件通过提供适当的要求和流程为测试工作推荐指导实践方法。车载控制器软件测试是通过一系列活动实现的，这些活动可以通过有效组织匹配应用于不同类型的控制器软件开发体系中，尽管本文件针对的是电动汽车车载控制器测试，但它也为其他工业领域的控制器开发的验收检验工作提供指导。电动汽车车载控制器软件测试活动受控制器开发体系（自主、外包）、开发类型（V型等）开发流程（迭代、瀑布等）、开发成熟程度（单一架构、多平台化等）的影响并与开发活动和工作成果直
9、接关联，本文件即与控制器软件开发工作强相关。T/CSAE 1772021 1 电动汽车车载控制器软件功能测试规范 1 范围 本文件规定了电动汽车车载控制器软件功能测试开展全过程的要求，包括对测试准备阶段、测试实施阶段和测试结束阶段要求，对测试问题管理的要求，对测试人员能力的要求，对供应商控制器管控的要求以及自动化测试实施方案的推荐。本文件适用于电动汽车出厂时与整车搭载的控制器系统完成安装链接的控制单元的软件功能测试，其他类型控制器的测试可参照使用。2 规范性引用文件 下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期
10、的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB 202632006 导航电子地图安全处理技术基本要求 GB/T 30290.32013 卫星定位车辆信息服务系统 第3部分：信息安全规范 GB/T 34590.6 道路车辆 功能安全 第6部分：产品开发：软件层面 GB/T 38634.12020 系统与软件工程 软件测试 第1部分：概念和定义 GB/T 38634.32020 系统与软件工程 软件测试 第3部分：测试文档 ISO/IEC 270012013 信息技术 安全技术 信息安全管理体系要求(Information technology Security techniques
11、Information security management systems.Requirements)CNAS-CL01-A019:2018 检测和校准实验室能力认可准则在软件检测领域的应用说明 3 术语和定义 GB/T 38634.12020界定的以及下列术语和定义适用于本文件。3.1 测试成功 test success 达成事先设定的测试目标，该测试目标可以是发现既定数量的问题、对文档或代码的覆盖要求、完成既定的测试范围等。3.2 静态测试 static testing 在不运行代码的情况下，通过一组质量准则或其他准则对测试项进行检查的测试。例如，对代码评审或静态代码分析。T/CSAE
12、 1772021 2 3.3 动态测试 dynamic testing 需要运行测试项的测试。通过运行组件或系统，判断其工作正确性。3.4 冒烟测试 smoke testing 所有定义的或计划的测试用例的一个子集。它覆盖组件/系统的主要功能，以查明程序的绝大部分关键功能是否正常工作，在正式测试之前，对简单的、基础的程序失效情况进行检测。3.5 再测试 verification testing 测试发现问题后，针对已修改程序进行的问题关闭验证测试，通常在回归测试之前完成。3.6 回归测试 regression testing 对已测试已修改的程序进行的测试，确保软件的更改没有对未改变的部分带来
13、新的失效。3.7 黑盒测试 black-box testing 主要基于测试项外部输入和输出的一种测试，通常是依据规格说明的测试。不考虑软件组件或系统内部结构的测试。3.8 白盒测试 white-box testing 通过分析组件/系统的内部结构的动态测试。4 测试过程要求 4.1 测试准备阶段要求 4.1.1 主要活动 测试准备阶段的主要活动如下：a)制定测试计划；b)收集测试依据；c)设置准入条件；d)入口质量要求；e)设置出口准则；f)测试环境准备。4.1.2 测试计划 4.1.2.1 测试范围确定 T/CSAE 1772021 3 测试范围按照项目不同阶段来确定，不应少于以下要求：a
14、)研发阶段功能验证，应对新功能本身开展完整的功能需求覆盖测试和代码覆盖度测试，对功能本身以及受影响功能开展功能集成测试，针对控制器涉及快充、慢充、行车基本功能开展测试，并确保在测试期间无非预期的故障报出；b)量产功能验收，应开展完整的功能测试，测试结果符合组织的测试出口准则；c)量产后功能变更验证，应开展完整功能测试，测试结果符合出口准则，但如果存在未涉变部分代码可由开发组织对质量做出承诺，且该质量承诺经测试方认可有效时，可缩减该部分代码的测试内容；d)除了以上测试目标外，若有其他测试目标时，可根据被测对象期望的目标质量要求来设置测试范围。4.1.2.2 测试时间周期确定 测试时间周期需要考虑
15、的内容有：a)已经确定的测试范围；b)被测对象质量现状；c)人员能力评估。已确定的测试范围按照4.1.2.1，被测对象质量现状要求按照4.1.2.3.4。人员能力评估是指在参考既定测试人员以往的工作效率数据，这些数据指向的既定人员当时具体的工作内容，评估时将其与本次测试实际工作内容的差异进行比较。需要考虑的差异项包括复杂程度、内容体量以及该人员已有的并行任务情况。应采用的方法有经验评估和专家评估等。测试准备阶段与测试结束阶段通常不占用设备资源，会与众多项目的活动并行开展，对项目整体影响较小，本文件重点对测试实施阶段的时间周期进行要求。测试实施阶段时间严格按照以下规则进行划分，其中的再测试与回归
16、测试可以单独进行时间计划排布，按以下方式拟定计划时，应将计划与工作内容细化到1个工作日。测试实施阶段时间按公式（1）进行计算：.(1)式中：T 测试实施阶段时间，单位为天（d）；Tp 测试环境搭建时间，单位为天（d）；Ts 冒烟测试时间，单位为天（d）；Tf 功能测试时间，单位为天（d）；Tv 再测试时间，单位为天（d）；Tr 回归测试时间，单位为天（d）。测试环境搭建：为被测对象搭建一个保障测试目标有效的测试环境，可以是闭环的，也可以是开环的。测试环境搭建时间主要需要考虑测试工具或软件使用的难易程度、模拟测试环境的难易程度以及历史测试资产的可重用情况。冒烟测试：保障后续测试的有效性和测试的连
17、续性，在正式的功能测试开始之前应对被测控制器的基本功能以及对整体功能有较大影响的部分首先开展测试。冒烟测试时间主要需要考虑冒烟测试的范围大小、自动化程度以及被测对象的质量现状。功能测试：即既定的测试需求，由具体测试范围大小所决定。再测试：为了关闭功能测试中所报出的问题而开展的测试，在再测试中应对受影响的功能以及被修改驱动的功能开展集成测试，对该时间影响较大的有问题的数量、问题本身的复杂程度以及受影响的代码范围。T/CSAE 1772021 4 回归测试：为了确定问题修改完之后没有引入新的问题而开展的测试，时间上受回归测试范围所决定，而回归测试范围受软件的集成过程、开发的自动化程度以及受影响的代
18、码范围所决定。应针对开发过程中的不同情况参照公式(1)预设测试周期的构成方式，并在测试开始前对开发人员做出测试周期的开放式承诺。使用者可根据需要按照附录A给出的测试周期构成方式示例预设测试周期构成。4.1.2.3 测试依赖资源确定 4.1.2.3.1 概述 测试依赖资源包括测试活动所需要的外在输入与内在资源。其中外在输入指测试提出方以及与本次测试成功与否相关的利益干系人提供的用以支撑测试实施以及确定测试范围的输入信息、被测对象。测试输入信息包含功能描述文档、接口描述文档、测试目标信息。被测对象除代码外也泛指被测对象功能整体表现所依存的对象，如在硬件在环测试环境中为了实现风扇开启功能所需的控制器
19、硬件与控制器硬件接插件及附带线束。内在资源指与测试相关的人员、测试设备、测试工具软件。4.1.2.3.2 外在输入要求 4.1.2.3.2.1 功能描述文档 功能描述文档应满足以下要求。a)功能描述文档应具备以下性质，并且提供方应通过含检查项表单在内的评审记录或可追溯的其他信息对功能描述文档进行以下承诺：1)一致性：该文档的直接干系人之间就内容已达成一致意见，在使用上不存在理解偏差，直接干系人至少包括文档的编写人、文档依据信息提供人、文档使用人；2)统一性：文档内容之间以及与其成套的文档间无相互矛盾；3)可验证性：有明确的访问或检查接口指引，同时有明确的判定指标；4)可追溯性：与其他文档有追溯
20、关系，或有明确的文件信息表明其来源；5)可理解性：术语用词基于虚拟或实际的测试开发团队共同约定，若文档依据信息的提供方为非软件开发团队时，应由文档编写方创建术语表。b)功能描述文档在内容描述时需要遵循以下原则：1)不可使用超过 7 条语句来描述同一功能情景；2)每条语句仅使用主动语态及用 1 个过程动词来明确表达需求，应避免错综复杂的语句描述；3)名词的指向应为某项具体的内容，而非指向某个类别的内容，比如不应用“控制器”来替代“电机控制器”；4)在使用全称量词时应确认是否适用，全称量词如，“从不”、“总是”、“没有”、“每个”、“所有的”；5)不可使用不确定的词汇对功能进行描述，比如“可能”、
21、“有时”、“一些”、“部分”；6)不可存在非完整的规格说明条件，在对一个需求进行说明时，应确保涵盖对所有数据范围的描述。例如，当描述“电压大于 380 V 时所有电磁阀打开”时，还应说明电压小于等于 380V时电磁阀开启或关闭情况及其引发现象。此外，只有一种情况可以不对全范围数据进行描述，即当接口输出值为布尔类型非 A 即 B 时，默认描述完合适输出 A 后，其他情况均为 B，即“当描述温度大于 20 度时风扇开启（A）”，则默认为当温度小于等于 20 度时风扇关闭（B），不完全说明时本文件默认为输出取值为相反状态；T/CSAE 1772021 5 7)推荐该文档提供者使用自然语言模板进行描述
22、，或者为了使该文档的使用程度更高，使用自然语言模板对编写者进行相应培训，以下推荐一种的自然语言模板见图 1。什么时候或在什么条件下系统系统名称信号名称必须应该将过程动词提供给谁？使其能够能够对象关于对象的细节补充 图1 被测模板文件功能描述文件自然语言模板 注1：过程动词是指描绘功能性、操作动作的词汇，如发送、断开、闭合。注2：目标文件是指“过程动词”作用的目标。注3：该文件在使用自然语言构成的同时，推荐在不同场合增加用例图、UML 类图、UML 活动图、UML 状态图等表达方式来清晰对功能的描述。4.1.2.3.2.2 接口描述文档 接口描述文档需要描述被测对象存在的物理状态以其接口形式。该
23、文件用以描述被测目标文件的测试接口，考虑到接口形式、类型并不相同，可通过多类文件进行描述，比如控制器硬线接口定义、通讯协议（CAN、CANFD、Flexray、Ethernet等）、诊断协议、标定协议文件、以太网协议等。接口名称应与该接口实际功能有匹配关系，接口描述的内容应包含其接口特性所应承载的内容，同时应描述该接口的传输方向。物理状态为真实控制器的被测对象接口涉及内容广泛，为免疏漏以真实控制器情况下的接口描述为例，如在对数字和模拟通道接口描述时，应包含以下信息：a)与数字和模拟通道相连的外围电气负载，可以原理图的形式呈现；b)信号类型（模拟量、开关量、PWM 等）、收发频率、门限值、准确度
24、设计要求；c)若该通道需要开展硬线信号故障注入，应确定接口外接属于执行器还是传感器；d)若有外接传感器应给出关联传感器电气特性；e)若有执行器应给出关联执行器电气特性。通信协议用于仿真和接收被测目标文件总线通信信息，模拟与被测目标文件交互的虚拟节点。所有协议相关文件（如.dbc、.ldf）和通讯矩阵(至少包含：ID、消息长度、信号、发送频率/周期、数据范围、数据分辨率)提供通讯矩阵每个信号的意义解释；对于状态信号，应在后续的功能描述文件中提供详细的状态转换逻辑说明；如果协议文件中存在CRC校验（或CheckSum），应在后续的功能描述文件中提供详细的校验算法说明。4.1.2.3.2.3 测试目
25、标信息补充 T/CSAE 1772021 6 测试任务描述应包括测试任务目标来源信息，任务相关的主要利益干系人，任务的直接下发团体及人员，描述任务发起人及主要利益干系人要求开展本次测试的目的、软件用途。在后续设计测试出口准则以及用例设计时应参考本部分内容。推荐包括下述其中一个或多个测试目标信息在任务表述时被提出：a)测试完成后期望达到的质量/性能目标（这个目标如果被提出则应是量化的）；b)测试未关闭问题的严重程度；c)测试功能覆盖范围与测试应完成的时间节点。4.1.2.3.2.4 被测对象 被测对象为代码时，应提供完整的程序，包括其所依赖的库文件。被测对象的载体若为控制器硬件，此时除了被测对象
26、所搭载的控制器外，同时也应包含带有插针的接插件以及连接线束。4.1.2.3.2.5 内在资源 应确定在实施计划以内完成测试所需的人员及其能力是否匹配，包括其出勤情况等。应确定所需工具是否可用，数量是否充足，所需工具如万用表、示波器、HIL测试台架、充电桩、充电卡、手机APP等。应确定所需要的测试软件是否完成在测试电脑上的部署，并确认测试电脑对外信息接口状态是否符合单位或团队的要求。4.1.3 准入条件 在以下情况时应考虑将测试所需信息、文件审核设置为准入条件：a)测试所依存的信息、文件缺失导致测试无法实施，严重影响测试启动；b)测试文件数量庞大，来源复杂，需要额外关注；c)若同一测试提出方开展
27、的测试，统计数据显示每次发生的问题数量随机性较大，导致测试计划时常无法按时完成。4.1.4 入口质量要求 入口质量要求如下：a)应被描述和证明，证明文件由被测对象提供方提供，若没有相关文档或交付信息时，也应描述为无，此时代表测试之前未开展过任何调试或测试；b)不单包含计划内测试内容应该达到的质量，还应包含在测试期间测试需求发生变化的部分应该达到的质量；c)文档应描述被测对象在开展本次测试前所经历过的测试，内容应包括测试覆盖范围、测试级别、发现问题列表以及其整改情况。若未开展过任何测试，则应描述其开展过的调试情况，包括调试时长、调试环境模拟情况以及调试发现的问题及其更改记录。4.1.5 出口准则
28、 出口准则为表明测试何时结束的条件。设置出口准则时应按照如下实施：a)测试在不可抗拒力的情况下无法实施应默认为出口准则，无需单独列出；b)当 4.1.2.1 中的测试范围全部完成并通过时应默认为出口准则，无需单独列出；c)可作为计划的时间节点应满足时的最低质量要求给出；d)可作为因软件问题导致测试无法实施的最长时间要求。T/CSAE 1772021 7 4.1.6 测试环境准备 4.1.6.1 概述 所搭建的测试环境可同时包含开环部分与闭环部分，测试环境中被测对象输入的某个或多个信号与被测对象输出的某个或多个信号，在以下情况下应搭建闭环测试环境：a)相互间因被控对象存在关联关系；b)输出至某个
29、控制器（该控制器为被测对象以外的虚拟节点）的某个或多个信号与接收的该控制器的某个或多个信号间有必然的逻辑关系。测试环境一般性要求如下：a)测试环境可与被测对象进行数据交互；b)测试环境的运行步长应小于被测对象的程序运行最小步长；c)测试环境与被测对象交互部分的仿真程度应符合测试目标的要求。4.1.6.2 硬件在环测试设备的要求 4.1.6.2.1 环测试设备要素 硬件在环测试设备应包含以下要素：a)PC 上位机：用于承载 HIL 测试系统中上位机软件的部署；b)实时仿真处理器：用于承载实时环境模型，处理实时模型数据，该处理器的选取应考虑需要被承载的环境模型在该处理器上运行时，被测控制器的程序运
30、行时钟步长应为仿真环境模型实时运行最小步长时间的整数倍数，且该整数应大于 2；c)I/O 板卡：用于数字量/模拟量/频率量/电阻/电流信号的采集与输出，能够涵盖汽车动力系统、底盘系统等系统所需的所有 I/O 通道。通道类型和数量可在实施前根据所需测试的控制器接口情况进行匹配，在对被测控制器进行调研时应关注其通道类型、信号范围、准确度要求，对于一些反复变化的信号还应考虑其采集/发送的频率情况；d)通讯板卡：用于仿真器与各种总线系统的连接通讯，支持 CAN、CANFD、LIN、车载以太网，具体选用何种通讯可根据实施方的情况进行选择；e)程控电源：用于模拟车载蓄电池电压曲线，为系统供电，并提供安全保
31、护等功能，考虑到该电源在模拟蓄电池电压的同时，还可能会给 I/O 板卡供电，为了获得车载蓄电池电压与控制器输入信号电压独立控制的测试效果，应配备 2 块以上的程控电源；f)故障注入板卡：可以与模拟和数字通道信号链接实现故障注入，通过电磁阀切换或者其他方式实现小电流与故障通道连接。用于故障注入测试，应包含悬空、对地短接、对电源短接、通道与通道间短接。4.1.6.2.2 设备仪器选型 对于具备不同属性的设备仪器选型应参考以下要求：a)对具有采样率指标的设备仪器，一般设备采样频率大于被测量信号的周期频率；b)对具有量程指标的设备仪器其被测信号正向最大值不超过仪器量程正向最大值的 80%，且精度控制在
32、0.5%以内；被测信号负向最小值不超过仪器量程负向最小值的 80%，且精度控制在0.5%以内；c)对具有功率等级的设备仪器所提供电压、电流及功率均应满足被测对象要求，且具有不低于20%的功率余量，电流电压精度控制在0.5%以内，10%负载时功率因素大于 98%，阻性负载时T/CSAE 1772021 8 纹波小于 0.1%，10%90%电流上升时间小于 2 ms，当设备发生短路或故障时能够安全及时动作保护。设备选型时应参考对应的设备说明书，结合被测软件的特点，还应考虑以下因素进行选型：a)从自动化扩展方面考虑，PC 上位机搭载上设备所需软件工具后，从其发送指令开始计时，到该信号被实时处理器处理
33、完成并回传截止的时间间隔为 T1，应至少为被测控制器中涉及时间控制描述中最小时间 T2 的 0.5 倍。T1 时间通常与操作系统、工作站性能、软件工具相关，测量条件推荐 CPU 利用率大于 50%；b)I/O 板卡的通道类型及总数根据被测软件的实际情况决定，模拟量大电压采样精度在0.5%，模拟量小电压采样精度在 0.1%。设备性能方面应达到表 1 要求：表1 设备性能要求 通道类型 采样率 输入/输出范围 精度 AI 10 kS/s 大于等于系统设计最大电压 优于控制器的输出精度 AO 10 kS/s 大于等于系统设计最大电压 优于控制器的采样精度 DI 10 kS/s 大于等于系统设计最大电
34、压 DO 10 kS/s 大于等于系统设计最大电压 c)对于 CAN 通讯通常要求：独立高速 CAN 通道，波特率可配置，最高传输速率 1 Mbps，可导入配置的 dbc 文件，通道数量满足被测控制器的网络数量；d)对于 CANFD 的通讯要求：独立高速 CANFD 通道，波特率可配置 401 Mbit/s，最高传输速率 8 Mbit/s，兼容高速 CAN 以及 J1939 通讯。可导入配置的 dbc 或 arxml 文件，通道数量满足被测控制器的网络数量；e)对于以太网的通讯要求：独立高速以太网通道，支持车载以太网物理接口，速率可配置100/1000 Mbit/s，可导入配置符合 AUTOS
35、AR 要求的 arxml 文件，支持 UDP 和 TCP 通讯协议，支持 IPv6 和 IPv4，应用层支持 SOME/IP 和 SOME/IP SD(Service Discovery)，支持配置 E2E 保护协议和 SecOC 协议，Server 和 Client 以及相关服务功能可配置，通道数量满足被测控制器的网络数量；f)程控电源配置：电压范围大于被测控制器的最大额定电压，电流范围满足被测控制器的最大工作电流，具有程控功能。由于车载控制器分类比较多，例如驱动电机控制器、整车控制器、电池管理系统、DC-DC控制器等，不同控制器台架的在环测试设备有所不同，在进行选择时还应在通道数量、信号频
36、率、信号范围等方面进行考虑。4.1.6.3 测试工具软件的要求 4.1.6.3.1 运行测试环境工具的要求 模型环境测试和软件集成环境测试在上位机平台上执行，测试工具软件选取可考虑以下因素：a)自动代码生成，可将常用的软件搭建模型转换为高效、确定且简明易读的 C 语言代码；b)代码覆盖度分析，针对代码执行过程的动态分析，找出从未被执行的代码段。要求自带代码覆盖度分析功能，或留有接口覆盖度分析的工具接入；c)测试机制，能够使用多种测试机制、测试手段对代码进行测试，留有不同的接口可用于模型或代码进行信号连接，构成如 MiL、SiL、PiL 等测试环境；d)代码生成效率，测试工具能够对模型或代码效率
37、进行分析，简化模型和代码的复杂度，通常一个 5 M 大小的环境模型编译时间不应超过 10 min；T/CSAE 1772021 9 e)自动化程度，测试工具的选取应具有一定的通用性和自动化功能，提高测试的效率；f)可扩展性，工具本身预留充足接口便于进行二次开发；g)用于测试的代码情况。由于上位机上开展测试的代码有可能并非完整代码，需要考虑用于测试的这部分代码里是否含有服务层代码，若有则在选择测试软件时应考虑是否应具备将服务层发送的数据转换为信号的功能；h)符合相关的质量标准和功能标准。这一项可根据实施方在这方面的要求进行考虑，如开发流程需要符合特定认证要求，那么需要考虑工具软件对该认证的支持。
38、4.1.6.3.2 测试执行工具的要求 测试设备本身也需要依托于测试上位机的工具软件来开展测试，测试设备的工具软件应至少满足以下要求：a)测试采用的软件应至少支持 Windows,Mac,Linux 等系统中的一种或多种操作系统，支持 C、C+、Python、JAVA 语言接口；b)支持使用可视化的图形建模工具搭建环境模型；c)具备数据分析和环境模型转换为运行代码的功能，具备标准的第三方软件接口。能够满足多任务、多用户的测试开发需求；d)测试软件应能支持实时测试和在线标定、配置和控制 I/O 接口，提供操作界面，实现测试自动化，出具测试报告的功能；e)测试软件应具备多种数据类型格式的实时导入和
39、存储功能，支持向量、数组、结构体等多种形式的数据写入和存储。存储的数据可以进行格式转化和二次开发。4.2 测试实施阶段要求 4.2.1 对测试需求的分析要求 4.2.1.1 条目化 根据功能描述文件进行条目化工作，从文档中将相对独立的功能描述内容提取出来构成一个单独的条目，同时明确该功能的前置条件。4.2.1.2 测试接口 根据功能描述文件与接口描述文件识别条目化后功能涉及的输入接口、输出接口。若两份描述文件由不同组织编写，导致两份文件中接口描述名词不一致的情况，如无法短时间内修正，应在描述测试接口时明确注明该接口所接收的额外信息来源。4.2.1.3 用例设计要求 根据测试目的以及需求本身可能
40、带来的影响，针对条目化的内容逐一编写用例设计要求，在设计时除考虑对测试设计方法选用的要求外，还应按照4.2.2采用对需求进行分类的方式进行测试设计。4.2.2 基于需求的测试用例设计要求 4.2.2.1 一般性要求及分类 在设计测试用例的同时对测试用例进行编号，编号规则需与前端功能描述文档或测试分析文档的编号规则有相似性。测试用例具体测试内容的格式上应包含前置条件、输入变量及预期结果。T/CSAE 1772021 10 测试用例在编写后应进行评审，评审应由对功能了解的开发人员以及编写用例的测试人员共同参与，在评审完成后需及时编写会议纪要进行签批确认，或对于该次会议的评审范围进行当场修改并于一致
41、通过后结束会议。在使用下述测试用例设计要求时，可根据功能本身的功能分类不同来选取采取何种等级的测试用例设计要求。相同的测试条件在不同的功能模块中，根据重要程度不同采用的设计测试方法也不同。本文件将功能分为三类：关键功能，辅助功能，信息采集功能。重要程度的定义如下：关键功能：影响整车安全或能否行驶的功能；辅助功能：影响车辆使用体验（包括驾驶体验）的功能；信息采集功能：人体无法直接感受。在根据测试设计要求设计用例时，对于不常被触发的关键功能，应按照辅助功能进行测试，对于不常触发的辅助功能，应按照信息采集功能进行测试，而对于经常使用的辅助功能应按照关键功能进行测试。目前电动汽车车载控制器软件功能内容
42、，主要可分为以下几类：a)阈值类；b)查表类；c)触发条件类；d)延迟触发类；e)分支类；f)故障类；g)枚举类；h)多状态跳转类；i)迭代控制类；j)公式类；k)配置类。不同测试点应按照输出有效与无效相互交错的方式进行排序，即有效、无效、有效、无效，相互交替顺序执行。测试用例设计质量主要与测试质量目标的达成情况来判断，不应单独使用用例数量、覆盖率、方法应用来进行评判。4.2.2.2 阈值类测试用例的设计方法 应用表2列出的阈值类需求描述设计测试用例。下表2表11中将关键功能简称位关键，辅助功能简称位辅助，信息采集功能简称为采集 表2 阈值类需求描述 描述：AXB 不同重要程度的测试点 关键
43、X 分别取值 A、A+精度值、B、B+精度值、AB 中间值、起作用的 A 的最小值、起作用的 B 的最大值 辅助 X 分别取值 A、A+精度值、B、B+精度值、AB 中间值 采集 X 分别取值 A、A+精度值、B、B+精度值 测试技术及方法 等价类、边界值 T/CSAE 1772021 11 4.2.2.3 查表类测试用例的设计方法 查表类测试用例设计方法包括二维查表及一维查表，以二维查表为例内容见表3：表3 查表类需求描述 描述：二维查表(直线代表表格边界,代表测试的数值点)不同重要程度的测试点 关键 有特征点的也需要选取特征点及其前后的点作为测试点 辅助 有特征点的也需要选取特征点及其前后
44、的点作为测试点 采集 有特征点的也需要选取特征点及其前后的点作为测试点 测试技术及方法 等价类、边界值 4.2.2.4 触发条件类测试用例的设计方法 应用表4列出的触发条件类的需求描述设计测试用例。T/CSAE 1772021 12 表4 触发条件类需求描述 描述 满足条件 1、条件 2、条件 3，即实现某功能，条件之间为逻辑运算符建立联系 以条件 1&条件 2&条件 3 为例 不同重要程度的测试点 关键 1.满足条件 1 且满足条件 2 且不满足条件 3，不实现该功能 2.满足条件 1 且不满足条件 2 且满足条件 3，不实现该功能 3.不满足条件 1 且满足条件 2 且满足条件 3，不实现
45、该功能 4.每个条件都满足，实现该功能 5.确定功能可以重复触发 辅助 1.满足条件 1 且满足条件 2 且不满足条件 3，不实现该功能 2.满足条件 1 且不满足条件 2 且满足条件 3，不实现该功能 3.不满足条件 1 且满足条件 2 且满足条件 3，不实现该功能 4.每个条件都满足，实现该功能 5.确定功能可以重复触发 采集 1.选取任意条件不满足，不实现该功能 2.每个条件都满足，实现该功能 测试技术及方法 MCDC 覆盖、判定覆盖 4.2.2.5 延迟触发类测试用例的设计方法 应用表5列出的延迟触发条件类需求描述设计测试用例。表5 延迟触发条件类需求描述 描述 满足一些单条件或条件组
46、合且持续时间T,实现此功能。当条件为多条件组合与延迟触发条件共同判断时，多条件可合并视为下列的条件 1。不同重要程度的测试点 关键 1.满足条件 1，持续时间T，不实现此功能。2.不满足条件 1，持续时间T，不实现此功能。3.达到前置条件，满足条件 1，持续时间 T1 T，再重新进入前置条件，满足条件 1，持续时间 T2T，在此期间均不实现此功能，其中 T1+T2 T 4.满足条件 1，持续时间T，实现此功能,同时观察在后续的 T 时间内该功能现象未消失或符合预期。辅助 1.满足条件 1，持续时间T1，不实现此功能。2.不满足条件 1，持续时间T1，不实现此功能。3.达到前置条件，满足条件 1
47、，持续时间T1，再重新进入前置条件，满足条件 1，持续时间T1 不实现此功能，其中 T1+T2T 4.满足条件 1，持续时间T，实现此功能,同时观察在后续的 0.5T 时间内该功能现象未消失或符合预期。采集 1.满足条件 1，持续时间T1，不实现此功能。2.不满足条件 1，持续时间T1，不实现此功能 3.满足条件 1，持续时间T，实现此功能。测试技术及方法 等价类、边界测试 T/CSAE 1772021 13 4.2.2.6 故障类测试用例的设计方法 应用表6列出的故障类需求描述设计测试用例。表6 故障类需求描述 描述 满足条件 1（或为组合条件）则触发故障。不同重要程度的测试点 1.不满足条
48、件 1，故障现象未触发。2.满足条件 1，触发故障现象。3.恢复故障。4.再次满足条件 1，触发故障现象。测试技术及方法 等价类、强度测试 4.2.2.7 枚举类测试用例的设计方法 应用表7列出的枚举类需求描述设计测试用例。表7 枚举类需求描述 描述：X 信号有 N 种输入值，之后导致 Y 信号有 3 种及以上的输出值或组合 不同重要程度的测试点 关键 1.测试 X 信号的 N 种输入值 辅助 1.测试 X 信号的 N 种输入值 采集 1.将 Y 信号的输出情况列出 2.测试每个输出的其中 1 个有效等价的 X 输入值 测试技术及方法 真值表、等价类 4.2.2.8 多状态跳转类测试用例的设计
49、方法 应用表8列出的多状态跳转类需求描述设计测试用例。表8 多状态跳转类需求描述 描述 2 个及以上的状态描述，且存在状态跳转路径的情况 不同重要程度的测试点 关键 1.将状态转换为状态树 2.按照 MCDC 以及路径覆盖的方式编写测试用例，若条件中存在非布尔型的输入量，则还应按阈值类测试中关键的取值方式覆盖取值 辅助 1.将状态转换为状态树 2.按照 MCDC 的方式编写测试用例，若条件中存在非布尔型的输入量，则还应按阈值类测试中辅助的取值方式覆盖取值 采集 1.将状态转换为状态树 2.按照判定覆盖的方式编写测试用例 测试技术及方法 状态转换、等价类、边界测试、MCDC 覆盖、路径覆盖、分支
50、覆盖 T/CSAE 1772021 14 4.2.2.9 迭代控制类测试用例的设计方法 应用表9列出的迭代控制类需求描述设计测试用例。表9 迭代控制类需求描述 描述 迭代控制变量 不同重要程度的测试点 1.操作 1 获得该变量的值并记录 A 2.操作 2 基于记录的值 A 获得记录值 B 3.操作 3 基于记录值 B 获得记录值 C 4.清除该记录值（根据具体情况验证）重新重复 1、2 测试技术及方法 状态转换 4.2.2.10 公式类测试用例推荐的设计方法 应用表10列出的工时类需求描述设计测试用例。表10 公式类需求描述 描述：以数学公式的方式给出的需求，有 N 个变量作为输入 不同重要程