您越早發現代碼中的問題，其影響就越小。處理它們的成本也更低。在此文中，我們探討了左移方法以及如何在組織中進行左移。

左移測試方法

向“左移”的方向是將關鍵的測試實踐移至開發生命周期的早期。這個術語尤其在敏捷、持續和DevOps計劃中找到。那么，為什么需要執行早期軟件測試？

許多測試活動發生在周期的后期，需要花費更長的時間找出問題所在，并花費更多的修復成本。左移是關于將缺陷的識別和預防移到較早。如果您不這樣做，并在開發周期的稍后階段等待執行測試實踐，則特別是非功能性業務需求（即安全性和性能測試）在代碼中已根深蒂固，以至于您只能打補丁而不是正確地修復它們。

錯誤何時輸入代碼？

左移測試策略在Capers Jones的一些著名圖表中得到了很好的說明，該圖表顯示了在軟件開發的每個階段，引入到軟件中的錯誤/缺陷的成本不斷增加。圖表的第一部分顯示了大部分錯誤是在編碼階段出現的，這是可以預料的。

無論他們是犯了實際的錯誤，還是誤解了要求，還是不考慮特定代碼的后果，開發人員都會在代碼生成時引入缺陷。

當需要將各個部分組合在一起時，缺陷也會引入到應用程序中，尤其是在涉及多個團隊的情況下（以及隨著微服務之類的現代體系結構變得更加復雜）。

何時發現這些錯誤？

當我們在所引入的錯誤圖表上方覆蓋顯示缺陷所在位置的線時，它開始變得有趣起來。

請注意，它基本上與第一行相反：

當然，這并不奇怪，因為通常在開始測試時就會發現錯誤，并且如果沒有適當的基礎架構就很難在一切準備就緒之前就開始進行測試（稍后會進行更多介紹）。我們在這里看到的是，大多數錯誤是在編碼過程中引入的，但在該階段幾乎沒有發現。

修復錯誤要花多少錢？

由于大多數錯誤是在編碼過程中引入的，但直到下一個階段才被發現，因此了解每個開發階段修復缺陷所花費的差異就變得很重要。如下所示：

現在，它開始變得非常有趣，因為我們看到了令人討厭的成本進步，一旦發現缺陷，成本就會急劇增加。讓錯誤潛入系統測試的成本是在編碼期間發現該錯誤的成本的40倍，或者比在單元測試期間發現該錯誤的成本高10倍。當您查看讓錯誤滲透到實際部署中的數量時，它的成本簡直荒唐可笑。

成本上升的原因包括：

• 跟蹤問題所需的時間和精力。測試用例越復雜（越大），就越難確定其中哪一部分是真正的麻煩制造者。

• 由于引入了諸如數據庫或第三方API之類的從屬系統，在開發人員的桌面上再現缺陷的挑戰。（在這種情況下，組織在缺陷檢測和缺陷修復之間經歷數周的延遲是很常見的。）

• 修復缺陷所需的更改的影響。如果是簡單的錯誤，那就沒關系了。但是，如果您在很多地方都做過，或者使用了錯誤的框架，或者所構建的代碼的可伸縮性不足以承受預期的負載，或者無法確保代碼的安全性……

盡早測試，經常測試（左移方法）

現在，觀看下圖中添加的橙色線，因為它說明了基于較早測試（左移）的建議的缺陷檢測周期：

您可以看到橙色檢測曲線在便宜的一面變大了，而在昂貴的一面變小了，這大大降低了我們的成本。

左移依賴于更成熟的開發實踐，例如基于軟件測試金字塔的開發實踐（開發人員創建了一組可以很好地覆蓋代碼的單元測試，而功能測試人員和API測試人員則盡其所能并最小化依靠后期測試，因此您只有足夠的手動/UI測試來證明一切正常。這樣，后期測試就可以證明其功能，而不是發現錯誤。盡早測試，經常測試是左移的口頭禪。

向左移動

一些向左移動的組織此時停止。但是當您進一步向左推動編碼本身時，您將獲得更多價值。畢竟，這是引入錯誤的地方——因此，讓我們在開發仍在進行的同時開始尋找它們。這是我們從靜態代碼分析中受益的地方-通過查找最左端的缺陷來修復缺陷，其中最便宜的缺陷是：

通過靜態分析，您可以在實際的編碼階段開始尋找錯誤，這時發現錯誤的成本會盡可能地降低。

正如您可以清楚地看到的那樣，在“測試”開始之前先找到東西是最劃算的。這也是最省時的方法，因為它不會使開發人員在嘗試重現錯誤或理解故障方面有任何問題。能夠將缺陷修復周期從數天或數周縮短到數小時或數分鐘，這是非常有用的。

謹防只是將負擔轉移給開發人員

但是此步驟存在一個危險，即偶然地給軟件開發人員帶來了過多的測試負擔。查看圖表時要記住的重要一點是，盡管隨著正確的選擇缺陷修復的成本急劇增加，但是左側的資源可能是軟件生命周期中成本最高的–更不用說您使他們不再專注于開發功能。

因此，您必須做正確的事，并將所有這些提升到一個新的水平。您不只是想早發現缺陷，實際上還想減少要放在應用程序中的缺陷數量。參見下圖，左側氣泡減少了。

但是，等等，有一個陷阱！如果您因發現和修復錯誤而獎勵別人，現在他們會發現的數量更少，這實際上是您想要的，但前提是您確實減少了最初要引入的錯誤的數量。測量進入現場的缺陷數量可能是一個更有用的指標。

那你怎么左移呢？

好的，這是我們在Parasoft所做的一切工作的核心。但是為了簡潔起見，左移測試方法分為兩個主要活動。

應用開發測試最佳實踐

進行早期階段的開發實踐，例如靜態代碼分析和單元測試，有助于在過程中盡早發現并防止缺陷。

重要的是要記住，目標不是查找錯誤，而是減少錯誤的數量（尤其是那些已發布的錯誤）。最終，與發現更多的bug相比，首先創建更少的bug有價值得多，而且價格便宜得多。因此，通過標記可能“有效”但仍不安全的代碼，采用一種主動預防性方法來制定安全關鍵代碼標準。

編碼標準是等同于工程標準的軟件，它們對于減少錯誤數量（除了更早發現錯誤），支持和從左移計劃中獲得最大價值至關重要。編碼標準是軟件工程知識的體現，可以幫助您避免錯誤/危險/不安全的代碼。要使用它們，您需要應用靜態代碼分析。

為了軟件安全，這對于成功強化軟件尤為重要。您想在代碼中構建安全性，而不是對其進行測試。編碼標準可讓您從一開始就構建更安全的應用程序（即通過設計確保安全性），這是一個好主意，并且如果您受制于諸如以下法規之類的要求GDPR。

利用服務虛擬化實現連續測試

接下來，您必須接受在開發過程的所有階段（包括后期）創建的測試，并不斷進行下去。這對于采用敏捷開發實踐以在整個開發過程中提供連續反饋的團隊來說至關重要。單元測試可以輕松地連續執行，但是由于外部系統的依賴性，通常很難將后期功能測試的執行轉移到左手，在這里您可以利用服務虛擬化來進行連續測試。

通過服務虛擬化，您可以模擬可用性可能有限的依賴系統，例如大型機、訪問費、第三方服務或可能尚未準備就緒的系統。通過模擬它們，您可以在沒有整個系統可用的情況下執行功能測試，并且可以將測試執行完全轉移到開發桌面。

在性能測試方面，服務虛擬化使您可以在一切準備就緒之前進行測試，而無需對系統中的所有內容進行完整的實驗。您甚至可以運行各種假設分析場景，例如，如果應用服務器運行速度快而數據庫運行緩慢（在現實世界中很難實現），該怎么辦。或者，如果我的服務器開始拋出一些有趣的錯誤，例如500錯誤，那將如何影響系統性能呢？

您可以隨心所欲地推動系統運行，并盡早實施。（了解有關如何左移性能測試的更多信息。）

同樣，您可以更早地開始進行安全測試。與物理系統解耦使您可以做一些更有趣的事情，這就是使模擬系統以邪惡的方式運行。現在，您可以真正進行安全測試了……您不僅可以在系統上查看受污染的數據和DDoS，還可以使系統充滿數據包，發送格式錯誤的數據或攻擊者常用的許多其他利用方法。因此，不僅可以進行更早的測試（左），而且還可以比測試實驗室或生產系統進行更深入的測試。

總結

經過數十年實踐證明有效的質量保證流程可用于顯著提高質量，同時節省時間和金錢。

當您利用現代軟件測試技術向左移動時，您可以獲得安全、可靠和保障的軟件。通過將測試向左移動，您可以通過在價格便宜的情況下盡早發現錯誤來降低測試成本，同時還可以減少首先放入代碼中的錯誤數量。