摘要：

你越早發(fā)現(xiàn)你代碼里的問題，它們的影響越小并且花越低的成本去修復(fù)它們。因此，它有助于更早地在軟件開發(fā)生命周期中推動(dòng)測試活動(dòng)——在流程時(shí)間軸上左移。這篇文章探索了左移方法，并告訴你在你的組織中如何著手左移。

敏捷和開發(fā)運(yùn)營團(tuán)隊(duì)對左移的混戰(zhàn)是關(guān)于更早地在開發(fā)生命周期里移動(dòng)關(guān)鍵的測試活動(dòng)。

很多測試活動(dòng)在周期里發(fā)生得晚，它花費(fèi)了更多的時(shí)間去定位問題，更多的成本去修復(fù)它們。當(dāng)你在開發(fā)周期之后等待實(shí)施測試活動(dòng)，特別你的非功能業(yè)務(wù)需求，比如安全和性能測試，如此基本地根深蒂固在你的代碼里，以至于你實(shí)際能做的是給它們打補(bǔ)丁而不是恰當(dāng)?shù)匦迯?fù)它們。

左移是關(guān)于更快地做這種識(shí)別和預(yù)防缺陷。

發(fā)現(xiàn)并修復(fù)軟件缺陷

左移的測試策略可以很好地以卡柏斯?瓊斯的有點(diǎn)出名的圖表表格做闡釋，下面展示了當(dāng)問題和缺陷被引入到軟件開發(fā)每個(gè)階段的軟件中，它們的增加成本。

?

圖表顯示的第一部分指明了絕大部分代碼缺陷在編碼周期引進(jìn)的，可以是預(yù)料之中的。

他們是否犯錯(cuò)誤、誤解需求，或者沒有通過特別的代碼塊的分支去考慮，當(dāng)代碼被生成時(shí)開發(fā)引入缺陷。當(dāng)一起結(jié)合代碼塊的時(shí)候，缺陷也被引進(jìn)應(yīng)用程序，特別是如果涉及多個(gè)團(tuán)隊(duì)成員（并且就像現(xiàn)代架構(gòu)比如微服務(wù)變得更復(fù)雜時(shí)）。

現(xiàn)在讓我們疊加上相同的圖，順著線，展示出被發(fā)現(xiàn)的缺陷。注意從根本上它是第一條線的倒轉(zhuǎn)：

?

這也不奇怪，因?yàn)榈湫偷禺?dāng)你開始測試時(shí)你發(fā)現(xiàn)了bug，并且在一切準(zhǔn)備就緒前沒有一個(gè)合適的基礎(chǔ)結(jié)構(gòu)開始測試，結(jié)果會(huì)是不同的。

但是我們在這里也能看到當(dāng)問題大多數(shù)在編碼過程中被引進(jìn)，它們幾乎沒有在那個(gè)階段被發(fā)現(xiàn)。它需要什么成本去修復(fù)這些問題呢？

理解在每一個(gè)開發(fā)階段去修復(fù)缺陷的成本的不同變得重要。這以第三條線為代表：

?

現(xiàn)在它開始變得真正地有意思，當(dāng)我們看到一個(gè)令人不快的回歸成本在缺陷被發(fā)現(xiàn)之后急劇地增加。讓一個(gè)問題通過系統(tǒng)測試遺漏會(huì)是在編碼期間找到它們的成本的40倍，或者在單元測試期間找到相同問題的10倍多。而且當(dāng)你看到讓問題在真正的部署中滑走的數(shù)目時(shí)它會(huì)變得荒唐的昂貴。

成本的逐步上升有一些原因：

• ·花費(fèi)在查到問題的時(shí)間和努力。測試用例越復(fù)雜，查找出它真正的問題搗亂者在哪個(gè)部分就越困難。
• ·在開發(fā)的桌面重新產(chǎn)生缺陷的挑戰(zhàn)被引進(jìn)如獨(dú)立的系統(tǒng)，像數(shù)據(jù)庫或者第三方的應(yīng)用程序接口。（對組織來講，這些情況下在缺陷探測和缺陷修復(fù)之間經(jīng)歷滯后幾個(gè)星期是常見的。）
• ·變化的影響是需要修復(fù)一個(gè)缺陷。如果它是一個(gè)簡單的問題，那不會(huì)關(guān)系很大，但是如果在很多地方有它，你使用了錯(cuò)誤的架構(gòu)，或者你構(gòu)建了對期望的壓力或者不能夠保證安全性的不可擴(kuò)展的代碼，它會(huì)是一個(gè)更大的問題。

左移背后的原因

現(xiàn)在看著以下圖表上橙色的線，因?yàn)樗忉屃艘粋€(gè)推遲的缺陷探測循環(huán)是在早期的測試基礎(chǔ)上。你可以看到橙色的缺陷在低廉的一邊增長地更快而且在昂貴的一邊增長地更慢些，這給我們一個(gè)很重要的成本降低情況：

?

這個(gè)左移依賴于更多成熟的開發(fā)實(shí)踐，比如一個(gè)基于軟件測試金字塔?——開發(fā)們創(chuàng)建了一系列的很好地合理覆蓋代碼的單元測試，并且功能測試者們和應(yīng)用程序接口測試者們盡他們所能而且最小化地依賴于晚循環(huán)測試，所以你正好有足夠的人工和用戶界面測試去改善每一個(gè)正在運(yùn)行的東西。這種方式，晚循環(huán)測試是為了改善功能性，不是去發(fā)現(xiàn)問題。“早測試，常測試”是這個(gè)左移團(tuán)隊(duì)的口頭禪。

一些組織在這一點(diǎn)上停止了。但是當(dāng)你更深入地推進(jìn)左移、融入編碼本身時(shí)，你會(huì)得到更多的價(jià)值。畢竟這是代碼被引進(jìn)的地方，所以讓我們開始在開發(fā)仍然工作時(shí)候查找它們。

這就是我們從靜態(tài)的代碼分析中獲益的地方。當(dāng)找問題的成本盡可能的低時(shí)，你可以在實(shí)際的編碼階段開始找問題。

在測試開始前找問題不僅是成本上最有效的，而且也是時(shí)間上最有效的，因?yàn)樗]有以任何一件嘗試重現(xiàn)產(chǎn)生問題或者理解失敗的事離開開發(fā)。有能力從數(shù)天或數(shù)周到數(shù)小時(shí)或數(shù)分鐘縮小缺陷修復(fù)循環(huán)是非常巨大的幫助。?

分析左移方法

這樣，你如何左移呢？為了簡潔起見，左移測試方法分解成兩個(gè)主要的活動(dòng)：提供開發(fā)和測試最佳實(shí)踐，借力服務(wù)虛擬化以確保持續(xù)性測試。

做更早階段的開發(fā)實(shí)踐，比如靜態(tài)代碼分析和單元測試，有助于你在這個(gè)流程中更早地識(shí)別和防止缺陷。重要的是記住找問題不是目標(biāo)，而是減少問題的數(shù)量，尤其是那些趕上發(fā)布的。最后，首先制造更少的問題比找更多的問題還有價(jià)值得多——并且它更低廉得多。看以下的圖表，在左邊有個(gè)可愛的減少的泡泡。

?

???編碼標(biāo)準(zhǔn)是軟件工程標(biāo)準(zhǔn)的等價(jià)物，而且它們是減少問題容量（除更早地找到問題外）的鑰匙，并且從你的左移活動(dòng)中獲得更多的價(jià)值。編碼標(biāo)準(zhǔn)幫助你避免壞的、危險(xiǎn)的或者是不安全的通過靜態(tài)代碼分析的代碼。

為了軟件的安全性，尤其重要的是加強(qiáng)你的軟件。你想要在你的代碼里創(chuàng)建安全性，而不是測試它。代碼標(biāo)準(zhǔn)讓你從開始去構(gòu)建一個(gè)更安全的應(yīng)用（比如通過設(shè)計(jì)使它安全），這既是一個(gè)好的想法也是一個(gè)需求，如果你服從于比如通用數(shù)據(jù)保護(hù)條例的規(guī)則。

接下來，你必須執(zhí)行在所有開發(fā)流程階段的測試，包括晚期，并持續(xù)向前地執(zhí)行它們。對團(tuán)隊(duì)來講重要的是在開發(fā)流程的自始至終采取敏捷開發(fā)實(shí)踐去提供持續(xù)的反饋。單元測試能簡單地被持續(xù)執(zhí)行但是晚期功能測試執(zhí)行的左移通常很困難，因?yàn)橥獠肯到y(tǒng)獨(dú)立性。這就是你能借力服務(wù)虛擬化使能夠持續(xù)測試的地方。

服務(wù)虛擬化使你能夠模擬可能有限能力的獨(dú)立系統(tǒng)，比如主機(jī)、第三方服務(wù)，或者可能還沒有準(zhǔn)備好的系統(tǒng)。通過模擬它們，你可以在還沒有完整系統(tǒng)可用時(shí)執(zhí)行功能測試，并且你能一直在桌面端開發(fā)中左移測試執(zhí)行。

在性能測試的術(shù)語里，服務(wù)虛擬化使你能夠在每件事都準(zhǔn)備好之前測試，并且不用有一個(gè)每一東西都在系統(tǒng)里的完整的實(shí)驗(yàn)室。你甚至可以運(yùn)行所有種類的“什么——假如”場景，就像假如智慧云快而數(shù)據(jù)庫慢（在真實(shí)世界里很難發(fā)生的一些事）運(yùn)行什么？或者我的服務(wù)器開始拋出可笑的錯(cuò)誤，就像500錯(cuò)誤——那將會(huì)如何影響系統(tǒng)的性能？你可以隨你喜歡并超越地推動(dòng)你的系統(tǒng)堅(jiān)固，而且盡可能早地做這個(gè)。

類似地，你可以更早地開始你的安全測試。從物理系統(tǒng)中去耦合允許你做甚至更有趣的一些事：使仿真的系統(tǒng)以一個(gè)惡魔的方式行動(dòng)。代替只為污染的數(shù)據(jù)捅你的系統(tǒng)和分布式拒絕服務(wù)攻擊，你可以有一個(gè)充滿包、發(fā)送有缺陷的數(shù)據(jù)的系統(tǒng)，或者很多其他普遍被攻擊者使用的漏洞。所以你不僅可以測試地更早，你還能測試地可能比一個(gè)測試實(shí)驗(yàn)或產(chǎn)品系統(tǒng)更深入。

避免錯(cuò)誤和陷阱

在轉(zhuǎn)移到代碼階段進(jìn)行缺陷檢查的一個(gè)危險(xiǎn)是意外地在軟件開發(fā)者們身上放太多測試負(fù)擔(dān)。當(dāng)你看圖表時(shí)需要記住的重要的事情是當(dāng)你向右去時(shí)缺陷修復(fù)的成本變得大幅高，在左邊的資源可能在任一軟件生命周期里有最高的成本——更不用說你正在把他們從專注于開發(fā)功能性中抽走。

你不僅想要更早地找到問題，你想要減少你首先放進(jìn)程序里的缺陷的數(shù)量。

而且那有另一個(gè)陷阱：假如你正在獎(jiǎng)勵(lì)找到和修復(fù)問題的人們，現(xiàn)在他們將找到更少的——這是你真正想要的，但是僅僅假如你確實(shí)減少了你正在制造的問題數(shù)量。度量缺陷數(shù)量使它趕上場可能是更有用得多的測量。

改進(jìn)你的流程和產(chǎn)品

通過借力于現(xiàn)代軟件測試技術(shù)，你能獲得安全的、可靠的和保密的軟件。通過在軟件開發(fā)生命周期里左移測試，你能通過更早地找到問題而減少測試的成本，當(dāng)它低廉時(shí)，同時(shí)當(dāng)你首先放進(jìn)代碼的問題的數(shù)量減少時(shí)。嘗試這個(gè)方法去節(jié)省時(shí)間、金錢和頭痛之事。

轉(zhuǎn)載于:https://www.cnblogs.com/fengye151/p/11518441.html

總結(jié)

以上是生活随笔為你收集整理的软件测试的左移方法(译）的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。