本文將以一個真實的項目為背景，從分析過去存儲過程的測試方法中存在的問題入手，逐步闡述我們分析問題，尋找問題根源和尋求解決辦法的過程，介紹我們開發這個基于 JUnit 的存儲過程自動化測試的 Eclipse 插件的過程和存儲過程單元測試的解決方案。
1 摘要
存儲過程的測試，是數據庫開發人員經常要面臨的任務，多數情況下這是一項繁瑣、費時、又沒有太多創新的工作。有沒有辦法改變這一現狀呢？有沒有可能實現快速、批量、自動化的存儲過程測試呢？
本文將以一個真實的項目為背景，從分析過去存儲過程的測試方法中存在的問題入手，逐步闡述我們分析問題，尋找問題根源和尋求解決辦法的過程，介紹我們開發這個基于 JUnit 的存儲過程自動化測試的 Eclipse 插件的過程和存儲過程單元測試的解決方案。
開始之前，我們希望讀者有以下基本知識，如果您沒有接觸過這些方面的技術，那也不要緊，我們在文章中對相關的技術做了簡單的說明，以幫助您的理解。
讀者有 Eclipse 或者 WSAD（WebSphere Studio Application Developer）平臺上的開發經驗
讀者對數據庫開發比較熟悉，有一定的 Java 語言開發經驗。
讀者對 JUnit 或 Cactus 有所了解
2 一個真實的項目
項目 A 是一個使用了 200 多個存儲過程的 J2EE 電子商務應用項目，數據庫系統是 DB2 V8.2，Web 應用程序采用 WSAD 5.1 開發。有 5 位程序員參與開發這些存儲過程，并負責存儲過程的單元測試和性能測試。在現有的技術條件下，通常我們是如何進行測試的呢？
首先，程序員會打開 DB2 的命令行窗口，連接到數據庫，提交類似這樣的命令：
db2 call SP_QUERY('1'，'2'，?)
程序員希望獲得的測試結果包括：
存儲過程的運行是否正常？
存儲過程的參數調用正確嗎？
存儲過程的返回結果正確嗎？
存儲過程的性能是否達到要求呢？
程序員通常會把命令窗口中的結果信息拷貝下來，存到一個文件里，以后可以分析或者比較用。有時候我們也使用類似 Rapid SQL 等圖形化的工具來幫助我們做一些工作，但完成測試工作的工作量基本相當。在完成這些測試后，通常我們還需要根據測試的結果手工來完成測試報告。
這樣的測試工作通常情況下不只做一次，例如有相關的存儲過程、UDF、Table 或者其他所依賴的數據庫對象更改之后，都需要重新驗證這些更改所涉及到的存儲過程。這也意味著我們的程序員需要再次重復上面的工作，一個一個的驗證每個存儲過程，評測它們的性能，并終形成所需的測試報告。項目 A 的情況而言，按照每個程序員負責 40 個存儲過程計算，整個開發周期平均下來，每個人每天都要花上大約 2 個小時的時間來做這些測試工作和測試報告。
盡管我們的程序員在開發過程中做了很多測試工作來保證存儲過程的可用性、可靠性和高性能，但是在項目后期尤其是上生產系統后的回歸測試中我們依然需要做類似的測試，來保證所有的存儲過程在生產系統上運行正常，同時完成生產系統的性能測試報告。顯而易見，很多工作不得不重復進行。
3 存在的問題
這樣大部分依靠手工進行的存儲過程單元測試，有著如下一些問題：
1） 效率低下：程序員要花每天近 1/4 的時間來進行重復的測試工作，這段時間應該通過使用可重復的測試方式應該是可以縮短的。下圖是在我們項目 A 中的一位程序員的平均時間分配圖，可以看出單元測試和回歸測試占用了他 40% 的工作量。
2） 手工進行性能測試，測試結果不準確。
3） 無法重用，沒有留下可供重用的工具或代碼。
4） 無法進行自動化的回歸測試。
5） 沒有直觀的測試結果，需要程序員自己整理測試結果并生成測試報告。
