重構性項目如何測試

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

2.爲何要進行重構?設計模式

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

3.重構的目標緩存

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

4.重構的範圍服務器

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

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

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

業務級別重構。常見爲某些業務需求由於系統設計的不合理性致使沒法知足或有缺陷知足,須要經過業務系統的重構調整或數據庫的重構來解決。tcp

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

 

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

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

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

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

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

因此重構是一個解耦的過程?


2、重構性項目如何測試
1.質量標準

 TDD或單元測試引入

2.效率標準
(1)方法一:對比測試
測試用例,簡單說,就是給定一個場景(輸入),驗證在這個場景下軟件的行爲(輸出)。因此定義測試用例就須要定義測試時的輸入輸出和驗證規則。
但在代碼重構中,由於軟件的功能並未增長,一次也就沒有增長新的測試用例。而且,重構前的老系統自己就提供了大量的測試用例。爲何這麼說,由於重構以後的新系統的各項業務行爲只要和老系統保持一致,那就能夠說是正確的。
因此,對於代碼重構工做,測試用例的編寫就被大大簡化:只需定義輸入,無需定義輸出,將老系統的輸出做爲輸出便可。同時,驗證規則也簡化了不少,各項數據一般只需和老系統保持一致,少數的不能徹底一致的數據,只需驗證其知足必定規則便可。
具體方法:
定義測試用例輸入,分別調用新(重構後的系統)、老系統。用老系統的結果校驗新系統,從而下降測試的工做量,提升測試效率。

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

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

相關文章
相關標籤/搜索