軟件開發項目的成敗，很大程度上取決于三方面的配合：過程、人、技術，三方面相互制約，又相互促進。為了能更加有效的管理軟件開發項目，規劃軟件開發過程，近年來國內引入了不少軟件開發模型，如：CMM/CMMI，RU 。
軟件開發項目的成敗，很大程度上取決于三方面的配合：過程、人、技術，三方面相互制約，又相互促進。為了能更加有效的管理軟件開發項目，規劃軟件開發過程，近年來國內引入了不少軟件開發模型，如：CMM/CMMI，RUP，XP等，每一種都體現了一種思想，都希望能在最大限度內，協調上述三者之間的關系，最大程度的減少軟件開發過程中的風險，能按照既定的計劃，交付出合格的軟件產品。
對于軟件測試工作，國內大多數企業采用V模型作為測試的標準模型，來規劃和情設計軟件測試流程，指導日常的測試工作，模型如下圖所示：
V模型帶給我們一個理想的開發方式，幫助我們理解軟件開發活動中各個階段之間的相互關系。
V模型的左側是以瀑布模型為基礎的開發活動，自上向下開展。V模型的右側是測試活動，以左側完成的活動為工作輸入，自下向上開展，最終通過驗收測試，交付給用戶合格的軟件產品。
通過這個模型，我們發現按照理想情況，如果需求獲取人員完成了需求分析工作，測試人員就可以按照需求分析的結果規劃我們的系統測試工作，設計系統測試用例，等待到系統測試階段執行測試用例，驗證系統是否實現了設計的所有功能和性能要求。
當概要設計人員完成了概要設計工作，測試人員或者開發人員(不同的公司可能會要求不同的角色完成這一工作)就可以規劃集成測試工作，設計集成測試用例，等待集成測試階段執行測試用例，驗證系統是否可以組裝成功，是否可以交付到下一個階段進行系統測試。
當詳細設計人員完成了詳細設計工作，開發人員就可以規劃單元測試工作，編寫單元測試用例，等待編碼完成后進行單元測試工作，驗證單個模塊或者類等(各個公司規劃的單元測試顆粒度不盡相同)內部的邏輯是否有問題，整個系統是否可以進入到集成測試階段。
通過分析我們發現，按照V模型來設計測試工作，測試人員可以在前期(需求獲取階段)就介入到整個開發過程中，設計測試用例規劃測試工作。這樣，有許多工作就可以并行開展，而且很多問題可以在開發的前期被發現，極大的規避了開發工作的風險，降低了改正缺陷的成本。
但是我們目前的實際情況是什么那?我們的需求總在變更，概要設計做的不夠好，而且變化頻繁，詳細設計不夠詳細或者根本不做，單元測試覆蓋率不夠或者根本不做，這樣造成測試工作步履維艱，質量難以控制。我們上面談到的幾種軟件過程改進模型，也是想在方法的高度上，盡量的改變這種現狀。
不管我們打算采用何種模型作為我們過程改進的基礎，對于軟件測試工作來講V模型都是我們很好的一盞路燈，它提供給我們一個軟件測試工作提前介入的思路，以測試或者說以質量保證為前提的軟件開發方法，只有這樣做，我們才有可能生產出高質量的軟件產品。
本文并不打算一一探討上述幾種過程改進模型的測試監控方法，而是參考V模型的架構，從軟件項目管理的角度談一談，如何對軟件測試工作進行監控，具體的監控手段都有那些，在平時的工作過程中我們應該怎樣使用。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
