模板
教程
環(huán)境
性能
功能
管理
Google測試工程師日常工作：構建基礎設施才是重點(diǎn)(2)
幾年前，我加入了一個(gè)工程項目組，主要任務(wù)是開(kāi)發(fā)一個(gè)新系統替換舊系統。因為構建替換過(guò)程需要幾年，我們需要保持舊系統正常運行，甚至在舊系統上添加新功能，同時(shí)慢慢替換為新系統，這樣才不會(huì )影響用戶(hù)使用。
然而舊的系統是如此復雜和脆弱，工程師要花費大部分時(shí)間來(lái)分類(lèi)并修復 bug 及進(jìn)行相關(guān)測試，以至于沒(méi)有時(shí)間實(shí)現新系統。新系統的目標是實(shí)現所有老系統功能的基礎上，并使之更容易維護且擴展性更好。作為團隊的 TE，我的工作是了解高維護成本的成因及如何改進(jìn)。
我發(fā)現兩個(gè)主要問(wèn)題：
-
端到端測試的基礎設施沒(méi)有機制提供創(chuàng )建和注入 mock 服務(wù)的方法。因此，測試必須為所有這些外部依賴(lài)關(guān)系啟動(dòng)大量服務(wù)器。這導致了測試的工作量很大并且很脆弱，現有的基礎設施無(wú)法可靠地處理這一問(wèn)題。
解決方案
首先，我嘗試將大測試分成更小的測試的可能性，小測試可以聚焦特定幾個(gè)功能，并減少依賴(lài)服務(wù)的數量。但是，在結構不良的舊系統代碼中，發(fā)現這個(gè)想法是不可能的，如果要按這種方法工作將需要重構整個(gè)系統及其依賴(lài)項，這不僅僅是測試團隊可以完成的工作。
第二種方法，我嘗試進(jìn)行大的測試，并試圖將非測試的功能的調用進(jìn)行 mock。這最終證明也是非常困難的，因為依賴(lài)經(jīng)常改變，并且單個(gè)依賴(lài)很難在 200 多個(gè)服務(wù)中進(jìn)行追蹤。最終，這種方法只是將所需的工作從維護測試代碼轉移到模擬和維護測試依賴(lài)。
我的第三個(gè)也是最后一個(gè)方法，如下圖所示：使小測試用例更加強大。在我們面臨的典型的端到端測試中，客戶(hù)端對幾個(gè)服務(wù)進(jìn)行了 RPC 調用，這些服務(wù)又 RPC 調用了其他依賴(lài)服務(wù)?？蛻?hù)端和所有后端服務(wù)的調用閉包一起形成了一個(gè)大的依賴(lài)圖（而不是樹(shù)?。?，這一切都必須在端到端測試中運行。
新模型改變了我們如何對客戶(hù)端和服務(wù)端進(jìn)行測試，僅運行客戶(hù)端來(lái)執行幾個(gè) RPC 調用，然后觀(guān)察相關(guān)依賴(lài)調用是否正常的做法不太適合，我們對 RPC stub 的代碼編寫(xiě)單元測試，Stub 本身是用一個(gè)常見(jiàn)的模擬框架（如 Java 中的 Mockito）來(lái)完成的。
原文轉自：https://www.testwo.com/article/891
