面向C/S結構的軟件自動化測試工具的設計

劉漢燁

（榆林學院 信息工程學院，陜西 榆林 719000）

隨著IT技術的迅速發展，軟件的規模越來越大，軟件測試在整個開發流程中所占的比重越來越大。有關統計表明，在軟件開發總成本中，軟件測試所占的開銷為30%～50%[1-2]。有人估計，測試階段的開銷要占到整個軟件生存周期開銷的50%甚至50%以上。如此巨大的軟件測試工作量，以往以手工測試為主的軟件測試方法往往會顯得力不從心，這為整個自動化測試理論的產生提供重要的應用背景。

軟件自動化測試是解決當今軟件復雜化測試的一個必然方向。軟件測試過程有很多操作是重復性的、非智力創造性、細致的工作。這類型的工作很適合做自動化，因此如果能將軟件測試中大部分這種類型的工作實現自動化測試，將會對軟件開發工作的質量、成本和周期帶來非常顯著的效果[2]。

1 相關概念

1.1 回歸測試

在軟件開發過程中，測試工作的很大一部分是回歸測試（Regression Testing）?；貧w測試主要是驗證系統的變更是否影響系統在變更前所具有的功能，保證當前變更功能的正確性。在漸進和快速迭代開發中，新版本的連續發布使回歸測試的執行更加頻繁，而在產品即將發布的時間段內，更是要求每天都進行若干次回歸測試。為了驗證修改的正確性及其影響，就需要進行回歸測試，執行回歸測試時，首要應考慮覆蓋范圍足夠大，而且用盡可能少的時間執行回歸測試，盡量進行自動化的回歸測試[3]。

1.2 關鍵字驅動技術

為了讓測試程序按照我們的意圖去執行測試，就需要使用一組控制命令來控制腳本的執行。這些控制命令是由測試軟件的共享函數庫來解釋的[4]。這些控制命令就是關鍵字，代表某個動作。關鍵字的不同組合可以構成不同的測試邏輯。

2 自動化測試工具的設計

2.1 總體框架模型的設計

測試工具包括以下組件：測試引擎、測試用例列表、測試用例配置文件集、測試用例集、日志生成器及公共函數庫等。測試工具的體系結構如圖1所示。

圖1 測試工具系統架構

2.2 自動測試框架的實現

測試軟件的測試框架基于3層腳本驅動方案，即測試軟件的測試腳本分為3類：高層腳本、中層腳本及低層腳本[4-6]。高層腳本為測試引擎，其主要工作為解析測試用例表，并將解析出的結果傳遞給中層腳本或底層腳本。中層腳本位于測試腳本集中。測試腳本集是中層腳本和底層腳本所在目錄，測試腳本根據測試用例的不同分類分布在不同的文件夾下。中層腳本主要負責接收高層腳本的解析結果，并調動底層腳本。底層腳本為測試用例具體執行腳本，是測試過程的主要實施者，每個測試用例對應1個底層腳本，腳本名與測試用例名一致。

2.3 測試工具主要模塊

2.3.1 測試引擎的設計

測試引擎主要由初始化、命令行解析、測試用例執行及系統清理和恢復等4個模塊組成。

1）初始化模塊 主要負責處理初始化工作。初始化工作包括檢查被測軟件的工作狀態，修改相關文件夾屬性，載入相關運行函數庫等。

2）命令行參數解析模塊 主要負責解析運行測試工具的命令行，以便完成不同類型的測試。

3）配置文件備份和恢復模塊 主要負責測試工具運行前被測軟件部分配置文件的備份情況，以便在測試工具發生運行錯誤時及時恢復被測環境。

4）測試用例執行模塊 測試引擎4個模塊中最核心的模塊。該模塊的主要任務有：從測試用例表中自動調用所需的測試用例并執行之；生成測試日志和測試報告；從已結束的測試用例中獲取返回信息；清理及重新初始化系統。

2.3.2 配置模塊設計

配置模塊主要負責測試工具測試環境的配置。測試工作所需的各種環境變量都是可配置的，測試人員在測試時可以根據自己的測試場景選擇配置。該配置模塊中主要有用戶配置、機器配置、測試用例列表、測試數據文件及測試軟件測試過程中所需要的其他配置信息。測試用例列表是整個配置模塊的核心文件，整個測試工具在測試過程中所要用到的有關測試用例的信息全部在測試用例列表中獲取。測試用例列表最基本的組成部分應包括測試用例ID、測試用例執行腳本的目錄位置及測試用例功能描述信息等。測試數據文件中包含的內容有測試用例測試邏輯、關鍵字及測試數據等。在測試的執行過程中，測試工具會依據不同的測試場景從中取得所需要的數據，用以替代測試驅動和執行腳本中的變量。

2.3.3 日志系統設計

日志系統也是測試工具的設計中非常重要的一個模塊。測試工具的日志系統包括3部分，分別是單個測試用例的測試日志，測試用例組的測試報告及整個測試過程的測試報告。從日志系統產生的日志類型來劃分，日志由2部分組成：一部分是輸出到測試機器屏幕上的日志，用戶使用輸出到測試機器屏幕上的日志可以很方便的跟蹤測試過程；另一部分是以文件的形式保存起來的日志。后一種類型的日志保存在一個文件夾內，該文件夾是測試日志的頂級目錄，文件夾內的測試日志又以不同分類的測試用例而歸類保存。日志系統目錄結構圖如圖2所示。

圖2 日志目錄結構圖

2.4 測試用例模板方案

被測軟件測試點依據功能的復雜程度來劃分，一般情況下可以劃分為2大類：復雜功能測試點和簡單功能測試點。針對這兩種不同類型的測試點，可以采用兩種不同的設計方案。即結構化單腳本測試模板方案和關鍵字驅動技術方案[7]。

2.4.1 結構化單腳本模板方案

結構化腳本模板方案主要是針對復雜的功能測試點而設計的。被測軟件的測試用例被劃分成了很多測試組，每一組測試用例在功能上基本接近，組內不同測試用例有可能只是所用的參數不同。那么這類測試用例就可以使用結構化單腳本模板方案。該方案的實施方法是：首先為測試用例開發一個模板腳本，組內其他測試用例腳本負責向模板腳本傳遞參數。

2.4.2 關鍵字驅動技術方案

關鍵字驅動技術方案主要是針對功能比較單一的測試點而設計的。該方案的實施方法是：首先在配置文件目錄中新建一個數據文件，數據文件中存儲的是各測試用例的配置信息，具體包括測試邏輯的定義、測試所需的數據及定義好的關鍵字。由于該方案主要針對于單一測試點，所以測試邏輯可以分為4大部分，邏輯結構可用以下結構來表示：

其中，Begin和End是測試工具保留字，用來定義每個測試用例的開始和結束，緊接著它們的是測試用例的測試序列號，該測試序列號在整個測試工具中是唯一的。preAction用來定義測試用例執行之前的一系列初始化操作，比如測試時所需要創建的文件、配置所需配置信息等。testAction是真正的測試用例執行步驟，測試用例在測試中所需完成的測試動作都需要在這一項定義。resultCheck是用來檢測測試用例執行結果的，判斷測試用例是否通過測試。postAction負責一系列的收尾工作，比如刪除測試過程中產生的臨時文件、殺死進程等工作。

配置信息中的關鍵字是根據被測試用例的特點而設計的，比如需要運行命令，可以設計一個關鍵字gRuncmd，需要創建文件可以設計一個關鍵字gCheckfile，關鍵字的解釋需要專門的函數庫來支撐。

2.5 測試工具的測試流程

測試工具的測試流程如下：

1）向CVS服務器發送更新代碼請求，獲取最新的測試工具代碼。

2）啟動測試引擎，并解析配置信息文件。

3）根據測試配置信息中的配置信息，確定啟動相應的測試方案。如果是為測試點編輯了單獨的測試腳本，那么根據配置信息中提供的腳本路徑尋找腳本；如果測試點選用關鍵字驅動技術方案進行測試，那么調用測試數據文件并解析之，驅動數據文件中的關鍵字執行測試。

4）自動判斷測試成功與否，并將結果實時返回。

5）在執行各個測試用例的同時啟動日志產生程序，將每個測試用例的測試日志按組保存在測試報告文件夾中。

3 結束語

測試工具主要使用B-shell語言實現，可以使測試軟件部署在不同的操作系統中；測試工具使用測試引擎自動調動測試用例及配置測試環境，提高了測試效率；根據測試軟件功能塊的不同特點，設計了2種不同的測試方案，增強了測試軟件的靈活性。該測試方案在platform公司Job scheduler產品上完成了實施，取得了預期的效果。但該方案也有一定的缺陷。由于該工具主要使用B-shell語言實現測試腳本，速度比較慢。所以如果測試軟件測試用例比較多的話，建議使用其他語言來實現測試引擎及測試腳本，比如Perl或Java。

[1]Cen Kaner，Jack Falk，Hung Quoc Nguyen.計算機軟件測試技術[M].王峰，陳杰，喻琳，譯.北京：機械工業出版社，1992：19-46.

[2]陳雷.基于軟件功能的自動化回歸測試技術的研究與應用[D].西安：西北工業大學，2005.

[3]商宇.基于STAF的自動化測試工具的研究和設計[J].云南大學學報，2009，18（3）：279-282.

[4]朱菊，王志堅，楊雪.基于數據驅動的軟件自動化測試框架[J].計算機技術與發展，2006，16（5）：69-70.

[5]徐振良，樊濱溫，王志鵬.關鍵字驅動技術在SAFS中的研究[J].微計算機信息，2006，22（15）：80-83.

[6]王鐵江，酈萌.基于關鍵字驅動腳本的安全軟件自動測試系統[J].同濟大學學報，2002，30（6）：720-722.

[7]王蕾.基于數據驅動的軟件自動化測試框架系統的研究與實現[J].軟件導刊，2009，8（6）：32-33.