本文節選自霍格沃茲測試學院內部教材

軟件測試是軟件質量保證的關鍵步驟。越早發現軟件中存在的問題，修復問題的成本就越低，軟件質量也就越高，軟件發布后的維護費用越低。

為了能更好的保障軟件質量，在軟件測試的實踐中，慢慢形成了一些流程用來達到這一目標。下面就來介紹一下常見的測試流程。

傳統測試流程

在傳統的測試流程中包含了如圖所示的步驟。

下面分別介紹下每一步流程的含義。

單元測試

單元測試是對軟件中的基本組成單位進行的測試。目的是檢驗軟件基本組成單位的正確性。

集成測試

集成測試是在軟件系統集成過程中所進行的測試。目的是檢查軟件模塊之間的接口是否正確。

冒煙測試

冒煙測試是在軟件開發過程中的一種針對軟件版本包的快速基本功能驗證策略，是對軟件基本功能進行確認驗證的手段。

系統測試

系統測試是對已經集成好的軟件系統進行徹底的測試，以驗證軟件系統的正確性和性能等是否滿足其規約所指定的要求。

一般系統的主要測試工作都集中系統測試階段。根據不同的系統，所進行的測試種類也很多。

在系統測試中，又包括如下測試種類：

驗收測試

驗收測試是部署軟件之前的最后一個測試操作。驗收測試的目的是確保軟件準備就緒，向軟件購買都展示該軟件系統滿足其用戶的需求。

軟件測試模型

軟件測試過程是一種抽象的模型，用于定義軟件測試的流程和方法。眾所周知，開發過程的質量決定了軟件的質量，同樣的，測試過程的質量將直接影響測試結果的準確性和有效性。軟件測試過程和軟件開發過程一樣，都遵循軟件工程原理，遵循管理學原理。

隨著測試過程管理的發展，軟件測試專家通過實踐總結出了很多很好的測試過程模型。這些模型將測試活動進行了抽象，并與開發活動有機的進行了結合，是測試過程管理的重要參考依據。

下面介紹幾種常見的測試模型。

V 模型

V 模型是開發模型中瀑布模型的一種改進。瀑布模型將軟件生命周期劃分為計劃、分析、設計、編碼、測試和維護六個階段，由于早期的錯誤可能要等到開發后期的測試階段才能發現，所以可能帶來嚴重的后果。

V 模型在這點改進了瀑布模型，在軟件開發的生存期，開發活動和測試活動幾乎同時開始，在開發活動進行的時候，測試活動開始進行相應的文檔準備工作，從而改進軟件開發的效率和效果。

V 模型的優點是明確的標注了測試過程中存在著那些不同的測試類型，并且可以清楚的表達測試階段和開發過程各階段的對應關系。

但是，它也有一些缺點。比如容易讓人誤解為測試是在開發完成之后的一個階段。而且由于它的順序性，當編碼完成之后，正式進入測試時，這時發現的一些 Bug 可能不容易找到其根源，并且代碼修改起來很困難。在實際工作中，因為需求變更較大，使用 V 模型可能導致要重復變更需求、設計、編碼、測試，返工量會比較大。

W 模型

W 模型從 V 模型演化過來。相對于 V 模型，W 模型增加了軟件各開發階段中應同步進行的驗證和確認活動。

W 模型由兩個 V 字型模型組成，分別代表測試與開發過程，圖中明確表示出了測試與開發的并行關系。測試與開發是同步進行的，有利于盡早的全面發現問題。

W 模型認為測試伴隨著整個軟件開發周期，而且測試的對象不僅僅是程序，需求、設計等同樣要測試。

W 模型有利于盡早地全面的發現問題。例如，需求分析完成后，測試人員就應該參與到對需求的驗證和確認活動中，以盡早地找出缺陷所在。

對需求的測試也有利于及時了解項目難度和測試風險，及早制定應對措施，這將顯著減少總體測試時間，加快項目進度。

使用 W 模型的優點很明顯。首先測試的活動與軟件開發同步進行，而且測試的對象不僅僅是程序，還包括需求和設計。這樣可以盡早發現軟件缺陷可降低軟件開發的成本。

但是 W 模型還是有一些缺點存在。比如開發和測試依然是線性的關系，需求的變更和調整，依然不方便。而且如果沒有文檔，根本無法執行 W 模型。使用 W 模型對于項目組成員的技術要求也更高。

H 模型

相對于 V 模型和 W 模型，H 模型將測試活動完全獨立出來，形成了一個完全獨立的流程，將測試準備活動和測試執行活動清晰地體現出來。

這個示意圖僅僅演示了在整個生產周期中某個層次上的一次測試“微循環”。圖中標注的其他流程可以是任意的開發流程，例如，設計流程或編碼流程。也就是說，只要測試條件成熟了，測試準備活動完成了，測試執行活動就可以（或者說需要）進行了。

H 模型中包含了如下概念：

H 模型揭示了軟件測試除測試執行外，還有很多工作。它讓測試活動完全獨立貫穿整個生命周期與其它流程并發進行。在 H 模型中，軟件測試活動可以盡早準備盡早執行，具有很強的靈活性。而且軟件測試可以根據被測對象的不同而分層次、分階段、分次序的執行，同時也是可以被迭代的。

但是 H 模型對于管理要求很高，因為需要定義清晰的規則和管理制度，否則測試過程將很難管理和控制。而且對于技能要求也很高，因為 H 模型要求能夠很好的定義每個迭代的規模，不能太大也不能太小。在 H 模型中，測試就緒點的分析也比較困難。因為測試過程中，并不知道測試準備到什么時候是合適的，就緒點在哪，就緒點標準是什么，這就對后續的測試執行啟動帶來很大的困難。

三種模型對比

上面介紹的三種測試模型是現在比較常見的，但是它們的使用場景會有一些不同。

系統測試工作流程

對于系統測試來說，工作流程如圖所示：

下面分別解釋一下每一步的具體含義。

項目計劃

描述測試目的、范圍、方法和軟件測試的重點等等內容的文檔。

需求分析

測試工程師參與需求分析，可以增加對需求的了解，減少后期與產品和開發人員的溝通，節省時間。早期確定測試用例的編寫思路，可以為測試打好基礎。在需求分析的過程中可以獲取一些測試數據，為測試用例設計提供幫助。而且在分析過程中可以發現需求不合理的地方，降低測試成本。

測試設計

測試設計是指把概括的測試目標轉化為具體的測試用例的一系列活動。設計時要同時評審測試依據，也就是需求、系統架構、設計和接口說明等文檔。通過對測試項、規格說明、測試對象行為和結構的分析，識別測試條件并確定優先級。根據分析的內容設計測試用例，并確定優先級，同時確定測試條件和測試用例所需的必要的測試數據。

用例評審

測試用例評審一般進行兩輪。

一輪是組內評審，組內人員會評審測試用例是否完全覆蓋了需求，提出一些修改意見。

二輪評審需要和產品、研發一起進行，產品和研發會從不同角度對用例進行一些補充。經過用例評審并且把評審中的建議補充完畢之后，測試用例才最終設計完畢，進入等待執行的狀態。

測試執行

開發人員完成需求的開發之后會提測，也就是把可以測試產品交付給測試人員進行測試。提測后需要先執行冒煙測試，通過之后正式進入測試執行階段。

開始執行之前要確認已經正確搭建了測試環境。環境沒有問題后，就根據計劃的執行順序，通過手工或使用測試工具來執行測試用例。執行過程中需要記錄測試執行的結果，以及被測軟件、測試工具的標識和版本。將實際結果和預期結果進行比較。對實際結果和預期結果之間的差異，作為 Bug 上報，并且進行分析以確定引起差異的原因。缺陷修正后，重新進行測試活動。

Bug 管理

軟件缺陷（Bug）是一種泛稱，它可以指功能的錯誤，也可以指性能低下，易用性差等。

發布維護

監控上線后的產品，發現問題及時修復。

Bug管理流程

Bug 的管理也需要遵循一定的流程，基本流程如圖所示：

提交 Bug

在提交一個 Bug 的時候，首先盡量描述這個 Bug 的屬性。重現環境，類型，等級，優先級以及詳細的重現步驟，結果與期望等。當然，在提交一個問題之前首先應該保證，這個 Bug 是沒有被提過的，以免造成重復提交。

指派 Bug

有些公司測試部門與開發部門獨立，那么測試人員就不確定自己測試的模塊是由哪位開發人員負責的，在這種情況下，測試人員統一把問題指派給項目組長或經理，由項目組長（或經理）對問題進行確認后再次分配給相應的開發人員。

有些測試人員是和研發團隊在一起工作的，這時，測試人員會對開人發員負責的模塊非常清楚，就可以將問題直接指派給相應的開發人員。

確認 Bug

當開發人員接到一個 Bug 時，首先是對其進行分析與重現，如果對其進行分析發現不是 Bug（可能由于測試人員不了解需求）或無法對此問題進行重現，那么就需要將此問題返回給測試人員再次進行回歸，并注明原因。如果確認為是 Bug 則需要對其進行處理。

判斷是否推遲處理

在處理問題之后，還需要進行一次判斷，是否需要推遲處理。有些 Bug 已經確認了是問題，由于其可能在極端情況下才會出現，或需要對系統架構進行改動，或其優先級非常低，所以暫時不需要對此問題進行處理，或到下個版本進再進行修復。

遺留 Bug

對于推遲處理的問題可以暫時進行遺留。一般遺留的問題需要經過項目經理與測試經理協商后才可以。

處理 Bug

開發人員在確認完一個問題需要處理時，那么就對其進行處理工作。

回歸 Bug

確認非 Bug 問題：對于提交的一個 Bug，開人員處理為非 Bug 或無法重現，然后直接轉交給測試人員回歸。測試人員再次確認，如果真如開發人員所說，則將問題關閉。如果非開發人員所說，是由于問題描述模糊或其它原因未重現問題，則再次注明原因轉給開發人員。

確認修復問題：對開發人員修復的問題再次進行確認，確認能過，則關閉問題。確認不通過，將問題再次打開并轉給開發人員。

確認遺留問題：有計劃的對遺留的問題進行確認，有些遺留問題隨著時間的推移，版本的更新或已經不存在了，對這類問題應該及時關閉。有些遺留問題依然存在且變得緊急，對于這類問題應該及時打開交給開發人員處理。

關閉 Bug

對于已經修復的 Bug 進行關閉，這也是一個 Bug 的最后一個狀態。

測試左移和測試右移

傳統的流程就是接到項目后參與需求評審，然后根據需求文寫用例和準備腳本，等開發提測之后正式開始測試、提 Bug、回歸，測試通過后就結束了，項目交給運維上線，之后投入下一個項目繼續重復這樣的流程。

這樣的流程看似沒什么問題，但缺點是測試過程是在一定時間間隔內發生的，測試人員必須等待產品完全構建才能找到錯誤和故障。有時候等待產品花費的時間超過了可以商定的時間，等待代碼成為測試人員的瓶頸。

而測試左移以及測試右移，能夠讓測試擁有更多的主動權，有更充足的時間進行測試，同時不會像之前因為質量差風險高每次都延期上線，并且產品的線上質量也能有保證。

不管是測試左移還是測試右移，都是為產品質量服務。不要把提測認為是測試活動的開始，上線是測試活動的結束，更不要認為質量只是測試同學需要關注的。

測試左移

測試左移是向測試之前的開發階段移動。

測試左移的原則支持測試團隊在軟件開發周期早期和所有干系人合作。因此他們能清晰地理解需求以及設計測試用例去幫助軟件“快速失敗”，促使團隊更早的修改所有的 Bug。

參與和理解會使測試人員獲取產品完整的知識，徹底想清楚各種場景，根據軟件行為設計實時的場景，這些都會幫助團隊在編碼完成之前識別出一些缺陷。

左移聚焦在使測試人員在全部和最重要的項目階段參與進來。這就是測試人員把焦點從發現 Bug 轉移到 Bug 的預防上，同時也驅動項目的商業目標。

隨著測試團隊的責任的提高，團隊不在僅僅聚焦在“測試軟件去發現 Bug”，而是積極團隊合作，參與項目初始階段的計劃和建立強壯有效的測試策略，而測試策略又為團隊提供好的測試領導力和指導，使團隊聚焦在產品的長遠的視角，而不僅僅是測試工作。

左移首先為測試人員提供了設計測試的機會，無論這些測試是被聚焦在客戶的體驗還是期望，也促使開發人員根據這些測試去開發軟件以滿足客戶需求。

測試右移

測試右移是測試活動向產品發布之后的步驟移動。

是產品上線了之后也可以進行一些測試活動。可以在生產環境做監控，監控線上性能和可用率，一旦線上發生任何問題，盡快反映，提前反映，給用戶良好的體驗

?? 復制“下方鏈接”，提升測試核心競爭力！

>>更多技術文章分享和免費資料領取 歡迎+V~ ceshiren001

https://qrcode.ceba.ceshiren.com/link?name=article&project_id=qrcode&from=souhu×tamp=1650941261

責任編輯：Rex_08