自動化測試總結

最近要在新入職的公司準備一份自動化測試的培訓，這是我在得知要作自動化測試培訓之後，隨手畫了個圖，壓壓驚：

這是我能想到的關於自動化測試的一些要點，而後根據一篇我三年前寫的關於自動化測試的隨筆更新了一下，固然遺憾的是到目前爲止，我接觸的成功的敏捷開發項目還不多，雖然敏捷近些年一直很火。關於敏捷自動化測試這一塊也只有一次不太成功的經驗，因此本文中我回避了這一塊：

1.什麼是自動化測試

以程序測試程序，以代碼代替思惟，以腳本的運行代替手工測試。自動化的測試涵蓋了：功能（黑盒）自動化測試，功能（白盒）自動化測試，性能測試，壓力測試，GUI（Graphical User Interface）測試，安全性測試等。

【Updated on 7/28/2015】

關於什麼是自動化，查閱了一些資料，並無一份權威規範的解釋，如下摘自維基百科：

In software testing, test automation is the use of special software (separate from the software being tested) to control the execution of tests and the comparison of actual outcomes with predicted outcomes.Test automation can automate some repetitive but necessary tasks in a formalized testing process already in place, or add additional testing that would be difficult to perform manually.

首先，test automation跟 automation test是有區別的，測試自動化涵蓋的面更普遍。本文闡述的是自動化測試，在這裏暫且混淆這兩個概念。

這一段英文不難，自行翻譯。我眼裏看到的幾個要點：1.須要工具；2.工具控制流程，比較預期輸出與實際輸出；3.重複性高且有必要的測試流程能夠自動化；4.用於手工測試難以達成的領域

說說我本身的理解：

自動化測試是測試思想的一個延伸，爲測試工程師提供了一個「觸鬚」，其行爲能夠當作一個工具，可是本質上自動化測試仍是一種思想。

順便提一句，狹義上的自動化測試指的就是基於GUI的自動化測試，而單元測試跟API測試，你有想過怎麼用手工不借助任何工具去作嗎？因此它們天生就屬於測試自動化的範疇。

 

2.自動化測試的優點

迴歸測試更方即可靠 ；可運行更多，更繁瑣的測試，且快速高效；可執行一些手工測試執行至關困難或者作不到的測試，如大量的用戶併發；更好的利用資源，具備一致性和可重複性的特色，自動化測試腳本徹底可複用；提高了軟件的可信度；多環境下測試等。

【Updated on 7/28/2015】

自動化最實在的優點在於——工做好找：有一個測試工程師（並非本人）發現一個有趣的現象，她申請過的幾乎全部測試職位，在招聘時都須要自動化測試經驗。但當她開始工做後，就發現這些公司都試圖作自動化測試，可是結果大多不怎麼地。不過，儘管她參與的都是一些杯具的項目，不過她總能把這些杯具包裝成洗具以應對下一次面試。

因此呢，既然自動化測試有那麼多優點，爲何還有那麼多項目作失敗了呢？

我我的有個推論：自動化測試的優點都是自動化測試成功完成獲得的結論，而自動化測試的劣勢纔是自動化項目立項的基礎。

還有個優點：自動化測試能夠將產品的知識固化到腳本中，以下降測試人員流動對項目形成的影響。可是這個優點的前提是，這些腳本易於維護，這就須要一些必要的文檔，這又是另外一個議題了。

 

3.自動化測試沒法作到的事以及劣勢

永遠不可能徹底替代手工測試，自動化測試沒法作到手工測試的覆蓋率，不是每一個測試用例都適合作成自動化，如建議一個頁面的佈局是否正確、安裝測試、文檔測試、兼容性測試、恢復性測試。

手工測試發現的缺陷遠比自動化多。自動化測試是幾乎沒法發現新缺陷的，最大的用途是用來回歸，確保曾經的bug沒有在新的版本上從新出現。

自動化測試工具是死的，它不具有任何想象力。自動化測試的好壞，徹底取決於測試工程師。

成本投入高，風險大。對測試人員的技術要求高，對測試工具一樣有要求。

【Updated on 7/28/2015】

關於成本，包括了資金預算，人力資源，人員培訓，硬件資源等。下圖顯示了自動化測試的投入成本與時間的關係，很顯然，前面多數時間，成本是很高的。

基於以上劣勢，因此雖然「貴爲」自動化測試工程師，我有一大半的時間在勸老闆，「親，能不能不作自動化」。這真是個悲傷的故事。

 

4.合適引入自動化

項目週期長，系統版本不斷，而且需求不會頻繁變動，此時是適合引入自動化測試的。

系統的測試對象基本能夠正常識別，以及對沒法識別的控件可否提供一個解決方案。

系統中不存在大量的不可識別第三方控件。

須要反覆測試，如可靠性測試、迴歸測試等須要進行上千次的系統測試。

 

5.不適合自動化

項目週期短，需求頻繁變動。即便是週期長的項目，若是常常需求變動，也不適合作自動化。

軟件版本尚未穩定的狀況下，主功能或大量功能有被從新更改的可能話，也不適合作自動化。

沒有明確的項目測試自動化計劃，措施和管理。

多數對象沒法識別，以及腳本維護頻繁與艱難，兩者有其一，自動化一定失敗。

 

6.自動化測試的流程【Updated on 7/28/2015】

合理的自動化切入點：一般，項目只有經歷了完整的系統測試以後纔算具有了基本的引入測試自動化的條件。

【Updated on 7/28/2015】

我的觀點：不管什麼測試，越早介入則越有利於下降成本，下降風險。而隨着新型的開發模式興起，自動化測試也具有了儘早介入的條件。好比敏捷開發中，某核心模塊核心功能完成後，則可針對該模塊的該功能開始實施自動化測試。

 

測試自動化分析：

（1）可行性分析

（2）抽樣demo分析,demo通常選取冒煙測試用例，檢查腳本是否可以成功運行經過，已設計的測試點是否所有執行

（3）測試需求分析，分析哪些功能點準備進行自動化

【Updated on 7/28/2015】

（1）可行性分析是自動化測試最重要的部分之一。可行性分析是自動化測試最重要的部分之一。可行性分析是自動化測試最重要的部分之一。重要的話要講三遍。

　　  關於可行性分析，請參考2,3,4,5點；你的一個錯誤決定（自動化測試項目立項），極可能給好幾我的帶來全職工做機會，從這個角度來說，還能促進雞的屁==

（2）抽菸Demo，主要仍是用來驗證你的工具是否能用

（3）自動化測試不是100%測試，不可能達到手工測試的覆蓋率，要篩選功能點進行自動化測試

 

測試計劃定製：自動化測試計劃越全面，後期越能循規蹈矩的去實施，自動化測試的成功率越高

計劃趕不上變化，有時候太全面了或許也不是什麼好事。

自動化測試設計階段：主要分爲自動化測試框架和自動化測試用例。

（1）自動化測試框架的設計，開發與搭建：應能保證測試的分佈執行，腳本模塊化，數據驅動，日誌分析，錯誤截圖，報表回收，共享對象庫，公共函數庫，環境配置，統一設計模式，異常處理，場景恢復的一個無人值守的，針對每一個獨立項目的測試框架

【Updated on 7/29/2015】

關於爲何須要自動化測試框架，我有另一篇文章詳細說明了，這裏再也不復述

http://www.cnblogs.com/ryansunyu/p/4080985.html

而後我順便說說找對象的事，是自動化測試框架找對象，不是我找對象：）

一般每種框架都應該支持動態跟靜態兩種找對象的方式，靜態找就涉及到對象庫，包括對象庫的讀、寫、合併、維護等一系列問題，這些均可以交給框架作；

關於動態查找，我舉個RFT的例子，大家意會一下：

Two types of find API in Rational Functional Tester:

• find(Subitem Properties).
• find(Subitem Properties, Boolean mappableOnly).

       Subitems can be either atChild() or atDescendant() or atList().

• atChild: One or more properties that must be matched against the direct child of the starting TestObject.
• atDescendant: One or more properties that can be matched against any child of the starting TestObject
• atList: A sequential list of properties to match against. Valid subitems for atList are atChild, atDescendant, and atProperty.
• mappableOnly: Arguments that limit the search. If it is set to true, the search for children will be limited to those test objects that are mappable, otherwise non-mappable test objects are also searched.

 

 

首先測試工具會提供動態查找的接口或者方法，RFT裏面提供的是find方法，調用這些接口或者方法便可實現動態查找。

動態查找的好處是能夠採用「相對路徑」來定位對象，而相對的，對象庫則採用的是「絕對路徑」。若是一旦對象的一些屬性改變，靜態查找的方式可能會找不到對象，固然了，如今的自動化測試愈來愈智能，已經能夠作到選取匹配度最高的對象返回。動態查找還有個好處是它找到的對象是「代碼」，你能夠進一步在框架裏去對這些對象進行處理，而對象庫裏的每個對象都是一個獨立的對象，你可使用它們，可是很難改變它們。

一般如今的自動化測試框架都是採用動靜結合的方式，即兩種找對象的方式都會兼顧，由於通常來講，靜態查找的方式速度更快，效率更高。可是靜態查找帶來的問題也是顯著的，主要集中在對象的維護管理以及合併上，如何共享對象，避免重複加對象等。此時，規範對象命名就顯得很重要了。以往我作的自動化測試項目中，這些都是坑。

 

（2）自動化測試用例設計三部曲：手工測試用例是從無到有，而後自動化測試用例是根據手工測試用例來寫的。首先，篩選手工測試用例。而後轉換手工測試用例，最後新增&補充自動化測試用例。

爲何不能用手工測試用例徹底替代自動化測試用例？

自動化測試用例的範圍每每是核心業務流程或者重複執行率高的，自動化測試的覆蓋率不能達到手工測試的覆蓋率。自動化測試的用例選擇通常以正向爲主，而反向的狀況卻有不少，可是並非全部反向狀況自動化測試都會涵蓋，而是有篩選的選取一部分。也並非全部的手工測試用例均可以用來作自動化的，如頁面佈局的檢查。手工測試能夠不須要回原點，可是自動化測試每每是必須的。自動化測試用例與手工測試用例不一樣，不須要每一個步驟都寫預期結果。

【Updated on 7/29/2015】

一般作自動化測試的時候我都會寫一個叫作shake-down test的測試用例，這個用例會把系統裏全部完成了的表單都過一遍，只是作一個Navigate的操做，以確保某個頁面是否可用。

每次作迴歸測試前，能夠先跑一遍shake-down test，很快能夠肯定哪些功能是accessible，至關於作了一整個系統的一個冒煙測試。

測試腳本設計與開發：

測試腳本大體可劃分爲：

（1）線性腳本：經過錄制直接產生的線性可執行的腳本

（2）結構化腳本：具備順序，循環，分支等結構的腳本

（3）可共享腳本：能夠被多個測試用例使用，被其餘腳本調用的腳本（即模塊化的腳本）

（4）數據驅動腳本：測試數據跟業務流程控制分離的腳本，經過讀入數據文件來驅動流程進行的腳本

（5）關鍵字驅動腳本：腳本，數據，業務分離，數據和關鍵字在不一樣的數據表中，經過關鍵字來驅動測試業務邏輯。關鍵字驅動的特色是，它更像是描述一個測試用例在作什麼，而不是如何作。

（6）混合型腳本：以上任意兩種及以上

（7）敏捷自動化測試腳本/框架：這一塊等我有了成功經驗再補充=。=

自動化測試執行：

（1）無人值守的測試：環境搭建，部署與配置；自動化測試用例與測試腳本相互綁定；自動化測試用例執行順序排列與組合

（2）異常處理與場景恢復

提交自動化測試產物：大體須要提交執行狀況，測試結果，分析報表，測試報告，質量狀況等。

測試腳本維護：嚴格來說，每一個階段都在作測試腳本維護。一個不值得維護的自動化測試項目是不值得立項的。（一般這裏有不少全職工做機會~LOL）