曾經記得剛畢業不久，以爲軟件自動化測試無所不能，無論什麼測試都想把它實現爲自動化測試。從微軟過來的測試經理曾跟我說，自動化測試是一種手段，真正能發現缺陷（Bug）的是手工測試，當時我很不理解。隨着經驗的積累，越來越體會到當時他給我說的那番理論，自動化測試也是有它的侷限性的。可悲的是，我所經歷的不少團隊領導一般都走向兩種極端，要不把自動化測試視爲萬能鑰匙，要不把自動化測試貶得一文不值。凡事都有利弊，這句真理亙古不變！在進行自動化測試之前，我們需要知道它的利弊。
自動化測試的先決條件
不少投入自動化測試的團隊，都對自動化測試能否帶來所期望的的價值產生懷疑，大家可以參考《如何讓軟件測試人員發揮最大價值》這篇博文對軟件測試人員的價值發揮的分析。本文將詳細講解，滿足哪些條件才適合做自動化測試，公司的哪些產品需要引入自動化測試，才能夠最大限度地發揮自動化測試帶來的效益。如果項目滿足以下一種或多種條件，就可以考慮引入自動化測試了。
產品需求變更較少
產品的開發也忌諱頻繁的需求變更，自動化測試也是如此。自動化測試本身也是一種軟件開發過程（需求分析，代碼編寫，測試等），良好的架構設計能夠降低變更帶來的風險，但風險不可避免，額外的工作也不可避免。如果產品需求比較明確，各方面都能夠按部就班的時候，就可以考慮把自動化測試提上議程了。
.項目開發週期較長
項目的開發週期較長，軟件產品的生命週期也較長，投入自動化測試就能夠帶來更多價值。自動化測試的前期投入是很大的，特別是對於自動化測試從零構建的團隊而言，它的週期甚至超過被測產品本身的開發週期。所以對於開發週期較短但軟件生命週期長，或者軟件開發週期和軟件生命週期都長，就可以考慮投入自動化測試。對於這種情形，不要吝嗇資源，否則隨着測試用例的增加，頻繁的迴歸測試，後續會更加被動。若軟件生命週期較短，就要慎重分析了。投入的自動化測試，能夠在將來的產品或其他部門的產品中使用？需要從現狀和長遠利益，統籌規劃，不能草率下決定。
測試用例執行頻繁
若測試用例數量龐大，執行時間漫長，執行頻率高，都是需要考慮引入自動化測試的特徵。這些問題，可能在軟件的開發初期，不是很明顯，所以需要決策者要有遠見，預測將來隨着時間的推移，測試用例的數量、執行時間、執行重複度等是否會增大，自動化測試投入產出比是否值得。
手工測試無法勝任
如果需要做高併發操作，持續收集設備資源（CPU、內存、磁盤IO、網絡帶寬等），長時間穩定性測試（7x24小時），多用戶操作等手工操作或測試無法勝任的工作，就需要利用自動化測試工具來完成這些任務了。對於存在大量的迴歸測試工作，也應該儘量考慮實現自動化測試，以減少手工測試人員的勞動強度，提高工作效率。
人物財力資源充足
自動化測試，特別是需要從頭開始做起（自主設計框架、自主研發測試工具等），更是需要耗費大量的人力、物力和財力。一般公司都會選擇開源測試框架和測試工具，以降低開發成本（後續系列文章會講解工具選型原則）。但是，對於自動化測試的二次開發和維護，測試腳本的編寫和維護，測試用例的管理，獨立的自動化測試環境（後續系列文章會講解測試環境）等，都需要投入客觀的資源。若公司資源有限（沒有自動化測試開發人員，沒有一套獨立的自動化測試環境，沒有充裕的自動化部署時間等），自動化測試想要取得預期的效果，那簡直是癡人說夢。
適合自動化的測試類型
不是所有的測試類型都適合做自動化測試，例如用戶體驗測試（QoS），本身就比較主觀，很難用自動化測試（機器是很客觀的）來驗證佈局是否美觀，視覺是否舒適，效果十分炫麗等。但是下面這些測試類型，比較適合自動化。
單元測試
單元測試一般都有開發人員實現和維護，主要是針對各功能模塊的函數調用進行測試，粒度較小，實現簡單，甚至可以通過工具自動生成單元測試用例。
迴歸測試
進行大量回歸驗收的測試用例時，或者手工執行用例發現了Bug，需要增加對應的自動化測試用例跟蹤缺陷是否解決等場景，也適合引入自動化測試。
性能測試
性能測試涵蓋比較廣泛，包括壓力測試、穩定性測試、吞吐量測試等，這些都是手工測試無法勝任的任務，必須引入自動化測試。
接口測試
對於接口(API)測試，由於接口相對比較固定，類似於單元測試，比較規整的API接口，甚至能夠通過工具來自動生成測試用例，非常適合自動化測試，投入小，回報大。
協議測試
由於協議（如HTTP，FTP，RTSP，HLS等）定義規範，接口說明比較嚴謹且很少改變，對協議兼容性進行測試時，也非常適合引入自動化測試。
系列文章目錄地址：
《漫談自動化測試（一）——如何入門》
（http://blog.csdn.net/thomashtq/article/details/45217271）
轉載請註明出處：漫談自動化測試（二）——適用場景（http://blog.csdn.net/thomashtq/article/details/45217499）