基于腳本的構件測試自動化框架[2]

　　基于腳本的構件測試自動化框架[2]   軟件測試

　　2 構件測試自動化框架設計

　　為了實現構件測試自動化，本文沿用現有的軟件測試自動化技術。由于構件是二進制復用，使用方常得不到構件的源代碼，構件對使用方而言是黑盒，無法進行代碼分析。若采用捕獲/回放方法，將會擁有大量測試腳本，并且當構件版本升級時，相應的測試腳本也必須重新錄制。

　　因此，測試自動化將采用前面提到的測試腳本技術。這可以分為測試腳本的自動生成與自動運行。前者建立在構件及其元數據的基礎上，后者應當能夠自動讀取獨立的測試用例數據。要實現構件測試的自動化，必須使測試驅動程序能夠直接讀取測試用例文件，并自動執行。

　　XML 語言強大的數據描述能力和方便快捷的解析手段，使之成為構件測試的最佳用例描述語言。在測試用例XML 文件中，一個構件對應一個Test Suites，一個CoClass 對應一個Test Suite，每個待測試的方法對應多個測試用例。

　　每個測試用例給出一組輸入參數和預期輸出參數，每個參數指出其名字和類型。測試驅動程序讀取測試用例到測試腳本中時可以使用XML 文檔讀寫的API，簡單方便。

　　2.1 構件混合測試自動化框架

　　本文的構件測試自動化框架主要基于xUnit 框架。對構件中方法的測試通常有相同的測試邏輯和稍有不同的系統輸入，因此，考慮將測試邏輯與測試用例分離，這樣既能獲得較好的測試覆蓋，又能最小化需要編寫與維護的測試代碼量。

　　因此，不能簡單地依賴xUnit 框架。本文設計的構件測試自動化框架將對xUnit 框架進行改進，把它與數據驅動測試的策略結合起來。xUnit 框架是單元測試框架，而數據驅動的測試框架適合于用戶測試。很多第三方構件則需要用戶對其進行黑盒單元測試，因此，將兩者結合切實可行。

　　為了應用數據驅動的測試策略，本框架設計了單獨的測試用例XML 文件用來存儲輸入和期望值。這些數據將被傳遞到測試腳本中。這樣，原先的測試就成為參數化測試，由測試驅動擔當數據驅動測試解釋器的角色，向測試腳本傳遞參數，包括輸入值和期望值。而共同的測試邏輯包括測試方法的調用和斷言的調用。

　　在具體實現兩者的結合時，最簡單的方法是在測試方法中包含一個循環來從測試用例文件中讀取輸入數據值和期望結果的集合。但這將導致一個單獨的測試用例對象帶有許多斷言。由此而來的結果是：

　　(1)執行的所有測試用例將被視作一個測試，這樣將減少執行的測試的計數。

　　(2)測試將在第一個失敗處停止，接下來的測試用例將不再運行。這正是xUnit 框架對于用戶測試存在的不足。這樣測試的充分性將大幅降低，將錯過后面可能也引起斷言失敗的測試用例，從而減少了缺陷的暴露，丟失很多錯誤定位。

　　(3)不能告訴測試者失敗發生時哪個子測試正被執行。這些問題正是測試的獨立性問題。尤其是在構件測試中，構件是有狀態的，因此，按上述方法測試，各次測試之間很可能有較緊密的耦合關系。

　　這樣必然造成測試的不準確。為了保證每次測試都是獨立的，本框架將繼續對xUnit 框架進行改進：對于每個測試用例都實例化，都進行測試固定設施的初始化和清理工作。這樣每個測試用例都能運行于自己的測試上下文中。

原文轉自：http://www.anti-gravitydesign.com