先來說說為什么會重構。原先的框架系統，思路是將自動化代碼，通過調用控件的適配接口，最終完成對界面的操作。而這些代碼，也被編譯到DLL中。這里面就有一些問題：
１.每一次修改，都必須重新編譯。
２.由于DLL被程序Load，不可直接覆蓋，所以必須重新啟動被測試系統。
３.基本上不可以部分執行腳本。
４.自動化代碼和自動化框架代碼同時暴露給用戶。
再一次說明一下原先的設計。原先的設計中，自動化代碼將作為DLL的一部分被編譯進去，而這個DLL會作為程序系統的一部分被裝載。本來我想用圖形來表示，突然感覺其實可以多多用表達式來表示，我想做一個嘗試，這樣可以免去圖片的麻煩。
被測試系統（自動化框架（自動化代碼））
其中括號表示包含關系。最終只有一個系統在運行。為了解決這些問題，我們思考從腳本入手，進行自動化測試框架的重構。
首先重構的對象是，將自動化代碼的編寫改變為XML的配置。自動化框架通過讀取配置，并解析每一段腳本，自動執行。我們先不談其中的實現技術細節，而是先來談談這樣的好處。
１.腳本是解釋性的，因此框架DLL不需要重新編譯。
２.腳本由于成為配置，那么其管理也就變得更加容易和簡單。
３.可以讓測試人員，完全只是關心業務上的腳本。
４.從配置中，可以方便地記錄每一步的執行內容。原先的編譯方式，失去了很多信息。
５.配置可以動態組織，這樣有可能實現部分腳本的執行。
重構，就是發現問題到解決問題的過程。相對于設計的不同，在于重構是在現有設計的基礎上發現問題。
下面說說實現過程中的細節。在這個過程中，最關鍵的是腳本的解析。由于之前，針對所有控件，都已經有了封裝的接口，因此在這個基礎上，我們考慮到采用SOAP的實現思想，通過對接口方法的Invoke，來實現最終的腳本執行。
要實現這個Invoke的過程，就必須深入了解一下Delphi是如何實現SOAP的。這當然是另外一個話題了。有興趣的可以看一下Invoker.pas中的代碼。要實現Invoke的過程，可以有兩個選擇：
１.完全參考SOAP的調用約束
２.自己定義結構，自己解析轉換參數，實現Invoke
我實際是選擇了后者，雖然說對于我理解Invoke原理有了很大幫助，但后來還是證實我的選擇不是最好的。先不管這個了。
文章來源于領測軟件測試網 http://www.kjueaiud.com/