只是拒絕更多的端到端測試

通常，測試人員的工作在測試失敗後即告結束。提交了乙個錯誤，然後是開發人員修復錯誤的工作。然而，為了確定端到端戰略失敗的地方，我們需要在這個框外思考並從第一原則出發解決問題。如果我們「專注於使用者（以及其他所有人都會關注），」我們必須問自己，失敗的測試如何使使用者受益。答案如下：

失敗的測試不會直接使使用者受益。

雖然這個說法起初看起來很震撼，但事實確實如此。如果產品有效，它是否有效，無論測試是否有效。如果產品壞了，它會被破壞，無論測試是否破壞了。因此，如果測試失敗不會使使用者受益，那麼使用者有什麼好處呢？

錯誤修復直接使使用者受益。

只有當意外行為（錯誤）消失時，使用者才會感到高興。顯然，要修復錯誤，您必須知道錯誤存在。要知道存在的錯誤，理想情況下，您有乙個捕獲錯誤的測試（因為如果測試沒有，使用者將找到錯誤）。但是在整個過程中，從失敗的測試到錯誤修復，只在最後一步新增了值。

階段失敗的測試

錯誤已開啟

錯誤修復

增值沒有沒有是

因此，要評估任何測試策略，您不能只評估它如何發現錯誤。您還必須評估它如何使開發人員能夠修復（甚至防止）錯誤。

測試建立乙個反饋迴圈，通知開發人員產品是否正常工作。理想的反饋迴路有幾個屬性：

那麼我們如何建立理想的反饋迴圈呢？通過思考更小，而不是更大。

單元測試只需要一小部分產品並單獨測試該部件。他們傾向於建立理想的反饋迴圈：

編寫有效的單元測試需要依賴管理，模擬和密封測試等領域的技能。我不會在這裡介紹這些技能，但作為乙個開始，為新google員工（或nooglers）提供的典型示例是google如何構建和測試秒錶。

使用端到端測試，您必須等待：首先構建整個產品，然後部署，最後執行所有端到端測試。當測試執行時，片狀測試往往是生活中的事實。即使測試發現了乙個錯誤，該錯誤也可能出現在產品的任何地方。

雖然端到端測試在模擬真實使用者場景方面做得更好，但端到端反饋迴圈的所有缺點很快就會超過這一優勢：

單元端到端快速

隔離失敗

模擬真實使用者

單元測試確實有乙個主要缺點：即使單元在隔離狀態下工作良好，也不知道它們是否能很好地協同工作。但即便如此，您也不一定需要端到端測試。為此，您可以使用整合測試。整合測試需要一小組單元，通常是兩個單元，並測試它們的整體行為，驗證它們是否一致地協同工作。

如果兩個單元沒有正確整合，為什麼要編寫乙個更小，更集中的整合測試來檢測相同的bug時編寫端到端測試？雖然您確實需要更大的思考，但您只需要考慮更大一點來驗證單元是否協同工作。

即使使用單元測試和整合測試，您仍可能需要少量的端到端測試來驗證整個系統。要在所有三種測試型別之間找到適當的平衡點，最好的視覺輔助工具是測試金字塔。以下是2023年google測試自動化大會開幕主題演講中測試金字塔的簡化版本：

大部分測試都是金字塔底部的單元測試。當您向上移動金字塔時，您的測試會變大，但同時測試次數（金字塔的寬度）會變小。

作為乙個良好的初步猜測，谷歌經常建議70/20/10拆分：70％的單元測試，20％的整合測試和10％的端到端測試。每個團隊的確切組合會有所不同，但總的來說，它應保留金字塔形狀。盡量避免這些反模式：

就像常規金字塔往往是現實生活中最穩定的結構一樣，測試金字塔也往往是最穩定的測試策略。

**：