电子发烧友App
摘要：文章首先介绍了动态文档发布系统，然后为了达到保证文档保真度不因系统升级而降低的目的，提出了一种轻量级的自动化测试框架，它能够对该系统进行自动化测试。然后，根据对该自动测试框架的要求，结合对实际系统各个模块的分析，运用模拟的方法绕过原系统对数据库的依赖，提出并实现了一个完整的解决方案。本方案既保证了客户文档在不同版本动态文档打印系统间的保真度，又极大地提高了生产效率。
引言
对于大多数人来说，都会有这样的客户体验：去银行或者保险公司办理业务，或者接收他们的保单宣传，我们所面对和接收的都是一张张一样的表单，然后上面有一些空白的表格或者下划线，然后将客户的信息填上去。这样的做法有以下两个缺点：
(1)客户体验差。所有客户拿到的都是一样的表单，因为考虑特殊的情况，表单里面的空白的地方都会比较大，所以一般会出现大片空白的区域。
(2)对于每种不同的客户或者不同的业务会需要不同的表单，对于客户信息变动的情况，需要人工完成，比较繁琐。
为了更好的客户体验，越来越多的公司倾向于采用动态打印技术。这样每个客户接收到的文档或者打印件都是定制化的，这样就能克服以上缺点而做到：
(1)客户体验优。所有客户拿到的文档都是定制化的，表单里没有需要填空的地方，客户的数据都会被程序动态地植入表格模板里，就好像专门为客户定做的文档。
(2)我们可以在模板中定义一些规则，然后根据客户数据来采用相应的规则。例如，美国各个州的法律是不一样的，我们可以在编辑文档的时候就定义规则：如果客户是A州的，就用A条文，如果是B州的，就用B条文。这样当生成文档的时候，程序会根据当前客户是属于哪个州的，动态地加入这一段条文，而不需要人工的判定。并且，当客户从A州搬到B州，我们只需要更新一下客户的数据，客户下次就能拿到更新的正确的文档。
1 动态文档发布系统
有了如上的需求，很多公司都加入了开发动态文档发布系统的行列。对于动态文档发布，简单说起来，一般的步骤是：1)建立文档模板;2)运行时，装载客户数据进入模板;3)拼接文档;4)排版;5)输出前处理;6)输出成不同格式的文档;7)发布和归档。
动态文档发布系统可以使客户高性能制作并发送设计精美、高度个性化的沟通材料，从合同、保险单、大批量的账户关系维护通知单，到定制的推广资料、商业信函等。客户可以在该系统平台上，运用自己熟悉的文档开发软件，如Word、Adobe Indesign、Dream Weaver，开发出文档模板，并根据系统提供的插件进行逻辑的设置。然后，该模板就能被送往系统，跟随提供的客户数据而批量地生成客户需要的定制文档。接着，生成的文件可以通过不同的途径，例如，邮件、e-mail、手机短信等方式发送到客户，使客户有良好的用户体验。
2 自动化测试的要求
对于这样一个复杂的系统，它的主要客户是一些保险公司和银行，而它的主要产出是保单和合同。同时，合同和保单都是很严肃和很严谨的文档。客户需要的是他们的客户在客户数据没有改变的情况下，得到的是一贯的体验。
但是同时，动态文档发布系统本身又是一个不断发展和改善的系统。它拥有非常复杂的排版逻辑，并且每个版本的升级都会有大量的新功能和新逻辑被引入，这样的逻辑改变如果哪怕有一点点的差错，原来客户的整个文档可能就会面目全非。如果老的客户需要升级这些新功能的话，我们需要保证客户得到一贯的体验。也就是说，他们用旧的版本系统生成的文档和在新的版本系统生成的文档要保持一致，除非新的版本生成的更好，并得到客户的同意。
这样，为了达到上面的目标，我们需要在新版本发布前，运行一些老客户的文档(挑选一些很典型的客户文档)，并且一个个和老版本生产的文档进行比较。但是我们不能把这个过程推到新版本发布之前才做，因为那个时候整个项目已经积累了很多的不同点，很难追查到源头并加以改正。所以我们需要把这个过程提前，并且频繁地去检查。
由于需要频繁的检查，并且文档的比较是个很繁重的体力活，所以自动测试将会是很好的方法，它不仅能够节省绝对的人力，而且能够保证绝对的准确，不会被人为因素干扰。
我们可以把这个自动测试集成到日常的打包系统中，每次打包后就可以自动地完成运行，比较和生成报告。
但是，我们不能在打包服务器上每次都去部署新的系统，因为那样太笨重了，并且会让环境问题和我们系统本身的问题经常性地纠缠不清。所以，我们需要自己建立一套轻量级的架构去承载这个测试过程：
(1)我们的系统是建立在基于应用服务器的EJB架构上的，并且EJB的主要操作是基于对数据库的操作，但是我们对于该自动测试的系统的要求是，对外部的依赖越少越好，因为这样的话，我们就能很方便地在各个相关程序员和测试人员以及配置人员之间进行部署和实施，所以我们希望他不要依赖应用服务器和数据库。
(2)我们要明确输入源和输出源，并且能够提供一些简单并且方便的配置，而且在很小代价的前提下，能够在不同的输入源和输出源之间随意切换。
(3)结果必须是可以有办法鉴别的，并且鉴别结果是能够很容易取得和方便查阅的。
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的比较，所以，对其它的格式文件输出，我们暂时不能提供自动比较。
工商网监
评论