《SOA架構測試概述》由會員分享,可在線閱讀,更多相關《SOA架構測試概述(12頁珍藏版)》請在裝配圖網(wǎng)上搜索。
1、SOA架構/測試階段接口描述語言轉換方案
SOA架構盛行
隨著汽車新四化的推進,汽車整車廠在實現(xiàn)車輛網(wǎng)聯(lián)、自動駕駛和數(shù)據(jù)驅動的同時,更要在滿足用戶體驗和基本服務的基礎上快速響應客戶的個性化需求,為更好地解決這些新的挑戰(zhàn),整車廠引入了高性能的芯片、突破性的技術產(chǎn)品,同時傳統(tǒng)的EE架構也需要變革,SOA(面向服務的架構)成為大多整車廠響應市場需求的首選架構。SOA架構的主要優(yōu)勢是可以在很大程度上實現(xiàn)分布式系統(tǒng)軟件模塊間的解耦,通過軟件升級OTA可以更方便靈活地將服務實體部署在任意的域控制器上,服務之間只需通過簡單、精確定義的接口進行通訊,不涉及底層編程接口和通訊模型。而且對于ECU的版本更新、
2、信號庫更新、代碼修改等過程更加簡便和靈活。簡化了注冊服務與調用API,節(jié)約了時間成本,提高系統(tǒng)的健壯性和擴展性。
SOA開發(fā)和部署步驟
設計和部署一個SOA汽車軟件大概可分為以下幾個步驟:
圖1: SOA開發(fā)部署步驟
服務接口開發(fā)階段往往需要挑選有固定規(guī)則、邏輯性強,又有大量高度重復的場景進行測試驗證,為了快速進行驗證,架構工程師通常會以IDL(接口描述語言)來做服務定義描述,作為開發(fā)鏈路上后續(xù)工作開展的輸入,業(yè)務邏輯開發(fā)階段以統(tǒng)一的標準進行服務實現(xiàn)。
市面上的IDL語言非常多,例如FIDL、Protobuf、vCDL、ARXML、OMG IDL、CANoe FDX等。測試人員對于各
3、種IDL的語法規(guī)則需要零基礎開始學習,在轉換過程中相應的操作也比較復雜、繁瑣,同時出錯率也很高。
如果軟件的架構采用了SOA,對系統(tǒng)中的功能進行了服務化,在前期技術選型,清單定義、架構設計以及中期的業(yè)務邏輯開發(fā)階段都會碰到諸如以下的幾種場景。
圖2-1: 接口和數(shù)據(jù)類型定義Excel
圖2-2: 接口和數(shù)據(jù)類型定義Excel
如上圖簡單示例,其中結構體引用,數(shù)據(jù)類型等信息容易出錯,時常需要反復修改后再重新轉換為ARXML,這個過程費時費力,從效率角度來說也影響了軟件的開發(fā)進度。
場景二:
以太網(wǎng)測試(以SOME/IP為例)時,開發(fā)人員輸出的是Excel,測試人員需要再把Exce
4、l轉成測試軟件可以支持的文件格式,如vCDL,此環(huán)節(jié)工作量極大,正確率也無法保證。
圖3-1: 以太網(wǎng)測試接口定義Excel
圖3-2: 以太網(wǎng)測試接口定義Excel
場景三:
開發(fā)人員在使用DaVinci做架構設計時,為了加快開發(fā)周期,通常情況下會先使用Excel做模板,在Excel中填入接口信息、數(shù)據(jù)類型、SWC定義、SWC與接口關系等信息,然后再由模塊責任人把Excel中的數(shù)據(jù)在DaVinci Developer中做相應的節(jié)點配置和連線關聯(lián),整個過程出錯概率高并且重復性高,需要有工具能依據(jù)Excel模板文件自動生成ARXML文件,實現(xiàn)SWC的轉換及接口與SWC結合工作,用以提
5、高設計效率。
場景四:
在SOA架構中,中間件技術的應用使得應用軟件與底層的操作系統(tǒng)和硬件實現(xiàn)了解耦,我們可以使用 SIL (Software in loop) 技術在系統(tǒng)開發(fā)早期對系統(tǒng)進行功能驗證。SIL 測試的一個重要環(huán)節(jié)是 SIL Adapter 開發(fā)。SIL Adapter 實現(xiàn)了測試系統(tǒng)對被測服務實現(xiàn)的調用。針對各個服務接口的 SIL Adapter代碼結構是相同的,只是接口參數(shù)數(shù)量、名稱、類型方面有少量代碼差異,整個過程重復性也較高,需要有工具能自動將架構設計產(chǎn)出的FIDL、XML、ARXML等文件自動轉化為C++等代碼,同時能根據(jù)文件中的描述/備注等內(nèi)容自動生成插樁代碼,這將
6、縮短驗證周期。
場景五:
SOA架構設計、測試驗證等階段,工程師在使用相關工具軟件時,會使用許多配置文件作為輸入或輸出文件,但是鑒于使用的工具眾多,且文件格式之間的標準并不統(tǒng)一,所使用的各個開發(fā)工具及測試工具也并不能支持所有的格式,所以各個工具間的串聯(lián)并不流暢,影響工程師的工作效率,需要有工具能自動將這些不同格式的文件進行互相轉換以實現(xiàn)工具的高效串聯(lián)。
場景六:
測試用例通常是在Doors或Polarion中管理,測試用例中的測試步驟或測試標準正常是以自然語言的方式描述,在測試執(zhí)行過程中軟件無法識別這些描述性語言,測試人員需要先將這些自然語言轉換為腳本文件,再把測試腳本放到測試工程中執(zhí)
7、行,在測試用例較多的時候這個工作量將會非常龐大,需要有工具能集成相關用例管理軟件,將測試用例能自動轉換為相應的測試軟件的腳本文件,在提高效率的同時減少出錯機率。
場景七:
SOA測試開發(fā)過程大體上需要進行以下幾個步驟:
1. 測試規(guī)范開發(fā):基于需求規(guī)范和測試經(jīng)驗及對實現(xiàn)方案的理解,完成測試規(guī)范的開發(fā)
2. SOA-HIL 測試系統(tǒng)需求分析和測試系統(tǒng)開發(fā):被測對象的引腳和資源定義,HIL硬件及測試軟件運行環(huán)境搭建
3. 測試工程開發(fā):開發(fā)測試工程,實現(xiàn)測試規(guī)范所定義的測試內(nèi)容的自動化/半自動化測試
4. 仿真模型開發(fā):開發(fā)仿真模型,與待測節(jié)點建立接口交互
5. 測試環(huán)境集成調試與測
8、試執(zhí)行:針對某一具體被測對象進行測試環(huán)境搭建、工程集成調試與測試執(zhí)行
以上各個步驟中所需的輸入物類型較多,如:SOA功能的需求規(guī)范、服務接口規(guī)范,資源定義文件,測試范圍定義,ARXML 等類型數(shù)據(jù)庫文件,測試系統(tǒng)第三方編程腳本,測試規(guī)范,通信數(shù)據(jù)庫,通信矩陣文件,被測節(jié)點交互數(shù)據(jù)格式定義等,需要有工具能夠按測試項目進行統(tǒng)一分類管理,同時能夠支持相關輸入物間進行格式轉換,轉換后的結果能夠便捷地加載到相關的測試軟件中或能夠通過網(wǎng)絡自動上傳到配置庫的對應位置下方便后續(xù)操作。
場景八:
目前SOA架構軟件普遍采用敏捷開發(fā)方式進行管理,軟件版本的高頻迭代極大考驗了測試人員工作量和自動化測試能力,目
9、前大多整車廠和零部件供應商基本上已在進行或正在研案持續(xù)集成測試方案來解決這一問題。
如下圖所示,隨著SOA架構的盛行,輸入物或規(guī)范文件已經(jīng)出現(xiàn)了多樣化,但是持續(xù)集成測試推進的前提條件是需要預先將這些測試軟件不可識別的接口文件或用例文件轉換為符合測試軟件定義的規(guī)范腳本,并且能夠與相關的工具進行集成自動轉換。
圖4: 持續(xù)集成測試文件轉換需求示意圖
為什么需要接口描述語言轉換
以上幾個場景都需要測試人員手動錄入或轉換后才能繼續(xù)推動項目進度,此環(huán)節(jié)尤為關鍵,但往往轉換周期較長,且該工作耗時又費力,出錯率也較高,導致經(jīng)常返工,這些問題一直困擾著的開發(fā)/測試人員。
PAVELINK.SOA
10、-Converter介紹
針對以上問題,北匯信息開發(fā)出了接口描述語言轉換工具——PAVELINK.SOA-Converter。
PAVELINK.SOA-Converter是一個基于Eclipse開發(fā)的IDL轉換工具??蓪崿F(xiàn)對常用IDL語言的批量轉換(FIDL、OMG IDL、Protobuf、vCDL、CANoe FDX、ARXML等),例如FIDL轉CANoe FDX,F(xiàn)IDL與Protobuf互轉,同時也支持直接通過Protobuf轉換CANoe FDX等便捷的轉換功能,轉換前可根據(jù)用戶需求自定義輸出目錄、是否忽略注釋信息、是否批量轉換、是否轉換為多個文件等配置。
PAVELINK
11、.SOA-Converter結合測試代理引擎進行自動化回歸測試,可以解決整個鏈路的溝通問題并縮短測試驗證的時間。
用戶通用使用PAVELINK.SOA-Converter實現(xiàn)對文件的快速轉換,相較于人工轉換,不但很大程度上節(jié)約了時間成本,而且保障了轉換的正確率,提高了開發(fā)測試的進度,同時有效降低了維護的成本。
圖5: PAVELINK.SOA-Converter工作示意圖
主要功能如下:
1. 接口語言腳換器: 通過接口語言轉換實現(xiàn)基于SOA架構的軟件設計開發(fā)過程中各工具鏈間的連通。
2. 接口語言編輯器: 通過搭建多個接口語言集中一站式編輯環(huán)境,可以實現(xiàn)對接口文件的二次編輯轉換,同
12、時實現(xiàn)語法校驗、關鍵字提示和補全等功能。
3. 命令行轉換器: 提供無頭(headless)跨平臺的命令行工具,支持命令行調用轉換功能。
4. 配置庫集成: 集成配置庫,自動同步文件,更新提醒,當有源文件更新后實現(xiàn)自動轉換為目標文件。
5. 開放調用接口: 通過文件流監(jiān)聽方式與外部工具集成,為自動化測試提供便利。
6. 插件靈活拓展: 通過插件的靈活拓展,快速實現(xiàn)新的腳本語言轉換。
7. SOA通信方案拓展: 通過對接口描述語言的解讀,自動轉換為服務端(Skeleton)和客戶端(Proxy)框架代碼等。
PAVELINK.SOA-Converter使用說明
PAVELINK.S
13、OA-Converter的使用操作十分便捷,在Eclipse中只需要點擊鼠標,或者使用簡單的命令即可完成轉換工作。
1.Eclipse 插件轉換
在Eclipse中安裝好插件,選擇文件后右擊->SOA-Converter->選擇需要轉換的格式類型即可。
圖6: PAVELINK.SOA-Converter圖形化示意圖
2. 命令行轉換
也可通過命令執(zhí)行轉換。
常用參數(shù)說明:
[-sf]指定轉換的源文件類型。
[-tf]指定轉換后生成的文件類型。
[-sp]指定需要轉換的文件或位置。
[-d]指定轉換后文件輸出位置。
[-dv]忽略版本校驗。
圖7: PA
14、VELINK.SOA-Converter命令行示意圖
3.示例說明
某OEM 基于SOA架構的服務接口測試項目,使用PAVELINK.SOA-Converter實現(xiàn)FIDL轉CANoe系統(tǒng)變量XML,簡化測試驗證過程。
圖8: FIDL轉CANoe系統(tǒng)變量示例
轉換完成后,按步驟在CANoe中直接導入轉換后的XML文件即可,如下圖。
圖9:轉換后的系統(tǒng)變量XML文件導入CANoe軟件示例
u CCU域控制器的測試規(guī)范、腳本開發(fā)及測試服務,使用PAVELINK.SOA-Converter實現(xiàn)FIDL轉SOA功能實現(xiàn)服務端和客戶端C++代碼示例
圖10
15、: SOA通信實現(xiàn)節(jié)點示意圖
如上圖所示,調用PAVELINK.SOA-Converter轉換PREEvision等設計工具輸出的服務接口文件,生成對應的Proxy、Skeleton、Stub代碼。
圖11: 服務接口文件轉換C++示例圖
u 某供應商網(wǎng)聯(lián)類控制器SOA功能規(guī)范測試開發(fā)項目,使用PAVELINK.SOA-Converter實現(xiàn)Excel轉ARXML,接口和SWC關聯(lián)示例
圖12: Excel模板示意圖
轉換后ARXML內(nèi)容如下:
圖13: ARXML截圖示意
更多功能,敬請期待
· IDL文件編輯器,支持實時轉換,即編輯的同時進行轉換結果的預覽,關鍵字提示、關鍵字高亮、語法錯誤提示等;
· 網(wǎng)絡測試模板文件定制,自動化腳本生成;
· 測試工具集成,自動驅動CANoe、ECU-TEST、dSPACE等加載工程執(zhí)行;
· 持續(xù)測試集成,服務接口定義文件變更后自動觸發(fā)測試驗證執(zhí)行。