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

左移測(cè)試方法

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

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

錯(cuò)誤何時(shí)輸入代碼？

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

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

當(dāng)需要將各個(gè)部分組合在一起時(shí)，缺陷也會(huì)引入到應(yīng)用程序中，尤其是在涉及多個(gè)團(tuán)隊(duì)的情況下（以及隨著微服務(wù)之類的現(xiàn)代體系結(jié)構(gòu)變得更加復(fù)雜）。

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

當(dāng)我們?cè)谒氲腻e(cuò)誤圖表上方覆蓋顯示缺陷所在位置的線時(shí)，它開始變得有趣起來(lái)。

請(qǐng)注意，它基本上與第一行相反：

當(dāng)然，這并不奇怪，因?yàn)橥ǔＴ陂_始測(cè)試時(shí)就會(huì)發(fā)現(xiàn)錯(cuò)誤，并且如果沒(méi)有適當(dāng)?shù)幕A(chǔ)架構(gòu)就很難在一切準(zhǔn)備就緒之前就開始進(jìn)行測(cè)試（稍后會(huì)進(jìn)行更多介紹）。我們?cè)谶@里看到的是，大多數(shù)錯(cuò)誤是在編碼過(guò)程中引入的，但在該階段幾乎沒(méi)有發(fā)現(xiàn)。

修復(fù)錯(cuò)誤要花多少錢？

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

現(xiàn)在，它開始變得非常有趣，因?yàn)槲覀兛吹搅肆钊擞憛挼?成本進(jìn)步，一旦發(fā)現(xiàn)缺陷，成本就會(huì)急劇增加。讓錯(cuò)誤潛入系統(tǒng)測(cè)試的成本是在編碼期間發(fā)現(xiàn)該錯(cuò)誤的成本的40倍，或者比在單元測(cè)試期間發(fā)現(xiàn)該錯(cuò)誤的成本高10倍。當(dāng)您查看讓錯(cuò)誤滲透到實(shí)際部署中的數(shù)量時(shí)，它的成本簡(jiǎn)直荒唐可笑。

成本上升的原因包括：

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

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

• 修復(fù)缺陷所需的更改的影響。如果是簡(jiǎn)單的錯(cuò)誤，那就沒(méi)關(guān)系了。但是，如果您在很多地方都做過(guò)，或者使用了錯(cuò)誤的框架，或者所構(gòu)建的代碼的可伸縮性不足以承受預(yù)期的負(fù)載，或者無(wú)法確保代碼的安全性……

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

現(xiàn)在，觀看下圖中添加的橙色線，因?yàn)樗f(shuō)明了基于較早測(cè)試（左移）的建議的缺陷檢測(cè)周期：

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

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

向左移動(dòng)

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

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

正如您可以清楚地看到的那樣，在“測(cè)試”開始之前先找到東西是最劃算的。這也是最省時(shí)的方法，因?yàn)樗粫?huì)使開發(fā)人員在嘗試重現(xiàn)錯(cuò)誤或理解故障方面有任何問(wèn)題。能夠?qū)⑷毕菪迯?fù)周期從數(shù)天或數(shù)周縮短到數(shù)小時(shí)或數(shù)分鐘，這是非常有用的。

謹(jǐn)防只是將負(fù)擔(dān)轉(zhuǎn)移給開發(fā)人員

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

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

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

那你怎么左移呢？

好的，這是我們?cè)?/span>Parasoft所做的一切工作的核心。但是為了簡(jiǎn)潔起見(jiàn)，左移測(cè)試方法分為兩個(gè)主要活動(dòng)。

應(yīng)用開發(fā)測(cè)試最佳實(shí)踐

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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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