汽车软件测试的挑战-2022

一、前言

智能汽车的发展，无论是传统汽车强调的四化（电动、智能、网联、共享），新造车势力引领的软件驱动汽车（SDV），都奔着更高的技术等级发展，今日的汽车，已经远远超出动力系统加沙发的结构了。
无论如何发展，有一个方向是不变的，那就是系统越来越复杂，软件的成分越来越多。
除了随着技术发展进行升级之外，汽车系统本身使用的芯片功能也越来越强大，成本也越来越低，这使得运行软件的环境越来越好，系统可以往更高复杂度发展的基础越来越好。
复杂性带来了两个好处：

功能可以做得越来越强大
稳定性可以不断的调优，用户体验会越来越好
同时带给汽车测试的挑战也越来越大：
原来的流程和方式面临不适用的问题，甚至有人开始质疑ASPICE甚至弃用
原来的思维方式不能有效的测试这个系统，甚至没有答案
供应商和主机厂的合作方式完全改变，供应商不再掌握一线的技术实践，主机厂需要自己思考怎么解决
敏捷交付的引入，让所有的流程混合在一起，让参与者无所适从，管理者目瞪口呆
变更越来越频繁，用户说了算，没有人真正的懂用户
等等
这些挑战如果放到传统行业，是找不到完整答案的。
通信行业产品研发有着完整的质量标准和测试流程，互联网行业也有各类开源的质量系统和测试工具，而且两者的产品都很出色。传统的汽车行业，有严格的供应商管理流程、整车开发流程、零部件集成制造规范、生产线问题处理规范、售后服务流程等等。现代汽车系统的研发，更像是三者的融合，而且互联网行业产品开发的偏向更明显。

二、测试挑战

拨开云雾，从测试的角度，这个工作本身也只是瀑布模型（或者V模型）的一个或者几个环节，或者是敏捷迭代工作中的一个任务，测试的挑战看起来仅仅是如何把这个工作做好，而不是回过头去思考如何适配流程。

2.1 传统通信行业的测试特点

结合通信行业高产品质量的要求，我们很容易了解到，通信行业的优秀实践：

完善的测试流程
高自动化率
重视产品性能
通信行业的测试流程非常规范，甚至现在很多运营商（购买通信设备的）自己都有入库测试，从设备设计到研发生产，层层拦截，道道控制质量，才有现在稳定的网络环境，清晰的语音通话质量。
同时，通信产品生命周期也在逐渐缩短，GSM是20+年，UMTS却只有10+年，现在LTE已经低于10年了，5G还在发展中，却遇到了各种OpenRAN的技术的挑战。因此在测试角度，对自动化测试的需求很高，一方面对已有产品的维护变得冗长，另一方面新功能的叠加依赖原有功能的稳定。因此，可以看到通行行业有很多优秀的自动化测试框架，很多独特的系统工具。
对产品性能的重视，也造就了通信行业产品的高可靠性和高品质。各层级的性能统计系统、MTBF、掉话率等等指标，在运营商层面就非常重视，特别是网规网优部门的关注，使得类似中国移动等企业可以实现“打造精品网络”的目标。

2.2 互联网行业的测试特点

互联网行业繁荣了20年，很多新技术涌现出来，而且行业专家具有高度开放的心态和奉献精神，使得这个行业高度繁荣而且将继续繁荣下去。
高收入和人才聚集的特点，使得互联网的测试具有下面的特点：

大量优质的工具，使得测试工作开展容易
大量优秀的人才聚集，使得行业的难题能够很快解决
技术纵深发展，全链条全环节都有覆盖
工具是测试的基础之一，良好的工具链，就像社会发展的轮子，造就了高度繁荣的基础。
优秀人才的聚集，引入更多的思考，对行业的技术难点把握的更清楚，解决方案也越多。
技术往纵深发展，虚拟化技术、云化技术、各种代码扫描、质量度量等技术，使得互联网产品广泛且稳定的运行于世界上各个角落。

2.3 传统汽车行业的测试特点

传统汽车行业形成的主机厂和供应商的结构，使得行业发展非常稳定，规范的流程和严密的全球供应链协作方式，可以确保一个具有2000+零件的产品可以保质保量的交付到用户手中，而且产品稳定可靠，经久耐用。
传统汽车行业测试的特点：

供应商能力强大，合作性强
质量流程规范，如FMEA、G8D等
全球优秀供应商如Bosch、Denso、Delphi、Aptiv、ZF、华域、延锋等等，为其服务的主机厂提供了大量优质的零部件和测试能力，而且创造了很强，新的工具、平台、方法都从供应商中产生。
严密的质量流程，各类质量系统，能够确保复杂系统在进行设计和开发时，能够考虑全面、层层把控，高质量的交付。

2.4 汽车软件测试的挑战与机遇

当今汽车行业的发展，可以理解为结合了这三个行业的特点，汽车软件测试也亟需综合这些特点，进行变革。
这些特点有：

高自动化率
关注性能（功能性能和产品性能）
丰富的工具链
完善的流程和规范
结合敏捷开发流程的引入，汽车软件测试需要从下面四个角度考虑实施方案：

如何在快速迭代流程下进行充分的测试
如何准备充分的环境、工具
测试方法革新
测试纵深策略
自动化测试
下面分开论述。

三、快速迭代下的测试要求

从流程的角度，敏捷开发要求更快的交付功能，更早的交付大功能，哪怕是其基础原型。因此在敏捷流程，特别是大型企业级敏捷流程（如SAFe）中，开始构造一种更细致的协作模式。这种模式从整车层面讲产品研发分级分类，然后在下一级中进行更为细致的划分，直到可以实施。同样的，产品研发的分级划分，最终测试需要把握颗粒度，并且逐级向上集成。
原本汽车开发的协作模式只有两级：零部件和整车，现在至少需要分成三级：零部件、域和整车，甚至四级：子系统（根据承载芯片划分，或者根据技术簇划分）、零部件系统、域和整车。

为满足快速迭代的要求，需要对各个层级的测试主体进行恰当的划分，以确保该测试主体能够均匀的分布在各个冲刺（Sprint）之中。

3.1 子系统

以智能座舱为例，座舱上一般至少含有2个异构的系统：仪表盘和人机交互系统，其他的如语音引擎、地图引擎、蓝牙/WIFI/USB连接模组、储存系统等。这几个系统的业务逻辑、技术簇、测试方法有很大的不同。
这个层级可以快速迭代，而且产品的可测试性很高。

3.2 零部件系统

仍然以智能座舱为例，座舱域的零件包含：控制器、仪表盘显示系统、人机交互系统、智能语音系统、功率放大器、各类摄像头组成的影像系统。这里每一个系统的测试方法也大不相同。
这个层级需要对功能和性能需求进行划分，调整到适当的颗粒度，确保满足敏捷迭代中要求的2周～4周的冲刺周期（Sprint）要求。子系统之间的接口需要架构师进行设计，确保系统满足各类性能指标：时延和丢包，CPU和内存占用率，响应时间和失效率等。
这些内容作为测试输入，由测试设计师进行评估，并给出完整的测试用例，并与架构师一起评估后实施。

3.3 域

现代汽车一般分6大域（视功能复杂度和结合度划分）：

智能座舱域
智能驾驶域
动力地盘域
车身控制域
智能网联域
基础设施域
每一个域的测试方法也都不一样。
这个层级需要非常小心的划分功能，特别是确保功能之间的独立性。
如果功能横跨多个域，则需要提前制定好域产品之间的接口，并且跟踪变更，确保高内聚低耦合的原则能够落地。
域内零件的接口，以及域间的接口，需要各个域的架构师进行设计和评审，考虑系统带宽、时延，接口类型、技术演进方向等方面的因素，最终确定下来，作为测试设计师的输入。测试设计师输出有针对性的测试用例后，由域系统架构师进行评估后，再进行实施。

3.4 整车

从整车的角度，一般以功能为切面进行测试验收，同时也以性能测试为交付条件，一般需要两组力量。功能测试可以随着敏捷开发的流程走，性能测试则遵守瀑布模型（或者V模型）进行长周期迭代。

四、环境要求

为了满足高效率测试的要求，测试工作必须稳定可靠的实施。由于汽车软件运行在各类异构的系统之上，且依赖各种电气接口，因此，构建一个稳定可靠的测试环境，是测试工作的重中之重。
测试接口是按照车辆电气架构设计时的规定，由各个零部件输出的EID（Electric Interface Document）来约定。线束工程师根据电气特性设计连接线束和端子，输出给线束供应商制作线束，提供给试制厂和制造厂。为了测试目的，这些端子和线束也广泛的用于各个零部件的测试。
另外，为了满足性能和功能的要求，也要对被测对象进行各类仿真，即模拟外围设备，使用计算机控制外围设备模拟各类工况输出给待测设备，并对待测设备的响应进行处理。
有了设备仿真，第一层级的要求即可满足，能够完成对子系统，或者零部件的测试工作。
各类样本量、稳定性的测试，可以在这个设备上进行量的叠加即可。
然而在域一级，则需要复杂的仿真设备。一种可能的方法是多个域中设备的组合，然后对组合域之外的接口进行设备仿真。这种方法带来的挑战在于，接口的数量成指数级的增加，而且控制逻辑的计算机软件也非常复杂。另一种简化策略是针对功能进行组合设计，如仅仅完成FOTA功能的设备仿真，仅需要实现上下高压的逻辑，而忽略各个域组合内零件的行为接口。
特别值得注意的是，需要考虑量级的设计，如FOTA成功率需要满足99.9%的要求，而且迭代周期是2周，则需要大概50个同样的测试设备，以确保2周内能够完成2000次测试迭代。

五、测试方法

智能汽车的一级软件功能已经超过400项，分散在各个域内，而且二级功能基本上在5000左右，为各个一级功能的分解，也是整车软件交付的功能原子。这些二级功能基本上可以在2～4个敏捷冲刺内完成，而不考虑软件基础系统的设计和开发，以及软件开发过程中的优化和代码重构，以此可见汽车软件开发的复杂度。
因此，测试方法中，需要紧密的跟踪这些敏捷开发过程，一个迭代一个迭代的跟踪，确保每一个迭代的输出质量。
另一个层面，汽车软件开发是一个叠加的过程，如何确保新开发的功能不能影响已存在的功能，新功能与原功能的交叉效应。

5.1 功能叠加

功能叠加需要强大的测试回归能力，一般借助自动化测试技术，确保每一个迭代中的测试用例能够收录到回归测试用例集合，在下一个迭代中进行回归测试，确保新增加的软件功能不会造成原有功能的回退。

5.2 功能交叉

更高的层次，新功能的增加，会在用户层面造成功能交叉，因此测试设计师需要考虑这些功能的交叉。
一般的方法是设计一个交叉矩阵，已实现的功能在行和列中描述，行中的功能为前置，列的功能为测试行为，进行功能交叉设计之后，可以评判出一个功能对另一个功能的影响，并进行系统优化。

六、纵深策略

测试纵深，也称为测试技术下沉。
一般实施方法为深入子系统内部，对系统中可测试的对象进行评估，并有选择性的进行测试。
从子系统的层面，子系统的硬件接口，软件进程、任务或者服务，都是可测试对象。
从测试的角度，这些接口和软件服务都是可以测试的对象，是软件系统运行的基石，只有这些对象稳定可靠，上层的功能才稳定可靠。

七、自动化测试

从技术层面，自动化测试是一个必须的工作。
首先，敏捷迭代要求快速回归，没有自动化测试技术，这个回归无法完成。纯粹的人海战术会导致高昂的人力成本和复杂的管理逻辑，最后还是会出现各类人为的测试遗漏。
其次，功能交叉和纵深策略会诞生大量的测试用例，而且相较于敏捷迭代中的测试用例，功能交叉的测试用例和纵深策略的测试用例会高一个维度，自动化测试，或者是自动化的生成测试用例会大大降低测试的复杂性。
最后，稳定性测试和性能测试需要长期的重复工作，不借助自动化测试无法确保完成度。