重構性項目如何測試


一、初識重構
1.重構是什么?
  代碼重構是在不修改軟件功能的情況下,對軟件內部進行調整優化。

2.為什么要進行重構?

  • 項目中的代碼有明顯的難以理解、難以修改的問題
  • 在復雜度、重復率方面有嚴重的問題
  • 重構可以把一些效率低的代碼,重新調整成效率更高的代碼
  • 可以將重復提交的代碼,為獨立的函數
  • 統一和規范變量名

3.重構的目標

  • 通過更優秀更合理的架構來滿足系統高性能、高並發、高可用的需求
  • 通過重構來提高代碼質量
  • 引入新的技術和框架來升級整個系統
  • 通過重構來優化業務流程,實現原來實現不了的需求

4.重構的范圍

平台級別重構。針對整體平台的重構,如阿里早期是LAMP架構,后來整體遷移到了Java平台。

系統級別重構。針對業務系統的重構,如通過引入微服務架構或者SOA架構,分解單體應用。

架構級別重構。如通過架構的調整和重新設計,改善原有架構的不合理之處。如通過分層使業務解耦,引入緩存設計提升系統高並發等。

業務級別重構。常見為某些業務需求因為系統設計的不合理性導致無法滿足或有缺陷滿足,需要通過業務系統的重構調整或數據庫的重構來解決。

模塊/代碼級別重構。這是最常見的重構。通常指使用設計模式、封裝繼承、優化拆解代碼,使得代碼的結構更良好,運行效率更高。

 

5.常見的項目重構的方法:
(1)梳理並且分解繼承體系
繼承是面向對象設計語言中一個很重要的特性,它可以減少子類的代碼量。同時繼承也會被誤用。今天為了一個功能添加了一個小類,也許明天還會為了另外一個功能添加另外一個類。時間一長你就會發現,這個類簡直就是慘不忍睹。代碼會出現大量的重復,而且修改也會變得很困難。
要修改這個類就要把這個類中相關的變量或者功能梳理清楚,分別給它們建立相應的父類,然后再繼承下去。它們分別屬於不同的功能體系,必須要有相應的繼承體系。

(2)將過程化的代碼轉化為對象設計
將數據記錄編成對象,將大塊的行為分成效塊並且將行為移入相關的對象之中。常見的場景,類中有很長很長的函數和很少的數據。我們要做的是將這個很長的函數提煉出來放到一個單獨的類中來處理。

(3)將程序分層,將數據、界面、邏輯分開
這個就要提到經典的MVC模型,這個模型的價值就在於:它將用戶界面和邏輯處理分開了。即界面只包含展示所用的東西;邏輯層只包含邏輯代碼而不包含界面的內容。

(4)提煉繼承體系
一個類做了很多的事情,其中有些事情是以大量的表達式來完成的,我們應該考慮為這個情況建立起相應的繼承體系,使每一個子類包含一種特殊情況。剛開始時,我們設計的時候,是一個類實現一種功能或者一個概念,但是隨着時間的推移、方案的改進,可能這個類添加了另外一個概念,變成了兩個概念,包含兩種功能,隨后變成三個四個五個等。最后這個類變得就會完成陌生了,失去了原來我們設計這個類的初衷了。

備注:重構需要對舊系統業務進行梳理,並分批重構。

所以重構是一個解耦的過程?


二、重構性項目如何測試
1.質量標准

 TDD或單元測試引入

2.效率標准
(1)方法一:對比測試
測試用例,簡單說,就是給定一個場景(輸入),驗證在這個場景下軟件的行為(輸出)。所以定義測試用例就需要定義測試時的輸入輸出和驗證規則。
但在代碼重構中,因為軟件的功能並未增加,一次也就沒有增加新的測試用例。並且,重構前的老系統本身就提供了大量的測試用例。為什么這么說,因為重構之后的新系統的各項業務行為只要和老系統保持一致,那就可以說是正確的。
所以,對於代碼重構工作,測試用例的編寫就被大大簡化:只需定義輸入,無需定義輸出,將老系統的輸出作為輸出即可。同時,驗證規則也簡化了很多,各項數據通常只需和老系統保持一致,少數的不能完全一致的數據,只需驗證其滿足一定規則即可。
具體方法:
定義測試用例輸入,分別調用新(重構后的系統)、老系統。用老系統的結果校驗新系統,從而降低測試的工作量,提高測試效率。

目前可依賴腳本自動化對比數據,但是腳本編寫成本與提升的效率是個需要商榷的問題。

(2)方法二:導流測試
方法一可以幫助簡化對測試結果的驗證,但是測試輸入還是要想辦法豐富起來,否則漏掉一個場景就有可能放過一個bug。
對於老功能,需求早已丟失,當年設計開發它的人也已不在,那如何為這樣缺失需求的功能設計測試用例。有一個方法是直接使用線上的請求測試。
具體方法:
通過使用Nginx的ngx_http_miror_module模塊(或其他技術,如tcpcopy),復制一份線上的請求,然后將這份復制的真實請求導向部署了重構版本應用的服務器。然后再通過方法一介紹的對比測試方式,比較線上應用和重構后應用的輸出結果(返回值、數據庫記錄等等),從而驗證代碼重構的正確與否。
但是這種測試方法有一定的局限性。簡單來說,這種方式適合測試讀接口,不太適合或者說是難以測試寫接口。因為測試請求來自線上,如果被測服務器同樣部署在線上環境,那寫接口就會對用戶數據造成應用。如果被測服務器部署在測試環境,需要在測試環境完整同步一份線上數據,這需要相當的基礎測試設施的支持。


免責聲明!

本站轉載的文章為個人學習借鑒使用,本站對版權不負任何法律責任。如果侵犯了您的隱私權益,請聯系本站郵箱yoyou2525@163.com刪除。



 
粵ICP備18138465號   © 2018-2025 CODEPRJ.COM