如何進行測試管理？想必每位測試管理者都有這個疑惑，我也不例外。
經過了2個公司的測試管理經歷，其實總的來說不外乎測試計劃、測試用例、測試執行、測試跟蹤和測試總結。
今天說一下測試計劃。
測試計劃，首先顧名思義，應該是為測試的所有工作進行全局的計劃安排，測試計劃中包括了所有的測試工作，比如說測試背景、測試目的、測試范圍、測試策略、測試方法、測試階段、測試完成標準、測試工作量、測試資源、測試環境、測試進度等等。測試進度是上至管理者、下至項目經理都會關心的一件事情，并且是僅此一件事情，由此可見測試之外的人員的膚淺，當然，不能稱之為膚淺，因為你得理解，他們也只能關心到這一層面了。
有幾個方面稍作記錄，供大家參考。
1、測試工作量的估算
測試工作如同項目工作一樣，都需要進行估算，且不說成本的估算，那是第三方測試關心的事情，一般公司內都是作集成測試和系統測試，而任何人都知道測試不是無休止的。所以我們需要對測試進度進行估算，但是首先我們需要估算測試的工作量。通常來說，測試人員在項目開始便介入項目，開展相應的測試工作，而并不是到了項目測試階段才參與項目。
測試的工作量是根據測試范圍和測試階段、測試方式來確定的，主要因素是測試范圍，所以我們需要確定測試范圍。測試范圍又是通過項目需求或者產品需求規格說明而來，因此這就是我們提取測試范圍和測試需求的一個好方式。
通常來說，建議對測試工作進行細化，對每項工作都進行工作分解，分解的粒度可以自己定義，以可以把分解后的工作量準確的估算出為準。WBS之后，那么可以粗略的將所有工作的工作量求和，得出最終的測試工作量，當然，一般來說回歸測試的遍數可以認為是3次，那么最后制定出調整因子，可以選擇20%用以浮動的工作量。
如果項目能力成熟度比較高，需求文檔寫得比較完整和詳細，那么也可以采取另外一種方法，就是根據需求文檔進行推導測試工作量，這個方法是從網上找來的，在實際中試用過2次，呵呵，試用結果證明，某些參數需要根據以往的經驗值調整。
以系統測試為例：
?。?）由需求文檔的頁數計算出系統測試用例的頁數（推薦比例為1.5）
?。?）由系統測試用例頁數計算編寫系統測試用例時間（推薦比例為1）
?。?）由系統用例計算執行系統測試時間（推薦比例為2）
（4）用執行系統測試計算回歸測試時間（推薦比例為0.5）
2、測試進度的制定
測試工作量制定出之后，根據測試的資源對測試進度進行估計，當然，估計的最終結果要跟項目的測試進度相對比，我本人認為可以參考COCOMO方法，進行測試工期的估算，當然，也可以根據每個公司的以往經驗值進行類推估算。
3、測試進度的更新
一般情況下，測試計劃不會被嚴格的執行，通常伴隨著都是項目的延期、測試階段的壓縮，如此一來，測試進度的更新是經常發生的事情。所以需要注意的一點是，測試進度估算完畢后，排定時最好不要以具體的時間點到時間點的方式，而是采用工作量和工期天數來表示，這樣在開發階段影響了測試計劃后，不需要頻繁的調整。
另外，在測試時間被壓縮后，如果測試計劃制定的詳細，包括了各項測試需求和他們的優先級，那么此時可以利用測試需求的優先級，跟項目經理協商，調整測試范圍和測試需求，在短的時間內優先測試重要的功能點，而一些不常用的和級別低的測試需求可以轉移到用戶現場或者后期進行。
對于項目中計劃的更改或者需求、設計的更改，項目組一定要注意及時通知測試人員，其實就是項目的干系人，所有的干系人都需要及時通知到，這也是項目中配置管理的重要職責。需求或設計發生變動時，測試人員需要及時調整測試計劃和測試用例，其中尤屬測試用例的調整工作量較大，這種情況的頻繁發生要求我們制定測試用例時，需要保證測試用例的條理性和通用性，避免具體數據的及早設入。
另外，關于測試的更新管理應在測試計劃中規定好，明確更新周期和暫停測試的原則。例如，小版本的產品更新不能大于每天三次，一個相對大的版本不能每周大于1次，規定緊急發布產品僅限于何種類型的修改或變更，由誰負責統一維護和同步更新測試環境。測試暫停可以表現在產品錯誤發布或者服務器數據更新等情況，是比較有必要的一個方面，有利于測試管理者有效安排測試資源的合理運用。