維基百科

自動化測試

在軟體測試中，自動化測試指的是使用獨立於待測軟體的其他軟體來自動執行測試、比較實際結果與預期並生成測試報告這一過程。[1] 在測試流程已經確定後，測試自動化可以自動執行的一些重複但必要測試工作。也可以完成手動測試幾乎不可能完成的測試[2]。對於持續交付和持續集成的開發方式而言，測試自動化是至關重要的。

隨著軟體系統規模的日益擴大，以及應用領域的不斷拓展，對軟體系統的測試也變得更加困難和複雜，傳統的人工測試的局限性也越來越明顯。自動化軟體測試技術可以克服傳統測試技術的許多問題。自動化測試所依據的是一套嚴密的測試法則和評估標準，具有完整的自動測試過程。因此，它可以避免測試人員慣性思維所導致的測試疏漏，也可減少由於手工測試中繁複的重複工作所導致的人為差錯。[3]

概述

編輯

自動化測試的意義和優點

編輯

自動化測試（尤其是單元測試的自動化），是極限編程和敏捷軟體開發的一個關鍵特徵，這也被稱為測試驅動開發（TDD）。單元測試的用例可以在代碼編寫完成之前就設計好，並作為功能的一種定義形式存在。隨著新的代碼不斷完成編寫，單元測試隨之進行，缺陷被不斷找出，因而代碼也不斷得到改進。[4] 由於開發人員能夠及時發現缺陷然後立即作出改變，修復的代價大大減小，這種不斷發展的開發方式被認為比瀑布模型這類開發結束再測試的方式更為可靠。

使用單元測試框架（如JUnit、NUnit等「xUnit（英語：xUnit）」類型測試框架）執行自動化測試是目前軟體開發行業的大趨勢。單元測試框架的應用使得各部分代碼開發完成後立即進行相關單元測試來驗證它們是否如預期在運行成為可能。

手工完成一些軟體測試的工作(例如大量的低級接口的回歸測試)十分艱苦耗時，而且尋找某些種類的缺陷時效率並不高，因而測試自動化，提供一種完成這類工作的有效方法。

一旦自動化測試方法開發完成，日後的測試工作將可以高效循環完成。很多時候這是針對軟體產品進行長期回歸測試的高效方法。畢竟，早期一個微小的補丁中引入的回歸問題可能在日後導致巨大的損失。

自動化測試的局限性

編輯

儘管長期來看（尤其是針對回歸問題的）自動化測試，可以帶來開支上的節省，將所有測試短期內全部自動化還是可能產生巨大的開銷[2]，通常情況下業內採用手工測試和自動化測試相結合的方法完成測試工作。

儘管測試「自動化」了，但測試結果分析、測試腳本維護和編寫仍然需要人力投入。

自動化測試的要求

編輯

對於測試用例的要求

編輯

需要被自動化的測試用例大多是待測產品中每次修改代碼都需要進行回歸測試的重要部分。對這樣的部分採取自動化測試手段後能大大減小手工測試消耗的人力物力[5]。

對於測試人員的要求

編輯

由於在自動化測試中的測試用例和輸出結果都由代碼構成，測試工程師（或軟體質量保證人員）必須具備軟體編碼的能力。不過某些測試自動化工具支持通過關鍵詞指定測試步驟，因而免除了程序編寫的過程，對測試人員而言也就不再要求他們掌握編程技術了。

對於團隊的要求

編輯

自動化測什麼，什麼時候可以自動化，團隊是否真的需要自動化——這三個問題是一個測試（或開發）團隊必須做出的關鍵決斷。[6]來自52名從業者和26名學者的研究與評論中共同指出測試自動化應考慮五個關鍵因素：

被測系統、測試的數量和種類、測試的工具、人和組織的工作重心、交叉因素（英語：cross-cutting concern）。

在上述研究中最常提及的獨立因素是：

回歸測試的必要性、經濟因素、被測系統成熟度。[7]

自動化測試的分類

編輯

測試自動化有許多途徑，下面列出一些廣泛應用的一般方法：

  • 基於圖形用戶交互界面測試（英語：Graphical_user_interface_testing）（GUI Based Testing）。基於用戶界面（GUI）的測試使用能夠產生圖形用戶界面操作（如出表點擊、鍵盤輸入等）的測試框架，模擬用戶動作來以觀察、驗證程序是否正確的響應[8]。
  • 接口測試（又稱基於API的測試，API Based Testing）。接口測試指的是通過調用接口（API）繞過GUI，，以應用到驗證的行為進行測試。通常API動繞過測試的應用程式的用戶界面。它也可以測試公共的接口，以類、模塊或圖書館都經過測試，有各種各樣的輸入參數來驗證返回的結果是正確的。

接口測試

編輯
主條目：接口測試

接口測試是被廣泛使用的軟體測試方法之一，它使軟體測試工程師能夠忽略GUI的影響，對軟體功能本身進行測試。它是程序邏輯測試中非常關鍵的一步[9]。通常情況下在開發的早期階段，接口測試就會開始執行來確保代碼始終是準確無誤的。

接口測試也作為集成測試的一部分，用於判斷系統是否滿足功能、可靠性、性能表現和安全性的要求。[10] 由於接口測試不使用GUI，它主要通過字符方式與測試者進行交互。[11]

圖形用戶界面(GUI)測試

編輯

許多測試自動化工具提供記錄與回放巨集的功能，這允許用戶記錄他們在交互式用戶界面上進行的滑鼠點擊、鍵盤輸入等操作。這樣在之後的測試當中，播放巨集便可以自動測試這些交互，與正常情況下的交互反饋進行對比便可完成針對GUI的測試工作。這種方法幾乎不要求用戶具有軟體開發經驗，並且可以應用於幾乎任何具有GUI的應用程式。然而，這些特點也帶來了一些可靠性和維護性問題：任何按鈕的重命名或是移動都會讓巨集出現錯誤，用戶便需要重新錄製巨集。

這類工具有一種用於測試網站的變種，其「界面」不是應用程式而是網頁，由於網頁依賴HTML渲染器展示用戶界面，因此這類變種不再關注操作本身，而是代為渲染HTML並監聽DOM事件來完成巨集的記錄與回放。在這裡，"接口"的網頁。然而，這一框架利用了完全不同的技術，因為它是渲染HTML並聽事件，而不是作業系統的活動。無頭瀏覽器（一種沒有用戶界面的瀏覽器，專用於網頁功能性測試）或Selenium Web Driver（英語：Selenium Web Driver）通常用於網站的測試工作。[12][13][14]

持續測試

編輯

持續測試（英語：Continuous testing）指的是在軟體開發過程中自動對即將發布的軟體版本，通過軟體輸送管道，自動的執行測試並給出即時反饋，依次降低軟體缺陷帶來的業務風險。[15][16]

自動化測試框架

編輯

測試自動化框架是一個為特定產品設置一系列特定自動化規則執行測試的集成系統。這套系統的整合（測試用的）函數庫、測試數據集、對象細節（元數據）和各種可重用模塊。將這些模塊按照測試需求組合起來便可以得到一個完整的，針對特定功能或應用場景的測試用例。測試框架為自動化測試提供基礎，並簡化了自動化測試的工作流程。

幾種常用的框架/腳本模式

編輯
  1. 線性測試（尤其是測試工具自動生成的巨集類腳本）
  2. 結構化測試（使用控制分支結構，如：if-else、switch、for、while等）
  3. 數據驅動測試
  4. 關鍵字驅動測試
  5. 基於模型的測試
  6. 代碼驅動的測試
  7. 行為驅動開發
  8. 混合模式（混合使用多種模式）
  9. 敏捷開發自動化測試框架

測試框架的功能[17]

編輯
  1. 定義軟體預期的表現（定義正確輸出）
  2. 針對待測試程序的生命周期創建運行鉤子，或直接驅動待測程序
  3. 執行測試
  4. 報告結果

自動化測試接口

編輯

自動化測試接口是自動化測試框架中，為不同測試工具提供統一工作空間（英語：workspace）的平台。其目標是儘可能減少將業務指標映射成測試步驟這一過程中產生的代碼量。自動化測試接口被設計用於改善測試腳本的維護效率和靈活性。[18]

 
自動化測試框架的接口模型

自動化測試接口包括以下核心模塊：

  • 接口引擎
  • 接口環境
  • 對象庫

接口引擎

編輯

接口引擎建立在接口環境之上，包括一個語法分析器和一個測試運行程序。

語法分析器用於將來自對象庫的文件解析成測試腳本語言可用的形式，之後由測試運行程序執行。[18]

對象庫

編輯

對象庫是使用測試工具，針對待測UI或應用程式創建的全部測試數據、宏對象的集合。[18]

自動化框架和測試工具的區別

編輯

測試工具是專門針對一些特殊應用場景設計的，它們在自動化測試過程中完成一部份工作。自動化框架則不執行特定任務，而作為基礎設施，為不同工具提供統一平台，並讓它們工作在同一個模式下，以便自動化測試工程師開展工作[19]。

有許多不同種類的框架，會依照測試或開發的架構來進行分類，有以下這些分類：

  1. 資料驅動測試
  2. 模組驅動測試（英語：Modularity-driven testing）
  3. 關鍵字驅動測試
  4. 混合測試（英語：Hybrid testing）
  5. 基於模型的測試
  6. 程式驅動測試
  7. 行為驅動開發

自動化測試在行業中的現狀

編輯

根據Practitest組織2018年收集，來自80多個國家的QA專業人士提供，約1,500份回復報告統計顯示，高達76%的受訪者執行自動化測試或負責編寫自動化測試腳本[20]。有85.5%的受訪企業採用了各類自動化測試方法，其中75%的企業利用自動化測試方法執行回歸測試，43%的企業將自動化測試和持續集成、持續開發方法結合使用，有3%的公司甚至將90%的測試工作自動化[20]進行。

就薪資水平看，有著一到兩年工作經歷的測試工程師在西方國家能夠拿到40k左右的年薪。具備自動化能力的工程師的年薪普遍更高。

另見

編輯

參考文獻

編輯
  1. ^ Kolawa, Adam; Huizinga, Dorota. Automated Defect Prevention: Best Practices in Software Management. Wiley-IEEE Computer Society Press. 2007: 74. ISBN 978-0-470-04212-0. 
  2. ^ 2.0 2.1 徐進. 自动化软件测试的分析. 《信息技術》: 152-155頁. 
  3. ^ 金虎. 自动化软件测试技术研究. 《四川大學》. 
  4. ^ Learning Test-Driven Development by Counting Lines; Bas Vodde & Lasse Koskela; IEEE Software Vol. 24, Issue 3, 2007
  5. ^ 李剛毅， 金蓓弘. 自动化回归测试的技术和实现 (pdf). 計算機應用研究. 2006. （原始內容存檔 (PDF)於2019-07-19）. 
  6. ^ Brian Marick. When Should a Test Be Automated?. StickyMinds.com. [2009-08-20]. （原始內容存檔於2013-07-30）. 
  7. ^ Garousi, Vahid; Mäntylä, Mika V. When and what to automate in software testing? A multi-vocal literature review. Information and Software Technology. 2016-08-01, 76: 92–117. doi:10.1016/j.infsof.2016.04.015. 
  8. ^ 李濤. 图形用户界面GUI的自动测试工具的研究. 四川大學碩士學位論文. 2005. 
  9. ^ Produce Better Software by Using a Layered Testing Strategy （頁面存檔備份，存於網際網路檔案館）, by Sean Kenefick, Gartner January 7, 2014
  10. ^ Testing APIs protects applications and reputations （頁面存檔備份，存於網際網路檔案館）, by Amy Reichert, SearchSoftwareQuality March 2015
  11. ^ All About API Testing: An Interview with Jonathan Cooper （頁面存檔備份，存於網際網路檔案館）, by Cameron Philipp-Edmonds, Stickyminds August 19, 2014
  12. ^ Headless Testing with Browsers; https://docs.travis-ci.com/user/gui-and-headless-browsers/ （頁面存檔備份，存於網際網路檔案館）
  13. ^ Headless Testing with PhantomJS;http://phantomjs.org/headless-testing.html （頁面存檔備份，存於網際網路檔案館）
  14. ^ Automated User Interface Testing; https://www.devbridge.com/articles/automated-user-interface-testing/ （頁面存檔備份，存於網際網路檔案館）
  15. ^ Part of the Pipeline: Why Continuous Testing Is Essential （頁面存檔備份，存於網際網路檔案館）, by Adam Auerbach, TechWell Insights August 2015
  16. ^ The Relationship between Risk and Continuous Testing: An Interview with Wayne Ariola （頁面存檔備份，存於網際網路檔案館）, by Cameron Philipp-Edmonds, Stickyminds December 2015
  17. ^ Selenium Meet-Up 4/20/2010 Elisabeth Hendrickson on Robot Framework 1of2. [2010-09-26]. （原始內容存檔於2020-06-18）. 
  18. ^ 18.0 18.1 18.2 Conquest: Interface for Test Automation Design (PDF). [2011-12-11]. （原始內容 (PDF)存檔於2012-04-26）. 
  19. ^ 小聊自动化测试工具和框架 - 51Testing软件测试网. www.51testing.com. [2019-07-19]. （原始內容存檔於2019-07-19）. 
  20. ^ 20.0 20.1 practitest.com. 2018 state of testing report (PDF): 10, 21, 22. 2018 [2019-07-17]. （原始內容存檔 (PDF)於2021-02-25）. 

注釋

編輯
  • Elfriede Dustin; et al. Automated Software Testing. Addison Wesley. 1999. ISBN 978-0-201-43287-9. 
  • Elfriede Dustin; et al. Implementing Automated Software Testing. Addison Wesley. 2009. ISBN 978-0-321-58051-1. 
  • Mark Fewster & Dorothy Graham. Software Test Automation. ACM Press/Addison-Wesley. 1999. ISBN 978-0-201-33140-0. 
  • Roman Savenkov: How to Become a Software Tester. Roman Savenkov Consulting, 2008, ISBN 978-0-615-23372-7
  • Hong Zhu; et al. AST '08: Proceedings of the 3rd International Workshop on Automation of Software Test. ACM Press. 2008 [2019-07-17]. ISBN 978-1-60558-030-2. （原始內容存檔於2020-02-19）. 
  • Mosley, Daniel J.; Posey, Bruce. Just Enough Software Test Automation. 2002. ISBN 978-0130084682. 
  • Hayes, Linda G., "Automated Testing Handbook", Software Testing Institute, 2nd Edition, March 2004
  • Kaner, Cem, "Architectures of Test Automation （頁面存檔備份，存於網際網路檔案館）", August 2000

外部連結

編輯
取自「https://zh.wikipedia.org/w/index.php?title=自动化测试&oldid=80039395」