转载声明：文章来源：https://blog.csdn.net/m0_46144994/article/details/123729364

前言
自动驾驶系统测试新手入门必须了解的职责、测试流程、测试用例设计方法、测试内容及关注点

一、概述

1.角色
测试人员：负责测试用例设计，测试执行，登录和验证Bug
测试负责人：负责对测试人员登录的Bug进行确认，以及对Bug进行统计分析和评价，评审测试用例
PSM：参与测试用例评审，跟踪Bug状态
开发人员：参与测试用例评审，修改Bug

2.入口标准
集成冒烟测试结束，软件系统测试启动

3.输入
软件功能式样书及引用附件，附件包含但不限于：
1.诊断调查表
2.网络管理规范
3.CAN信号矩阵
4.Coding规范
5.标定流程
6.升级流程
法规&标准（JT/T、GB、GB/T、ISO）

4.输出
软件系统测试用例
软件系统测试报告
BUGlist

5.出口标准
软件系统测试活动结束
测试用例执行覆盖率100%
系统BUG数为0

二、测试过程

1.总览
测试流程总体如下：

2.需求分析
依据规格人员提供的《软件功能式样书》，确定软件实现的功能，识别软件测试点。在需求分析的过程中，如果有不理解的功能点，应第一时间与规格人员沟通反馈，明晰测试需求。理解功能需求是编写有效测试用例的前提。

3.制定测试策略
根据《软件功能式样书》及版本Release Note评估测试工作量，决定采用的测试方法和测试范围。在满足按时交付和保证质量要求的前提下，合理安排测试所需的人员及测试周期。
(1).确定被测试对象和测试范围
(2).评估测试工作量
(3).确定角色分工和工作任务
(4).标识出测试各阶段的时间，任务，约束等条件
(5).考虑一定的风险分析及应急计划
(6).考虑和准备测试工具，协调测试仪器等测试资源，搭建测试环境
(7).定义测试完成标准

4.测试用例编写
根据《软件功能式样书》及引用附件，设计测试用例。

5.测试用例评审
测试人员完成用例编写后，需组织测试用例评审，参与评审的人员至少应包括测试负责人、开发人员及PSM。评审的形式可以是邮件评审，也可以是会议评审。评审人根据《软件功能式样书》及引用附件，结合以往项目的测试经验，对编写完成的测试用例进行评审，同时被评审人应记录汇总评审意见，生成测试用例评审记录表。

6.测试用例修改
评审测试用例如果出现错误或者测试用例不全以及式样变更要对原有测试用例进行修改和添加。测试执行中发现BUG后，开发人员修改BUG，程序的逻辑、结构等可能会影响之前测试用例时，需要根据当前版本程序，修改受影响的测试用例，满足当前程序测试的需求，并在测试用例文档的变更履历中简述修改内容。

7.测试用例执行
测试人员执行手动或自动化测试用例，对被测控制器进行验证。

8.提交BUG
发现程序中的BUG后，登录Bug管理工具，对BUG问题进行描述，选择测试负责人提交BUG。

9.输出成果物
完成测试后，将测试用例、测试报告等相关资料，上传至服务器，并通过邮件通知项目所有成员。

10.漏出BUG分析
项目测试过程中，不可避免地会漏出个别BUG到客户侧。对于这类问题，应给予充分的重视。在问题发生后，应及时地进行详尽的复盘总结，分析BUG漏出的原因，制定再发防止策略，并延展到其他项目上，形成问题分析报告。

三、测试用例设计方法
设计测试用例的主要依据是软件功能式样书、诊断调查表、标定规范及CAN信号矩阵 。另外，国标和平台测试用例也是在设计测试用例时的重要输入。在设计测试用例时，会按照式样书中规定的功能类型来划分用例的功能分类，再运用常用的测试用例设计方法和以往测试的经验来详细设计每条用例；常用的测试用例设计方法如下：
1.文档转化法
将式样书中所有的文字信息、示意图、流程图、状态图，所有项目需求达成的共识，以及需求确认的邮件沟通信息，直接转成测试用例。
2.等价类划分
将被测项按照式样书的条件项划分为若干个等价类，从等价类中选出一个测试用例，如果这个测试用例测试通过，则认为所代表的等价类测试通过，这样就可以用较少的测试用例达到尽量多的功能覆盖，解决了不能穷举测试的问题。
例如在CANmini信号验证测试中，用例不能覆盖信号所有的值，所以需将信号的值划分为几个等价类，来覆盖信号的取值区域。
3.边界值法
在测试取值类型为数值型的测试项时，若输入文档规定了取值范围，则选择恰好落在取值范围边界上和处在边界内、边界外的测试值来设计测试用例。
式样书中描述：“若自车车速达到启动车速，则系统进入ready状态，启动车速为60km/h”
1）车速从0加速到59，状态机为passive
2）车速从59加速到60，状态机为ready
3）车速从60减速到55，状态机为ready
4）速度从60减速到54，状态机为passive
4.场景设计法
在设计实验室测试用例时，会在用例中设计通过模拟工具和硬件设施来模拟事件触发时的情景，使测试用例更容易理解、更具说服性，最大的降低因实验室环境的不全面导致的用例设计错误。
例如：在版本稳定性验证的测试中，由于资源有限，不能使控制器在实车上长时间持续运行，需要在实验室使用实车版本的控制器，使摄像头对准实车录制的视频或可导致功能触发的静态图片进行验证。这样能在实验室尽可能的模拟控制器在实车场景中的运行状态。
5.错误推断法
根据以往的测试经验，在被测系统中容易出现Bug的功能点上有针对性地编写对于这些Bug的测试用例。
例如在DTC测试中，以往测试时平台配置这部分容易出现问题，所以在设计用例时会分别添加配置自动挡和手动挡丢失部分信号而产生的不同结果。

四、测试内容及关注点
ADAS软件测试按发布版本特性可分为全功能测试和变更点测试，按测试内容可划分为信号验证测试、网络通信测试、诊断测试、升级测试、Coding测试、标定测试、ADAS功能测试及系统稳定性测试。测试责任人在测试发布版本时应按照版本特性安排测试内容，并在测试相应内容时需要分别注意各个测试内容的不同关注点。

1.信号验证测试
信号验证是依照CAN矩阵和DBC文件，对实车、控制器和CANmini工具所发出的信号进行验证的过程。测试中需确保所有的信号有效，且能与CAN矩阵和DBC文件的信号一一对应。
2.网络通信测试
网络通信测试是按照项目的通信文档和软件功能式样书而进行的测试，目的是为了验证控制器单节点通信是否正常。具体包括控制器产品的电压、诊断电压、CAN线短接、通信延迟、负载率、鲁棒性和采样点等测试项。网络通信是反映控制器品质和性能的重要指标，因此在测试过程中应详细准确记录各项通信数据，以保证控制器的品质。
3.诊断测试
诊断测试的测试用例是依据项目的诊断调查表编写的，具体分为诊断服务测试，DTC测试和DID测试。诊断服务测试对应测试控制器对各项诊断服务的支持情况、一般在测试前需要根据诊断调查表使用CANdelastudio工具编写.cdd文件，测试时通过CANoe.Diva工具生成自动化测试工程，导入CANoe中运行诊断自动化测试，而对于自动化用例中覆盖不到的内容，通过执行手动测试用例进行测试。DTC测试则要通过对控制器的一系列故障操作和DTC自动化工具实现信号异常，来测试控制器对DTC的支持情况。DID测试则是使用DID读取工具读取控制器的DID，判断是否能跟诊断调查表规定的DID相对应。
4.升级测试
升级测试包括实车升级测试和实验室升级测试。实车升级测试是把控制器接到实车环境中使用升级工具和实车升级文件，进行多次的升级并对升级过程以及升级后的控制器运行情况进行监测的测试。而实验室升级测试则需要使用回放版本及实车版本（需要在实验室升级验证后再到实车上升级）的升级文件进行同样的升级测试。在升级过程中应关注是否产生因升级中断操作和连续的升降版本操作而导致的升级失败或无法继续升级。
5.Coding测试
Coding测试是依照车厂提供的车身参数摄像头参数、雷达参数、车型配置参数以及式样中的控制器参数，使用Coding工具测试是否能够成功读写控制器改变的各项参数。主要关注Coding参数是否生效，及因Coding参数改动对标定或其他功能造成的影响。
6.标定测试
标定是根据标定规范对控制器的摄像头进行参数校正。包括下线标定、售后静态标定和售后动态标定，下线标定在实验室的验证方式为使用回放标定图片和下线标定工具进行标定；实车下线标定的验证方式为在摄像头前方按照标定规范所规定的距离竖立标定板，再通过下线标定工具进行标定。售后静态标定一般在实验室的验证方式为通过回放动态行驶视频和动态标定工具进行标定：售后动态标定的验证方式则为在满足售后标定要求的道路上以规定的速度行驶并使用售后标定工具进行标定。标定过程中需要关注标定流程，标定完成后需要关注标定状态及摄像头参数（标定的目的是否达成）。
7.电源变动测试
电源变动测试是将控制器的主线束中ACC和BATT分别接到两台可编程电源（编号为WJ002595和WJ002594）的正极上，GND接到其中一个可编程电源的负极上，通过同时变动两台可编程电源事先烧写的波形程序来测试在特殊波形下控制器的通信诊断和功能是否会保持正常。在测试电源变动时应确保两台可编程电源运行的波形程序保持匹配且同时改变。
8.暗电流测试
暗电流测试的过程是使用台式万用表接到控制器线束的BATT和GND上，检测控制器在关闭状态时产生的微弱电流，该电流数值必须低于式样中规定的暗电流最大数值，从而避免因控制器产生的暗电流过大而对整车其他系统或元件造成影响。
9.ADAS功能测试
根据软件功能式样书和国标规定针对控制器产品的ADAS功能进行设计和执行，通常包括HIL测试、实验室回放功能测试和实车测试。HIL硬件在环测试是通过适配车辆动力学模型、搭建仿真工况，满足测试环境的需要，从而对产品功能进行闭环测试验证，另外能够对部分测试用例实现自动化测试；实验室功能测试主要是通过模拟实车的信号输入和回放视频来进行实车无法做到的精确值和危险行为测试，因此测试人员需要关注测试项相关的所有信号；而实车测试主要是针对实车环境来进行测试，并且需要在实车上对实验室测试的结果进行验证，以确保测试ADAS功能的有效性。
10.系统稳定性测试
此部分测试目的在于验证控制器在长时间运行的情况下是否会出现性能下降及死机等问题。系统稳定性测试时需要使用实车版本控制器，通过实验室环境使其在功能触发的条件下运行7×24H，并在运行时连接串口线抓取log。如果出现死机等问题需要将log提供给相关的开发人员分析并在问题修正后进行持续跟踪验证。

总结
以上内容可以为新进入自动驾驶系统测试的工作人员及相关教研人员提供参考，部分内容来源于网络，仅供参考。