面向C/S結(jié)構(gòu)的軟件自動化測試工具的設(shè)計

劉漢燁

（榆林學(xué)院 信息工程學(xué)院，陜西 榆林 719000）

隨著IT技術(shù)的迅速發(fā)展，軟件的規(guī)模越來越大，軟件測試在整個開發(fā)流程中所占的比重越來越大。有關(guān)統(tǒng)計表明，在軟件開發(fā)總成本中，軟件測試所占的開銷為30%～50%[1-2]。有人估計，測試階段的開銷要占到整個軟件生存周期開銷的50%甚至50%以上。如此巨大的軟件測試工作量，以往以手工測試為主的軟件測試方法往往會顯得力不從心，這為整個自動化測試?yán)碚摰漠a(chǎn)生提供重要的應(yīng)用背景。

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

1 相關(guān)概念

1.1 回歸測試

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

1.2 關(guān)鍵字驅(qū)動技術(shù)

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

2 自動化測試工具的設(shè)計

2.1 總體框架模型的設(shè)計

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

圖1 測試工具系統(tǒng)架構(gòu)

2.2 自動測試框架的實現(xiàn)

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

2.3 測試工具主要模塊

2.3.1 測試引擎的設(shè)計

測試引擎主要由初始化、命令行解析、測試用例執(zhí)行及系統(tǒng)清理和恢復(fù)等4個模塊組成。

1）初始化模塊 主要負(fù)責(zé)處理初始化工作。初始化工作包括檢查被測軟件的工作狀態(tài)，修改相關(guān)文件夾屬性，載入相關(guān)運行函數(shù)庫等。

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

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

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

2.3.2 配置模塊設(shè)計

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

2.3.3 日志系統(tǒng)設(shè)計

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

圖2 日志目錄結(jié)構(gòu)圖

2.4 測試用例模板方案

被測軟件測試點依據(jù)功能的復(fù)雜程度來劃分，一般情況下可以劃分為2大類：復(fù)雜功能測試點和簡單功能測試點。針對這兩種不同類型的測試點，可以采用兩種不同的設(shè)計方案。即結(jié)構(gòu)化單腳本測試模板方案和關(guān)鍵字驅(qū)動技術(shù)方案[7]。

2.4.1 結(jié)構(gòu)化單腳本模板方案

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

2.4.2 關(guān)鍵字驅(qū)動技術(shù)方案

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

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

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

2.5 測試工具的測試流程

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

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

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

3）根據(jù)測試配置信息中的配置信息，確定啟動相應(yīng)的測試方案。如果是為測試點編輯了單獨的測試腳本，那么根據(jù)配置信息中提供的腳本路徑尋找腳本；如果測試點選用關(guān)鍵字驅(qū)動技術(shù)方案進(jìn)行測試，那么調(diào)用測試數(shù)據(jù)文件并解析之，驅(qū)動數(shù)據(jù)文件中的關(guān)鍵字執(zhí)行測試。

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

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

3 結(jié)束語

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

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

[2]陳雷.基于軟件功能的自動化回歸測試技術(shù)的研究與應(yīng)用[D].西安：西北工業(yè)大學(xué)，2005.

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

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

[5]徐振良，樊濱溫，王志鵬.關(guān)鍵字驅(qū)動技術(shù)在SAFS中的研究[J].微計算機(jī)信息，2006，22（15）：80-83.

[6]王鐵江，酈萌.基于關(guān)鍵字驅(qū)動腳本的安全軟件自動測試系統(tǒng)[J].同濟(jì)大學(xué)學(xué)報，2002，30（6）：720-722.

[7]王蕾.基于數(shù)據(jù)驅(qū)動的軟件自動化測試框架系統(tǒng)的研究與實現(xiàn)[J].軟件導(dǎo)刊，2009，8（6）：32-33.