在无硬件、无协议栈的情况下，Classic AUTOSAR SWCs软件系统如何测试？

在Classic AUTOSAR SWCs开发、测试时，会存在依赖硬件的才能开展相关工作的问题，那么如果在没有硬件也不关心底层的情况下，基本上可以认为就和IT工程师一样，可以在任何地区做相应的开发和相应的测试，以及相应的交付工作。在疫情、跨团队/地区和跨车厂/供应商之间将会更加敏捷的实现开发迭代。软件定义汽车，都在聚焦开发的话题，但永远不能忽视其中大量工作是与测试相关。AUTOSAR里面提供了复杂性，但是也提供了很多便捷的接口在里面，因为它是分层的架构体系，这就可以使得在开发的时候能够利用相应的技术，比如需要相应的RTE和底层的BSW，可以采用虚拟的手段，把相应的底层虚拟出来，保证不同的SWCs逻辑，是可以进行相应访问，以及在访问的时候，它的状态也是可以控制的，以及内部的port口，包括Service的一些port口和用户自定义变量，也需要做监控和相应的处理。 当开发工程师在SWC进行集成时，也需要实现相应的测试应用。随着软件定义汽车的发展，有一部分SWC的软件模块被OEM要求整合到HPC里面去，它可能会在MCU端进行相应的运行部署。这个时候本身就是面临怎么只是去测试相应的软件以及做相应的开发工作，以及到后期的时候，在OEM系统角度而言，肯定会面临软硬结合的应用场景，VECTOR在工具层面提供相应的支撑工具。Classic AUTOSAR SWC在Windows或Linux中部署测试从若干SWCs测试开始，到进行虚拟ECU的测试，最后到系统测试，都需要在出现Fail时进行回归，相对于基于硬件板子的测试来说，基于软件的测试会更加灵活一些，与之对应的新的IDE环境也需要满足相应的工作。具体来说针对今天主题需解决相应的Classic AUTOSAR的SWCs虚拟化集成，VECTOR为此提供的主要工具是vVIRTUALtarget，在这个vVIRTUALtarget里可以加载相应的SWCs的描述文件，以及各个SWCs所对应的代码，通过VisualStudio进行相应的编译和生成，生成虚拟的SWCs或虚拟的ECU，会加载在CANoe平台里面做相应的执行。那么就可以通过这样的手段实现相应的集成和编译。 在ECU运行的CANoe环境里面，直接基于VisualStudio增加断点做相应的SWCs开发调试。这种方案会明显看到过往开发工程师桌子上肯定会有电源、调试器、板子，现在对应这些东西都是不需要的，因为电脑上只要装软件工具，所有的那些开发调适都可以在电脑上通过相应的软件工具进行实现。在集成实现相应的调试，后面就要进行相应的测试工作，测试时CANoe提供了相应的功能，能够通过CANoe满足手动交互式的测试应有需求。当然在工具层面也能通过vTESTstudio实现自动化测试。在更加系统的层面实现完整的虚拟ECU，不管是通过仿真的方式还是虚拟化的方式，都可实现了对应的封装。这样一个虚拟的ECU或者和SWCs，它本身是一个“黑盒”的dll，在测试完之后就可以Deliver，Deliver给相应的OEM端或者是别的一些客户，实际项目也遇到有联合开发的情况，也是完全可以Deliver给客户拿去做相应的系统验证工作。目前在敏捷化时代，开发和测试可以同时进行，需要进行持续集成、持续测试工作。开发和测试两端都是基于客户的需求，针对需求的条目，只要SWC软件开发好一个，能够使用vVIRTUALtarget虚拟化出来，可以在相应的测试环境中通过部署和调度，实现相应的自动化。一旦谈到持续集成、持续测试，不得不说相关环境是基于服务器系统里面，通常会是Linux系统。在Linux系统里面，Vector同样一套工具体系（比如CANoe4SWServerEdition）也是能够把Classic AUTOSAR SWCs模块部署到Linux里面做相应的测试，或者在Docker环境里面做相应的测试，是完全可行的。因为这样对于后期打通SoC端软件的虚拟集成和测试等等，相应来说是一个更加完整的系统。 SiL测试的重要性 从单元测试到整车测试都是为了验证系统中的软件无故障运行。无论从软件最开始的静态测试还是到后期的HiL测试，都是过往常规的测试手段。在整个流程中需要增强一个概念：建立系统化的SiL能力。传统SiL指“背靠背”，现在我们讨论的是SiL是更广泛的,指在虚拟环境里面做相应的测试工作，那可能是单个的软件模块，也可能集成系统。当然在整个环境里面，作为工具厂商，在每一环节都是能够提供相应的工具。其中在工具这一块，很多工具是大家已经“耳熟能详”的。不被大家熟悉的就是今天话题的主角，就是这里面看到的CANoe4SW、CANoe4SWServerEdition、vVIRTUALtarget等。这些产品都是为了面向SiL市场，专门定制化开发的一些产品，而这些产品目前已经是发布多年的成熟产品。 有必要针对SIL展开做一个补充说明，大家可以看到在早期软件开发时都是单个或若干函数构成，随着迭代开发才会有整个软件系统，一旦有一个软件模块能够运行起来，就可以把它称之为一个SIL，技术层面就可以实现相应的Deliver，以及开展相应的测试工作。随着HPC区域控制器以及ADAS的应用，包括敏捷，以及大环境下疫情的影响，SiL更应在公司层面开展陆续做相应的试点。无自动化脚本即无敏捷，vTESTstudio可支持主流XiL平台无论是SiL也好，单元测试也好，还是“黑盒”HiL也好，测试设计是永恒的话题。只有好的测试设计框架和自动化脚本才能保障CI/CT，如果公司里面没有自动化测试脚本的，基本就是“空谈”敏捷开发持续集成与测试，是没有办法实现快速的迭代和相应的回归验证。所以在这里面有一个很重要工作就是要做好测试设计。在测试设计里面有很多理论的方法可参考，Vector提供非常智能化以及能够支持众多测试里面的工具vTESTstudio。具体来看，所有的测试都是从需求开始的，不管是单元测试还是代码的检查，不管集中部门还是分布式的部门，都需要建立“追溯性”来满足A-SPICE、ISO2626和ISO21434等流程要求。无论是开发还是测试，都需要以需求进行相应的设计。所以在各个公司里面可能会遇到不同的TDM系统，都需要能够把相对Requirements的信息加载在相应的测试工具里面去。VECTOR已经把主流的ALM和TDM系统，全部以免费的插件的方式打通了对接，同时VECTOR也提供了开放的接口，使得用户能够自行开发，或者双方沟通定制实现，实行相应的开发，当vTESTstudio导入Requirements进行相应的设计，vTESTstudio可以暂时测试覆盖度。可以看到哪个Requirements是由那些Test case去覆盖它，这个信息是非常重要的。可以看到vTESTstudio对各类流程要求的基于需求的测试都是可以覆盖的。在进行相应的HPC或者一些区域控制器时，遇到的问题就是代码非常复杂，在这种情况下做相应的单元测试、集成测试以及相应的系统测试时，回归测试将会遇到很大的问题是，当出现Fail时，怎么做相应的回归，是全部回归还是仅选中相关Fail的做回归。这两种方式都是效率不高的，也会存在一些问题。 可以看到每一部分代码都是有它相对应的测试运力做相应的覆盖，别的代码也是一样的。假设系统软件中一部分代码是有异常的，它所对应的关联测试率是红色所示的。通过映射关系会明显知道这部分Testcase是覆盖了红色所标识的这部分代码。当其中一个Testcase出现了相应的Fail，进行代码的更改，更改完代码之后是希望能够把它有关联的，这段代码所引起的关联的Testcase，从单元测试到后面的HiL测试回归，VECTOR希望能够智能化的实现相应的筛选。该如何实现？毫无疑问，要借助于该代码打桩及借助于CodeCoverage技术来实现。在工具层面会提供相应的功能，VectorCAST能够给代码ECU打桩，之后CANoe相应的测试，每条测试执行完之后，CANoe都能够拿到相应的Cover信息。每个测试力以及相应的源代码都是与之对应的requirements是有关联的，所以把所有的Cover拿到之后会加载到VectorCAST里面，看到代码是什么样的关联关系，应该做相应的回归，整个系统可以实现相应的联动。当然也支持在HiL层面的自动化筛选实现回归。倡导理论：测试建模在测试里面也会同样提倡的理论就是测试建模，我们可以反思一个话题：凭什么研发开发逻辑的时候，是通过MATLAB/Simulink去建模的？为什么不是手写代码？难道测试不可以建模吗？毫无疑问在工具层面Vector能够提供相应的功能，方便大家做测试的时候也建立相应的测试模型。在测试模型里面，vTESTstudio支持状态机模型和序列图模型，这两种模型都是能够按照用户制定的相应规则和相应系统的设计，能够有效的生成相应的Test case。每种测试理论也一些差异，但是针对具体的Requirements点，针对这个Requirements，在设计的时候需要着重考虑，到底是由建模，还是通过表格，还是通过原始代码去写。 核心要考虑的因素是要看一下怎么样测的更全一些。另一个核心因素是考虑怎么样在不同项目或者不同阶段的复用性，并不是说全部的建模，也知道在开发那端，也一些算法逻辑就是手写的，所以在测试这端，提倡和推广大家以测试建模的方式开展，但仍然有大量工作还是会采用传统方式去做相应的支持。另外也会提倡大家在做测试设计使能够把参数和相应的脚本分开，在测试里常用的理论方法就是等价类、边界值等进行测试设计，与之对应的抽象设计就是分类树法。分类数的数据驱动型的架构，在工具层面也完全能做相应的支持，也提供了相应的编辑器，后面大家定义参数，去复制相应的测试，当然了同样的工具理念Vector也集成到集成测试工具VectorCAST中，相关参数可实现复用。在数据驱动里，除了离散的参数还有大量的连续参数，在工具里会提供连续曲线的参数做相应的激励。除了传统的单元测试和集中测试，很多时候是没有去做的，但现在如果你做这些，你的ECU或者其他的是用起来的，那我就可以增加连续性，连续性曲线给ECU或者软件做输入，就可以连续的去做观测和判断，在工具层面vTESTstudio也提供了相应的功能。另外一个测试理论就是分层的“关键字”法，在行业内有时候会看到说关键字（Keyword）驱动的架构。在测试工具里，vTESTstudio同样是能支持封层的设计，所需要的关键字，vTESTstudio在工具底层都是能够支持的，而且是有相应的封装。 最后是在vTESTstudio里能够支持Python，可直接在工具里实现相应的Python开发。当然vTESTstudio可支持主流XiL平台的集成。