作者 | 梵高先生

小編 | 不吃豬頭肉

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

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

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

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

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

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

關于性能測試，由于 DDS 的性能很大程度上取決于硬件平臺的性能和資源情況，以及操作系統的調度和管理機制，故在測試服務器中得到的性能測試結果與實際系統的性能表現可能相差很大，故本次測試不包含性能測試。

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

圖2-測試結果概覽

問題示例

功能缺失

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

行為錯誤

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

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

異常終止

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