自動化測試更適合缺陷預防，而不是提高測試效率

很多人在回答為什麼要開展自動化測試時，立即回想到的答案是提高測試效率。這種回答本身並沒有錯，但我想這只是問題的次要方面。在經過數次的自動化測試時間投入與效益比來看，可以基本得出，基於某個場景的測試指令碼，在沒有變更與維護情況下，指令碼執行頻率大於5-7次才基本能夠收回投入成本，產生自動化效益。基於網際網路的產品條件下，一個專案或系統如果包含 > =100個測試場景，事實遠超這個資料的N倍，其實很難能夠保證在收回自動化效益後，場景業務或資料才變更，通常變更是無法預期的或難以控制。

從技術的手段來保證：

曾經我們大膽試圖在技術上創新，嘗試如下技術攻關點：

1、能否透過手工用例，自動化生成指令碼？

2、業務物件變更自動識別，與指令碼自動化維護？

技術點1與2看起來很有挑戰，很值得做，曾經為這樣的Idea 也熱血，與冷靜思考過，並開始一步步逼近實現。但現在可以告訴大家四個字：“得不償失”，其實上面技術點的本質，是在客觀上用技術來代替現實世界中人的主觀。

對於技術1，事實上很難能夠找到通用的建模方式，來描述用例生成指令碼；

對於技術2，   自動化技術是永遠落後開發實現技術的發展，任何新的操作物件產生，必須跟進自動化識別技術，但搞自動化一幫人不可能在office意淫明天會有什麼新的物件面世。即，真正意義上的做到完全無人職守，指令碼自動生成或透過物件嗅探自動維護指令碼，幾乎是“布林什維克”主義， 或者可以說實現上述兩種技術方法，要先誕生實驗室研究或論文階段，類似於企業或像阿里巴巴，華為這樣的大的公司來說，也不會有人站出來說這樣做肯定有收益。

從流程的手段來保證：透過自動化測試體系中流程來約束變更的發現機制？如果，任何變更的源頭來自於需求或者業務，他們可以在變更時告訴軟體生命週期後期測試環節的QA工程師來維護指令碼麼？答案也是幾乎很難，所以從上述技術與流程兩個方面來看，就會涉及到測試效率提高的被動性，當然和重複生成測試資料與較穩定功能的迴歸，測試效率還是有提高的，但和剛才提到的測試效率提高的被動性來比，透過自動化測試來提高效率，其侷限性就不言而喻了。

舉例來看：

上個月釋出了功能點A，有2000個case，這個月釋出了功能點B又新增1000個case。

對於QA手工測試來講，如果沒有自動化測試介入的情況下，我們只是測試與後面1000個case相關的功能，如果時間允許的情況下，我們把頂多把A功能其中主要的500case測試一遍，就可以認為盡力測試到放心上線了，但問題恰恰出現在A功能2000減去500後的1500個case中，但如果我們用了自動化測試角度來看，但我們用了2000個case指令碼，我們只要開發功能點B又新增1000個case的指令碼，那麼我們是可以保證在釋出之前，用自動化來check 2000+ 1000=3000case的，手工測試的釋出時間，肯定要早於用了自動化測試的釋出時間，但測試的覆蓋與範圍從1500case增加到3000case

那麼最後當然得出結論自動化測試更適合缺陷預防，而不是提高測試效率，希望看完這篇文章的同學，能夠和我悟出同樣結論與觀點，也幫助影響你的主管或身邊的同事。