軟件測試計劃是一個老生常談的問題了，不同的人對計劃的理解往往是大相徑庭的。這里讓我們回顧一下何為計劃，一般來說計劃的目的是用來識別任務，分析風險，規劃資源和確定進度。從計劃的定義上來看，計劃并不是一張時間進度表，而是一個動態的過程，終以系列文檔的形式確定下來。擬定軟件測試計劃需要測試項目管理人員的積極參與，這是因為主項目計劃已經確定了整體項目的一個時間框架，軟件測試作為階段工作必須服從時間和資源上的約定。

　　2. 一個完整的測試計劃應該包含以下幾個方面：

　　(1) 對測試范圍的界定，簡單的說是測試活動需要覆蓋的范圍。在有時間約束，工作產品質量約束的情況下，能夠調整是范圍。在實際的工作中，我們總是不自覺的在調整軟件測試的范圍，比如在時間緊張的情況下，通常優先完成重要功能的測試。這是一種測試范圍上調整。所以作為測試管理者在接收到一項任務的時候，需要根據主項目計劃的時間來確定測試范圍。如果在確定范圍上出現偏差，會給測試執行工作帶來消極的影響，例如加班。確定范圍前需要管理人員來進行任務的劃分，簡單的說是分解測試任務。分解任務有兩個方面的目的，一個是識別子任務，二是方便估算資源的需求。完成了上述的任務之后，管理者便需要根據項目的歷史數據估算出完成這些子任務一共需要消耗的時間和資源。通常意義上說，執行一次完整的全面測試幾乎是不可能的事情，我們總是要在測試的范圍上面做出有策略的妥協。

　　(2) 風險的確定，項目中總是有不確定的因素。這些因素一旦發生之后記錄對項目的順利執行產生相當大的消極影響。所以在項目中，首先需要識別出存在的風險。風險識別的原則可以有很多，常見的一種是如果一件事情發生后，會對項目的進度產生較大影響，那么可以把該事件做為一個風險。風險識別出之后，管理者需要按照這些風險制定出規避風險的方法。在小的項目中，識別風險和制定規避方法可以省略。

　　(3) 資源的規劃，確定完成任務需要消耗的人力資源，物資資源。這些是保證項目執行的物資要素。物資資源是管理者容易忽略的問題，實際上物資資源是人得以開展工作的工具，細致的規劃可以讓人更有效的去執行項目。常見的物資資源有計算機硬件，軟件，測試環境的搭建等等。

　　(4) 時間表的制定，在識別出子任務和資源之后，我們便可以將任務，資源和時間關聯起來形成時間進度表。本質上說，時間表是對前3項任務的一個概括。沒有前三步的工作，時間進度表是沒有意義的。

　　3. 溝通

　　溝通的測試管理人員的必須的技能。雖然我們制定出詳細的項目計劃，當這不意味著有了這個契約之后，項目中的各種角色不需要溝通了。做為測試的管理者，需要將測試發現的問題及時的反饋給開發人員，同時也要積極的去了解外界產生的變更。項目中存在變化是普遍現象，而作為管理者是要去管理這里變化，及時的修訂計劃。嚴格的說，如果沒有這些變化，做為測試管理者的你沒有多少存在的價值。有些人認為一旦有了計劃這個契約之后，只要按照要求去執行可以，但是項目本身是一個動態的過程，計劃是項目在某一個時刻、段的靜態體現，所以要按照發展的眼光來對待計劃。溝通是了解外界變化的積極手段，所以測試管理者而言。其計劃溝通能力的要求要高于測試技能的要求。

　　4. 執行

　　去年國內流行一本書，名稱為執行力。書中的作者認為大多數項目沒有成功的原因在于執行。軟件測試也存在一個執行的能力問題，有人會說我把要求的事情按照要求做完了不可以了嗎? 的確，按照期望去執行任務是正解，但是這里有一個問題是如何保證執行者對期望的理解同要求者的期望是完全一致的呢?所以執行的背后還是一個溝通的問題，這里的溝通是測試管理者和執行者之間的溝通。所以作為一名測試管理人員一定要在測試工程師開始工作之前明確任務的意圖，前提和結果。

　　5. 版本控制

　　前面說道的幾點都是過程，個人技能方面的要求。這里我們要討論的是純粹的工程活動??版本控制。對于版本控制這個概念大家都不陌生，它是軟件配置管理的初期表現形式，來于于測試對穩定環境的要求。測試版本控制簡單的說是測試版本有明確的標識，說明。并且測試版本的交付是在項目管理人員的控制之下的。

　　測試版本的標識用來識別所用的版本。版本號碼的用處很多，例如在填寫錯誤報告的時候往往需要提供發現錯誤的那個版本。在做缺陷分析時，我們可以利用版本號來區別缺陷和判斷缺陷的發展趨勢。

　　測試版本的說明，它是開發人員和測試人員之間交流的有效形式。測試人員可以通過這份文檔了解到當前的測試版本中上一版本而言有那些顯著的變化，明確了這些之后，測試人員可以更加高效，有針對性的執行測試。

　　測試版本交付，測試版本的控制必須納于測試管理人員的控制之下。常見的形式是測試管理者控制測試版本的更新和發布。開發人員在看到錯誤報告之后，總是傾向于馬上修正這些錯誤并且發布給測試工程師做驗證。