軟體測試專案啟動、規劃與需求分析

   更多軟體測試技術文章請訪問 http://www.itmarks.cn/    

     測試專案的啟動、規劃以及測試專案需求分析往往是很多軟體服務型企業的薄弱環節所在。本文圍繞該痛點問題，重點討論了這兩個階段所應進行的項目活動以及相關工作流程。
　
　　一、測試專案啟動與規劃
　
　　一般地，項目啟動過程組包括兩個過程[參見PMBOK2004版]：即制定項目章程和制定項目初步範圍說明書；而專案規劃過程組則會綜合項目的成本、範圍、時間、品質、風險、人力、溝通、採購等因素制定專案計劃，該專案計劃將用於指導項目的實際執行。
　
　　對任一項目而言，有三個檔案是非常重要的。即：項目章程、專案範圍說明書，專案管理計劃。這三個檔案均產生於項目啟動階段和專案規劃階段。其中項目章程被認為是三大檔案之首（項目章程、專案範圍說明書，專案管理計劃）。一個項目，不論大小，都應該有項目章程。一個典型的項目章程包括如下內容：1）項目名稱及背景描述；2）專案經理任命及職責範圍界定；3）項目業務需求描述；4）項目發起的原因；5）主要項目干係人及其初步需求；6）產品及預期交付成果描述；7）專案假設和約束條件。項目章程由項目發起人（Sponsor）簽發，自簽發之日起，專案經理即獲得法定權力。專案經理在獲得法定權力之後的第一動作是制定項目初步範圍說明書。為了制定這份文檔，他/她將廣泛地收集來自項目發起人的需求，以便在專案計劃正式編製之前，與項目發起人在專案範圍的理解上達成一致。項目初步範圍說明書還將在後續專案範圍規划過程中進一步細化，並融入項目客戶、執行組織、項目干係人等各方面需求，進而形成完整的專案範圍說明書。項目初步範圍說明書編製完成以後，專案經理將進入專案計劃編製階段。這個階段將會涉及專案管理方方面面的規劃、計劃。比較典型的有專案範圍基準、項目成本基準、項目進度計劃、項目品質計劃、項目風險分析及應對計劃、人力資源計劃、項目溝通計劃以及項目採購計劃。這些計劃、規劃經過權衡、調整，最終將整合為一個完整的專案管理計劃。專案管理計劃經由項目發起人、進階管理層審批以後，即可生效。此後，專案經理將召開項目開工會議（Kickoff meeting），宣布項目正式開始進入執行階段。
　
　　項目啟動階段的項目章程和項目初步範圍說明書（或SOW），也可以體現在分包或採購合約中。這在軟體外包服務型企業中最為常見。通常，伴隨合約到達專案經理手中的還有專案提案書（Project Proposal），專案提案書由項目發起人制定，內容和項目章程中有關產品、可交付成果的描述大致類似，此外，還應包括對專案經理成功完成此項目的一些指導性建議。專案經理根據合約、SOW以及Project Proposal進行綜合考慮，與相關干係人磋商，在項目團隊相關專家的協助下，制定出合適的專案管理計劃。
　
　　上面討論的是一般項目啟動過程組與規划過程組。具體到測試專案的啟動與規劃，工作內容也是類似的。讀者朋友請根據所在測試專案的特點做適當調整。需要交待清楚的是測試專案啟動與規划過程組有可能與其他六個過程組有重疊。比如，規划過程組有可能在整個項目生命期內都有更新和完善（典型的有滾動波浪式規劃）。
　
　　對於整周期軟體開發項目的測試而言，上述過程組的內容會有較大的差異。比如：項目章程將重點關注開發，而不會過多討論測試相關的工作。對於這一類型的軟體測試，筆者建議在任命開發專案經理的同時，由專案經理[適用於項目型或強矩陣組織]或高層經理[適用於弱矩陣或職能型組織]指定項目測試經理。測試經理應根據項目章程、項目初步範圍說明書和專案提案書儘早開始軟體測試相關規劃和設計（即會先粗略地進行軟體測試需求分析和軟體測試設計，以後再進一步細化），並和專案經理溝通、協調，以將一些重要的資訊及時反映給專案經理，從而使專案計劃能較好地支援測試工作的開展。
　
　　二、軟體測試需求分析
　
　　理論上，軟體測試需求是源於軟體需求的，而軟體需求又是源於使用者需求的。然而，有些時候在分析軟體測試需求時並不存在已經文檔化的軟體需求規格說明。在這種情況下，要分析軟體測試需求可能仍然需要追溯到使用者需求（當發生這種情況時，普通測試工程師會很吃驚地發現自己原來還肩負著需求開發工程師的部分職責。是的，事實上，資深的軟體測試工程師會發現軟體測試這個職位幾乎涉及所有的開發技能和部分管理技能。）由於後者涉及需求工程的專門知識，本文略過不做細述；這裡重點討論前者。在一個正常化的軟體需求規格說明中，使用者需求是由更高層次的業務需求（體現在項目章程、SOW、專案提案書等文檔中）細化而成，它通常描述了使用者使用該軟體系統會涉及到的不同的執行路徑、工作邏輯以及所預期的處理結果。在UML表示方法中，使用者需求通常通過Use Case來進行刻畫。接下來，使用者需求將進一步轉化為三類需求項，即功能需求項、效能需求項以及約束性需求項。這三類需求項就是通常意義上的軟體需求項。管理這三類需求項的矩陣被稱為需求矩陣。
　
　　理論上，在測試資源許可並且確有必要的前提下，測試的使命將是驗證和確認待開發的軟體及其中間產品滿足需求矩陣各個需求項。（注意：為了簡化討論，這裡筆者沒有把需求的驗證與確認納入進來，實際上這部分工作也是軟體測試工作的重要組成部分。詳細論述請參閱拙文《試論軟體測試學科架構建設》）然而，幾乎沒有幾個公司或Team Dev能夠提供這類測試所需的諸多的資源，此時，一種可行的策略是將待測試的軟體需求項按照優先關係進行排序，以協助測試經理決策在既定資源的情況下，應該如何統籌安排測試工作。
　
　　軟體需求項是測試需求分析的起點，這一點在工程實踐中並不絕對。對於不同階段的測試（這裡主要指單元測試、整合測試、系統測試和驗收測試，暫不考慮驗證技術和需求設計確認），測試需求開發所涉及的工作內容和方法都會略有差異。例如，如果是一個驗收測試，那麼，除了個別的需求需要做進一步明確外，幾乎可以將測試需求等同於使用者需求和業務需求（由於該類測試是以客戶為主體，因此並不需要向下追溯到軟體需求）；又如，如果是系統測試，除了需要對不具備可測試性的軟體需求項進一步開發外，幾乎可以對軟體需求和測試需求不做區分。再如，如果是整合測試，測試需求應該從概要設計規格說明中匯出。如果尚不存在概要設計規格說明，就需要從軟體需求規格說明出發，與軟體設計人員協同工作，具體定出構成系統的各個模組、子系統、分系統的功能、效能、約束性條件以及相互介面關係。根據協同工作的結果，開發出對應的測試需求。最後，如果是單元測試，測試需求應該從詳細設計規格說明中匯出。如果項目不存在概要設計規格說明，就需要從概要設計規格說明出發，與軟體設計人員明確每個模組內部的對象屬性與方法以及對象與對象間的通訊關係。根據此結果，進一步開發相應的測試需求。相應地，上一節所說的對軟體需求項進行優先關係排序在實踐中要變通地理解為對測試需求項進行優先關係排序。
　
　　讀者朋友可能會問，對於整周期的開發項目，以上論述是否意味著測試需求開發的依據文檔是否要根據測試所處的階段而不斷調整呢？是的，筆者認為這也是完全必要的。我們不能指望軟體需求項能夠描述清楚整合或單元測試階段的測試需求。測試需求的開發總是有賴於相應層次的軟體規格說明書（只有在Team Dev不能提供的情況下才確有必要循著“詳細設計規格說明->概要設計規格說明->軟體需求規格說明->使用者需求規格說明->項目章程、合約、專案提案書、工作說明書等”的順序往前追溯）。通常相關依據文檔的可測試性越好，測試需求開發所需要的工作量越少。
　
　　除了對軟體需求項、測試需求項做優先關係排序、對不具備可測試性或不確定的需求進一步細化、明確化之外，測試需求開發階段的工作還包括分析各測試需求項之間可能的時間關係排序。哪些測試需求項應該先測，哪些可以延後，那些是可以並行等等，都需要在測試需求開發階段一併分析清楚。

   更多軟體測試技術文章請訪問 http://www.itmarks.cn/