S.l.e!ep.￠%

我們先看三個小故事：
1. 某1整天加班為了一個自動化測試項目，所有的事情都是他自己做，他得不到一個測試工具，但是最后軟件部門給他幫助派個工程師一起工作，很多個月過去了，但是某1拒絕使用自動化測試了
2. 年輕能干的某2接管了這項工作，做自動化測試有趣嗎？然后他做了個很大的庫和復雜的測試系統，然后使用這個測試工具也能發現bug了，但是最后某2因為能力突出離開這個職位到一個開發的職位了。
3.最后某3接管了這個測試集，他費了九牛二虎之力才搞懂怎么去運行測試，但是由于項目改變讓自動化擱淺了，大部分的測試都失敗了，某3得到幫助，測試集被修復，這些測試最終都通過了，但是忽略了很多軟件問題，因此最后客戶惱怒了，項目失敗了。

從第一個故事中我們看到故事123中，所有的自動化測試項目都是一個人搞，第一個因為缺乏經驗，而不愿意使用自動化測試，第二個有熱情和能力去搞，但是他的作用沒有留下任何有意義的東西，他沒能使他的才能和智慧得到保留和傳承，第三個問題是忽略了自動化測試的目的。

所以從上面的例子來看我們必須重視：自動化測試是個團隊行為，比如我現在做的東西，我很怕會失敗，因為領導沒有給我那么多人，我的培訓還沒有時間去執行，不能傳承目前，還有我的自動化測試的很多會失敗，但是后來人如果把我的延時改動的話完全對我的腳本曲解。
所以：1.要有測試團隊， 2.要傳承,3.要保證測試的有效性，不是pass率

測試自動化不能從根本上代替測試人員，更無法保證產品的質量。那么自動化測試能做什么？產品的質量又是如何保證的？自動化測試的主要應用范圍是回歸測試，也就是說測試曾經正常的功能在產品加入新功能或者有了bug fixing以后是不是依然能夠工作。這是自動化測試的主要目的，而自動化測試的Case依然需要測試人員的智慧來編寫，所以可以說自動化測試只是一個輔助性的工具。當然，在某些軟件的壓力測試上也需要自動化測試工具。產品質量其實在設計之間就已經被決定了，這其中的決定因素就是團隊本身的素質和團隊成員在這個具體項目上的經驗。測試只能幫助一個設計良好的產品不會因為小的bug而大幅度的降低可用性，而無法挽救一個設計就很差的產品成為優秀的產品。

并不是所有的測試都能用或者必須用自動化測試，有時候自動化測試會吃力不討好的,我們要評估某些測試的頻度，和自動化測試的不足，然后人工測試的case要彌補這些不足，比如哦某些測試頻度很少，case又多，難于開發這樣就不用去做自動化測試，因為維護需要很多工作量，項目不斷的前行，特別是以GUI操作的測試工具來說尤為是這樣。任何一處改變都會帶來很多case失敗。

每個人、每個工具談論自動化的時候都在說如何真實模擬用戶使用產品的情況，這很好，絕對需要關心。不過我得問一句：測試的最后結果是什么？如果你回答“各種使用產品的場景已經運行過“就嘎然而止的話，你就漏掉了一大塊：最起碼還得加上“產品能工作/不能工作“！所以模擬用戶使用產品的各種情況，只是解決上述問題的第一部分；如何得出測試通過/不通過的最終結論，才是解決問題第二部分的基礎部分，還有詳細缺陷描述、上下文數據收集等沒做到呢！

所以讓機器像人一樣使用產品，并沒有解決全部問題，剩下的事情還有多少，這是需要視情況而定的。如果只是解決了第一個問題就認為萬事大吉，那簡直就是在賭運氣——有些時候自動驗證是小菜一碟，但很多時候不是。
令事情惡化的是，自動驗證了產品的一些指標，并不能反映產品的真實質量。有時驗證過的指標通過了，其實其他地方暴露了問題卻沒有檢查

自動化測試需要規劃和管理不能亂了章法，比如幾個版本后需要改動的話代價有多少（別有嘩嘩的跑了很多人），投入產出比是多少，我們要看到效果，測試有效性有多高，過程可控嗎？回答了這些問題其實就把自動化測試項目管理搞懂一部分了。

不要津津樂道于某個版本的輝煌，適應新的軟件才是有價值的：
要了解啥能用上，啥用不上，它是做什么的是否能為我所用，找些零件對付一個新的老爺車，別中途散了架，舊的不是不能用，要關注測試有效性，別走上了我們的故事3中的后果！切記！