導航計算機測試軟件的架構設計

秦振漢，郭雙紅

(航天科工慣性技術有限公司，北京 100074)

0 引言

導航計算機測試軟件是一種部署在不同類型的測試設備上，實現對不同型號導航計算機產品的測試，以確定被測產品是否為滿足功能和性能指標的應用軟件。在導航計算機測試軟件的開發中，面臨著以下問題：

1)導航計算機作為被測產品，雖然種類有限，但型號繁多。每一類導航計算機產品，雖然功能上相近，但在個體上都存在差異。反映在測試軟件上，在測試方法、測試流程、數據處理、測試激勵與響應等方面有很多都是相同或相似的, 但是由于受到軟件開發方法、開發人員和開發運行環境的限制，這些軟件的重用性很低。每當有新的軟件需求時，都要對現有程序進行修改和完善，這不僅浪費了大量的時間和精力, 同時測試軟件的質量也很難得到保證。

2)一種測試設備，通常解決一種或幾種產品的測試，無法兼容全部型號，由此逐漸衍生出針對不同類型產品的多型測試設備。這些測試設備受制于開發時間、成本和需求等因素，在硬件構成上采用了很多的專用測試儀器，有些儀器或板卡是為滿足測試要求而定制開發的。當測試設備變更、升級或板卡替換時，測試程序都會受到影響，甚至重新開發。

出現這些問題的原因主要是，在測試軟件開發初期缺乏統一的設計，每個軟件只是針對單臺測試設備，滿足對某種型號產品的測試需要。這些軟件本質上都是獨立開發和維護的，即使存在復用，也主要體現在代碼層面和模塊層面。隨著測試設備和被測產品的種類、型號的增加，測試軟件的數量越來越多，給后期的修改、完善和功能擴展帶來了巨大的困難。

對于導航計算機測試軟件的開發而言，一個清晰明確的軟件架構是解決這些問題的關鍵，能夠為測試軟件的開發提供一個完整而統一的技術途徑。軟件架構最近才作為軟件工程的一個獨立研究領域出現，它對于軟件開發的重要性和指導意義已經得到了廣泛的共識，但目前對于軟件架構這一概念還沒有一個統一的定義。相關的研究人員、組織和機構分別從不同的角度，給出了不同的概念說明，在參考文獻[1-3]中做了較為詳細的闡述。拋開這些概念本身的差異，從測試軟件開發的實用角度出發，軟件架構是對整個軟件系統的高層抽象，描述了該系統內部的組件以及組件間的相互作用，反映了系統設計決策的基本原理。

本文提出了一種基于組件的測試軟件架構，其出發點不是某個單獨的軟件項目，而是針對導航計算機測試這一特定領域，以解決不同被測產品、在不同測試設備上的軟件開發問題。通過軟件復用方式，減少重復開發，提高了軟件質量；同時，該架構提供了良好的可擴展性，能夠適應后續不斷增加和變化的軟件需求，滿足了研發和生產過程中測試軟件快速開發的需要。

1 測試軟件的基本設計思路

導航計算機測試軟件采用了組件化開發方法。組件技術從根本上改變了軟件的開發方式，可以通過對組件的組裝，形成新的軟件[4-5]，從而縮短了軟件的開發周期，并提高了軟件的開發質量。組件技術的核心是組件模型。目前比較常用的組件模型主要包括CORBA、JavaBean以及COM/ActiveX、 .Net等。導航計算機測試軟件一般運行于Win-dows操作系統中，綜合考慮軟硬件資源、開發習慣、后期維護等多方面因素，導航計算機測試軟件采用了.Net組件模型。

大量經過驗證的、功能多樣的組件，是測試軟件開發的基礎。在導航計算機測試軟件開發中，這些組件按性質可以大致劃分為兩類。

第一類為測試軟件開發和運行所必須的基礎組件，例如報表生成組件、接口定義組件、常用算法、界面控件、數據訪問組件、領域模型組件等。該類組件反映的是軟件開發中的共性內容，帶有一般性，與具體的測試業務沒有直接相關性，在測試軟件中可以全局復用，也是軟件開發和運行的必備要素。

第二類是軟件開發中帶有特定性質的個性組件。主要包括反映不同類型測試設備信息的系統交互組件；針對不同型號被測產品，實現不同功能需求的測試業務組件等。該類組件面向特定對象，具有特殊性。在軟件開發和調試時，主要是針對這些元素進行修改、完善和補充。

這些組件主要來自對已有的知識和經驗的歸納和總結。通過將具有復用價值的內容封裝為獨立的組件，建立了適用于導航計算機測試這一特定領域的組件庫。當針對特定的軟件需求進行應用軟件開發時，可直接復用已有的基礎，遵循公共的軟件架構，將需要的組件裝配在一起，以實現不同的軟件功能。在這種開發方式下，不同項目的測試軟件開發問題，可以轉換為依靠統一的軟件架構、針對特定需求的組件開發與組件裝配問題。

在導航計算機測試軟件開發中，架構設計處于核心位置。它規定了軟件的整體組織結構、內部組成元素及功能分工；提供了可納入組件庫的各種組件的接口規范；預先定義了測試軟件的開發流程，指導軟件開發活動。

2 測試軟件的架構設計

軟件架構是對系統的整體構想，詳細描述了包含的架構圖、組件、接口規范和交互機制等[6]。與獨立的測試軟件相比，導航計算機測試軟件的架構設計不能只針對某個特定的軟件項目，而應該覆蓋導航計算機測試領域內的不同的軟件需求；同時，能夠提供靈活的擴展機制，適應多樣化的需求變化。

2.1 分層體系結構

導航計算機測試軟件架構采用了常用的分層式架構風格[7-9]，將體系結構劃分為顯示層、系統交互層、數據訪問層和業務邏輯層等4層，如圖1所示。

圖1 導航計算機測試軟件的邏輯架構框圖Fig.1 The logic architecture of navigation computer test software

1)顯示層是應用程序和用戶的交互界面。該層內包含了與具體業務無關的界面組件，并通過組合模式加載在主程序中。主程序以可執行程序形式存在，負責完成各組件的動態加載和組件間通信等，是所有組件賴以運行的基礎。

2)數據訪問層負責配置參數的訪問、修改，測試數據、結果的保存，測試履歷書的生成等。

3)系統交互層負責完成測試設備硬件(包括測試儀器、電氣連接關系等)的封裝，其主要功能是將軟件的測試業務與具體的硬件設計分離，提高儀器互換性。導航計算機測試設備使用了很多非標儀器和板卡，無法使用諸如可編程儀器的標準命令(Standard Commands for Programmable Instrum-ents，SCPI)、VXI總線即插即用(VXI Plug&Play,VPP)規范、可互換虛擬儀器 (Interchangeable Virtual Instruments，IVI)標準等儀器互換性技術和方法。僅以IVI驅動而言，目前只提供了13種儀器類驅動，且只適用于通用儀器[10-11]。但在導航計算機測試設備中，大多數儀器和板卡的驅動程序都不是按照這些標準開發的。為此，采用了基于功能分解的設計方法，忽略具體儀器或板卡的實現細節[12-14]，通過對測試設備所需實現功能的抽象，形成針對該設備的接口模型。

在導航計算機測試中，所需的功能項可細分為基本的儀器操作、產品切換、產品供電等共用類；以及各種通信數據收發、各種脈沖信號的輸出控制、外部的恒流源控制、選通信號控制、振梁信號輸出、DI/DO操作、AD/DA操作等專用類。每種測試設備需要實現的功能都是若干個功能項的組合，區別集中在功能項的種類和數量。為此，將帶有共用性質的功能項合并為基礎接口，在定義后基本不會修改；將帶有專用性質的功能項合并為專用接口，在軟件設計時需要根據測試需求的不同進行修改和完善。例如，在圖1中，X類設備實現組件和Y類設備實現組件就是根據不同需求，單獨開發的個性化組件。

4)業務邏輯層負責完成各種導航計算機的特定測試功能，包括常用的性能測試功能、在線升級功能、VF標定功能和電源監測功能等。業務邏輯層內的組件只關注各自的業務流程與軟件需求，例如，在圖1中，業務邏輯層內部包含了電源監測組件，以及針對A、B兩種型號被測產品的性能測試組件。這些業務組件直接反映了某種特定的測試需求，往往需要根據不同的業務需求進行定制開發。在業務層定義的組件接口中，包含了測試設備硬件控制接口、數據訪問層控制接口、事件發送與接收接口等，開發人員只針對接口編程，不依賴具體實現，有效降低了組件間的耦合性。

5)組件庫是各種類型組件的集合，其中既包括公共性組件，例如，定義接口規范、常用工具、算法的基礎組件；管理電子履歷模板、配置文件模板等的模板管理庫等；也包括反映特定測試設備的硬件驅動庫和反映特定業務領域的領域模型庫。

2.2 交互方式設計

在該架構設計中采用了兩種交互方式：1)顯式調用方式，即上層組件通過接口，調用臨近下層提供的服務。例如，業務層組件可以通過系統交互層的對外接口，實現對硬件設備的直接控制;2)采用事件機制的發布-訂閱方式[4,15]。例如，系統交互層組件將采集到的電源數據封裝為事件消息，通過事件發送接口，發布給業務邏輯層的事件訂閱組件；后者通過事件接收接口獲得信息，完成監測數據的處理。針對處于同一層次的組件，采用基于事件的轉發方式，即先將交互信息發送到主程序，再由后者將信息轉發到目標組件中。

通過接口調用和事件機制，降低、簡化了各組件的對外依賴性,使軟件可以在不修改、少修改的前提下，快速應對業務需求的變化。

2.3 組裝方法設計

根據組裝模式的不同，可以分為靜態組裝和動態組裝。對于測試軟件開發和運行所必須的共性組件，直接通過引用方式，由軟件集成開發工具完成組裝。但對于各種后續開發的、以獨立的插件形式發布的個性化組件，必須使用動態組裝方式。動態組裝的組件信息統一保存在一組配置文件中，該文件采用XML形式，內部包括了各種組件的存在目錄、命名空間、類名和加載順序等基本信息。

動態組裝功能由主程序發起，但具體的執行交由各層的類廠組件。類廠組件根據配置文件的內容，使用反射機制動態創建類型的實例。通過這種動態組裝方式，使測試軟件具有良好的擴展性，當需要增加或修改軟件功能時，只需要在配置文件中修改或增加該組件的屬性信息。

3 測試軟件的開發

組件庫提供了測試軟件開發的基礎材料，軟件架構規定了測試軟件的整體結構，明確了組件的裝配方式和交互方式，但兩者本身并不實現具體的測試功能。在面向某型號導航計算機的測試需求時，需要從已有組件庫選擇必須的組件，并開發針對特定需求的個性化組件，然后按照預先定義的開發流程，將這些組件組裝在一起，形成針對該型號產品的應用軟件。

3.1 組件的開發

在組件庫中，共性組件可以直接復用，不必重新開發，因而組件開發的重點是按照軟件架構的規定，開發針對特定需求的個性化組件。在該軟件架構中，待開發的組件集中在業務邏輯層和系統交互層內。業務邏輯層組件和系統交互層組件的組合方式如圖2所示。

圖2 組件關系示意圖Fig.2 The diagram of component relationship

在導航計算機測試中，核心的測試業務包括測試過程中的電源監測、功能和性能指標測試、老化測試、產品標定測試、監控上傳等。這些業務組件遵循架構中定義的業務組件接口，通過事件接口實現組件間的隱式交互；通過數據訪問層對外接口獲取和保存測試數據；通過系統交互層基礎接口，實現與測試設備硬件的交互。在業務層組件開發時，這些核心組件一般以大顆粒度的、帶有界面的控件形式存在，以確保每個組件能夠完整地實現一項相對獨立的業務需求。因為需求相對獨立，所以修改和新增組件時，不會對其他組件產生太大影響。

系統交互層組件必須實現該層定義的基礎接口和專用接口。在軟件架構中，每個型號的測試設備，都對應一個系統交互組件和若干個電氣連接文件。系統交互組件通過調用對應硬件的驅動程序實現了對各種測試儀器和板卡的控制功能。測試設備的電氣連接關系以表格或配置文件的形式單獨封裝。在配置文件內部描述了測試設備的對外連接端口，以及各連接端口與硬件儀器間的映射關系。當交互層組件建立后，測試軟件根據這些配置文件，實現對各硬件儀器和板卡的控制。

以產品切換控制功能為例，在硬件層面，切換控制功能可以采用外設部件互連標準(Peripheral Component Interconnect，PCI)總線形式的專用板卡，也可以采用標準的繼電器儀器。在交互層組件開發時，對于前者，使用硬件廠商提供的應用程序編程接口(Application Programming Interface，API)函數；對于后者可直接調用IviSwtch類驅動[16-17]。在交互層組件開發和調試完畢后，除非硬件發生變化，否則該組件和配置文件基本不會修改。

3.2 測試軟件的快速開發流程

在架構設計時，預先定義了幾種典型場景下的軟件開發流程，為軟件開發人員提供指導，便于后續的應用軟件開發、修改和完善。

場景1：在全新的測試設備上，進行首個測試軟件的開發。開發人員的工作包括兩點，首先針對軟件架構中的系統交互層，抽象出與該設備功能對應的專用接口，開發系統交互層組件，該組件開發完畢后可直接復用；其次，根據測試產品的測試需求，分解具體的測試業務，開發測試業務組件，形成的組件成果可作為后續其他型號開發的模板。

場景2：日常的完善性或更正性維護。從實際情況看，這些維護工作基本集中在業務邏輯層。在組件進行針對性修改后，可直接進行替換。

場景3：增加對新增產品的測試支持。一種測試設備經過擴展后，可以實現對新增型號產品的測試。此時，采用增量化開發方法，針對新增的需求，開發特定的業務組件，并通過插件方式增加到已有的程序中。在開發過程中，可直接以現有的業務組件為模板，衍生出特定的業務組件。

場景4：測試軟件的移植。測試設備的硬件在升級和改造后，已有的測試軟件可以快速移植，避免了重復開發。在架構設計時，與硬件相關的內容已經統一劃分在系統交互層中，同時業務層組件只和系統交互層對外接口關聯，所以在移植前，只需要重新開發和修改交互層組件，即可直接進行替換。

4 結論

本文以導航計算機測試這一特定領域為目標，設計了基于組件的分層式軟件架構，為測試軟件開發提供了統一的解決方案。該方案規范了軟件開發的整體流程，避免了測試軟件的分立開發問題；通過架構復用和組件復用等方式，使得測試軟件可以在一套基礎平臺下開發，減少了重復勞動，提高了軟件的開發質量和開發效率。

目前，該軟件架構已經在多種導航計算機測試軟件項目中得到應用。從使用情況看，在軟件開發的前期，因為需要搭建軟件的整體架構、開發共性組件、建立配置文件、進行軟件的調試和驗證等，工作量較大，占用時間較長。但是這些基礎工作完畢后，其成果可以直接復用在后面的所有軟件項目中，并且隨著組件庫的不斷更新、擴展和完善，開發周期大幅縮減；同時，這些軟件遵循相同的體系結構，軟件間具有很強的延續性，有效降低了修改、維護和管理的難度，可以很方便地針對不同需求進行功能擴展，滿足不同被測產品、在不同測試設備上的測試軟件開發需要。