本文提供了一個結構化的方法來建立和更新迴歸測試套件。迴歸測試套件應包含哪些型別的測試？應該執行哪些迴歸測試？如何應對迴歸測試失敗？迴歸測試套件如何演變？這些問題以及其他考慮因素都會逐步探討。
首先探討回歸測試的基本動態和考慮因素。
迴歸測試的基本原理
假設研發對軟體程式碼進行了一些更改，任何型別的更改。我們如何確信這些更改不會對我們的程式碼產生負面影響呢？實現信心的一種方式是進行徹底的迴歸測試。編寫並執行測試，檢查和探索我們的程式碼在更改後的行為。因此，我們編寫和執行的測試越多，我們就會越有信心。是的，但也要考慮實際成本——編寫、執行和維護迴歸測試套件所需的時間、精力。
在迴歸測試套件中包含每一個可能的測試結果，這太大了，無法管理，而且它的執行具有挑戰性，因為經常對軟體進行更改。如果迴歸測試沒有及時完成，開發過程就會中斷。對於投入額外計算資源和/或人員以執行軟體測試工作,需要權衡利弊。從保證產品質量、降低潛在風險的角度來看,這種投資是十分必要的。然而,測試工作的投入需要審慎評估,附加值與所需資源消耗之間應該保持適度平衡。在某些情況下,測試工作的邊際收益可能無法抵消資源的額外支出,此時就應審慎考慮是否繼續擴大測試範圍。
向迴歸測試套件中新增少量測試用例的操作相對簡單。但需注意,即便每個新增用例的邊際成本不高,長期累積下來也會導致測試套件變得龐大臃腫。從迴歸測試套件中刪除某些測試用例,雖然可以精簡測試規模,但也可能帶來潛在風險。一旦客戶反饋某個被刪除用例原本可檢測出的缺陷,就會造成被動應對的被動局面。
因此,在擴充和精簡迴歸測試套件時,都需要權衡影響,遵循一定原則。適度擴充套件用例有助於提高測試覆蓋面,但也要注意控制測試集整體規模,避免因過度臃腫而影響執行效率。刪減用例時,需要保留覆蓋核心功能場景的測試,並妥善記錄移除的測試點,以備不時之需。綜合平衡測試質量和執行成本,對迴歸測試套件進行持續最佳化,是保證高效測試的關鍵所在。
測試用例選擇
選擇正確的測試用例包括識別直接和間接受影響的測試用例。我們至少應該知道客戶最常使用哪些特性，哪些測試覆蓋了重要的功能，哪些測試經常失敗。其他選擇技術包括線性方程、符號執行、路徑分析、資料流分析、程式依賴圖、系統依賴圖、修改分析、聚類識別、切片、圖遍歷和修改的實體分析。在選擇選擇技術時，考慮以下標準是有用的：
包容性
包容性指的是迴歸測試選擇技術能夠有效識別並納入那些可能暴露由最新軟體更改引入缺陷的測試用例。如果某種技術能夠準確選擇覆蓋了被修改或受影響程式碼區域的測試用例,則該技術被視為具有較高的包容性。包容性對於確保所選測試用例全面覆蓋自上次測試周期以來的所有變更至關重要。任何不完全覆蓋變更區域的測試選擇技術,其包容性都將低於 100%,存在漏測風險。
提高包容性有助於最大限度減少遺漏測試,從而降低軟體更新後產生新缺陷的機率。因此,在評估迴歸測試方案時,包容性是一個重要的衡量標準。技術人員應當努力採用包容性較高的測試選擇機制,以保證測試的全面性,從根本上提高軟體質量。
精度
精度衡量回歸測試選擇技術排除當前測試目標不必要的測試的能力。一個精確的技術應該儘量減少包含的測試，不有助於檢測與最近的修改有關的故障。該標準旨在防止過度測試，過度測試可能導致測試執行時間延長和資源效率低下。
精度
精度衡量回歸測試選擇技術能夠排除與當前測試目標無關的冗餘測試用例。一種精確的技術應當儘可能縮減無助於檢測最新修改引入缺陷的測試範圍。該標準旨在防止測試過度膨脹,避免由此導致的測試執行週期過長、資源利用率低下等效率問題。
精度是評價迴歸測試選擇技術的另一重要指標。高精度技術能夠有效甄別出真正必要的測試點,剔除那些與本次變更無關的用例,從而確保測試資源的高效利用。反之,精度低下的技術將不加甄別地納入大量無關測試,造成資源的極大浪費。
通用性
通用性評估了迴歸測試選擇技術在各種軟體測試場景和領域中的適用性。更通用的技術可以用於廣泛的實際情況，而無需進行大量定製。它不應該為特定型別的軟體或測試環境過度專業化，使其適應不同的開發專案。
接下來，我們將探討回歸測試的四個步驟。
步驟 1：識別修改的程式碼
確定自上次迴歸測試周期以來已修改的軟體的特定部分。這可以透過版本控制系統和變更跟蹤機制來實現。此步驟是後續迴歸測試步驟的基礎。
版本控制和更改跟蹤
識別程式碼修改區域是實施有效迴歸測試的基礎。我們可以利用版本控制系統和變更跟蹤機制來達成這一目標。像 Git、SVN 這樣的版本控制系統能夠保留對軟體原始碼的所有歷史改動記錄。開發人員在提交程式碼變更時,會附帶描述性的提交資訊,有助於後續分析。
除版本控制系統外,變更跟蹤機制如問題跟蹤系統 (JIRA) 或缺陷資料庫也是重要輔助手段。它們記錄了導致程式碼變更的具體需求或缺陷資訊,有利於更全面地刻畫和定位變更點。
透過合理利用上述工具,我們不僅能夠準確獲取程式碼改動的內容和範圍,還可以深入瞭解變更背景及目的,從而更精準地選擇與之相關的測試用例,確保覆蓋所有風險點,提高迴歸測試的針對性和質量。
分析提交歷史記錄
在版本控制系統中，我們可以檢查提交歷史，以檢視對程式碼庫進行了哪些更改。每個提交通常包括有關修改了哪些檔案、新增、刪除或修改了哪些程式碼行的資訊，以及對所做更改的描述。透過分析這個提交歷史，我們可以查明被修改的特定程式碼。
標識修改的檔案和程式碼段
根據提交歷史，我們可以識別修改過的檔案以及這些檔案中發生過更改的程式碼段。這可能包括函式、類、方法，甚至是單行程式碼。在識別修改的程式碼時儘可能細粒度是至關重要的。
文件更改
記錄並理解程式碼變更的具體性質對於指導迴歸測試策略制定至關重要。不同型別的變更如缺陷修復、新功能開發、功能增強、程式碼重構等,對應著不同的風險點和測試側重面,需要採取有針對性的測試方法和策略。只有透徹把握變更本質,我們才能合理規劃迴歸測試的範圍、深度和側重點,避免遺漏重要測試點或資源浪費,從而最大限度保證測試的全面性和有效性。
文件更改
測試和開發團隊之間的無縫溝通合作是確保迴歸測試策略高效可行的關鍵一環。測試人員應當主動與開發人員保持聯絡,全面瞭解本次變更的具體內容、影響範圍以及對軟體功能的潛在影響。
開發人員對於程式碼變動和技術細節有著最直接的認識,而測試人員則更加關注功能表現和質量保障角度。雙方的緊密交流有助於測試人員全方位把握變更實質,從而更準確地評估風險點,制定出覆蓋面廣、針對性強的測試策略和用例。
同時,開發人員也可以藉助測試人員的視角發現自身疏漏,減少遺漏風險。雙方通力合作,相互印證,必能事半功倍,為高質量的迴歸測試奠定堅實基礎。只有測試和開發團隊形成高度默契的協同,迴歸測試的效率和質量才能達到最優水平。
文件更改
除了準確識別出程式碼修改點,我們還應當將其與相應的需求或使用者故事建立可追溯的關聯關係。這一環節有助於確保程式碼修改確實與預期的功能或行為變化一致,併為制定迴歸測試策略提供了明確的目標和範圍。
具體來說,透過追溯程式碼變更與業務需求的關聯,我們能夠全面把握變更的初衷以及對功能的預期影響。進而,測試人員就可以基於此制定出覆蓋所有應被驗證點的充分測試用例,對變更涉及的新舊功能行為都予以全面檢測,從根本上確保系統質量滿足預期。
另一方面,需求與程式碼變更的可追溯性關係,還為我們分析新發現問題的起因提供了重要線索,有助於持續質量改進。因此,建立良好的可追溯機制不僅是迴歸測試的重要保障,也是提升軟體質量的關鍵手段,應當作為測試流程的標配環節。
步驟 2：選擇相關測試
這一步的第一部分涉及評估覆蓋標準，以確定哪些型別的測試應該包含在我們的迴歸測試套件中。覆蓋標準幫助我們定義測試工作的範圍。兩個常見的覆蓋標準是：
Coverage Criteria 覆蓋準則
方法覆蓋
節點覆蓋集中於識別在修改後的程式碼中從未呼叫的方法或函式。這個標準對於確保我們程式碼庫的所有部分都得到執行至關重要，這可以幫助發現死程式碼或未使用的功能。
邏輯覆蓋
邏輯覆蓋率透過分析哪些程式碼路徑受到修改的影響而更進一步。此標準考慮是否呼叫方法以及這些方法中的特定執行路徑。語句覆蓋、分支覆蓋和路徑覆蓋等技術都屬於這一類。它有助於確保呼叫每個方法，並測試不同的執行分支和場景。
測試用例選擇
對於步驟 1 中確定的每個修改，我們需要選擇直接或間接執行修改後程式碼的測試。
直接影響的測試
確定直接覆蓋修改後的程式碼的測試。這些測試專門針對已更改的函式或方法。執行這些測試有助於確保修改按預期工作，並且沒有引入新的 bug。
間接受影響的檢測
某些更改可能會對軟體的其他部分產生連鎖反應。間接影響的測試是那些可能不直接執行修改後的程式碼，但以某種方式與之互動的測試。例如，如果一個模組中的更改影響另一個模組的輸出，則還應考慮對後一個模組進行測試。
測試充分性
評估我們所選測試的充分性至關重要。問問你自己這些測試是否提供了修改後程式碼的足夠覆蓋率。考慮變更的複雜性以及對軟體行為的潛在影響。在某些情況下，我們可能需要建立專門針對更改的新測試。
文件
保留完整的文件，記錄每次修改選擇的測試。該文件確保了透明度，並允許輕鬆跟蹤不同程式碼更改的測試覆蓋率。
步驟 3：平衡測試套件大小
雖然選擇充分覆蓋修改後的程式碼的測試是必要的，但避免在迴歸測試套件中包含所有可能的測試也同樣重要。管理一個大規模的測試套件會變得非常耗時和資源密集。迴歸測試的第三步可以關注於有效地管理迴歸測試套件的大小。在徹底的測試和實用性之間取得平衡是至關重要的。
避免過多的測試
在我們的迴歸測試套件中包含每一個可以想到的測試通常是不可行的。隨著軟體的發展，測試的數量會呈指數級增長，這使得在合理的時間範圍內執行所有測試變得不切實際。執行一組詳盡的測試可能會大大減慢測試過程，使其難以跟上開發的步伐。我們的迴歸測試套件的最佳大小應該確定。這個規模可以基於資源可用性、時間限制、風險、開發過程和優先順序等因素。
可用資源
由於軟體不斷發展演進,迴歸測試套件的規模需要根據資源可用性、時間限制、風險評估、開發流程和測試優先順序等多方面因素綜合確定,在測試覆蓋面和執行效率之間尋求平衡,避免測試集過大導致執行效率低下,也防止測試範圍過小遺漏重要測試點。
時間限制
瞭解專案的截止日期和釋出計劃對於合理安排迴歸測試工作是至關重要的。我們應該以此為時間約束,在有限的工期內完成足夠覆蓋核心場景和高風險區域的迴歸測試,確保測試質量和進度要求的平衡。精心規劃、分配資源、最佳化流程,努力在既定時間視窗內高效完成迴歸測試任務,是測試團隊應當時刻把握的工作重點。
風險評估
評估程式碼修改的重要性和潛在缺陷影響,並根據風險程度調整測試投入,是最佳化迴歸測試策略的關鍵手段。具體來說，有以下幾點需要注意：
- 對於高度關鍵的核心程式碼修改,我們需要制定更加全面徹底的測試計劃,擴大測試覆蓋面,增加測試深度,確保質量無遺漏。
- 而對於一些非核心的次要修改,可以適當壓縮測試規模,使用較小的測試套件即可覆蓋,從而節省資源。
- 透過對修改程式碼的重要性和影響範圍進行評估和分級,我們能夠更加精準地調配測試資源,對高風險區域加大投入,對低風險區域控制投入。
- 這種以風險為導向的測試策略能最大限度發揮有限的測試資源效用,在保證高風險質量的同時,也避免了對低風險區域的資源浪費。
- 評估和分級的過程需結合開發、測試、運維等部門的意見,充分了解系統和修改的重要性,確保分級的準確性。
開發過程注意事項
測試套件大小的選擇應該與開發過程保持一致。在敏捷方法中，變更頻繁，迴歸測試通常會更頻繁地執行（例如，在每次 sprint 或迭代之後）。因此，每個迴歸週期的測試套件大小可能會更小，以保持測試的敏捷性和對變化的響應。
在更傳統的開發過程中，更改不太頻繁，釋出也不太頻繁，迴歸測試可能不太頻繁地進行。在這種情況下，我們可能有更大的測試套件，覆蓋更廣泛的功能。
優先順序排序
在確定測試的優先順序時，我們可以考慮多種因素，例如關鍵業務功能、常用功能或具有缺陷歷史的區域。透過這些因素，我們可以確保軟體的最關鍵部分得到徹底的測試，即使我們對測試套件的大小有限制。優先測試關鍵業務功能可以確保系統的核心功能正常執行，從而保障使用者的基本需求。對於常用功能的優先測試能夠覆蓋使用者最常用的部分，提升使用者體驗和滿意度。而對於具有缺陷歷史的區域的優先測試，則可以幫助我們解決已知的問題，提高軟體的穩定性和可靠性。綜合考慮這些因素，我們可以制定出更加全面和有效的測試策略，確保有限的測試資源得到最大程度的利用，最大程度地提高軟體的質量和可靠性。
文件
我們應該認真記錄關於測試套件大小的決定，因為這對我們的測試策略至關重要。這份文件將成為我們未來測試工作的指導方針，為所有利益相關者提供清晰的透明度。透過記錄我們的決策過程，我們可以更好地追蹤測試套件的發展和變化，確保測試的全面性和有效性。這也有助於避免重複的測試工作，並確保資源的最佳利用。此外，記錄決策過程還可以幫助我們更好地理解測試套件大小對專案成功的影響，從而為未來的決策提供更多的參考依據。因此，我們應該把這一步驟視為測試流程中不可或缺的一環，認真記錄並持續更新相關文件。
平衡迴歸測試套件的大小對於有效的測試至關重要。它使我們能夠將測試工作集中在最重要的地方，同時確保我們可以在專案的限制範圍內完成迴歸測試。透過根據我們的特定上下文定製我們的測試套件大小，我們可以在迴歸測試的徹底性和實用性之間取得適當的平衡。
步驟 4：執行測試並處理結果
有了一個平衡的迴歸測試套件，我們現在可以執行它並評估我們的測試結果。
失敗的測試
如果一個或多個迴歸測試失敗，調查失敗是由於軟體修改中的錯誤還是迴歸測試本身的問題。測試失敗的原因是正確的還是錯誤的？測試失敗的正確原因是它發現了一個 bug。一個錯誤的原因是沒有 bug，測試失敗是因為它是如何編寫或執行的。在這兩種情況下都需要額外的工作。
透過的測試
如果沒有迴歸測試失敗，那麼我們應該能夠自信地回答以下問題：我們的測試透過是出於正確的原因還是錯誤的原因？一個正確的原因是，測試可以透過正常執行的程式碼部分。然而，測試可能會透過，因為它實際上可能並未執行任何有效測試。這種情況可能是因為測試被認為是舊的，沒有得到適當的維護，目前沒有測試到它預期的功能。它也可能偶然地透過了測試。
測試自動化
迴歸測試是測試自動化帶來最大好處的領域。理想情況下，我們希望確保所有迴歸測試都是自動化的。如果這總是可行的和實用的，那麼迴歸測試的執行將不需要手動操作，並且可以在任何時候重複。不幸的是，可能會有自動化迴歸測試因未知原因而失敗，其中一些經常失敗，另一些則不規則。有些測試執行得快，有些則慢，而有些測試可能在某些執行中執行得快，在另一些執行中執行得慢。像這樣的問題可能會得到解決，但是如果我們不解決它們，隨著迴歸測試數量的增加，它們只會變得更糟。
測試自動化在持續整合/持續交付（CI/CD）管道中使用時最有價值。如果我們的專案遵循 CI/CD 管道，我們可能有機會自動化和簡化迴歸測試。作為 CI/CD 過程的一部分，可以更頻繁地執行更小的、有針對性的測試套件，在開發週期的早期捕獲迴歸。
自動化測試與手動測試有著相同的目標：為我們提供一個清晰的畫面，讓我們瞭解被測系統如何按照預期的方式工作。我們應該對我們的手動測試結果充滿信心，同樣也應該對我們的自動化測試結果充滿信心。當一個自動化的迴歸測試套件完成執行時，我們應該確信測試結果描述了被測系統的真實情況。我們對測試結果的信心越高，就越能夠減少在除錯自動化測試結果和識別真實的 bug，或修復無用測試上的時間和精力。
- 2021 年原創合集
- 2022 年原創合集
- 2023 年原創合集
- 服務端功能測試
- 效能測試專題
- Java、Groovy、Go、Python
- 單元&白盒&工具合集
- 測試方案&BUG&爬蟲&UI 自動化
- 測試理論雞湯
- 社群風采&影片合集