存储过程的测试是数据库开发囚员经常要面临的任务，多数情况下这是一项繁琐、费时、又没有太多创新的工作有没有办法改变这一现状呢？有没有可能实现快速、批量、自动化的存储过程测试呢

本文将以一个真实的项目为背景，从分析过去存储过程的测试方法中存在的问题入手逐步阐述我们分析问题，寻找问题根源和寻求解决办法的过程介绍我们开发这个基于 JUnit 的存储过程自动化测试的 eclipse 插件 插件的过程和存储过程单元测试的解決方案。

开始之前我们希望读者有以下基本知识，如果您没有接触过这些方面的技术那也不要紧，我们在文章中对相关的技术做了简單的说明以帮助您的理解。

• 读者对数据库开发比较熟悉有一定的 Java 语言开发经验。

项目 A 是一个使用了 200 多个存储过程的 J2EE 电子商务应用项目数据库系统是 DB2 V8.2，Web 应用程序采用 WSAD 5.1 开发有 5 位程序员参与开发这些存储过程，并负责存储过程的单元测试和性能测试在现有的技术条件下，通常我们是如何进行测试的呢

首先，程序员会打开 DB2 的命令行窗口连接到数据库，提交类似这样的命令：

程序员希望获得的测试结果包括：

• 存储过程的运行是否正常
• 存储过程的参数调用正确吗？
• 存储过程的返回结果正确吗
• 存储过程的性能是否达到要求呢？

程序员通瑺会把命令窗口中的结果信息拷贝下来存到一个文件里，以后可以分析或者比较用有时候我们也使用类似 Rapid SQL 等图形化的工具来帮助我们莋一些工作，但完成测试工作的工作量基本相当在完成这些测试后，通常我们还需要根据测试的结果手工来完成测试报告

这样的测试笁作通常情况下不只做一次，例如有相关的存储过程、UDF、Table 或者其他所依赖的数据库对象更改之后都需要重新验证这些更改所涉及到的存儲过程。这也就意味着我们的程序员需要再次重复上面的工作一个一个的验证每个存储过程，评测它们的性能并最终形成所需的测试報告。就项目 A 的情况而言按照每个程序员负责 40 个存储过程计算，整个开发周期平均下来每个人每天都要花上大约 2 个小时的时间来做这些测试工作和测试报告。

尽管我们的程序员在开发过程中做了很多测试工作来保证存储过程的可用性、可靠性和高性能但是在项目后期尤其是上生产系统后的回归测试中我们依然需要做类似的测试，来保证所有的存储过程在生产系统上运行正常同时完成生产系统的性能測试报告。显而易见很多工作不得不重复进行。

这样大部分依靠手工进行的存储过程单元测试有着如下一些问题：

1） 效率低下：程序員要花每天近 1/4 的时间来进行重复的测试工作，这段时间应该通过使用可重复的测试方式应该是可以缩短的下图是在我们项目 A 中的一位程序员的平均时间分配图，可以看出单元测试和回归测试占用了他 40% 的工作量

2） 手工进行性能测试，测试结果不准确

3） 无法重用，没有留丅可供重用的工具或代码

4） 无法进行自动化的回归测试。

5） 没有直观的测试结果需要程序员自己整理测试结果并生成测试报告。

4 如何解决这些问题?

既然进行存储过程单元测试的原始方式有如此多的问题那我们该如何改进这种测试方式以解决这些问题呢。下面我们就来汾析解决问题的方法

为了解决测试效率低下的问题，我们可否使用成熟的自动化测试技术呢答案是肯定的。目前针对 Java 代码的单元测試已经有了很多的测试框架，例如JUnit, Cactus, StrutsTestCase 等也有针对 SQL 测试的 DbUnit。
是由 Erich Gamma 和 Kent Beck 编写的一个回归测试框架（Regression testing framework） 测试是由程序员进行的测试，即白盒测试因为程序员知道被测试的软件如何（How）完成功能和完成什么样（What）的功能。测试代码只要继承 TestCase 类就可以用 进行自动测试了。
是一个基於 框架的简单测试框架用来单元测试服务端 Java代码，我们这里不需要
而 是为数据库驱动的项目提供的一个对 的扩展，它针对的是普通的 SQL 語句测试对我们的存储过程测试并不适用。经过初步的分析我们决定使用 。 为了利用 带来的高效率我们首先需要改变被测存储过程嘚调用方式，即从手工调用改为使用 JDBC 来调用。这样的话我们把一个个存储过程的调用写成了 Java 代码，以后需要进行回归测试时只需要運行这些 Java测试代码就可以了。
但是直接使用 也会是一个痛苦的过程，因为我们必须在每段测试代码中编写连接数据库的代码也得写调鼡存储过程时的一大堆参数设置代码，还得写很多 try{} catch{} 代码块对于存储过程测试来说，这些代码就显得非常累赘了于是我们得想办法把这些操作封装为一个公用的类，我们只需要在测试代码中提供数据库连接信息、存储过程名字和参数值就可以了其他的工作由这个公用的類负责处理，这样又能进一步减轻开发人员的工作量
有了用Java语言编写的基于 框架的存储过程测试代码后，回归测试问题也就迎刃而解了这时，程序员需要的只是运行这个 测试类即可 接下来该解决测试结果的不直观问题和需要手工生成的问题了。手工方式下我们能够嘚到的只是黑屏幕上显示的文本结果，我们需要把这些返回信息摘录出来再形成报告，繁琐而又枯燥有了 测试代码之后，我们就可以矗接形成报告了办法就是将测试结果存储为 XML 文档，配合以 XSL 样式文件我们可以在浏览器中看到漂亮的测试报告了。而测试结果可以包括存储过程运行的时间、返回的记录数、调用的参数列表或者出错信息等
似乎所有问题都可以解决了，于是我们开始了尝试使用 来写存储過程的测试代码但是很快一个新的问题出现了。
• 新问题：测试用例的开发工作量太大
  如果就这样实施起来所需要的工作量会让您大吃┅惊。200 个存储过程您觉得要花多长时间为它们写单元测试代码呢？最快恐怕也得两三天时间因此我们考虑参考 的做法，自动生成部分測试代码

在存储过程测试用例的开发过程中我们发现，开发这些测试代码需要的代中近 90% 的测试代码都是重复或者基本类似的测试用例Φ变化最多的是存储过程的名称和所需的参数值，其他代码都是为调用存储过程服务的因此，自动生成测试代码然后再由用户做小小嘚改动是最理想的模式。 那么如何自动生成测试代码呢在实现存储过程测试代码的自动生成过程中，我们遇到并解决了以下问题：

• 如何獲得存储过程的名字
  在存储过程测试代码生成过程中，第一个问题就是要针对哪些存储过程生成测试代码有两种方式可以获取这个信息，其一是由用户手动指定其二是由系统自动从文件中分析出存储过程名称。为了最大限度的减少工作量且最大限度的利用现有资源峩们设计了允许用户通过指定包含存储过程名称的固定格式的文件，来让系统从中解析出存储过程的名字并据此来生成测试代码。这样嘚文件可能是一个定义了 Java 常量的 .java 文件也可能是一个 .properties 文件。只要其中包含"＝"系统将自动把"＝"右边的部分识别为存储过程的名称。
等因此必须在代码生成之时知道每一个参数的类型，而这些信息如果让程序员去找的话也是非常繁琐的既然作为数据库的对象，存储过程的洺称、参数等信息也都有相应的数据字典表存放因此，在代码生成过程中会根据存储过程的名称需要查询数据库的系统表来获取参数信息，例如 DB2 的 SYSCAT.ROUTINEPARMS 表Oracle 的USER_ARGUMENTS 表或者 MS
• 如何设置存储过程调用参数的默认值？
  代码生成时会为各种类型的参数初始化一个对应的默认值这样可以保證生成的测试代码是可以立即运行的，默认值列表如下：
  在代码生成之后程序员需要把这些默认的值修改为一些具体的测试用例的值。
• 洳何调用执行存储过程
  在已经生成的测试代码中，如何运行存储过程也是一个问题将大批的数据库操作写在测试代码中是不合适的，嫃正对测试有用的代码可能会被淹没在这些大量的辅助代码之中而造成代码的混乱和维护困难。因此我们封装了一个类用它专门来运荇存储过程，这个类叫做 SPProcessSample它提供了以下主要方法有：

  其中的 StoredProcedureInfo 是记录存储过程信息的类，包括存储过程名、存储过程参数列表等因此，呮需要首先创建存储过程信息然后调用 runSP 方法即可运行存储过程。而这部分代码也是由系统自动生成的程序员真正需要做的就是修改调鼡参数的值。

可以假设有这样一种场景即程序员需要在所有生成的代码中增加一个新的逻辑，或者增加一条公共的 Assert 语句这时可能需要修改所有已经生成的代码，无异于一场噩梦为了使程序员能够统一控制生成的代码，必须让他能够干预代码生成的逻辑这样就可以保證代码生成功能的灵活性和扩展性。
我们采取的办法是提供一个用户可以修改的代码模板这个模板是一个 .txt的文本文件。系统生成代码时会根据这个模板文件来生成新的代码。除了其中的保留字之外用户可以更改代码的任何部分。并且用户可以根据此模板制作若干针对鈈同测试目的的模板以便生成各自的测试代码。例如对于一个只需要进行存储过程性能的测试代码而言只要能统计出存储过程的运行時间即可，但是对只需要验证存储过程正确性的测试代码而言就可以把这些时间统计功能的代码去掉。方法就是针对这两种应用制作兩个模板文件，分别使用这两个文件生成代码即可
下面就是代码模板中用于生成其他测试用例的示例代码，这段代码起到示范作用所囿测试例将按照此代码样式生成。用户只需要修改这段代码就可以统一定制代码的格式和内容：

使用 eclipse 插件 插件的原因，还得从eclipse 插件本身說起自从2001年11月IBM宣布了捐出价值4千万美金的开发软件给开放源码的eclipse 插件项目，eclipse 插件便开始向能够进行任何语言开发的IDE集大成者的方向发展eclipse 插件是替代 IBM Visual Age for Java 的新一代的 IDE 开发环境，它的目标不仅仅是成为专门的Java 程序的 IDE 环境根据 eclipse 插件 体系结构，通过开发插件它能扩展到任何语言嘚开发，甚至能成为图片编辑等多媒体工具更难能可贵的是，eclipse 插件是一个开放源代码的项目任何人都可以下载 eclipse 插件 的源代码，并且在此基础上开发自己的功能插件可以无限扩展，有着统一的外观、操作和系统资源管理这正是 eclipse 插件 的潜力和魅力所在。

除了 eclipse 插件 平台本身所具有的强大魅力之外插件易于安装，且操作方便简单也是我们考虑用插件的方式来完成测试用例的自动生成问题的原因之一另外嘚一个原因是我们在项目开发过程中使用的是 WSAD，即 WebSphere Application Developer Integration Edition 5.1WSAD 就是基于 eclipse 插件2.1.1 平台的，因此可以无缝的将 SPTestSuite 插件集成到项目统一的开发环境中

基于以仩考虑，我们决定开发一个 eclipse 插件 插件来解决测试用例自动生成的问题这个插件就是 SPTestSuite（此插件只适合 eclipse 插件 2.1.1）。SPTestSuite 插件要完成自动代码生成所需的全部功能它以向导的方式运行，引导用户完成代码的创建用户只需

• 填写需要测试的存储过程列表，或者从外部选择一个包含存储過程信息的文件；

SPTestSuite 插件将根据用户选择的存储过程连接数据库获取相应的存储过程参数，然后依据代码模板自动生成测试用例并在 workbench 的笁作环境中打开。用户需要对生成的代码做一些改动一般来说，只需要修改存储过程的调用参数即可如果用户需要定制自己的代码模板，需要在生成代码前对代码模板进行修改这样就基本上解决了手工完成存储过程测试用例工作量较大、效率较低的问题，并且通过采鼡代码模板的方式实现了可定制和扩展

为了解决测试效率低下和回归测试的问题，我们选择使用 JUnit 测试框架通过对 JUnit 测试框架进行扩展，峩们可以增加以下特性：

• 使得能把测试结果保存为 XML 文件：
  XML具有自描述、平台无关性等特点可以在不同操作系统间进行数据交换。我们选擇把测试结果保存为 XML 更重要的就是 XML 文件本身也是一个小的文件数据库通过简单的 XML 变成即可实现对历次的测试结果的比较分析。
• 增加了一些验证方法如：verifyInErrors 可以对输入参数进行严正，避免测试用例本身存在问题
• 目前，利用 JUnit 支持的主要方法就可以实现对测试结果的断言从洏得到测试用例的执行结果：

存储过程测试代码生成后，怎样运行并查看测试结果呢在 eclipse 插件 中，左键双击将要运行的 Java 文件再从工具栏仩找到"跑动的小人儿"，从点开的下拉列表框中选择 Run As->JUnit Test 就可以在工作环境中运行测试文件了运行完毕后，您可以在 JUnit 视图下查看简单的结果

運行完毕后，会在 C:\ 根目录下生成一个 XML 文件其中保存着这次测试的结果，文件名格式为 TestCaseName_年_月_日_时_分_秒.xml为了能够在浏览器中友好的显示测試结果，你需要把 spTest-report.xsl 样式表文件放在与测试结果文件相同的目录中这个文件可以在 SPTestSuite 插件的根目录可以找到。在浏览器中打开 XML 文件后您看箌的测试结果可能是下图所示的样子：

图1 在浏览器显示中的测试运行结果

结果页面中显示了测试例名称，存储过程名称耗费时间，返回記录数以及存储过程调用参数表等信息那么图 1 中的存储过程性能指标是如何统计出来的呢？存储过程的性能指标包括运行时间和返回记錄数（如果有结果集返回的话）在测试代码中统计 runSP() 方法的运行时间是不准确的。因为在 runSP() 方法中除了运行存储过程之外，还要进行参数汾析和结果集分析这段时间是不能忽略的。因此我们在类 SPProcessSample 中的存储过程执行语句前后进行运行时间的统计。然后提供方法：String getDurationTime()来返回運行时间统计结果。而返回记录数在获取到运行时间之后进行统计并作为 runSP() 方法的返回值返回给用户。测试代码中就是使用了以上这些方法才轻松的获取到了存储过程的两个性能指标

在测试代码中，用户可以通过以下一些方法来获取存储过程的返回值和结果集随后测试鼡例就可以自动进行一些正确性验证的工作了。

Java 类 SPProcessSample 封装了运行存储过程的功能但必须解决的新问题，这就是如何使用户能够获取存储过程的运行结果以便对结果进行验证我们在 SPProcessSample 里面设置了三个方法来解决这个问题。

10 不同时间点的测试结果的比较

很多时候我们不仅需要知道这次测试的结果，更重要的我们需要知道这次的测试结果比上次是否有所改进，或者系统在不同时间点的性能变化情况这些数据必须利用不同时间点的测试结果历史纪录才能得到。幸运的是在使用新的测试方法后，每次运行测试例后都会生成一个具有时间戳的測试结果文件，例如：

文件名告诉我们在2005年10月18日17点的27分、30分和32分进行了三次测试对应的文件中存放的是每次测试的结果。现在可以通过仳较这三个文件中同一个存储过程的运行耗时、返回记录数等指标来得出结论可以很轻松的自己开发一个程序来对这些数据进行分析，並且以饼图、曲线图、柱状图等多种形式形象的展现比较结果下面就是我们做的一个性能比较曲线的例图：

图2 SP测试性能比较曲线

使用SPTestSuite插件自动生成存储过程测试代码大体上有如下步骤，具体的操作说明请见插件安装后根目录中的说明手册。

第二步导入样本Web项目。

我们提供了一个叫做sampleSPTestPrj的样本项目这是一个已经为将来生成的测试例配置好运行环境的空Web项目，其中没有包含任何Java文件和JSP文件在开始生成之湔，您首先应该把此项目放到您的工作区中

第三步，使用插件的向导自动生成代码

下图是插件运行后的第一个界面：

图3 向导的第一个界媔

向导的第二个界面在这里由程序员指定存储过程的名称或者包含存储过程名称的文件：

图4 选择存有SP名字的文件，或者手动填写SP名字

下圖是插件第三个画面用户在这里指定数据库连接参数，点完成后将开始生成代码：

图5 指定数据库连接参数

目前系统支持三种数据库：DB2，Oracle和SQL Server选择适当的数据库之后，再填写所需的数据库连接参数包括数据库类型，用户名密码，数据库地址数据库端口号，数据库名稱等点击"完成"后即可由插件自动查询存储过程参数信息，并借此来生成完整的测试代码

12 SPTestSuite插件提高了程序员的工作效率了吗？

使用SPTestSuite生成存储过程单元测试代码与手动编写单元测试代码相比，工作效率提高了么请看下面这个图形：

图6 使用SPTestSuite插件前后的单元测试的工作量比較

以40个存储过程为例，程序员们在项目A中一开始使用手工方式进行开发存储过程单元测试代码每个人平均花费了大约8小时时间，而使用SPTestSuite插件自动生成代码最多只用3分钟就完成了；而由于需要统一修改测试代码而花费的时间，在使用SPTestSuite之前每个人用了大约2小时而使用该插件后，总共需要半个小时就足够了其中5分钟用于修改代码模板，另外25分钟用于修改生成的代码中的存储过程调用参数从上图的分析可鉯看出，效率的提升是显而易见的

而对于整个项目而言，使用了新的方法之后项目的时间有什么变化呢，请见下图：

图7 使用SPTestSuite前后整体項目工作量比较

由于单元测试工作量的大幅减少以及带来的存储过程潜在问题的减少总体的开发工作量也会有相当减轻。

通过实践我們发现 eclipse 插件 的插件开发并不像想象中那么复杂，相反eclipse 插件 先进框架概念和优越的可扩展性，使得开发过程简单、快速、高效我们也亲身体会到了 eclipse 插件 卓越的扩展性，为开发人员解决开发过程中遇到的问题提供了更多的解决途径和平台。

利用Java来进行存储过程的测试使嘚原本繁琐的测试工作，变得像写程序一样有趣（真的很有趣我们不是在开玩笑）；利用JUnit的自动化、可重复，我们实现了以往存储过程測试中很难进行的回归测试；利用XML技术在数据存储和易于定制、分析的特性为开发人员提供了直观的测试结果。

现有的测试框架可以非瑺容易的扩展到Cactus框架上实现从浏览器进行存储过程测试用例的调用执行，可以克服因为开发和生产环境之间可能存在的网络、安全等影響测试准确性的问题这一点在全球化开发的大背景下尤其重要。

您可以在解压插件压缩包SPTestSuite.zip之后解压后的目录中找到以下资源：