恰當選擇軟件測試自動化方案
發(fā)布: 2007-8-14 09:41 | 作者: 網(wǎng)絡(luò)轉(zhuǎn)載 | 來源: 網(wǎng)絡(luò)轉(zhuǎn)載 | 查看: 108次
隨著測試流程的不斷規(guī)范以及軟件測試技術(shù)的進一步細化，軟件測試自動化已經(jīng)日益成為一支不可忽視的力量。能否借助于這支外在力量以及如何借助于這支力量來規(guī)范企業(yè)測試流程、提高特定測試活動的效率，正是本 期所要討論的話題。
目前，軟件測試自動化的研究領(lǐng)域主要集中在軟件測試流程的自動化管理以及動態(tài)測試的自動化（如單元測試、功能測試以及性能測試方面）。在這兩個領(lǐng)域，與手工測試相比，測試自動化的優(yōu)勢是明顯的。首先自動化測試可以提高測試效率，使測試人員更加專注于新的測試模塊的建立和開發(fā)，從而提高測試覆蓋率; 其次，自動化測試更便于測試資產(chǎn)的數(shù)字化管理，使得測試資產(chǎn)在整個測試生命周期內(nèi)可以得到復(fù)用，這個特點在功能測試和回歸測試中尤其具有意義; 此外，測試流程自動化管理可以使機構(gòu)的測試活動開展更加過程化，這很符合CMMI過程改進的思想。根據(jù)Oppenheimer Funds的調(diào)查，在2001年前后的3年中，全球范圍內(nèi)由于采用了測試自動化手段所實現(xiàn)的投資回報率高達1500％。
方案選型六大原則
然而存在優(yōu)勢是否就一定意味著選擇自動化測試方案都能為企業(yè)帶來效益回報呢？也不盡然，任何一種產(chǎn)品化的測試自動化工具，都可能存在與某具體項目不甚貼切的地方。再加上，在企業(yè)內(nèi)部通常存在許多不同種類的應(yīng)用平臺，應(yīng)用開發(fā)技術(shù)也不盡相同，甚至在一個應(yīng)用中可能就跨越了多種平臺; 或同一應(yīng)用的不同版本之間存在技術(shù)差異。所以選擇軟件測試自動化方案必須深刻理解這一選擇可能帶來的變動、來自諸多方面的風險和成本開銷。
以下筆者給出企業(yè)用戶進行軟件測試自動化方案選型的參考性原則，這些原則是從筆者實際工作中凝練而成的，它包括以下六個方面的建議:
● 選擇盡可能少的自動化產(chǎn)品覆蓋盡可能多的平臺，以降低產(chǎn)品投資和團隊的學(xué)習(xí)成本;
● 測試流程管理自動化通常應(yīng)該優(yōu)先考慮，以滿足為企業(yè)測試團隊提供流程管理支持的需求;
● 在投資有限的情況下，性能測試自動化產(chǎn)品將優(yōu)先于功能測試自動化被考慮;
● 在考慮產(chǎn)品性價比的同時，應(yīng)充分關(guān)注產(chǎn)品的支持服務(wù)和售后服務(wù)的完善性;
● 盡量選擇趨于主流的產(chǎn)品，以便通過行業(yè)間交流甚至網(wǎng)絡(luò)等方式獲得更為廣泛的經(jīng)驗和支持;
● 應(yīng)對測試自動化方案的可擴展性提出要求，以滿足企業(yè)不斷發(fā)展的技術(shù)和業(yè)務(wù)需求。
實戰(zhàn)模擬
以下筆者結(jié)合一個典型的企業(yè)客戶，剖析其適用的軟件測試自動化方案選型過程。
1．公司背景介紹
A公司是一家大型保險公司，擁有近20個城市的分公司，并在其中5個城市建立了IT支持中心。平均每年的上線應(yīng)用數(shù)量在20個左右（新業(yè)務(wù)系統(tǒng)和原有業(yè)務(wù)系統(tǒng)的主要版本發(fā)布）。目前A公司的專職測試團隊人數(shù)不足30人，而且測試團隊的測試人員技能參差不齊，目前測試只是作為項目上線前的一道工序而已。在測試團隊內(nèi)部也幾乎沒有自動化的手段，主要依靠手工測試。由于已上線應(yīng)用系統(tǒng)的問題，開發(fā)團隊必須分出一部分資源去維護和修復(fù)上線應(yīng)用，而同時測試團隊的測試成果和效率卻無法和這些應(yīng)用質(zhì)量掛鉤，也更無從談起對軟件質(zhì)量的控制。所以，A公司決定在軟件質(zhì)量和測試方面進行投入，他們考慮以下幾方面:
● 引進軟件測試流程管理的自動化，提高軟件測試過程的管理水平，使軟件測試和軟件開發(fā)一樣可被評估、被衡量。
● 實現(xiàn)性能測試自動化，所有應(yīng)用上線之前必須有應(yīng)用性能風險評估報告和相關(guān)部門的確認
● 逐步實現(xiàn)功能測試的自動化，在目前人員配置的情況下，把部分手工測試變成自動化測試，提高測試可信度，降低人為錯誤。
● 通過軟件測試自動化，管理軟件測試中的案例、缺陷、報告等資產(chǎn)，進一步提升軟件測試的效率并建立測試基礎(chǔ)庫。
● 在規(guī)劃中，將來的2～3年內(nèi)使所有的應(yīng)用系統(tǒng)上線都必須有數(shù)字化的測試數(shù)據(jù)作為依據(jù)。
2．公司應(yīng)用系統(tǒng)的情況
由于保險公司的業(yè)務(wù)種類繁多，同時在經(jīng)過了幾十年的經(jīng)營后，公司內(nèi)的應(yīng)用系統(tǒng)從早期的終端方式到現(xiàn)代的J2EE和.NET等應(yīng)有盡有，魚龍混雜。IT部門已經(jīng)建立的3年規(guī)劃，即在未來的3年時間內(nèi)將所有終端和C/S方式的應(yīng)用轉(zhuǎn)換成B/S架構(gòu)，但當前仍然需要對這些舊應(yīng)用系統(tǒng)進行維護，以保證業(yè)務(wù)的順利進行。對于開發(fā)部門來說，目前新應(yīng)用開發(fā)基本上已經(jīng)以B/S架構(gòu)為主，主要是基于J2EE架構(gòu)的Web HTTP應(yīng)用和部分Window.NET Form的應(yīng)用。
3．公司軟件測試現(xiàn)狀
企業(yè)機構(gòu)在做測試自動化選型時一定要考慮清楚企業(yè)內(nèi)部哪些部分可以實施自動化、哪些部分暫不實施自動化、哪些部分僅在某幾個項目做自動化試點。切忌匆忙上馬或盲目否定，缺乏實事求是的理性思考。
測試部門目前僅負責系統(tǒng)測試和對用戶驗證測試進行管理，對于之前的單元測試和集成測試主要由開發(fā)團隊中劃分出的一部分臨時測試人員完成。由于缺乏監(jiān)測手段，測試部門也無法收集和確定集成測試和單元測試的完成情況，在整個軟件測試過程中，業(yè)務(wù)需求是由開發(fā)部門通過Rational RequisitePro進行管理，但測試需求目前尚沒有提出要求，測試案例主要通過在公司公用的文件服務(wù)器中的目錄管理方式管理，對測試中缺陷流程等管理主要依靠郵件的流轉(zhuǎn)進行處理。目前90％以上的測試是通過Excel和Word等測試案例文檔來完成，測試人員對軟件測試自動化的認識僅停留在“記錄＋回放”的認識上。
4．可供選擇的方案
方案A: A公司可以采用美科利（Mercury）公司產(chǎn)品為主的軟件測試自動化方案。
● 依照原先的郵件流轉(zhuǎn)過程配置TestDirector缺陷管理流程，為每個保險業(yè)務(wù)的開發(fā)小組和測試團隊分配相應(yīng)的用戶許可證，取消原有郵件方式。
● 部署Mercury Quick Test Professional，以便完成應(yīng)用程序相關(guān)功能測試。
● 部署Mercury Load-Runner。從測試團隊中分化出專職的性能測試自動化工程師和小組，和業(yè)務(wù)部門協(xié)調(diào)，建立A公司應(yīng)用系統(tǒng)上線性能指標，通過LoadRunner給出測試指標。
● 建議A公司成立專門的質(zhì)量控制部門，對TestDirector中的數(shù)據(jù)定期進行分析，建立相關(guān)質(zhì)量模型，以便于企業(yè)量化管理和過程改進。
方案B: A公司也可以采用IBM Rational產(chǎn)品為主的軟件測試自動化方案。
● 采用Rational Test manager來進行整個測試流程的管理，為相關(guān)開發(fā)和測試小組成員分配相應(yīng)權(quán)限，改變以前通過郵件以及Word、Excel文檔管理測試的工作方式。
● 部署Rational Robot，用它來完成功能相關(guān)的測試工作以及新版本發(fā)布時的冒煙測試。此外，Rational Robot也能較好地完成性能相關(guān)測試。統(tǒng)一的操作方式降低了工具的學(xué)習(xí)周期和培訓(xùn)帶來的大筆開銷。
● 部署Rational Purify plus，使測試工作前移到開發(fā)階段。由于Purify plus能較好地支持白盒測試，編程人員在編碼階段引入的錯誤能盡早被檢測到，這大幅降低了后期測試的開銷。
● 建議A公司成立專門的質(zhì)量控制部門，對Test manager中的數(shù)據(jù)定期進行分析，建立相關(guān)質(zhì)量模型，以便于企業(yè)量化管理和過程改進。
方案C: A公司也可以采用開源軟件為主的軟件測試自動化方案。
● 采用Bugzilla來進行Bug跟蹤管理，采用Bugzilla Test Runner進行測試用例管理，采用CVS進行測試資源的配置管理。
● 采用MaxQ和WebInject對B/S結(jié)構(gòu)的應(yīng)用系統(tǒng)進行功能測試。
● 采用DBMonster、Open－STA、LoadSim進行性能相關(guān)測試。
● 可采用Xunit架構(gòu)的開源工具對不同語言的程序單元進行單元測試。
● 建議A公司成立專門的開源軟件維護小組，以解決可能會碰到的工具維護工作。
● 建議A公司成立專門的質(zhì)量控制部門，對Bugzilla、Test Runner、CVS中的數(shù)據(jù)定期進行分析，建立相關(guān)質(zhì)量模型，以便于企業(yè)量化管理和過程改進。
5． 方案評價
由于不同客戶在組織架構(gòu)、員工素質(zhì)以及流程管理水平等方面的不同，我們很難用一個實例、一兩句話來說明不同解決方案的適用性。在上面的例子中，筆者給出了3種可行的方案，具體選擇哪一個，需要仔細權(quán)衡。這里筆者給出一般性的意見，對于不想受制于某個測試自動化廠家的企業(yè)，開源絕對是一個理想的選擇。此外，它不需要支付成本，工具的源代碼可以隨意修改，因而具有較好的靈活性。但開源工具的弊端也是明顯的: 缺乏使用培訓(xùn)和技術(shù)支持，工具的用戶界面一般也較為粗糙。而對于那些比較看重培訓(xùn)和售后支持的企業(yè)，筆者建議選擇IBM Rational或Mercury或其他廠家的產(chǎn)品。這樣雖然需要支付一部分費用，但省去了工具維護所需要的大量工作。至于具體選擇哪個廠家的產(chǎn)品為好，筆者尚無結(jié)論性意見。相信讀者朋友都有一些見仁見智的看法，不妨來信交流。
實施中的注意事項
首先，一個企業(yè)實施測試自動化，絕對不是拍腦袋說干就能干好的，它不僅涉及測試工作本身流程上、組織結(jié)構(gòu)上的調(diào)整與改進，甚至也包括需求、設(shè)計、開發(fā)、維護及配置管理等其他方面的配合。如果對這些必要的因素沒有考慮周全的話，必然在實施過程中處處碰壁，既定的實施方案也無法開展。其次，盡管自動化測試可以降低人工測試的工作量，但并不能完全取代手工測試。100％的自動化測試只是一個理想目標，根據(jù)筆者的經(jīng)驗，即便一些如SAP、Oracle ERP等測試庫規(guī)劃十分完善的套件，其測試自動化率也不會超過70％。所以一味追求測試自動化只會給企業(yè)帶來運作成本的急劇上升。再次，實施測試自動化需要企業(yè)有相對規(guī)模的投入，對企業(yè)運作來說，投入回報率將是決定是否實施軟件測試自動化的最終指揮棒，筆者建議企業(yè)在決定實施軟件測試自動化之前，必須要做量化的投資回報分析。此外，實施軟件測試自動化并不意味著必須采購強大的自動化軟件測試工具或自動化管理平臺，畢竟軟件質(zhì)量的保證不是依靠產(chǎn)品或技術(shù)，更多的因素在于高素質(zhì)的人員和合理有效的流程。
http://www.testage.net/html/87/n-139487.html參考資料：
http://www.testage.net