DDS下的軟件接口測試方法

前言：想要寫出一篇引人入勝的文章？我們特意為您整理了DDS下的軟件接口測試方法范文，希望能給你帶來靈感和參考，敬請閱讀。

摘要：隨著艦船一體化工作的推進，各個異構(gòu)設(shè)備節(jié)點統(tǒng)一采用數(shù)據(jù)分發(fā)服務(wù)（DataDistributionService）規(guī)范實現(xiàn)了信息的互聯(lián)互通，但對dds規(guī)范相關(guān)的軟件接口測試方法的研究卻相對遲緩?；诖饲闆r，通過分析DDS規(guī)范的模型特點和分發(fā)流程，提出一種基于DDS的軟件接口測試方法，并將測試方法的設(shè)計步驟進行了闡述，通過對軟件接口測試情況的討論，經(jīng)過實踐檢驗，解決了對采用DDS規(guī)范的接口測試問題。

關(guān)鍵詞：數(shù)據(jù)分發(fā)服務(wù)；測試方法；接口測試

引言

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

1DDS介紹

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

DDS是/訂閱信息分發(fā)模型衍化而來，繼承了/訂閱模型的優(yōu)點也借鑒了分布式對象模型的異構(gòu)特點，有著低延遲、高容錯性、高帶寬、傳輸方式靈活的特點。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)建了全局數(shù)據(jù)空間(GDS)的概念，所有的數(shù)據(jù)對象都存在于空間中，可自動和異步地向GDS讀取/寫入數(shù)據(jù),者和訂閱者可隨時加入和離開GDS,者和訂閱者通過主題進行匹配所需的數(shù)據(jù)類型，通過檢查和校驗機制后完成數(shù)據(jù)的傳送。

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

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

2軟件接口測試常用方法

2.1借助測試工具

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

2.2自研工具

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

3設(shè)計步驟

3.1者設(shè)計步驟

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

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

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

4接口測試實踐

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

4.1測試節(jié)點做者

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

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

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

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

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

5總結(jié)

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

參考文獻

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

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

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

[5]裘楷,沈棟,李娜,吳宇紅.基于DCPS模型的數(shù)據(jù)分發(fā)服務(wù)DDS的研究[J].電子科技,2006(11):68-71+76.

[6]廖闖,鄭剛,高騫.船舶信息系統(tǒng)數(shù)據(jù)分發(fā)服務(wù)研究[J].計算機工程,2013,39(09):94-97+113.

作者：童佳鋒 單位：中國船舶重工集團公司第七一五研究所