前面很多嘉宾提到了，在软件定义汽车的大背景下，软件的代码复杂度越来越高，这种情况下对软件测试的重视度也需要进一步提升，这样才能确保我们的软件质量，甚至整个汽车的质量是可被信赖的。今天的分享分这四个部分。

首先我们来看一下端到端的软件测试流程；

第二块是功能安全软件测试的最佳实践；

第三块是客户案例概览；

最后为公司做个小广告。

第一部分关于软件测试流程，在谈流程之前先统一一下软件测试的定义，它是软件分析的过程，去检测存在的软件和需求的差异，并且去评估软件的功能，这里的差异就是所谓的Bug，所以我们的软件测试并不是证明软件没有Bug，而是要发现bug的存在。

这个是汽车行业最为经典的V字型开发流程，我所展示的这个比较朴素的版本则是来自于中国的功能安全标准34590-2022版中，第6部分的软件层面产品开发阶段参考模型，大家对于整个流程应该都很熟悉，我就不再一一介绍，但是对于软件测试部分稍微展开一下。在完成开发之后我们会做软件单元测试，这块其实是去检查我们的软件是否对应到软件单元设计文档的，所以单元测试与单元设计文档之间存在着这样的映射关系，完成这步之后做软件集成测试，这里是我们要去检验我们的软件是否符合软件架构的设计，包含我们的模块间接口是否符合预期，我们的模块调用关系等等是否符合预期，完成这部之后要做嵌入式软件测试，这里更多的是验证我们的软件在目标的嵌入式是否符合预期，最后做系统测试，看我们开发完的系统与系统需求和系统架构是否匹配，跟我们的产品需求是否一致，也是这里所强调的一一对应关系和可追溯性决定了我们的流程不是一字型开发流程，而是V字开发流程，所以这是保证我们软件质量的很重要的流程。

具体到软件测试，从流程的角度先做软件单元测试，再做软件集成测试，最后做嵌入式软件测试，但是这几步会用到这些方法，包含代码的静态检查，代码的动态测试，如果是基于模型开发的话还要做基于模型的测试，最后是软件故障注入测试和资源使用量测试。

对于代码的静态检查要做编码规则检查，代码质量的度量，要做语义检查，在不运行软件的情况下确保软件可以满足相关规则和要求。

代码动态测试涵盖了代码的单元和集成测试，要测量它的结构化的覆盖率，不管从语句覆盖，MC/DC等等都能符合我们的要求和标准。

基于模型的开发方法也是汽车行业主流的开发方式，对于模型的测试是往往容易被忽视的，模型测试需包含模型的动态、静态和背靠背测试三个环节，对于背靠背测试，重点则是对比模型和代码在同样测试用例下的表现是否一致。

对于软件故障注入测试，这是被功能安全标准所建议或者要求的，但又是我们容易忽视的部分，这里需要结合功能安全分析来识别可能的故障来实现全局的故障注入，最后检查故障的识别和处理机制是否符合我们的预期。

对于资源使用量的测试，我们希望在目标的嵌入式硬件下实时的检测，希望CPU、内容和任务时序等均在安全的范围内，这样才能确保我们的软件在最终的实车表现中可信赖。

接下来我们来看一下第2部分，对于代码的静态检查和代码的单元测试，代码的集成测试和软件故障注入测试，我们将结合实际客户案例来做一些分享。

首先是代码的静态检查，这里我拿的是燃料电池控制器的例子，首先定义一下规则集，既有MISRA C规则集，也有FCU规则集，最后在经过了双方的专家团队评审后明确了84个FCU规则集，对代码进行静态检查。我们要测试的软件一共包含13个模块，最后完成迭代也有7万行代码，一共进行了4次代码的静态检查，大家可以看到第一次静态检查查出了12000多个违背项，每行代码是0.45个违背项。到第二次降低到了1800多个违背项，所以说在测试过程当中我们的开发团队是在一直持续解决违背项的，从这些结果可以看到我们的代码质量是有了大幅度提升的，最后做第四次静态检查时，违背项降到2300个，但是过程中因为涉及到了代码的持续更新，所以它其实还是有产生新的违背项的。在这4次的静态检查过程中我们的团队进行了13次迭代，第4次检查前我们更新了很多新代码。在这个过程当中软件开发团队持续提升了开发能力本身，也包含了对FCU规则集的理解。所以我们不希望代码静态检查流于形式，而是希望它既可以提升软件质量，也可以提升软件开发和测试团队对软件质量的理解，将质量意识融入到团队甚至企业的基因之中。

二是软件单元测试。国内有专门的单元测试团队来做这部分测试的并不多，大部分是开发团队做自测而已，这种情况下质量是没法保证的。从我这边展示的这个例子可以看出，我们首先第一次单元测试分支覆盖率达到99.4%，发现20个错误，这样合下来是4.9乘以10的负4次方个错误每行代码。第二次单元测试分支覆盖率是99.55%，降到了5个错误，然后到第三次我们的分支覆盖率达到99.9%，MC/DC覆盖率达到99.28%，有4个错误，也就是0.96×10的负4次方个错误每行代码。总的说来，代码的错误数量和密度都逐步下降了！

接下来是FCU软件集成测试。从需求出发设计了45个测试场景，对应的开发了相关的测试用例，在Controller Tester这个动态测试工具当中执行了整个测试，测试结果有跟需求当中提取的期望值做对比，确保我们的测试用例可以回溯到需求，然后分析一下需求覆盖率和函数调用覆盖率是否符合预期，最后测出来80个错误，最常见的错误是代码实现与需求是不匹配的。

接下来是关于软件故障注入测试的必要性及方案。从功能安全标准来看，不管从系统和软件部分都有对故障注入提出要求，而且根据不同的阶段和不同的ASIL等级，有的是建议，有的是必需，所以软件故障注入测试是一定要做的。在我们这里用的是一款FIT工具，这个工具本身也是过了功能安全认证的，这个工具是我们的合作伙伴在过去20多年的开发和测试经验当中逐步迭代出来的一款工具，其实这个工具里本身提供了一些基础的软件故障模式，我们也可以自定义故障，从功能安全角度分析一些新的故障模式，这些故障模式可以在软件中通过配置去补充到基础的故障测试用例当中，最后实现软件故障的测试。这里我们推荐软件故障测试在更真实的电子电器的环境当中也就是HiL台架上来进行测试。

对于这个软件故障注入测试的具体流程，首先我们是需要对被测的MCU架构进行分析，把我们的FIT的库与被测软件集成，确保FIT工具可以运行起来，然后在FIT中运行所有的测试用例，最后获取所有的结果评估整个功能安全的设计是否有被实现。

这里我们再快速看一下我们的客户案例的分布，只强调两点，第一是这些案例涵盖了整个V字型开发流程，第二个是我们的案例涵盖了不同类型的汽车电子控制器，大家有任何需求都可以找到我们做进一步的沟通。

最后3分钟时间给公司做个广告，首先我们公司是IAE智行众维，是专注于智能网联仿真测试的企业，涵盖全套的仿真测试解决方案。基于软件定义汽车这个大背景下，今年在中国汽车工业协会、上海汽车城和上海智能汽车软件园的领导们的关怀与支持下，成立了一家新的子公司叫上海智测众维智能科技有限公司，希望能够从软件测试领域出发去更好的助力整个行业的发展。我们的业务核心是软件测试工具链和软件测试服务，但是我们也提供围绕功能安全、信息安全、预期功能安全以及ASPICE流程的认证服务和咨询服务、培训服务。

我们的软件测试工具链涵盖了代码级到系统级的完整的测试工具链，包含代码的静态测试STATIC工具，代码的动态验证CONTROLLER TESTER，到系统级的覆盖测试工具COVER，再到模型的静态MODEL INSPECTOR，模型的动态MODEL VERIFIER。再到面向功能安全的软件故障注入工具FIT，做资源使用量监控的PROV，这是我们整个的软件测试工具链的图谱，大家都任何需要都可以跟我们联系。

　　（注：本文根据现场速记整理，未经演讲嘉宾审阅）

一、软件定义汽车的含义

现在是软件定义汽车的时代，关于软件定义汽车的含义前面各位专家已经做了很多介绍，这里不再赘述。从软件测试的角度来看，软件定义汽车带来的是整个产品开发价值链、价值流的重构。在这个过程中，我们既需要有新的开发工具和开发平台，在验证体系层面也需要做出相应的技术创新，我们需要有新的方法、新的工具链体系，有新的技术架构来支撑新的发展趋势。既要满足功能安全“V”字型开发流程的要求，同时又要满足开发过程中，各个环节上快速迭代上的需求。

软件定义汽车时代，同时也是电动化和智能化的新时代，对于软件开发来说新的挑战有很多，比方说代码数量从原来的千万级增加到亿行，很快会到若干亿行代码的级别。这个过程中对仿真测试手段，对我们如何去验证、确认它的质量，也提出了新的挑战。

这既有技术上的挑战，从市场角度也是一个很好的机遇，根据不同口径的统计数据，在2020年围绕软件相关的测试已经达到了百亿美元的市场规模，并且以后每年还会以很高的复合增长比在增长。这对新技术、新方法有很高的要求，根据不同口径统计，软件在整个新的智能化、电动化汽车开发中的成本比重，正在从10%增加到50%。测试验证确认工作的成本比重也会占到三分之一以上，这就要求我们在新的趋势下研发、打造一套科学有效的技术体系，来支撑这一进程。

二、仿真测试工具链体系构建

在这里和大家分享我们的探索和思考。从软件测试的角度来讲，我们面临从代码到单元，从单元到系统，还包括从系统到整车，软件的测试是覆盖产品的全生命周期，甚至包括OTA升级之前很多关键功能的验证、很多场景的测试也需要覆盖到。这过程中需要考虑功能安全、信息安全、预期功能安全，需要什么样的体系支撑测试验证和确认的过程，这是我们要考虑的。

我们从两个层面开展相应的工作，一个是从端到端的软件测试，从基础层需要有一套完整闭环的工具链体系，针对静态的代码检查、动态代码测试、模型测试，以及基于嵌入式开发所需要的故障注入模拟、资源占用测试等一系列，我们需要有先进的自动化的工具手段来提升整个验证过程的生产力。这里我们需要开发一系列的工具，通过自动化的手段来提升生产研发的效率。在智能化和电动化新的趋势下，我们仅做基础层的测试是不够的，因为和传统的汽车开发，和传统的电子电器开发相比，我们所要测试的测试用例的数量会面临从百和千的量级，到百万和千万，甚至更高比例的跃迁。

在这个新的形势下，前面有其他专家也提到过，我们面对智能驾驶，面对各种不同层级智能化的需求，我们需要的测试用例数量已经不再是以往做控制器级别测试的时候几百几千的概念了，而是面临自然驾驶环境下看起来甚至是无穷无尽的自然驾驶的场景。我们的测试用例将会以仿真测试的场景来体现，这个过程将覆盖整个研发的全流程，从需求提出到最后实车的验证，是一个连续测试的过程，我们对于算法、软件、质量的检查是从代码到软件到模型到控制器到实车是连续的，并且以海量的场景、数据来驱动的一个过程。

我们需要研究的是发掘在新的场景、新的背景下，我们要构建一个什么样的技术体系来持续支持在产品力上的提升，在软件质量上的保障和创新。对比传统的软件开发和传统的电子电器开发，我们会发现，围绕一个大的“V”字型的框架，我们在研发的不同阶段，和传统的汽车软件、控制器开发将会新的变化，这里主要列举了四点。

第一，当前的测试不管是针对软件本身，还是针对嵌入式芯片、控制器，还是整车，我们面临的测试用例，在数量上会有万，甚至更高量级的提升。我们需要有合适的路径构建足以支撑测试覆盖性和多样性所需要的海量场景，这是一个巨大的变化。

第二，也是因为有海量的测试用例和测试场景的需求，传统的基于线下、单机，或者基于实际道路的测试，效率或者说加速性远不足以满足我们当前的需要，我们需要AI技术、海量的算力支持在云端有百千万甚至更多的并行测试，来完成场景的覆盖和验证。

第三，不论是基于域控还是中央计算平台架构，我们对芯片的功能需求，对芯片的算力，包括嵌入式开发提出了新的需求，这是我们传统电子电器测试的时候，针对控制器测试时候没有的，针对芯片、处理器在环，也是新的场景下软硬一体测试的新需求。

第四，当前智能化、电动化车辆及软件开发流程里，智能化车辆在上路之前，我们在传统的测试环节里缺失实车在环或者说实车闭环测试的环节。针对智能化算法和软件开发的海量测试用例和场景，我们通过对可能危险场景的覆盖和筛选，类似于AI从深度学习到强化学习的过程。在实车测试环节我们需要搭建闭环测试能力，来对感知、控制决策，包括针对各种非理想天气、恶劣天气，对算法和软件功能设计，对是否有bug完成相应的测试验证。

从海量数据驱动到云算力仿真，到芯片处理器在环，到实车在环这样一个闭环测试的流程，共同构建了面向智能化、电动化车辆新时代，为保障软件质量，一个闭环的仿真测试体系，这里我们把它称之为“X-in-loop”。

进一步，在智能化的时代，我们也在做一些研究，目标是什么呢？希望打通从基础层到刚才介绍的功能层测试之间的壁垒，我们希望在软件测试，在软件质量检查过程中，能够全面覆盖从代码本身到应用层、功能层所做的工作，把它们链路给打通。这里我们做的探索，是把软件的故障注入模拟，资源占用检测等工作，和面向场景的仿试结合在一起，这块后面我们有一个具体的案例和大家分享。

三、行业应用实践

构建从基础层到功能层闭环测试体系，这里有五个具体的例子。

第一，我们基于ISO26262功能安全测试体系，针对车辆不同的控制器，对软件代码、控制器所做的测试实践汇总。这是大家比较熟悉的，服务于新能源智能化汽车，围绕电池、电控、电机，包括围绕智能化，对各类控制器的测试。

第二，从功能安全到预期功能安全，很大的区别，就是测试用例所需覆盖的场景是海量的，基于此我们构建了服务于预期功能安全测试的海量场景数据库，这个场景库涵盖了自然驾驶、法规、标准，同时数据既来源于逻辑的构建，来自于车端的采集，也来自于上海汽车城、苏州高铁新城路侧端设备采集的车路协同数据，所共同构建的仿真场景库，目前整个场景库已经涵盖了围绕辅助驾驶到自动驾驶所需的各类不同场景，目前最新的数据量大概有超过2万组不同的仿真场景可以实际服务于仿真测试和训练。

第三，通过云算力仿真测试的手段，服务于自动驾驶算法和软件安全验证。右边展示的是实践案例，在苏州针对高级别无人驾驶的算法安全验证，打造了一个基于云算力仿真的无人车驾校，我们通过云算力仿真的高效率和海量的场景，完成自动驾驶在上路测试和示范应用之前的安全验证。通过无人车驾考我们可以发现可能存在的安全隐患。为了进一步找到到底是功能设计上还是软件质量上的问题，还需要相应闭环测试和软件测试的手段，最终找到问题的症结所在。

第四，我们在致力打造从芯片处理器在环到实车在环、软硬结合的仿真测试手段，来做算法、软件质量的检查和确认。这里需要一提的是，围绕实车在环技术，我们今年也做出了重大突破。原有的实车在环测试的高级实现方式是基于实验室和单车，即高级整车在环实验室，我们今年开发出了称之为“协同式高级整车在环”的仿真测试技术，把位于不同实验室，不同城市，甚至不同国家的车辆在环仿真测试平台，在共同的仿真场景下进行协同仿真，实现高复杂度、高真实度的对抗测试。这也是智能驾驶算法和软件在商用落地之前真实参与对抗测试最有效的支撑手段。目前以高级整车在环为代表的IAE仿真测试产品已在一汽、上汽、招商车研等客户投入使用，招商车研的实验室正服务于赛力斯等企业，做了很多的实际的测试验证工作。

第五，我们把软件故障模拟和硬件在环、处理器在环、实车在环结合在一起，针对ECU，针对自动驾驶或者辅助驾驶软件所开展的测试。传统做软件故障注入模拟的时候，很多时候仍然需要实车在道路上跑，这对于安全性依然是挑战。我们推动在实验室里，在台架上，把软件的故障注入模拟和基于场景的仿真结合在，能够让安全测试更加安全。

以上就是此次和大家的分享。IAE智行众维通过打造X-in-Loop仿真测试技术体系，水木灵境仿真场景数据工场，通过技术闭环和数据驱动，服务于软件定义汽车。同时，我们公司位于苏州高铁新城和上海汽车城的创新港，尤其软件测试板块的总部就在汽车城创新港，也希望后续和大家有更多的互动和交流。

非常感谢大家的时间，谢谢。

（注：本文根据现场速记整理，未经演讲嘉宾审阅）

作为江苏省首批智能网联汽车高质量发展先行区和数字交通示范区，相城近年来已集聚超260家智能车联网相关企业，产业链已覆盖30余个细分领域，在自动驾驶核心算法、新型传感器、线控底盘、域控制器等领域形成了一批头部企业和代表性产品，已成为长三角地区最具活力和影响力的产业发展高地。

天翼交通由中国电信、中智行和先导产投联合组建，定位是面向自动驾驶的国家级智能交通运营及服务商。IAE智行众维^?主营领先的智能驾驶仿真、测试与验证技术平台，是国内可提供智能驾驶仿真测试与验证全栈式解决方案的公司。

在天翼交通，张伟参观了企业展厅，详细了解了其技术路线和项目成果，勉励企业进一步利用资源优势，在团队建设、技术方面形成强大竞争力，建立健全商业化运营模式，争做领域内龙头企业，带动相城智能车联网产业向纵深发展。在智行众维，张伟与企业负责人举行座谈，深入了解了其技术优势和产业布局，希望企业进一步把握发展机遇，持续精进前沿技术，主动拓展国内国际市场，争做细分赛道的领头羊。

区有关板块、部门相关负责人参加活动。