近年來，隨著艦船一體化[1]的工作不斷推進，在艦船上的各種設備紛紛加入主干網絡中，各個設備節點實現了互聯互通，信息處理系統需要將不同設備和不同時間的數據進行整合，數據分發過程隨著數據需求的多樣性而變得更加復雜。為了滿足分布式的實時通信需求，由OMG組織提出的數據分發服務DDS[2]規范有效解決了此問題。隨著DDS規范的逐步完善，越來越多的系統在設計之初就采用了以數據為中心的信息發布/訂閱通信模型，以滿足不同設備的通信需求，但與此同時，DDS相關的軟件接口測試方法卻發展緩慢，相應的測試工具并未被及時開發與應用。針對此情況，分析其模型特點和分發流程，提出了一種DDS接口測試方法，經過實踐檢驗，可以有效地對采用DDS規范的系統進行軟件接口測試[3]。

　　1DDS介紹

　　1.1數據分發服務(DDS)

　　DDS是發布/訂閱信息分發模型衍化而來，繼承了發布/訂閱模型的優點也借鑒了分布式對象模型的異構特點，有著低延遲、高容錯性、高帶寬、傳輸方式靈活的特點。DDS規范體系結構有兩層，分別是數據本地重構(DLRL[4])層和DCPS[5]層，DLRL層是可選的，DCPS層是DDS的核心和基礎，提供數據分發的基礎結構，保障了數據的傳輸。DCPS層創建了全局數據空間(GDS)的概念，所有的數據對象都存在于空間中，可自動和異步地向GDS讀取/寫入數據,發布者和訂閱者可隨時加入和離開GDS,發布者和訂閱者通過主題進行匹配所需的數據類型，通過檢查和校驗機制后完成數據的傳送。

　　1.2DDS的分發流程簡述

　　DDS為了實現數據的分發[6]設計了一整套相應的流程，可概括為DCPS初始化，發布者初始化、訂閱者訂閱、傳遞數據四個步驟。在DCPS初始化階段最主要的工作為域的建立、Qos策略設置和傳輸的初始化工作，域存在校驗機制，訂閱者和發布者的域必須與DCPS層的域一致。發布者定義數據類型、生成主題，訂閱者查找主題并完成訂閱，經過中間檢查機制檢查，符合連接規則后發布者和訂閱者將建立連接，發布者通過DataWriter寫入最新數據，DCPS進行數據分發，訂閱者通過DataReader讀取最新數據，通過以上的流程就實現了數據的分發，數據有效地從發布者傳遞到訂閱者。

　　2軟件接口測試常用方法

　　2.1借助測試工具

　　軟件測試時如測試接口類型為串口，軟件測試人員往往會使用串口調試助手，當測試接口類型為網口時，軟件測試人員會使用Wireshark工具測試TCP或UDP協議的報文，借助得心應手的測試工具來進行接口測試是軟件測試人員的優先選擇，但正如前文所提到的有關DDS的測試工具未被及時開發與應用，在針對DDS進行軟件接口測試時，面臨著無測試工具可用的尷尬局面。

　　2.2自研工具

　　根據對以數據為中心的發布訂閱模式進行分析，由于系統內均為分布式節點，自然可以聯想到將測試節點加入全局數據空間進行全局通信，得益于DDS異步通信方式的特性，測試節點的加入不會影響系統原有的分布式節點，并且加入的測試節點不受數量上的制約，可以加入多個測試節點來并行測試以提升測試效率，這有利于減少接口測試在整個測試周期中的時間占比。根據對DDS的分發流程的分析，全局數據空間是根據主題進行數據分發，測試節點設置完成主題即可完成與被測對象的關聯，形成測試節點-被測對象的成對關系。

　　3設計步驟

　　3.1發布者設計步驟

　　(1)配置本機ip和廣播地址。(2)使用接口定義語言(idl)定義數據類型，推薦創建一個結構體，根據被測報文定義所需的成員變量及其數據類型并做好相應的注釋。(3)使用腳本，生成輔助文件。(4)創建工程，將輔助文件添加至工程文件中。(5)編寫publisher代碼。此步驟會先將域初始化，如果域初始化失敗將會直接報錯處理，域初始化成功再將發布者加入至所需的域中，根據被測報文將每個成員變量都進行賦值，將主題設置與訂閱端主題一致，Qos策略可以按需配置，主要有BEST_EFFORT盡力而為模式和RELIABLE可靠模式，無明確要求時可選BEST_EFFORT盡力而為模式，一直重復發送報文觀察現象即可，如果沒有發送周期需求，建議設置2s-3s的發送間隔，防止接收端接收大量的數據從而產生異常，2s-3s的發送周期也適合軟件測試人員觀察被測對象是否達到了預期的結果。(6)編譯工程，運行程序查看發送結果。此處建議添加對發送結果的反饋，如果發送失敗可將錯誤代碼進行打印，方便排查錯誤。發送成功后就可根據用例設計情況，改變成員變量的賦值，重新編譯后發送直至用例全部執行結束。

　　3.2訂閱者設計步驟

　　(1)配置本機ip和廣播地址。(2)使用接口定義語言(idl)定義數據類型。(3)使用腳本，生成輔助文件。(4)創建工程，將輔助文件添加至工程文件中。(5)編寫subscriber代碼。域的初始化、主題設置和Qos策略設計與前文一致，將所需的報文中的成員變量打印輸出。(6)編譯工程，運行程序查看接收結果。此處也同樣建議添加對接收結果的反饋，避免由DDS分發錯誤而導致的接收異常。

　　4接口測試實踐

　　在配置項和系統測試時，軟件測試人員常常會選擇黑盒測試方法來進行軟件測試，當軟件測試人員需要測試采用DDS規范的接口時，測試目標為軟件接口與受控文檔協議的一致性，在測試環境搭建完成并分析環境差異性后，可以分為2種情況進行討論。

　　4.1測試節點做發布者

　　根據前文中的發布者設計步驟完成一個最小單元的發布者樣例，保證樣例通信正常，可以正常發布報文數據，排除由數據分發服務或樣例引起的測試異常中止情況，使用受控文檔協議補充完成所有成員變量的定義并賦合理初始值。在實際測試時，往往會有多個域的多條報文需要測試，編寫publisher代碼時可以一次性將所有域的所有報文編寫完成，也可以僅將一個域內的所有報文編制完成，依據單個用例覆蓋最小化原則，測試時一次僅選擇一個域內一條報文的某一字段進行測試，依次執行測試用例觀察預期結果。

　　4.2測試節點做訂閱者

　　根據前文中的訂閱者設計步驟完成一個最小單元的訂閱者樣例，保證樣例通信正常，可以正常接收報文數據，使用受控文檔協議補充完成所有成員變量的定義。編寫subscriber代碼時推薦一次性將所有域的所有報文編寫完成，根據實際測試需要，選擇性地接收所需報文進行打印，依次執行測試用例觀察預期結果。

　　4.3測試結果判斷和處理

　　由于使用黑盒測試的方式，預期結果也可能是多樣的，測試節點發布者依據文檔協議發送了報文，若測試對象有人機界面，可以根據人機界面顯示情況判斷是否達到了預期結果，若測試對象無人機界面，但有回送報文，需要添加訂閱者測試節點接收回送報文，可根據回送報文判斷是否達到了預期結果，根據預期結果，即可有效定位測試缺陷。但也存在一些特殊情況，若報文發送完成后，測試對象無響應，則應按照發布者、測試環境、被測對象的順序排查問題，使用Wireshark等網絡抓包工具判斷發布者是否成功發布，檢查發布者的成員變量定義是否正確，賦值是否在有效范圍之外，然后排除鏈路故障、丟包、硬件損壞等一系列測試環境異常情況，最后可引入白盒測試的方式定位被測對象的測試缺陷，即可分析出是由于文檔問題還是軟件問題引起的測試對象無響應的情況。

　　5總結

　　在軟件接口測試中，由于采用DDS規范的測試工具未被開發，就需要軟件測試人員使用自研測試工具完成接口測試。從DDS的特點和分發流程入手，對自研工具的發布者和訂閱者進行了詳細設計論述，通過實踐檢驗，可以有效地對采用DDS規范的軟件接口完成軟件測試，也為后續開發DDS測試工具奠定了基礎。由于此方法要求軟件測試人員需要熟練掌握編程技巧，雖然可以多個測試節點并行測試互不干擾，但是整體的測試效率仍低于預期，后續可以考慮研究針對采用DDS接口的軟件自動化測試方法。

　　參考文獻

　　[1]楊楚平,趙剛,馬超.艦船一體化網絡應用研究[J].艦船科學技術,2019,41(19):168-172.

　　[3]何瓊月.軟件測試中接口測試概述與實踐[J].電子測試,2021(02):80-81+75.

　　[4]周平,蘇銀科,沈超.基于DDS的分布式數字仿真系統設計與實現[J].系統仿真學報,2014,26(08):1678-1683+1691.

　　《基于DDS的軟件接口測試方法研究》來源：《電子測試》，作者：童佳鋒