測試數據密集型遺留應用程序的提示

Question

我正在處理一個非常大的數據密集型遺留應用程序。代碼庫&的規模都很大。大量業務邏輯分佈在所有層，包括存儲過程中。

對於如何開始以有效的方式將「單元」測試（技術上的集成測試，因爲它們需要跨層測試幾乎任何給定流程的單一方面）有任何建議？目前的體系結構不容易支持任何類型的注入或模擬。正在編寫新代碼以促進測試，但遺留代碼又如何呢？由於數據庫本身和數據庫業務邏輯的強烈依賴性，我目前使用內聯sql來查找要用於測試的數據，但這些都很耗時。創建視圖和/或存儲過程是不夠的。

你採取了哪些方法（如果適用）？什麼工作？爲什麼沒有&？任何建議，將不勝感激。謝謝。

Answer 1

獲得Michael Feathers的Working Effectively with Legacy Code的副本。對於大型未經測試的代碼庫的工作，它提供了很多有用的建議。

另一本好書是Object Oriented Reengineering Patterns。本書的大部分內容並不針對面向對象的軟件。全文可以PDF格式免費下載。

從我自己的經驗：儘量...

• 自動化構建和部署
• 獲取數據庫架構版本控制，如果還沒有到。通常數據庫包括事務代碼在工作之前需要存在的引用數據。在版本控制下也可以得到這個。諸如dbdeploy之類的工具可以幫助您輕鬆地從一系列增量中重建模式和參考數據。
• 在開發工作站上安裝數據庫的版本（以及其他任何基礎架構服務）。這將讓您在不需要經過DBA的情況下處理數據庫。它也比在遠程數據中心的共享服務器上使用模式更快。所有主要的商業數據庫服務器都有免費的（如啤酒）開發版本，可以在Windows上工作（如果你陷入了在Windows上開發並在Unix上部署的不可避免的情況）。
• 在開始編寫代碼區域之前，編寫大致覆蓋您所在區域行爲的端到端測試。端到端測試應該從外部對系統進行操作 - 通過控制其用戶界面或通過網絡服務進行交互 - 因此您無需更改代碼即可實現。它將作爲（不完美的）迴歸測試，讓您更有信心將系統的內部構造重構爲易於進行單元測試的結構。
• 如果有手動測試計劃，請閱讀並查看可以自動執行的操作。大多數手動測試計劃幾乎完全是腳本化的，所以對於自動化來說是低成本的
• 一旦您獲得了端到端測試覆蓋率，在修改和/或擴展代碼時，將代碼重構爲更鬆散耦合的單元。用單元測試圍繞這些單元。

需要避免的事項：從生產數據庫

• 將數據複製到您使用自動測試環境。這會使你的測試不可預測。當然，運行系統對照生產數據的副本，但將其用於探索性測試，而不是迴歸測試。
• 在測試結束時回滾事務以隔離彼此的測試。這不會測試僅在事務提交時發生的行爲，並會丟棄對診斷測試失敗很有價值的數據。相反，測試應該確保數據庫在啓動時處於已知的初始狀態。
• 創建一個「小」數據集供測試運行。這使得測試很難理解，因爲它們不能作爲一個單元來讀取。隨着您爲不同場景添加測試，「微小」數據集很快就會增長很多。相反，測試可以將數據插入數據庫以設置測試夾具。

Answer 2

「測試遺留應用現代化，」亮點：

的測試如何在AscentialTest

方式創建的遺留轉換

1. 高級概述對象到對象的新平臺組件定義

2. 如何確保現代化版本的應用程序產生相同的結果

有關測試遺留應用程序的用法的細節，做檢查在這裏：

http://application-management.cioreview.com/whitepaper/testing-legacy-application-modernization-wid-529.html