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