對 End-to-End 測試說不

你是否還記得有那麼一部電影，你和你的朋友們都很想看，可是看過就後悔了。你是否還記得你的團隊發現了一個「殺手級特性」，發佈後看到的倒是隨之發佈的「炸彈」。

好的idea經常在實踐中失敗，而在測試的世界中，一個的好的idea經常在實踐中失敗，是由於測試策略是基於End-to-End的。

測試人員會花費時間寫各類自動化測試，包含單元測試、集成測試、和End-to-End測試，他們花費最多的時間在end-to-end測試上，將產品或者服務當作一個總體來進行測試。值得一提的是，這些測試模擬了真實的用戶場景。

理論上的 End-to-End 測試

雖然end-to-end並非一個好的實踐，可是不乏有人說在理論上他很是合理。

Google十大信條第一條：以用戶爲中心,其餘一切天然水到渠成。所以，end-to-end測試聚焦於真實用戶場景聽起來像是毫無問題的，這種策略也有贏得了不少支持者：

• 開發人員：能夠將幾乎全部測試工做都交給其餘人來作。

• 管理人員和決策者：模擬了真實用戶場景，能夠很直觀的看到測試失敗的影響。

• 測試人員：避免測試用例沒有驗證到真實的用戶行爲，而且給測試人員帶來了成就感。

實踐中的 End-to-End 測試

理論上這種測試策略簡直是完美的，在實踐中出了什麼問題呢？咱們從測試人員那裏蒐集到一些反饋。

咱們假定測試的基礎建設很是完善，天天晚上能夠作到：

• 軟件的最新版本構建完成

• 構建好的版本部署到測試環境

• 全部end-to-end測試用例在測試環境上運行

• 測試報告以郵件形式發送給團隊成員

整個團隊在爲了新特性的發佈忙碌着，轉眼間截止日期要到了。爲了確保產品的高質量，end-to-end測試用例至少要經過90%。離截止日期還有一天：

分析

儘管有很多問題，可是測試最終找到了真正的bug。

好處：在用戶使用以前，影響用戶體驗的bug被找出並被修復。

問題：

• 團隊里程碑推遲一週（伴隨着大量的加班）

• 定位一條失敗的測試用例很是痛苦，花費了大量的時間

• 團隊配合問題和環境問題屢次毀掉了測試結果

• 許多小的bug被隱藏在大的bug後面

• 測試有時候包含不肯定性

• bug修改後迴歸測試每每耗時較久，每每要次日才知道結果

找到了end-to-end策略的問題所在，接下來咱們須要改變測試策略來避免這些問題。那麼，正確的策略應該是什麼樣的？

測試的真正價值

通常來講，一旦用例執行失敗，測試人員的工做就結束了。記錄bug，而後開發人員解決bug。把end-to-end策略分解一下，咱們須要從「聚焦用戶」跳出來，想一想一條失敗的測試用例爲用戶帶來了什麼好處。答案在這裏：

測試用例失敗並不會直接讓用戶受益。

首先，不要被這個結論嚇到。一個產品被開發出來後，測試人員並不能左右它。那麼若是一條失敗的測試用例並不能讓用戶受益，那什麼才能讓用戶受益呢？

修復一個bug纔會直接讓用戶受益。

只有當軟件沒有bug用戶才能愉快的使用產品。要修復bug，你必須知道bug存在於哪裏。要知道bug存在於哪裏，須要測試來找出它（若是測試找不到bug，用戶必定會找到它）。可是，從用例執行失敗，到修復bug，在整個過程當中，最後一步纔是真正有價值的。

所以，要評估任何一個測試策略，不能只是評估它如何發現bug。還必須評估這種策略下，開發人員是如何 修復（防止）bug的。

構築有效的反饋機制

測試構築了一個反饋機制，這種機制影響這產品的運行。好的反饋機制有幾個特色：

• 快速：沒有哪一個開發人員想等待幾個小時來驗證新的改動是否是有bug。當出現bug的時候，須要運行屢次來複現。快速的反饋機制修復起bug來會快不少。若是機制足夠快，開發人員甚至能在每個改變後測試一次。

• 可靠：沒有哪一個開發人員想要花幾個小時去debug，而debug的緣由是由於一種不肯定的測試。不肯定的測試讓開發人員對測試不信任，致使一些測試結果直接被忽略，甚至這些結果中有一些是真正的產品問題。

• 隔離錯誤：要修復一個bug，開發人員須要找到引發bug的特定代碼行。若是一個產品擁有百萬行代碼，找bug無異於大海撈針。

從小處着手

咱們怎麼構建一個理想的反饋機制？從小處着手。

單元測試

單元測試能夠將產品中的一小塊進行隔離。這種方式能夠構建一個理想的反饋機制：

• 單元測試是快速的：測試被拆分爲一個個很小的單元，每一條測試甚至耗時不到0.1秒。

• 單元測試是可靠的：簡單的體系和小的單元帶來了可靠性。甚至能夠進行封閉測試，完全解決不肯定性問題。

• 單元測試隔離錯誤：即便產品擁有上百萬行代碼，若是測試不經過，只須要在一小塊代碼來找bug。

單元測試 vs. End-to-End測試

使用end-to-end測試，不得不等待：編譯 => 部署 => 執行測試。不肯定性又貫穿始終整個測試執行過程：即便發現了一個bug，bug可能存在於代碼的任何位置。

雖然end-to-end測試能更好的模擬用戶使用場景，然而相比於其帶來的問題，它帶來的好處變的並不那麼重要：

集成測試

單元測試有一個不足：即便獨立的單元一個個都運行良好，也沒法確保它們一塊兒運行的時候會不會出問題。但這並不意味着要立刻進行end-to-end測試，咱們須要的是一個集成測試。一個集成測試須要一組單元（一般是兩個）作爲一個總體，來測試它們的行爲。

若是兩個單元的集成有問題，寫一個更小、更聚焦的集成測試也會找到相同的bug，爲何要寫end-to-end測試呢？

測試金字塔

經過了單元測試和集成測試，就須要一些end-to-end測試將整個系統做爲一個總體來驗證。這三種測試之間的比例，能夠用一個測試金字塔來描述。如下是一個測試金字塔的簡圖：

單元測試位於金字塔底部。越往上測試規模變的越大，測試的數量越少。

Google建議的比例是"7:2:1"：單元測試佔70%，集成測試佔20%，end-to-end測試佔10%。不一樣的團隊比例會有些不一樣，可是總的來講，應該是一個金字塔形狀。儘可能避免這些不一樣的形狀：

• 倒金字塔：團隊主要依賴於end-to-end測試，有不多的集成測試，基本沒有單元你測試。

• 沙漏：團隊有大量的單元測試，在應該用集成測試的時候使用了end-to-end測試。沙漏型有不少單元測試和end-to-end測試，可是隻有不多的集成測試。

正如金字塔是最穩定的結構同樣，測試金字塔也是最靠譜的測試策略。

本文系TestBird測試工程師編譯整理。想了解更多開發測試相關信息，請訪問 TestBird。
原文地址：http://googletesting.blogspot...