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

不少人在回答爲何要開展自動化測試時，當即回想到的答案是提升測試效率。

　　這種回答自己並無錯，但我想這只是問題的次要方面。在通過數次的自動化測試時間投入與效益比來看，

　　能夠基本得出，基於某個場景的測試腳本，在沒有變動與維護狀況下，腳本執行頻率大於5-7次才基本可以收回

　　投入成本，產生自動化效益。基於互聯網的產品條件下，一個項目或系統若是包含 > =100個測試場景，事實遠超這個數據的N倍，其實很難可以保證在收回自動化效益後，場景業務或數據才變動，一般變動是沒法預期的或難以控制。

　　從技術的手段來保證：

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

　　一、可否經過手工用例，自動化生成腳本？

　　二、業務對象變動自動識別，與腳本自動化維護？

　　技術點1與2看起來頗有挑戰，很值得作，曾經爲這樣的Idea 也熱血，與冷靜思考過，並開始一步步逼近實現。

　　但如今能夠告訴你們四個字：「得不償失」，其實上面技術點的本質，是在客觀上用技術來代替現實世界中人的主觀。

　　對於技術1，事實上很難可以找到通用的建模方式，來描述用例生成腳本；

　　對於技術2，   自動化技術是永遠落後開發實現技術的發展，任何新的操做對象產生，必須跟進自動化識別技術，但搞自動化一幫人不可能在office意淫明天會有什麼新的對象面世。即，真正意義上的作到徹底無人職守，腳本自動生成或經過對象嗅探自動維護腳本，幾乎是「布爾什維克」主義， 或者能夠說實現上述兩種技術方法，要先誕生實驗室研究或論文階段，相似於企業或像阿里巴巴，華爲這樣的大的公司來講，也不會有人站出來講這樣作確定有收益。不過，仍是能夠參照個人發明專利《http://www.ilib2.com/A-%E7%94%B3%E8%AF%B7%E5%8F%B7~CN200810007645.2.html》，來比較標準與歷史對象來發現變動。

　　從流程的手段來保證：經過自動化測試體系中流程來約束變動的發現機制？若是，任何變動的源頭來自於需求，

　　或者業務，他們能夠在變動時告訴軟件生命週期後期測試環節的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

　　那麼最後固然得出結論自動化測試更適合缺陷預防，而不是提升測試效率，但願看完這篇文章的同窗，可以和我悟出一樣結論與觀點，也幫助影響你的主管或身邊的同事。