左移測試是一種軟件測試方法，其中將測試移至開發過程的早期階段，更接近開發階段。左移測試的目標是在開發周期中盡早發現并修復缺陷，從長遠來看可以節省時間和資源。

在軟件開發中更早地集成測試，可以更早地發現錯誤，加速反饋循環，并加快部署到生產環境的速度。

發布代碼的最佳途徑是什么？一個沒有尖峰、沒有滅火、沒有拼命急于添加快速功能以滿足企業客戶要求的流程？當一切正常時，該過程如下所示：

十年前，項目經理嘲笑軟件開發生命周期（SDLC）的瀑布式實現，其中階段是嚴格定義的，規劃階段的工作從不與開發重疊，測試只有在開發結束后才開始。這種固定的過程意味著發布頻率不高，并且需要很長時間才能獲得用戶反饋。瀑布特別不適合通過互聯網交付的軟件，在互聯網上，敏捷方法可以每天發布軟件，并在幾周內反映用戶的反饋。

雖然敏捷方法允許這些階段重疊并強調交付速度，但這些階段仍然是基于瀑布的，傳統的開發、構建和測試方法不太適合現代基于微服務的環境。

當今測試的兩個主要問題

盡管越來越多的工作負載正在遷移到微服務，但測試仍無法跟上現代開發需求。這里有兩個原因。

QA應該找到回歸，而不是回歸到瀑布時代

雖然敏捷方法與在線軟件交付的興起密切相關，但使瀑布流過時的另一個組成部分是質量保證 （QA） 的自動化和民主化。隨著自動化測試和 QA 與開發團隊的集成程度越來越高，測試等待開發完成是不尋常的?，F代流程定義了許多精細的測試等級，從單元測試到端到端測試，并在開發人員編寫代碼和連接服務時不斷提供反饋。

微服務在某種程度上打破了這種范式，重新打開了通往瀑布世界的大門。從廣義上講，問題是相互依存。微服務非常依賴其他服務，因此在部署服務并與我們的其他組件和第三方 API 交互之前，很難獲得準確的測試圖。通常，QA 或運營團隊是第一個發現微服務代碼嚴重問題的人。

這種破碎范式的結果是，反饋在周期的后期出現，需要將發布帶回開發的最初階段。雖然這有時會發生在代碼投入生產之后，但很多時候，測試的初始部署無法捕獲后期階段出現的問題，或者最終的金絲雀測試發現了應該在流程中更早出現的集成問題。真正的過程更像是這樣的：

針對這些問題提供的最常見解決方案是構建單元測試、存根和模擬來模擬所有其他組件，但這種策略很少完全成功。一個可以模擬復雜集群的測試套件要么要求QA對堆棧中的每個服務都非常復雜，要么每個團隊都愿意投入大量時間來維護其服務的測試并準確模擬其他服務。

測試對開發人員來說太慢了

當嘗試模擬整個集群進行測試時，結果慢得令人無法接受。由于您必須在測試環境中運行整個測試套件，因此可能需要 20 分鐘到幾個小時才能運行所有測試并獲得結果。即使是 10 或 20 分鐘也足夠長，開發人員不會坐下來等待所有測試在一天中運行幾次。人們普遍認為，開發人員不會經常運行集成測試，更新后的服務會與集群的其余部分一起工作;相反，他們會等待在部署生命周期的后期運行它。

由于許多錯誤是在部署周期的后期發現的，因此還有另一個流程問題讓人想起瀑布時代：當另一個團隊的工程師發現錯誤時，診斷、報告和修復問題的過程變得繁瑣。運營和 QA 工程師的任務是為每個集成問題提交錯誤報告，并要求開發人員在帶外修復問題。

左移以修復測試和開發

若要修復開發和測試代碼的過程，請左移：在周期的早期測試代碼，并直接向開發人員提供反饋。左移是一種文化和實踐的轉變，但也包括對共享測試環境設置方式的技術更改。

更頻繁地進行較小的更改

在理想的微服務 SDLC 中，重點是盡早且經常地集成測試，從開發階段開始。這種方法強調了小的增量代碼更改的重要性。通過將更改限制在范圍內，開發人員可以更輕松地理解和測試其修改的影響。這種粒度不僅加快了驗證過程，而且使測試更加精確。

在此模型中，開發人員擁有其代碼的開發和測試的所有權。這種所有權明確了責任，從一開始就將質量放在首位。該方法可以在工程團隊之間有效擴展，因為每個團隊或開發人員都可以獨立處理各自的服務或功能，從而減少依賴性。雖然這是一個很好的建議，但在當前的開發環境中實施起來可能很困難：如果將代碼發布到共享測試集群的過程花費了太多時間，那么測試小的增量更改似乎不可行。最好實現一個共享的測試環境，開發人員可以在其中測試一些小的更改。

獲得更快的反饋

該模型中的反饋循環速度很快。由于開發人員邊做邊測試，因此許多潛在問題會立即得到解決，通常是在它們被識別為傳統意義上的錯誤之前。作為用戶查找 bug 和作為開發人員查找 bug 之間的區別是巨大的：當運營或站點可靠性工程師 （SRE） 發現問題時，他們需要找到發布代碼的工程師，描述他們看到的問題，并提供一些步驟來復制問題。相反，如果原始開發人員發現了問題，他們可以通過查看輸出、找到原因并開始修復來減少所有這些步驟。這種主動的質量方法減少了在開發周期后期需要歸檔和解決的錯誤數量。

從文化上講，這種 SDLC 模型培養了一種 CI/CD 文化，在這種文化中，代碼更改可以快速可靠地集成、測試和交付。這不僅加快了開發過程，還提高了軟件的整體質量。盡管 CI 意味著“持續集成”，但在微服務的上下文中，CI 工具以最佳方式提供持續測試，讓開發人員盡早了解他們在嘗試部署微服務代碼時將面臨的實際問題。

測試空間集成

集成用于預覽代碼更改的系統是一個關鍵組件，因為它允許即時反饋更改在實時環境中的行為方式。此類預覽對于開發人員以及其他利益相關者（如項目經理和 QA 團隊）來說非常寶貴。技術挑戰是巨大的，而且沒有“插入式”解決方案來創建一個非常準確的生產副本，每個開發人員都可以測試頻繁的更改。

簡而言之，任何此類系統的基本要求是：

• 生產環境的真實副本，包含所有必需的依賴項和由其他團隊維護的許多微服務。
• 將新的小型代碼更改部署到此共享環境的簡單方法。
• 一種防止沖突的方法，以便部署到服務的實驗性代碼不會中斷其他開發人員的群集性能。

通常，承諾僅在需要測試時才建立整個集群副本的解決方案并不令人滿意。相反，開發人員需要進行小的增量更改，有時一天部署不止一次。一旦事情變得非常復雜，建立整個集群所需的時間將抑制左移的目標。

請求左移隔離

面向開發人員的快速準確的測試環境必須是 Kubernetes 空間的原生環境，以便動態地允許在使用運行生產環境的系統的共享集群中進行更新和測試。許多大型企業團隊已經實現了一種稱為請求隔離的模型，該模型允許測試服務作為集群的一部分運行，而不會中斷其他服務。包括 Uber 和 netflix 在內的團隊可以推出服務的測試版本，甚至可以推送到生產環境，該版本只能處理測試請求，但仍然可以向它所依賴的所有其他服務發出請求。

netflix 允許開發團隊在其集群上使用請求隔離技術。通過利用服務網格，工程團隊可以僅將測試請求定向到其服務的更新版本。使用測試版本更新服務時，服務的基本版本仍可供其他團隊使用，因此他們可以使用相同的測試群集。

結果使團隊能夠進行小的增量更改，并針對實際集群進行測試。開發人員自己發現問題，大大縮短了反饋時間并加快了開發速度。