一種工業自動化測試流程的建立方法

摘 要:軟件質量保證活動與軟件生命周期各階段的檢驗和有效性活動緊密相聯。為了極大程度地減少人為干預，提高軟件的測試效率，這里從實際出發，采用建立一整套的自動化測試的工業化流程的方法。該過程分三個階段重點討論從代碼編譯、單元測試、產品打包到最終的自動化測試的全過程。做了基于開放源碼開發平臺ISMP和RFT框架的測試實驗。結果表明，建立的自動化測試的流程可以有效地實現自動化測試，在很大程度上提高了測試效率，縮短了整個產品研發周期。關鍵詞:軟件質量保證; 自動化測試; 軟件測試; 軟件生命周期

中圖分類號:TN911-34; TP3115文獻標識碼:A

文章編號:1004-373X(2010)18-0053-04

Establishment Method of Industrial Automation Testing Process

LI Liang1， LI Yuan-cheng2

(1.Academic Service Section， Xi’an University of Posts and Telecommunications， Xi’an 710121， China;

2.Department of Computer Science， Xi’an Jiaoyong University， Xi’an 710049， China)

Abstract: Software quality assurance activities have close relationship with the various stages of the software life cycle testing and the effectiveness of activities. A set of automation testing industrialization processes are established proceeding from the reality to reduce the human intervention at great extent. The entire automation testing process， including code compilation， unit testing， product packaging and the ultimate testing， is dicussed emphatically. The testing experiment was implemented based on the open source development platform install shield multiplatform (ISMP) and IBM rational functional test (RFT) framework. The experimental results show that the testing method can significantly reduce the anthropogenic interfe-rence and improve the efficiency of software testing in comparison with the traditional test automation.Keywords: software quality assurance; automation testing; software testing; softwarelife cycle

0 引 言

當今的軟件發展，很大程度上還是停留在手工作坊式的操作水平上[1-2]。這種情況導致了由于溝通、技術限制等方面的原因，多階段的軟件開發過程不可避免地存在著錯誤積累與放大效應。一般來講，當前階段的工作較上一階段有一定的程度擴展，統計與經驗都表明[3]，其擴展倍數一般是5~10倍，同時錯誤也同樣被放大。因此，手工開發的軟件質量無法得到保證。此外，這種傳統的軟件開發方式還存在開發周期長，對用戶需求的改變、市場的變化適應性差，二次開發困難，擴展、升級、維護成本過高等缺點，因而實現軟件的自動化生成是軟件產業發展的必然趨勢。

在這里提出的軟件自動化是“自動化+組裝+測試”軟件工藝思想的實施工具[4-5]。它通過對軟件流程優化和軟件測試技術進行整合與集成，實現了軟件由從源代碼的編譯、各模塊的測試、產品的打包、在測試機器的安裝到產品的功能測試報告生成的整個過程的工藝化、流水線式的自動生產。

1 自動化的基本概念

1.1 自動化的分類

圖1給出了三種類型的自動化:

(1) 命令自動化。通常是指調用某個命令后計算機去執行一系列固定不變的操作。例如，運行構建腳本。

(2) 調度自動化。通常是指當命令自動化建立好后，按時間計劃去調用將命令自動化腳本，無需人工干預的去執行。

(3) 觸發自動化。通常是指當命令自動化建立好后且某個重要事件發生時去觸發命令自動化腳本的執行。

充分利用上述三種自動化，可以從軟件的構建過程、部署過程以及檢審過程得到充分的反饋，并以此可以決定是否進行修改代碼，將錯誤控制在最小的范圍內。

圖1 自動化的類型

1.2 自動化的準備

為了使軟件自動化的過程建立起來，還需要以下工具:

(1) 版本控制系統。一個版本控制系統最基本的功能就是記錄每次修改的地方，并且可以讓使用者方便地存取各個版本、比較版本差異。同時，此系統建立了一個多人開發的環境，可以記錄每個人的修改，解決版本沖突的問題。通常使用的工具有以CVS為代表的開放源碼產品和以IBM Rational的ClearCase為代表的商業產品。

(2) 自動化測試。自動化測試就是通過自動化測試工具或其他手段，按照測試工程師的預定計劃進行自動的測試，目的是減輕手工測試的勞動量，從而達到提高軟件質量的目的。手工測試的目的在于發現新缺陷，自動化測試的目的在于發現老缺陷。

(3) 建立自動化命令的腳本。自動化命令腳本是指一些shell腳本(或批處理文件)，它們指定計算機以何種方式運行一系列的操作。自動化命令腳本通常是易學易用、調試簡單，同時也不需構建。

(4) 通信機制。當自動化流程運行完畢時，系統將給予用戶預期的反饋信息。這些反饋可以通過電子郵件、網頁等形式報告給自動化的用戶。當然，用戶也可以通過定制手機短信得到更加及時信息。

1.3 自動化流程的各個階段

完整的自動化流程需要三個階段[6-7]。

如圖2所示，第一階段主要完成的工作為獲取最新版本、代碼編譯和單元測試等三部分。第二階段主要完成的工作為獲取最新版本、產品打包和產品發布三部分。第三階段則主要完成獲取最新產品、產品安裝和功能測試等三部分工作。一般情況，自動化的頻度應該隨自動化過程不同而不同。例如，構建過程是命令自動化，它應該在運行于任何需要構建一個版本的時候;而調度自動化應該盡可能的頻繁以便于及時的反饋給用戶軟件的健康情況。

2 完整的自動化流程

2.1 第一階段

該階段由3個部分組成1個周期，如圖3所示。第一部分是根據配置文件到指定的CVS服務器得到最新版本的代碼。第二個部分是編譯這些代碼。第三個部分是對編譯好的的代碼進行單元測試。在本階段需要用到的工具有Ant，JUnit和CVS。

圖2 自動化流程

圖3 一次性驗證

Ant是apache基金會下的子項目，是一個用于簡單或復雜Java工程的自動化構建、部署工具。最基本的任務包括添加和移除目錄、使用FTP拷貝和下載文件、創建JAR和ZIP文件以及創建文檔。更高級的特性包括用源代碼控制系統諸如CVS或者SourceSafe來檢查源代碼、執行SQL查詢或腳本、將XML文件轉換為人能識別的HTML，以及為遠程方法調用生成stub(存根)文件。

Ant是一種基于Java的Build工具。理論上來說，它有些類似于C中的Make，但比Make優越。Ant是為Java而創建，帶有屬于其自身的、獨特的范例，具有可移植性。而Make依賴于固定的操作系統命令，利用Ant構建的純Java工程是可移植的。因為Ant本身就是用Java編寫的，具有良好的跨平臺性，同時可以通過增加新的Java類來擴展Ant的功能，而無需去了解不同平臺上不同的腳本語言。Ant bulidfiles使用XML語法，以XML樹來描述Target/Task的關系，文件結構清晰、易讀易寫，并且利用XML對格式的控制來避免由于配置文件的錯誤造成的Build操作失敗。

JUnit最初是由Erich Gamma(GoF之一)和Kent Beck(敏捷編程和重構的先驅之一)編寫的，是一個開發源代碼的Java測試框架，用于編寫和運行可重復的測試。它是用于單元測試框架體系xUnit的一個實例(用于Java語言)。它包括以下特性:

(1) 用于測試期望結果的斷言(assertion);

(2) 用于共享共同測試數據的測試工具;

(3) 用于方便的組織和運行測試的測試套件;

(4) 圖形和文本的測試運行器。

在JUnit單元測試框架的設計時，一共設定了三個總體目標:第一個是簡化測試的編寫，這種簡化包括測試框架的學習和實際測試單元的編寫;第二個是使測試單元保持持久性;第三個則是可以利用既有的測試來編寫相關的測試。JUnit一般是用來進行單元測試的，因此需要了解被測試代碼的內部結構，即所謂的白盒測試。另外JUnit是在敏捷編程(extreme programming)和重構(refactor)中被極力推薦使用的工具，因為在實現自動單元測試的情況下可以大大的提高開發的效率。

在一次性驗證周期中通過Ant將獲取最新版本、編譯代碼和調用JUnit進行單元測試這三部分組織成任務列表。一個周期完成大概需要4 h，當然這個時間是在配置文件中進行指定的。每隔4 h檢測1次，在檢測過程中若發現CVS上的版本與當前版本相同則不進行下載，等待下次檢測。否則，下載新程序，轉入第二部分的編譯代碼。當完成第二個部分工作時轉入第三個部分中。在第三個部分中，Ant將調用利用JUnit寫好的單元測試代碼進行測試。

在這個周期中會產生“代碼下載”、“代碼編譯”和“單元測試”報告。其中“代碼下載”報告通過電子郵件等方式發送給配置管理員確認配置的正確性，“代碼編譯”和“單元測試”這兩個報告發送給測試小組，由測試小組對測試進行確認提交給有關部門。

2.2 第二個階段

該階段由3個部分組成1個周期，如圖4所示。第一部分是根據配置文件到指定的CVS服務器得到最新版本的程序;第二個部分是產品打包;第三個部分是產品發布。

圖4 調度構建

在本階段用到的工具有Ant，ISMP和CVS。ISMP(install shield multiplatform)是一款可以構建多平臺和多語言支持的安裝程序的開發工具。它給開發人員提供了一步一步的向導來構建一個安裝項目，它支持的平臺有Windows，Linux，Solaris，MacOSX，AIX，HP-UX和OS/400[9]。它支持的安裝模式有圖形化安裝，控制臺安裝和自動安裝。自動安裝通過在手動安裝時產生的記錄文件來進行自動安裝，用戶不需要進行干預。

ISMP為創建、構建按測試多平臺安裝提供了最靈活全面的安裝創建技術。ISMP提供了一系列全面且靈活使用的工具，使得方便快捷的精確設計且構造出你的應用程序。在ISMP中，安裝程序主要由多個Product Bean和Wizard Bean組成的。每一個Product Bean 和 Wizard Bean都是一個JavaBean組件，因此用戶可以自行定制組件來擴充現有組件的功能。

在調度構建周期中通過Ant將獲取最新版本、產品打包和產品發布這三部分組織成任務列表。1個周期的完成大概需要48 h，當然根據實際情況這個時間是在配置文件中進行指定的。每隔48 h檢測1次，在檢測過程中若發現CVS上的版本與當前版本相同則不進行下載，等待下次檢測。否則，下載新程序，轉入第二部分的產品打包。第二部分完成的工作是將可運行的應用程序打包成可以為用戶所用的安裝程序。完成第二個部分工作時轉入第三個部分中。在這個部分中調用一個應用程序使用已寫好的配置文件將打包好的程序發布到FTP服務器上，以供下載使用。

在這個周期中會產生《程序下載》、《產品打包》和《產品發布》報告。其中《程序下載》報告通過電子郵件等方式發送給配置管理員確認配置的正確性，《產品打包》和《產品發布》這兩個報告發送給測試小組進行確認和修改。

2.3 第三個階段

該階段由2個部分組成1個周期，如圖5所示。第一部分是根據配置文件到指定的FTP服務器得到最新版本的代碼。第二個部分是功能測試。在本階段用到的工具有Ant和RFT。

圖5 安裝測試

RFT(IBM Rational Functional Test)是一款先進的、自動化的功能和回歸測試工具[8]，它適用于測試人員和GUI開發人員。使用它，測試新手可以簡化復雜的測試任務，很快上手;測試專家能夠通過選擇工業標準化的腳本語言，實現各種高級定制功能。通過IBM的最新專利技術，例如基于Wizard的智能數據驅動的軟件測試技術、提高測試腳本重用的Script Assurance技術等，大大提高了腳本的易用性和維護能力。同時，它第一次為Java和Web測試人員，提供了和開發人員同樣的操作平臺(Eclipse)，并通過提供與IBM Rational整個測試生命周期軟件的完美集成，真正實現了一個平臺統一整個軟件開發團隊的能力。

IBM RFT的最大特色就是基于開發人員的同一開發平臺(Eclipse)，為Java和Web測試人員提供了自動化測試能力。使用RFT進行軟件測試時，我們只要在開發人員工作的Eclipse環境中打開Functional Test透視圖，就會馬上擁有專業的自動化功能測試工具所擁有的全部功能。

在安裝測試周期中通過Ant將獲取最新版本、產品安裝和功能測試這三部分組織成任務列表。1個周期的完成大概需要1個工作周。每隔1個工作周就到FTP服務器上檢測新發布的程序，在檢測過程中若發現沒有最新版本則不進行下載，等待下次檢測。否則，下載新程序。如果有特殊情況發生，例如發生一個工作日的延誤，在相應的配置文件中進行配置，重新轉入檢測過程。第二部分是產品安裝。通過ISMP構建的安裝程序可以通過命令行的方式進行產品的安裝，這樣大大的方便了Ant的調用執行。三部分是Ant將調用利用RFT寫好的單元測試代碼進行測試。

在這個周期中會產生《產品下載》、《產品安裝》和《功能測試》報告。其中《產品下載》報告通過電子郵件等方式發送給配置管理員確認配置的正確性。《產品安裝》和《功能測試》報告發送給測試小組，由測試小組對測試進行確認提交給有關部門。

3 結 語

本文建立了一整套的自動化測試流程，從實際出發實現了自動化的軟件測試，將繁瑣的任務自動化，提高了準確性和測試人員的積極性，將測試技術人員解脫出來投入更多精力設計更好的測試用例。自動化測試流程可以很方便的實現從程序的編譯到成熟版本形成的軟件質量保證的全過程，特別是在程序修改比較頻繁時，可以極大提高測試效率，縮短了整個產品研發周期。由于整個過程是自動化的，所以可以執行一些手工測試困難或不可能進行的測試。更有意義的是增加軟件信任度，不存在執行過程中的疏忽和錯誤，使得整個測試過程完全取決于測試的設計質量。

參考文獻

[1]單錦輝，姜瑛，孫萍.軟件測試研究進展[J].北京大學學報:自然科學版，2005，41(1):134-139.

[2]王海礁，韓文文.自動化測試在國際軟件測試中的應用[J].軟件導刊，2010，9(3):12-14.

[3]周景才，楊家紅，陳毅波.模型驅動的自動化測試架構[J].計算機工程與應用，2010，46(2):66-68.

[4]鞠秀娟，趙明.軟件自動化測試概述及應用工具分析[J].計算機應用，2007，27(Z6):317-318，321.

[5]CLARK M. Pragmatic project automation: How to build， deploy and monitor Java Applications[M]. [S.l.]: Pragmatic Programmers， 2004.

[6]BINDER R V. Testing of object-oriented system[M]. England: Addison-wesley， 2001.

[7]SEIFERK Dirk， HELKE Steffen， SANTEN Tomas. Comformance testing for statecharts[R/OL]. [2003-03-01]. Http://www.siteseerx.ist.psu.edu. Technical University of Berlin， 2003.

[8]IBM. IBM Rational Functional Tester[EB/OL]. [2005-04-12]. http://www.ibm.com.

[9]彭園園，熊盛武.測試用例集的優化技術分析與改進[J].現代電子技術，2009，32(6):77-80.

[10]馬亮，張剛.測試用例自動生成方法的現狀及研究[J].現代電子技術，2008，31(6):126-129，132.