關于自動化測試框架的探討

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

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

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

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

   @ValidateIntValue(min=25,max=35)
    private String age;

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

   @ValidateIntValue(min=25,max=35，default=28)
    private String age;

這取決于我們的偏好。

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

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

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

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

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

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