眾所周知，在軟件開發(fā)的生命周期中，開發(fā)人員往往需要修改已有代碼，或將新功能引入目標系統(tǒng)。不過，此類更改可能會通過影響現(xiàn)有功能對系統(tǒng)造成破壞。因此，我們需要執(zhí)行一系列測試，以驗證新的代碼對系統(tǒng)不會造成負面影響。這便是回歸測試。

在本文中，我們將從回歸測試的概念入手，討論其實施的重要性，以及那些實現(xiàn)自動化測試的方法與優(yōu)秀實踐。

什么是回歸測試?

回歸測試(https://en.wikipedia.org/wiki/Regression_testing)是一種軟件的測試形式，能夠涵蓋軟件系統(tǒng)中的各種功能性和非功能性的元素。我們可以在執(zhí)行如下操作后，通過它來發(fā)現(xiàn)潛在的問題或錯誤。

• 部署新的功能
• 添加新的模塊
• 修復現(xiàn)有缺陷
• 重構程序代碼
• 更改系統(tǒng)配置
• 改善應用程序的性能

針對上述任何事件，如果采用手動的方式測試整個系統(tǒng)，顯然既費時又費力。開發(fā)團隊往往希望通過自動化測試的方式，來加快整個工作流程，以實現(xiàn)每修改一次代碼，都能執(zhí)行一系列預先開發(fā)好的測試腳本。據(jù)此，他們能夠在進行連續(xù)性回歸測試的同時，降低測試的總體成本，減少人為錯誤，并保持更高的準確性。

為何要使用自動化回歸測試?

如前文所述，我們在對每個系統(tǒng)組件進行下一階段開發(fā)之前，需要對其進行徹底的測試，否則就會積累所謂的技術債(technical debt)。這不僅成本高昂，而且對于開發(fā)工作流程來說也是危害極大的。

值得注意的是，錯誤的修復成本會在軟件開發(fā)的各個階段呈指數(shù)性增長(請參考：https://www.nist.gov/system/files/documents/director/planning/report02-3.pdf)，并且會在產(chǎn)品發(fā)布的時候高達30倍以上。下圖是此類費用隨時間增加的統(tǒng)計圖。

可見，通過在開發(fā)的早期階段進行徹底的測試，不但可以及時地發(fā)現(xiàn)錯誤，還能夠避免糾正錯誤所帶來的高昂成本。這也正是自動化回歸測試發(fā)揮作用的地方。當然，除了改進錯誤檢測的效率，自動化回歸測試還能夠為開發(fā)工作、及其流程帶來如下好處：

• 更高的測試覆蓋范圍 - 自動化能夠讓我們通過運行更多的回歸測試，來檢查系統(tǒng)的各個方面。顯然，這是手動回歸測試所無法達到的徹底水平。
• 更高的測試投資回報率 - 盡管自動化測試有時會引發(fā)更高的初期投資，但是從長遠來看，由于軟件開發(fā)和維護是一個連續(xù)性的過程，因此自動化回歸測試往往可以在可預見的將來，為團隊節(jié)省大量的時間與金錢，并能收獲更大的回報。
• 更少的人力成本 - 使用自動化測試平臺時，團隊只需一名QA(質(zhì)量檢測)工程師即可測試腳本。相反，手動回歸測試將需要數(shù)名專業(yè)人員，才能達到相似的效果。因此，自動化大幅減少了回歸測試所需的總體時間和人力成本。
• 增強的穩(wěn)定性 - 手動回歸測試的結果，往往取決于團隊中QA專家的專業(yè)知識和測試方法。而自動化卻能夠確保用相同的專業(yè)技術，來測試整個系統(tǒng)的方方面面。
• 重復性 - 自動化回歸測試可以按需隨時執(zhí)行，而無需顧及QA團隊是否有時間和精力。而手動測試則需要為每個新項目配備足夠的QA人員。

如何執(zhí)行自動化回歸測試?

正如執(zhí)行任何其他類型的自動化軟件測試一樣，我們需要遵循預定義的測試路線，才能成功地完成回歸測試。

正所謂“工欲善其事，必先利其器”，我們在執(zhí)行自動化回歸測試前，首先也是最重要的一步是：選擇合適的工具。目前市場上的自動化回歸測試工具林林總總，其中比較流行的包括Selenium、TestComplete、Ranorex Studio和Perfecto。

接著，我們可以按照如下四步來開展自動執(zhí)行回歸測試：

• 發(fā)現(xiàn)和計劃 - 首先概述產(chǎn)品將要發(fā)布的范圍，確定哪些測試用例可能會被包含在回歸測試的套件中。
• 設計和開發(fā) – 在確定測試項目需包含的所有任務后，開始為每個測試用例編寫自動化的腳本。
• 測試執(zhí)行 – 運行測試，并在執(zhí)行過程中識別錯誤。
• 測試結束 - 最后，記錄和提交測試報告，進而執(zhí)行其他的后續(xù)測試。

自動化回歸測試的方法

目前，業(yè)界通常會使用如下三種方法，來執(zhí)行自動化回歸測試(請參見--https://ieeexplore.ieee.org/document/10189)。您該具體選擇哪種方法，則完全取決于開發(fā)的優(yōu)先級、代碼庫的大小、以及可用在測試中的資源。

• 全部重新測試 - 有時候，在代碼庫上執(zhí)行所有現(xiàn)有的回歸測試是一種最佳選擇。盡管需要初期大量的投入，但是只要設計合理，就能夠發(fā)現(xiàn)一些不需要回歸的環(huán)節(jié)。當然，客觀地說，該方法對于大型代碼庫幾乎是不可行的。
• 基于優(yōu)先級重新測試 – 按照重要性和緊迫性的順序，執(zhí)行測試用例。在確定具有最高優(yōu)先級的測試用例時，往往需要QA專家給出專家意見。而且，優(yōu)先級測試應涵蓋所有關鍵的代碼路徑，以發(fā)現(xiàn)那些嚴重的錯誤。
• 選擇性重新測試 - 您可以選擇回歸測試套件中的一個子集來執(zhí)行，而不是重新運行整個測試套件。在后續(xù)的回歸周期中，您只需執(zhí)行那些可以在代碼庫上復用的測試用例，并將過時的用例剔除出去。

此外，您還可以使用混合回歸測試技術，即：先執(zhí)行優(yōu)先級測試，然后再運行其他必要的測試，以避免遺漏并實現(xiàn)全覆蓋。

自動化回歸測試的實例

如前所述，我們可以根據(jù)對代碼庫所進行的更改，來采用不同形式的回歸測試。有些是在添加新的功能后執(zhí)行，而有些是在修復了系統(tǒng)中已知錯誤后執(zhí)行。下面，讓我們來討論回歸測試的一些實際案例：

• 場景1：假設有一個具有數(shù)據(jù)庫管理功能的應用，其核心功能有三個，即：數(shù)據(jù)添加、數(shù)據(jù)保存、以及數(shù)據(jù)刪除。當我們在新版本中，引入允許用戶對數(shù)據(jù)進行修改的“數(shù)據(jù)更新”功能時，則需要通過執(zhí)行回歸測試，來確保該功能不會影響到既有的“添加”、“保存”和“刪除”功能。
• 場景2：某個系統(tǒng)具有管理員、版主、客戶和作者，四個角色模塊。如果管理員模塊出現(xiàn)了錯誤，那么就會導致作者使用其憑據(jù)，以版主的身份登錄到后臺系統(tǒng)中。因此，測試團隊需要反饋開發(fā)團隊修復該錯誤。而在實施了有效修復后，測試團隊將再次檢查系統(tǒng)，以確保具有修復功效的代碼能夠正常工作，且不會影響到其他模塊與功能(該過程便是回歸測試)。

根據(jù)上述的場景，我們來討論其中的登錄驗證功能，即：用戶輸入其登錄憑據(jù)(如用戶名和密碼)，然后單擊登錄按鈕。其中，用于測試此功能的分步實施代碼如下：

如下代碼則展示了當我們對該功能性代碼進行測試時，生成的具有登錄功能的類：

上述代碼實為手動回歸測試的示例。如果我們使用諸如Perfecto之類的自動化回歸測試工具，則無需對測試腳本進行硬編碼。我們只需做到：首先，確定可能用到的回歸測試，并記錄每個測試用例的工作流程。接著，使用Perfecto儀表板對測試方案進行建模。如下圖所示，我們可以讓Perfecto協(xié)助將工作流程轉換為測試腳本。

在工作流程準備就緒后，我們即可執(zhí)行測試并捕獲結果。而在完成測試之后，Perfecto將返回對應的測試通過或失敗狀態(tài)，并為每個執(zhí)行的命令提供詳細的反饋。據(jù)此，您可以相繼開展分析測試結果，生成報告，以及重新測試更改等工作。

自動執(zhí)行回歸測試的最佳做法

在執(zhí)行回歸測試時，開發(fā)團隊往往會碰到包括：時間與資源有限，測試時間過長，測試用例增多等各方面的挑戰(zhàn)。為了避免“踩坑”，并能夠成功地完成自動化回歸測試，我在此為您羅列了如下實踐建議：

• 選用可靠的自動化工具，以擴大測試的范圍，并利用其自動化的優(yōu)勢。
• 在整個項目中采用常規(guī)化的測試方案。
• 通過獨立可重用的回歸測試，以節(jié)省時間。
• 在修改代碼庫后，應重新運行過往已成功完成的測試。
• 通過定期更新回歸測試包，以確保與更新的產(chǎn)品版本相對應。
• 為每個新發(fā)現(xiàn)的錯誤編寫各種測試。
• 確保所有集成測試用例都被包含在回歸測試的套件中。

希望上述實踐經(jīng)驗能夠幫助您平滑地開展回歸測試，并獲得預期的結果。

小結

回歸測試是在減少潛在技術債，并改善軟件項目維護態(tài)勢的有效方法。借助自動化測試工具，開發(fā)團隊不但能夠簡化測試的整體工作量，并且可以確保產(chǎn)品在交付到生產(chǎn)環(huán)境之前的穩(wěn)定性與代碼質(zhì)量。

網(wǎng)頁標題：自動化回歸測試全接觸：概念、方法和實踐
網(wǎng)址分享：http://uogjgqi.cn/article/cdjjpgd.html