測試左移是將關鍵的測試實踐移至開發(fā)生命周期的早期。這個術語尤其在敏捷，持續(xù)和DevOps計劃中找到。那么，為什么需要執(zhí)行早期軟件測試？
許多測試活動發(fā)生在周期的后期，需要花費更長的時間找出問題所在，并花費更多的修復成本。左移是關于將缺陷的識別和預防轉移到較早的階段。如果不這樣做，并在開發(fā)周期的稍后階段等待執(zhí)行測試實踐，則特別是非功能性業(yè)務需求（即安全性和性能測試）在代碼中已根深蒂固，以至于只能打補丁而不是正確地修復它們。
測試左移策略在Capers Jones的一些著名圖表中得到了很好的說明，該圖表顯示了在軟件開發(fā)的每個階段，引入到軟件中的錯誤/缺陷的成本不斷增加。圖表的第一部分顯示了預計大多數錯誤會在編碼階段進入。
無論他們是犯了實際的錯誤，還是誤解了需求，還是不考慮特定代碼的后果，開發(fā)人員都會在代碼生成時引入缺陷。
當需要將各個部分組合在一起時，缺陷也會引入到應用程序中，尤其是在涉及多個團隊的情況下（以及隨著微服務等現代體系結構變得更加復雜）。
何時發(fā)現這些錯誤？
如上圖，因為通常在開始測試時會發(fā)現錯誤，并且如果沒有適當的基礎架構就很難在一切準備就緒之前就開始進行測試。我們在這里看到的是，大多數錯誤是在編碼期間引入的，但在該階段幾乎沒有發(fā)現。
各階段修復bug成本
由于大多數錯誤是在編碼期間引入的，但直到下一個階段才被發(fā)現，因此了解在開發(fā)的每個階段修復缺陷所花費的差異就變得很重要。如下所示：
如上圖，越往后發(fā)現缺陷，成本就會急劇增加。讓錯誤潛入系統(tǒng)測試的成本是在編碼過程中發(fā)現該錯誤的成本的40倍，或比在單元測試期間發(fā)現該錯誤的成本高10倍。
成本上升的原因包括：
跟蹤問題所需的時間和精力。測試用例越復雜（越大），則更難定位具體問題的所在
由于引入了諸如數據庫或第三方API之類的相關系統(tǒng)，溝通成本較大。（在這種情況下，組織在缺陷檢測和缺陷修復之間通常要經歷數周的延遲，這是很常見的。）
修復缺陷所需的更改的影響。如果這是一個簡單的錯誤，那就沒關系了。但是，如果在很多地方都做過，或者使用了錯誤的框架，或者所構建的代碼的可伸縮性不足以承受預期的負載，或者無法確保安全性……
盡早測試、頻繁測試（測試左移）
現在，觀看下圖中添加的橙色線，它說明了基于較早測試（左移）的缺陷檢測周期：
可以看到橙色檢測曲線在越早發(fā)現，修復成本越低，這大大降低了我們的成本。
左移依賴于更成熟的開發(fā)實踐，例如基于軟件測試金字塔的開發(fā)實踐（開發(fā)人員創(chuàng)建了一組可以很好地覆蓋代碼的單元測試，而功能測試人員和API測試人員則盡其所能并最小化依靠后期測試，因此您只有足夠的手動/ UI測試來證明一切正常。這樣，后期測試就可以證明其功能，而不是發(fā)現錯誤。盡早測試，頻繁測試是左移的口頭禪。
測試左移
當進一步向左推動編碼本身時，將獲得更多價值。畢竟，這是引入錯誤的地方-因此，讓我們在開發(fā)仍在進行的同時開始介入測試。這是我們從靜態(tài)代碼分析中受益的地方-通過查找最左端的缺陷來修復缺陷，其中修復成本最低的缺陷是：
通過靜態(tài)分析，可以在實際的編碼階段開始尋找錯誤，這時發(fā)現錯誤的成本會盡可能地降低。
如上圖，在“測試”開始之前先找到缺陷是最劃算的。它也是最省時的，因為它不會給開發(fā)人員帶來嘗試重現錯誤或理解故障的任何問題。能夠將缺陷修復周期從數天或數周縮短到數小時或數分鐘，這是非常有用的。
測試左移不是增加開發(fā)工作量
測試左移偶然地給軟件開發(fā)人員帶來了過多的測試負擔。查看圖表時要記住的重要一點是，盡管隨著正確的選擇缺陷修復的成本急劇增加，但是左側的資源可能是軟件生命周期中成本最高的–這可能是使他開發(fā)人員不再專注于開發(fā)功能。
更早的發(fā)現問題是一方面，更重要的減少問題的數量，提升研發(fā)工程質量意識。
如何左移
靜態(tài)代碼掃描，單元測試，發(fā)現問題不是關鍵，關聯是在質量意識的生態(tài)閉環(huán)中，不斷減少存量問題，進而不斷減少問題的發(fā)生。
規(guī)范：編碼規(guī)范，數據規(guī)范、發(fā)布規(guī)范等
mock、第三方服務隔離
原文參考：https://www.parasoft.com/what-is-shift-left-testing/
聯系客服
