對于整周期軟件開發項目的測試而言，上述過程組的內容會有較大的差異。
比如：項目章程將重點關注開發，而不會過多討論測試相關的工作。對于這一類型的軟件測試，筆者建議在任命開發項目經理的同時，由項目經理[適用于項目型或強矩陣組織]或高層經理[適用于弱矩陣或職能型組織]指定項目測試經理。測試經理應根據項目章程、項目初步范圍說明書和項目建議書盡早開始軟件測試相關規劃和設計(即會先粗略地進行軟件測試需求分析和軟件測試設計，以后再進一步細化)，并和項目經理溝通、協調，以將一些重要的信息及時反映給項目經理，從而使項目計劃能較好地支持測試工作的開展。
二、軟件測試需求分析
理論上，軟件測試需求是源于軟件需求的，而軟件需求又是源于用戶需求的。然而，有些時候在分析軟件測試需求時并不存在已經文檔化的軟件需求規格說明。
在這種情況下，要分析軟件測試需求可能仍然需要追溯到用戶需求(當發生這種情況時，普通測試工程師會很吃驚地發現自己原來還肩負著需求開發工程師的部分職責。是的，事實上，資深的軟件測試工程師會發現軟件測試這個職位幾乎涉及所有的開發技能和部分管理技能。)由于后者涉及需求工程的專門知識，本文略過不做細述;這里重點討論前者。在一個規范化的軟件需求規格說明中，用戶需求是由更高層次的業務需求(體現在項目章程、SOW、項目建議書等文檔中)細化而成，它通常描述了用戶使用該軟件系統會涉及到的不同的執行路徑、工作邏輯以及所預期的處理結果。
在UML表示方法中，用戶需求通常通過Use Case來進行刻畫。接下來，用戶需求將進一步轉化為三類需求項，即功能需求項、性能需求項以及約束性需求項。這三類需求項就是通常意義上的軟件需求項。管理這三類需求項的矩陣被稱為需求矩陣。
理論上，在測試資源許可并且確有必要的前提下，測試的使命將是驗證和確認待開發的軟件及其中間產品滿足需求矩陣各個需求項。(注意：為了簡化討論，這里筆者沒有把需求的驗證與確認納入進來，實際上這部分工作也是軟件測試工作的重要組成部分。詳細論述請參閱拙文《試論軟件測試學科架構建設》)然而，幾乎沒有幾個公司或開發團隊能夠提供這類測試所需的諸多的資源，此時，一種可行的策略是將待測試的軟件需求項按照優先關系進行排序，以幫助測試經理決策在既定資源的情況下，應該如何統籌安排測試工作。
軟件需求項是測試需求分析的起點，這一點在工程實踐中并不絕對。
對于不同階段的測試(這里主要指單元測試、集成測試、系統測試和驗收測試，暫不考慮驗證技術和需求設計確認)，測試需求開發所涉及的工作內容和方法都會略有差異。例如，如果是一個驗收測試，那么，除了個別的需求需要做進一步明確外，幾乎可以將測試需求等同于用戶需求和業務需求(由于該類測試是以客戶為主體，因此并不需要向下追溯到軟件需求);
又如，如果是系統測試，除了需要對不具備可測試性的軟件需求項進一步開發外，
文章來源于領測軟件測試網 http://www.kjueaiud.com/
