通過前面的描述你已經對重構中“小步快跑”的開發模式有了一個清楚的認識。學會和習慣小步快跑的開發模式，對於重構工作極其重要，因為它讓這種大範圍、大幅度修改程式碼的重構工作變得不再像以往那樣讓人膽戰心驚。究其原因，雖然從結果上是在大範圍、大幅度調整，但每一步卻是小範圍、小福度調整，並且能保證每一步都是正確的。

然而，這裡有一個非常重要的假設條件，那就是“保證每一步都是正確的”，這是怎麼保證的呢？就這個問題，我們需要展開來認真討論討論。

毫無疑問，系統重構就其結果來看，是在對軟體系統進行大範圍、大幅度的改動，而這種改動過去我們是無法想象的，因為它實在是改動太大了，一不小心就會產生一個毀滅性的結果。這就是許多人不敢輕易嘗試系統重構的重要原因。

是的，這就是真相，如果你不能正確地驗證每一步系統重構是否正確，或者你的驗證方式存在缺陷，即使小步快跑也不能解決重構帶來的風險。所以我們說，系統重構，你不能沒有保險索。這個保險索就是每次重構後正確的測試方法。

什麼是程式程式碼正確的測試方法，其在不同的場景中標準是不一樣的。但與其它測試不同，系統重構在測試程式碼正確性方面卻有自己獨特的方法。系統重構，從自身的定義上就把其程式碼正確性的驗證方式描述得十分明白，那就是“不改變軟體外部行為”。

“不改變軟體外部行為”，我們可以從多個層面上看待這個問題。首先從功能層面上看，重構前系統提供給使用者什麼樣的功能，重構後也應當提供同樣的功能。說得更加具體一些，重構前，使用者從介面上輸入什麼內容，發出什麼請求，得到什麼結果，那麼重構後用戶應當得到同樣的結果。這種結果可能體現在前端介面所展現的結果中，也可能體現在此處操作後存入資料庫的資料中，即重構前後系統存入資料庫的資料也應當是一致的。存入資料庫的資料同樣是測試中系統輸出的一種。

從功能層面再往下鑽就到了程式碼層面。開啟我們的軟體系統，有各個層次、各項介面和各種函式。我們進行系統重構往往是在某個層次、某項介面或某個函式上進行的重構。比如，我們對某項介面進行重構，那麼我們可能會修改這個介面的實現類、方法函式、底層呼叫類，但不論怎麼修改，這個介面必須保持不變。也就是說，我們程式碼層面的重構，“不改變軟體外部行為”是針對的這個介面。你可以重構介面內部，但必須保證介面外部是不變的。

所以，系統重構的測試可以從兩個層面來進行：系統測試與單元測試。系統測試往往是一種手工測試，當然也可以使用QTP等工具進行一些簡單的錄製。重構前我們首先通過需求文件確認系統現有功能，根據現有功能設計測試用例。然後進入系統，確保每個測試通過，並錄製成QTP指令碼。這樣，我們對重構的準備工作就完成了。在整個測試過程中，我們每完成一次重構就去手工執行這些測試，或者執行QTP指令碼，保證每個測試通過。如果測試不通過，則要麼尋找問題原因並解決，要麼就恢復到上次測試的版本，此次重構宣佈失敗。

反覆地手工進行同樣的測試是一件比較煩人的事，因此你可以有兩個選擇：錄製QTP指令碼，以及在介面層面建立自動化測試程式。這裡所說的自動化測試程式是指那些基於JUnit編寫的自動化測試程式，它實際上是在程式碼層面進行的單元測試。建立自動化測試的關鍵在於我們在哪個層面建立測試。程式碼有許多層次，有函式級別、有類級別、有介面或抽象類級別，從系統分層結構來說有底層、DAO層、BUS層、Web層。每次重構都是站在某個層次進行重構，因此自動化測試程式碼也應當在這個層次上寫。比如最初的重構是在函式層次上進行的，就應當對函式寫測試程式碼；後來在物件層次上進行重構，就對物件寫測試程式碼；再到介面層次……

與手工測試一樣，在系統重構前，我們首先保證原有程式碼自動化測試通過。然後執行重構，保證每次重構都能夠測試通過，如此往復。但重構中的自動化測試有一個問題就是，測試介面不太穩定。起初是在函式級別進行的重構，我們寫了針對函式的測試程式碼。但隨著重構的深入，我們開始在物件層面進行重構了，我們可能要調整原有的函式。這時將意味著原有的針對函式編寫的測試程式碼將失效而必須要遺棄，這不得不說是一種浪費。因此我給大家的建議是，不要過早編寫自動化測試程式碼，它不一定能節省我們的時間，甚至可能花費更多。最初的重構可以採用手工測試或QTP測試的方式進行。

特別說明：希望網友們在轉載本文時，應當註明作者或出處，以示對作者的尊重，謝謝！