作者 | 梵高先生

小編 | 不吃豬頭肉

在上一篇文章中，我們對 DDS 協(xié)議測試的策略、方法和工具進行了詳細的介紹。本文旨在進一步探討如何利用這些方法和工具搭建實際的測試環(huán)境，并執(zhí)行測試，進而揭示可能遇到的各類問題。

被測協(xié)議棧簡介
在本次測試中，被測協(xié)議棧選擇了一個在汽車行業(yè)內(nèi)廣泛使用的開源 DDS 產(chǎn)品。
近年來隨著開源軟件社區(qū)的不斷發(fā)展和成熟，越來越多的整車廠在選擇 DDS 協(xié)議棧實現(xiàn)時，開始青睞開源產(chǎn)品。相比商業(yè)化的 DDS 協(xié)議棧，開源產(chǎn)品具有顯著的成本優(yōu)勢。此外，使用開源產(chǎn)品還可以讓整車廠獲得更大的自主可控性，以便根據(jù)自身需求對協(xié)議棧進行定制和優(yōu)化。
然而天下沒有免費的午餐，選擇開源 DDS 協(xié)議棧也意味著使用者必須承擔起產(chǎn)品質(zhì)量的責任。與商業(yè)化產(chǎn)品不同，開源產(chǎn)品通常沒有專門的團隊負責質(zhì)量保證。因此，開源 DDS 協(xié)議棧的使用者必須投入額外的精力和資源，甚至組建專門的軟件團隊，來全面評估、測試和維護所選擇的開源產(chǎn)品，以確保其功能和性能滿足汽車行業(yè)的嚴苛要求。
本篇文章中我們試圖準確地識別出可能存在的問題，希望為汽車行業(yè)用戶在選擇開源 DDS 協(xié)議棧時提供實用的參考。

測試環(huán)境搭建
被測的 DDS 協(xié)議棧部署在一臺運行 Ubuntu 操作系統(tǒng)的 x 86 服務(wù)器上。這種部署方式能夠為 DDS 協(xié)議棧提供一個簡單、穩(wěn)定，且一致的運行環(huán)境，避免資源或網(wǎng)絡(luò)配置錯誤等原因?qū)е碌臏y試結(jié)果不可信。
同時，為了全面評估 DDS 協(xié)議棧的功能和性能，我們在 DDS 之上部署了兩個專門設(shè)計的測試應(yīng)用程序。這兩個應(yīng)用程序的主要目的是模擬真實場景下的應(yīng)用程序?qū)?DDS 接口的調(diào)用，以驗證 DDS 能夠正確地處理各種請求并返回預(yù)期的結(jié)果。通過這種方式, 可以全面檢驗 DDS 的接口是否符合 OMG DDS 標準，以及是否能夠滿足汽車行業(yè)的特定需求。
為了實現(xiàn)對測試過程的自動化控制和管理，我們在上位機中開發(fā)了一套專門的測試腳本。這些腳本負責向 DDS 測試應(yīng)用程序發(fā)送各種測試指令，根據(jù)預(yù)定的邏輯對測試應(yīng)用程序的行為進行編排和調(diào)度。測試過程全自動化，無需任何人工干預(yù)，能夠確保測試過程的一致性和可重復(fù)性。
此外，為了方便工程師對測試用例進行管理和監(jiān)控，上位機軟件還提供了一個直觀的圖形化界面。通過這個界面，測試人員可以輕松地創(chuàng)建、編輯和組織測試用例，并實時監(jiān)控測試的執(zhí)行狀態(tài)和結(jié)果。
圖1-DDS測試環(huán)境搭建
需要強調(diào)的是，測試環(huán)境可以根據(jù)用戶的具體需求進行靈活地配置。比如將 DDS 測試程序部署在一個或多個真實的 ECU 中，以幫助我們發(fā)現(xiàn)系統(tǒng)性的網(wǎng)絡(luò)配置問題、兼容性問題或性能問題等，包括防火墻、IP 地址、端口號、TSN 約束、時間同步、網(wǎng)絡(luò)拓撲結(jié)構(gòu)問題，DDS 中間件與不同硬件和軟件平臺之間的兼容性問題，也包括吞吐量、延遲、資源占用等指標。從而全面評估 DDS 分布式系統(tǒng)在實際應(yīng)用場景下的可靠性、兼容性和性能表現(xiàn)，為系統(tǒng)的開發(fā)和優(yōu)化提供重要的依據(jù)。

測試用例介紹
測試用例覆蓋了 OMG DDS 規(guī)范中定義的所有軟件接口，共 406條測試用例，內(nèi)容如下：

?接口行為測試，包括正常調(diào)用時的行為測試，以及錯誤調(diào)用的故障行為測試，共計 353 條用例

?QoS 測試，即 OMG DDS 中定義的各項 QoS 的功能測試，共計 53 條用例

關(guān)于性能測試，由于 DDS 的性能很大程度上取決于硬件平臺的性能和資源情況，以及操作系統(tǒng)的調(diào)度和管理機制，故在測試服務(wù)器中得到的性能測試結(jié)果與實際系統(tǒng)的性能表現(xiàn)可能相差很大，故本次測試不包含性能測試。

測試結(jié)果分析
概覽本次測試共計執(zhí)行 406 個測試用例，通過194個，失敗 212 個，通過率為 47.78%。如下為各模塊的通過情況。

圖2-測試結(jié)果概覽

問題示例

功能缺失

如下表格列出了部分當前版本 DDS 缺失的接口。這些缺失的接口對于 DDS 分布式系統(tǒng)的功能和性能具有直接或間接的影響。重要的是，開發(fā)者文檔可能并未明確指出這些接口功能的缺失，這種情況可能會對系統(tǒng)的穩(wěn)定性和可靠性帶來潛在風險。因此，用戶在使用 DDS 時需要對這些潛在的缺陷保持警覺，并采取相應(yīng)的預(yù)防措施。此外，用戶應(yīng)當積極參與開源社區(qū)討論，關(guān)注產(chǎn)品的更新日志，以便及時了解和補充這些關(guān)鍵接口的功能，從而降低系統(tǒng)運行中的不確定性和風險。表 1: 功能缺失問題示例
圖3-功能缺失問題的測試報告示例

行為錯誤

當開發(fā)者根據(jù)官方文檔調(diào)用特定 API 時，軟件表現(xiàn)出的行為與文檔描述不一致。這種不一致性可能表現(xiàn)為返回錯誤的結(jié)果、觸發(fā)未預(yù)期的副作用或完全無響應(yīng)。這種情況下，開發(fā)者不得不投入大量的時間去排查和定位問題。表 2：API 行為錯誤示例

圖4-行為錯誤測試報告示例

異常終止

此類問題指的是當應(yīng)用程序在某些場景下調(diào)用特定接口時，DDS 中間件出現(xiàn)異常終止。這類問題的嚴重性在于其難以被發(fā)現(xiàn)、排查和修復(fù)。問題的隱蔽性在于異常通常只在特定的條件下觸發(fā)，這些條件可能包括特定的數(shù)據(jù)模式、并發(fā)級別或資源使用情況，使得在常規(guī)測試中難以觸發(fā)和識別。同時，即使問題被成功識別，修復(fù)工作也同樣困難重重，這需要精確修改復(fù)雜的代碼邏輯，還需要確保不會對 DDS 的其他功能造成負面影響。
由于 DDS 中間件作為系統(tǒng)的基礎(chǔ)軟件，其穩(wěn)定性對整個系統(tǒng)的運行至關(guān)重要。同時，基礎(chǔ)軟件的不穩(wěn)定性會對上層應(yīng)用和最終用戶產(chǎn)生連鎖反應(yīng)，極大地影響整個系統(tǒng)的質(zhì)量和用戶體驗。因此，解決 DDS 中間件的異常終止問題，不僅是提升軟件質(zhì)量的技術(shù)挑戰(zhàn)，也是確保系統(tǒng)整體穩(wěn)定性和可靠性的重要一環(huán)。表 3: DDS 軟件異常終止問題示例總結(jié)
經(jīng)過本篇文章的介紹，相信讀者已經(jīng)對DDS的協(xié)議測試以及可能存在的問題有了大概的了解。
在敏捷開發(fā)模式下，軟件需求不斷增加，軟件系統(tǒng)的規(guī)模和復(fù)雜度也在不斷增長。然而，許多關(guān)鍵問題（尤其是性能問題）只有在軟件達到一定規(guī)模和復(fù)雜度后才會暴露出來。一旦發(fā)現(xiàn)這些問題，修復(fù)的成本往往非常高昂，因為任何基礎(chǔ)軟件的改動可能會影響到整個系統(tǒng)，牽一發(fā)而動全身。
相比之下，如果在項目早期就能夠模擬實際的應(yīng)用場景，并對 DDS 進行全面的功能和性能測試，開發(fā)團隊可以深入了解 DDS 的行為特點，甚至軟件缺陷，識別性能瓶頸，從而及時調(diào)整設(shè)計，優(yōu)化實現(xiàn)。這種“前置”的測試方法不僅能夠顯著降低后期的修復(fù)成本，能夠提高整個系統(tǒng)的質(zhì)量和可靠性，幫助系統(tǒng)應(yīng)對未來的挑戰(zhàn)。
本文介紹了南京臻融科技有限公司（以下簡稱“臻融科技”）開發(fā)的DDS協(xié)議測試工具。臻融科技在過去十年里，一直致力于DDS產(chǎn)品及其相關(guān)工具鏈的自主研發(fā)，并且在國內(nèi)關(guān)鍵行業(yè)領(lǐng)域取得了最高的市場份額。這款DDS協(xié)議測試工具在DDS研發(fā)過程中已經(jīng)歷了近十年的不斷迭代，證明了其產(chǎn)品的成熟性和可靠性。臻融科技與北匯信息的合作，旨在將這套工具引入汽車行業(yè)，以協(xié)助客戶建立DDS測試能力，提供高品質(zhì)的測試服務(wù)和相關(guān)培訓(xùn)，進而加快DDS在汽車行業(yè)的推廣和應(yīng)用。