框架方案 - 动态文档发布系统中的自动化测试应用

　　有了输入和输出，以及明确的需求，我们给出框架的解决方案：

　　(1)把整个过程分为输入、过程中、输出、输出后。

　　(2)对于配置，采用XML，并且在XML里提供对输入、输出、以及中间的过程的配置。

　　(3)对于输入，我们定义一个接口，对于这个接口的实现将会是各个不同的输入方式，对于目前来说我们是支持ASL+Textpieces。但是我们以后会支持另外的输入方式。然后对于所有的输入接口，我们定义一个中心的中间输出，我们叫它IDoc。它实际上是输入和发布的中心，输入都要转成这个我们定义的中间结果，然后输出都需要从这个中间结果进行加工。

　　(4)对于输出，我们可以把它们同样配置在XML里面。并且对于最基本的输出例如PDF，我们可以把它作为默认的一个输出，而不需要每次进行配置。

　　(5)对于中间过程，我们配置了一些拦截器，这些拦截器以IDoc为中心，设置了publish前和publish后的拦截器，也就是说，在这里我们可以对publish前和publish后进行一些配置。比如，在开始前我们可以开始计时，结束后结束计时，这样我们可以测试一些效率方面的例子。

　　(6)对于输出，我们对于PDF输出，我们要实现它和自动比较工具的一个集成，也就是生成完PDF后，在配置要求进行比较的情况下，自动调用PDF比较工具对输出结果和标准进行比较，然后得出结果，并且生成HTML结果表格，然后通过Email给相关人员进行发送。

　　3.3 用例

　　当整个系统运行起来后，操作步骤如下：

　　首先，简单来说，我们会提供一些默认的XML配置，包括用例存放路径、输入方式、输出方式、发比较结果邮件会发给哪些人等等进行默认配置。因为这些东西会很少改动，当然改动的时候，我们重新配置就行。然后我们把需要运行的输入，即ASL+Text Pieces放到一个配置的路径里，然后用名字去区分不同的用例。然后我们通过XML配置我们的输入格式、输出格式，以及需不需要对结果进行比较、需不需要发邮件等等选项。当这些配置配完以后，我们给它起一个唯一的用例名，然后在程序里将这个用例名作为参数运行就能使整个过程自动完成。对于程序员，我们每次提交关键代码，都会先运行一下这个框架程序，然后查看自动生成的测试报告。如果发现问题，及时改正。而对于配置管理员来说，他们这个过程用ant工具配置在打包脚本中，然后我们就可以在每次打包时，自动地运行我们预先设置的用例。并且，生成文件后，程序会自动对生成的PDF文件进行比较，并将结果整理发出邮件。相关人员会通过Email收到比较结果，在上面可以通过超链接很方便地点选那些比较不对的文档，然后通知程序员进行改正。整个过程由于都是由机器在后台快速运行，少了人工的干扰，所以既提高了准确率，又提高了效率。

　　4 结论

　　由于文档发布系统的客户对于不同系统版本间文档一致性的高要求，使我们必须要提供一个长久的机制保证这个一致性。而要保证这个系统的一致性，我们提出了一个轻量级自动测试的方案。这里所说的轻量级，只是说该框架下运行方便，不需要受应用服务器和数据库的约束，但是理论它上提供了文档发布系统同样的功能和行为。实际上在整个过程中，我们尽量调用原先系统的程序，但是在解除对于服务器和数据库的依赖方面，我们通过仔细分析原来的动态文档发布系统各个模块的前提下，采用了用本地文件模拟数据库的方法，通过重载方法实现了对于数据库的解耦。