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

什么是回歸測試

簡單而言，回歸測試(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)可以被定義為：在對(duì)計(jì)算機(jī)程序進(jìn)行了一些修改之后，對(duì)其進(jìn)行重新測試，以確保所實(shí)施的更改不會(huì)對(duì)現(xiàn)有代碼產(chǎn)生不利的影響?？梢哉f，回歸測試提高了測試人員盡早檢測到那些由更改所引入的程序缺陷，同時(shí)也降低了解決缺陷的成本。

可見，回歸測試既能夠確保軟件的正常運(yùn)行，又能保證軟件開發(fā)者將產(chǎn)品的最佳版本投入市場。但是，光靠人工來創(chuàng)建和維護(hù)那些幾乎無休止的回歸測試是根本不可能的。這就是為什么大多數(shù)軟件企業(yè)會(huì)采用自動(dòng)化的回歸測試方式，以節(jié)省時(shí)間和精力的原因。

回歸測試的類型

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

• 單元測試(Unit Testing)：在完成了對(duì)于某個(gè)單元的代碼變更后，需要測試人員重新測試先前已經(jīng)通過了的單元測試。通常，我們可以在代碼中設(shè)置自動(dòng)化單元測試(https://dzone.com/articles/unit-testing-and-test-automation-two-things-youre)的入口，以提高測試的效率。
• 漸進(jìn)式測試(Progressive Testing)：當(dāng)開發(fā)人員對(duì)軟件及應(yīng)用程序的相關(guān)規(guī)范進(jìn)行了更改，并且重新設(shè)計(jì)了測試用例(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)后，就需要有效地進(jìn)行此類漸進(jìn)式測試。
• 選擇性測試(Selective Testing)：為了減少重新測試的成本和工作量，測試人員會(huì)采用當(dāng)前測試用例中的一部分。不過，當(dāng)它所涵蓋的程序?qū)嶓w發(fā)生變化時(shí)，則必須重新運(yùn)行相應(yīng)的單元測試。
• 全盤重新測試(Retest-All Testing)：隨著時(shí)間的推移，就算未對(duì)程序代碼進(jìn)行修改，也要重復(fù)測試所有的用例。當(dāng)然，如果應(yīng)用程序的改動(dòng)較小，此舉則會(huì)非常耗時(shí)。
• 完全測試(Complete Testing)：在對(duì)現(xiàn)有的代碼進(jìn)行了多次修改之后，我們需要有效地進(jìn)行完全測試。此舉不但是為了識(shí)別程序中的潛在錯(cuò)誤，而且在完成之后，我們便可以將最終的軟件直接提交給用戶了。

如何選擇回歸測試計(jì)劃

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

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

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

接著，我們可以通過執(zhí)行集成測試，來驗(yàn)證應(yīng)用程序的各個(gè)單元彼此是否能夠順暢通信，以及是否與后端的服務(wù)(例如數(shù)據(jù)庫)進(jìn)行交互。

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

在測試過程中所發(fā)現(xiàn)的代碼缺陷，會(huì)以報(bào)告的形式提交給開發(fā)團(tuán)隊(duì)。通過分析、找到解決方案之后，他們也需要為下一輪檢測過程設(shè)計(jì)出新的測試用例。而新的回歸測試又會(huì)生成新的報(bào)告。如此往復(fù)，形成了正反饋。

回歸測試面臨的挑戰(zhàn)

自動(dòng)化回歸測試雖然高效且省時(shí)，但是它也會(huì)面臨各種挑戰(zhàn)。具體包括如下方面：

成本高

在業(yè)務(wù)支出方面，軟件公司不得不花費(fèi)大量時(shí)間和金錢進(jìn)行重復(fù)性測試。業(yè)務(wù)方從收益的角度時(shí)常會(huì)認(rèn)為：此類回歸測試不但復(fù)雜，而且并不會(huì)產(chǎn)生顯著的投資回報(bào)。即便是從管理方的角度來看，開展回歸測試的理由可能只是為了獲取相關(guān)的預(yù)算。

時(shí)間限制

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

維護(hù)與優(yōu)化

維護(hù)和優(yōu)化現(xiàn)有的回歸測試套件是另一項(xiàng)主要挑戰(zhàn)。例如，每當(dāng)開發(fā)人員對(duì)其軟件代碼完成了更新之后，我們就添加、刪除或編輯現(xiàn)有的測試用例。而且這些操作往往需要在為回歸測試設(shè)定截止日期之前就已完成。

進(jìn)行回歸測試的優(yōu)秀實(shí)踐

既然已經(jīng)了解了回歸測試所面對(duì)的挑戰(zhàn)，那么我們?cè)撊绾瓮ㄟ^一些優(yōu)秀實(shí)踐來讓企業(yè)更好地交付高質(zhì)量的軟件呢?

專注于常用路徑

常用路徑是指：那些在您的應(yīng)用程序中，最常用到的用例。它們必須包含應(yīng)用程序中最常見、且最基本的功能。您應(yīng)該了解自己的核心用戶群、以及他們?cè)谑褂媚繕?biāo)應(yīng)用時(shí)，經(jīng)常用到的程序功能。您的回歸測試用例必須確保此類功能能夠按照預(yù)期完成測試。

定期更新回歸包

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

創(chuàng)建一個(gè)準(zhǔn)進(jìn)/準(zhǔn)出規(guī)范

通常，我們?cè)谲浖_發(fā)的生命周期中所遵循的準(zhǔn)進(jìn)/準(zhǔn)出規(guī)范，同樣有助于回歸測試的實(shí)現(xiàn)。

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

自動(dòng)化回歸測試

由于測試工作往往會(huì)涉及到各種重復(fù)性的操作，因此使用自動(dòng)化工具來執(zhí)行回歸測試的好處是業(yè)界有目共睹的。同時(shí)，測試人員可以通過由自動(dòng)化回歸測試所釋放出的資源，去進(jìn)行更為復(fù)雜的測試、以及用例的設(shè)計(jì)，進(jìn)而提高企業(yè)的投資回報(bào)率。

目前，許多企業(yè)已開始選用基于云的應(yīng)用測試平臺(tái)。此類平臺(tái)能夠模擬數(shù)百種設(shè)備、以并行的方式，高效地執(zhí)行各種自動(dòng)化的回歸測試。

總結(jié)

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

原文標(biāo)題：A Brief Overview Of Regression Testing，作者：Bala Murugan

【51CTO譯稿，合作站點(diǎn)轉(zhuǎn)載請(qǐng)注明原文譯者和出處為51CTO.com】