鑒于項目組以及整個Team的自動化測試現狀，我在我們Team內部的一次Share會議上分享了我對于有效自動化測試策略的一些看法，可能觀點相較于其他同事，比較極端，但是我的初衷其實是想給大家敲個警鐘，不要小欲則安，淺嘗輒止，我們應該保持對自動化，敏捷，以及持續集成的不斷追求，在保證質量的同時提高效率。
因此對于什么樣的自動化測試才是有效的，我強調首先第一點，我們要確保我們的自動化case對我們的項目有用
相信這一點，絕大多數人都是認同的，但是我這里把它又拎出來是因為，知道是一回事，但是有沒有照著做又是另外一回事。要說做自動化，大家都做，都愿意做，但是我們做的真正對我們的項目有用嘛？下面是我羅列的三條標準：
● 要確信你的自動化case是有價值的，可以代替你的手動測試
自動化測試，尤其是功能性，基于User Story的case，多數是對手動case的Cover，也就是說代替手動case的。所以說我們必須確信我們的case是有價值的，可以代替我們去執行相應的手動case。至于什么是有價值的自動化case，我們相信應該是這樣的：在一定的環境中執行過了自動化case，我們就相信，在這個環境中，我們沒必要再進行同樣的手動操作。
至于如何寫出有價值的case，當然也有其策略和方法，這里不再提及。
● 在測試環境中的執行才更有價值的
上條說道，在一定的環境中去執行case，那這個一定的環境是什么樣的環境呢？這里我的觀點可能比較極端，我認為寫case的環境，是我們的開發環境，并不是我們理想中的測試環境。
那什么才是測試環境呢？答案就是，我們自己定義的，并且專門用于測試的環境。這個環境的所有情形都是Expected，或者是可枚舉的。比如說裝什么系統，裝什么相關軟件，如何跑我們的case，這都應該是定義好的。這樣的環境才是測試環境。
也許有人會對我這里定義的測試環境持反對意見，認為這樣的環境并不是用戶真實使用的環境，我們應該在更復雜的環境中去執行自動化測試，以期找到更多的bug。但是我認為自動化測試的目的就是做Regression Testing，以期有效的功能測試和版本控制。自動化測試并不能代替手動case，它應該是一個增量式的過程，我們不要期望讓自動化發現更多的bug，而應該不斷的添加，豐富各種自動化case，以及Bug Verification，以解放測試人員，讓其更關注于測試本身。
● 能持續集成的運行了，才算我們的自動化測試跑起來了
這條算是錦上添花型的，持續集成是業界非常好的經驗總結，不光適用于我們測試，實際上她應該是適用于整個項目的。要想做到持續集成我們有很多的開源工具可以選擇，這條是大力提倡的。
第二點，我們要擁抱任何有意義的變化
這一點非常重要，這個是觀念上的轉變。很多時候，公司，領導花了大價錢，大精力，來讓我們做自動化，而且我們也通過現有的，或者是買來的工具，也確實做了自動化。但是更多時候總會因為這樣或者那樣的原因，啥項目周期短啊，需求總是變動啊，導致我們的case這條掛了，那條跑不起來了，修了再修，最后測試人員也煩了，自然的，自動化case最終也束之高閣，日久生塵。
但是這里我仍然強調，我們要擁抱任何有意義的變化，這是觀念上的轉變。為了做出更好的產品，需求在變，代碼也跟著變，我們的case在變，自動化case又有何理由不變呢？如果因為需求的變動導致我們自動化case掛了，我們應該高興才是，因為我們的case成功的偵測到了這個變動，它是有價值的。換句話說，如果需求都變了，而我們的case還跑的好好的，那我可就要懷疑你的case到底有沒有價值嘍？！
擁抱任何有意義的變動，不是說創建穩定性好的自動化case就沒有意義了。試想如果因為一個蟻穴，就導致我們的自動化大堤全線崩潰，那自動化的工作量可就如山高，如海深嘍，那又談何敏捷呢？！
第三點，至于如何做自動化，我想說，Just Coding！
雖然測試自動化可能并不如開發那么高深，但是我覺得我們不要自己潛意識當中就把自己限制的死死的，“我就是個測試，我肯定不如開發”，這樣的觀點是不對的。尤其現在公司推行的Scrum模式，其理想狀態是不分DEV和QA的，大家都是敏捷模式的一員，工作甚至也是可以互相交換的。
當然，現階段無可否認，DEV的開發水平會更高一些，但是對于我們QA，尤其是做開源領域比如Android的測試，做自動化的終極解決方案其實就是閱讀產品代碼，當我們讀懂了開發代碼，那寫測試case就不是問題了。
Conclusion
所以我最終的的建議就是：Just Coding，Just Do It！只有真正去做了，你才會發現問題，才會想到去解決問題，才會想到要總結一些方法，然后讓我們的Case在測試環境中自由的跑起來！