一個項目的自動化測試實踐(2)

　　我們最后的自動化測試結構：

　　手工測試

　　手工測試內容主要是功能測試。

　　自動化測試價值低的部分我們采用手工測試，這部分內容包括報表模板，相對獨立，內容不多，一次測試處處通過;

　　自動化測試成本高的部分我們采用手工測試，這部分內容包括報表展現組件的編輯功能，因為采用了Ext JS，所以自動化測試困難;

　　無法自動化的測試：報表在線生成PDF，報表樣式，WEBDEV批量上傳圖片等;

　　我們與QA的約定：

　　每完成一個用戶故事，我們會與QA、BA一起mini showcase;

　　QA驗收完成后編寫功能測試用例;

　　我們對QA編寫的功能測試用例進行自動化，共同維護一個功能測試列表;

　　對于不能自動化或自動化價值不高的測試用例QA繼續使用手工測試。

　　四、我們感受到的自動化測試價值

　　1、通過自動化功能測試，我們使得需求對客戶可視化;

　　2、QA的回歸測試成本降低，盡管目前頻繁的向客戶實際使用環境部署，但QA每次部署只需要做一些簡單的冒煙測試;

　　3、測試即需求，這點在TDD的開發過程中感覺非常明顯，今天開發的目的就是使這個測試通過，避免了頻繁部署到應用中進行測試，最快的電梯不是速度最快的電梯，而是中間停的樓層最少的電梯;

　　4、與持續集成一起，及時反饋。這點在進行JS代碼編寫時，心理上都非常依賴于selenium測試，對于沒有測試覆蓋的地方，沒有安全感;

　　5、足夠的單元、集成測試保證了頻繁重構，沒有人愿意引入BUG，沒有足夠的測試，沒人愿意重構;

　　6、測試即文檔，良好的測試和命名，使得新加入的成員非常容易理解當前代碼的功能。

　　五、思考和討論

　　1、自動化功能測試做到多少才合適?

　　當然是越多越合適，問題在于自動化功能測試成本要大大高于單元測試和集成測試，這些成本反映在測試環境的搭建、數據的準備，需要準備其他很多關聯數據例如用戶信息和權限信息、自動化功能測試的運行時間長、穩定性(隨機成功/失敗)、編寫等等，需要權衡成本與收益。

　　個人認為，自動化功能測試需要考慮的著重點包括：頁面是否包含大量功能交互性JS(與展現性JS相對)?當前功能是否與其他功能共享一些代碼?即獨立性，獨立性越低越需要著重覆蓋(這里又涉及到另外一個問題，即從各個模塊里重構出共用代碼是否總是合適?)。QA每次冒煙測試時是否需要重復回歸(重復回歸次數越多，自動化越有價值)?經常失敗的測試一定比不失敗的測試價值更高?或者從未失敗過的測試就沒有價值?

　　2、單元測試?功能單元測試?

　　TDD的測試粒度多大才合適?從我個人而言，幾乎天然的反對mock，為了滿足測試覆蓋率的追求，強制將兩個聯系很緊密的類分開，做出各式各樣mock，這真讓人氣餒;stub也不是什么好東西，在一個曾經的spring項目里，在測試目錄里，一堆一堆的測試xml配置文件讓人有種嘔吐的感覺。那就做集成測試吧，兩個類關系很好，那么就整體測試它們的輸入和輸出，看起來很不錯，功能實現了，測試也沒多寫，也不用準備太多其他東西，但是打開實現代碼，你就發現那個丑陋，到處是復制和粘貼，是啊，不管黑貓白貓抓住老鼠就是好貓，只關注了當前結果，完全失去了TDD驅動簡單設計的好處。

　　3、測試的重點是測試用例的設計，它反映出對需求的理解

　　那么結論就很明顯，我們如果連需求就沒有理解，如何進行實現，所以測試驅動是很自然的。

原文轉自：http://www.uml.org.cn/Test/201006281.asp