這兩個缺點，讓我們決定，為每一個窗體都建立一個基類，在這個基類中，完成所有控件的定義和訪問。并將所有這些控件封裝類，集中在一個單元中。每一個類，一個單元也想過，但是感覺太復雜了。也沒必要。
這里面還有另外一個易用性問題。這和第一篇中講到的組件架構有關。如果我們的測試業務代碼，都是和主程序混在一起，那么對于測試人員，
他們必須在有主程序代碼的前提下，才可以調試業務測試代碼 程序代碼，也會成為他們的負擔另外，從程序代碼的封裝角度來看，也有可能遭受破壞的可能。所以，決定將所有業務代碼都封裝到一個獨立的Dll中。另外，為了降低Dll對程序代碼的依賴，所有對控件的訪問，都通過對應的接口（如IEdit,IForm,IButton）來訪問，而這些接口的對象實例的創建，都可以留在程序代碼中（這是為了方便擴展）。
整個框架過程中，還有幾個重要的問題。第一個就是控件名稱的命名問題。本來可能通過控件的屬性來生成，但后來發現，不一定有中文信息，比如Edit控件啊，Grid控件啊。所以支持了字典表的方式來做翻譯。首先將控件Name按照駱駝命名法分離，然后將那些縮寫或者單詞，到對應表中，查找中文解釋，最后組合稱為名稱。
還有就是業務流程的Log問題。這個實現，后來采用的是AOP模式。具體的實現思路，后面會有專門介紹。
當然了，實際應用中，還可能有很多其他問題。這些都需要細細解決�？傊痪湓�，由于充分考慮了用戶的感受，所以這部分的框架，改了又改，現在才稍微滿意了。
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
