0 引言
    對于大多數人來說，都會有這樣的客戶體驗：去銀行或者保險公司辦理業務，或者接收他們的保單宣傳，我們所面對和接收的都是一張張一樣的表單，然后上面有一些空白的表格或者下劃線，然后將客戶的信息填上去。這樣的做法有以下兩個缺點：
    (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的比較，所以，對其它的格式文件輸出，我們暫時不能提供自動比較。

3．2 框架方案
    有了輸入和輸出，以及明確的需求，我們給出框架的解決方案：

    (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 結論
    由于文檔發布系統的客戶對于不同系統版本間文檔一致性的高要求，使我們必須要提供一個長久的機制保證這個一致性。而要保證這個系統的一致性，我們提出了一個輕量級自動測試的方案。這里所說的輕量級，只是說該框架下運行方便，不需要受應用服務器和數據庫的約束，但是理論它上提供了文檔發布系統同樣的功能和行為。實際上在整個過程中，我們盡量調用原先系統的程序，但是在解除對于服務器和數據庫的依賴方面，我們通過仔細分析原來的動態文檔發布系統各個模塊的前提下，采用了用本地文件模擬數據庫的方法，通過重載方法實現了對于數據庫的解耦。該框架提供了強大的可配置功能，通過簡單的XML設置，我們可以對整個過程進行配置，靈活實現不同的功能組合。
    在未來，我們還會不斷完善這個框架，例如會提供更多的輸入選擇，提供可視化的配置，提供盡量準確的診斷功能幫助程序員方便定位錯誤，并且根據動態文檔發布系統的升級而相應提供更多的配置和功能。