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

摘要：文章首先介紹了動態文檔發布系統，然后為了達到保證文檔保真度不因系統升級而降低的目的，提出了一種輕量級的自動化測試框架，它能夠對該系統進行自動化測試。然后，根據對該自動測試框架的要求，結合對實際系統各個模塊的分析，運用模擬的方法繞過原系統對數據庫的依賴，提出并實現了一個完整的解決方案。本方案既保證了客戶文檔在不同版本動態文檔打印系統間的保真度，又極大地提高了生產效率。
關鍵詞：動態文檔發布；自動測試；模擬

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的依賴。為了達到這個目的，我們必須對系統的主要模塊進行分析，來想辦法如何解除依賴。