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

2.3 雷區迴歸問題：覆蓋模型

我們現在討論的自動化測試是點擊式的檢查性測試，通過工具模擬並執行用户操作，檢查操作過程中可能出現的問題。當然，對於沒有太多隨機變化元素的測試，單元測試和腳本測試也可以完成。模型驅動和其他一些測試方法好像可以應對隨機變化元素的測試，但這些方法因為存在一些弊端，最終並沒有得到廣泛應用。

當前，也有一些人編寫了他們所謂的測試代碼，我們暫且不論他們是如何實現的。假設有一個電子商務系統，測試肯定需要模擬用户的一系列行為，例如創建賬户，商品搜索，找到產品，將其添加到購物車，付款購買。

但對於搜索功能，早期的自動化測試並不能直接帶來價值。對於多數自動化工具而言，在大部分時間裏由於各種原因，搜索功能可能會出現搜索按鈕找不到、搜索引擎本身存在 bug、搜索結果不一致或結果數據不斷變化等問題，此時就需要和開發人員不斷溝通和調試。直到這些問題都被修復，搜索功能穩定運行後，自動化測試才真正開始發揮作用，在此之前，它並不能提供有效的價值。故自動化工具的真正價值是從開發人員修復完所有問題後開始的，即迴歸測試。而回歸測試的目的就是檢查原有功能是否可以正確運行。例如點擊第一頁面上的元素 A 跳轉到第二頁面；第二頁面中有元素 B，點擊可跳轉到第三頁面。在某次迭代中，第三頁面正在開發時，元素 A 突然消失，導致無法再進入第二乃至第三頁面。

在自然增長的代碼庫中，代碼之間相互影響，甚至破壞邏輯是一件很常見的事情，此現象也被稱為“大泥球”（big ball of mud）現象，關於大泥球現象可閲讀 Brian Foote 和 Joseph Yoder 在 20 世紀 90 年代末發表的文章（鏈接 2-1）。同一代碼庫中，不同程序員在同一區域進行開發，大泥球現象是避免不了的。

在第 3 章，本書會簡要介紹現代工程實踐對於降低迴歸問題發生頻率的益處。本節討論的是自動化測試對於迴歸測試的價值。接下來，我們通過探索狗狗公園並清除狗狗粑粑的示例進行説明。

本書第 1 章就提到，不可能做到完全測試，因此也不可能創建一個輸入空間映射所有可能的輸入變換組合。俗話説，地圖並非疆域（The map is not theterritory）。模型也是一種地圖，其試圖以一種近似的方式反映出實際狀況，在構建時，就需要做出一定的取捨，為了可理解性而犧牲全面性。正如喬治 • 博克斯(George Box) 所説：“所有的模型都是錯誤的，但有些確實有用”。

在本節示例中，我們將可能的輸入空間構建成一個二維網格模型。你可將其想象為一片雷區，在此雷區內，我們可以做的事情就是軟件的各種操作，而地雷就是軟件 bug。或者也可以將二維網格模型想象成一個有很多人遛狗的公園，隨着時間的推移，遛狗人次一直在增加，未被清理的“粑粑”也在增加，於是公園裏留下了很多狗狗粑粑。軟件測試就好比是探索這個公園，然後發現並清除狗狗粑粑。公園就是被測軟件，狗狗粑粑則是軟件 bug。

因此，我們手裏拿着鏟子在公園裏行走，行走的區域就是軟件可能的輸入。在此過程中，我們看不到全局。此想法來自軟件質量方法公司的 Doug Hoffman，如圖 2-1 所示。

在 20 世紀 80 ～ 90 年代，軟件測試深受制造業的影響，非常注重穩定性、可預測性和可重複性。人們討論的重點是如何創建測試用例，並將這些測試用例整合到一個用例庫中。當涉及自動化時，人們會將用例庫轉換為一套可以反覆執行的測試套件。類比到在公園裏清理狗狗粑粑的示例中，測試套件就是在公園裏預先計劃好的行走路徑。由於是預先計劃好的，且無法做到完全測試，因此只能覆蓋相對較小的區域。故首次執行測試套件，可能得到的結果如圖 2-2 所示。

首次執行測試套件，可以發現幾個 bug。在之後的測試中，它會不斷地重複執行同樣的操作，具有高度的可重複性。與人的探索行為不同，一旦存在 bug，測試腳本就會被阻塞，無法執行。如果使用錄製 / 回放的方式實現測試自動化腳本，在功能正確運行之前，自動化腳本可能會被阻塞，甚至不能實現。例如添加購物車功能存在 bug，則自動化運行就會被暫停，直到 bug 被修復。故此種風格的自動化測試，唯一的價值在於迴歸測試。

修復完 bug 後，再次運行測試套件，結果如圖 2-3 所示。

從圖 2-3 中可以看到，已經修復了四個 bug，重複執行測試套件不會再發現新的 bug。故迴歸測試的價值在於，確保先前已修復的問題不會再次出現，以及已覆蓋的路徑上不會出現新 bug。如果可以跟蹤項目 bug 並統計迴歸測試中發現的 bug 量，你會發現迴歸測試所能發現的 bug 量佔比非常小。這也正是 Heusser關於（傳統，預定義）自動化測試的準則：100% 自動化測試團隊中，大多數 bug不是通過運行迴歸測試工具發現的，而是由人類執行其他活動（包括在創建自動化測試腳本時，被 bug 阻礙的活動）發現的。換言之，如果團隊致力於實現100% 的自動化測試，那麼大部分 bug 將會以低效、手工或偶然的方式發現。此時，就需要立刻停止這種不切實際的做法，轉而深入研究和改進測試方法，以提高測試的整體效率和質量。

Lisa Crispin 曾經對“100% 測試自動化”作出過寬泛且合理的解釋：這是一種策略，如果需要每次都遵循固定步驟，那麼這些操作應該交給計算機來執行，讓人力專注研究和探索可能只需要運行一次的事情，或者每次運行都略有不同。這種工作方式可以看作探索性測試，我們也曾採用類似的做法，即仔細考慮哪些測試適合自動化，哪些適合保持手工，然後只將一小部分真正需要在每次構建時運行的核心測試納入自動化測試套件。

至此，希望讀者可以對重複執行相同測試的做法持有適度的懷疑態度。下一節，將通過海戰棋遊戲，探討如何根據輸入空間的變化調整自動化測試策略。