既然进行存储过程单元测试的原始方式有如此多的问题，那我们该如何改进这种测试方式以解决这些问题呢。下面我们就来分析解决问题的方法。
- 测试效率低下的问题
为了解决测试效率低下的问题，我们可否使用成熟的自动化测试技术呢。答案是肯定的。目前，针对 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 样式文件，我们可以在浏览器中看到漂亮的测试报告了。而测试结果可以包括存储过程运行的时间、返回的记录数、调用的参数列表或者出错信息等。