摘要：作者以自己多年在測試領域尤其是在自動化測試中的經驗，從管理層面講述了自動化測試相對於手動測試的優勢；並且從不同的方面論述了目前大家對於自動化測試的錯誤認識，同時讓大家充分意識到推行自動化過程中會面臨的困難。
關健詞：自動化測試；手動測試；
如今自動化測試以其執行速度快，結果反饋迅速的最大優點獲得了業界的廣泛認可，尤其在如今需求快速變化的今天，大家對於自動化測試的需求和渴望更是到了乙個空前的地步。誠然，自動化測試受到大家的追捧是有充分的理由，因為相對於人工測試，它有著不少的優勢。我們且來看看。
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 來自於組織內其他人員的阻撓
在自動化測試的初期階段，必然是會耗費相當多額外的精力去構建環境等等，而且我們也需要時間完成技術上的積累。所以這時候不得不像專案經理去索要更多的人力。這是乙個長期受益的舉措，但對於當前而言似乎是利大於弊的。所以會遭受各方各面的壓力，尤其是來自於專案經理的壓力。我們很幸運我們走過來了，而現在當所有的人嘗到了甜頭之後，對於自動化測試的支援程度也大大的提高了。
以上是筆者在經歷自動化測試轉型過程中的一點體會，希望能對其他正在轉型或者準備轉型的組織能有一些幫助。
***********************************=分割線******************************==
自動化測試 引言 自動化之我見
作為開篇，這裡先簡單介紹一下個人情況 本人非計算機專業的本科畢業，從事軟體測試工作一年多了，同樣的，接觸自動化測試領域也有一年了，打算開個部落格把我在工作中所學到與自動化測試有關的東西分享出來。好啦，下面開始說正題 自動化測試自身就是乙個很大的概念。逛過一些測試論壇的童鞋應該會知道qtp和loadr...
軟體測試自動化
只有當系統的介面元素不會頻繁的變化 系統功能基本穩定，已經通過一至兩輪的手工測試，確定系統不會存在重大缺陷時，才可以考慮自動化的實施。使用自動化測試工具代替手工完成一些測試任務，現在國內主流的測試工具是loadrunner 和qtp。lr 效能測試工具 和qtp 自動化測試工具 的區別 1 lr 基...
軟體測試之自動化測試
自動化測試的優勢 能夠極大地提公升測試的效率，測試人員可以迅速地在指定平台部署測試指令碼且對相應功能進行測試。弱化 了軟體測試人員個體差異對測試結果的影響。提高整個測試團隊的技能水平。自動化測試的缺陷 自動化測試的缺陷在於 總是按照既定的流程往下走，不能像人一樣隨機應變。一旦功能發生變動，就需要重新...