自动化测试在动态文档发布系统中的应用

3 设计方案
根据上面提出的三个要求，我们将通过分析我们的系统来提出我们的解决方案。
3．1 分析
对于这个系统来说，我们首先需要解决对于应用服务器，也就是对于EJB的依赖。为了达到这个目的，我们必须对系统的主要模块进行分析，来想办法如何解除依赖。

3．1．1 系统主要模块介绍
我们可以看看此系统的一个特别简化同时又很典型的流程：

首先介绍一下每个术语：
BDT：Business document template，商业文档模板。在这里我们定义一些规则，然后会跟客户数据关联选择具体的规则。
Customer Data：客户数据。XML格式记录特定客户的数据，然后根据这些客户数据，动态产生不同文档。
ASL：Assembly List，装配列表。由BDT和客户数据装载生成，里面记录的是一个个根据规则而选出来的最终文档片段(text piece)。
Text Piece：文档片段。在客户端定义，并存储在数据库端的文档片段。
MSO：微软自己定义的HTML格式Microsoft HTML，然后我们在里面加入一些我们自己定义的标记。
Styled Doc：式样文档。我们定义的一个格式，其实就是一些结构类，会对文档的各个内容、样式、布局进行描述。
DIF：Document Independent Format，独立文档格式。StyledDoc经过CE(composition)排版的结果就是DIF。它是一个页面级别的概念，告诉你什么时候生成一个新页面，多大，在哪里用什么字体写些什么字，在哪里放一个什么样的图片。
PDL：Page Description Language，页面描述语言。我们需要生成的最终结果，就是那些用页面来表示文档的语言，例如，Word、PDF、AFP、Postscript等等。
从图1可以看出，我们的EJB主要用在对数据库的操作上。对于数据库的操作，主要是对数据模板(BDT)的提取，然后和本地客户数据进行整合，进而得出需要真正从数据库取出数据的组合(ASL)，最后进行后面的排版(CE)、计算，生成各种不同类型的文档。
3．1．2 解耦数据库
既然我们要去除EJB和数据库的束缚，我们能不能绕过去呢?进一步分析，我们得到，数据模板在和客户数据装载(Assemble)后会在数据库里生成一个xml文件，用来描述最终会用到的具体的存在于数据库中间的文本片段。而这个xml文件，我们称之为ASL。我们试想，如果我们用一个办法，直接生成我们要用到的ASL文件，那么我们是不是就可以绕过EJB和数据库了呢?
答案是一半肯定，一半否定。首先，我们的确能绕过EJB的应用，它主要用于assemble这个阶段。但是光有ASL是没有用的，因为我们还需要通过ASL去数据库里取得所有的文本片段去做整合(Merge)。那么我们能不能把输入进一步地往后面推，推到Merge以后呢?答案是不能。首先来说Merge的输入也就是文本片段会有很多，他们之间的关系很复杂，这些都是记录在ASL里面，并且，Merge本身就是一个比较容易出问题的模块，是我们做这个Test Client要重点模拟和测试的模块，所以我们只能另想办法。
这里我们大概介绍一下通过ASL去数据库取文本片段的过程。这个过程其实比较简单，因为逻辑方面的运算已经在Assemble的过程中处理完成，这里的任务是根据ASL里面的一个个的文本片段ID去数据库里取出相应的数据来进行后续的流程。既然是这样的一个过程，我们决定尝试通过本地文件来模拟数据库记录。我们可以把数据从数据库里取出来，按照一定的规则，给它们命名为本地的一个个文件，然后在我们的测试框架中重载以前的去数据库取文本片段的方法为去本地的文件夹里取。这样的确是可行的，因为：
(1)我们的目的是验证我们的文档历史的保真度(Fidelity)的问题，那么我们的文档的文本片段是不会有所改变的。所以我们可以把它们放心转移到本地，而不用担心更新问题。
(2)文件放到本地，能减少传输上的消耗，并且如果把方法进行重载，是代价最小和最自然的一件事情，并且能最大限度地利用原来的代码。
(3)经过一些小小实验，我们发现经过很小的改动，我们可以把数据库的文件按照一定的规则改写到本地。这些都可以通过写一些小程序来实现。以后有新的文档，都可以用这个方法来实现，简单而易用。
3．1．3 输入和输出
在去除EJB和数据库的束缚的过程中，我们得到了我们的输入方式，那就是ASL+Text Pieces。输出文件当然很简单了，我们选择PDF，这个是我们主要的打印格式，当然，我们可以方便配置生成其它的格式文件，但是对于自动比较，由于我们现在的工具只支持PDF的比较，所以，对其它的格式文件输出，我们暂时不能提供自动比较。

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

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