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