定義
前置測試模型是由Robin Fgoldsmith等人提出的，是一個將測試和開發緊密結合的模型，該模型提供了輕鬆的方式，可以使你的項目加快速度。
前置測試模型可參考下面的圖示：
前置測試模型特點
（一）開發和測試相結合
前置測試模型將開發和測試的生命周期整合在一起，標識了項目生命周期從開始到結束之間的關鍵行為。並且表示了這些行為在項目周期中的價值所在。如果其中有些行為沒有得到很好的執行，那么項目成功的可能性就會因此而有所降低。如果有業務需求，則系統開發過程將更有效率。在沒有業務需求的情況下進行開發和測試是不可能的。而且，業務需求最好在設計和開發之前就被正確定義。
（二）對每一個交付內容進行測試
每一個交付的開發結果都必須通過一定的方式進行測試。源程式代碼並不是唯一需要測試的內容。在圖中的綠色框表示了其它一些要測試的對象，包括可行性報告、業務需求說明，以及系統設計文檔等。這同V模型中開發和測試的對應關係是相一致的，並且在其基礎上有所擴展，變得更為明確。
前置測試模型包括2項測試計畫技術:
其中的第一項技術是開發基於需求的測試用例。這並不僅僅是為以後提交上來的程式的測試做好初始化準備，也是為了驗證需求是否是可測試的。這些測試可以交由用戶來進行驗收測試，或者由開發部門做某些技術測試。很多測試團體都認為，需求的可測試性即使不是需求首要的屬性，也應是其最基本的屬性之一。因此，在必要的時候可以為每一個需求編寫測試用例。不過，基於需求的測試最多也只是和需求本身一樣重要。一項需求可能本身是錯誤的，但它仍是可測試的。而且，你無法為一些被忽略的需求來編寫測試用例。
第二項技術是定義驗收標準。在接受交付的系統之前，用戶需要用驗收標準來進行驗證。驗收標準不僅僅是定義需求，還應在前置測試之前進行定義，這將幫助揭示某些需求是否正確，以及某些需求是否被忽略了。
同樣的，系統設計在投入編碼實現之前也必須經過測試，以確保其正確性和完整性。很多組織趨向於對設計進行測試，而不是對需求進行測試。Goldsmith 曾提供過15項以上的測試方法來對設計進行測試，這些組織也只使用了其中很小的一部分。在對設計進行的測試中有一項非常有用的技術，即制訂計畫以確定應如何針對提交的系統進行測試，這在處於設計階段並即將進入編碼階段時十分有用。
（三）在設計階段進行計畫和測試設計
設計階段是做測試計畫和測試設計的最好時機。很多組織要么根本不做測試計畫和測試設計，要么在即將開始執行測試之間才飛快地完成測試計畫和設計。在這種情況下，測試只是驗證了程式的正確性，而不是驗證整個系統本該實現的東西。
測試有2種主要的類型，這2種類型都需要測試計畫。在V模型中，驗收測試最早被定義好，並在最後執行，以驗證所交付的系統是否真正符合用戶業務的需求。與V模型不同的是，前置測試模型認識到驗收測試中所包含的3種成份，其中的2種都與業務需求定義相聯繫：即定義基於需求的測試，以及定義驗收標準。但是，第三種則需要等到系統設計完成，因為驗收測試計畫是由針對按設計實現的系統來進行的一些明確操作定義所組成，這些定義包括：如何判斷驗收標準已經達到，以及基於需求的測試已算成功完成。
技術測試主要是針對開發代碼的測試，例如V模型中所定義的動態的單元測試，集成測試和系統測試。另外，前置測試還提示我們應增加靜態審查，以及獨立的QA測試。QA測試通常跟隨在系統測試之後，從技術部門的意見和用戶的預期方面出發，進行最後的檢查.同樣的還有特別測試。我們取名特別測試，並把該名稱作為很多測試的一個統稱，這些測試包括負載測試、安全性測試、可用性測試等等，這些測試不是由業務邏輯和套用來驅動的。
對技術測試最基本的要求是驗證代碼的編寫和設計的要求是否相一致。一致的意思是系統確實提供了要求提供的，並且系統並沒有提供不要求提供的。技術測試在設計階段進行計畫和設計，並在開發階段由技術部門來執行。
（四）測試和開發結合在一起
前置測試將測試執行和開發結合在一起，並在開發階段以編碼-測試-編碼-測試的方式來體現。也就是說，程式片段一旦編寫完成，就會立即進行測試。普通情況下，先進行的測試是單元測試，因為開發人員認為通過測試來發現錯誤是最經濟的方式。但也可參考X模型，即一個程式片段也需要相關的集成測試，甚至有時還需要一些特殊測試。對於一個特定的程式片段，其測試的順序可以按照V模型的規定，但其中還會交織一些程式片段的開發，而不是按階段完全地隔離。
在技術測試計畫中必須定義好這樣的結合。測試的主體方法和結構應在設計階段定義完成，並在開發階段進行補充和升版。這尤其會對基於代碼的測試產生影響，這種測試主要包括針對單元的測試和集成測試。不管在哪種情況下，如果在執行測試之前做一點計畫和設計，都會提高測試效率，改善測試結果，而且對測試重用也更加有利。
（五）讓驗收測試和技術測試保持相互獨立
驗收測試應該獨立於技術測試，這樣可以提供雙重的保險，以保證設計及程式編碼能夠符合最終用戶的需求。驗收測試既可以在實施階段的第一步來執行，也可以在開發階段的最後一步執行。
前置測試模型提倡驗收測試和技術測試沿循2條不同的路線來進行，每條路線分別地驗證系統是否能夠如預期的構想進行正常工作。這樣，當單獨設計好的驗收測試完成了系統的驗證, 我們即可確信這是一個正確的系統。
（六）反覆交替的開發和測試
在項目中從很多方面可以看到變更的發生，例如需要重新訪問前一階段的內容，或者地跟蹤並糾正以前提交的內容，修復錯誤，排除多餘的成分，以及增加新發現的功能，等等。開發和測試需要一起反覆交替地執行。模型並沒有明確指出參與的系統部分的大小。這一點和V模型中所提供的內容相似。不同的是，前置測試模型對反覆和交替進行了非常明確的描述。
（七）發現內在的價值
前置測試能給需要使用測試技術的開發人員、測試人員、項目經理和用戶等帶來很多不同於傳統方法的內在的價值。與以前的方法中很少劃分優先權所不同的是，前置測試用較低的成本來及早發現錯誤，並且充分強調了測試對確保系統的高質量的重要意義。前置測試代表了整個對測試的新的不同的觀念。在整個開發過程中，反覆使用了各種測試技術以使開發人員、經理和用戶節省其時間，簡化其工作。
通常情況下，開發人員會將測試工作視為阻礙其按期完成開發進度的額外的負擔。然而，當我們提前定義好該如何對程式進行測試以後，我們會發現開發人員將節省至少20%的時間。雖然開發人員很少意識到他們的時間是如何分配的，也許他們只是感覺到有一大塊時間從重新修改中節省下來可用來進行其它的開發。保守地說，在編碼之前對設計進行測試可以節省總共將近一半的時間，這可以從以下方面體現出來：
針對設計的測試編寫是檢驗設計的一個非常好的方法，由此可以及時避免因為設計不正確而造成的重複開發及代碼修改。通常情況下，這樣的測試可以使設計中的邏輯缺陷凸顯出來。另一方面，編寫測試用例還能揭示設計中比較模糊的地方。總的來說，如果你不能勾畫出如何對程式進行測試，那么程式設計師很可能也很難確定他們所開發的程式怎樣才算是正確的。
測試工作先於程式開發而進行，這樣可以明顯地看到程式應該如何工作，否則，如果要等到程式開發完成後才開始測試，那么測試只是查驗開發人員的代碼是如何運行的。而提前的測試可以幫助開發人員立刻得到正確的錯誤定位。
在測試先於編碼的情況下，開發人員可以在一完成編碼時就立刻進行測試。而且，她會更有效率，在同一時間內能夠執行更多的現成的測試，她的思路也不會因為去蒐集測試數據而被打斷。
即使是最好的程式設計師，從他們各自的觀念出發，也常常會對一些看似非常明確的設計說明產生不同的理解。如果他們能參考到測試的輸入數據及輸出結果要求，就可以幫助他們及時糾正理解上的誤區，使其在一開始就編寫出正確的代碼。
前置測試定義了如何在編碼之前對程式進行測試設計，開發人員一旦體會到其中的價值，就會對其表現出特別的欣賞。前置方法不僅能節省時間，而且可以減少那些令他們十分厭惡的重複工作。
