深入了解自動化對自動化測試的誤解

這邊文章是寫給沒有接觸過自動化測試，包括剛學自動化測試或者專案管理人員。

在工作中常常會有這種人，專案剛開始才出設計稿就要求先將自動化測試用例寫出來；既然有自動化測試，那麼就不要手工測試了，全部使用自動化。

最常出現的誤解，既然有自動化測試就不需要手工測試。我在世界排名前幾位的公司專案文件上看到過這樣的字眼「 goal: no manual testing」，目標沒有手工測試，我認為這是個笑話。

自動化測試是否能夠替代手工測試？

我們先來了解手工測試與自動化測試的概念。

手工測試是測試人員根據用例描述的測試步驟和方法，手工地乙個乙個執行，然後觀察結果，看被測程式是否存在異常。手工測試與自動化測試相比較，手工測試能實時觀察各個測試功能執行，但它的工作量大、繁瑣、低效，並且出現bug需要重複的測試。

自動化測試是在預設條件下執行程式，評估執行結果，預先條件應包括正常條件和異常條件。它是把以人為驅動的測試行為轉化為機器執行的一種過程，自動化測試執行速度比手工測試高很多，他的測試的準確性也相對較高。

從上面的描述能看出，自動化測試是在預設條件下執行程式，評估執行結果，它是設定固定路徑來執行程式，這就造成它呆板。當執行結果出現預設條件之外異常，自動化程式就無法識別就會直接放行通過。

以現在的技術條件，程式還無法達到人的觀察力，所以對於新功能，新需求無法使用自動化測試。

自動化測試僅僅是某些條件下手工測試的一種補充，它無法全面取代手工測試。

自動化測試用例，天天在執行應該會發現大量的bug。

這個也是對前面自動化測試的概念沒有理解透徹，自動化測試在預設條件下執行程式，評估執行結果。證明你在編寫自動化測試指令碼的時候這個功能已經正常，而你要在執行過程中發現大量的bug，這有可能嗎？除非每個版本質量太差，開發每次都創造老功能的新bug。

自動化測試測試的真正用途不是用來找bug，而是解放有經驗的測試工程師的生產力，讓其從事新的測試方法和測試手段的研究。讓測試人員的時間和精力來花費在找到更多、更深層次的新bug上，將產品質量再提高乙個檔次。

自動化化測試它無法發現新問題，它只適合用於回歸測試。

自動化測試的人員投入不一定比手工測試少，前期的指令碼編寫與除錯，後期的用例更新與維護，這些都是需要人力投入。尤其是前期自動化測試指令碼開發耗時最多，而且自動化測試遠比手工測試脆弱，後期用例維護成本也很高；

自動化測試用例的開發工作遠大於單次的手工測試，產出價值往往在於長期的回歸測試，短期內發揮的作用可能不明顯。

實行自動化測試的初期，用例開發效率通常都很低，並且有很大概率後期在功能沒有的變化的情況下需要重構用例。

自動化測試的效率很大程度上依賴用例的設計以及指令碼實現質量，不穩定的自動化測試用例比沒有自動化更糟糕。

自動化測試的投入成本與需求的變更頻率相關，產品需求頻繁變更，自動化測試工作量的投入也就相應提高。

也不是所有的測試用例和測試步驟都可以轉化為自動化測試。在自動化測試投入較多的行業，領先企業的自動化測試率有的能達到80%左右，但仍有20%左右的測試用例還是需要手工來進行。在國外，通常從開發第一版測試用例時，就同步進行自動化測試指令碼的開發，所以自動化測試率普遍比中國企業高。

自動化測試是為了增加手工測試的廣度和深度，它無法達到100%的測試覆蓋，因為沒有足夠的時間或資源，它的投入與收入不能成正比。

自動化測試不光只能進行效能測試和功能測試，介面測試也會採用自動化測試。由於功能測試的覆蓋率無法達到100%，所以現在能多企業將自動化測試瞄向了介面，介面測試的自動化能實現100%覆蓋。

錄製得到的指令碼不是有效的指令碼。

很多人仍然把自動化測試等同於自動化測試工具的錄製和回放。而事實上，錄製的指令碼通常是不可重複使用的指令碼，指令碼中充滿了不可變動的輸入值，這些值應該被引數化，否則指令碼僅僅適用於當前測試情況，指令碼中還需要加入條件判斷、迴圈結構等，以便增強測試指令碼的靈活性。

錄製的指令碼維護成本高，它前期投入可能相對較少，但後期的更新與維護很高。

深入了解自動化 對自動化測試的誤解