基于任務的艦船裝備軟件測試技術研究

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

0 引言

基于任務的艦船裝備軟件側重于以軍方用戶的實際使用場景為出發點和落腳點。在設計上，此類軟件主要采用開放式架構使組件松散耦合，以便對系統資源進行自動配置和動態重組，力求軟件能用、好用，符合執行實際任務的要求。

對于此類基于任務的艦船裝備軟件，當前型號軟件測試技術手段的適用性不強，主要體現在：①當前型號軟件測試技術缺乏對任務需求的系統化分析，即使測試中考慮到隱含任務需求，有意設計了一些測試用例，也無法覆蓋被測軟件的全部可測任務需求，測試充分性難以保證[1]；②當前型號軟件測試技術主要關注于對軟件各功能點實現的正確性進行驗證，較少從任務完整執行過程的角度來設計測試用例，因而很難暴露出軟件在任務執行層面的缺陷[2]；③當前型號軟件測試技術大多是在單機環境下運行被測軟件實施測試，但基于任務的艦船裝備軟件常需要跨平臺部署于采用不同處理器、操作系統的分布式網絡基礎設施和公共計算環境，現有測試工具難以針對此類軟件進行有效的跨平臺測試[3]。

針對上述問題，本文將深入探討基于任務的艦船裝備軟件測試技術，包括：艦船裝備軟件任務分析與建模、基于任務模型的艦船裝備軟件測試用例生成和艦船裝備軟件測試自動化執行等三方面關鍵技術，給出相應的工具實現。在此基礎上，開展基于任務的艦船裝備軟件測試技術實例應用，驗證該技術的工程適用性和工具的有效性。總體研究思路如圖1所示。

圖1 基于任務的艦船裝備軟件測試技術總體研究思路

1 任務分析與建模技術

艦船作戰任務具有分階段、多層次、目標動態演化、協同關系復雜等特點，通常可視為由一系列子任務和元任務及它們之間的依賴關系(如順序、并發、選擇等)所組成的集合。其中，元任務是任務執行過程中系統對應關系相對固定、能夠實現一定任務目標的最小任務單元，其特征為互不包含、不可再分。

對于基于任務的艦船裝備軟件而言，每項任務均可視為在達到規定目標過程中經歷的一系列狀態和事件，因而適于采用擴展有限狀態機(Extended Finite State Machine, EFSM)來建立準確、有效的艦船裝備軟件任務模型，并以此為基礎開展軟件測試工作。

1.1 艦船裝備軟件任務特征分析

通過收集并分析現有艦船裝備軟件的用戶任務需求，開展任務特征分析，明確任務執行過程涉及的主要狀態、關鍵變量以及各主要狀態間的遷移關系，從而歸納出艦船裝備軟件的任務特征信息，包括：狀態特征、數據特征、狀態遷移特征。

在狀態特征分析中，首先找出被測軟件任務需求所包含的主要狀態，然后明確初始狀態和終止狀態；在數據特征分析中，識別出任務執行過程涉及的關鍵變量，包括：輸入變量、輸出變量、可能影響狀態變化的中間變量；在狀態遷移特征分析中，理清各主要狀態之間的遷移關系，進而分別確定每個狀態遷移的源狀態、目標狀態、激勵事件、前置條件、行動操作、后置條件。這些要素共同組成了艦船裝備軟件的任務特征信息。

1.2 艦船裝備軟件任務建模

根據任務特征信息，建立被測艦船裝備軟件任務EFSM模型。該模型由一個七元組M=構成[4]，其中S是一個非空的狀態集，表示被測軟件任務需求所包含的主要狀態，s0是初始狀態集，sn是終止狀態集，V是任務執行過程涉及的關鍵變量集，I是輸入變量集，O是輸出變量集，T是非空的狀態遷移集。T中的每個元素t是一個六元組。ssrc為源狀態，stgt為目標狀態，event是t的激勵事件，pre-cond是t的前置條件，action為t引發的行動操作，post-cond是t的后置條件。

以某艦船裝備軟件設備初始化任務為例，建立EFSM模型如圖2所示。在該模型中，狀態集S={s0,s1,s2,s3,s4,s5}，初始狀態為s0，終止狀態為s5，遷移集T={t1,t2,t3,t4,t5,t6,t7,t8,t9}。表1明確了每個遷移的源狀態、目標狀態、激勵事件、前置條件、行動操作和后置條件。

在任務模型M中，一些復雜的行動操作可分解為若干個子任務，相應的模型由七元組M′=構成。在此基礎上，子任務可進一步分解為元任務，相應的模型由七元組M″=構成。

針對子任務，采用上述方法構造狀態遷移視圖和狀態遷移表，即可建立相應的子任務EFSM模型。類似地，針對元任務，也可建立相應的元任務EFSM模型。這樣，就可以自頂向下建立完整的艦船裝備軟件任務EFSM模型。

2 基于任務模型的測試用例生成技術

基于任務模型的測試用例生成思路如下：首先，根據艦船裝備軟件任務EFSM模型，采用深度優先搜索策略，遍歷艦船裝備軟件任務模型，生成滿足指定測試覆蓋準則的測試路徑。然后，分析艦船裝備軟件的常見故障，識別出所蘊含的故障模式。根據每條測試路徑涉及的前置條件集合，生成正常測試數據；輔以艦船裝備軟件故障模式，生成異常測試數據。另一方面，利用每條測試路徑涉及的后置條件或隱含的蛻變關系、容錯機制、通用要求等信息，生成相應的測試預言。

表1 設備初始化任務EFSM模型狀態遷移表

2.1 測試路徑生成

對于基于任務的艦船裝備軟件而言，每條測試路徑p可以用一個從初始狀態s0到終止狀態sn的狀態-遷移序列表示。

根據被測艦船裝備軟件的規模、復雜度，可以定義和選取合適的測試覆蓋準則，生成滿足指定測試覆蓋準則的測試路徑，然后分別針對每條測試路徑設計測試用例，實現對被測軟件的測試，同時達到測試資源和測試質量之間的良好折衷。

本文采用深度優先搜索策略，遍歷艦船裝備軟件任務EFSM模型，生成滿足指定測試覆蓋準則的測試路徑。具體而言，測試路徑生成分為2步實現：

1)深度優先搜索各元任務、子任務EFSM模型，生成原子測試路徑；

2)深度優先搜索完整的任務EFSM模型，連接所經原子測試路徑，構成復合測試路徑，即目標測試路徑。

隨著軟件復雜度增加，相應的EFSM模型中狀態數和遷移數也會明顯增加，導致測試路徑生成的搜索空間急劇增大，測試路徑生成效率嚴重下降。為此，本文根據軟件外部組件調用和異常處理機制的特點，提出了兩種搜索空間約簡策略，通過約簡軟件任務EFSM模型中的外部組件狀態節點和異常處理狀態節點，在保證測試覆蓋效果的同時，可減小測試路徑搜索空間規模，提高測試路徑生成效率。

2.1.1 針對外部組件狀態節點的約簡策略

軟件測試主要關注被測軟件本地組件內的狀態遷移以及本地組件與外部組件間的臨界狀態遷移是否正確。因此，本文提出在構建艦船裝備軟件任務EFSM模型時，針對外部組件狀態節點進行約簡，以減小生成測試路徑時的搜索空間，約簡步驟如算法1所示。

該算法以艦船裝備軟件任務EFSM模型為輸入，其核心思想是通過廣度優先遍歷EFSM模型，識別并刪除外部組件狀態節點以及相應的遷移邊，從而得到約簡后的EFSM模型。

算法1:外部組件狀態節點約簡策略輸入:約簡前的EFSM模型mission_efsm輸出:約簡后的EFSM模型reduced_efsms0 = mission_efsm.getEntry();foreach state∈mission_efsm.getNodes()-{s0} do visited[state] = FALSE;Queue Q = ?;enqueue(Q, s0);while Q≠? do si = dequeue(Q); foreach transition∈cg.edgesOutOf(si) do sj = transition.tgt(); if visited[sj]=FALSE and sj.belongToExtComponent()=TRUE then mission_efsm.nodes= mission_efsm.nodes-{sj}; mission_efsm.edges= mission_efsm.edges-{}; enqueue(Q, sj); visited[si] = TRUE;reduced_efsm = mission_efsm;return reduced_efsm;

2.1.2 針對異常處理狀態節點的約簡策略

軟件測試首要目標是檢測軟件核心功能是否正確。作為測試覆蓋目標，測試路徑不必包含異常處理狀態信息。因此，本文提出在構建軟件任務EFSM模型時，針對異常處理狀態節點進行約簡，以減小生成測試路徑時的搜索空間。

與針對組件調用狀態節點的搜索空間約簡策略的實現方式相似，針對異常處理狀態節點的搜索空間約簡策略可通過廣度優先遍歷軟件任務EFSM模型，識別并刪除EFSM模型上的異常處理狀態節點及其相應的邊。

2.2 故障模式分析

開展艦船裝備軟件故障模式分析，針對艦船裝備軟件的常見故障，歸納故障特征(包括故障類型、原因、現象等)，形成艦船裝備軟件故障模式庫，目的在于根據故障模式生成可能觸發軟件故障的異常測試數據，并施加于被測軟件，從而對其進行針對性的測試[6]。考慮到實際艦船裝備軟件中故障種類繁多、難以窮盡，因此本文主要考慮不可達路徑、前置條件失效、激勵事件失效、非法操作、死循環、死鎖等6種故障模式。

1)不可達路徑故障模式指軟件設計或實現中分支判斷間相互矛盾，造成相應的測試路徑無法執行。例如，某條測試路徑上的約束條件要求var<10和var>100同時為真，但實際上不存在這樣的數據，導致該路徑永遠無法執行。

2)前置條件失效故障模式是指軟件設計或實現中出現分支判斷錯誤，導致軟件前置條件失效，常見情況包括：在分支判斷中對浮點型變量進行相等/不等比較、對無符號數與有符號數進行比較等。

3)激勵事件失效故障模式是指軟件中涉及并發任務時信號量處理不當，導致激勵事件未發揮預期作用，軟件狀態出現錯誤。

4)非法操作故障模式是指軟件執行任務(尤其是用戶輸入操作、接口輸入操作)時，輸入的數據由于訪問控制不當等問題，威脅到軟件的安全性和健壯性，導致軟件出現異常。

5)死循環故障模式指的是軟件由于循環或遞歸邏輯設計、實現不當，陷入重復執行某段程序的過程中，通常表現為軟件失去控制從而無法響應外部輸入事件或者程序調用棧溢出。

6)死鎖故障模式是指軟件中通過多線程訪問共享資源，由于訪問的順序不當，造成線程間互相等待，軟件無法繼續執行。

2.3 測試數據生成

為艦船裝備軟件生成測試數據，首先要獲取各測試路徑上涉及的數據約束，其步驟如下：

1)針對被測軟件的每條測試路徑p，收集路徑上的全部狀態遷移，構成狀態遷移集Tp；

2)提取狀態遷移集Tp中每個狀態遷移t涉及的數據約束，構成該路徑的數據約束集Cp。

根據測試路徑及數據約束信息，可生成所需測試數據[7]。本節討論的測試數據生成方法及其適用情形如表2所示。

2.3.1 常量池法

通過分析艦船裝備軟件的數據約束，可以發現某些通用字段的取值范圍是一些離散點，甚至是固定取值。根據這

表2 測試數據生成方法一覽表

些字段的取值范圍/典型值，通過劃分等價類取值、邊界取值等方式建立常量池。在測試數據生成階段，為相應字段高效生成所需測試數據。

例如，執行某艦船裝備軟件任務時需要輸入1個航速字段，該字段為int類型，占用4個字節，正常取值范圍為[-40, 40]kn。為了檢驗該軟件能否接收航速輸入數據并正確響應，可以在常量池中為該字段添加{-41, -40, -39, -1, 0, 1, 39, 40, 41}等備選值。這樣在測試數據生成階段，就能由常量池為該字段高效生成所需測試數據。

2.3.2 隨機生成法

對于被測艦船裝備軟件中未明確取值范圍的連續型字段，本項目根據相應字段的數據類型通過隨機取值的方法快速生成測試數據。對于被測軟件中有明確取值范圍的連續型字段，可采用更為先進的自適應隨機測試方法生成測試數據，該方法的核心思想是在各字段取值范圍內盡可能生成均勻分布的測試數據，以提高發現潛在故障的概率[8]。

隨機生成法便捷易行，而且適用于不同規模的被測軟件，但是常常難以生成滿足復雜約束的測試數據。因此，對于涉及復雜數據約束的連續型變量，建議采用符號執行法。

2.3.3 符號執行法

符號執行的核心思想是使用符號表示軟件輸入變量，而軟件中的變量以及輸出結果則由符號表達式(由代表輸入變量的符號以及運算符構成)表示，通過模擬軟件的執行過程，根據每條路徑的執行條件，利用現有的約束求解器(如SMT、Z3等)對執行條件構成的方程組進行求解，即可生成測試數據。

艦船裝備軟件常采用收發報文的方式進行組件交互，以實現某些指揮、監控和通信任務，常用報文均涉及數組、結構體等復雜數據結構。然而，符號執行法通常難以生成此類涉及復雜數據結構的測試數據。因此，本文進一步探討基于被測軟件源代碼的啟發式生成法，作為常量池法、隨機生成法和符號執行法的有益補充。

2.3.4 啟發式生成法

針對含復雜數據結構輸入變量的艦船裝備軟件測試數據生成需求，利用啟發式測試數據生成方法意在為被測艦船裝備軟件搜索到一組覆蓋指定路徑的測試數據。具體來說，首先需要構建初始種群，其中每個個體表示一條隨機生成的測試數據，每個個體的基因數量取決于測試路徑上輸入變量的個數，基因的排列順序由測試路徑上輸入變量的出現順序決定。每個基因由二元組構成，其中f是一個標志位，用于表示該基因對應的輸入變量的數據類型，0為基本類型數據，1為復合類型數據；當基因對應于基本數據類型輸入變量時，d為該輸入變量取值范圍內的一個具體數據值，當基因對應于復合數據類型輸入變量時，d為一個索引，指向表示該復雜數據的所有基因。然后，將個體解碼為可驅動測試數據，在被測軟件執行測試數據并評估實際執行路徑與當前目標路徑的距離。如果其中某條測試數據能夠覆蓋當前目標路徑，就將該測試數據添加到結果數據集合，并為下一條目標路徑搜索相應的測試數據；否則，如果該種群中每個個體對應的測試數據都無法覆蓋當前目標路徑，就利用遺傳算子再生成一個新的種群，并評估新種群中每個個體對應的實際執行路徑與當前目標路徑的距離。依此重復種群再生、個體執行和距離評估過程，直到滿足指定的測試覆蓋準則或達到其它終止條件。結果數據集合中即為所生成的具備良好測試覆蓋能力的測試數據。

2.4 測試預言生成

測試預言用于判定被測軟件在特定場景下是否正確運行。隨著軟件測試過程中程序分析、測試數據生成、測試執行等環節的自動化水平不斷提升，測試預言已成為制約整體測試效率的主要瓶頸[9-10]。本文利用艦船裝備軟件測試路徑上的后置條件和隱含的蛻變關系、容錯機制、通用要求等信息生成測試預言。

2.4.1 測試預言的分類

根據測試預言所要檢測的內容，可將測試預言分為2類：數據型測試預言、事件型測試預言。

數據型測試預言用于判定被測軟件執行過程中指定變量的取值是否正確。例如，在某軟件設計文檔中描述了GetRSSpeed函數的返回值為串口通信波特率代號(0：9600bps，1：38400bps，2：115200bps)，則其測試預言為函數返回值必須為0,1或2，若實際返回值不是這三者之一，則認為函數實現有誤。

事件型測試預言用于檢查被測軟件在執行過程中是否發生特定事件。例如，在調用OpenRS函數后，可以通過執行WriteRS函數向串口寫入數據并在另一端讀取數據來判斷串口是否成功打開，也可通過執行GetRSState函數獲取當前串口狀態來判斷串口是否成功打開。

此外，還可以根據被測軟件的隱含要求，歸納出通用型測試預言。在很多情況下，這類通用型測試預言在軟件相關的文檔中沒有明確進行定義，但是其作為對軟件產品普遍適用的要求，也應當作為測試預言。

2.4.2 測試預言的生成

2.4.2.1 基于后置條件的測試預言生成方法

根據軟件用戶需求，采用任務分析與建模技術可快速構建軟件任務EFSM模型。在被測艦船裝備軟件EFSM模型中，狀態遷移的后置條件可直接轉換為測試預言。例如：某后置條件要求輸出字符串string1≠NULL，則其預期輸出就是一個非空字符串。

2.4.2.2 基于蛻變關系的測試預言生成方法

2.4.2.3 基于容錯機制的測試預言生成方法

根據被測艦船裝備軟件任務中的容錯機制生成測試預言是指：艦船裝備軟件中的某些關鍵組件會通過多個版本實現，且在并行執行后以大多數實現版本所支持的運算結果作為實際輸出，從而實現容錯。也就是說，給定某組件的N個實現p1，p2，…，pN以及某門限值σ∈(1/2，1]，若p1，p2，…，pN中有n個實現版本的實際輸出均為x且n/N≥σ時，則將x作為該組件的實際輸出。在這種情況下，該組件的預期輸出也認為是x。一旦以某測試數據為輸入，執行該組件，相應的實際輸出結果不是x，則認為該組件實現有誤。

2.4.2.4 通用型測試預言生成方法

有些對軟件產品普遍適用的要求，雖然未在軟件文檔中直接言明，但是作為隱含要求，被測軟件也應當滿足。例如：軟件不允許崩潰、不允許發生死鎖、不允許出現內存泄露、不允許緩沖區溢出等。這類必須遵守的隱含要求可作為通用型測試預言。

需要補充說明的是，考慮到開發文檔對軟件預期行為描述詳細程度不一、軟件任務流程的某些中間狀態有時難以觀測、軟件實際運行場景存在不確定性等因素，理想的測試預言是幾乎無法實現的。在具體實踐中，需要考慮多方面因素，在測試預言的成本和效益之間做出權衡，利用有限的資源盡可能對軟件中可能出錯的環節進行充分測試。

3 測試自動化執行技術

生成滿足測試覆蓋準則的測試用例后，就需要將測試用例翻譯為可執行且便于復用的測試腳本，然后按照測試環境要求在測試平臺上執行測試腳本，通過比較實際輸出與預期輸出是否相符，判斷各測試用例是否通過。實現軟件測試的自動化執行能夠有效提高測試效率，降低測試成本。

3.1 測試腳本生成技術

艦船裝備軟件測試腳本生成可通過4步實現：①定義測試腳本關鍵字；②測試腳本關鍵字實例化；③生成可執行測試腳本；④測試腳本優化。

首先，根據測試用例中描述的要素信息，定義測試腳本關鍵字集合。測試腳本關鍵字是根據測試用例描述的腳本要素信息。從艦船裝備軟件測試腳本的共性入手，可以歸納出兩大類關鍵字：腳本執行關鍵字和腳本說明關鍵字。腳本執行關鍵字用于描述測試場景，涵蓋測試腳本中的函數名稱、參數名稱、控制邏輯等，在測試腳本中實例化為可執行語句；腳本說明關鍵字則用于描述測試腳本的標識信息、測試條件、預期輸出以及補充信息，在測試腳本中實例化為斷言語句和注釋語句。

其次，生成測試腳本框架，并對測試腳本關鍵字進行實例化。測試腳本框架是指根據測試用例預先定義的具有一定流程控制功能的腳本單元，采用XML格式表示。測試用例執行行為與測試腳本的執行邏輯密切相關，因此可以根據測試用例建立測試腳本框架。測試腳本關鍵字實例化就是將測試腳本框架中的關鍵字替換為測試用例要素信息的過程。在測試用例信息完備和測試腳本關鍵字定義清晰的基礎上，根據測試用例描述，在測試腳本框架的標識信息、測試前提、測試步驟、預期輸出、測試備注這五個部分中查找關鍵字，將相應的測試用例要素信息替換到關鍵字位置，即可實現測試腳本關鍵字實例化，得到XML格式的測試腳本。

接下來，采用DOM或SAX對XML格式的測試腳本進行解析，根據測試用例要求及可執行測試腳本的語法要求，將XML格式的測試腳本中各元素逐項轉化為可執行腳本語句，從而生成完整的可執行測試腳本。

3.2 測試自動化執行技術

現有研究和工程實踐中，單機運行環境下的測試執行技術已相對較為成熟。然而，基于任務的艦船裝備軟件常需要能夠跨平臺運行于i386、sparc32、x86_64、sparc64、amd64、ppc64等不同處理器以及Windows、Linux、Solaris等不同操作系統上的分布式網絡基礎設施和公共計算環境，傳統的單機測試技術已不適用。如果通過手工操作來執行跨平臺測試并逐一判斷測試結果，不僅人力成本高昂，還可能難以滿足某些測試用例中對特定行為的時序要求，而無法實現相應的復雜測試場景[11]。

實現艦船裝備軟件的跨平臺測試，主要步驟如下：①腳本分發：將需要執行的一組測試腳本分發至指定測試機；②遠程環境部署：遠程配置測試腳本所需的運行環境；③遠程測試執行：遠程驅動測試腳本批量化執行；④遠程結果收集：收集各測試腳本的執行結果并回傳至本地計算機；⑤結果顯示：利用本地計算機直觀地顯示各測試腳本的執行結果。

針對艦船裝備軟件的跨平臺測試需求，本文提出利用Software Testing Automation Framework(STAF)[12]的可重用組件實現跨平臺測試的自動化執行框架，如圖3所示。

圖3 艦船裝備軟件跨平臺測試的自動化執行技術方案

具體而言，跨平臺測試的自動化執行框架負責接收并處理測試人員的測試執行指令，并利用STAF后臺服務將測試腳本自動分發到指定運行平臺，然后驅動測試腳本批量執行，全程監控測試執行過程、收集測試結果并提供可視化顯示，從而實現測試腳本的跨平臺分發、批量化執行、全過程監控以及測試結果的自動歸集，以滿足基于任務的艦船裝備軟件的跨平臺測試要求。

4 基于任務的艦船裝備軟件測試工具研制

基于任務的艦船裝備軟件測試工具是上述任務分析與建模技術、測試用例生成技術和測試自動化執行技術的工程實現，其研制方案如圖4所示、組成結構如圖5所示。

圖4 基于任務的艦船裝備軟件測試工具研制方案

圖5 基于任務的艦船裝備軟件測試工具組成結構圖

基于任務的艦船裝備軟件測試工具主要包括三個子系統：任務分析與建模子系統、測試用例生成子系統、測試自動化執行子系統。任務分析與建模子系統用于根據軟件用戶需求建立被測艦船裝備軟件任務EFSM模型；測試用例生成子系統包括測試路徑生成、故障模式分析、測試數據生成和測試預言生成四大功能；測試自動化執行子系統通過人機交互將需要執行的測試腳本從本地計算機分發至指定測試機、配置測試腳本的運行環境、驅動測試腳本批量化執行、收集并顯示測試執行結果。其中，測試執行所使用的接口轉換設備為硬件系統，主要實現CAN總線接口、RS232/RS422/RS485串口與以太網接口的多功能轉換。

5 實例應用

為了驗證上述技術方法的技術可行性和測試工具的工程適用性，選用某裝置監控軟件、某概貌系統軟件、某跟蹤應用軟件等3型艦船裝備軟件作為應用對象開展實例應用，應用方案如圖6所示。

圖6 實例應用方案

應用過程中，采用本文提出的技術方法和測試工具可根據軟件任務需求，成功建立軟件任務EFSM模型。從測試用例編寫和測試腳本生成的時間來看，此前人工對應用對象進行測試時，由于測試數據量較大，3人用了8天時間完成相關測試用例編寫和測試腳本編輯工作；本次實例應用過程中，采用基于任務的艦船裝備軟件測試工具，由1人在1天內完成了測試用例的編寫和測試腳本的生成。從測試執行情況來看，此前對應用對象進行測試時，每個用例都需要人工逐步執行，3個人用了約2天執行完相關測試用例；在本次實例應用過程中，采用基于任務的艦船裝備軟件測試工具，由1名測試人員執行測試、1名測試人員操作被測軟件和查看結果，全部測試用例在2小時內執行完畢，與未采用測試工具開展測試相比，測試設計和執行效率提高了70%以上。

此外，基于任務的艦船裝備軟件測試工具可實現對多線程死鎖故障測試，支持跨平臺遠程測試執行，有效解決現有艦船裝備軟件采用不同處理器、操作系統的分布式網絡基礎設施和公共計算環境復雜的問題。

實例應用結果表明：本文提出的基于任務的艦船裝備軟件測試技術是切實可行的，以此為基礎研制的配套工具有助于提高艦船裝備軟件測試質量和效率，達到了預期效果。

6 結束語

本文以基于任務的艦船裝備軟件為對象，開展軟件任務分析與建模、基于任務模型的測試用例生成、測試自動化執行等三方面技術方法研究。在軟件任務分析與建模技術研究中，通過分析艦船裝備軟件任務特征，獲取狀態、數據和遷移信息，準確建立艦船裝備軟件任務EFSM模型?；谌蝿漳Ｐ偷臏y試用例生成技術研究中，根據艦船裝備軟件任務EFSM模型，高效生成測試數據和測試預言。在測試自動化執行技術研究中，將XML格式測試用例轉化為可執行測試腳本，實現了跨平臺運行環境下的測試自動化執行，可顯著提升測試自動化水平。在此基礎上，研制了基于任務的艦船裝備軟件測試工具，并以某裝置監控軟件、某概貌系統軟件、某跟蹤應用軟件等3型艦船裝備軟件為對象開展實例應用，取得了良好的應用效果，能夠為實施基于任務的艦船裝備軟件測試提供技術支撐。

本文研究成果的適用范圍主要針對艦船裝備軟件的測試設計與執行階段，后續可探討測試需求分析、測試策劃、測試總結等階段的自動化測試技術，從而進一步提升艦船裝備軟件自動化測試水平。