DDS下的軟件接口測試方法

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

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

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

引言

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

1DDS介紹

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

DDS是/訂閱信息分發(fā)模型衍化而來，繼承了/訂閱模型的優(yōu)點也借鑒了分布式對象模型的異構特點，有著低延遲、高容錯性、高帶寬、傳輸方式靈活的特點。DDS規(guī)范體系結構有兩層，分別是數(shù)據(jù)本地重構（DLRL[4]）層和DCPS[5]層，DLRL層是可選的，DCPS層是DDS的核心和基礎，提供數(shù)據(jù)分發(fā)的基礎結構，保障了數(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]設計了一整套相應的流程，可概括為DCPS初始化，者初始化、訂閱者訂閱、傳遞數(shù)據(jù)四個步驟。在DCPS初始化階段最主要的工作為域的建立、Qos策略設置和傳輸?shù)某跏蓟ぷ?，域存在校驗機制，訂閱者和者的域必須與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)試助手，當測試接口類型為網(wǎng)口時，軟件測試人員會使用Wireshark工具測試TCP或UDP協(xié)議的報文，借助得心應手的測試工具來進行接口測試是軟件測試人員的優(yōu)先選擇，但正如前文所提到的有關DDS的測試工具未被及時開發(fā)與應用，在針對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é)點設置完成主題即可完成與被測對象的關聯(lián)，形成測試節(jié)點-被測對象的成對關系。

3設計步驟

3.1者設計步驟

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

3.2訂閱者設計步驟

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

4接口測試實踐

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

4.1測試節(jié)點做者

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

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

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

4.3測試結果判斷和處理

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

5總結

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

參考文獻

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

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

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

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

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

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