自動化測試在動態文檔發布系統中的應用

首先介紹一下每個術語：
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的比較，所以，對其它的格式文件輸出，我們暫時不能提供自動比較。