這些工具是被設計用于檢查已有代碼塊的，它將以分支、循環等為基礎，綜合生成一套針對代碼的觀測報告，開發者可以通過審查這些報告，選擇為自己關心的部分 生成整套的測試用例。對于遺留代碼，這種方式是了解已有行為的一種非常有效的方式，讓開發者可以在進行改變之前，先創建一張安全網。
然而，任何技術都是有限制的：這些工具只是針對代碼生成一套觀察報告，它們并不能理解算法或是開發者的意圖。下面是來自Bob的說明：
作為一個簡單的示例，我試著使用兩款知名的測試生成工具來為保齡球游戲程序生成測試代碼。保齡球游戲的接口看上去是這樣的：
public class BowlingGame { public void roll(int pins) {...} public int score() {...} } 設計思想是：在每次投球后調用roll方法，在游戲結束后調用score方法得到本次游戲的得分。
顯而易見，測試生成器并不能隨機生成有效的游戲。一次有效的游戲應該是一個有12到21次投球的序列，每次投球得分應該在0到10之間，還有什么？那就是 在每一格內，投球的得分總數不能超過10，對于處在目前階段的隨機生成器來說，要實現這些約束條件確實太困難了。
另一個方面，測試驅動開發（TDD）要求先寫測試、再寫產品代碼的工作方法與眾不同。TDD能起到作用，那是因為它會對開發 人員編寫的代碼進行即時的反饋。在做出任何小修改后，只要運行測試，開發者就可以知道這些改變是否正確；TDD確保了代碼與我們通過測試代碼表達的意圖是 相匹配的；TDD讓我們以一個消費者、而不僅僅是創造者的角度來思考如何設計代碼，它讓我們針對每一個條件和回路進行思考；而且，就像James Carr提到的那樣，TDD迫使我們去考慮代碼耦合的程度，看看Bob對此又是怎么說的：
使用測試生成器破壞了這個原則，因為生成器是以產品代碼作為輸入來生成測試的，而且因為它是全自動轉換的，所以其生成的測試代碼也不便于閱讀。人類的意圖 只是通過產品代碼進行了體現，而無法通過閱讀所生成的測試代碼來獲得驗證，更無法通過它來確認產品代碼是否已經實現了人類的意圖。雖然人類會去檢查自動生 成的報告，但相比TTD而言，這只是一個很被動的行為，遠不及TTD對于缺陷、設計和意圖體現上的洞察力。
……這并不是在說測試代碼生成器沒有用……我想它們有助于部分標識出大量遺留代碼的特性。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
