本文將以一個真實的項目為背景，從分析過去存儲過程的測試方法中存在的問題入手，逐步闡述我們分析問題，尋找問題根源和尋求解決辦法的過程，介紹我們開發(fā)這個基于 JUnit 的存儲過程自動化測試的 Eclipse 插件的過程和存儲過程單元測試的解決方案。

1 摘要

存儲過程的測試，是數(shù)據(jù)庫開發(fā)人員經常要面臨的任務，多數(shù)情況下這是一項繁瑣、費時、又沒有太多創(chuàng)新的工作。有沒有辦法改變這一現(xiàn)狀呢？有沒有可能實現(xiàn)快速、批量、自動化的存儲過程測試呢？

本文將以一個真實的項目為背景，從分析過去存儲過程的測試方法中存在的問題入手，逐步闡述我們分析問題，尋找問題根源和尋求解決辦法的過程，介紹我們開發(fā)這個基于 JUnit 的存儲過程自動化測試的 Eclipse 插件的過程和存儲過程單元測試的解決方案。

開始之前，我們希望讀者有以下基本知識，如果您沒有接觸過這些方面的技術，那也不要緊，我們在文章中對相關的技術做了簡單的說明，以幫助您的理解。

    讀者有 Eclipse 或者 WSAD（WebSphere Studio Application Developer）平臺上的開發(fā)經驗
    讀者對數(shù)據(jù)庫開發(fā)比較熟悉，有一定的 Java 語言開發(fā)經驗。
    讀者對 JUnit 或 Cactus 有所了解

2 一個真實的項目

項目 A 是一個使用了 200 多個存儲過程的 J2EE 電子商務應用項目，數(shù)據(jù)庫系統(tǒng)是 DB2 V8.2，Web 應用程序采用 WSAD 5.1 開發(fā)。有 5 位程序員參與開發(fā)這些存儲過程，并負責存儲過程的單元測試和性能測試。在現(xiàn)有的技術條件下，通常我們是如何進行測試的呢？

首先，程序員會打開 DB2 的命令行窗口，連接到數(shù)據(jù)庫，提交類似這樣的命令：

db2 call SP_QUERY('1'，'2'，?)

程序員希望獲得的測試結果包括：

    存儲過程的運行是否正常？
    存儲過程的參數(shù)調用正確嗎？
    存儲過程的返回結果正確嗎？
    存儲過程的性能是否達到要求呢？

程序員通常會把命令窗口中的結果信息拷貝下來，存到一個文件里，以后可以分析或者比較用。有時候我們也使用類似 Rapid SQL 等圖形化的工具來幫助我們做一些工作，但完成測試工作的工作量基本相當。在完成這些測試后，通常我們還需要根據(jù)測試的結果手工來完成測試報告。

這樣的測試工作通常情況下不只做一次，例如有相關的存儲過程、UDF、Table 或者其他所依賴的數(shù)據(jù)庫對象更改之后，都需要重新驗證這些更改所涉及到的存儲過程。這也意味著我們的程序員需要再次重復上面的工作，一個一個的驗證每個存儲過程，評測它們的性能，并終形成所需的測試報告。項目 A 的情況而言，按照每個程序員負責 40 個存儲過程計算，整個開發(fā)周期平均下來，每個人每天都要花上大約 2 個小時的時間來做這些測試工作和測試報告。

盡管我們的程序員在開發(fā)過程中做了很多測試工作來保證存儲過程的可用性、可靠性和高性能，但是在項目后期尤其是上生產系統(tǒng)后的回歸測試中我們依然需要做類似的測試，來保證所有的存儲過程在生產系統(tǒng)上運行正常，同時完成生產系統(tǒng)的性能測試報告。顯而易見，很多工作不得不重復進行。

3 存在的問題

這樣大部分依靠手工進行的存儲過程單元測試，有著如下一些問題：

1） 效率低下：程序員要花每天近 1/4 的時間來進行重復的測試工作，這段時間應該通過使用可重復的測試方式應該是可以縮短的。下圖是在我們項目 A 中的一位程序員的平均時間分配圖，可以看出單元測試和回歸測試占用了他 40% 的工作量。

2） 手工進行性能測試，測試結果不準確。

3） 無法重用，沒有留下可供重用的工具或代碼。

4） 無法進行自動化的回歸測試。

5） 沒有直觀的測試結果，需要程序員自己整理測試結果并生成測試報告。