【51CTO.com快譯】有研究表明：在安裝了新的應用程序之后，只有四分之一的用戶會在次日回到該應用。而大多數用戶在首次使用之后就直接將其卸載掉了。造成此類留存率低下的主要原因，便是測試人員對于應用程序的測試不足。由于他們對于重復測試毫無興趣，因此盡管深知回歸測試的重要性，但是他們仍然會在軟件項目中選擇性地忽略掉測試的環節。

什么是回歸測試

簡單而言，回歸測試(https://www.pcloudy.com/a-brief-overview-of-regression-testing/?utm_source=linkedin&utm_medium=post&utm_term=p&utm_campaign=continuous_testing_wp&utm_source=linkedin&utm_medium=post&utm_campaign=continuous_testing_wp&utm_term=p)可以被定義為：在對計算機程序進行了一些修改之后，對其進行重新測試，以確保所實施的更改不會對現有代碼產生不利的影響?？梢哉f，回歸測試提高了測試人員盡早檢測到那些由更改所引入的程序缺陷，同時也降低了解決缺陷的成本。

可見，回歸測試既能夠確保軟件的正常運行，又能保證軟件開發者將產品的最佳版本投入市場。但是，光靠人工來創建和維護那些幾乎無休止的回歸測試是根本不可能的。這就是為什么大多數軟件企業會采用自動化的回歸測試方式，以節省時間和精力的原因。

回歸測試的類型

一般而言，對于不同的測試階段，我們會采用不同類型的回歸測試。下面讓我們來了解一下回歸測試的類型：

• 單元測試(Unit Testing)：在完成了對于某個單元的代碼變更后，需要測試人員重新測試先前已經通過了的單元測試。通常，我們可以在代碼中設置自動化單元測試(https://dzone.com/articles/unit-testing-and-test-automation-two-things-youre)的入口，以提高測試的效率。
• 漸進式測試(Progressive Testing)：當開發人員對軟件及應用程序的相關規范進行了更改，并且重新設計了測試用例(https://www.pcloudy.com/17-best-tips-to-write-effective-test-cases/?utm_source=linkedin&utm_medium=post&utm_term=p&utm_campaign=continuous_testing_wp&utm_source=linkedin&utm_medium=post&utm_campaign=continuous_testing_wp&utm_term=p)后，就需要有效地進行此類漸進式測試。
• 選擇性測試(Selective Testing)：為了減少重新測試的成本和工作量，測試人員會采用當前測試用例中的一部分。不過，當它所涵蓋的程序實體發生變化時，則必須重新運行相應的單元測試。
• 全盤重新測試(Retest-All Testing)：隨著時間的推移，就算未對程序代碼進行修改，也要重復測試所有的用例。當然，如果應用程序的改動較小，此舉則會非常耗時。
• 完全測試(Complete Testing)：在對現有的代碼進行了多次修改之后，我們需要有效地進行完全測試。此舉不但是為了識別程序中的潛在錯誤，而且在完成之后，我們便可以將最終的軟件直接提交給用戶了。

如何選擇回歸測試計劃

因此，每當軟件應用程序發生變更、或是有新的版本需要發布之前，開發人員都會選擇性地將上述測試類型作為回歸測試過程(https://dzone.com/articles/plan-your-regression-testing-strategy-by-asking-th-4)的一部分予以執行。

• 首先，開發人員執行單元級的回歸測試，以驗證其修改代碼的正確性。創建此類新的測試，是為了應盡可能多地覆蓋那些新增的軟件功能。
• 然后，開發人員通過將修改后的代碼合并集成到現有軟件中，以創建新的自動化單元測試(AUT)版本。
• 接著，開發人員執行冒煙測試(smoke tests，https://dzone.com/articles/how-to-distinguish-the-differences-between-smoke-s)，以確保前面步驟所產生的構建(build)是正確可行的。

上述測試都可以交由諸如Jenkins之類的持續集成(https://dzone.com/articles/what-is-continuous-integration-11-key-practices-an)服務，來自動執行。一旦確認了構建的正確性，我們就需要通過完整性測試，來確認在掃清了所有已知缺陷的基礎上，新增的功能是否能夠按照預期運行。

接著，我們可以通過執行集成測試，來驗證應用程序的各個單元彼此是否能夠順暢通信，以及是否與后端的服務(例如數據庫)進行交互。

下一步，我們需要根據代碼的大小和涉及到的范圍，來進行部分或全部的回歸測試。

在測試過程中所發現的代碼缺陷，會以報告的形式提交給開發團隊。通過分析、找到解決方案之后，他們也需要為下一輪檢測過程設計出新的測試用例。而新的回歸測試又會生成新的報告。如此往復，形成了正反饋。

回歸測試面臨的挑戰

自動化回歸測試雖然高效且省時，但是它也會面臨各種挑戰。具體包括如下方面：

成本高

在業務支出方面，軟件公司不得不花費大量時間和金錢進行重復性測試。業務方從收益的角度時常會認為：此類回歸測試不但復雜，而且并不會產生顯著的投資回報。即便是從管理方的角度來看，開展回歸測試的理由可能只是為了獲取相關的預算。

時間限制

軟件企業的業務重點是：開發出高質量的應用程序，并更快地交付給用戶。而這就造成了回歸測試經常與時間限制相“共生”的狀況。為了與規定的時間保持同步，并在最后期限之前完成回歸測試的全部過程，測試人員往往需要將精力集中在那些關鍵性的回歸測試環節上，并且選擇性地跳過一些細枝末節。那么，在面對此類嚴峻的挑戰時，到底應該跳過哪些不重要的環節，便成了測試人員憑借個人經驗進行主觀判斷的“試驗田”。

維護與優化

維護和優化現有的回歸測試套件是另一項主要挑戰。例如，每當開發人員對其軟件代碼完成了更新之后，我們就添加、刪除或編輯現有的測試用例。而且這些操作往往需要在為回歸測試設定截止日期之前就已完成。

進行回歸測試的優秀實踐

既然已經了解了回歸測試所面對的挑戰，那么我們該如何通過一些優秀實踐來讓企業更好地交付高質量的軟件呢?

專注于常用路徑

常用路徑是指：那些在您的應用程序中，最常用到的用例。它們必須包含應用程序中最常見、且最基本的功能。您應該了解自己的核心用戶群、以及他們在使用目標應用時，經常用到的程序功能。您的回歸測試用例必須確保此類功能能夠按照預期完成測試。

定期更新回歸包

回歸包是各種測試用例的集合。這些測試用例需要在發布新的應用版本、以及執行任何更新操作之前就已完成。為了不再浪費測試人員的時間，去驗證應用程序的最新版本是否包含有舊版本的保留功能，回歸包中的測試用例應當包含舊版應用的相關規范。當然，后期新增的測試用例也應當被及時更新到回歸包之中。

創建一個準進/準出規范

通常，我們在軟件開發的生命周期中所遵循的準進/準出規范，同樣有助于回歸測試的實現。

此處的準入規范是指需要滿足的一組固定條件。例如：先執行回歸測試，再檢查與分析缺陷，然后修復缺陷與錯誤。而準出規范同樣也是一組固定條件，例如：只有確保執行了所有測試，并不再剩下任何未能解決的缺陷與錯誤后，方可交付軟件。

自動化回歸測試

由于測試工作往往會涉及到各種重復性的操作，因此使用自動化工具來執行回歸測試的好處是業界有目共睹的。同時，測試人員可以通過由自動化回歸測試所釋放出的資源，去進行更為復雜的測試、以及用例的設計，進而提高企業的投資回報率。

目前，許多企業已開始選用基于云的應用測試平臺。此類平臺能夠模擬數百種設備、以并行的方式，高效地執行各種自動化的回歸測試。

總結

領導學專家Robin Sharma曾有句名言：“變革在開始時最為困難，在中間最為混亂，而在結束時最為美好。”這段話恰好體現了回歸測試，在應用程序流暢地交付其服務功能時的重要性。如前所述，我們應當克服回歸測試中的各種挑戰，在測試生命周期的不同階段，執行不同類型的回歸測試。

原文標題：A Brief Overview Of Regression Testing，作者：Bala Murugan

【51CTO譯稿，合作站點轉載請注明原文譯者和出處為51CTO.com】