專案的開發風險來自於對需求的誤解，來自於設計與開發過程及產品的缺陷，只有儘早發現這些缺陷，才能降低並控制專案風險。基於這種思想，軟體業出現了一些新的測試思路，主要有二：

　　1、測試驅動開發（Test-Driven Development，簡稱TDD）。這種測試思想被最近流行的XP（Extreme Programming）極限程式設計方式所大力提倡。它的基本思想是，通過測試來為程式設計做指導，在某個要開發的需求物件明確之後，在編碼之前，先進行相關測試程式碼（測試程式碼的內容和需求規格說明書描述是相同的，有人把它稱為“可執行的需求規格說明書”）的編寫工作，完成之後針對測試程式碼進行程式設計，然後再用測試程式對開發程式碼進行測試，驗證其正確性，若程式通過了測試，就說明它是符合需求規格說明書要求的。周而復始，通過這樣的過程，開發程序得以層層深入，直到開發完成。而這時單元測試也基本完成了。

　　這種測試方式的最大的好處是，儘早地發現設計、開發中存在的問題，避免傳統開發模式中的“測試過程中發現程式碼不能滿足需求而導致的大量返工”。降低專案風險；同時可以儘早地將“半成品”展示給客戶，使客戶對需求進行驗證、補充及完善，另外測試程式碼的表達方式相對準確、無二義性，可以降低因需求理解錯誤而導致的專案風險。

　　2、迭代測試。這種測試是IBM所推崇測試方式之一，它從迭代式開發模式演變而來。在迭代開發模式中，每個迭代都包含需求、設計、編碼、整合、測試等過程。在每一次迭代完成之後，便會開始新的迭代過程。通過一次次迭代的累進，系統會增量式整合一些新的功能，直至整個系統功能的完成。其中，每個迭代週期的測試工作由兩方面內容構成：
• 對當前迭代週期產品的增量測試。
• 對前迭代週期已完成功能的迴歸測試。

　　隨著迭代週期的累進，測試工作內容隨之不斷變化。早期迭代測試重點在於新功能的測試，後期迭代測試重點在於累積功能的迴歸測試。

　　有的人不喜歡XP程式設計的開發方式，認為其沒有明確的階段性劃分，不利於計劃管理，模式過於靈活，不好掌握。迭代式開發模式為這些人提供了新的選擇。這種開發方式繼承了瀑布式開發模式的優點――全面、嚴謹、有計劃性、易管理，更重要的是，這種模式將測試工作分佈到每個迭代週期中，使測試工作提前進行，從而使將發現軟體缺陷的週期提前，大大降低軟體風險及開發成本。

　　它將軟體開發比喻成製作一桌盛宴，專案經理比作大廚，測試人員比作品嚐師，使用者則比作就餐者。為保障飯菜質量，上菜之前，先由品嚐師對滿桌的半成品、準成品逐個品嚐，發現不足的地方要及時通知大廚進行改進，完善質量，直至品嚐師覺得：全部的飯菜已經色、香、味俱佳，滿足使用者要求了，才通過審查，允許飯菜上桌，供就餐者品嚐。我想說的是：飯菜質量靠品嚐師的監督，但主要靠的是大廚的技術，同理，軟體的質量則是靠各個專案管理過程的互相配合及專案經理的整體控制和把握，測試只是其中的一份子。所以，請不要將軟體的質量都交給測試過程來承擔，那樣將是“生命不能承受之重”。