軟件測試中自動化測試框架: 設計的重構
單元測試（模塊測試）是開發者編寫的一小段代碼，用于檢驗被測代碼的一個很小的、很明確的功能是否正確。通常而言，一個單元測試是用于判斷某個特定條件（或者場景）下某個特定函數的行為。例如，你可能把一個很大的值放入一個有序list 中去，然后確認該值出現在list 的尾部�；蛘�，你可能會從字符串中刪除匹配某種模式的字符，然后確認字符串確實不再包含這些字符了。
單元測試是由程序員自己來完成，最終受益的也是程序員自己�？梢赃@么說，程序員有責任編寫功能代碼，同時也就有責任為自己的代碼編寫單元測試。執行單元測試，就是為了證明這段代碼的行為和我們期望的一致。
工廠在組裝一臺電視機之前，會對每個元件都進行測試，這，就是單元測試。
其實我們每天都在做單元測試。你寫了一個函數，除了極簡單的外，總是要執行一下，看看功能是否正常，有時還要想辦法輸出些數據，如彈出信息窗口什么的，這，也是單元測試，把這種單元測試稱為臨時單元測試。只進行了臨時單元測試的軟件，針對代碼的測試很不完整，代碼覆蓋率要超過70%都很困難，未覆蓋的代碼可能遺留大量的細小的錯誤，這些錯誤還會互相影響，當BUG暴露出來的時候難于調試，大幅度提高后期測試和維護成本，也降低了開發商的競爭力�？梢哉f，進行充分的單元測試，是提高軟件質量，降低開發成本的必由之路。
對于程序員來說，如果養成了對自己寫的代碼進行單元測試的習慣，不但可以寫出高質量的代碼，而且還能提高編程水平。
要進行充分的單元測試，應專門編寫測試代碼，并與產品代碼隔離。老納認為，比較簡單的辦法是為產品工程建立對應的測試工程，為每個類建立對應的測試類，為每個函數（很簡單的除外）建立測試函數。首先就幾個概念談談老納的看法。
一般認為，在結構化程序時代，單元測試所說的單元是指函數，在當今的面向對象時代，單元測試所說的單元是指類。以老納的實踐來看，以類作為測試單位，復雜度高，可操作性較差，因此仍然主張以函數作為單元測試的測試單位，但可以用一個測試類來組織某個類的所有測試函數。單元測試不應過分強調面向對象，因為局部代碼依然是結構化的。單元測試的工作量較大，簡單實用高效才是硬道理。
有一種看法是，只測試類的接口(公有函數)，不測試其他函數，從面向對象角度來看，確實有其道理，但是，測試的目的是找錯并最終排錯，因此，只要是包含錯誤的可能性較大的函數都要測試，跟函數是否私有沒有關系。對于C++來說，可以用一種簡單的方法區隔需測試的函數：簡單的函數如數據讀寫函數的實現在頭文件中編寫(inline函數)，所有在源文件編寫實現的函數都要進行測試(構造函數和析構函數除外)。
最近對測試框架進行了重構，也對其中原有的一些設計進行了反思。其中不免有一些自我感覺得意之處，因此寫出來和大家分享。這是一個重構的過程，所以將以重構的思路來講述。
先來說說為什么會重構。原先的框架系統，思路是將自動化代碼，通過調用控件的適配接口，最終完成對界面的操作。而這些代碼，也被編譯到DLL中。這里面就有一些問題：
每一次修改，都必須重新編譯。
由于DLL被程序Load，不可直接覆蓋，所以必須重新啟動被測試系統。
基本上不可以部分執行腳本。
自動化代碼和自動化框架代碼同時暴露給用戶
再一次說明一下原先的設計。原先的設計中，自動化代碼將作為DLL的一部分被編譯進去，而這個DLL會作為程序系統的一部分被裝載。本來我想用圖形來表示，突然感覺其實可以多多用表達式來表示，我想做一個嘗試，這樣可以免去圖片的麻煩。
被測試系統（自動化框架（自動化代碼））
其中括號表示包含關系。最終只有一個系統在運行。為了解決這些問題，我們思考從腳本入手，進行自動化測試框架的重構。
首先重構的對象是，將自動化代碼的編寫改變為XML的配置。自動化框架通過讀取配置，并解析每一段腳本，自動執行。我們先不談其中的實現技術細節，而是先來談談這樣的好處。
腳本是解釋性的，因此框架DLL不需要重新編譯。
腳本由于成為配置，那么其管理也就變得更加容易和簡單。
可以讓測試人員，完全只是關心業務上的腳本。
從配置中，可以方便地記錄每一步的執行內容。原先的編譯方式，失去了很多信息。
配置可以動態組織，這樣有可能實現部分腳本的執行。
重構，就是發現問題到解決問題的過程。相對于設計的不同，在于重構是在現有設計的基礎上發現問題。
下面說說實現過程中的細節。在這個過程中，最關鍵的是腳本的解析。由于之前，針對所有控件，都已經有了封裝的接口，因此在這個基礎上，我們考慮到采用SOAP的實現思想，通過對接口方法的Invoke，來實現最終的腳本執行。
要實現這個Invoke的過程，就必須深入了解一下Delphi是如何實現SOAP的。這當然是另外一個話題了。有興趣的可以看一下Invoker.pas中的代碼。要實現Invoke的過程，可以有兩個選擇：
完全參考SOAP的調用約束
自己定義結構，自己解析轉換參數，實現Invoke
我實際是選擇了后者，雖然說對于我理解Invoke原理有了很大幫助，但后來還是證實我的選擇不是最好的。先不管這個了。
完成了Invoke的過程，下面就是腳本的設計了。我為腳本的設計，增加了幾方面的內容：
定義TestWindow的概念，表示每一個被測試和編碼的窗體。
定義TestStep的概念，表示對用戶界面發出的每一次命令。
定義TestPackage概念，表示多個TestStep的組合。
定義TestWindow和TestStep之間的關系。TestWindow包含多個TestStep。每一個TestStep包含多個TestWindow，表示這個命令可能觸發的新的測試窗體。
定義這些概念是非常有意義的�？梢詭椭覀兦逦乩斫庀到y，也非常便于以后的技術交流。這也說明了自動化測試框架本身設計的完善和進步。
在定義完成這些概念后，就是完成一個腳本的配置工具。并在這個編輯器上實現腳本的調試和日志功能。調試方面，我們選擇了HTTP的調用方式。其實可以選擇很多其他方式。一來HTTP的方式，實現起來很簡單。二來支持HTTP后，調用自動化測試，只需要通過HTTP就可以了。FinalBuilder和一些Shell都支持這種方式。這對于以后的自動化調用是非常有意義的。
現在系統的架構變了。不再是原先的一個系統了，因為這里引入了一個輔助系統，可以稱之為自動化的IDE。再使用上面的方式，我們描述以下系統：
被測試系統（自動化框架）＝ IDE（自動化腳本）
等號表示系統交互是雙方向的。IDE向系統發送腳本，系統向IDE發送LOG。
好了，這次重構基本都完成了。整個過程的中心在于腳本的結構遷移。而重構的前因和結果也都進行了對比。雖然說很多方面的細節也許并沒有考慮清除。但是這次框架設計的重構，其實更是框架本身的完善過程。
希望自動化測試框架越來越好！
文章來源于領測軟件測試網 http://www.k11sc111.com/
