10年老測試工程師的一些心得：結合案例談談迴歸測試和確認測試

本人在測試崗位工作10有餘，本著對測試工作的熱愛，在工作崗位上一直表現還不錯，在測試技術、流程方面頗有一些心得。今天就談談迴歸測試和確認測試的區別。

一、迴歸測試和確認測試的誤區

其實我在之前的工作當中一直都經常說“迴歸測試”，基本上沒有提到過“確認測試”。正式接觸到“確認測試”還是從學習ISTQB認證開始。ISTQB基礎級大綱中就提到了確認測試和迴歸測試的區別。

一開始我還很疑惑，難道迴歸測試不就是確認測試嗎?迴歸測試不就是在確認bug修改有沒有生效嗎?但是，實際上大錯特錯。確認測試是在修復缺陷後，在軟體的最新版本上，重新執行之前因該缺陷而導致失敗的測試用例，來確認缺陷被解決。而回歸測試是在確認測試完成的基礎上，確保缺陷修復不會產生副作用，也就是說不會產生修改引入。加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~

二、迴歸測試和確認測試的案例

案例一：

Bug概述：一個公司官網web頁面，在介紹公司主營產品的頁面出現了錯別字，把“智慧”顯示成了“只能”。

針對這個bug，基於風險及改動大小進行初步判斷，這個bug只是涉及到web前端顯示問題，並且修改該bug只是需要把文案修正即可，不會涉及到程式碼邏輯或者底層函式的變動。所以，該bug可以只做確認測試即可。

不過，雖然不需要進行迴歸測試(重點指修改影響測試)，可以針對這個錯誤，舉一反三，進行擴充套件測試。因為“智慧”這個用詞可能是官網文案中的一個高頻詞，那麼很有可能其他地方也出現一樣的錯誤。

案例二：

Bug概述：一個公司官網web頁面，使用者進入商務合作頁面，錄入商務合作資訊(例如，姓名、電話等)後，點選提交按鈕，沒有任何反應。

針對這個bug進行分析：該bug相關的模組為重點模組，且該bug明顯是基本功能存在問題，影響重大。所以，一定要做迴歸測試。具體的迴歸測試用例可以結合bug根因和修改點進行輸出。該bug的原因是Web前端傳送介面請求，後端響應超時。那麼，針對這個bug，我們不僅要進行確認測試(測試bug解決)，還要進行迴歸測試(避免修改引入)。加我VX：atstudy-js 回覆“測試”，進入軟體測試學習交流裙~~用例示例如下：

1)填寫商務合作人員資訊中的必填欄位，然後點選提交按鈕(確認測試);

2)商務合作人員資訊中的必填欄位和選填欄位都填寫，然後點選提交按鈕;

3)商務合作人員資訊填寫內容達到各個欄位的最大長度，然後點選提交按鈕;

4)商務合作人員資訊填寫內容存在特殊字元，然後點選提交按鈕;

5)針對提交按鈕呼叫的介面進行併發測試，觀察記錄介面響應時間。

三、迴歸測試和確認測試的應用場景

如果你是測試工程師，我相信你一定會經常遇到這種情況，領導說你問題單迴歸的太不充分了，沒辦法避免修改引入。那麼，在這個場景下，一般是你雖然名義上做的是迴歸測試，但是實際上你可能只做了確認測試。

那麼既然迴歸測試的測試覆蓋大於確認測試，是不是任何時候都不能只做確認測試，一定要做迴歸測試呢。當然不是。

我覺得，這個主要是基於以下幾方面考慮：

首先，評估bug修改的影響程度。如果改動大，影響到底層或者影響到系統框架，那肯定要做全面的迴歸測試，甚至要做詳細的迴歸測試分析和測試設計。如果改動較小，就可以酌情只做確認測試即可。

其次，要評估bug涉及到的功能的重要性和使用頻率。如果是核心功能模組，一定要做迴歸測試。如果是不常用功能模組，也可以酌情只做確認測試。

另外，負責修改bug的開發人員最瞭解bug的來龍去脈，所以，最好跟開發人員溝通交流，討論bug的根因、修改方案及修改影響，結合開發人員的測試建議，再結合測試人員自身的經驗，輸出相關測試用例。這種迴歸過程是比較精準的一種迴歸測試的途徑。

當然，什麼時候選擇確認測試型別，什麼時候選擇迴歸測試型別，很多情況下，會根據專案的整體情況，基於風險對迴歸測試做取捨，這不僅僅是技術層面的事情了，涉及到測試策略方面的調整。