自動化初識

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，其中前３項工具的功能強大，而其餘工具則檢查某個方面的測試。例如，TamperIE是一個小巧的XSS漏洞檢測輔助工具，而WebScarab分析HTTP和HTTPS協議的通訊。除此以外，還有專門檢查數據庫SQL注入攻擊漏洞的工具，如sqlninja.

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

 

7.5.2       可達性測試工具

可達性（Accessibility）在國際性軟件測試中也是不可忽視的。這類工具包括色彩對比度分析，鍵盤和鼠標的特殊操做等。微軟公司在２００９年３月發佈了兩種可達性測試工具（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就很不錯。

 

轉自：http://www.cnblogs.com/yangxia-test/p/4554385.html