淺談自動化軟件測試

關鍵字：自動化，軟件測試
自動化軟件測試是把以人為驅動的測試行為轉化為機器執行的一種過程。通常，在設計了測試用例并通過評審之后，由測試人員根據測試用例中描述的過程一步一步地執行測試，得到實際結果與期望結果的比較。在此過程中，為了節省人力、時間或硬件資源，提高測試效率，便引入了自動化測試的概念。所謂自動化測試，就是使用自動化測試工具來對軟件進行測試，自動化測試工具可以自己開發，也可選用現成的工具。常用的自動化測試工具有：QTP，WinRunner，Rational Robot，AdventNet Qengine，SilkTest，QA Run，Test Partner，Holodeck，Telelogic TAU，AutoRunner，Phoenix Framework等等。這些工具的功能不太一樣，可根據需要選用不同的工具，詳見百度百科[1]。
目前，軟件測試自動化的研究領域主要集中在軟件測試流程的自動化管理以及動態測試的自動化（如單元測試、功能測試以及性能測試方面）。在這兩個領域，與手工測試相比，測試自動化有以下的優勢：
A）自動化測試可以提高測試效率，使測試人員更加專注于新的測試模塊的建立和開發，從而提高測試覆蓋率;
B）自動化測試更便于測試資產的數字化管理，使得測試資產在整個測試生命周期內可以得到復用，這個特點在功能測試和回歸測試中尤其重要;
C）測試流程自動化管理可以使機構的測試活動更加過程化，這很符合CMMI過程改進的思想。
D）投資回報率高，根據OppenheimerFunds的調查，在2001年前后的3年中，全球范圍內由于采用了測試自動化手段所實現的投資回報率高達1500%。
注：本文所論述的自動化測試主要指動態測試的自動化，不考慮軟件測試流程的自動化管理。
1，自動化軟件測試工具本身也是軟件，也要重視工具本身的質量。
自動化測試工具也是通過編寫代碼來實現的，所以也肯定存在缺陷或不符合測試需求的地方。我們在工作中經常會發生如下情形：當自動化測試工具顯示出某個測試用例的測試結果沒有通過，然后開發人員對相應部分的開發代碼進行排查，同時測試人員配合開發人員也對測試工具相應的測試代碼進行排查，最后發現沒通過的原因是在測試代碼上而并非在開發代碼上，即測試代碼本身出現了錯誤。為了提高測試代碼的質量，我們經常采用以下二種方法：
1)在書寫測試代碼前，先對相應的測試用例進行嚴格的評審工作；
2)當測試代碼書寫完畢，對測試代碼進行嚴格的以走讀的方式進行檢查。由于測試代碼相對于開發代碼比較簡單，所以走讀檢查是比較容易實施的。
雖然對測試用例評審與對測試代碼走讀都是很費時間和精力的，但這是控制測試代碼質量的最好的辦法。對測試用例的評審，測試代碼的走讀最好由專門的負責人員安排專門的場所（比如：會議室）進行，如有可能，最好請相關的人員，如：測試人員，開發人員，需求人員，市場銷售人員也在場，以便更有效地達到評審或走讀的效率。
2，自動化測試工具要隨著用戶的需求變化而變化。
在百度百科中提出，“自動化軟件測試的前提條件之一是軟件需求變動不頻繁”[1]。但是現實情況是用戶的需求經常在變化。隨著敏捷開發方法的提出，“擁抱變化”是敏捷開發所提倡的一個理念。所以我們在使用自動化工具進行測試的時候，需要注意的是：當用戶的需求發生變更，開發要及時調整產品代碼，與此同時，測試也應該及時對測試代碼進行調整。
3，不是所有的功能都可以作自動化測試的。
使用自動化測試工具的同行都會感受到自動化測試工具給我們工作帶來的便利，但是并不是所有的功能都可以通過自動化測試方式來實現的，比如UI測試，又比如James Whittaker在他《探索式軟件測試》一書中提到的超模測試。由于這些類型的測試沒有統一的標準，具有一定的主觀性。所以這種類型的測試是不適合用自動化方式來進行測試的。在測試界一直以來有句非常經典的話：“自動化測試永遠代替不了手工測試”。
4，探索式測試也可由自動化測試來實現。
“探索式測試”是測試專家Cem Kaner博士在1983年提出，并隨著近年來敏捷開發的出現，探索式測試的理論由于符合快速提交的理念，也被重新提出。但是許多人可能存在一種誤解，認為探索式測試只能通過手工測試的方法來實現，而不能采用自動化測試。然而就像我在“淺談探索式測試中用到的一些方法”一文中提到的“強迫癥測試法”，由于這種方法具有典型的機械重復性，所以對這種方法我們最好采用自動化工具來實現，這樣可以節省很多精力，并且可以帶來很好的效果。

原文轉自：http://www.anti-gravitydesign.com/ceshi/ceshijishu/zdcs/2014/0808/207435.html