實際應用：
這樣的框架設計會帶來什么結果呢?我們來計算一下：
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有限帶來的時效性不高的問題。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
