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

1 摘要

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

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

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

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

2 一個(gè)真實(shí)的項(xiàng)目

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

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

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

程序員希望獲得的測試結(jié)果包括：

    存儲(chǔ)過程的運(yùn)行是否正常？
    存儲(chǔ)過程的參數(shù)調(diào)用正確嗎？
    存儲(chǔ)過程的返回結(jié)果正確嗎？
    存儲(chǔ)過程的性能是否達(dá)到要求呢？

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

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

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

3 存在的問題

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

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

2） 手工進(jìn)行性能測試，測試結(jié)果不準(zhǔn)確。

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

4） 無法進(jìn)行自動(dòng)化的回歸測試。

5） 沒有直觀的測試結(jié)果，需要程序員自己整理測試結(jié)果并生成測試報(bào)告。