那么業務模塊劃分的準則和依據到底是什么呢？不同的系統有著不同的標準，下面引用一個案例對金融系統做個粗略的介紹。
對金融系統來說，我們進行業務分解和設計業務流程的時候需要做如下要求：
1.較為模塊化的設計，避免重復的腳本，減少建立或維護腳本的成本。
2.在應用軟件開發的同時，就可以同步進行腳本建立的動作，而且當應用軟件功能變動時，只需要修改業務功能腳本。
3.由于應用軟件的功能已經被分解成獨立的業務功能腳本，測試人員可以隨意組合業務功能腳本成為更復雜多樣的測試個案。
4.測試輸入數據與驗證數據與腳本分開，儲存在另外的檔案，如純文字文件或 Excel 文件，測試人員可以更容易修改與維護。
5.加強錯誤處理合結果分析判斷，讓腳本更有彈性。
當然這樣做也會帶來一定的額外開銷，但是這些都是必須的，自動化本身就是需要結合良好的管理以犧牲人力成本來贏得時間的，針對一些缺點我做一下簡單的注釋：
1.在編寫業務功能腳本時，需要「精通」測試工具腳本語言的工程師：其實很多公司都有實力尋找這樣的人，因為VBS本身相對比較簡單，雖然自動化測試還沒有在整個中國全面興起，但是有著豐富自動化測試經驗的測試人員已經非常多了。
2.每個Action都會有自己的輸入輸出參數，需要用文檔統一維護，控制變更：這的確增加了一些工作量，但是對測試本身的規范來說，是一大進步。
3.測試人員除了要維護測試計劃之外，還要另外維護數據文件：同上。
4.對軟件測試工具以及腳本語言來說，使用數據文件可能也要注意數據文件的格式。
這個分解結果來自51Testing上的一位同仁，我在做完興業銀行自動化之后做總結的時候無意發現了這段話，緣分哪！與我的想法不謀而和，呵呵，所以當時就Copy下來了，并非有意剽竊，如果侵犯了這位仁兄，敬請原諒！這里修改了一些地方，我覺得這是金融尤其是銀行業務分解的一個經典，也算是一個不大不小的標準吧，可能并不能適用于所有系統，但是對銀行來說，還是很實用的。
下面以興業銀行交易處理中心項目自動化測試為例，看看這份業務分解和腳本規范會帶來什么樣的效果。（注：附件文檔乃非正式發布文檔，系個人私有，不牽涉興業銀行商業秘密，諸位放心�。�
系統說明：
前臺Teller（銀行柜員操作界面）、電子驗印系統（印章校驗）、Integrator（信息管道）、工作流系統（IBM的FileNet）、后臺交易集中處理系統（中間業務平臺）、核心（聯想亞信的FTS）等�？紤]金融系統的安全性，所有交易流程的處理采用獨占的方式，后臺界面交易處理按交易優先級次、時間先后進行，同等條件下FileNet隨機分配，所以自動化的難度相當的大。交易功能分解按照操作員崗位職責劃分為前臺柜員，CPC（中間業務平臺）的錄入崗、審核崗、報文審核崗、異常處理崗、監控崗等部分。
實際應用：
這樣的框架設計會帶來什么結果呢？我們來計算一下：
1.前臺發起的交易大約有60多個，每個交易的典型業務覆蓋需要大約20個流程，這樣共計1200個測試流程；
2.每個測試流程除去操作員登陸、簽退之后大約有10個腳本，這樣如果沒有采取公用的話，每個健全的腳本應該在200行左右，不計算重復的測試流程，總的腳本的行數應該是：10*200*60=120000行；
3.但是采用了子模塊的公用，我們完整地寫了不到300個腳本（其中包含近百個10行以內的登陸、登出腳本），平均每個腳本只有不到100行，并且通文件系統操作覆蓋了所有的流程，即：300*100=30000行；
4.這樣可以清楚地看到，同樣覆蓋了1200個流程，我們節省了75%的腳本行數，減輕至少50%的工作量（考慮技術問題甚至80%），為QC/TD服務器也減輕了75%的存儲壓力，雖然在技術上帶來一定難度，但是也沒有產生多大的影響。
如果在沒有外界壓力的情況下，這種框架設計是非常有效的。很明顯，稍微加大一些技術層面的工作量會給我們帶來很大的好處：
1.減少30%到50%甚至更多的腳本編寫的工作量，系統越大，有點越明顯。
2.后期維護難度和工作量在同一的管理下大幅度下降。
3.減輕了測試管理服務器的存儲壓力，對于QC/TD和QTP的license不多的企業和單位來說，統一協調運行、管理可以很大程度上減少由于license有限帶來的時效性不高的問題。
剛才提到外界壓力，什么是外界壓力：我是你老大，我讓你寫1000個腳本你就不能偷懶寫900……
文章來源于領測軟件測試網 http://www.kjueaiud.com/