车载SOA测试利器ParasoftSOA自动化测试方案

​随着汽车“新四化”进程的不断深入发展，车内电控单元的数量与复杂性与日俱增，为解决传统汽车电子架构交互难、变更难的问题，SOA (面向服务的体系架构)在IT行业广泛应用的理念被引入到汽车行业中。

SOA架构具备松耦合、标准化、易变更、可重用等特点，满足整车E/E架构向中央计算平台 区域控制方向的发展趋势，目前大部分整车制造商所采用的E/E架构域控制器之间、车云之间均大量采用了基于以太网的SOA架构。

Parasoft基于多年软件行业测试经验，推出汽车电子SOA自动化测试解决方案，充分利用产品内置图形配置工具及业务流程，减少车内SOA接口/服务开发或升级部署带来的技术风险，提升测试效率、降低测试成本，可有效缩短整车发布时间。

测试内容

» 协议测试：支持SOME/IP、DDS、MQTT等多种传输协议和消息格式。

» 服务测试：提供直观的用户界面实现多种原子服务组合，形成完整的在环测试逻辑。

» 场景测试：支持根据XML/ARXML创建服务场景，不需要额外的工作。

» 测试逻辑组织：提供多样性、图形化的测试逻辑控制完成复杂的测试需求(循环，等待，并行，条件执行等)。

» 服务虚拟化：提供Virtualize 服务虚拟化组件，替代不可用服务，组建完整的业务逻辑。

» 压力测试：提供LoadTest压力性能测试组件，测试用例可直接用于进行性能和压力测试，确保系统在海量的访问请求下能达到性能要求。

» 持续测试：所有的测试用例和断言均可长期保存，便于自动化测试，反复测试。支持主动查找服务更改，使测试资产与不断开发的系统保持同步。

结果分析

支持报文自动解析，支持进行断言比较，包括结构断言、复合断言、所有有意义字段的值断言等，以达到自动判断报文内容是否符合预期。

提供连续测试平台（CTP），允许团队之间共享测试用例、同步测试活动，测试团队可以在集中式基础架构中搜索、重用、共享和维护测试用例、测试数据和虚拟服务。

提供SOA自动化测试统一监管门户，可为不同角色提供不同访问内容，包括测试信息、测试工具、测试环境、测试日志、测试报告等。

测试对象

» 支持通过数据监测和仿真设备基于SOME/IP连接车载ECU连通进行测试。

» 支持通过MQTT、HTTPS、SOAP、MQ等协议与TSP、OTA等云平台服务连通进行测试

优势分析

Parasoft具备多年软件行业测试经验，对测试流程、测试业务、测试方法具有深刻理解。

方案打造统一的SOA测试平台，将云端、车端应用不同通信协议的软件模块集中到统一的平台进行测试和环境仿真。

方案提供成熟的测试套模板，全面覆盖OPEN联盟车载以太网ECU测试规范（TC8）中的5-7层协议规范，支持无代码模式自动化生成测试用例。

覆盖不同层级的测试，实现从最上层的业务功能场景到各模块功能服务再到最细粒度的单个接口的各个层级的测试。不同测试间可相互复用，并可一键式拖拽实现灵活地切换组合测试场景和方式。

对于各粒度测试均可应用数据源和内建工具自动化批量验证结果。

方案将传统的硬件驱动的测试(单次调试/从整体到局部)思想，过渡到以软件驱动测试(自动可复用/从局部到整体)的思想。

» 通过提供海量业务模板，简化测试工作，降低对测试工程师的技术要求与实现难度。

» 通过成熟产品保证测试结果，确保产品质量和加快上线时间。

Parasoft愿以核心产品及丰富的测试经验，协助汽车行业合作伙伴打造SOA标准化测试规范，助力我国汽车基础软件产业健康发展。

软件测试一般都用到哪些工具

常用的软件测试工具一般是：QTP+LoadRunner+QC

软件测试中还需的工具如下：

功能测试工具：QTP（HP），WinRunner（MI），Robort（IBM），QARun（Compuware）

性能测试工具：LoadRunner（HP），WAS（MS），Robort（IBM）【必须下载相应的插件才支持性能方面的测试】，QALoad（Compuware）

测试管理工具：TestDirector/Quarlity Center【这两个工具一个横版一个竖版，功能完全一样】，察握Rational TestManager

缺陷跟踪工具：Bugzilla、Mantis

其他：Rational Purify、Rational PureCoverager

一般测试流程：

需求分析阶段：只要就是对业务的学习，分析需求点。猜清

测试计划阶段：测试组长就要根据SOW开始编写《测试计划》，其中包括人员，软件硬件资源，测试点，集成顺序，进度安排和风险识别等内容。

测试设计阶段：测试方案一般由对需求很熟的高资深的测试工程师设计，测试方案要求根据《SRS》上的每个需求点设计出包括需求点简介，测试思路和详细测试方法三部分的方案。《测试方案》编写完成后也需要进行评审。

测试方案阶段：主要是对测试用例和规程的设计。测试用例是根据《测试方案》来编写的，通过《测试方案》阶段，测试人员对整个系统需求有了详细的理解。这时开始编写用例才能保证用例的可执行和对需求的覆盖。测试用例需要包括测试项，用例级穗没前别，预置条件，操作步骤和预期结果。其中操作步骤和预期结果需要编写详细和明确。测试用例应该覆盖测试方案，而测试方案又覆盖了测试需求点，这样才能保证客户需求不遗漏。同样，测试用例也需要评审。

测试执行阶段：执行测试用例，及时提交有质量的Bug和测试日报，测试报告等相关文档

SOA在汽车行业的应用和前景

面向服务架构（SOA）是一个典型的从IT／互联网行业引入到 汽车 的软件技术，现在 汽车 行业围绕SOA有很多讨论和实践，主要集中于SOA本身的概念和在智能 汽车 中的实际应用，有些观点把SOA捧得很高，认为SOA是一劳永逸的方案，用了SOA就可以具备和特斯拉一较高下的软件能力，也有人觉得SOA比较虚，上了SOA用户也没什么直接的体验，不见得能多卖几辆车。毫无疑问，新技术的引入总是伴随着争议，主要还是专业背景的不同，站在 汽车 电子，通信或者电气工程师的角度去看待一个软件问题，总会有各种怀疑，也有很多与SOA无关的需求和问题，想让SOA来解决，这些都跨专业的理解偏差。而 汽车 软件，毕竟还是软件，晌橡不是信号、电子或芯片，很多疑问还得回到软件的领域，才能正确理解SOA的概念以及它能解决的问题。

智能 汽车 到底需不需要SOA？这里需要先看一下智能驾驶时代的 汽车 架构和 汽车 软件的实际需求：

传统的整车架构，尤其是电子和电气部分，主要就是分布式ECU，嵌入式软件和现场总线级别的通信网络，传统的EEA很大程度上是一套硬件集成方案（当然复杂度比手机高出几个量级），如果没有特斯拉，可能这套成熟的体系还能用上很多年，没有人考虑过把IT行业的软硬件架构直接套用到 汽车 上，但现在这事被特斯拉做成了，而且类似 科技 公司背景的入局者和模仿者越来越多，各类 汽车 软件也大幅增加。对于传统OEM，根据自己的专业背景，在这一轮技术升级中，基本都能看到域控制器、新型传感器、车载以太网、操作系统、APP和各种算法等新技术，但如何把它们有效地集成在一起，做成用户体验卓越的智能产品，还能保证成本可控，是一个比较大的挑战。新并谨陪硬件好学，拆来看看，大概也能明白对手怎么做的，但是软件和代码，还有基于这些软件的运维方式和盈利模式，对于传统 汽车 行业来说，是所谓的虚拟经济和“灵魂”，既看不太懂也有内部变革的阻力。所以OEM需要的是在现有EEA基础上，想办法把这些五花八门的新技术用更快更有效的方式集成到一起，而且采用成本和风险可控的迭代方式，而不是推倒现有架构和供应链重来。这个目标从软件的角度来看，其实就是要求OEM要具备整车软件的集成能力。

但大型系统软件的集成正是传统EEA缺失的能力，因为现有零部件都是软硬件耦合的，传统车内嵌入式软件的集成基本是零部件和CAN网络调通即可，由于CAN是基于广播的，所以各个零部件软件之间实际并没有直接对接。而随着新的非嵌入式的软件越来越多进入到车内，相互之间会通过基于以太网的软件接口(API)来直接传输数据，API调用和CAN信号广播完全是两回事，API设计是软件问题不是通信问题，同时新的 汽车 软件会有独立的生命周期线，为了保证让大量的新软件能通过以太网络在一起协同工作，OEM必须引入全新的独立于硬件的大型软件集成能力，相当于需要一套单独的整车软件架构。

这套软件架构的基本作用是：

能集成整车各个ECU、DCU(域控制器)、ZCU(区域控制器)、分布式网关/中央网关等的软件，而软件集成最重要的环节就是，设计一套统一的软件接口和数据传输格式，当然还有安全、性能等一系列规范。有了这套整车软件集成方案，OEM才能让各个供应商或服务商的软件按事先约定好的统一标准来传输数据。否则就会演变成各供应商自行定义接口名称和参数，输出各式各样的数据，安全标准也不一致，最终还得由OEM来适配和对接，成百上千的新软件集成到车内，接口联调和适配的复杂度和工作量是OEM无法承受的，这会比CAN矩阵设计高出几个量级。

那么现在 汽车 行业选择了面向服务架构(SOA)来作为 汽车 的整车软件架构，主要是为了解决各个零部件间的数据交换和通信。这个方向对不对？我们可以从IT行业设计SOA的初衷来分析。绝蠢

广义的面向服务架构，或者广义的“服务”本身，是从单机软件到网络软件都一直存在的最基本的概念。传统 汽车 的ECU嵌入式软件，都算是单机软件，功能界面数据处理基本都在同一个硬件上，没有前台界面+后台服务的概念，但在IT/软件行业，从局域网到广域网、互联网、物联网等，软件早已完成了分层架构，从最早局域网软件的Client/Server(C/S)架构，到web时代的B/S架构，最近十几年又迭代出SOA、微服务、无服务架构等等，服务这个概念始终存在且保持进化，贯穿了整个软件发展。简单来讲，软件的复杂业务代码都是运行在所谓的“服务器”上，这些服务器都是远程部署在机房的高性能计算机，运行在这些服务器上的软件被统称为“后台服务”，而运行在用户终端上的，比如PC、手机或智能硬件的软件，都叫做“前台界面”，其实就是 汽车 行业经常提的HMI。这种把交互界面和业务模块(算法)分离的主要原因是终端算力有限，同时为了避免重复开发可共用的复杂模块，才把这类模块都放到后台服务器上去做成“服务”来共享使用。

所以 汽车 软件从嵌入式逐步升级为大型系统软件的趋势下，只要有网络，那么基于服务的架构是不可避免的。高算力平台或域控制器就是车内的服务器，这些服务器把各种 汽车 零部件的控制权以软件接口的方式，提供给车内或车外以太网的其他软件使用。

但狭义上的SOA (Service-Oriented Architecture), 尤其是 汽车 行业目前多从IBM借鉴的那套SOA和企业总线理念，是不是必须的呢？并不是，而且IBM的SOA解决方案已经是过时的技术了，原因有很多，总的来说，和商业软件公司的没落有关系。

上面讲了面向服务架构的来龙去脉，就比较容易澄清SOA的用处，面向服务架构是在IT行业软硬件运行环境都很成熟的基础上出现的架构，用于软件模块之间分层，对于部分公用的，消耗计算资源的代码，被抽象成服务，单独运行在专门的服务器上，被其他软件模块共享使用。十几年前SOA的提出显然没有考虑过 汽车 行业现在还需要先实现车载以太网通信，域控制器和操作系统升级的情况。 如果说IT行业搞SOA是从0到1，那么 汽车 行业搞SOA就是从-1到0，再从0到1 ，因为还得先解决硬件升级的问题，-1到0就是OEM先得补齐的硬件功课（当然自动驾驶或者座舱应用本来也需要升级这些硬件），这里面又涉及到成本和长期ROI，以及传统OEM如何看待SOA的价值问题。 从整车成本的角度来看 ，SOA会给OEM每次新车换代节省一定比例的零部件开发费，但是在使用了SOA的第二代车开始才会节省，而第一代使用SOA的 汽车 ，又要升级网络又要引入中间件，各种新增成本，OEM未必能买单，所以如果对软件架构的长期价值理解不清楚，这个总账算起来很有难度。 而从技术上看 ，OEM其实需要在短时间内同时完成通信网络升级、硬件升级、软件升级(生态建立,盈利模式)的三步走，这三步可能在其他行业都经历了十年以上的时间，所以 汽车 行业面临的挑战要复杂不少。

SOA本身能解决哪些问题，不能解决哪些问题，到底能带来什么好处？

SOA的范围包括：

SOA最重要的作用：

SOA能保证车内和车外所有使用以太网通信的软件采用同一套数据格式进行数据交换，避免大量的软件接口适配和数据不兼容，给OEM和供应商双方都省去大量的集成成本。长期来看，SOA会是未来 汽车 开放平台的基础，如果有一天特斯拉开放和苹果类似的应用商店，面向服务架构必然是最底层的技术基础。

SOA不包含：

另外OEM需要的软硬件解耦能力，须由操作系统和SOA中间件开发商共同提供，操作系统可以通过驱动模型、硬件抽象和设备树等方式把常用的标准零部件转成系统接口，但各OEM的零部件很多都是非标准化的，操作系统并没自带这些零部件系统接口，所以还需要SOA这样的架构来补充这部分零部件的协议转化和为应用层提供API。

在实际SOA项目落地过程中，会有各种车载网络和硬件的限制条件，尤其是SOA整体性能问题，会牵涉到车内现有网络和ECU的性能和负载瓶颈，需要OEM和零部件厂商共同解决，都是有不小的挑战。另外SOA虽然是后台架构，但也会被质疑能带来什么用户体验，这涉及到应用层开发，确实需要一些新的APP或新场景来验证SOA的作用。

汽车 行业的工程师多年来习惯了先找行业标准，工具，然后才是研发，制造，最后再用标准来测试验证的闭环，这套流程是典型的制造行业的模式，凡事都得先看看有没有行业标准和成熟工具，上下游各公司都用同一套标准，最后以最小的成本和最低的风险把 汽车 造出来，流程很稳定，但这种思维模式会让工程师过分依赖标准和工具，失去真正的研发和创新能力，尤其是整车架构中很多标准和协议都是欧美日定义的，大量的资金都投给了国外的工具商和外资Tier-1，给到工程团队的研发费用反而很少。现在这套闭环被特斯拉带头用更先进的理念和技术打破了，还造出了跨代领先的产品，证明了开源软件在车内的可行性。而且新的智能软件并不像硬件或者嵌入式软件需要那么多规范，传统 汽车 软件开发类似于做填空题，题干都被固定了，我们只能做最没有技术含量的部分，而智能软件都是根据用户需求自行开发，更像是写作文，就一个题目，剩下的自由发挥。这个变化对于新一代智能 汽车 或者新一代的 汽车 软件供应商，都是研发能力升级的最佳机会，也有充分的商业动机去完成新一代核心软件和工具的国产化。

作者：

Luke Chen

快控 科技 CEO