SOA服務測試內容及環境搭建

SOME/IP協議底層通過乙太網實現，基於service的控制器之間對服務的呼叫流程，以及基於service的控制器和基於訊號(signal)的控制器之間對資訊的傳輸，都需要在軟體開發過程中進行驗證，一般分5個方面測試SOA的效能。

• SD測試：服務的訂閱/釋出測試
• 介面測試：測試服務的每一個Interface，以及Interface對應的引數
• 功能測試：測試特定輸入場景下的SOA功能輸出
• 壓力測試：多個客戶端同時呼叫某個服務的測試
• 系統測試：服務的巢狀呼叫

進行SOA測試首先要能與DUT建立通訊（CAN(FD)/LIN/乙太網），能控制DUT上下電和喚醒，可以參考以下的測試拓撲來監控DUT的通訊，同時模擬傳統的CAN(FD)/LIN網路節點，以及服務的client/server與DUT建立連線，測試DUT實現SOME/IP服務的狀態。

SOA服務介面測試

前置：需要提供服務介面的需求規範、服務矩陣(Ethernet Matrix)、服務資料庫(Arxml)，如果涉及到S2S（service to signal）的介面，也要提供相關的CAN(FD)/LIN資料庫檔案。

測試需求：

以BodyDoorLock服務的RR method介面LockReq為例，DUT作為server，Tester模擬client。介面包含兩個請求引數（Source，Req），和一個響應引數（Result）。

測試規範：

根據需求規範的描述設計測試用例，需要覆蓋介面的通訊機制，介面引數值以及S2S。可以參考思維導圖的方式解析需求，並設計測試用例。

測試工程：

首先，要在CANoe工程中新增SOME/IP資料庫檔案，在CANoe介面點選“Simulation > System and Communication Setup > Import Data Source > 選擇對應的Arxml檔案 > Finish”。然後在“System Explorer”中，繫結BodyDoorLock為SOME/IP服務。

CANoe工程匯入對應的資料庫之後，可以跟DUT自動建立服務的釋出和訂閱，也可以自動的解析服務介面的引數。測試工程師不需要考慮底層邏輯的實現，即服務發現（Service Discovery）和序列化等過程，只需要考慮介面層的使用即可。

其次，在CAPL指令碼中實現介面的呼叫和響應引數的檢查，開發測試指令碼如下：