葉素梅

摘要：當軟件產(chǎn)品的代碼被修改，特別是在產(chǎn)品的版本更新時，會對原有的代碼產(chǎn)生影響。為了保證產(chǎn)品的整體性能，必須對整個代碼進行回歸測試?；貧w測試的重復度較高，工作量較大，自動化測試可以大大提高測試的效率。通過設計并生成測試腳本，在服務器上執(zhí)行測試命令，并調(diào)取用例庫中的測試用例，可以實現(xiàn)回歸測試的自動化。對測試結果進行分析后，自動生成測試報告。

關鍵詞：回歸測試;自動化測試;用例庫;測試用例復用

中圖分類號：TP311.52 ? ? 文獻標識碼：A? ? ?文章編號：1009-3044（2018）35-0055-02

Abstract： When the code of the software product is modified， especially when the product version is updated， it will affect the original code.In order to ensure the overall performance of the product， the entire code must be tested for regression.Regression testing has high repeatability and heavy workload. Automated testing can greatly improve the efficiency of testing.The automation of regression testing can be realized by designing and generating test scripts， executing test commands on the server and calling test cases from the test case database.After analyzing the test results， the test report is automatically generated.

Keywords：Regression Testing; Automated Testing;Testcase Database; Testcasereuse

在軟件開發(fā)的整個過程中，對代碼的任何一次修改，都有可能給軟件帶來問題。軟件代碼的修改一般是增加新功能，或者是對已有代碼進行缺陷修正和性能提升。新加入的代碼除了本身可能存在問題外，也有可能會對原有的代碼產(chǎn)生影響[1]。同樣的，對缺陷進行修正的同時，又可能引發(fā)了其他的缺陷。因此，每當代碼發(fā)生改變時，需要對代碼進行回歸測試，再一次測試所有的功能[2]。對新增的代碼需要對應的增加新的測試用例，對原有的代碼需要再次運行所有的測試用例，以便確定修改后的代碼達到了預期的目標。

回歸測試在整個軟件開發(fā)周期中，有著很重要的作用，保障著整個產(chǎn)品的質(zhì)量和安全。但是回歸測試在軟件測試環(huán)節(jié)的工作量很大，手動測試的效率不高[3]。在回歸測試中引入自動化測試，通過控制被測軟件的執(zhí)行，模擬手動測試，可以大大提高測試的效率，節(jié)約開發(fā)的成本[4]。本文通過對測試用例庫中用例的復用，在多個服務器之間進行腳本設計與執(zhí)行，構建了一個適用于回歸測試的自動化平臺。

1 系統(tǒng)設計

軟件測試過程中，有很多重復性的工作，特別是在產(chǎn)品的回歸測試中尤為明顯。我們設計了一個由多臺服務器構成的測試平臺，能夠自動執(zhí)行測試腳本，并通過測試結果的比較分析，最終生成測試報告。

1.1 系統(tǒng)的構成

回歸測試平臺包含4個服務器系統(tǒng)，分別是代碼服務器、編譯服務器、用例庫服務器和測試執(zhí)行服務器等。

代碼服務器上保存著產(chǎn)品所有被測代碼，可以進行產(chǎn)品的版本管理。在這個服務器上可以根據(jù)版本號，自動簽出需要測試的所有代碼。代碼被簽出后，在編譯服務器上進行產(chǎn)品編譯，并根據(jù)測試任務生成測試命令腳本。

用例庫服務器管理著產(chǎn)品測試中的可復用測試用例。通過接口可以向庫中手動添加用例，對庫中已有的用例可以通過用例號自動調(diào)取。測試執(zhí)行服務器主要是在服務器上搭建了產(chǎn)品運行的所有環(huán)境，以確保產(chǎn)品能夠正常運行。根據(jù)產(chǎn)品需求的不同，不同版本的產(chǎn)品所需要的硬件、設備參數(shù)、性能參數(shù)等環(huán)境不太一致。在專門的測試執(zhí)行服務器上執(zhí)行產(chǎn)品測試，最大程度上模擬了最終產(chǎn)品的運行環(huán)境，避免了多系統(tǒng)多版本的干擾，能夠得到最真實的測試結果。

1.2 系統(tǒng)的邏輯關聯(lián)

系統(tǒng)所涉及的四類服務器都構建在局域網(wǎng)環(huán)境內(nèi)。編譯服務器負責從代碼服務器上簽出需要測試的代碼，并開始進行編譯。編譯成功后的產(chǎn)品會回傳到代碼服務器進行版本管理。當編譯結束后，在編譯服務器上會生成測試腳本，也就是生成不同的測試命令清單，并根據(jù)測試命令，拉取測試用例清單。測試用例清單會傳送到測試用例庫，用于測試用例的校驗。這個過程主要是為了確保測試用例庫中有全部所需的用例，以免自動執(zhí)行時，因為無法調(diào)取測試用例而報錯。

測試命令會下發(fā)到測試執(zhí)行服務器中，針對每一條執(zhí)行命令，調(diào)取合適的測試用例，并分析結果，最終生成一個測試報告。圖1給出了在各服務器之間數(shù)據(jù)流轉(zhuǎn)的示意圖。通過這個平臺，能夠有效地進行產(chǎn)品的回歸測試，盡可能檢測出因為代碼的修改而造成的軟件缺陷，而且測試效率得到很大的提升。

2 系統(tǒng)實現(xiàn)

2.1 回歸測試的預處理

在對一個新版本的產(chǎn)品進行回歸測試之前，必須有針對性地進行軟硬件方面的前期準備。在編譯服務器上需要構建編譯環(huán)境，我們的產(chǎn)品主要是要區(qū)分Linux系統(tǒng)和windows系統(tǒng)。測試用例庫服務器上需要根據(jù)代碼的更新，設計并手動新增合適的測試用例。這些用例需要事先進行手動測試，以確保新增的用例真實有效。一般而言，測試用例庫中更多的是新增用例，不太會刪除用例。新增的用例都有對應的用例編號，以便能存入到用例庫中進行復用管理。測試執(zhí)行服務器上需要構建產(chǎn)品運行的真實環(huán)境。對于我們的產(chǎn)品而言，就是需要機、電、光等各部分都配合到位。

2.2 測試的設計

當產(chǎn)品編譯成功并且測試用例庫完備以后，就可以進行回歸測試的腳本設計了。這個過程需要測試人員人工干預，是一個半自動的過程。測試人員根據(jù)產(chǎn)品的業(yè)務邏輯，選擇產(chǎn)品的業(yè)務編號。每個業(yè)務都有相應的測試命令和測試用例列表。測試人員完成選擇后，編譯服務器上會根據(jù)業(yè)務邏輯自動生成測試腳本。

測試命令腳本示例如下所示：

<TestCommandID = 0101.10>

<Parameter1> a </ Parameter1>

<Parameter2> b </ Parameter2>

……

<InputSet>//192.168.1.1/in.dat</InputSet>

<OutSet>//192.168.1.7/result.dat</OutSet>

<TestCase Suits ID>0101</ TestCase Suits ID>

</ TestCommandID>

一個測試任務一般僅生成一個測試腳本，該腳本依據(jù)不同的業(yè)務邏輯分成若干段落，每個段落有若干條測試命令，并定義了命令執(zhí)行的一些參數(shù)。對于環(huán)境參數(shù)一般使用文件附件的形式調(diào)入。測試結果的輸出也是記錄在對應的文件中。同時測試命令中給出了需要到測試用例庫中去調(diào)取的用例套編號。

2.3 腳本的執(zhí)行

測試任務腳本在專門的服務器上執(zhí)行，由測試人員根據(jù)任務編號輸入腳本啟動命令后開始。腳本在執(zhí)行過程中，會對硬件環(huán)境的情況進行檢測，對于硬件沒有準備好或者某些場景沒有保存的情況，都會一一記錄在測試結果內(nèi)。在測試命令執(zhí)行過程中，會自動調(diào)取用例庫中的用例。在測試用例測試過程中，如果出現(xiàn)錯誤，一般會有三種情況。第一種情況是測試用例沒有準備好。這種情況比較少見，一般是由于軟件功能新增后，配套的測試用例沒有同步。第二種情況是測試用例結果錯誤。針對特定的用例值，運行后的結果是錯誤的。這就是需要捕捉的軟件缺陷。還有一種情況是測試命令結果返回錯誤。這種情況是指用例運行結果正確，但是測試命令返回的結果有誤。這個情形出現(xiàn)后，要根據(jù)具體情況分析，看看缺陷到底是出現(xiàn)在軟件產(chǎn)品上，還是出現(xiàn)在測試工具本身。

2.4 報告生成

當測試腳本運行結束后，系統(tǒng)會生成當前測試的報告。測試報告給出了測試的統(tǒng)計信息和明細信息。整個報告一般分為三部分：第一部分是測試的統(tǒng)計信息，給出每種缺陷發(fā)生的數(shù)目;第二部分給出測試用例的運行結果明細;第三部分給出測試命令的運行結果明細。測試報告的示例如下所示：

Test Time： 2018-11-9 09：08：55

Test Task ID： 201811005

Excuting Machine： 192.168.1.7

Object Machine： 192.168.1.2

Summary of Test：

Pass：? 300

EnvNotReady： 0

ExeError： 0

RltError： 0

EnvNotRestore： 0

Test cases detail：

0101 → pass

……

Test command detail：

0101.10 → pass

……

3 結論

當產(chǎn)品的版本進行更新時，隨著代碼的修改或增加，對原有代碼會產(chǎn)生影響。此時需要對整個產(chǎn)品進行回歸測試，以盡可能保證產(chǎn)品整體的穩(wěn)定性和安全性?；貧w測試的重復率較高，而且工作量較大。通過測試任務腳本的生成與執(zhí)行，并結合測試用例的復用，能夠?qū)崿F(xiàn)回歸測試的自動化，避免測試用例執(zhí)行的遺漏，大大提高軟件測試的效率。

參考文獻：

[1] 李丹， 劉杰. 軟件回歸測試及其實踐[J]. 電子產(chǎn)品可靠性與環(huán)境試驗， 2001（6）：23-25.

[2] 李剛毅， 金蓓弘. 自動化回歸測試的技術和實現(xiàn) [J]. 計算機應用研究， 2006， 23（2）：192-194+213.

[3] 張麗波. 軟件自動化測試的設計與實施[J]. 佳木斯大學學報：自然科學版， 2004， 22（4）：568-572.

[4] 朱芳， 李曦， 趙振西. 一種多平臺自動化測試工具的設計和實現(xiàn) [J]. 計算機工程， 2004， 30（24）：186-188.

[通聯(lián)編輯：梁書]