摘要：作者以自己多年在測試領域尤其是在自動化測試中的經驗，從管理層面講述了自動化測試相對于手動測試的優勢；并且從不同的方面論述了目前大家對于自動化測試的錯誤認識，同時讓大家充分意識到推行自動化過程中會面臨的困難。
關健詞：自動化測試；手動測試；
如今自動化測試以其執行速度快，結果反饋迅速的最大優點獲得了業界的廣泛認可，尤其在如今需求快速變化的今天，大家對于自動化測試的需求和渴望更是到了一個空前的地步。誠然，自動化測試受到大家的追捧是有充分的理由，因為相對于人工測試，它有著不少的優勢。我們且來看看。
1、自動化測試的優勢
1.1 對程序的回歸測試更方便
回歸測試可能是自動化測試最主要的任務，特別是在程序修改比較頻繁時，效果是非常明顯的。由于回歸測試的動作和用例是完全設計好的，測試期望的結果也是完全可以預料的，將回歸測試自動運行，可以極大提高測試效率，縮短回歸測試時間。
1.2 可運行更多更繁瑣的測試
自動化的一個明顯的好處是可以在較少的時間內運行更多的測試。而且人工測試在面對多輪重復執行時，測試人員往往會趨于倦怠，而這將對產品的測試質量帶來其他的損害
1.3 可以執行一些手工測試困難或不可能進行的測試
比如，對于大量用戶的測試，不可能同時讓足夠多的測試人員同時進行測試，但是卻可以通過自動化測試模擬同時有許多用戶，從而達到測試的目的。
1.4 更好地利用資源
將繁瑣的任務自動化，可以提高準確性和測試人員的積極性，將測試技術人員解脫出來投入更多精力設計更好的測試用例。有些測試不適合于自動測試，僅適合于手工測試，將可自動測試的測試自動化后，可以讓測試人員專注于手工測試部分，提高手工測試的效率。
1.5 測試具有一致性和可重復性
由于測試是自動執行的，每次測試的結果和執行的內容的一致性是可以得到保障的，這樣使測試結果具有可對比性，并且達到測試的可重復的效果。
1.6 測試的復用性
由于自動測試通常采用腳本技術，這樣就有可能只需要做少量的甚至不做修改，實現在不同的測試過程中使用相同的用例。
1.7 增加軟件信任度
由于測試是自動執行的，所以不存在執行過程中的疏忽和錯誤，完全取決于測試的設計質量。一旦軟件通過了強有力的自動測試后，軟件的信任度自然會增加。
因為自動化測試現在如旋風之勢席卷而上，特別是全球風靡于敏捷開發之后，更是把自動化測試提高到了一個史無前例的高度。而且人工測試具有更敏銳的觀察力，能從一個稍縱即逝的小異常中挖掘出大問題。
另外有些測試是必然需要人工干預的，如冷啟動機器，如需要人的感官去體驗的。那么如果真的需要追求100%的自動化測試覆蓋率，我們唯一的選擇就是犧牲這部分的測試案例來成全100%，這對于測試覆蓋率也是很大的一個損失。
而從投入產出比的角度來看，以目前對各組織的統計而言，60%是一個比較合理的值，如果要高于這個值，那么付出的人力將是成倍增長的。在我們的組織中一度自動化測試覆蓋率的要求是95%，曾經我們也勉強達到，但是投入的代價是不可維續的。所以我們過后調整了我們的合理期望值。比如說在比較簡單的功能性測試中自動化測試是比較容易的，但如果是涉及模塊和網元很多的系統測試或互通性測試中就顯得相當的力不從心了。
2、自動化測試是適用于任何情況的
2.1 自動化測試是適用于任何產品的
并不是所有的產品都適用于自動化測試的，如果這個產品只會做有限的幾輪測試，接著就不會再有持續的開發。那么就沒必要使用自動化測試，因為這樣的投入產出比比較低。畢竟在開發自動化測試階段需要耗費大量的人力物力。對于決定自動化一個測試用例的一般規則是這個測試用例必須被運行 4 次以上。這個數字是基于用戶對測試工具有良好的技能并且有一個良好的測試框架的。如果情況不是這樣的話，整個數字能夠是 10-20次或者更高。
再者如果變化比較大的話也不適用自動化測試。國內多數軟件公司是針對最終用戶進行項目開發—工程性質的軟件，而不是產品開發。項目開發周期短，不同的用戶需求不一樣，而且在整個開發過程中需求和用戶界面變動較大，這種情況下就不適合自動化測試，對于不停變化的需求和界面，可能修改和錄制腳本的工作量大大超過測試實施的工作量，運用測試工具不但不能減輕工作量，反而加重了測試人員的負擔。
2.2 自動化測試是適用于任何測試階段的
版本經理通常認為自動化測試能運用于任何階段的萬能鑰匙，但事實上從本人的經驗來看，自動化測試適用于回歸測試，但不適用于新功能的測試。首先因為新功能剛遞交之時穩定性是不可保證的。而自動化測試對于其不穩定性是相當敏感的，所以通常都無法正常的運行完測試，也無法達到我們盡快得到結果的預期。其次在新功能剛遞交時其期望結果是不可預知的，這對于自動化測試腳本的編寫帶來了極大的不確定性。最后在新功能遞交階段是需要我們發現大量問題的時候，而自動化測試無法擔此重任。
2.3 自動化測試是適用于任何組織的
在最初嘗試自動化測試的時候，是需要投入相當的人力和物力去選擇自動化工具，構建自動化測試的框架，做必要的技能培訓，摸索編寫自動化測試的腳本，如果一個組織無力承負這樣的代價，那么是不適合自動化的，否則只能是半途而廢的下場。
即使我們澄清了這些誤區，我們對于自動化測試有了一個比較清晰的認識，也對其有了一個正確的期望，但實際在推行的過程中我們還是會遇到不少的困難，而困難主要來自于以下幾個方面。
3、自動化測試推廣中的困難
3.1 來自于測試人員的不接受
因為測試人員是自動化測試的主體，他們承擔著轉型的重要職責，所以他們的接受與否對于工作的展開是尤為重要的。但作為一個新生事物，通常是不太容易被接受的，尤其是在大家覺得原有的模式很舒服很習慣的情況下。所以在最初的階段完全是強推。而經過一年的努力，當作年終總結時，所有的測試人員都說那年最艱難的是自動化測試，感觸最深的是自動化測試，從中學到最多是是自動化測試，而且發現自動化測試的確幫了很大的忙。
3.2 來自于測試人員技術上的不足
測試人員很多都不具有編程的經驗，但自動化測試腳本的編寫還是需要一定的編程功底，如果組織中專門有一個具有編程功底的團隊能開發自動化測試的工具，并且根據手動的測試案例編寫自動化測試的腳本，那狀況可能會好些。但目前更多的組織是需要人人能編寫自動化腳本的。而在我們的轉型中我們經歷了三個階段，基本完成了能力的建設。第一階段以能用為目的，專門有人提供所需的函數，測試人員只需調用這些函數完成自動化測試的目的，不需要考慮程序的可移植性，可復用性。第二個階段每個人會寫一些自己所需要的函數，并且具有良好的移植性和靈活性。第三個階段每個人會寫能為他人復用的函數并且遵循制定的規范。這樣的轉型雖然慢但卻是比較穩妥的方式。
3.3 來自于組織內其他人員的阻撓
在自動化測試的初期階段，必然是會耗費相當多額外的精力去構建環境等等，而且我們也需要時間完成技術上的積累。所以這時候不得不像項目經理去索要更多的人力。這是一個長期受益的舉措，但對于當前而言似乎是利大于弊的。所以會遭受各方各面的壓力，尤其是來自于項目經理的壓力。我們很幸運我們走過來了，而現在當所有的人嘗到了甜頭之后，對于自動化測試的支持程度也大大的提高了。
以上是筆者在經歷自動化測試轉型過程中的一點體會，希望能對其他正在轉型或者準備轉型的組織能有一些幫助。