既然進行存儲過程單元測試的原始方式有如此多的問題，那我們該如何改進這種測試方式以解決這些問題呢。下面我們就來分析解決問題的方法。
- 測試效率低下的問題
為了解決測試效率低下的問題，我們可否使用成熟的自動化測試技術呢。答案是肯定的。目前，針對 Java 代碼的單元測試已經有了很多的測試框架，例如JUnit, Cactus, StrutsTestCase 等，也有針對 SQL 測試的 DbUnit。
JUnit 是由 Erich Gamma 和 Kent Beck 編寫的一個回歸測試框架（Regression testing framework）。JUnit 測試是由程序員進行的測試，即白盒測試，因為程序員知道被測試的軟件如何（How）完成功能和完成什么樣（What）的功能。測試代碼只要繼承 TestCase 類，就可以用 JUnit 進行自動測試了。
Cactus 是一個基于 JUnit 框架的簡單測試框架，用來單元測試服務端 Java代碼，我們這里不需要。
而 DbUnit 是為數據庫驅動的項目提供的一個對 JUnit 的擴展，它針對的是普通的 SQL 語句測試，對我們的存儲過程測試并不適用。經過初步的分析，我們決定使用 JUnit。 - 回歸測試的問題
為了利用 JUnit 帶來的高效率，我們首先需要改變被測存儲過程的調用方式，即從手工調用，改為使用 JDBC 來調用。這樣的話，我們把一個個存儲過程的調用寫成了 Java 代碼，以后需要進行回歸測試時，只需要運行這些 Java測試代碼就可以了。
但是直接使用 JUnit，也會是一個痛苦的過程，因為我們必須在每段測試代碼中編寫連接數據庫的代碼，也得寫調用存儲過程時的一大堆參數設置代碼，還得寫很多 try{} catch{} 代碼塊。對于存儲過程測試來說，這些代碼就顯得非常累贅了，于是我們得想辦法把這些操作封裝為一個公用的類，我們只需要在測試代碼中提供數據庫連接信息、存儲過程名字和參數值就可以了，其他的工作由這個公用的類負責處理，這樣又能進一步減輕開發人員的工作量。
有了用Java語言編寫的基于 JUnit 框架的存儲過程測試代碼后，回歸測試問題也就迎刃而解了。這時，程序員需要的只是運行這個 JUnit 測試類即可。 - 測試結果的問題
接下來該解決測試結果的不直觀問題和需要手工生成的問題了。手工方式下，我們能夠得到的只是黑屏幕上顯示的文本結果，我們需要把這些返回信息摘錄出來，再形成報告，繁瑣而又枯燥。有了 JUnit 測試代碼之后，我們就可以直接形成報告了。辦法就是將測試結果存儲為 XML 文檔，配合以 XSL 樣式文件，我們可以在瀏覽器中看到漂亮的測試報告了。而測試結果可以包括存儲過程運行的時間、返回的記錄數、調用的參數列表或者出錯信息等。