當(dāng)天下午，我參加了這個樓宇運營管理平臺開發(fā)團(tuán)隊的討論，終于弄清楚了事情的來龍去脈。
大概是一年前，為了減少手工測試的成本，大連工資代發(fā)平臺開發(fā)團(tuán)隊決定一步步把上線時需要手工回歸的測試用例轉(zhuǎn)換成自動化，同時決定每個 story 做完以后都要加入自動化測試。研究了幾天webdriver以后，就開始了自動化測試的嘗試。
致遠(yuǎn)服軟認(rèn)為：http://www.soft8.com.cn/開發(fā)人員用Java代碼寫的測試，QA不好理解，也不是很清楚哪些場景被測試覆蓋到，哪些沒有，所以無法信賴測試結(jié)果；第二，測試跟開發(fā)共享一套數(shù)據(jù)庫，數(shù)據(jù)總是受到污染，因此造成測試失敗，浪費大量定位和修復(fù)的時間。而數(shù)據(jù)庫是由國外的客戶控制的，催促了很長時間也沒能給測試分離出一套專用的數(shù)據(jù)庫來。
測試紅啊紅，修啊修，后來一算時間，在自動化測試上投入了 120 多人天，依然得不到一套穩(wěn)定執(zhí)行的測試用例，不但沒辦法保證交付質(zhì)量，還讓每個人心力交瘁，于是毅然決然的停掉了。
過了兩三個月，客戶終于準(zhǔn)備好了一套專門用來跑功能測試的數(shù)據(jù)庫，大連工資代發(fā)平臺開發(fā)團(tuán)隊也對行為驅(qū)動開發(fā)有了一定的認(rèn)識。于是他們又開始寫自動化測試，這次用了Cucumber，QA寫場景，Dev寫實現(xiàn)。
寫了大概 100 多個場景的測試后，又有人開始質(zhì)疑這一切。第一，整套系統(tǒng)實在是太龐大復(fù)雜了，寫到現(xiàn)在，連 1/4 都沒覆蓋到，所以應(yīng)該上線還是手工回歸？到底要花多大的精力才能把所有的場景都自動化起來？這些投入是不是值得？第二，測試環(huán)境還是不穩(wěn)定，比如本地數(shù)據(jù)跟CI用的數(shù)據(jù)不一致，比如Tomcat里面部署的應(yīng)用常常啟動不起來，等等。每個問題都要消耗大量的人力。這些浪費能不能平衡自動化測試到最后能夠帶來的收益？
但團(tuán)隊中還有其他人對自動化測試持樂觀態(tài)度，認(rèn)為問題總是可以解決的，只要堅持不懈就能夠看到長期的回報。于是就有了這次討論。
分析繪制系統(tǒng)循環(huán)圖的第二條法則是：“從有趣的地方開始”。在這個案例的場景下，開發(fā)團(tuán)隊最關(guān)心的是該不該寫自動化測試、它對交付能力會帶來什么影響，于是我們選擇“自動化測試的數(shù)量”作為起始點。
接下來是第三條法則——“詢問‘它將驅(qū)動什么’，以及‘它的驅(qū)動力是什么’”。
我們首先可以想到的是，自動化測試的數(shù)量增加會縮短發(fā)現(xiàn)Bug的周期，但是這個作用是需要測試數(shù)量積累到一定程度才會發(fā)揮出來的。它同時還會增加大連工資代發(fā)平臺開發(fā)測試的開發(fā)和維護(hù)成本，增加測試執(zhí)行時間，縮短手工測試周期。
