本文将以一个真实的项目为背景，从分析过去存储过程的测试方法中存在的问题入手，逐步阐述我们分析问题，寻找问题根源和寻求解决办法的过程，介绍我们开发这个基于 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） 没有直观的测试结果，需要程序员自己整理测试结果并生成测试报告。
