自動化測試在動態(tài)文檔發(fā)布系統(tǒng)中的應(yīng)用

摘要：文章首先介紹了動態(tài)文檔發(fā)布系統(tǒng)，然后為了達(dá)到保證文檔保真度不因系統(tǒng)升級而降低的目的，提出了一種輕量級的自動化測試框架，它能夠?qū)υ撓到y(tǒng)進(jìn)行自動化測試。然后，根據(jù)對該自動測試框架的要求，結(jié)合對實(shí)際系統(tǒng)各個模塊的分析，運(yùn)用模擬的方法繞過原系統(tǒng)對數(shù)據(jù)庫的依賴，提出并實(shí)現(xiàn)了一個完整的解決方案。本方案既保證了客戶文檔在不同版本動態(tài)文檔打印系統(tǒng)間的保真度，又極大地提高了生產(chǎn)效率。
關(guān)鍵詞：動態(tài)文檔發(fā)布；自動測試；模擬

0 引言
對于大多數(shù)人來說，都會有這樣的客戶體驗(yàn)：去銀行或者保險公司辦理業(yè)務(wù)，或者接收他們的保單宣傳，我們所面對和接收的都是一張張一樣的表單，然后上面有一些空白的表格或者下劃線，然后將客戶的信息填上去。這樣的做法有以下兩個缺點(diǎn)：
(1)客戶體驗(yàn)差。所有客戶拿到的都是一樣的表單，因?yàn)榭紤]特殊的情況，表單里面的空白的地方都會比較大，所以一般會出現(xiàn)大片空白的區(qū)域。
(2)對于每種不同的客戶或者不同的業(yè)務(wù)會需要不同的表單，對于客戶信息變動的情況，需要人工完成，比較繁瑣。
為了更好的客戶體驗(yàn)，越來越多的公司傾向于采用動態(tài)打印技術(shù)。這樣每個客戶接收到的文檔或者打印件都是定制化的，這樣就能克服以上缺點(diǎn)而做到：
(1)客戶體驗(yàn)優(yōu)。所有客戶拿到的文檔都是定制化的，表單里沒有需要填空的地方，客戶的數(shù)據(jù)都會被程序動態(tài)地植入表格模板里，就好像專門為客戶定做的文檔。
(2)我們可以在模板中定義一些規(guī)則，然后根據(jù)客戶數(shù)據(jù)來采用相應(yīng)的規(guī)則。例如，美國各個州的法律是不一樣的，我們可以在編輯文檔的時候就定義規(guī)則：如果客戶是A州的，就用A條文，如果是B州的，就用B條文。這樣當(dāng)生成文檔的時候，程序會根據(jù)當(dāng)前客戶是屬于哪個州的，動態(tài)地加入這一段條文，而不需要人工的判定。并且，當(dāng)客戶從A州搬到B州，我們只需要更新一下客戶的數(shù)據(jù)，客戶下次就能拿到更新的正確的文檔。

1 動態(tài)文檔發(fā)布系統(tǒng)
有了如上的需求，很多公司都加入了開發(fā)動態(tài)文檔發(fā)布系統(tǒng)的行列。對于動態(tài)文檔發(fā)布，簡單說起來，一般的步驟是：1)建立文檔模板；2)運(yùn)行時，裝載客戶數(shù)據(jù)進(jìn)入模板；3)拼接文檔；4)排版；5)輸出前處理；6)輸出成不同格式的文檔；7)發(fā)布和歸檔。
動態(tài)文檔發(fā)布系統(tǒng)可以使客戶高性能制作并發(fā)送設(shè)計(jì)精美、高度個性化的溝通材料，從合同、保險單、大批量的賬戶關(guān)系維護(hù)通知單，到定制的推廣資料、商業(yè)信函等?？蛻艨梢栽谠撓到y(tǒng)平臺上，運(yùn)用自己熟悉的文檔開發(fā)軟件，如Word、Adobe Indesign、Dream Weaver，開發(fā)出文檔模板，并根據(jù)系統(tǒng)提供的插件進(jìn)行邏輯的設(shè)置。然后，該模板就能被送往系統(tǒng)，跟隨提供的客戶數(shù)據(jù)而批量地生成客戶需要的定制文檔。接著，生成的文件可以通過不同的途徑，例如，郵件、e-mail、手機(jī)短信等方式發(fā)送到客戶，使客戶有良好的用戶體驗(yàn)。

2 自動化測試的要求
對于這樣一個復(fù)雜的系統(tǒng)，它的主要客戶是一些保險公司和銀行，而它的主要產(chǎn)出是保單和合同。同時，合同和保單都是很嚴(yán)肅和很嚴(yán)謹(jǐn)?shù)奈臋n?？蛻粜枰氖撬麄兊目蛻粼诳蛻魯?shù)據(jù)沒有改變的情況下，得到的是一貫的體驗(yàn)。
但是同時，動態(tài)文檔發(fā)布系統(tǒng)本身又是一個不斷發(fā)展和改善的系統(tǒng)。它擁有非常復(fù)雜的排版邏輯，并且每個版本的升級都會有大量的新功能和新邏輯被引入，這樣的邏輯改變?nèi)绻呐掠幸稽c(diǎn)點(diǎn)的差錯，原來客戶的整個文檔可能就會面目全非。如果老的客戶需要升級這些新功能的話，我們需要保證客戶得到一貫的體驗(yàn)。也就是說，他們用舊的版本系統(tǒng)生成的文檔和在新的版本系統(tǒng)生成的文檔要保持一致，除非新的版本生成的更好，并得到客戶的同意。
這樣，為了達(dá)到上面的目標(biāo)，我們需要在新版本發(fā)布前，運(yùn)行一些老客戶的文檔(挑選一些很典型的客戶文檔)，并且一個個和老版本生產(chǎn)的文檔進(jìn)行比較。但是我們不能把這個過程推到新版本發(fā)布之前才做，因?yàn)槟莻€時候整個項(xiàng)目已經(jīng)積累了很多的不同點(diǎn)，很難追查到源頭并加以改正。所以我們需要把這個過程提前，并且頻繁地去檢查。
由于需要頻繁的檢查，并且文檔的比較是個很繁重的體力活，所以自動測試將會是很好的方法，它不僅能夠節(jié)省絕對的人力，而且能夠保證絕對的準(zhǔn)確，不會被人為因素干擾。
我們可以把這個自動測試集成到日常的打包系統(tǒng)中，每次打包后就可以自動地完成運(yùn)行，比較和生成報告。
但是，我們不能在打包服務(wù)器上每次都去部署新的系統(tǒng)，因?yàn)槟菢犹恐亓?，并且會讓環(huán)境問題和我們系統(tǒng)本身的問題經(jīng)常性地糾纏不清。所以，我們需要自己建立一套輕量級的架構(gòu)去承載這個測試過程：
(1)我們的系統(tǒng)是建立在基于應(yīng)用服務(wù)器的EJB架構(gòu)上的，并且EJB的主要操作是基于對數(shù)據(jù)庫的操作，但是我們對于該自動測試的系統(tǒng)的要求是，對外部的依賴越少越好，因?yàn)檫@樣的話，我們就能很方便地在各個相關(guān)程序員和測試人員以及配置人員之間進(jìn)行部署和實(shí)施，所以我們希望他不要依賴應(yīng)用服務(wù)器和數(shù)據(jù)庫。
(2)我們要明確輸入源和輸出源，并且能夠提供一些簡單并且方便的配置，而且在很小代價的前提下，能夠在不同的輸入源和輸出源之間隨意切換。
(3)結(jié)果必須是可以有辦法鑒別的，并且鑒別結(jié)果是能夠很容易取得和方便查閱的。

3 設(shè)計(jì)方案
根據(jù)上面提出的三個要求，我們將通過分析我們的系統(tǒng)來提出我們的解決方案。
3．1 分析
對于這個系統(tǒng)來說，我們首先需要解決對于應(yīng)用服務(wù)器，也就是對于EJB的依賴。為了達(dá)到這個目的，我們必須對系統(tǒng)的主要模塊進(jìn)行分析，來想辦法如何解除依賴。