摘要：

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

敏捷和開發運營團隊對左移的混戰是關于更早地在開發生命周期里移動關鍵的測試活動。

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

左移是關于更快地做這種識別和預防缺陷。

發現并修復軟件缺陷

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

?

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

他們是否犯錯誤、誤解需求，或者沒有通過特別的代碼塊的分支去考慮，當代碼被生成時開發引入缺陷。當一起結合代碼塊的時候，缺陷也被引進應用程序，特別是如果涉及多個團隊成員（并且就像現代架構比如微服務變得更復雜時）。

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

?

這也不奇怪，因為典型地當你開始測試時你發現了bug，并且在一切準備就緒前沒有一個合適的基礎結構開始測試，結果會是不同的。

但是我們在這里也能看到當問題大多數在編碼過程中被引進，它們幾乎沒有在那個階段被發現。它需要什么成本去修復這些問題呢？

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

?

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

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

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

左移背后的原因

現在看著以下圖表上橙色的線，因為它解釋了一個推遲的缺陷探測循環是在早期的測試基礎上。你可以看到橙色的缺陷在低廉的一邊增長地更快而且在昂貴的一邊增長地更慢些，這給我們一個很重要的成本降低情況：

?

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

一些組織在這一點上停止了。但是當你更深入地推進左移、融入編碼本身時，你會得到更多的價值。畢竟這是代碼被引進的地方，所以讓我們開始在開發仍然工作時候查找它們。

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

在測試開始前找問題不僅是成本上最有效的，而且也是時間上最有效的，因為它并沒有以任何一件嘗試重現產生問題或者理解失敗的事離開開發。有能力從數天或數周到數小時或數分鐘縮小缺陷修復循環是非常巨大的幫助。?

分析左移方法

這樣，你如何左移呢？為了簡潔起見，左移測試方法分解成兩個主要的活動：提供開發和測試最佳實踐，借力服務虛擬化以確保持續性測試。

做更早階段的開發實踐，比如靜態代碼分析和單元測試，有助于你在這個流程中更早地識別和防止缺陷。重要的是記住找問題不是目標，而是減少問題的數量，尤其是那些趕上發布的。最后，首先制造更少的問題比找更多的問題還有價值得多——并且它更低廉得多?？匆韵碌膱D表，在左邊有個可愛的減少的泡泡。

?

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

為了軟件的安全性，尤其重要的是加強你的軟件。你想要在你的代碼里創建安全性，而不是測試它。代碼標準讓你從開始去構建一個更安全的應用（比如通過設計使它安全），這既是一個好的想法也是一個需求，如果你服從于比如通用數據保護條例的規則。

接下來，你必須執行在所有開發流程階段的測試，包括晚期，并持續向前地執行它們。對團隊來講重要的是在開發流程的自始至終采取敏捷開發實踐去提供持續的反饋。單元測試能簡單地被持續執行但是晚期功能測試執行的左移通常很困難，因為外部系統獨立性。這就是你能借力服務虛擬化使能夠持續測試的地方。

服務虛擬化使你能夠模擬可能有限能力的獨立系統，比如主機、第三方服務，或者可能還沒有準備好的系統。通過模擬它們，你可以在還沒有完整系統可用時執行功能測試，并且你能一直在桌面端開發中左移測試執行。

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

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

避免錯誤和陷阱

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

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

而且那有另一個陷阱：假如你正在獎勵找到和修復問題的人們，現在他們將找到更少的——這是你真正想要的，但是僅僅假如你確實減少了你正在制造的問題數量。度量缺陷數量使它趕上場可能是更有用得多的測量。

改進你的流程和產品

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

轉載于:https://www.cnblogs.com/fengye151/p/11518441.html

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。