自動化測試的探討

領測軟件測試網

自動化測試的探討      軟件測試

    目前測試工作大多數以手動為主，并不是各個軟件公司不想做自動化測試，無奈再沒有成熟單位應用的情況下，但靠每個公司自己的摸索，顯然比手動測試代價更大，且項目變化頻度過快，也對測試框架提出了挑戰，到底公司能夠下多大的人力，物力來做測試框架的搭建，想必也是困擾了大家許久�？蚣苓@個概念并不是只有在測試里面有，開發同樣也有框架的概念。

        框架（Framework）是整個或部分系統的可重用設計，表現為一組抽象構件及構件實例間交互的方法;另一種定義認為，框架是可被應用開發者定制的應用骨架。前者是從應用方面而后者是從目的方面給出的定義。

 
        可以說，一個框架是一個可復用的設計構件，它規定了應用的體系結構，闡明了整個設計、協作構件之間的依賴關系、責任分配和控制流程，表現為一組抽象類以及其實例之間協作的方法，它為構件復用提供了上下文(Context)關系。因此構件庫的大規模重用也需要框架。

        構件領域框架方法在很大程度上借鑒了硬件技術發展的成就，它是構件技術、軟件體系結構研究和應用軟件開發三者發展結合的產物。在很多情況下，框架通常以構件庫的形式出現，但構件庫只是框架的一個重要部分�？蚣艿年P鍵還在于框架內對象間的交互模式和控制流模式。

        框架比構件可定制性強。在某種程度上，將構件和框架看成兩個不同但彼此協作的技術或許更好�？蚣転闃嫾�提供重用的環境，為構件處理錯誤、交換數據及激活操作提供了標準的方法。

        應用框架的概念也很簡單。它并不是包含構件應用程序的小片程序，而是實現了某應用領域通用完備功能（除去特殊應用的部分）的底層服務。使用這種框架的編程人員可以在一個通用功能已經實現的基礎上開始具體的系統開發�？蚣芴峁┝怂�有應用期望的默認行為的類集合。具體的應用通過重寫子類(該子類屬于框架的默認行為)或組裝對象來支持應用專用的行為。

        應用框架強調的是軟件的設計重用性和系統的可擴充性,以縮短大型應用軟件系統的開發周期，提高開發質量。與傳統的基于類庫的面向對象重用技術比較，應用框架更注重于面向專業領域的軟件重用。應用框架具有領域相關性，構件根據框架進行復合而生成可運行的系統�？蚣艿牧６仍酱�，其中包含的領域知識就更加完整。

        框架，即framework。其實就是某種應用的半成品，就是一組組件，供你選用完成你自己的系統。簡單說就是使用別人搭好的舞臺，你來做表演。而且，框架一般是成熟的，不斷升級的軟件。

        同樣，測試框架也是如此，每個公司力求的最終結果，就是花少量的資源來盡可能多的完成測試任務，所以測試框架的建立以及框架的重用性方面是最值得探討的地方，沙龍里面“自動化測試的框架要講究粒度”和“建立測試框架需要一定的開發能力”這2句話說的非常有道理，你不能苛求測試人員完成所有測試應用框架的建立，這是不現實的，時間、資源都不允許。所以被測系統的主營業務，核心應用理當成為框架的首選。

        自動化測試框架比較多，基本上都是以junit為基礎，以TestCase和TestSuit為主要運用，對所要測試的類和主要方法，加test方法，然后作assert判斷，如果與結果不符合，就拋出異常�？梢砸淮螆绦卸鄠�testcase.這樣就簡化了人工的干預，可以稱之為自動化測試。

         由此也衍生了不少更強大的測試框架，比如可以得出執行時間指標，內存指標，以及web測試和多線程測試，使之擴展測試的深度和廣度。這其中，人工干預的環節基本上在前期，也就是寫testcase的環節上，比如要構造最初輸入參數，編寫測試邏輯流程，如果方法之間本身耦合度較高，就需要比較復雜的測試邏輯流程，這也就是說，增加了前期的工作量，但也極大降低了后期的時間和工作量，總體而言還是極大提高了測試的效率。

 　　但如果測試的前期能夠降下來的話，這不是更好嗎？這也是我當時的一個最初想法。

　　舉個具體的例子闡述一下想法：

　　比如

　　@ValidateIntValue(min=25,max=35)

　　private String age;

　　從上面這個age變量，我們可以得出age的最小值25，最大值35，這是它的規則，就是說，如果在程序測試中，如果出現age不符合這個范圍，就必須拋出異常，提示出錯，這個也是一個朋友上面說的校驗。但另一方面，這也給我們提供了一個testcase輸入參數的思路，這就是如果我們遇到以age為輸入參數的話，我們可以自動生成3個參數來執行三個case，2個邊緣case，25，35，還有一個在這個隨機值范圍里面。當然我們可以修改為：

　　@ValidateIntValue(min=25,max=35，default=28)

　　private String age;

　　這取決于我們的偏好。

　　由于這些meta信息不只可以作用于方法里面，也可以作用在類里面，我們也可以針對類作一些描述，這樣我們就可以對類本身也可以作一些特定的描述。

　　一般來說，對復雜的類變量，populate方法必須提供能夠實現遞歸，即填充父類的信息以及自身內部的變量信息，一直深入到最小的不可分解的原型變量，因為我們一般面對的都是一些比較復雜的類。

　　這樣我們就簡化了前期的一部分工作量。但是測試的業務流程并沒有簡化，尤其是一些復雜的業務流程。

　　我的思路是另外一種思路，就是做一個圖形界面工具，通過對類方法的拖拉，基于流程圖的形式，自動生成相對應的代碼。我感覺是可行的，因為一般來說，測試的邏輯并不是怎么復雜。不過因為我沒有實踐過，所以不知道可行性，也不知道網上是否已經有這類框架。

　　這半年來基本上沒有寫過一行代碼了，不過有時間的話，還是愿意嘗試一下，和大家共享代碼，雖然我已經決定不再吃技術這碗飯了，但是它確實已經成為我生命的一部分了。

 

 

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 探討 自動化