京東購買鏈接：https://item.jd.com/10205955087769.html

在我們的諮詢業務中，經常會遇到這樣一個現象：從未開展過測試自動化的團隊，都會説自己對測試自動化非常瞭解。同時，在我們主持過數百次播客訪談後，也認識到測試自動化對他們來説，往往只是一個概念，一種基於信念的概念。我們在一年、兩年，甚至五年後，再次回訪這些團隊，發現那些曾被指導過的團隊要麼終於領悟了我們給出的建議、經驗和教訓（但當時未能踐行），要麼由於某些原因最終失敗了。

事實證明，使用測試工具的一些思路，只能通過實踐經驗來學習。如果沒有前輩、文檔、視頻教程等資料的引導，團隊成員可能會重複犯同樣的錯誤，甚至周而復始。就像一些團隊，沒有地基便建造橋樑，橋樑最終會垮塌。因此，建議不要重蹈覆轍，而是從實踐經驗中學習。故本章以筆者多年經驗為框架，將討論以下內容：

● 沒有銀彈：沒有任何一種技術或方法可以從根本上縮短測試 / 修復週期。

● 雷區迴歸問題：傳統的自動化測試只在第二次及之後的運行中才有價值，且價值非常有限。

● 海戰棋問題：當發現 bug 時，無法改變策略的自動化工具是有侷限性的。

● 測試維護成本問題：只關注特定變更（可能會遺漏一些隱藏變更）與每次變更後腳本報錯之間如何把握平衡。最後，針對這些挑戰，我們將給出一些解決方案。

2.1 技術要求

本章主要包含一系列概念，如此設計的目的是使任何受過高中教育、瞭解互聯網、有抽象思維能力的人都能夠理解。本節通過比喻的方式展開論述，並從網格座標和遊戲等概念中汲取測試靈感。讀者可以打印表格，並與其他人員一起用鉛筆和紙張進行實際操作，如此有助於理解本章討論的概念。例如海戰棋（Battleships）遊戲，讀者可以通過谷歌、百度等搜索引擎搜索海戰棋相關文檔，瞭解海戰棋棋盤和規則，以便在閲讀本章時能夠容易理解。

提示：海戰棋（Battleships）是一款模擬海戰的棋類遊戲，它包括佈陣和對戰兩個過程。玩家必須在規則範圍內佈陣，通過分析和判斷來確定對方戰艦的準確位置並將其摧毀。首先將對方所有戰艦全部摧毀的玩家獲勝。遊戲採用回合制，每回合玩家有一次點擊格子的機會，如果未能點中敵方戰艦，將輪到對手回合；如果點中了敵方戰艦，將繼續點擊。

2.2 沒有銀彈

Fred Brooks 在 1975 年出版了一本《人月神話》，這可能是最早面向大眾，且至今仍在印刷的一本軟件工程書籍。其內容可能有些過時，但書中的三個觀點至今仍具現實意義。觀點一：增人不能增效，向已經延期的項目投入更多的人力會使項目進一步延期。隨着項目的擴展，團隊成員之間的溝通成本會呈指數級增長，從而導致成本重心從實際工作轉向溝通與協調。下一節將會討論如何保持有效溝通，降低溝通成本；觀點二：Brooks 提出了“第二系統效應”，可以理解為只有從客户需求的角度做出嘗試，才能真正瞭解什麼對客户有益。這一觀點也促進了快速原型設計和其他應對措施的發展；觀點三：沒有銀彈，沒有任何一項技術或方法可使軟件工程的生產力在十年內提高十倍。正如 Brooks 所説：“做好捨棄第一個原型的準備，你往往需要這麼做”（Plan to throw one away – you willanyway）。並且，本節的核心內容也來源於 1995 年他在第二版增加的一篇名為《沒有銀彈》的文章。

Brooks 博士在《沒有銀彈》這篇文章中指出，軟件開發由一系列明確的階段組成，例如規劃、需求分析、設計、編碼、測試和運維等，每個階段可能只佔總工作量的六分之一。因此，即使通過一些人工智能技術使編程變得簡單，甚至完全靠它生成，從而壓縮這一階段工作量，理論上，時間和成本最多也只能減少六分之一，約 16%。但在實踐中，任何階段的工作量都不可能完全壓縮為 0，即使依靠一些技術減少 75%，放置於整個軟件開發中，體量依然很小。故 Brooks 博士提出，沒有任何一個“銀彈”可以解決失控軟件的開發問題，而建議採用多個“銅質子彈”—嘗試多種方式逐步減少工作量，產生累積效應。本書正是我們嘗試打造多個“銅質子彈”的一次實踐。

接下來，讓我們嘗試通過自動化測試來縮短測試周期。

大多數團隊執行自動化測試後，都需要對結果進行檢查，確保測試報告都是系統功能問題，而非是受腳本、網絡等其他因素影響而出現的問題。對於一個測試人員來説，每個結果都需要依據數據或邏輯進行判斷。但對於自動化測試來説，是按照一定的順序直接執行操作並檢查結果的，更多的是檢測變化而非測試。因此，運行自動化測試就會出現失敗或錯誤，但這也可能意味着自動化工具正在按照預期的方式運行。測試人員除了檢查結果外，對一些失敗的用例可能還需要深入研究。藉助自動化工具測試複雜場景發現的問題，往往比手工測試發現的問題更難復現和定位。一旦可以穩定復現後，就需要提交 bug，然後等待開發人員修復，接着對程序重新構建和發版，最後執行自動化測試腳本，用例通過。

所有上述討論都基於一個假設，即自動化測試不需要成本，並且能夠立即完成。然而自動化測試的實施和運行都需要投入成本，包括編寫、調試、執行以及維護等。

在我們合作過的團隊中，多數情況下，自動化測試工具能減少的測試工作量也不到 50%，何況自動化測試工具並非免費和無限快的。即使是在每年耗資數千萬美元的測試項目中，仍非常重視手工測試，因為其比工具更能快速地給出有意義的反饋，即對於程序變更的地方，手工測試可以迅速開展並提交 bug，當開發人員開始修復問題時，依靠工具測試的項目可能報告都還沒有出來。我們並不是反對自動化測試，自動化測試也有自身的價值，例如持續交付的實現就需要工具輔助測試。本書所要表達的是：在沒有找到一個普適的解決方案（涵蓋產品研發的整個過程）前，不能盲目地“一切皆可自動化”。

如果你執意踐行一切皆可自動化的理念，當你在搜索引擎中輸入“軟件測試自動化如何實現”時，很可能會踏上一條艱辛的道路。雖然通過自己的鑽研，也能有所收穫。但這並不是本書所希望的，本書的目的是加速讀者的學習過程，即不必花費數年時間在黑暗中摸索筆者曾經蹚過的泥坑，而直接掌握這些經驗教訓。本章剩餘部分就將引導讀者擺脱宗教式的一切皆可自動化理念，提供更健康、更實際的選擇。