很多人在回答為什麼要開展自動化測試時，立即回想到的答案是提高測試效率。
這種回答本身並沒有錯，但我想這只是問題的次要方面。在經過數次的自動化測試時間投入與效益比來看，
可以基本得出，基於某個場景的測試指令碼，在沒有變更與維護情況下，指令碼執行頻率大於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
那麼最後當然得出結論自動化測試更適合缺陷預防，而不是提高測試效率，希望看完這篇
文章
的同學，能夠和我悟出同樣結論與觀點，也幫助影響你的主管或身邊的同事。
適合做自動化測試的專案
自動化測試最怕的就是需求不穩定，過高的需求變更頻率會導致自動化測試用例的維護成本直線上公升。剛剛開發完成並除錯通過的用例可能因為介面變化，或者是業務流程變化，不得不重新開發除錯。所以 自動化測試更適用於需求相對穩定的軟體專案。在我看來，軟體產品比軟體專案更適合做自動化測試。首先，軟體產品的生命週期一...
什麼樣的專案適合自動化測試
雖然，在你拿到這本書時已經對要測試的專案做了一些分析和考量，但筆者還是有必要在這裡囉嗦一下不是所有專案有適合實施自動化測試的，以免讀者對專案實施自動化過程中發現困難重重，浪費了大量的人力和時間而沒有得到應有的收益。1 任務測試明確，不會頻繁變動 2 每日構建後的測試驗證 3 比較頻繁的回歸測試 4 ...
自動化測試是不是能達到90 甚至100 的覆蓋率
自動化測試是不是能達到90 的覆蓋率？簡單的說，理論上可以。實際上不可能。在網上看了不少關於測試自動化的文章，大多是 高屋建瓴 或者是互相轉述。就像寫程式，寫的越抽象的頂層父類越不容易出錯，都是指導性方向性的話，輕易是找不出什麼破綻的，也不容易被駁倒。對於自動化測試是不是能達到90 的問題想說說自己...