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

　　1DDS介紹

　　1.1數(shù)據(jù)分發(fā)服務(wù)(DDS)

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

　　1.2DDS的分發(fā)流程簡述

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

　　2軟件接口測試常用方法

　　2.1借助測試工具

　　軟件測試時(shí)如測試接口類型為串口，軟件測試人員往往會使用串口調(diào)試助手，當(dāng)測試接口類型為網(wǎng)口時(shí)，軟件測試人員會使用Wireshark工具測試TCP或UDP協(xié)議的報(bào)文，借助得心應(yīng)手的測試工具來進(jìn)行接口測試是軟件測試人員的優(yōu)先選擇，但正如前文所提到的有關(guān)DDS的測試工具未被及時(shí)開發(fā)與應(yīng)用，在針對DDS進(jìn)行軟件接口測試時(shí)，面臨著無測試工具可用的尷尬局面。

　　2.2自研工具

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

　　3設(shè)計(jì)步驟

　　3.1發(fā)布者設(shè)計(jì)步驟

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

　　3.2訂閱者設(shè)計(jì)步驟

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

　　4接口測試實(shí)踐

　　在配置項(xiàng)和系統(tǒng)測試時(shí)，軟件測試人員常常會選擇黑盒測試方法來進(jìn)行軟件測試，當(dāng)軟件測試人員需要測試采用DDS規(guī)范的接口時(shí)，測試目標(biāo)為軟件接口與受控文檔協(xié)議的一致性，在測試環(huán)境搭建完成并分析環(huán)境差異性后，可以分為2種情況進(jìn)行討論。

　　4.1測試節(jié)點(diǎn)做發(fā)布者

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

　　4.2測試節(jié)點(diǎn)做訂閱者

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

　　4.3測試結(jié)果判斷和處理

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

　　5總結(jié)

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

　　參考文獻(xiàn)

　　[1]楊楚平,趙剛,馬超.艦船一體化網(wǎng)絡(luò)應(yīng)用研究[J].艦船科學(xué)技術(shù),2019,41(19):168-172.

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

　　[4]周平,蘇銀科,沈超.基于DDS的分布式數(shù)字仿真系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)[J].系統(tǒng)仿真學(xué)報(bào),2014,26(08):1678-1683+1691.

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