做了五年自動化平臺開發，根據這幾年的工作經歷，個人把自動測試分為三個階段：
   
    依賴工具階段：
   
    在這個階段，一般是剛起步階段，公司開始想做自動化，開始在選擇自動化工具階段，是采用開源的，還是商用的或者自己自主開發呢。個人建議使用開源+二次開發。原因很簡單一個是成本問題，開源意味著免費了，二是開源能拿到源碼可以讓它來適應自己的結構框架。采用商用的話，一個是成本問題，因為測試本身不是產品不能直接效益的。公司一般都希望把資金盡可能投在產品上。而是采用商用產品，可能要去適應它的框架。當然你如果你的需求是那種大眾化需求，采用商用產品是一個比較好的選擇。
   
    另外一種選擇是自主開發然后把它開源。如果在市面沒有找到合適的工具，這時候要采用自己開發了。但是為什么要開源呢。原因在于一旦開源之后，你的維護成本降低了，并且會大批具有相同需求人來不斷改進它。但是如果你打算將來當作產品來賣，那另說了。但常見的做法是公司一般會把自主開發的helper工具開源。
   
    工具有了之后，公司開始招人，學習工具的使用，開始大規模自動化了。在這時候，依靠工具本身提供的功能，產品的自動化率很大突飛猛進的變化。基本上能很快做到了30%左右的覆蓋率。
   
    走到這個時候，慢慢發現自動化腳本開發效率不高。這個時候開始對工具進行二次開發，開發一些針對自己產品的特定功能。例如實現針對產品原語開發。使開發效率從C語言時代跨越到matlab時代。
   
    另外在這個時候，腳本的量有一定的規模，這個時候會發現讓這些腳本能夠有效run起來是一個大問題。并且還不斷集成新開發的腳本。這個時候開始對腳本開發了有一定的規范。例如要求case之間要求相互獨立。每個case要自成一體。不能說一個case只能login，create動作，而沒有delete，logout等等。
   
    等你把這開發效率和case集成的問題解決了，這時候產品的自動化覆蓋率會有一個新突破，輕松能做70%以上。
   
    依賴人的階段：
   
    等自動化覆蓋率達到50%以上之后，慢慢從對工具的依賴轉移到了對人的依賴。畢竟現在還做不到腳本的自動定位問題，自動提bug. 腳本fail了，只能說明出了問題，但到底是誰出錯了（是腳本錯了，還是軟件一個真正的bug呢）。這個是還是需要人來定位了。走到這個階段了，你的自動化的case應該已經上1000了吧。每次的SUCCESS的可能性不大。假設fail 10%，這已經是一個很好的值了。也是說一次要有100個左右的case需要人來查，定位問題，重現問題。如果產品發布高一些三天發布一個版本。基本上一周會200個case需要去查，定位。如果發布頻率再高一些。要出現人機賽跑了。機器一晚上能run 1000個case沒有問題。但讓人去做100左右的case的問題定位，重現。是非常吃力了。這個時候自動化有效性取決于結果檢查人員的效率。并且這個時候自動化開始招來結果檢查人員的抱怨。并且這個時候還會出現一個現象。例如1000個case失敗了80%，也是800個case.那800 失敗的case終對應是1-2bug呢，還是對應100bug呢（不敢期望800 失敗的case對應800個bug了）。 如果是前者，可能會引起人們對自動化有效性開始懷疑。進一步可能加劇測試與開發之間矛盾。因為80%的失敗率意味著軟件質量很差，但實際結果查下來，只是一兩個小bug引起的。以后遇到問題，大家第一個問題那是不是腳本錯了。一旦這個矛頭出現了。測試與開發之間矛盾激化了。
   
    到了這個時候，測試效率瓶頸又回到人的身上。在這個時候，要開始對case本身結構進行重構了。例如抽出一些基本功能的case來做smoke test. 然后把case按照產品功能的邏輯性進行從上到下分層歸類，哪些case先run，哪些case后run.  并且盡可能優化結果檢查效率，例如建立失敗后rerun的機制，對執行過程log日志進行分類優化等等，把結果結果檢查效率給提上來。
 
這個階段，對于case本身有效性要做review了，例如是不是有測試點重復的case.刪除合并那些測試點重復的case.在這個時候大家想辦法如何減少case的數量（這個時候理想標準是case加一個太多，減一個又太少）。
   
    等把這些都做完了，產品的自動化覆蓋率基本達到85%以上了。后面15%怎么辦呢，要從客戶反饋問題中來提高了。但是能走到這一步的公司，自動化測試可以說是做的相當成功了。
   
    依賴架構的階段：
   
    走過了前面兩個階段，大家可能自動化是不是做到頭了。其實只是萬里長征的第一步了。只要軟件開發沒有停止。測試不會停止。在這時候往往會兩個方向：繼續開發新的release，還是開發新的產品。
   
    先說繼續開發的release. 新的release要開發新功能，可能要對老功能進行重構。一些接口或者邏輯變了，你的自動腳本自然也跟著改了。也是說軟件有改動，你的腳本可能要跟著改。有可能接口改變對你來說是致命的傷害。并且有的時候，一個老的版本已經賣給出去了（假設為r1.0吧，現在開發為r2.0）。客戶現場發現了bug.客戶由于各種原因又不愿意升級到新版本r2.0. 這時候你的開發要出現分枝，并行開發了。對于手工測試來說，問題不大。但拿r2.0的腳本去測r1.0分枝恐怕不行吧。估計這時候，要么使現在腳本能夠這個差異給吃掉了。要么使測試腳本也分枝。對于產品公司可以花人力去做并行開發，對于測試也花人力去并開維護腳本。這個有違當初做自動化初衷吧。軟件開發怕是需求變更。自動化測試腳本質也是軟件。只是一套軟件去測另一軟件。  如果一個構架好的軟件，具有很強擴展性，容易應對變化。反之，這個軟件慢慢會做不去了，給做死了。自動化測試也會遇到同樣的問題。
   
    現在在說開發新產品。一般大家都會選擇功能相似產品去開發，去重構以前的代碼，以實現盡可能復用。同樣測試腳本也一樣，是不是能夠復用呢。對于軟件本身大家會花費大量的人力去框架結構設計與代碼重構。對于測試腳本很少有人會花同樣人力去這樣做。并且走到時候，初做底層那批人也走的差不多，現在這個時候系統也可能變的非常龐大，重構成本非常大。如果原來的測試腳本不能方便移植復用到新的產品中。慢慢這個自動化測式也走到頭了。要么要從頭來過了。