在Classic AUTOSAR SWCs開發(fā)、測試時，會存在依賴硬件的才能開展相關(guān)工作的問題，那么如果在沒有硬件也不關(guān)心底層的情況下，基本上可以認為就和IT工程師一樣，可以在任何地區(qū)做相應(yīng)的開發(fā)和相應(yīng)的測試，以及相應(yīng)的交付工作。在疫情、跨團隊/地區(qū)和跨車廠/供應(yīng)商之間將會更加敏捷的實現(xiàn)開發(fā)迭代。
軟件定義汽車，都在聚焦開發(fā)的話題，但永遠不能忽視其中大量工作是與測試相關(guān)。AUTOSAR里面提供了復雜性，但是也提供了很多便捷的接口在里面，因為它是分層的架構(gòu)體系，這就可以使得在開發(fā)的時候能夠利用相應(yīng)的技術(shù)，比如需要相應(yīng)的RTE和底層的BSW，可以采用虛擬的手段，把相應(yīng)的底層虛擬出來，保證不同的SWCs邏輯，是可以進行相應(yīng)訪問，以及在訪問的時候，它的狀態(tài)也是可以控制的，以及內(nèi)部的port口，包括Service的一些port口和用戶自定義變量，也需要做監(jiān)控和相應(yīng)的處理。
當開發(fā)工程師在SWC進行集成時，也需要實現(xiàn)相應(yīng)的測試應(yīng)用。隨著軟件定義汽車的發(fā)展，有一部分SWC的軟件模塊被OEM要求整合到HPC里面去，它可能會在MCU端進行相應(yīng)的運行部署。這個時候本身就是面臨怎么只是去測試相應(yīng)的軟件以及做相應(yīng)的開發(fā)工作，以及到后期的時候，在OEM系統(tǒng)角度而言，肯定會面臨軟硬結(jié)合的應(yīng)用場景，VECTOR在工具層面提供相應(yīng)的支撐工具。
Classic AUTOSAR SWC在Windows或Linux中部署測試
從若干SWCs測試開始，到進行虛擬ECU的測試，最后到系統(tǒng)測試，都需要在出現(xiàn)Fail時進行回歸，相對于基于硬件板子的測試來說，基于軟件的測試會更加靈活一些，與之對應(yīng)的新的IDE環(huán)境也需要滿足相應(yīng)的工作。
具體來說針對今天主題需解決相應(yīng)的Classic AUTOSAR的SWCs虛擬化集成，VECTOR為此提供的主要工具是vVIRTUALtarget，在這個vVIRTUALtarget里可以加載相應(yīng)的SWCs的描述文件，以及各個SWCs所對應(yīng)的代碼，通過Visual Studio進行相應(yīng)的編譯和生成，生成虛擬的SWCs或虛擬的ECU，會加載在CANoe平臺里面做相應(yīng)的執(zhí)行。那么就可以通過這樣的手段實現(xiàn)相應(yīng)的集成和編譯。
在ECU運行的CANoe環(huán)境里面，直接基于Visual Studio增加斷點做相應(yīng)的SWCs開發(fā)調(diào)試。這種方案會明顯看到過往開發(fā)工程師桌子上肯定會有電源、調(diào)試器、板子，現(xiàn)在對應(yīng)這些東西都是不需要的，因為電腦上只要裝軟件工具，所有的那些開發(fā)調(diào)適都可以在電腦上通過相應(yīng)的軟件工具進行實現(xiàn)。
在集成實現(xiàn)相應(yīng)的調(diào)試，后面就要進行相應(yīng)的測試工作，測試時CANoe提供了相應(yīng)的功能，能夠通過CANoe滿足手動交互式的測試應(yīng)有需求。當然在工具層面也能通過vTESTstudio實現(xiàn)自動化測試。在更加系統(tǒng)的層面實現(xiàn)完整的虛擬ECU，不管是通過仿真的方式還是虛擬化的方式，都可實現(xiàn)了對應(yīng)的封裝。這樣一個虛擬的ECU或者和SWCs，它本身是一個“黑盒”的dll，在測試完之后就可以Deliver，Deliver給相應(yīng)的OEM端或者是別的一些客戶，實際項目也遇到有聯(lián)合開發(fā)的情況，也是完全可以Deliver給客戶拿去做相應(yīng)的系統(tǒng)驗證工作。
目前在敏捷化時代，開發(fā)和測試可以同時進行，需要進行持續(xù)集成、持續(xù)測試工作。開發(fā)和測試兩端都是基于客戶的需求，針對需求的條目，只要SWC軟件開發(fā)好一個，能夠使用vVIRTUALtarget虛擬化出來，可以在相應(yīng)的測試環(huán)境中通過部署和調(diào)度，實現(xiàn)相應(yīng)的自動化。
一旦談到持續(xù)集成、持續(xù)測試，不得不說相關(guān)環(huán)境是基于服務(wù)器系統(tǒng)里面，通常會是Linux系統(tǒng)。在Linux系統(tǒng)里面，Vector同樣一套工具體系（比如CANoe4SW Server Edition）也是能夠把Classic AUTOSAR SWCs模塊部署到Linux里面做相應(yīng)的測試，或者在Docker環(huán)境里面做相應(yīng)的測試，是完全可行的。因為這樣對于后期打通SoC端軟件的虛擬集成和測試等等，相應(yīng)來說是一個更加完整的系統(tǒng)。
SiL測試的重要性
從單元測試到整車測試都是為了驗證系統(tǒng)中的軟件無故障運行。無論從軟件最開始的靜態(tài)測試還是到后期的HiL測試，都是過往常規(guī)的測試手段。在整個流程中需要增強一個概念：建立系統(tǒng)化的SiL能力。
傳統(tǒng)SiL指“背靠背”，現(xiàn)在我們討論的是SiL是更廣泛的,指在虛擬環(huán)境里面做相應(yīng)的測試工作，那可能是單個的軟件模塊，也可能集成系統(tǒng)。當然在整個環(huán)境里面，作為工具廠商，在每一環(huán)節(jié)都是能夠提供相應(yīng)的工具。其中在工具這一塊，很多工具是大家已經(jīng)“耳熟能詳”的。不被大家熟悉的就是今天話題的主角，就是這里面看到的CANoe4SW、CANoe4SW Server Edition、vVIRTUALtarget等。這些產(chǎn)品都是為了面向SiL市場，專門定制化開發(fā)的一些產(chǎn)品，而這些產(chǎn)品目前已經(jīng)是發(fā)布多年的成熟產(chǎn)品。
有必要針對SIL展開做一個補充說明，大家可以看到在早期軟件開發(fā)時都是單個或若干函數(shù)構(gòu)成，隨著迭代開發(fā)才會有整個軟件系統(tǒng)，一旦有一個軟件模塊能夠運行起來，就可以把它稱之為一個SIL，技術(shù)層面就可以實現(xiàn)相應(yīng)的Deliver，以及開展相應(yīng)的測試工作。隨著HPC區(qū)域控制器以及ADAS的應(yīng)用，包括敏捷，以及大環(huán)境下疫情的影響，SiL更應(yīng)在公司層面開展陸續(xù)做相應(yīng)的試點。
無自動化腳本即無敏捷，vTESTstudio可支持主流XiL平臺
無論是SiL也好，單元測試也好，還是“黑盒”HiL也好，測試設(shè)計是永恒的話題。只有好的測試設(shè)計框架和自動化腳本才能保障CI/CT，如果公司里面沒有自動化測試腳本的，基本就是“空談”敏捷開發(fā)持續(xù)集成與測試，是沒有辦法實現(xiàn)快速的迭代和相應(yīng)的回歸驗證。所以在這里面有一個很重要工作就是要做好測試設(shè)計。
在測試設(shè)計里面有很多理論的方法可參考，Vector提供非常智能化以及能夠支持眾多測試里面的工具vTESTstudio。具體來看，所有的測試都是從需求開始的，不管是單元測試還是代碼的檢查，不管集中部門還是分布式的部門，都需要建立“追溯性”來滿足A-SPICE、ISO2626和ISO21434等流程要求。
無論是開發(fā)還是測試，都需要以需求進行相應(yīng)的設(shè)計。所以在各個公司里面可能會遇到不同的TDM系統(tǒng)，都需要能夠把相對Requirements的信息加載在相應(yīng)的測試工具里面去。VECTOR已經(jīng)把主流的ALM和TDM系統(tǒng)，全部以免費的插件的方式打通了對接，同時VECTOR也提供了開放的接口，使得用戶能夠自行開發(fā)，或者雙方溝通定制實現(xiàn)，實行相應(yīng)的開發(fā)，當vTESTstudio導入Requirements進行相應(yīng)的設(shè)計，vTESTstudio可以暫時測試覆蓋度?？梢钥吹侥膫€Requirements是由那些Test case去覆蓋它，這個信息是非常重要的?？梢钥吹絭TESTstudio對各類流程要求的基于需求的測試都是可以覆蓋的。
在進行相應(yīng)的HPC或者一些區(qū)域控制器時，遇到的問題就是代碼非常復雜，在這種情況下做相應(yīng)的單元測試、集成測試以及相應(yīng)的系統(tǒng)測試時，回歸測試將會遇到很大的問題是，當出現(xiàn)Fail時，怎么做相應(yīng)的回歸，是全部回歸還是僅選中相關(guān)Fail的做回歸。這兩種方式都是效率不高的，也會存在一些問題。
可以看到每一部分代碼都是有它相對應(yīng)的測試運力做相應(yīng)的覆蓋，別的代碼也是一樣的。假設(shè)系統(tǒng)軟件中一部分代碼是有異常的，它所對應(yīng)的關(guān)聯(lián)測試率是紅色所示的。通過映射關(guān)系會明顯知道這部分Test case是覆蓋了紅色所標識的這部分代碼。當其中一個Test case出現(xiàn)了相應(yīng)的Fail，進行代碼的更改，更改完代碼之后是希望能夠把它有關(guān)聯(lián)的，這段代碼所引起的關(guān)聯(lián)的Test case，從單元測試到后面的HiL測試回歸，VECTOR希望能夠智能化的實現(xiàn)相應(yīng)的篩選。
該如何實現(xiàn)？毫無疑問，要借助于該代碼打樁及借助于Code Coverage技術(shù)來實現(xiàn)。
在工具層面會提供相應(yīng)的功能，VectorCAST能夠給代碼ECU打樁，之后CANoe相應(yīng)的測試，每條測試執(zhí)行完之后，CANoe都能夠拿到相應(yīng)的Cover信息。每個測試力以及相應(yīng)的源代碼都是與之對應(yīng)的requirements是有關(guān)聯(lián)的，所以把所有的Cover拿到之后會加載到VectorCAST里面，看到代碼是什么樣的關(guān)聯(lián)關(guān)系，應(yīng)該做相應(yīng)的回歸，整個系統(tǒng)可以實現(xiàn)相應(yīng)的聯(lián)動。當然也支持在HiL層面的自動化篩選實現(xiàn)回歸。
倡導理論：測試建模
在測試里面也會同樣提倡的理論就是測試建模，我們可以反思一個話題：憑什么研發(fā)開發(fā)邏輯的時候，是通過MATLAB/Simulink去建模的？為什么不是手寫代碼？難道測試不可以建模嗎？毫無疑問在工具層面Vector能夠提供相應(yīng)的功能，方便大家做測試的時候也建立相應(yīng)的測試模型。在測試模型里面，vTESTstudio支持狀態(tài)機模型和序列圖模型，這兩種模型都是能夠按照用戶制定的相應(yīng)規(guī)則和相應(yīng)系統(tǒng)的設(shè)計，能夠有效的生成相應(yīng)的Test case。每種測試理論也一些差異，但是針對具體的Requirements點，針對這個Requirements，在設(shè)計的時候需要著重考慮，到底是由建模，還是通過表格，還是通過原始代碼去寫。
核心要考慮的因素是要看一下怎么樣測的更全一些。另一個核心因素是考慮怎么樣在不同項目或者不同階段的復用性，并不是說全部的建模，也知道在開發(fā)那端，也一些算法邏輯就是手寫的，所以在測試這端，提倡和推廣大家以測試建模的方式開展，但仍然有大量工作還是會采用傳統(tǒng)方式去做相應(yīng)的支持。另外也會提倡大家在做測試設(shè)計使能夠把參數(shù)和相應(yīng)的腳本分開，在測試里常用的理論方法就是等價類、邊界值等進行測試設(shè)計，與之對應(yīng)的抽象設(shè)計就是分類樹法。分類數(shù)的數(shù)據(jù)驅(qū)動型的架構(gòu)，在工具層面也完全能做相應(yīng)的支持，也提供了相應(yīng)的編輯器，后面大家定義參數(shù)，去復制相應(yīng)的測試，當然了同樣的工具理念Vector也集成到集成測試工具VectorCAST中，相關(guān)參數(shù)可實現(xiàn)復用。
在數(shù)據(jù)驅(qū)動里，除了離散的參數(shù)還有大量的連續(xù)參數(shù)，在工具里會提供連續(xù)曲線的參數(shù)做相應(yīng)的激勵。除了傳統(tǒng)的單元測試和集中測試，很多時候是沒有去做的，但現(xiàn)在如果你做這些，你的ECU或者其他的是用起來的，那我就可以增加連續(xù)性，連續(xù)性曲線給ECU或者軟件做輸入，就可以連續(xù)的去做觀測和判斷，在工具層面vTESTstudio也提供了相應(yīng)的功能。
另外一個測試理論就是分層的“關(guān)鍵字”法，在行業(yè)內(nèi)有時候會看到說關(guān)鍵字（Keyword）驅(qū)動的架構(gòu)。在測試工具里，vTESTstudio同樣是能支持封層的設(shè)計，所需要的關(guān)鍵字，vTESTstudio在工具底層都是能夠支持的，而且是有相應(yīng)的封裝。
最后是在vTESTstudio里能夠支持Python，可直接在工具里實現(xiàn)相應(yīng)的Python開發(fā)。當然vTESTstudio可支持主流XiL平臺的集成。
