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

左移測試方法

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

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

錯誤何時輸入代碼？

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

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

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

何時發(fā)現(xiàn)這些錯誤？

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

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

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

修復錯誤要花多少錢？

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

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

成本上升的原因包括：

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

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

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

盡早測試，經(jīng)常測試（左移方法）

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

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

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

向左移動

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

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

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

謹防只是將負擔轉移給開發(fā)人員

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

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

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

那你怎么左移呢？

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

應用開發(fā)測試最佳實踐

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

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

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

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

利用服務虛擬化實現(xiàn)連續(xù)測試

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

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

在性能測試方面，服務虛擬化使您可以在一切準備就緒之前進行測試，而無需對系統(tǒng)中的所有內容進行完整的實驗。您甚至可以運行各種假設分析場景，例如，如果應用服務器運行速度快而數(shù)據(jù)庫運行緩慢（在現(xiàn)實世界中很難實現(xiàn)），該怎么辦?；蛘撸绻业姆掌鏖_始拋出一些有趣的錯誤，例如500錯誤，那將如何影響系統(tǒng)性能呢？

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

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

總結

經(jīng)過數(shù)十年實踐證明有效的質量保證流程可用于顯著提高質量，同時節(jié)省時間和金錢。

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