一切都是為了改變。

“當源代碼被修改時，我有哪些選擇來維護我現有的測試？” 這是我在與客戶交談時遇到的一個非常常見的問題。

我的一些對話者指出他們必須重構他們的軟件，其他一些人會談論重新設計的努力。

首先，我注意到這兩個與軟件更改相關的概念在人們的頭腦中并不總是很清楚，有時會在錯誤的環境中使用。這些概念對您來說可能非常清楚，但如果不是，這里有一些提示可以幫助您理解差異。

重新設計和重構軟件有什么區別？

這些概念之間的主要區別在于：重新設計意味著您修改軟件以改變它的功能，而重構則是努力修改它的工作方式。

出于多種原因進行重新設計工作。例如，由于硬件更改，軟件需要在不同的 CPU 上運行或必須處理新的外圍設備，因此需要修改或擴展代碼以解決這些物理修改并提供新功能。當軟件需要與新的或更新的 3 rd方庫交互時，也可能發生重新設計，這些庫提供了有益于您的應用程序的新服務。您可能會找到許多其他重新設計的原因，但在大多數情況下，在此上下文中執行的軟件更改會影響一般行為或修改后的應用程序提供的功能。

與重新設計相反，重構是努力優化代碼的內部實現，以提高其可維護性并降低其總體運營成本。和許多人一樣，我相信 Martin Fowler 在他的“重構書”中寫了軟件重構的最佳定義之一：

“對軟件的內部結構進行了更改，使其更易于理解且修改成本更低，而不會改變其可觀察到的行為。”

鑒于此定義，重構通常由開發人員在以下情況下執行：

需要將技術債務控制在可容忍的水平，即低于從頭開始重新構建整個代碼看起來更經濟的線以下。

降低復雜性和內部依賴，使軟件更模塊化、更容易擴展、對開發團隊中的新人更易讀和更易管理等。

確保隨著時間的推移，原始設計保持可理解和清晰，并保留其預期功能。..。..

鑒于我們現在對重新設計與重構工作有了更清晰的了解，

哪些情況需要重新驗證您的軟件？

好吧，軟件測試的本質是它們主要檢查代碼是否符合其目的。換句話說，他們根據應用程序的功能需求驗證組成系統的每個軟件單元的行為是否符合預期。話雖如此，如果您嘗試重新設計代碼，則必須對其進行測試以確保新功能已根據新引入的要求進行驗證，同時確保這些新擴展不會在您現有的通過測試中引入回歸。

您可能會爭辯說，重構工作只會影響軟件內部結構，因此不一定會影響代碼接口和根據應用程序需求交付的一般服務。是的，但是…… 像任何其他開發活動一樣，重構是引入新錯誤的一種非常簡單的方法，因此您必須重新測試您的軟件。維護一組完整且詳盡的通過測試將確保您的重構不會導致代碼中的回歸錯誤未被檢測到。確實，每當您進行小的更改時，您都應該重新執行現有的測試作為安全網，以檢查您沒有修改預期的行為。經過一系列增量更改后，您將以安全的方式達到最初目標的重構狀態。

大多數組織希望通過在源代碼更改時更新這些測試來保留先前測試投資的價值。但這會導致高昂的測試維護成本。該解決方案并不像僅僅識別受代碼更改影響的受影響測試的子集以重新運行（有時稱為測試影響分析或基于更改的測試）那么簡單。測試維護的昂貴部分是開發人員花費在識別依賴關系和更新相應測試以確保它們與修改后的軟件同步的工作。

那么適當的測試自動化如何降低這些測試維護成本呢？

1） 通過 對代碼變更和測試依賴的初步分析：

· 了解正在測試的代碼的更改（通過保留上次測試時的代碼信息并將其與更改的代碼進行比較）

· 識別哪些測試受到代碼更改的影響

· 在單個視圖中識別影響測試的所有代碼更改

· 識別可能影響現有測試實現的代碼覆蓋率的代碼更改

2） 通過為開發人員提供自動測試更新的指導選擇，以便重新同步源代碼和測試：

? 對于每個代碼更改，建議對測試腳本和用例進行適當的更新

? 自動重構測試腳本以節省時間和成本

3） 對于主要影響軟件內部結構的代碼更改，自動生成安全網或通過測試的基線，以便：

? 在回歸測試或持續集成期間查明故障

? 識別可測試性問題，例如無法訪問的代碼

作為專業的軟件供應商，QA Systems 敏銳地意識到在軟件修改的情況下控制測試維護成本的重要性。為了解決這個問題，我們開發了作為我們的測試解決方案 Cantata的一部分，一個代碼更改分析和管理功能以及一個AutoTest生成框架，它們是在您的軟件項目的整個生命周期中自動化單元和集成測試維護的獨特技術。當您需要管理測試時，重新設計或重構您的軟件不再是（煩人的）問題！

審核編輯：郭婷