左移測試是一種軟件測試方法，其中將測試移至開發(fā)過程的早期階段，更接近開發(fā)階段。左移測試的目標(biāo)是在開發(fā)周期中盡早發(fā)現(xiàn)并修復(fù)缺陷，從長遠(yuǎn)來看可以節(jié)省時間和資源。

在軟件開發(fā)中更早地集成測試，可以更早地發(fā)現(xiàn)錯誤，加速反饋循環(huán)，并加快部署到生產(chǎn)環(huán)境的速度。

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

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

雖然敏捷方法允許這些階段重疊并強調(diào)交付速度，但這些階段仍然是基于瀑布的，傳統(tǒng)的開發(fā)、構(gòu)建和測試方法不太適合現(xiàn)代基于微服務(wù)的環(huán)境。

當(dāng)今測試的兩個主要問題

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

QA應(yīng)該找到回歸，而不是回歸到瀑布時代

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

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

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

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

測試對開發(fā)人員來說太慢了

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

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

左移以修復(fù)測試和開發(fā)

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

更頻繁地進(jìn)行較小的更改

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

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

獲得更快的反饋

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

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

測試空間集成

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

簡而言之，任何此類系統(tǒng)的基本要求是：

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

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

請求左移隔離

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

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

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