基于組件的測試軟件定制開發方法

秦振漢，林 淵，胡廣明，郭雙紅

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

0 引言

測試軟件是自動化測試系統的核心組成部分之一，與測試設備硬件開發的工業化、集成化相比, 測試軟件的開發中普遍存在開發周期長、重復開發、復用性差、可維護性和適應性低等問題[1-2], 不能很好地滿足用戶需求變化和個性化開發的需要。尤其是當被測產品處于研發、試驗或小批量試制階段時，情況更為明顯。此外，在軟件的全壽命周期中，不同的用戶，包括產品設計人員、產線人員、工藝人員、相關管理人員等，都會根據各自的使用背景，提出不同的軟件開發、改進和升級要求。

目前，測試軟件開發中普遍使用了諸如開發平臺、架構重用、組件復用等技術和方法，可以快速搭建測試軟件的基礎原型，能夠解決開發中遇到的很多普遍性問題。但在解決個性化需求時，已有的平臺開發、組件開發等方式顯得過于僵化，靈活性不足。為實現這些特定需求，開發人員需要不斷修改已有的軟件產品，甚至大幅調整現有的體系結構，給后續的修改和維護帶來了很多隱患。實際工程經驗表明，在很多項目中，大部分時間都消耗在針對少數幾個定制需求所進行的軟件開發和調試工作上，同時，軟件交付后暴露的問題也往往集中在這些特殊需求上。

本文提出了一種基于組件的測試軟件定制化開發方法。通過對實踐經驗的總結，建立針對定制開發的原型化組件，在內部引入“可變點”的概念，標明了組件內部的變化熱點，并提供了標準的開發流程和變化機制。通過這種方式，使得原型組件具有了很強的適應能力，可依據不同的軟件需求，靈活選擇必要的可變點并進行針對性開發，重構出滿足要求的定制化組件，實現軟件的快速開發。

1 基于組件的定制化開發方法

組件技術從根本上改變了軟件的開發方式，可以使用一些預先構建的組件，將它們組裝在一起，形成具有全新功能的軟件產品，而不用從頭開發[2-4]。大量經過驗證的、成熟的組件，是測試軟件能夠進行定制開發的基礎。

1.1 組件的劃分

這些組件按照復用性質，分為共性組件和個性組件，兩者遵循統一的接口定義規范和開發準則，但實現方法和開發目的各不相同。

1.1.1 共性組件

反映的是軟件開發中的共性內容，為測試軟件開發和運行提供了必須的、帶有公用性質的基礎材料。共性組件包括：統一定義各種組件接口的接口定義庫；用于創建組件實例的類廠組件；定義了常用的數據結構、概念模型的公共數據模型庫；數據訪問組件庫；數據模型組件庫；在應用工程中提取的、具有復用價值的測試業務組件；基礎界面組件等。

1.1.2 個性組件

個性組件反映了軟件開發中的差異性內容，在應用軟件開發時，需要進行針對性調整。例如，與用戶交互的顯示界面、總線通訊數據的解析、業務邏輯中的時序控制、數據分析算法等，經常會因為需求的變化而頻繁修改。為此，將這些帶有差異性的內容單獨提取出來，封裝為獨立的原型組件。該類組件采用設計延遲方式，預先提供了若干個功能擴展點，并將組件的具體實現推遲到應用軟件開發中。

共性組件和個性組件的劃分并不是絕對的。隨著被測產品的不斷發展，其測試方法、測試流程、數據分析方法等也在不斷變化，導致已有的共性組件失去了公用性質，轉換為個性組件；同樣，之前只在特定產品測試中出現的個性組件，成為了當前軟件開發的標準配置，差異性消失，從而轉換為共性組件。

1.2 定制開發方法

測試軟件定制化開發的基本思路如圖1所示。針對不同的軟件任務時，對于共性需求，選擇需要的共性組件；對于個性需求，以個性組件為模板，定制開發新的應用組件。通過對這些組件的靈活調配，建立滿足特定需求的定制軟件。

圖1 測試軟件定制化開發方法示意圖

該方法的本質是通過對共性組件的選擇和個性組件的重構，將測試軟件的定制化開發問題轉換為對組件的復用問題，利用各種組件的大規模復用所帶來的規模化效應，快速解決大部分共性問題，并保證開發的穩定性；然后，將工作的重心集中在個性問題的定制化開發上，使軟件開發具備了更高的靈活性。

2 個性組件的設計與開發

在定制化開發過程中，主要是通過對個性組件的二次開發，衍生出新的應用組件，實現用戶的定制需求，其原理如圖2所示。個性組件來源于特定領域的實踐經驗，在設計中貫徹“開發以復用”的思想，專門用于后續的功能擴展。

圖2 以個性組件為模板的定制化開發

在個性組件設計時，首先需要明確兩個問題：哪些內容可以定制；如何進行定制。為此，引入了可變點和變化機制，用以標明定制開發的內容和實現方法。

2.1 可變點

“可變點”的概念來自軟件產品線，用于標識各個項目差異性所在的位置[5]。在個性組件設計時，可變點代表了組件內部的變化熱點。在軟件開發時，如果發現各項目間存在差異，需要頻繁修改，就可以通過設置可變點的方式，將其單獨標注出來。設置可變點時應考慮以下因素：

1)每個可變點實現的功能應單一、明確，對應一個完整的功能需求。

2)可變點不是孤立存在的，在設置時應明確前置條件、后置條件、限定信息等。

3)位置信息，包括可變點所在的層級和具體位置。當系統較為復雜時，分層結構便于職責定義，也利于可變點的管理。

4)為可變點提供若干種可選的實現方案。定制開發人員可根據被測產品的具體要求，選擇不同的實現方式。

5)變化機制。定義了標準的開發流程，用于指導定制開發人員進行后續的重構開發。

可變點的設置是一個不斷完善的過程，隨著對該領域問題認識的逐漸清晰和明確，可變點所在的位置、功能職責、實現方案等同步漸進明確，不斷更新和完善現有的個性組件。

2.2 變化機制

變化機制定義了可變點的具體實現方法。本文從工程應用出發，結合已有的研究成果[6-7]，提供了如下幾種常用的變化機制。

2.2.1 代碼層面的變化機制

為實現功能擴展，在代碼層面的修改和開發是必須的。在面對定制化需求時，無法對所有細節進行標準化處理，進而通過參數配置、組件替換等方式實現所需的功能，很多情況下還是需要通過修改代碼的方式實現。

該層面的變化機制包括：

1)使用面向對象編程中的繼承、重寫方式，重新實現父類定義的方法[8]。

2)使用橋接、裝飾、模板、類廠等設計模式[2,9]，將抽象與實現解耦、或者延后實現。

3)通過預處理器、宏定義等方式，在代碼編譯時調整具體實現細節。

2.2.2 組件層面的變化機制

對于每個可變點，提供多種可直接復用的功能組件，代表了該可變點上預期的各種擴展選項。開發人員可根據定制需要，從中選擇需要的組件，快速實現功能擴展。

該層面的變化機制包括：

1)使用新的組件替代已有的組件，兩者的接口定義一致，但組件內部的具體實現不同。這是一種靜態替換方式。

2)使用動態創建機制，通過組件類廠，采用反射機制，完成組件的實例化操作。這是一種動態替換方式，減少組件間的直接耦合關系。

2.2.3 軟件體系結構層面的擴展要求

組件不是獨立存在的，必須通過預先設計的軟件體系結構，將其組合在一起，構成具有完整功能的應用軟件。為滿足體系結構擴展方式的要求，個性組件需滿足：

1)設計和開發時必須嚴格遵循接口定義、接口規范、交互機制等。

2)個性組件在設計時要有合理的劃分，以能夠完整地實現一項相對獨立的軟件功能為標準。因為功能相對獨立，所以修改時避免了連鎖反應，提高軟件體系結構的可修改性[10]。

3)在交互方式設計時，對于下層組件，可使用接口直接調用；對于上層組件，采用事件方式的隱式調用，減少組件間的直接關聯。

2.2.4 配置文件

將具體業務的實現細節從組件內部剝離，形成了標準化的配置參數。改變配置文件中的對應參數，從而影響組件對象內部的運行狀態，實現對需求變化的快速響應。

3 組件定制開發實例

本文以某類電子產品的性能測試功能為例，描述了個性組件的設計和開發過程。性能測試是該類電子產品的必備測試項目，用以完成被測產品的各項功能與性能指標的檢測，確定是否滿足指標要求。

3.1 差異性分析

不同型號被測產品的性能測試功能具有很強的相似性，其測試場景、測試流程、激勵信號的形式和種類、數據處理的實現過程等宏觀方面基本一致，在測試軟件開發時，可以將這些共性內容封裝在組件內部，作為定制化開發的基礎。但不同產品在某些細節方面，存在明顯的差異，主要體現在以下幾個方面：

1)通訊端口的種類、數量上的差異。被測產品必須含有通訊端口(最少為1個)，但不同產品的端口的數量、種類是不確定的。

2)測試信號上差異。該類產品測試中涉及的信號主要包括數字量、模擬量、脈沖量、計數器信號、陀螺儀信號、波形信號、光纖陀螺信號等，但不同產品的具體情況各不相同。

3)通訊格式上的差異。既包括通訊幀在協議格式上的差別，也包括通訊幀在數據構成、類型上的差別。前者決定了能否實現數據的正常收發，后者決定了該產品測試參數的種類和存儲形式。

4)測試數據分析與處理上的差異。很多情況下，測試數據的分析處理算法需要在與被測產品對接調試后才能徹底固化下來，軟件可以提供一般性的標準流程，但無法準確描述全部細節。

5)數據顯示、保存方式的差異。

3.2 組件設計實例

通過對性能測試功能的共性和差異性分析，建立了面向電子產品性能測試的個性組件。圖3使用統一建模語言(unified modeling language，UML)，以組件圖的形式,描述了該組件模型的頂層拓撲結構。該組件實現了測試流程控制、數據收發與解析、測試結果的分析與處理、數據保存、數據顯示等一系列功能，是一個功能相對獨立的業務組件。組件通過3個對外端口，完成與測試儀器、數據訪問、上層業務邏輯的交互。在組件內部，共設置了6個可變點，實現具體業務功能的擴展。

圖3 性能測試組件的頂層拓撲結構(組件圖)

V1：位于測試組件核心業務類中，主要職責是根據被測產品信息(如型號、個數、產品編號等)，建立被測產品業務執行類的實例對象，實現與外部組件的交互等。該類的職責限定在宏觀控制上，不涉及執行細節，各步驟高度程式化，因而采用了配置參數方式實現。

V2：該可變點位于被測產品業務執行類中，測試流程可以劃分為初始化、前置操作、測試執行、后置操作等。其中，“測試執行”實現不同產品的業務流程控制，差異性較大，其功能包括：利用通訊測試接口，完成不同通訊端口的流程控制與同步；利用硬件交互端口，完成測試信號的輸出和時序控制。此處采用模板設計模式，開發人員根據業務需求，修改該操作的具體實現。

V3：該可變點位于組件界面的具體實現。界面部分是變化比較頻繁的部分，界面顯示的內容、界面風格、樣式等需要根據不同用戶的要求進行調整。在代碼層面，通過開發單獨的界面實現類實現；在組件層面，開發獨立的顯示界面組件，通過組件替換方式實現，但兩種方式必須遵循組件界面接口定義。

V4：位于通訊測試接口的不同實現方式上。該可變點提供了多種通訊測試方案，其中，主通訊端口測試組件是必選項，其它的端口測試組件均為可選項。該可變點采用了組件的動態創建機制，可根據被測產品的端口信息，在運行時完成擴展組件的實例化。

V5：位于協議解析器組件中，該組件負責通訊數據的解幀和組幀。在特定領域中，總線通信協議的格式固定，在此限制條件下，當針對不同的被測產品時，只需調整各通訊幀的格式。該可變點采用了配置文件方式。

V6：位于總線通訊數據的物理數據分析組件中，負責將接收的數據幀解析為物理數據，并對其進行分析，確定測試指標是否合格，其核心在于針對不同的產品，采用不同的處理方式和分析算法。該可變點采用了模板設計模式，將共性處理方法封裝在抽象基類中，將特定算法的實現細節放到子類中實現。

3.3 實例結果分析

通過個性組件的開發實例，得到以下結論：

1)通過個性組件，為該類問題提供了一個完整的、標準化的解決方案。面對同樣問題時，可以直接復用該組件，快速搭建應用軟件的基礎。

2)針對項目間的差異性問題，提供了可變點和變化機制，開發人員按圖索驥，精準定位，通過選擇、編輯、修改等方式，在已有的軟件基礎上，完成特定問題的定制化開發。

3)組件設計的質量取決于對領域開發經驗的總結，重點是對各項目間差異性的準確識別和描述，對開發人員的經驗要求較高。

4 結束語

本文提出了一種基于組件的測試軟件定制開發方法。通過對個性組件內部預設可變點的靈活配置，實現對需求變化和用戶個性需求的快速響應，開發出更加貼合用戶要求的應用軟件。

該方法已經在多種測試軟件開發項目中得到應用。從使用情況看，該方法尤其適用于特定領域內中小規模軟件的定制開發，此時問題的范圍相對固定，項目間的共性內容占多數，差異性的需求只占少數，并且基本控制在可預估的范圍內。在擴展可變點的功能時，多采用參數配置、組件替換等方法，只在少數情況下才會使用代碼層面的擴展方式。本方法保留了基于組件開發方式在提高復用性、維護性方面的優勢，同時，在針對用戶的多樣性需求時，實現上更為敏捷和高效，便于應用軟件的定制化開發。