2、迭代測試。這種測試是IBM所推崇測試方式之一，它從迭代式開發模式演變而來。在迭代開發模式中，每個迭代都包含需求、設計、編碼、集成、測試等過程。在每一次迭代完成之后，便會開始新的迭代過程。通過一次次迭代的累進，系統會增量式集成一些新的功能，直至整個系統功能的完成。其中，每個迭代周期的測試工作由兩方面內容構成：
· 對當前迭代周期產品的增量測試。
· 對前迭代周期已完成功能的回歸測試
隨著迭代周期的累進，測試工作內容隨之不斷變化。早期迭代測試重點在于新功能的測試，后期迭代測試重點在于累積功能的回歸測試。
有的人不喜歡XP編程的開發方式，認為其沒有明確的階段性劃分，不利于計劃管理，模式過于靈活，不好掌握。迭代式開發模式為這些人提供了新的選擇。這種開發方式繼承了瀑布式開發模式的優點――全面、嚴謹、有計劃性、易管理，更重要的是，這種模式將測試工作分布到每個迭代周期中，使測試工作提前進行，從而使將發現軟件缺陷的周期提前，大大降低軟件風險及開發成本。
測試過程的衡量
測試過程在不斷地改進，但效果如何，如何來衡量測試的效果呢?我們需要引入一把尺子，一個度量標準，這樣才能把握測試過程的改進方向。那么，怎樣來收集數據，如何來度量?這是我們長久以來一直困惑的地方。
我們不妨借助“他山之石”來想想辦法，CMMI是當今國際流行的軟件過程衡量模型，它在這方面是有自己的獨到之處的：
1、 面向全局。CMMI的測試度量面向的不僅僅是測試過程的改進，測試效果的加強，它面向的是整個開發過程，并始終將質量監督放在工作首位。比如，它度量工作產品規模(例如代碼行數)，度量工作量和成本(例如人工小時數)。我們從中搜集的數據對整個開發過程的改進都有指導作用。更高的起點可使我們避免項目管理改進過程中常見的“頭痛醫頭、腳痛醫腳”毛病。
2、 建立度量數據庫，從而對搜集的數據、分析的方式及結果進行完整、規范的保存。這個數據庫面向的是軟件開發過程的持續改進，它的數據是可復用的，可供多個項目參考使用，不隨當前項目的結束而消失，而是會作為歷史信息持續保存，從而為測試及其他軟件過程的改進提供更客觀、更全面的度量數據。
3、 關注度量、分析過程的改進。度量過程是為了對測試及其他軟件過程的改進提供參考依據，它自身運作方式的合理性直接會影響度量結果的準確性。CMMI避免了“燈下黑”現象的出現，它沒有忽略測量分析度量過程的改進，它會定期召集受影響的受益者一起審查初始分析結果，總結本過程運作中遇到的經驗教訓，從而對度量過程方式進行改進，保證度量結果的正確性，可參考性。
CMMI度量方式的優點往往是我們所忽略的，我們應盡力學習它的這些長處，這對軟件測試過程的改進會很有幫助。
結束語
測試很重要，它是檢驗開發結果是否接近預期目標的重要手段，但我們應清楚地認識到：它畢竟只是一種信息反饋過程，作為軟件質量的守護者，它可以發現缺陷，但無法避免缺陷的發生，我們不能將軟件質量的安危都押在測試這個砝碼上。
曾看過一個比喻，還記憶猶新，它將軟件開發比喻成制作一桌盛宴，項目經理比作大廚，測試人員比作品嘗師，用戶則比作就餐者。為保障飯菜質量，上菜之前，先由品嘗師對滿桌的半成品、準成品逐個品嘗，發現不足的地方要及時通知大廚進行改進，完善質量，直至品嘗師覺得：全部的飯菜已經色、香、味俱佳，滿足用戶要求了，才通過審查，允許飯菜上桌，供就餐者品嘗。我想說的是：飯菜質量靠品嘗師的監督，但主要靠的是大廚的技術，同理，軟件的質量則是靠各個項目管理過程的互相配合及項目經理的整體控制和把握，測試只是其中的一份子。所以，請不要將軟件的質量都交給測試過程來承擔，那樣將是“生命不能承受之重”。
文章來源于領測軟件測試網 http://www.kjueaiud.com/