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

　　實施Scrum開發過程充滿著挑戰—尤其對于從零開始做產品的團隊來說。在每個增量沖刺中，你不僅要新增功能，還要確保已實現的功能依然可用。這時，擁有一個可覆蓋系統測試和集成測試的自動化框架,可為團隊增添不少火力。它不僅能為回歸測試增添一層保障，還能釋放出珍貴的開發和測試人員時間,讓他們花更多的精力在擅長的領域。

　　在這篇文章中，我想分享我們團隊在最近項目中成功應用的一些自動化測試方法--事實證明，這些成果是一項巨大的資產。付出的努力將會在未來得到很多的回報?，F在，我們每天能在類似線上的測試環境下，構建，集成，測試和發布同線上一樣高質量的產品應用。通過相互分享好的和壞的經驗，我們學到新的知識并且加以實踐，把事情做得更好。

　　我們團隊很高興看到應用自動化測試方法所收獲的這些成果。采用這些方法能讓我們持續地在每個沖刺中輕松添加新的功能，同時，把我們從多輪回歸測試中解救出來去尋找和修復重要的問題。

　　下面是我們學到的一些實戰經驗，如果你正開始著手在項目中增加自動化測試，這些經驗應該可以讓你少走彎路。

　　從小做起

　　生成自動化測試的過程類似于生產被測軟件。這涉及到大量的設計，編碼和測試它本身是否正常工作。因此，同應用一樣，自動化測試最好是增量開發的—在幾輪沖刺中陸續地向自動化框架添加新的測試和功能。需要明確的是，我們的目的不是在一開始就產生完美得能做任何事情的測試框架， 它不可能達到。 從事測試同生產軟件一樣，是有價值的。它們能讓人建立自信和看到令人激動的進展。即使再小的成功也能讓大家快速地進入狀態—特別是當測試自動化方案已經運行并且證明是對團隊有價值的時候。

　　測試自動化訂單

　　為你的項目維護一份測試自動化訂單，在訂單中列出所有的自動化任務和已識別的改進需求。如果每個沖刺你從訂單中認領幾項并實現，不久就會看到一個新的自動化回歸測試集合成型。有時候 ，測試自動化訂單的用戶故事可能需要開發人員專職來實施，為推進自動化測試，需要向產品負責人提出人員需求。但如果團隊成員都推崇質量，讓產品負責人看到這些用戶故事的價值不是難事。

　　一個測試自動化訂單可以包含如下有先后優先級的項：

　　參數化測試執行環境

　　持續地集成

　　提升報告機制

　　在通知郵件中提供附上錯誤日志的選項

　　為流程場景收集性能報告

　　為重要測試用例的并發執行增加驗證性測試

　　工具只是手段不是最終目的

　　測試自動化所用的工具和框架不是投入測試時間的真實目的。如果你眼光長遠的話，真正的目的是通過快速的反饋來支持新一輪的開發。它可以讓各方知曉項目的最新狀態，由此，利益相關者可以做出有根據的決定。既然工具和框架只是實現更多的一種途徑，就不要沉迷在新工具上而忽視了最終的目的。

　　測試數據和腳本獨立于所選的自動化測試工具也尤為重要。寫死在腳本里的測試數據，系統配置和對象很難維護。從長期看來，如果項目碰到意外問題，頻繁地與測試數據交互會讓中途更換測試工具成為一件困難的事。

　　設計有意義的測試而不是什么都自動化

　　測試方案最重要的部分是測試。很多團隊花大量的時間和精力在開發功能齊全的框架上而忽視了有意義的測試。不要讓框架代碼比測試代碼更重要。開發一流的框架理念是誘人的但是要避免這個陷阱。投入測試自動化的真正價值在于它產生的測試，因此要集中精力在有意義的測試本身。

　　另外，不要因為自動化而自動化。在添加新的測試之前適當的考慮可維護性和執行時間。每個加入到自動化測試集合的測試，都成為了產品基線的一部分，也需要同其他基線一樣維護—在整個應用的生命周期中。添加復雜和難維護的測試，最終結果是減慢組內反饋循環，這個應當避免。

　　讓自動化測試遠離你本地機器

　　如果你正在為項目編寫自動化測試，而且只在你本地機器上運行。那么這個測試基本沒有價值。團隊中的每個成員應該享受到自動化產生的安全保障。要達到這個目的，你必須讓自動化測試遠離你本地機器。

　　團隊所有成員應該能夠訪問自動化測試集合并且點擊按鈕就能執行。如果某個成員想要在提交大量改動之前或之后執行測試集合，他應該能夠執行并且不麻煩地得到結果。理想狀態下，自動化測試集合最好架設在外部服務上，作為構建過程或者持續集成環境的一部分來運行。有頻率地訂制測試集合執行(如在每次遷入或者至少每日)并標上執行狀態。適時地制定通知機制來通知有關人員最新的執行狀態。

　　有關執行時間

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

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

　　保持測試用例狀態為綠色

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

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

原文轉自：http://www.anti-gravitydesign.com