自動化測試入門


 

1         初識自動化測試

如果以前沒有做過自動化測試,那么就不了解自動化測試,可能會覺得自動化測試比較神秘,但是,我們在日常的計算機操作中,可能會碰到一些自動化處理的過程,這些過程和自動化測試比較接近。

例如,

  1. Windows操作系統的控制面板中,有一項功能:任務計划向導
  2. DOS批處理文件,直到今天的Windows Vista還在使用它。它更接近自動化測試。

上述的自動化處理過程還不是測試,因為測試的重要一點是須要驗證,將實際執行的結果和用戶期望的結果進行比較。沒有這個比較,就不是自動化測試。

 

2         自動化測試和手工測試有什么不同

親手做過自動化測試之后,我們對自動化測試就有了一個感性的認識,至少有下列幾點感覺:

  l  機器人從來就不會感覺累

  l  自動化測試的速度,是手工測試無法比的

  l  測試結果准確。例如搜索用時即使是0.33秒或0.24秒,系統都會發現問題,不會忽視任何差異。

  l  一旦腳本完成,可以一勞永逸地運行很多遍,重復使用。

從這里就可以初步體會到自動化測試的優越性――高效率、准確可靠復用性。同時,自動化測試也有不利的一面,即在創造性、發現新缺陷等方面能力不足。

有資料顯示,即使自動化測試實施良好,也只能發現軟件系統中30%的問題,而70%的問題還要靠手工測試發現。所以自動化測試更適合於負載測試、性能測試和回歸測試

 

概括起來,通過自動化測試,軟件企業可以獲得許多好處。

  l  測試周期縮短,因為自動化測試效率高、能夠長時間不間斷地運行。

  l  完成更多的測試,實現更高的測試覆蓋率,保證測試的一致性,提高測試的可靠性,最終獲得更高質量的軟件。

  l  更高的測試團隊士氣,因為有更多機會學習編程、獲取新技術;同時,自動化測試使測試工作變得更有趣。

 

3         什么是自動化測試

談到自動化測試,一般會提到測試工具。許多人覺得使用了一兩個測試工具就是實現了測試自動化,這種理解是不對的,至少是片面的。的確,測試工具的使用是自動化測試的一部分工作,但是“用測試工具進行測試”不等於“自動化測試”。那么,什么是“自動化測試”呢?

自動化測試是把以人為驅動的測試行為轉化為機器執行的一種過程,即模擬手工測試步驟,通過執行程序語言編制的測試腳本自動地測試軟件,自動地完成軟件的單元測試、功能測試、負載測試或性能測試等全部工作。

實際上,對於自動化測試有兩種說法――“自動化測試”和“測試自動化”。它們之間存在某些微妙的差別,如果嚴格地加以區分,可以看作是兩個概念:

自動化測試(Automated Test,側重說明由測試工具自動地執行某項軟件測試任務,自動化處理范圍比較小。例如通過某個軟件工具完成應用系統的功能測試和性能測試等測試執行工作,而測試的計划、設計和管理等其他工作還是由手工完成的。

測試自動化(Test Automated,側重說明整個測試過程都由計算機系統自動完成,體現了更理想的自動化測試思想,有更廣的范疇和更大的挑戰。它不僅要求由工具完成測試的執行,而且要求測試的設計和管理也能由系統自動完成,例如基於模型實現測試設計的自動化、基於軟件設計規格說明書實現測試用例的自動生成、基於數據庫系統實現測試管理的自動化等。

根據上面的描述,測試自動化的要求相對來說高得多,即要求所有的測試工作都由計算機系統自動完成。包括:

  l  測試環境的搭建和設置,如自動上傳軟件包到服務器並完成安裝。

  l  腳本自動生成,如根據UML狀態圖、時序圖等生成可運行的測試腳本。

  l  測試數據的自動產生,例如通過SQL語句在數據庫中產生大量的數據記錄,用於測試;

  l  測試操作步驟的自動執行,包括軟件系統的模擬操作、測試執行過程的監控;

  l  測試結果分析,實際輸出和預期輸出的自動對比分析;

  l  測試流程(工作流)的自動處理,包括測試計划復審和批准、測試任務安排和執行、缺陷生命周期等自動化處理。

  l  測試報告自動生成功能等。

這樣,測試自動化意味着測試全過程的自動化和測試管理工作的完全自動化,是測試工程師所追求的一種理想境界。如果使整個軟件測試過程完全自動化,而不需要絲毫的人工參與或干涉,這是不現實的。

 

4         自動化測試和手工測試應用范圍的對比

在充分利用自動化工具、全力進行自動化測試的同時,牢記不要追求100%的自動化,手工測試仍然至關重要。對高風險的模塊或領域要進行更多的人工測試。根據手工測試和自動化測試的各自優勢,對人工測試和自動測試區別對待,進行有效分工。

適用於自動化測試

適用於手工測試

l  明確的、特定的測試任務

l  軟件包括驗證測試(Build Verification Test、BVT)

l  回歸測試、壓力測試、性能測試等

l  相對穩定且界面改動比較少的功能測試

l  人工容易出錯的測試工作

l  在多個平台環境上運行相同的用例、大量組合性測試或其他重復性測試任務

l  周期長的軟件產品開發項目

l  項目的時間壓力不太大

l  被測試軟件具有很好的可測試性

l  能確保多個測試運行的構建策略

l  擁有運行測試所需的軟硬件資源

l  擁有較強編程能力的測試人員

l  一次性項目或周期很短的項目的功能測試

l  需求不確定或需求變化比較快

l  適用性測試或驗收測試

l  產品的功能設計或界面設計還不成熟

l  沒有適當的測試過程

l  測試內容和測試方法不清晰

l  項目的時間壓力較大

l  團隊缺乏編程能力的測試人才

l  缺乏軟硬件資源

如表,概括起來,任務越單調,自動化測試越適合;重復性越大,自動化測試越適合;越容易量化,自動化測試越適合

 

5         區別對待不同的測試階段

單元測試、集成測試、系統測試和驗收測試等不同的測試階段,雖然都可以采用自動化測試來完成,但自動化測試的程度不一樣。

在單元測試中,自動化測試工具和開發工具集成在一起,自動化測試程度比較高,而且比較全面。如前面所說的,代碼的靜態掃描,可以充分利用測試工具來完成。而單元的功能測試,一般可以借助單元測試框架實現,但須要寫大量的測試腳本或測試代碼,手工的工作量不小,這也是許多軟件公司的單元測試覆蓋率總是不夠高的主要原因。

在集成測試階段,自動化測試工具的作用是間接的,不是直接的、主動的。多數測試組織不是通過測試工具驗證模塊之間的接口,而是通過基本功能的驗證來驗證系統的集成,即通過BVT來完成每日測試,以滿足每日構建、每日集成(持續集成)的需要。

在系統測試階段,人們首先會將自動化測試運用在性能測試、壓力測試、可靠性測試中,而在功能測試中,自動化測試的投入會比較謹慎。功能測試中邏輯、數據和API等驗證,比較適合自動化測試,而GUI界面、易用性等測試,更宜由手工完成。

在用戶參與的驗收測試中,一般不宜於采用自動化測試。同樣,針對軟件界面操作友好性、易用性的測試,自動化無能為力,必須由手工測試來完成。

 

6         如何評估測試工具

滿足測試任務及其特點的測試工具可能會比較多,我們須要考慮對它們進行評估,選擇出正確的測試工具。如何評估測試工具呢?人們可能會想到下列這些指標:

  l  工具的功能是否強大,或者是滿足需要?

  l  價格是否合適、在預算之內?

  l  性能價格比如何、是否數一數二?

  l  工具的質量,工具運行是否穩定?

  l  目前的用戶量或是否流行?

  l  和其他測試工具的兼容性、集成是否容易?

  l  技術支持和服務是否及時、方便?

有時候,工具的選擇也沒有那么復雜,而是根據市場決定,市場哪個流行就選擇哪個。市場流行,自然也有優勢,這樣做也不無道理。但這樣做,具有盲目性,畢竟功能最強的工具不一定適合自己,最合適的工具,才是最好的。

我們建議將開源測試工具作為首選目標。如果開源測試工具應用一段時間之后,確實不能滿足自己的需求,可以考慮選擇商業化的測試工具。實際上,如果發現工具不能滿足自己的需求,因為它是開源工具,完全可以對它進行修改(二次開發),增加相應的功能特性,從而滿足自己的特定需求,這也是開源測試工具的魅力所在。

千萬不要一開始就用巨資引入商業化的測試工具,那樣測試人員壓力很大,急於求成,反而效果不好,要么測試工具成了擺設,要么從此以后再也不敢提“自動化測試”。

 

7         如何選擇合適的測試工具

測試工具的選擇,還須要從某類具體的工具着手,對症下葯,才能達到期望的目標。一般來說,測試工具可以分為:

單元測試工具,包括靜態測試工具和動態測試工具;

功能測試工具,包括WEB功能測試工具、Windows客戶端功能測試工具等;

性能測試工具,包括負載測試工具、壓力測試工具等;

測試管理工具,包括缺陷、測試用例和計划等管理工具;

其他測試工具,如安全測試、多媒體測試等。

 

7.1 單元測試工具的選擇

建議:用什么編程語言就選用對應這種編程語言的單元測試工具,如:

如果用JAVA語言編程,就要選用JAVA的單元測試工具,如Junit,TestNG

如果用NET語言,就要選用適用C#的單元測試工具,如:NUnit,NUnitForms等;

如果用PHP語言,就要選用PHPUnit作為單元測試工具;

如果針對C/C++語言的程序,就要選擇相應的單元測試工具,如CppTest*等;

如果只是進行純頁面的開發,針對HTML文件的table\form\link等元素進行測試,則單元測試工具選擇HtmlUnit。

 

7.2   功能測試工具的選擇

如:Selenium\TestMaker

 

7.3   性能測試工具的選擇

Grinder是一個很好的負載測試框架,被譽為J2EE上的LoadRunner。通過Jython來編寫測試腳本,支持多種協議的WEB服務和應用服務器,基於HTTP的測試可以由瀏覽器來記錄整個要測試的過程。

TestMaker通過基於Jython的測試代理來完成測試,並借助PTTMonitor以監控應用服務器的資源和統計信息。

OpenSTA是針對B/S結構的性能測試開源工具,基於公共對象請求代理體系結構,並通過虛擬代理來記錄通過proxy的HTTP請求,而其性能測試指標收集各項性能指標,然后進行分析,能提供較為豐富的圖形化測試結果,提高了測試報告的可讀性。

Siege是一個開源的WEB壓力測試和評測工具。

ApacheBench能同時模擬多個並發請求,專門用於Web服務器的基准測試。

DBMonster是一個生成隨機數據、用來測試SQL數據庫的壓力測試工具。

JDB Hammer是針對MySQL數據庫服務器進行壓力測試的開源工具,而MySQL官方提供的壓力測試工具則mysqlslap.

 

另外要說明的是,TestMarker是一個更靈活的框架,可以和Seleinium、soapUI集成,充分利用Selenium和soapUI的測試能力,而TestMarker只是更好地調度、監控和管理測試的過程,監控系統的性能指標,獲得測試結果。

 

7.4   測試管理工具

軟件測試離不開管理,包括測試計划、用例、測試結果和缺陷等管理,這些管理也通過工具和系統來幫助處理,以提高管理的效率和准確性。測試管理工具的選擇,依賴於測試組織的規模和流程。規模小的組織,可以選擇輕量型的測試管理工具;而規模大的組織,應選擇功能強、支持多項目和分布式的測試管理工具。

對於輕型的開源測試管理框架,如JtestCase\FitNesse\Salome TMF\JTR等

對於更為規范的、具有一定規模的軟件組織,可以選用TestLink\Bromine\Eclipse TPTP等測試管理框架或系統。

軟件測試管理的重要工作之一是缺陷管理,缺陷管理工具有Mantis、Bugzilla、Bugfree、Scarab、TrackIT、Itracker等。

 

7.5   其它測試工具

7.5.1       安全測試工具

主要有Nikto、Paros Proxy、SPI Dynamics WebInspect、Tripwire、TamperIE、Wapiti,其中前3項工具的功能強大,而其他工具則檢查某個方面的測試。例如,TamperIE是一個小巧的XSS漏洞檢測輔助工具,而WebScarab分析HTTP和HTTPS協議的通信。除此之外,還有專門檢查數據庫SQL注入攻擊漏洞的工具,如sqlninja.

Paros Proxy是基於JAVA的WEB代理程序,可以評估WEB的應用程序的漏洞。它支持動態地編輯、查看HTTP/HTTPS,從而改變cookies和表單字段等項目。它包括一個WEB通信記錄程序。

 

7.5.2       可達性測試工具

可達性(Accessibility)在國際性軟件測試中也是不可忽視的。這類工具包括色彩對比度分析,鍵盤和鼠標的特殊操作等。微軟公司在2009年3月發布了兩種可達性測試工具(http://www.codeplex.com)。

AccChecker:用戶界面可達性測試工具(UI Accessibility Checker);

UIA Verify:用戶界面自動驗證(UI Automation Verify).

除此之外,還有很多這類測試工具,詳見:http://www.w3.org/WAI/ER/tools/complete.

 

7.5.3     多媒體測試工具

多媒體應用越來越多,對測試工具的要求也越來越高,須要覆蓋語言(VoIP)、視頻(Vedio)和IP電話等各項多媒體應用的特殊測試,如多媒體數據交換、服務質量(Qos)等。多媒體方面的開源測試工具有Ethereal、Auto Tool、SIPp、Seagull、Asterisk和X-Lite等。

 

7.5.4     網絡監控工具

網絡監控工具也常常在測試中使用,這類開源工具比較多,選擇的余地很大,常用的工具有Nessus、Ethereal/Wireshark、Snort、Switzerland和Netcat,其中Wireshark就很不錯。

 


注意!

本站转载的文章为个人学习借鉴使用,本站对版权不负任何法律责任。如果侵犯了您的隐私权益,请联系我们删除。



 
粤ICP备14056181号  © 2014-2021 ITdaan.com