基于數據源識別和驅動分析的軟件系統測試方法

魏 波，張慧穎，司倩然

(北京跟蹤與通信技術研究所，北京 100094)

0 引言

航天測控中心軟件系統主要部署于航天測控中心、測量船、二級指控中心等，完成對遙測數據、外測數據的接收、處理、顯示，對測控設備的引導控制，以及向航天器發送遙控指令等功能[1]。基本的航天測控軟件系統一般包括數據交換、匯集分發、遙測數據處理、外測數據處理、綜合數據處理、監視顯示、安控輔助判決、遙控發令等軟件配置項。航天測控軟件系統具有架構復雜、軟件配置項多、內外接口復雜、實時性強、軟件安全關鍵等級高等顯著特點[2]，對軟件測試提出了非常高的要求[3]。

軟件測試的目的是發現軟件錯誤，驗證其是否滿足研制任務書、軟件需求、軟件設計等規定的各項技術要求，并為軟件質量評價提供依據[4]。依照測試級別來分，軟件研制過程中，會依次進行軟件單元測試、軟件集成測試、軟件配置項測試、軟件系統測試等各個級別的測試，各級別的測試的關注點是不同的[5-6]。

軟件系統測試一般在真實的系統工作環境下進行，重點檢查系統所屬配置項之間的接口、時序、邏輯關系等是否正確[7]，重點考核各軟件配置項之間能否協調有序的正確工作[8]，是否滿足軟件系統設計說明的要求。開展系統測試的前提是系統包含的軟件配置項都已經通過了各自的配置項測試。

1 軟件系統測試的現狀和困境

當前，相對于配置項測試，人們對系統測試的重視還不夠，在配置項測試完成后，存在不進行正規的系統測試，直接以系統聯調代替系統測試的情況，導致在聯調中暴露出軟件系統的諸多問題，嚴重影響任務進度。

根據軟件工程規范要求，系統測試的輸入是軟件系統設計說明。軟件系統設計說明中應準確分析、提取、描述軟件系統需求，包括功能、性能、外部接口、適應性、安全性、操作、可靠性以及其他需求。但因人們對系統測試重視不夠，導致編寫的軟件系統設計說明往往不夠規范，關鍵內容缺失。

依照載人航天工程軟件工程化技術標準的要求，軟件系統設計說明應在系統分析與設計階段編寫，是后續編寫軟件配置項需求規格說明的依據。但有些時候，軟件系統設計說明往往與軟件配置項需求規格說明同步編寫，或晚于軟件配置項需求規格說明進行補寫，系統級的需求往往成為了多個配置項需求的簡單羅列。

以上種種情況，導致第三方評測機構在進行系統測試需求分析和測試設計時，得到的軟件系統需求要么非常簡單，無法作為有效的系統測試依據進行測試設計；要么是所有軟件配置項需求的簡單羅列，缺少系統級軟件需求等關鍵信息，如果測試人員依照這些需求進行用例設計，就變成了系統所屬各軟件的配置項測試，無法體現系統測試的價值。

目前，對系統測試方法研究，大多集中于基于控制流[9]、基于場景[10-11]、基于數據流和控制流疊加[12]、基于業務流程[13]、基于操作概圖(Operational Profile)[14]和基于形式化模型(Formal Model)[15]等方面，雖然取得了較好的測試效果，但僅僅適合于指揮控制、金融、電子商務等基于工作流的軟件系統。

本文結合航天測控中心軟件系統特點，設計了一種基于數據源識別和數據驅動分析的軟件系統測試方法，能夠從軟件系統層面入手，快速梳理系統測試需求，提高系統測試用例設計針對性，進而提高測試效率和測試有效性。

2 基于數據識別和驅動分析的軟件系統測試方法設計

航天測控中心軟件系統是一個典型的數據驅動型軟件系統，具有數據輸入、處理和輸出的典型特征，其大部分功能均由數據觸發，數據的類型和狀態決定了數據處理邏輯的不同分支。在具體編程實現上，各軟件基本采用多線程處理架構，數據接收線程通過輸入接口接收數據，根據數據類型標志放入不同的數據接收緩沖區；處理線程從數據接收緩沖區中取出數據，根據數據的要求，或進行系統行為控制，或進行數據處理并將處理結果放入數據發送緩沖區；數據發送線程從數據發送緩沖區取出數據，通過輸出接口向外發送數據。

本文針對數據驅動型軟件系統特點，設計了一種基于數據識別和驅動分析的軟件系統測試方法，通過對系統處理數據的測試全覆蓋，進而覆蓋系統的絕大部分功能和性能，從而以較小的測試成本，最大程度的檢驗系統所屬軟件配置項之間的接口、時序、邏輯關系，達到系統級測試的目的。

基于數據識別和驅動分析的系統測試方法的關鍵技術包括數據源的識別、數據路徑分析、數據狀態分析、系統級數據順序圖繪制、系統測試用例設計等。該系統測試方法的一般工作流程如圖1所示。

圖1 基于數據源識別和驅動分析的系統測試方法工作流程圖

3 關鍵技術

3.1 數據源識別

本文規定，系統中被注入的或自主產生的一類數據，稱為一個數據源。通過定義可知，數據源的類型有兩種，一種是外部數據源，即系統外部注入的數據，典型的該類數據有遙測數據、雷達測量數據、光學測量數據等。另一種是內部數據源，即系統在運行過程中，由操作人員操作控制產生，或由軟件系統自主產生的數據，典型的該類數據包括遙控指令數據、綜合彈道、設備引導數據、系統狀態上報數據等。

識別數據源的方法主要包括3種。一是梳理軟件系統設計等文檔，通過系統外部接口中輸入接口的描述來識別外部數據源；二是梳理系統所含的各個軟件配置項的需求規格說明文檔，通過功能和接口的描述，識別系統內部數據源。三是通過與操作員和系統總體人員的交互，并依靠測試分析人員的領域知識和測試經驗來識別數據源。

需要說明的是，由于系統中數據傳遞路徑較長，雖然一個數據源在系統內部流動時，格式或內容發生了變化，但我們仍然定義它為一個數據源，所發生變化的僅僅是該數據源的狀態。

識別數據源的關鍵在于不重復、不遺漏。我們將識別的數據源，以表格的形式表示出來，該表格包含數據源描述、數據源類型、數據發起方等字段。其中數據發起方可以是外部硬件設備或外部軟件系統，也可以是軟件系統內部的軟件配置項。在對某測控中心軟件系統進行系統測試時，獲取的外部數據源如表1所示，獲取的內部數據源表如表2所示。

表1 某測量船測控中心軟件系統外部數據源表

表2 某測量船中心軟件系統內部數據源表

3.2 數據路徑分析和數據狀態分析

識別數據源后，下一步工作是數據路徑分析和數據狀態分析。數據路徑分析，是指分析數據源在系統內部各配置項之間被處理、傳遞的路徑，分析的粒度應達到配置項級別。數據狀態分析則是分析和確定數據在路徑中各個節點上的狀態。這兩個分析步驟關系緊密，且在時間上是交叉進行的，在實際測試中，可以同時進行路徑分析和狀態分析。

本文規定數據源首次從外部注入系統時，或首次在系統內部產生時，其狀態為初始狀態。當數據流出系統，或者終止在系統內部某個配置項時，其狀態為最終狀態。當一個數據源在系統中流動時，必然會依照數據處理流程，依次途徑系統中多個軟件配置項，在每流經一個軟件配置項后，數據的狀態一般會發生變化。

數據的狀態包括數據幀格式、頻率、存儲介質，以及幀內各數據項的類型、字節長度、數值、單位、量綱等特性，上述特性均可以從系統的接口控制文件中獲得。數據狀態的變化，包括了數據幀的轉發、數據幀的格式變化、數據幀的分解和重組、數據量綱的變化、數據坐標系的轉換、參數值的解算、數據融合處理等。數據狀態變化的正確與否，反映了系統功能的正確性。

針對每一個數據源，都要分析和記錄其數據路徑和狀態變化，分析要素見表3。

表3 數據路徑分析和狀態分析要素表

3.3 基于順序圖的系統數據流向圖

識別出全部數據源、并依照分析要素進行路徑分析和狀態分析后，下一步要對分析結果進行建模和呈現。當前，研究人員對基于UML模型的系統測試方法進行了一些研究，文獻[16]通過擴展UML用例圖的方法導出系統測試用例，文獻[17]綜合利用UML活動圖和用例圖信息，通過擴展活動圖的方法獲取系統測試信息，均取得了較好的效果。

本文設計了一種簡化的UML順序圖，對系統的數據流向圖進行建模。UML順序圖的主要元素為參與者和事件消息等[19]，主要用來幫助用戶準確的為組成系統的各部分之間如何交互進行建模[18]。本文設計的基于順序圖的數據流向圖，參與者為與該數據源有關的外部硬件設備、外部軟件系統，以及系統內部所屬軟件配置項，事件消息為具備一定狀態特征的數據。一個典型的飛船遙測數據源的數據流向圖如圖2所示。

圖2 飛船遙測數據源的系統數據流向圖

3.4 編寫軟件系統測試用例

設計系統測試用例，關鍵在于確定用例的測試輸入和期望結果。以下給出依照系統數據流向圖，確定測試輸入和期望結果的方法。

1)測試輸入:

系統測試用例的輸入，取決于數據源的初始狀態，通過數據流向圖，可以得到數據源的初始狀態。在圖2中，數據源的初始狀態為注入至數據交換軟件配置項的原始遙測幀。

當數據的初始狀態是外部注入時，測試用例的輸入是外部測量設備或者測試仿真程序產生的注入數據；當數據的初始狀態是由系統內部產生時，測試用例的輸入就是操作員對系統的相關操作，或者軟件系統自主產生的數據。

2)期望結果：

系統測試用例的期望結果，包括3個基本要素。(1)確定系統測試檢查點，即在系統什么位置獲取數據狀態；(2)通過什么方式獲取數據狀態；(3)期望的數據狀態應該是什么。

一般來說，數據的最終狀態表明系統功能將在該點完成，該點對測試人員而言往往是可見的，因此我們將數據最終狀態所處的軟件配置項設置為系統測試檢查點。通過查看該軟件配置項的顯示界面、數據文件、數據庫等方式，獲取數據的實際狀態，并與接口控制文件中規定的期望狀態相比較，驗證系統功能是否正確。

圖2中，飛船遙測數據源的最終狀態有兩處，一處是數據存儲軟件配置項存儲的原始遙測幀，另一處是監視顯示軟件配置項界面顯示的解算后遙測參數值，因此該測試用例將擁有兩個系統檢查點，在后續的用例設計中將至少對應兩個測試步驟。

需要說明的是，數據的中間狀態對用戶來說則不一定是可見的，但如果測試中有必要，測試人員依舊可以通過網絡捕獲、查看日志、查看共享內存的方法來設置系統檢查點。

3)編寫系統測試用例：

依照系統數據流向圖2，確定系統測試輸入和期望結果后，編寫的系統測試用例如表4所示。

表4 飛船遙測數據接收、處理和顯示測試用例

需要說明的是，表4測試用例是針對一個數據源編寫的。系統測試時，要按照系統真實使用場景，同時注入系統工作時的所有數據源，測試人員需要同時關注每個數據源的處理結果，以及有關聯關系的多個數據源的綜合處理結果。

4 實驗結果與分析

在某測控中心軟件系統測試中，對本文提出的系統測試方法進行了驗證。用例設計階段，通過對數據源的識別，數據路徑和狀態分析，共設計測試用例91個，測試用例設計情況見表5。

表5 測試用例設計一覽表

表5中，因系統參試設備較多，且大多數設備產生多種數據，共梳理出62個外部數據源。梳理內部數據源19個，包括遙控數據、綜合彈道、設備引導數據、系統狀態上報數據、鏈監信息等，遙控數據又細分為指令碼、執行脈沖、指令序列等多個子類。綜合性測試用例則進行多個數據源的組合，用于數據優選功能、數據融合功能、性能和余量測試。

系統測試共發現軟件缺陷13處，軟件缺陷分布情況見表6。

表6 軟件缺陷分布一覽表

該系統是在原有系統基礎上進行的國產化改造，大部分軟件為代碼移植，故13個軟件缺陷符合測試預期。其中軟件功能缺陷3個，說明軟件配置項測試比較充分，大部分軟件功能缺陷已在配置項測試中發現并解決。其余10個軟件缺陷為系統級缺陷，分布于系統內外接口、軟件互操作和綜合試驗流程中，系統級缺陷數占比為76.92%。而系統所屬配置項間接口、時序、邏輯關系是否正確，能否協調有序工作，正是軟件系統測試應重點關注的對象。

經過本次系統測試，該系統一年內運行穩定，成功執行多次試驗任務。實踐證明，本文提出的基于數據源識別和數據驅動分析的軟件系統測試方法，從系統所處理的數據入手，能夠快速、清晰提取測試需求，提高系統測試用例設計的針對性和有效性。

5 結束語

本文結合航天測控中心軟件系統的特點，設計了一種基于數據源識別和數據驅動分析的航天測控軟件系統測試方法，給出了該方法的一般工作流程，并對數據源的識別、數據路徑分析、數據狀態分析，系統數據流向圖繪制、系統測試用例編寫等關鍵技術進行了研究。該方法是對傳統的基于需求的系統測試方法的有力補充，能夠顯著提高系統測試用例設計的針對性和有效性。該方法已經在多個航天測控中心、測量船的軟件系統測試中得到應用和驗證，結果表明，該方法能夠有效發現系統層面的軟件缺陷，提高系統測試效率。后續，作者將針對該方法的測試充分性、測試數據和測試用例輔助生成[20]、數據驅動和業務驅動相結合的系統測試方法做進一步的研究。