回歸測試的四個(gè)步驟

本文提供了一種創(chuàng)建和更新回歸測試套件的結(jié)構(gòu)化方法。回歸測試套件中應(yīng)該包含哪些類型的測試?應(yīng)該運(yùn)行哪些回歸測試，如何應(yīng)對失敗的回歸測試，回歸測試套件如何發(fā)展?這些問題和其他考慮因素將逐步探討。我將首先探討回歸測試的基本動態(tài)和考慮因素。然后，我將提供一組有助于通過回歸測試實(shí)現(xiàn)長期軟件穩(wěn)定性的步驟。

回歸測試的具體細(xì)節(jié)

假設(shè)我們對軟件代碼做了一些更改，任何類型的更改。我們?nèi)绾未_信這些更改不會對我們的代碼整體產(chǎn)生負(fù)面影響?獲得信心的一種方法是進(jìn)行徹底的回歸測試。編寫和執(zhí)行測試來檢查和探索我們的代碼在更改后的行為。因此，我們編寫和執(zhí)行的測試越多，我們就越有信心。是的，但也需要考慮實(shí)際成本——編寫、執(zhí)行和維護(hù)回歸測試套件所需的時(shí)間、精力和金錢。

將所有可能的測試都包括進(jìn)去會導(dǎo)致回歸測試套件過于龐大而難以管理 — 而且，由于軟件經(jīng)常發(fā)生更改，因此運(yùn)行起來非常困難。如果回歸測試不能及時(shí)完成，開發(fā)過程就會中斷。投入資金來解決這個(gè)問題是值得的，例如增加計(jì)算資源和/或雇用新員工來執(zhí)行測試。然而，在某些時(shí)候，增加測試的附加價(jià)值可能不值得花費(fèi)執(zhí)行測試所需的額外資源。

另一方面，太小的測試套件無法充分覆蓋軟件的功能，并且會將太多的錯誤傳遞給用戶。

向回歸測試套件添加少量測試通常很簡單。即使每個(gè)額外測試的邊際成本很小，但累積起來，測試套件也會變得難以處理。從回歸測試套件中刪除測試可能會產(chǎn)生問題。如果客戶報(bào)告了被刪除的測試之一會發(fā)現(xiàn)的錯誤，該怎么辦?

測試用例選擇技術(shù)

選擇正確的測試用例涉及識別直接和間接受影響的測試用例。我們至少應(yīng)該知道客戶最常使用哪些功能，哪些測試涵蓋重要功能以及哪些測試經(jīng)常失敗。其他選擇技術(shù)包括線性方程、符號執(zhí)行、路徑分析、數(shù)據(jù)流分析、程序依賴圖、系統(tǒng)依賴圖、修改分析、集群識別、切片、圖形遍歷和修改后的實(shí)體分析。在選擇選擇技術(shù)時(shí)，考慮以下標(biāo)準(zhǔn)很有用：

包容性

包容性是指回歸測試選擇技術(shù)在多大程度上包含了可能暴露軟件最近更改所引入的故障的測試。如果一種技術(shù)能夠有效地識別和選擇涵蓋代碼修改或受影響部分的測試，則該技術(shù)被認(rèn)為更具包容性。包容性對于確保所選測試全面覆蓋自上一個(gè)測試周期以來所做的更改至關(guān)重要。不安全的技術(shù)的包容性低于 100%。

精確

精確度衡量回歸測試選擇技術(shù)排除當(dāng)前測試目標(biāo)不需要的測試的能力。精確技術(shù)應(yīng)盡量減少包含對檢測與最近修改相關(guān)的故障沒有幫助的測試。此標(biāo)準(zhǔn)旨在防止過度測試，因?yàn)檫^度測試可能導(dǎo)致測試執(zhí)行時(shí)間延長和資源效率低下。

效率

效率評估使用特定技術(shù)執(zhí)行回歸測試所需的計(jì)算和時(shí)間資源。高效的技術(shù)應(yīng)該能夠快速識別和選擇相關(guān)的測試子集，同時(shí)最大限度地縮短總體測試時(shí)間。這對于具有大量測試套件的大型軟件系統(tǒng)尤其重要，因?yàn)樾枰斓臏y試周期來支持敏捷開發(fā)實(shí)踐。

概論

通用性評估回歸測試選擇技術(shù)在各種軟件測試場景和領(lǐng)域的適用性。更通用的技術(shù)可以在廣泛的實(shí)際情況中使用，而無需進(jìn)行大量定制。它不應(yīng)該針對特定類型的軟件或測試環(huán)境過度專業(yè)化，使其能夠適應(yīng)不同的開發(fā)項(xiàng)目。

接下來，我們將探討回歸測試的四個(gè)步驟。我們首先確定被測修改后的代碼。確定需要執(zhí)行的測試，然后是平衡測試套件大小的步驟。這一切都與我們的測試執(zhí)行結(jié)果有關(guān)。我們測試的范圍有多廣，我們的測試運(yùn)行得有多快，我們對測試結(jié)果提供被測系統(tǒng)的真實(shí)情況有多大信心?隨著我們在四個(gè)步驟中的每一步都做得越來越好，軟件的長期穩(wěn)定性就可以隨之而來。

步驟 1：識別修改的代碼

確定自上一次回歸測試周期以來軟件中被修改的具體部分。這可以通過版本控制系統(tǒng)和變更跟蹤機(jī)制來實(shí)現(xiàn)。此步驟是后續(xù)回歸測試步驟的基礎(chǔ)。

版本控制和變更跟蹤

為了識別修改的代碼，我們可以使用版本控制系統(tǒng)和變更跟蹤機(jī)制。Git、SVN 或 Mercurial 等版本控制系統(tǒng)會保留對軟件源代碼所做更改的歷史記錄。開發(fā)人員使用這些系統(tǒng)提交更改以及描述性提交消息。變更跟蹤機(jī)制還可以包括問題跟蹤系統(tǒng)，例如 JIRA 或錯誤數(shù)據(jù)庫。

分析提交歷史

在版本控制系統(tǒng)中，我們可以檢查提交歷史記錄以查看代碼庫中發(fā)生了哪些更改。每次提交通常都包含有關(guān)修改了哪些文件、添加、刪除或修改了哪些代碼行以及對所做更改的描述的信息。通過分析此提交歷史記錄，我們可以精確定位已更改的具體代碼。

識別已修改的文件和代碼部分

根據(jù)提交歷史，我們可以識別修改過的文件以及這些文件中發(fā)生更改的代碼部分。這可能包括函數(shù)、類、方法，甚至是個(gè)別代碼行。在識別修改過的代碼時(shí)，盡可能細(xì)致是至關(guān)重要的。

文檔變更

記錄變更的性質(zhì)很有幫助。這些是修改、錯誤修復(fù)、新功能、增強(qiáng)功能還是其他類型的變更?了解變更的性質(zhì)可以指導(dǎo)我們的回歸測試策略。

與開發(fā)團(tuán)隊(duì)的合作

在此步驟中，測試團(tuán)隊(duì)和開發(fā)團(tuán)隊(duì)之間的協(xié)作至關(guān)重要。測試人員應(yīng)與開發(fā)人員溝通，以清楚了解變更及其對軟件功能的影響。

可追溯性

在已識別的修改代碼與相應(yīng)的需求或用戶故事之間建立可追溯性。這有助于確保修改與預(yù)期功能一致，并且我們的回歸測試充分涵蓋了這些更改。

在第 1 步結(jié)束時(shí)，我們應(yīng)該有一個(gè)完整的代碼修改列表，以及有關(guān)更改的詳細(xì)信息。此信息可作為第 2 步中選擇相關(guān)測試的基礎(chǔ)，確保我們將回歸測試工作重點(diǎn)放在最有可能受到最近修改影響的軟件領(lǐng)域。這種有針對性的方法是我們回歸測試結(jié)構(gòu)的支柱。它對于高效和有效的回歸測試至關(guān)重要。

第 2 步：選擇相關(guān)測試

一旦我們確定了修改后的代碼，下一步就是選擇相關(guān)測試以納入我們的回歸測試套件。這一步對于確保我們徹底測試對軟件所做的更改至關(guān)重要。

覆蓋標(biāo)準(zhǔn)

此步驟的第一部分涉及評估覆蓋率標(biāo)準(zhǔn)，以確定哪些類型的測試應(yīng)包含在我們的回歸測試套件中。覆蓋率標(biāo)準(zhǔn)幫助我們定義測試工作的范圍。兩個(gè)常見的覆蓋率標(biāo)準(zhǔn)是：

節(jié)點(diǎn)覆蓋率(或方法調(diào)用覆蓋率)

節(jié)點(diǎn)覆蓋側(cè)重于識別修改后的代碼中從未調(diào)用的方法或函數(shù)。此標(biāo)準(zhǔn)對于確保代碼庫的所有部分都得到執(zhí)行至關(guān)重要，這有助于發(fā)現(xiàn)死代碼或未使用的功能。

結(jié)構(gòu)覆蓋

結(jié)構(gòu)覆蓋更進(jìn)一步，分析哪些代碼路徑受到修改的影響。此標(biāo)準(zhǔn)考慮是否調(diào)用了方法以及這些方法內(nèi)的具體執(zhí)行路徑。語句覆蓋、分支覆蓋和路徑覆蓋等技術(shù)屬于此類別。它有助于確保調(diào)用每個(gè)方法，并測試不同的執(zhí)行分支和場景。

測試選擇

對于步驟 1 中確定的每個(gè)修改，我們需要選擇直接或間接執(zhí)行修改后代碼的測試。

直接受影響的測試

確定直接覆蓋修改后代碼的測試。這些測試專門針對已更改的函數(shù)或方法。運(yùn)行這些測試有助于確保修改按預(yù)期運(yùn)行并且沒有引入新的錯誤。

間接影響的測試

某些更改可能會對軟件的其他部分產(chǎn)生連鎖反應(yīng)。間接影響的測試可能不直接執(zhí)行修改后的代碼，但會以某種方式與其交互。例如，如果一個(gè)模塊的更改影響另一個(gè)模塊的輸出，則還應(yīng)考慮對后者模塊的測試。

測試充分性

評估我們所選測試的充分性至關(guān)重要。問問自己這些測試是否對修改后的代碼提供了足夠的覆蓋范圍?？紤]更改的復(fù)雜性和對軟件行為的潛在影響。在某些情況下，我們可能需要創(chuàng)建專門針對更改的新測試。

文檔

保存每次修改所選擇的測試的完整文檔。此文檔可確保透明度，并可輕松跟蹤不同代碼更改的測試覆蓋率。

在第 2 步結(jié)束時(shí)，我們應(yīng)該有一個(gè)定義良好的回歸測試套件，其中包含有效驗(yàn)證修改后的代碼所需的測試。這種有針對性的測試選擇方法可確保我們的測試工作全面，幫助我們在開發(fā)周期的早期發(fā)現(xiàn)回歸和缺陷。

步驟 3：平衡測試套件大小

雖然選擇能夠充分覆蓋修改后的代碼的測試至關(guān)重要，但同樣重要的是避免在回歸測試套件中包含所有可能的測試。管理龐大的測試套件可能會耗費(fèi)大量時(shí)間和資源。回歸測試的第三步可以專注于有效管理回歸測試套件的大小。在全面測試和實(shí)用性之間取得平衡至關(guān)重要。

避免包括所有可能的測試

在我們的回歸測試套件中包含所有可以想到的測試通常是不可行的。隨著軟件的發(fā)展，測試數(shù)量會呈指數(shù)級增長，因此在合理的時(shí)間范圍內(nèi)執(zhí)行所有測試是不切實(shí)際的。運(yùn)行一組詳盡的測試可能會大大減慢測試過程，從而難以跟上開發(fā)速度。應(yīng)該確定回歸測試套件的最佳大小。該大小可以基于資源可用性、時(shí)間限制、風(fēng)險(xiǎn)、開發(fā)過程和優(yōu)先級等因素。

可用資源

考慮可用于測試的硬件、軟件和團(tuán)隊(duì)成員。有限的資源可能會限制我們的測試套件的大小。

時(shí)間限制

注意項(xiàng)目截止日期和發(fā)布時(shí)間表。我們應(yīng)該力爭在可用時(shí)間內(nèi)完成回歸測試，同時(shí)確保足夠的覆蓋范圍。

風(fēng)險(xiǎn)評估

評估修改代碼的重要性和缺陷的潛在影響。高度關(guān)鍵的代碼更改可能需要更廣泛的測試，而不太重要的更改可以用較小的測試套件進(jìn)行覆蓋。

開發(fā)流程注意事項(xiàng)

測試套件大小的選擇應(yīng)該與開發(fā)過程保持一致。

在敏捷方法中，變化頻繁，回歸測試通常執(zhí)行得更頻繁(例如，在每個(gè)沖刺或迭代之后)。因此，每個(gè)回歸周期的測試套件大小可能較小，以保持測試敏捷并對變化做出響應(yīng)。

在更傳統(tǒng)的開發(fā)過程中，變更頻率較低，發(fā)布頻率也較低，因此回歸測試的執(zhí)行頻率也較低。在這種情況下，我們可能會有更大的測試套件，涵蓋更廣泛的功能。

優(yōu)先級

考慮根據(jù)關(guān)鍵業(yè)務(wù)功能、常用功能或存在缺陷歷史的區(qū)域等因素對測試進(jìn)行優(yōu)先排序。即使測試套件大小有限，這也有助于確保軟件中最關(guān)鍵的部分得到徹底測試。

文檔

我們關(guān)于測試套件大小的決定應(yīng)該記錄下來。該文檔將作為我們測試策略的指南，并為所有利益相關(guān)者提供透明度。

平衡回歸測試套件的大小對于高效測試至關(guān)重要。它使我們能夠?qū)y試工作重點(diǎn)放在最重要的地方，同時(shí)確保我們能夠在項(xiàng)目限制內(nèi)完成回歸測試。通過根據(jù)具體情況調(diào)整測試套件的大小，我們可以在回歸測試的徹底性和實(shí)用性之間取得適當(dāng)?shù)钠胶狻?

步驟 4：執(zhí)行測試并處理結(jié)果

有了平衡的回歸測試套件，我們現(xiàn)在可以執(zhí)行它并評估我們的測試結(jié)果。

失敗的測試

如果一個(gè)或多個(gè)回歸測試失敗，請調(diào)查失敗是由于軟件修改中的錯誤還是回歸測試本身的問題。測試失敗的原因是正確的還是錯誤的原因?測試失敗的正確原因是發(fā)現(xiàn)了錯誤。錯誤原因是沒有錯誤，測試失敗是因?yàn)榫帉懟驁?zhí)行方式不當(dāng)。無論哪種情況都需要額外的工作。

通過的測試

如果沒有回歸測試失敗，那么我們應(yīng)該能夠自信地回答以下問題。我們的測試通過是出于正確的原因還是錯誤的原因?發(fā)生這種情況的一個(gè)正確原因是測試執(zhí)行了代碼中正常運(yùn)行的部分。但是，測試可能會通過測試，因?yàn)樗鼘?shí)際上可能什么都沒測試。這是一個(gè)沒有得到適當(dāng)維護(hù)的舊測試，它目前沒有測試它打算測試的內(nèi)容。它碰巧意外地通過了測試。

測試自動化

回歸測試是測試自動化帶來最大好處的領(lǐng)域。理想情況下，我們希望確保所有回歸測試都是自動化的。如果這始終可行且實(shí)用，那么回歸測試的執(zhí)行將不需要人工干預(yù)，并且可以隨時(shí)重復(fù)。不幸的是，有些自動化回歸測試可能會因未知原因而失敗，而有些則經(jīng)常失敗，有些則不定期失敗。有些測試執(zhí)行得很快，有些則很慢，有些測試可能在某些運(yùn)行中執(zhí)行得很快，而在其他運(yùn)行中執(zhí)行得很慢。這些問題可能會得到解決，但如果我們不解決它們，隨著回歸測試數(shù)量的增加，它們只會變得更糟。

測試自動化在持續(xù)集成/持續(xù)交付 (CI/CD) 流程中使用時(shí)最有價(jià)值。如果我們的項(xiàng)目遵循 CI/CD 流程，我們可能有機(jī)會自動化和簡化回歸測試。作為 CI/CD 流程的一部分，可以更頻繁地運(yùn)行較小、有針對性的測試套件，從而在開發(fā)周期的早期發(fā)現(xiàn)回歸問題。

請記住，自動化測試與手動測試的目標(biāo)相同：讓我們清楚地了解被測系統(tǒng)如何按預(yù)期運(yùn)行。我們應(yīng)該對手動測試結(jié)果充滿信心，也應(yīng)該對自動化測試結(jié)果充滿信心。當(dāng)自動回歸測試套件完成執(zhí)行時(shí)，我們應(yīng)該確信測試結(jié)果描繪了被測系統(tǒng)的真實(shí)情況。我們越有信心，我們花在調(diào)試自動化測試結(jié)果和識別真正的錯誤或修復(fù)無用測試上的時(shí)間就越少。

包起來

為了適應(yīng)軟件變化，我們必須首先認(rèn)識到，適用于一個(gè)軟件版本的回歸測試套件可能不足以滿足后續(xù)版本的需要。第一步是確定代碼中發(fā)生了哪些變化。我們必須考慮不同類型的代碼變化，例如創(chuàng)建新功能、改進(jìn)現(xiàn)有功能、修復(fù)錯誤和故障、重構(gòu)和性能改進(jìn)。即使功能保持不變，我們也必須重新評估回歸測試套件的適用性，尤其是在代碼重組的情況下。

第二步是確定要將哪些測試納入我們的回歸測試套件。我們可以選擇涵蓋步驟 1 中確定的代碼更改的所有相關(guān)測試。應(yīng)根據(jù)需要創(chuàng)建或修改回歸測試套件，以納入涵蓋更改的功能或代碼路徑的新測試。請記住，沒有完美的指標(biāo)。例如，節(jié)點(diǎn)覆蓋率可能是一個(gè)有用的指標(biāo)，但即使節(jié)點(diǎn)覆蓋率很高，測試套件中也可能存在差距。例如，測試套件可能涵蓋程序中的所有節(jié)點(diǎn)，但可能不會測試重要的輸入值或執(zhí)行路徑。

第三步是平衡測試套件的大小。這一點(diǎn)非常重要，因?yàn)闇y試數(shù)量增加和/或測試執(zhí)行完成所需的時(shí)間成為障礙。由于軟件更改而不再相關(guān)的過時(shí)測試可以被刪除。

測試執(zhí)行完成后，仔細(xì)檢查測試結(jié)果非常重要。一旦我們確信測試結(jié)果值得信賴，我們就可以與適當(dāng)?shù)睦嫦嚓P(guān)者分享我們的發(fā)現(xiàn)。