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