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