基于LoadRunner自動化應用程序接口的艦船裝備軟件測試系統(tǒng)設計與實現(xiàn)

韓新宇,何 偉,張 凱

(中國船舶工業(yè)集團公司軟件質(zhì)量與可靠性測評中心，北京 100081)

?

基于LoadRunner自動化應用程序接口的艦船裝備軟件測試系統(tǒng)設計與實現(xiàn)

韓新宇,何 偉,張 凱

(中國船舶工業(yè)集團公司軟件質(zhì)量與可靠性測評中心，北京 100081)

針對艦船裝備軟件接口交互信息量大，利用現(xiàn)有動態(tài)測試技術(shù)對此類軟件開展測試工作時效率較低，自動化測試水平亟待提高的現(xiàn)狀，歸納分析了艦船裝備軟件測試系統(tǒng)的主要能力需求，研究了接口協(xié)議形式化、測試用例自動生成、測試用例自動驅(qū)動、通信接口轉(zhuǎn)換等關(guān)鍵技術(shù)，并以上述技術(shù)為基礎給出了艦船裝備軟件測試系統(tǒng)的體系架構(gòu)設計方案，進而實現(xiàn)了一種基于LoadRunner自動化應用程序接口(LoadRunner Automation API)的艦船裝備軟件測試系統(tǒng)，為艦船裝備軟件提供了一種可行的自動化測試手段；該測試系統(tǒng)主要包括測試管理模塊、測試用例生成模塊、測試用例驅(qū)動模塊和數(shù)據(jù)收集與分析模塊；采用該測試系統(tǒng)能夠有效提高艦船裝備軟件的測試效率。

測試用例；自動化測試；LoadRunner自動化應用程序接口；組件

0 引言

隨著信息集成需求的日益增加，艦船裝備軟件接口交互信息量越來越大。對于此類軟件而言，在動態(tài)測試過程中，大量工作用于測試數(shù)據(jù)的準備和驅(qū)動。傳統(tǒng)的做法是，測評機構(gòu)根據(jù)接口協(xié)議說明利用軟件研制單位提供的模擬器產(chǎn)生報文格式，然后手工準備測試數(shù)據(jù)，再利用通用的測試工具(如LoadRunner、各種調(diào)試助手)作為數(shù)據(jù)驅(qū)動工具實施測試。由于研制單位提供的模擬器只能產(chǎn)生固定格式的正常報文，無法產(chǎn)生異常、邊界等測試數(shù)據(jù)，且調(diào)試助手等難以模擬多個接口邏輯關(guān)系[1]，測試人員往往需要自行開發(fā)數(shù)據(jù)生成和驅(qū)動工具[2]。對于以軟件測評為主要業(yè)務的專業(yè)軟件測評機構(gòu)而言，這種做法費時費力，難以形成通用的測試能力，而人工編寫測試數(shù)據(jù)，工作量繁雜，影響測試效率和測試質(zhì)量，因此迫切需要研制一種通用的艦船裝備軟件測試系統(tǒng)[3]。根據(jù)本文研究內(nèi)容設計并實現(xiàn)的艦船裝備軟件測試系統(tǒng)解決了接口協(xié)議形式化、測試用例自動生成、測試腳本的自動生成、接口轉(zhuǎn)換等多項技術(shù)難題，可針對被測對象做出快速的測試設計，對整個測試過程提供統(tǒng)一的管理、設計、驅(qū)動和分析能力。

1 測試系統(tǒng)的需求

針對目前艦船裝備軟件測試過程中存在的問題，測試系統(tǒng)的主要能力需求如下：

1)接口協(xié)議形式化能力。測試系統(tǒng)應具備可視化接口協(xié)議編輯器，實現(xiàn)對被測軟件接口協(xié)議的形式化建模和編輯功能，包括字段的數(shù)據(jù)類型、長度、最低有效位(LSB)、范圍等信息。

2)測試用例自動生成建模能力。測試系統(tǒng)應具備可視化測試剖面模型編輯器，能夠結(jié)合接口協(xié)議形式化結(jié)果，實現(xiàn)對測試步驟的定義。

3)測試用例自動生成能力。測試系統(tǒng)應能夠自動生成測試用例所需的測試數(shù)據(jù)和測試步驟，通過遍歷測試剖面中所有可能的測試路徑，結(jié)合路徑上測試步驟的定義，生成滿足測試覆蓋要求的測試用例，且支持典型的執(zhí)行邏輯(順序、周期、延遲、反饋、同步)。

4)測試用例驅(qū)動能力。測試系統(tǒng)應能根據(jù)測試用例自動生成測試腳本和可驅(qū)動測試數(shù)據(jù)，并完成多種接口邏輯關(guān)系下的信息交互，覆蓋艦船裝備常用的接口類型(如RS232、RS422、RS485、CAN總線以及以太網(wǎng)接口)。

5)數(shù)據(jù)收集與監(jiān)測能力。測試系統(tǒng)應提供可視化的圖形用戶界面，完成測試數(shù)據(jù)收集方案配置功能，確定數(shù)據(jù)收集的要求、方法、時機以及數(shù)據(jù)的分析功能(包括數(shù)據(jù)的篩選、判斷與趨勢分析)。

2 關(guān)鍵技術(shù)研究

2.1 接口協(xié)議形式化技術(shù)

接口協(xié)議形式化用于建立接口協(xié)議的基本信息模型、元素信息模型和執(zhí)行邏輯模型。基本信息模型由接口類型、協(xié)議名稱、發(fā)送方地址、接收方地址和數(shù)據(jù)長度等信息構(gòu)成。元素信息模型包含了元素名稱、元素類型、字節(jié)數(shù)和有效值信息。其中元素類型信息較為復雜，其模型見表1。執(zhí)行邏輯模型用以描述報文收發(fā)的執(zhí)行邏輯，特征屬性有：1)收發(fā)標識；2)執(zhí)行條件標識(0-錯誤、1-順序、2-周期、3-延遲、4-反饋、5-同步)；3)周期特性：周期間隔、停止條件、停止時間、停止周期數(shù)、停止消息；4)反饋特性：反饋條件、反饋變量名稱、反饋變量數(shù)據(jù)特性、反饋消息；5)同步特性：同步步驟、同步時間；6)是否有返回值。

測試系統(tǒng)采用XML語言對接口協(xié)議進行形式化描述，具體的操作和數(shù)據(jù)信息分別記錄到XML文件的子結(jié)點中，一棵XML數(shù)據(jù)樹就能夠表示一個完整的接口協(xié)議。

2.2 測試用例自動生成技術(shù)

在測試用例自動生成階段，首先需要進行測試用例建模。本研究提出了一種基于軟件任務的測試用例生成模型(以下稱軟件任務模型)，其組成包括系統(tǒng)的使用者和參與者、功能模塊、功能點、操作和輸入輸出數(shù)據(jù)。構(gòu)造該模型包括以下4個步驟：

1)構(gòu)造系統(tǒng)使用視圖：確定系統(tǒng)的使用者、參與者和被測系統(tǒng)，利用使用視圖描述被測對象，即從使用的角度看待和描述被測系統(tǒng)；

2)構(gòu)造功能模型：根據(jù)軟件需求規(guī)格說明，獲取系統(tǒng)的功能并逐層分解，將其分解為最小功能點的集合；

3)構(gòu)造操作模型：根據(jù)軟件需求規(guī)格說明，將每一個功能點的實現(xiàn)分解為具體的操作；

4)構(gòu)造任務模型：遍歷操作模型，將其中的每個操作序列單獨提取出來作為一個任務流，所有任務流的集合稱為任務模型。生成任務模型時主要可以遵循4種覆蓋準則。

準則1(節(jié)點覆蓋準則)：遍歷完成后，所有的操作節(jié)點至少被執(zhí)行一次，這是最基本的覆蓋準則。

準則2(遷移邊覆蓋準則)：遍歷完成后，所有的遷移邊至少被覆蓋一次。

準則3(邏輯路徑覆蓋準則)：遍歷完成后，各邏輯路徑至少被執(zhí)行一次。采用此覆蓋準則時，可對模型中循環(huán)體的執(zhí)行次數(shù)進行限定，例如只覆蓋兩種情況，即不進入循環(huán)體和進入循環(huán)體至少1次。

準則4(代表值覆蓋準則)：對于各邏輯控制節(jié)點上的每個控制變量，依據(jù)指定的測試策略分別選定一個有限的輸入值集合，稱作代表值集合，則遍歷完成后各邏輯控制節(jié)點的每個代表值集合中所有取值至少被覆蓋1次。

測試用例生成包括測試步驟生成和測試數(shù)據(jù)生成。測試步驟生成的總體策略是：根據(jù)軟件任務模型，采用圖的遍歷技術(shù)，生成被測件及外圍設備的交互流程，即測試用例所包含的各步驟。測試步驟生成包括4個階段，如圖1所示。異常測試步驟生成考慮：1)正常操作流程中缺少步驟；2)正常操作流程中某些步驟的輸入時序不符合要求(包括提前或滯后)；3)正常操作流程中某些操作的輸入變量不正確。

測試數(shù)據(jù)生成主要考慮不同測試類型的需要，如功能測試采用等價類劃分、錯誤推測、因果圖等方法給出相應的測試數(shù)據(jù)，邊界測試采用邊界值分析法給出所需測試數(shù)據(jù)，接口測試根據(jù)接口的特性給出相應的測試數(shù)據(jù)，性能測試根據(jù)性能需求的測試場景生成所需的測試數(shù)據(jù)。

表1 接口協(xié)議元素類型模型

圖1 測試步驟生成過程

2.3 測試用例自動驅(qū)動技術(shù)

考慮到艦船裝備軟件測試用例的輸入以接口報文居多，且字段取值具有不確定性，測試系統(tǒng)采用腳本驅(qū)動技術(shù)，即：首先根據(jù)需求生成測試腳本，實現(xiàn)各種測試場景，然后通過執(zhí)行測試腳本，檢查被測軟件在不同場景下運行結(jié)果是否正確。本研究主要利用LoadRunner測試腳本的穩(wěn)定驅(qū)動能力，將測試輸入數(shù)據(jù)存儲在數(shù)據(jù)文件里，測試腳本則存放用例步驟信息，執(zhí)行測試時從文件中讀取測試輸入數(shù)據(jù)，以便復用同一個腳本執(zhí)行不同的測試場景。其中測試數(shù)據(jù)和測試腳本的自動生成由測試系統(tǒng)來實現(xiàn)，腳本的解析和執(zhí)行由LoadRunner工具來實現(xiàn)。

2.3.1 測試腳本的自動生成

測試腳本的生成方法包括建立測試用例腳本框架集、定義腳本關(guān)鍵字和關(guān)鍵字實例化3個技術(shù)要點，而且要符合LoadRunner工具對測試腳本的語法要求。

測試用例腳本框架是指根據(jù)測試用例執(zhí)行行為預先定義的具有一定流程控制功能的腳本單元。測試用例執(zhí)行行為與測試腳本的執(zhí)行邏輯密切相關(guān)，因此可以根據(jù)對測試用例行為的分類結(jié)果建立測試用例腳本框架集。對測試行為的分類主要從以下幾個方面考慮：

1)按照數(shù)據(jù)傳輸方向分：只有輸入行為、只有輸出行為、既有輸入行為也有輸出行為；

2)按照時間特性分：如周期行為、事件行為(如反饋行為、中斷行為等)；

3)按照傳輸條件分：無條件行為、有條件執(zhí)行行為。

腳本關(guān)鍵字[4]是根據(jù)測試用例模型要素，在測試框架集中定義的變量、函數(shù)、語句等信息。腳本關(guān)鍵字包括兩類：一類是固定關(guān)鍵字，標識了腳本框架的類型、關(guān)鍵分支點，此類關(guān)鍵字是選擇與調(diào)整腳本框架的依據(jù)；另一類是可變關(guān)鍵字，標識了用例要素描述信息，需要替換為具體的用例要素值。

關(guān)鍵字實例化就是用測試用例要素值替換測試腳本關(guān)鍵字的過程。在測試用例模型完備且關(guān)鍵字定義清晰的基礎上，根據(jù)用例要素的描述在腳本框架中查找與之對應的關(guān)鍵字，并完成替換。

2.3.2 驅(qū)動數(shù)據(jù)的自動生成

驅(qū)動數(shù)據(jù)是指符合LoadRunner工具buf數(shù)據(jù)格式的測試數(shù)據(jù)，其生成過程包括數(shù)據(jù)驅(qū)動需求要素的獲取、接口報文數(shù)據(jù)的生成和轉(zhuǎn)換3個步驟：

1)數(shù)據(jù)需求要素獲?。簩π问交瘻y試用例的抽象描述進行解析，識別出對所需測試數(shù)據(jù)的名稱、長度、類型、取值范圍、最低有效位等要素的描述信息，統(tǒng)稱為數(shù)據(jù)驅(qū)動需求要素信息。

2)接口報文數(shù)據(jù)生成：利用測試用例的數(shù)據(jù)驅(qū)動要素生成所需接口報文數(shù)據(jù)。對于離散變量可從預先設定的常量池中取值作為接口報文數(shù)據(jù)；對于連續(xù)型變量可采用隨機測試數(shù)據(jù)生成方法，根據(jù)變量的取值范圍隨機生成接口報文數(shù)據(jù)；如果軟件開發(fā)方提供被測軟件的源代碼，還可以利用啟發(fā)式搜索算法生成接口報文數(shù)據(jù)[5]。

3)接口報文數(shù)據(jù)轉(zhuǎn)換：在測試數(shù)據(jù)生成過程中需要解決兩類數(shù)據(jù)轉(zhuǎn)換問題。一類是實際物理量的轉(zhuǎn)換，將接口報文中使用的實際物理量映射為LoadRunner可直接驅(qū)動的十六進制數(shù)據(jù)；另一類是狀態(tài)數(shù)據(jù)的轉(zhuǎn)換，將接口報文中使用的“狀態(tài)位”信息按要求進行組合并轉(zhuǎn)換成LoadRunner可直接驅(qū)動的十六進制數(shù)據(jù)。

2.4 硬件接口轉(zhuǎn)換技術(shù)

由于LoadRunner工具只支持以太網(wǎng)數(shù)據(jù)傳輸接口，要想滿足艦船裝備軟件其他常用接口(RS232、RS422、RS485、CAN總線)的信息交互需求，就需要實現(xiàn)接口轉(zhuǎn)換，實現(xiàn)以太網(wǎng)與CAN總線接口、以太網(wǎng)與串口(RS232/RS422/RS485)的雙向透明數(shù)據(jù)傳輸。本研究中采用ARM CORTEX-M3處理芯片進行編程以實現(xiàn)接口轉(zhuǎn)換，總體方案如圖2所示，其軟件部分采用模塊化的設計思路，主要分為接口初始化、串口通信、CAN通信、以太網(wǎng)通信、緩沖區(qū)管理、設備管理等模塊，具備網(wǎng)絡中斷后自動斷開連接、以太網(wǎng)/CAN總線/串口傳輸參數(shù)設定、兼容CAN2.0A和CAN2.0B標準、串口數(shù)據(jù)分幀設置、串口硬件隔離、支持TCP/IP、UDP工作模式等能力。

圖2 接口轉(zhuǎn)換方案

3 測試系統(tǒng)的設計與實現(xiàn)

3.1 測試系統(tǒng)的體系結(jié)構(gòu)

本研究以上述技術(shù)為基礎開發(fā)艦船裝備軟件測試系統(tǒng)。該測試系統(tǒng)包括操作顯示層、業(yè)務邏輯層、數(shù)據(jù)存儲層、通信服務層和物理層共五層結(jié)構(gòu)。操作顯示層提供人機交互界面接口；業(yè)務邏輯層實現(xiàn)系統(tǒng)的各項核心功能；數(shù)據(jù)存儲層負責存儲系統(tǒng)運行過程中產(chǎn)生的各類數(shù)據(jù)；通信服務層和物理層負責測試過程中與被測件的數(shù)據(jù)交互和管理，其軟件體系結(jié)構(gòu)如圖3所示。

圖3 艦船裝備軟件測試系統(tǒng)軟件體系結(jié)構(gòu)

3.2 測試系統(tǒng)的設計

艦船裝備軟件測試系統(tǒng)硬件部分包括：1)已安裝Windows操作系統(tǒng)和.NET Framework 4.0的測試計算機1臺；2)接口轉(zhuǎn)換設備2臺，每臺設備對外提供2路 CAN總線接口、2路RS232串口、2路RS485串口、2路RS422串口和1路以太網(wǎng)接口。接口轉(zhuǎn)換設備通過交換機與測試計算機連接，如圖4所示。

圖4 測試系統(tǒng)硬件組成

艦船裝備軟件測試系統(tǒng)軟件部分主要包括測試管理模塊、測試用例生成模塊、測試用例驅(qū)動模塊和數(shù)據(jù)收集與分析模塊，其組成如圖5所示，采用C++/C#語言基于LoadRunner自動化應用程序接口(LoadRunner Automation API)開發(fā)實現(xiàn)。

圖5 艦船裝備軟件測試系統(tǒng)軟件組成

為了提高測試執(zhí)行效率，通過編寫測試后臺程序調(diào)用LoadRunner自動化應用程序接口，實現(xiàn)測試場景的自動構(gòu)建、負載生成器的自動配置、測試腳本的自動執(zhí)行以及運行日志的自動記錄。通過編寫掛接外部模塊對LoadRunner測試腳本功能進行擴展，實時監(jiān)控和采集測試響應數(shù)據(jù)、測試用例執(zhí)行狀態(tài)以及測試結(jié)果等信息。

4 結(jié)束語

軟件測試自動化技術(shù)一直是軟件工程領域研究的熱點。本文依據(jù)艦船裝備軟件報文信息交互測試的需要，研究接口協(xié)議形式化、測試用例自動生成、測試用例自動驅(qū)動、接口轉(zhuǎn)換等技術(shù)，然后以LoadRunner工具為依托，給出了測試系統(tǒng)的實現(xiàn)方法，相對于手工測試本測試系統(tǒng)主要優(yōu)點在于：

1)便于回歸測試。利用已有的測試腳本能夠很方便的執(zhí)行回歸測試，回歸測試是自動化測試最主要的任務。

2)縮短測試時間。由于自動測試采用腳本技術(shù)，可能只需要做少量的甚至不做修改實現(xiàn)在不同的測試過程中使用相同的用例，可多次重復執(zhí)行，提高測試的效率。

3)自動輸入大量數(shù)據(jù)，可以執(zhí)行很多手工測試困難或不可能做的測試，比如性能測試、大數(shù)據(jù)量輸入測試等。

4)節(jié)約人力資源，可實現(xiàn)無人化測試執(zhí)行，測試人員可投入更多的精力到測試用例設計工作。

5)保證測試的一致性和可重復性，利用自動測試重復多次相同的測試，在手工測試中是很難得到保證的。

實踐證明，本測試系統(tǒng)為艦船報文交互軟件提供了一種可行的自動化測試手段。然而，受人機交互存在不確定性的約束，測試系統(tǒng)未考慮人機交互界面測試的情況，這也是后續(xù)重點研究方向。

[1] 陳 策, 郭久武, 胡 勇. 裝備通用嵌入式軟件綜合測試平臺研究[J]. 軍用軟件測評實驗室, 2014，44.

[2] 劉娟娟. 基于Robot框架的軟件自動化測試技術(shù)的研究與應用[D]. 杭州: 浙江大學, 2013.

[3] 張 峰, 斯中毅, 王 斌. 信息化裝備軟件測試[J]. 艦船電子工程, 2006(5)：23-26.

[4] 王云鵬．一種關(guān)鍵字驅(qū)動的 UI 自動化測試框架的設計與實現(xiàn)[D]．北京: 北京大學, 2010.

[5] 何 偉, 韓新宇, 唐龍利，等. 艦船裝備軟件測試數(shù)據(jù)自動生成方法及其應用研究[J]. 計算機測量與控制, 2015(8):2633-2636.

Automated Warship Software Testing System Based On LoadRunner Automation API

Han Xinyu，He Wei，Zhang Kai

(China Shipbuilding Software Quality & Reliability Testing Center，CSSC，Beijing 100081,China)

In order to test warship software which has lots of information to communicate, main requirements of a general warship software testing system are analyzed, key issues including interface protocol formalization, automated test case generation, automated test case driving, and hardware interface conversion are investigated. Then, the architecture of an automated warship software testing system is proposed accordingly, and the system is implemented based on the LoadRunner Automation API. This system is comprised of four parts, which are test management module, test case generation module, test case driving module, data collection and analysis module. The practical results show that this system can greatly improve the efficiency for testing warship software.

test case; automated software testing; LoadRunner automation API; component

2016-03-16；

2016-04-18。

韓新宇(1980-)，女，高級工程師，主要從事軟件可靠性與軟件測試方向的研究。

1671-4598(2016)09-0163-04

10.16526/j.cnki.11-4762/tp.2016.09.045

TP3

A