自動化測試的7個步驟

領測軟件測試網

　　上面提到的這些原因都是基于采用 GUI 自動化測試的方法完成產品的功能測試。圖形界面接口當然需要測試，可以考慮實現 GUI 測試自動化。不過，你也應該考慮采用其他方法測試產品的核心功能，并且這些測試不會因為圖形界面發生變化而被中斷，這類測試應該采用命令行接口或者 API 接口。我曾經看到有人選擇 GUI 自動化測試，因為，他們不打算修改被測試產品，但是，最終他們認識到必須對產品做修改，以保證 GUI 測試自動化可以正常工作。無論你選擇哪種方法，自動化都需要對被測試的產品做修改。因此，采用可編程的接口是最可靠的。  

　　為了讓 API 接口測試更為容易，應該把接口與某種解釋程序，例如 Tcl 、 Perl 或者 Python 綁定在一起。這使交互式測試成為可能，并且可以縮短自動化測試的開發周期。采用 API 接口的方式，還可以實現獨立的產品模塊的單元測試自動化。  

　　一個關于隱藏可編程接口的例子是關于 InstallShield—— 非常流行的制作安裝盤的工具。 InstallShield 有命令行選項，采用這種選項可以實現非 GUI 方式的安裝盤，采用這種方式，從提前創建好的文件中讀取安裝選項。這種方式可能比采用 GUI 的安裝方式更簡單更可靠。  

　　另一個例子是關于如何避免基于 WEB 軟件的 GUI 自動化測試。采用 GUI 測試工具可以通過瀏覽器操作 WEB 界面。 WEB 瀏覽器是通過 HTTP 協議與 WEB 服務器交互的，所以直接測試 HTTP 協議更為簡單。 Perl 可以直接連接 TCP/IP 端口，完成這類的自動化測試。采用高級接口技術，譬如客戶端 JAVA 或者 ActiveX 不可能利用這種方法。但是，如果在合適的環境中采用這種方式，你將發現這種方式的自動化測試比 GUI 自動化測試更加便宜更加簡單。  

　　我曾經受雇在一家公司負責某個產品 GUI 相關的自動化測試，該產品也提供命令行接口，不過，他們已經實現了 GUI 的自動化測試。經過一段時間的研究，我發現找到圖形界面中的 BUG 并不困難，不過，用戶并不關注圖形界面，他們更喜歡使用命令行。我還發現我們還沒有針對最新的產品功能（這些功能即可通過 GUI 的方式，也可以通過命令行的方式使用）實現自動化測試。我決定推遲 GUI 自動化測試，擴展命令行測試套，測試新增的產品功能�，F在回過頭看這個決定，我沒有選擇 GUI 自動化測試是最大的成功之處，如果采用了 GUI 自動化測試所有的時間和努力都會浪費在其中。他們已經準備好做 GUI 自動化測試了，并且已經購買了一套測試工具和其他需要的東西，但我知道在開展具體的 GUI 自動化測試活動中，會遇到各種各樣的困難和障礙。  

　　無論你需要支持圖形界面接口、命令行接口還是 API 接口，如果你盡可能早的在產品設計階段提出產品的可測試性設計需求，未來的測試工作中，你很可能成功。盡可能早的啟動自動化測試項目，提出可測試性需求，會使您走向自動化測試成功之路。  

　　步驟五：具有可延續性的設計  

　　在開篇的故事中，我們看到由于自動化工程師把注意力僅僅集中在如何使自動化運轉起來，導致測試自動化達不到預期的效果。自動化測試是一個長期的過程，為了與產品新版本的功能和其他相關修改保持一致，自動化測試需要不停的維護和擴充。自動化測試設計中考慮自動化在未來的可擴充性是很關鍵的，不過，自動化測試的完整性也是很重要的。如果自動化測試程序報告測試用例執行通過，測試人員應該相信得到的結果，測試執行的實際結果也應該是通過了。其實，有很多存在問題的測試用例表面上執行通過了，實際上卻執行失敗了，并且沒有記錄任何錯誤日志，這就是失敗的自動化。這種失敗的自動化會給整個項目帶來災難性的后果，而當測試人員構建的測試自動化采用了很糟糕的設計方案或者由于后來的修改引入了錯誤，都會導致這種失敗的測試自動化。失敗的自動化通常是由于沒有關注自動化測試的性能或者沒有充分的自動化設計導致的。  

　　性能： 提高代碼的性能往往增加了代碼的復雜性，因此，會威脅到代碼的可靠性。很少有人關心如何對自動化本身加以測試。通過我對測試套性能的分析，很多測試套都是花費大量的時間等候產品的運行。因此，在不提高產品運行性能的前提下，無法更有效的提高自動化測試執行效率。我懷疑測試自動化工程師只是從計算機課程了解到應該關注軟件的性能，而并沒有實際的操作經驗。如果測試套的性能問題無法改變，那么應該考慮提高硬件的性能；測試套中經常會出現冗余，也可以考慮取出測試套中的冗余或者減少一個測試套中完成的測試任務，都是很好的辦法。  

　　便于分析： 測試自動化執行失敗后應該分析失敗的結果，這是一個棘手的問題。分析執行失敗的自動化測試結果是件困難的事情，需要從多方面著手，測試上報的告警信息是真的還是假的？是不是因為測試套中存在缺陷導致測試執行失��？是不是在搭建測試環境中出現了錯誤導致測試執行失��？是不是產品中確實存在缺陷導致測試執行失��？有幾個方法可以幫助測試執行失敗的結果分析，某些方法可以找到問題所在。通過在測試執行之前檢查常見的測試環境搭建問題，從而提高測試套的可靠性；通過改進錯誤輸出報告，從而提高測試自動化的錯誤輸出的可分析性；此外，還可以改進自動化測試框架中存在的問題。訓練測試人員如何分析測試執行失敗結果。甚至可以找到那些不可靠的、冗余的或者功能比較獨立的測試，然后安全地將之刪除。上面這些都是減少自動化測試誤報告警、提高測試可分析性的積極有效的方法。另外，有一種錯誤的測試結果分析方法，那就是采用測試結果后處理程序對測試結果自動分析和過濾，盡管也可以采用這種測試結果分析方法，不過這種方法會使自動化測試系統復雜化，更重要的是，后處理程序中的 BUG 會嚴重損害自動化測試的完整性。如果由于自動化測試本身存在的缺陷誤把產品中的正常功能視為異常，那該怎么辦？我曾經看到測試小組花費開發測試自動化兩倍的時間來修改測試腳本，并且不愿意開展培訓過程。那些僅僅關注很淺層次測試技術的測試管理者對這種方法很感興趣，他們排斥采用隱藏測試復雜度的方法。  

　　綜上所述，應該集中精力關注可以延續使用的測試套，從以下幾方面考慮，測試的可檢視性、測試的可維護性、測試的完整性、測試的獨立性、測試的可重復性。  

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 自動測試