重構學習筆記(4)-大話重構第四章-保險索下的系統重構-筆記

大話重構

你不能沒有保險索

書中提及的針對軟體系統進行大範圍的、大幅度改動、就會造成毀滅性的結果,很多人不敢嘗試系統重構的原因。

在筆者實務上很常見系統的祖產是家常便飯,因為這種系統改動幅度風險相當高,即便採用【小步快跑】也一定有風險…

在書上提及的部分:這個保險索就是重構後的正確測試方法

不改變軟體的外部行為,功能層面來看以下為:

  • 重構前,使用者什麼樣的功能,重構應當提供同樣的功能
  • 重構前,輸入什麼樣的請求得到運算結果,重構後也應得到相同的結果

筆者曾經在改寫vb 6轉移.net API的時候就會將過程的部分搬移,先將邏輯搬移,確保程式的輸入,輸出是對的,在資料庫寫入的結果,舊程式跑過一次與新程式跑過,兩者比對,測試不同情境也沒問題的時候先上線在開始提取類別,提取介面,反覆的測試,讓後續接手維護成本沒這麼高,不改寫的狀況下,一堆人搶那唯一windows 98的環境去vb 6 debug…成本時間浪費相當高…而且也不好debug…

系統重構測試方法

  • 系統測試
  • 單元測試

系統測試:透過QTP進行簡單錄製、重構前透過需求確認系統的現有功能,根據現有功能設計測試案例,進入系統,,確保每個測試都通過,並錄製QTP。

註記:每完成一次重構就手動測試或執行QTP腳本,保證測試通過,若不通過,找尋問題並解決或者退到上次的測試版本,重構失敗。

不要過早寫自動化測試程式,它不一定節省時間,可能花費更多,初期重構可以採用手動測試或QTP錄製測試進行。

 

遺留系統共同的特點

  • 程式碼亂
  • 沒有清晰介面
  • 程式耦合度高
  • 相互依賴嚴重

撰寫自動化測試程式前

確保測試程式已經與web容器與其他設備驅動程式相關解耦合。

其實筆者解讀是例如像DB存取驅動或API及廠商提供SDK…等都要進行解耦合。

不合適自動化測試:就是存取資料庫程式,因為要跟程式要跟資料庫互動,結果跟資料庫有關,因為會可能改狀態或是環境問題等…跟資料庫存取部分就要進行Mock。

當進行【系統重構】就要把資料庫存取相關從業務邏輯抽離出來寫入到DAO,在C#來說應該是Repository Layer,最後Mock的Repository Layer不會存取資料庫。

總結:透過手動測試和OTP錄製方式進行重構,滿足自動化測試條件後,才能進行自動化測試。

IT界的影武者