很多新升為測試管理崗的小伙伴們經常會有的疑問，除了自己去分配其他團隊成員任務外，幾乎其他的事情與自己以往工作并無區別。特別是團隊中沒有比自己更有經驗的測試人員時，完全不懂測試管理到底要做哪些事情。

簡言之，無論是做測試執行還是測試管理，都是一個不斷解決問題的崗位 ，只是解決問題的方式與層次不同而已。

而軟件測試管理與執行的最大區別就是，后者只需執行前者分配好的任務即可，無論是編寫測試設計還是執行用例，或是提煉測試需求點，只需要在規定的時間里完成任務并交付即可。而測試管理并不只是單純地安排其他人任務就好，需要管理人員對測試團隊服務的“客戶”以及“客戶”需要達到的服務了解地非常清楚（這里的“客戶”指服務的對象，比如我們公司測試團隊的服務對象即為產品經理，因測試交付后是需要提交給產品經理驗收的，驗收通過則進入下一環節，否則測試返工，重新執行。這樣測試團隊對于產品經理給出的驗收交付標準、交付功能點清單以及其他要求的質量特性要非常清晰。當然這里測試團隊的服務對象會與公司內部的管理有關，不同情況下存在不同的“客戶”）同時，要清楚當前的測試資源，如有些團隊包括測試人員也是非固定性質的，當成立新的項目組時，會臨時借調其他組成員，這樣需要提前了解好有多少可以投入的測試人員，以及配備的軟硬件等； 接下來就是分析產品及可能存在的風險； 根據以上情況來確定測試任務； 一般可以與技術負責人一起商議，如目前存量的資源以及按照項目計劃書描述每個節點應該完成的任務百分比等。同時需要提前準備好測試策略，但測試策略應該是動態的，根據項目進展情況隨時調整測試策略。

以上是制訂測試計劃的基本流程，也是基礎信息來源。

一般情況下如果公司有測試管理工具的話建議直接有工具更清晰，也更便于管理維護。如TAPD的自定義測試計劃模板，也可以使用在線的思維導圖或文檔。

以下以一常用的軟件測試計劃模板為例 ，介紹下如何制訂好一份測試計劃。

這里主要分為部分：

文檔簡介

測試資源與工具

測試策略

測試階段的開始/結束標準

風險與應對計劃

質量目標

測試過程管理

測試范圍定義

測試排期（進度、人員安排）

測試交付物

附錄-測試關注點

-----------------------

文檔簡介

一般包含測試計劃編寫目的、限制條件及參考文檔

編寫目的需要根據文檔閱讀人群來編寫，如果項目屬于外包性質的，需要考慮是否會合并在驗收文檔中。

測試環境

一般包含硬件環境和軟件環境，如下圖：

測試工具

所有測試過程中使用到的工具，包含用例編寫工具、執行測試工具、缺陷管理系統、需求管理系統等等。

測試策略及方法

常見的測試策略如下：

盡量做到在有限的時間里發現盡可能多的缺陷（尤其是嚴重缺陷）

測試計劃與需求閱讀同步進行

用例的設計需要高匹配產品需求，在需求的指導下設計出更多更有效的用例

逐步完善測試用例庫（測試用例需要根據執行過程中不斷修訂，動態調整）

保證測試過程受控

常用的用例設計方法：

等價類劃分法

是把所有可能的輸入數據，即程序的輸入域劃分成若干部分（子集），然后從每一個子集中選取少數具有代表性的數據作為測試用例。

邊界值分析法

邊界值分析方法是對等價類劃分方法的補充。通常輸入和輸出等價類的邊界，就是應側重測試的邊界情況。

錯誤推測法

基于經驗和直覺推測程序中所有可能存在的各種錯誤，從而有針對性的設計測試用例的方法。錯誤推測方法的基本思想：列舉出程序中所有可能有錯誤及易發生錯誤的特殊情況，根據它們來選擇Case。

判定表法

判定表是分析和表達多邏輯條件下執行不同操作的情況的工具。

判定表的優點是可以將復雜問題按照各種可能的情況全部列舉出來，避免遺漏。在一些數據處理問題當中，某些操作的實施依賴于多個邏輯條件的組合，即：針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合于處理這類問題。

場景分析法

對于業務功能測試領域，場景分析法是最普遍也是最主要的設計方法了。首先需要充分了解整體業務。結合分析應用場景，從用戶角度出發設計Case，是一種面向用戶的測試用例設計方法。

缺陷的嚴重級別定義

此處不作過多說明，通常按照行業標準定義。但業務為主的產品中，需由產品經理及用戶代表來確定缺陷的嚴重程度，主要根據對用戶使用的影響程度來計算。

開始/結束標準定義

開始標準與結束標準通常按照公司內部的測試流程來確定，如測試交付產品經理或驗收通過，或是達到已經定義好的質量標準。

中斷標準

軟件開發過程中，難免會出現一些意外導致項目中斷，這時測試也應按照提前約定好的暫停，一般存在以下情況時：

軟件項目需暫停以進行調整時，測試應隨之暫停。

軟件項目在開發生命周期內出現重大進度偏差，需暫停或終止時，測試應隨之暫停或終止。

若開發任務暫停，則相應測試也暫停。

風險與應對計劃

一般包含需求風險、時間風險、資源風險等，需要注意的是，每條風險識別都需要有對應的應對計劃措施，至少2條。

質量目標

一般包含產品質量目標與測試質量目標

測試質量目標以下可作為參考：

所有的Case已執行過至少一遍

所有嚴重級別及以上的Bug已修復且測試人員驗證通過

核心功能不允許有中級及以上的Bug

一般功能與終端用戶不直接使用的功能不允許有中級以上的Bug

缺陷趨勢呈下降并接近為0

在最后的10%時間內沒有發現中級以上Bug

測試過程管理

通常包含測試文檔的過程管理與缺陷處理的流程、匯報會議、進度日報形式等。

文檔的過程管理如管理人員、存儲、移交、分享等需要定義好形式，缺陷處理流程可以以缺陷管理系統中定義好的工作流來說明。

測試范圍定義

測試范圍可以按照項目計劃書的里程碑來提前擬定，如哪個階段需要進行底層框架的性能測試、是否需要完成接口測試、功能測試中包含哪些功能點等等。非測試范圍一般說明不在本次范圍內的功能點或測試類型，有時因項目進度原因可能臨時對某些功能點進行刪減，需要同步更新。

測試排期（進度、人員安排）

進度排期可參考以下幾個節點進行劃分，可以根據特定節點來劃分不同的階段。

人員與任務安排可以根據前期已整理好的可用固定資源與臨時資源調配來作好相應調動計劃。

測試交付物

一般一個項目結束后需要交付的測試產物有：軟件測試方案、測試用例、缺陷報告、項目測試報告、用戶操作手冊（若由測試團隊提供時）

附錄-測試關注點

附錄中依據需要可以增加多個附錄，如相關術語、縮略語的解釋、測試需特別關注點等 。

測試關注點一般由技術負責人、所屬產品經理及用戶代表提供，可以在測試方案中提前明確以提醒測試人員的注意事項。

如增刪查改功能點、數據導入、導出及特定輸入框功能的測試側重點

不能破壞數據庫數據的關聯和完整

檢查多次使用back鍵的情況，在有back的地方，back回到原頁面，再back重復多次，檢查是否出錯

修改正在使用的數據；

多次連續查詢正確性

導入數據格式要求不應太苛刻，提示明確

數據的動態監測是否正確無誤

對于日期時間型數據，檢查格式正確性以及時間日期的合理性。比如開始時間不能晚于結束時間等

重復數據處理，尤其是鍵值的重復

測試計劃制訂完成后，需要與項目中核心負責人確認，待審核通過后便可開始進行下一環節。需要注意的是，測試計劃是隸屬于項目計劃書中的一部分，也是項目計劃書的延伸，完成制訂后仍需要根據實際情況來動態調整，才能達到最理想的指導目的。#軟件測試#（更多詳情請關注“木螞蟻”公眾號查閱）