整车厂自研软件的测试

摘 要：随着智能汽车的快速发展，越来越多的整车厂涉足控制器软件开发，甚至完全自研。因此，整车厂传统验收性测试如何同步跟进、扩展到软件开发性测试，对软件质量的提高非常重要。将组件测试、组件集成测试、软件合格性测试3 项测试内容从供应商划到了软件自研测试的整车厂，打破了以前的软件开发仅单一地使用1 种或2 种测试方法对软件进行测试的局面。在测试过程中，须确保软件组件测试、组件集成测试以及软件合格性测试与软件自研开发的良好配合，并梳理各个测试级别的细节，合理分配资源。结果表明，采用这种方法，可以很好地完成整个开发V 流程右侧各个阶段的测试验证工作，并形成完整的汽车软件全栈自研。

0 引言

大众集团首席执行官赫伯特·迪斯曾在2020 年披露：“几乎没有一行软件代码来自我们自己的团队。”该公司估计，大众汽车90%的软件是由数十家供应商负责开发的。如此多的软件供应商，每家都有自己的开发方法，甚至是不同的操作系统和开发语言，这无疑增加了后续集成的复杂性，特别是在后续测试验证和迭代方面[1]。目前，越来越多的汽车制造商也意识到，将软件和电子产品外包给供应商，然后再进行集成的传统模式已不再适用。整车厂只负责提需求、验收、集成装配的传统思路已经跟不上这种智能化网联化汽车的发展了。

中国车企的软件自研最初是从互联网转行到汽车行业的那几家造车新势力开始的，因为这几家企业原本就是做软件的，这也是他们相较于传统整车厂的优势。随着车辆智能化、网联化的逐步深入发展，软件定义汽车已经成为行业共识。越来越多的整车厂不满足于把软件开发完全交给供应商，不满足于只收到黑盒的软件交付，正逐步建立软件白盒开发的能力,或者要求零部件厂商把整个原代码打开，以白盒交付。中国车企几十年的造车经验大部分集中在硬件上，而复杂的软件目前变得越来越重要，通过对计算机软件的功能和性能进行不断的优化，可提升计算机软件的适应性、可靠性和安全性[2]，是整车厂亟待同步建立的能力。

1 相关研究

目前，Automotive SPICE（简称A-SPICE 或ASPICE）是汽车产业的软件流程改进和能力测定标准，基本上是汽车产业软件开发过程的默认流程标准。根据ASPICE[3]，组件和系统的开发测试是分开的，其实这也可以看作是传统供应商和传统整车厂在软件开发测试上的分工，组件由供应商去开发和验证，系统由整车厂来集成。当整车厂进行软件自研后，从组件到系统的开发和测试就都落在整车厂了。同时，从供应商划到软件自研测试整车厂的还有组件测试、组件集成测试、软件合格性测试这3 项测试内容，如图1 所示。

图1 整车厂软件自研与测试的下移

2 测试方法

组件测试（也称为单元或模块测试）关注可单独测试的组件，如图1 所示，是软件开发V 模型右侧验证的开端，很多时候是和代码开发同步迭代进行的，所以组件测试由软件开发人员来完成。在组件测试中，开发人员通常使用自己的开发环境进行测试，尽早识别和修复潜在的缺陷。软件单元验证过程的目的是验证软件单元，以提供软件单元符合软件详细设计和非功能性软件需求的证据。

组件测试的典型对象包括组件、单元或模块，代码和数据结构。组件测试可以包括功能特性（例如计算的正确性）、非功能特性（例如查找内存泄漏）和结构特性（例如判定测试）。组件测试发现的典型缺陷和失效有功能不正确（例如不符合设计规格说明中的描述）、数据流问题以及代码和逻辑不正确[4]。

组件测试一般采用静态测试和动态测试相结合的方法[5]。

2.1 静态测试

静态测试是指被测试程序不在机器上运行，而采用人工检测和计算机辅助静态分析的手段对程序进行检测。静态测试包括对文档的静态测试和对代码的静态测试。对文档的静态测试主要以检查单的形式进行，而对代码的静态测试一般采用桌前检查（deskchecking）、代码走查和代码审查的形式。静态测试技术不需要执行代码，只须通过手工检查（评审）或自动化分析（静态分析）的方式对代码或者其他的项目文档进行检查。经验表明，使用这种方法能够有效地发现30%～70%的逻辑设计和编码错误。

几乎所有软件都可使用静态测试（评审\静态分析技术）进行检查，在软件生命周期的早期阶段进行评审并发现和修改缺陷（例如发现需求中的缺陷）的成本会比在动态测试中才发现并修改这些缺陷的成本低得多。通过评审也可以发现一些需求遗漏项或者不合理项。静态分析可以确定不正确的模块化的代码、组件可重用性差的代码以及难以分析和修改的代码而不引入新缺陷，而这些在动态测试中是很难或者不能被发现的。静态测试在尽早发现和修改缺陷、改善开发能力、缩短开发时间、缩减测试成本和时间、减少产品生命周期成本、减少缺陷等方面都发挥了重要的作用。

2.2 动态测试

动态测试须借助软件测试工具，参与程序的运行[6]，通过比较运行结果和预期结果之间的差距来确定程序中是否有缺陷和错误[7]，一般采用白盒测试和黑盒测试方法。

白盒测试也称为结构测试，从内部结构与逻辑出发，结合覆盖标准进行覆盖测试，属于穷举路径测试[8]。另外，使用静态测试的方法也可以实现白盒测试[9]。例如，使用人工检查代码的方法来检查代码的逻辑问题，也属于白盒测试的范畴。白盒测试方法中，最常用的技术是逻辑覆盖，即使用测试数据运行被测程序，考查其对程序逻辑的覆盖程度。主要的覆盖标准有语句覆盖、判定覆盖、条件覆盖、判定\条件覆盖、条件组合覆盖、修正的条件\判定覆盖和路径覆盖等。

黑盒测试也称为功能测试，从用户的角度出发，着重于输入和输出，根据需求规格查看是否有功能、界面以及明显的性能方面的缺陷[10]。黑盒测试将程序看作一个不透明的黑盒，完全不考虑（不了解）程序的内部结构和处理算法，而只检查程序功能是否能按照需求定义正常使用、程序是否能适当地接收输入数据并产生正确的输出信息、程序运行过程中能否保持外部信息（例如文件和数据库等）的完整性等。黑盒测试根据规定的功能来设计测试用例，一般包括等价类划分、边界值分析、判定表、因果图、状态图、随机测试、猜错法和正交试验法等。

静态测试可直接发现软件工作产品中的缺陷，而动态测试是在运行软件时识别由缺陷引起的失效。相比于静态测试，动态测试要付出更多的工作量才可以找到缺陷。

3 组件集成测试

组件集成测试将单元测试过程中构造的桩模块、驱动程序或全局数据用实际部件和实际全局数据替代，逐步将部件集成为较大的部件。组件集成测试通过模块间的交互作用和不同人的理解和交流,更容易发现实现上、理解上的不一致和差错[11]。组件集成测试的目标包括减少风险、验证接口的功能和非功能行为是否符合设计和规定、发现缺陷（可能存在于接口本身，也可能存在于组件或系统内部）、防止缺陷遗漏到更高的测试级别等。

传统整车厂内的集成测试指的是系统级的集成测试，而ASPICE 里的集成测试指的是组件集成测试，它侧重于集成组件之间的交互和接口，在组件测试之后执行。在迭代和增量开发中，要尽量做到产品有变更也不会破坏已有的接口、组件或系统，这需要组件集成测试进行持续的验证。软件集成是把软件单元集成到更大的软件项，直至形成与软件架构设计相一致的完整的集成软件，然后将这些集成软件交付到组件集成测试，以验证其是否符合软件架构设计（包括软件单元之间和软件项之间的接口设计）的要求。

组件集成测试中能够发现的比较典型的缺陷和失效如下：

（1）数据不正确、数据丢失或数据编码不正确；

（2）接口调用的顺序或时序不正确；

（3）接口不匹配；

（4）组件间通信失效；

（5）组件间未处理或处理不当的通信失效；

（6）关于组件间传递的数据含义、数据单位或数据边界的假设不正确。

组件集成测试的重点在集成上，例如，将模块A 与模块B 集成，组件集成测试侧重于模块之间的通信，而不是单个模块的功能，因为在组件测试期间已经覆盖了单个模块的功能。组件集成测试通常由开发人员负责，这不同于系统集成测试由专职测试人员负责。

集成通常应该是增量式的，即每次增加少量的组件或系统，而不是大爆炸式的，即一次性集成所有的组件或系统。因为集成的范围越大，将缺陷定位到指定的组件或系统就越困难，会增加风险及排查问题的时间，所以在持续集成中，软件中的每个组件逐步集成并持续地进行集成测试成了普遍做法。

4 软件合格性测试

在国内汽车行业整车研发阶段,零部件软件质量保证过程大多依赖供应商的软件研发实力，而整车厂对软件的实质性管控非常缺乏。ASPICE 中定义的这个软件合格性测试是连接传统供应商软件开发与整车厂验证的重要一环，很多时候被忽视甚至忽略。从传统整车厂的角度看，软件合格性测试可以理解为供应商完成软件开发后在交付前进行的出厂测试。软件合格性测试完成并合格以后，软件从供应商来到整车厂，随后被进行后续的系统级、整车级的测试。软件合格性测试是检验软件配置项、软件任务书和软件需求规格说明的一致性[12]，相对于组件集成测试只是保障了软件架构设计的正确性。软件合格性测试的范围更广，其测试报告可以看成是组件软件从开发商交付到用户的产品合格证书。测试人员要按照测试要求编写合理、规范的测试方案、测试用例报告、Bug缺陷报告、测试总结报告[13-15]。若整车厂选择了软件自研，那这部分软件合格性测试也应由整车厂来执行。与组件测试执行人员为软件开发人员不同，这部分测试的执行人员为专职的测试人员。

实施本过程的关键步骤如下：

（1）制定与项目计划和发布计划相一致的软件合格性测试策略（包括回归测试策略），以测试集成软件；

（2）根据软件合格性测试策略，开发集成软件的软件合格性测试规范，以适于提供符合软件需求的证据；

（3）根据软件合格性测试策略和发布计划，选择软件合格性测试规范中的测试用例；

（4）使用选定的测试用例测试集成软件，并记录软件合格性测试结果；

（5）建立软件需求与软件合格性测试规范中的测试用例之间的一致性和双向可追溯性，建立测试用例与测试结果之间的一致性和双向的可追溯性；

（6）总结软件合格性测试结果，并与所有受影响方沟通。

软件合格性测试并不一定要所有的测试用例都通过才算合格，而是要总结软件合格性测试结果，与所有受影响方通报及沟通。

5 结论

随着新架构、新通信、新测试内容的加入，整车厂的软件测试面临更大的困难和挑战，软件质量直接影响了软件的使用与维护，对软件质量进行客观、科学地评价贯穿于软件整个生命周期。当整车厂的测试下探到了传统供应商的测试时，单一地使用1 种或2 种测试方法对软件质量的提高有限，测试工作需要增加软件组件测试、组件集成测试、软件合格性测试以匹配软件自研开发。梳理好各个级别（零部件、系统、整车）测试的颗粒度，优化各个测试级别的资源分配，才能够在软件自研的转型过程中，完成整个软件开发V 模型流程右侧各个阶段的测试验证工作，并最终形成完整的汽车软件全栈自研，将整车的“灵魂”掌握在整车厂手中。

参考文献

[1] 黄磊.基于供应链模式的软件企业人力资源管理研究[D].北京：北京交通大学,2015.

[2] 朱海燕.计算机软件测试技术及其应用研究.信息记录材料,2021(4)：187-188.

[3] 王丽娟,刘全周,晏江华，等.基于ASPICE及ISO26262的软件测试技术研究[J].中国测试,2020,46(S1)：139-143.

[4] 李辉.汽车软件测试方法研究[J].汽车工业研究,2024(1)：47-50.

[5] 陈雪,王圆春,刘娜，等.GJB5000B软件测试与监督探析[J].电子质量,2023(9)：21-25.

[6] 龚昌.浅谈白盒测试与黑盒测试在软件测试中的应用[J].信息与电脑(理论版),2011(2)：57.

[7] 杨梵.软件测试技术的关键能力培养探讨[J].福建电脑,2022,38(9)：71-74.

[8] 淡海英.软件测试中的白盒测试分析[J].时代农机,2018,45(11)：244.

[9] 杨培培,赵海生,李振星.实用软件测试方法研究[J].计算机应用,2015,35(S1)：166-167.

[10] 钟睿.浅析软件黑盒测试[J].数字通信世界,2018(5)：145.

[11] 杨鹏.浅谈集成测试中的一点思考[J].电子世界,2012(22)：116.

[12] 林生旭,盘茂杰.软件测试技术及其测试工具的研究与应用[J].现代计算机,2023,29(12)：37-43.

[13] 马振宇,张威,吴纬,等.软件可靠性验证测试研究方法综述.兵器装备工程学报,2019(7)：118-122.

[14] 李勇,汪伟,彭再武，等.新能源商用车控制软件质量提升研究[J].客车技术与研究,2020,42(3)：12-15.

[15] 郑霖娟,林昆.基于岗位核心能力的“软件测试技术”课程课程设计与实践.软件,2020(10)：286-288.