做過一個單元測試自動化，我們開發了近百行的測試代碼去測試一個代碼行為10行的函數;在UI測試自動化，則調用了IE的COM接口去驅動IE application，以模擬在界面上的兩個動作，輸入“測所”和點擊“搜索”按鈕，總共9行代碼(如果考慮自動化健壯性的話，還要增加錯誤處理代碼)。
觀察到這些，我們暫且不考慮自動化測試開發之后的維護，至少可以有一個直觀的認識：從手工測試向自動化測試的轉變是要付出的成本的，而且這個投入要遠比做一次手工測試的代價要高，比如，一個有經驗的自動化測試開發人員完成一段健壯的100行左右的測試腳本大概需要一天左右的時間，而手工完成這個功能點的測試則只需要10分鐘。一天 VS十分鐘，按理說，這是一個賠本的買賣，但為什么還有這么多的軟件企業對測試自動化情有獨鐘呢?排除一些盲目跟風，試圖提高測試技術含金量的情感因素，至少有以下幾個理性的現實驅動力。
1. 測試自動化主要是做長線投資，而非一時之計
顯而易見地，開發一個程序，只為了運行一次自動化測試是非常不劃算的。那么要想能收回開發自動化測試的投資，就要盡可能多地運行測試程序，每多運行一次，就會多節省一份手工測試工作量。這個簡單的道理可以說明為什么如今測試自動化應用最多的就是回歸測試階段。由于回歸測試往往是驗證軟件bug的fix或者軟件補丁的有效性，理論上，每一次bug的修復，都需要進行一次全面回歸測試。如下圖所示。
這樣在軟件測試流程里，回歸測試包括在測試分支(Test Branch)上進行的bug驗證測試，還有在發布分支(Release Branch)上進行的補丁更新測試(在實際的企業實踐中，發布分支的更新遠遠比圖中頻繁)，這樣回歸測試的重復性就非常高，而且持續時間長，直到軟件在市場上的退出才結束。這對于手工測試人員來說，可以說是一個對耐心和毅力的巨大考驗，再美好有趣的事情如果天天重復去做，而不做任何變化，最終也會成為枯燥乏味的代名詞。所以手工測試人員是有愿望通過自動化測試來改變現狀的。這就為回歸測試自動化的實施同時提供了主觀的動機和客觀需求。
【案例】：
一些有經驗的軟件測試團隊通常會采用一些激勵或游戲規則來增加回歸測試的趣味性，我曾看過一個TOP500的軟件企業里的測試部門，每隔一段時間就會由高層發起一個“蟲子打獵”(Bug hunting)的活動，通常在一個不太繁忙的周五午后，通知郵件一發出，全體部門立即行動，不論職務高低，不分經理，工程師，紛紛赤膊上陣。為了找到獵物，每人都各顯神通，盡可能地設計一些平時想不到的測試場景去尋找軟件里的bug，但有一個前提條件，就是他不能測試自己本來負責的系統模塊，必須去測試別人的而且他不熟悉的的模塊。比如小張是負責測Email的，那他在這次活動中，偏偏就要去測試Messenger;測試messenger的小李這次又要去測試calendar，這完全是一個網狀交叉的測試。打獵活動結束后，高層還要召開“慶功會”，評定出“最好的bug”，“最有創意的bug”等等稱號，雖然沒有獎金，但是每個獲得榮譽的人都會倍感自豪。而且，對于團隊來說，打獵活動收到成效也是顯著的，是一舉三得的好事情。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
