在敏捷項目中實施自動化測試之我見(2)

　　有關執行時間

　　執行測試集合里的所有用例需要花多少時間是個關鍵問題。如果自動化測試需要執行很長時間，那么它不再為我們增加價值，因為預期的反饋已經不再迅速(尤其對于敏捷項目中小的迭代)。另外，這些正在執行的測試集合會被停掉，因為等待它執行完是件痛苦的事。采用并行，類似infrastructure的產品，或者書中的其他方法--只要能使測試跑的快，你就可以維持一個快速的反饋循環。

　　另外，可為每個測試用例標上標簽并選擇性的執行所從事的功能模塊。能夠選擇性執行可以節省很多執行時間，尤其對于測試集合相當的大并且執行完整個集合在特定情況下沒有實際意義的場景。

　　保持測試用例狀態為綠色

　　將測試集合里的所有用例標成綠色(例如，執行成功的)。有時候，你可能知道某些用例會因為一些已知的原因失敗，也許是部分系統不可用或者在修復中的問題推遲一段時間上線。在這種情況下，你可以把這部分用例標成已知失敗的用例，讓測試框架忽略或者跳過它們。這樣做可區分構建中未知的和已知的失敗，新增的失敗用例可立即被發現。

　　一旦用例狀態變成紅色，自覺地優先將它變成綠色(例如，通過修復測試用例或者修復代碼)。越早定位到失敗測試，越容易更正他們--特別是剛剛簽入代碼改動導致用例失敗的情況。同樣要重視那些看似永遠不會失敗的用例集合，因為有自動化測試在會給人一種很安全的錯覺。某種情況下，如果加入的測試用例很脆弱經常失敗，又讓人覺得不安全。這兩種情況，團隊都應該做一些調查研究。

　　通過測試這些測試代碼來查找出問題是值得推薦的，它可以建立自動化測試可靠的自信。同樣，使用data fuzzing是個不錯的選擇，這樣，你不用在每次測試執行中用同一套數據。有助于產生更健壯和有意義的測試。

　　清晰的報告

　　花一些時間在測試框架中實現報告功能。用簡潔且精確的方式來報告失敗和錯誤，這樣研究人員可快速地定位到哪里出錯。報告要絕對簡單，如果有時間精力的話圖表化更好。

　　對所有人可見

　　最后也最重要的是，讓過程簡單，且所有的相關人員可操作和看到執行結果。在網上記錄測試執行歷史和趨勢，如果可能的話，把它掛到代碼質量分析工具如Sonar上。讓大家從各自的角度去看結果。盡量讓添加和更新測試簡單，大家一起參與進來把測試做的更好。

　　總結

　　總的說來，我們認為有效的，應該格外重視的測試自動化方法包括：

　　在項目的開始從小做起，迭代地在每個完成的沖刺中構建測試集合。

　　建立測試自動化訂單，作為優先級任務清單。這有助于集中精力在當前任務，同時不忽視長期目標。好好研究可選測試工具的用途，不要舍不得花費一到兩個沖刺的時間去熟悉它們。

　　保持測試腳本和數據較少的依賴，有助于日后有需要更換測試工具時輕松應對。

　　產出有意義的測試，在向自動化測試集合添加用例的時候，適當地考慮可維護性和執行時間。

　　盡快地想盡辦法讓整個團隊使用已遷入到build/CI system的安全保障。

　　產出有意義的測試并且確保它們不會給人安全的假象。

　　努力地快速解決失敗用例，讓測試執行時間盡可能的短。

　　最后也最重要的是，適當地添加直觀的報告機制，讓團隊所有人能看到測試結果和歷史趨勢。這有助于每個人都參與進來監督開發的進展和健康度，并做出有根據的決定。

　　在這篇文章中，我分享了在最近項目中實施測試自動化所學到的經驗教訓。其中所列的測試自動化方法絕對是完整的。它們是我在一個很棒的團隊實施測試自動化時收集到的寶貴經驗集合。

　　要銘記的是，軟件測試自動化讓電腦一遍遍地快速執行回歸測試集合，驗證功能點，發揮其最大的價值。團隊中的成員被釋放出來做更擅長的事，運用其認知技能在流行前沿探索式測試系統。

　　如果你贊同文章中所提倡的測試方法并投入自動化測試，你也可以每天在類似線上的測試環境下，構建，集成，測試和發布同線上一樣高質量的產品應用。

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