任何活動都是計劃先行，制定了周密計劃，活動效果就有了一定的保證。如果沒有計劃，結果往往難以預料。軟件測試也不例外，通常都會有詳細的項目計劃。
軟件測試作為整個項目中的重要一環，也要執行詳細的測試計劃。正所謂運籌帷幄之中，決勝千里之外，強調的就是預先計劃的重要性和必要性。

如果沒有測試計劃，會帶來哪些問題呢？

1、很難確切地知道具體的測試范圍，以及應該采取的具體測試策略；

2、很難預估具體的工作量和所需要的測試工程師數量，同時還會造成各個測試工程師的分工不明確，引發某些測試工作被重復執行而有些測試則被遺漏的問題；

3、測試的整體進度完全不可控，甚至很難確切知道目前測試的完成情況，對于測試完成時間就更難預估準確的時間節點了；

4、整個項目對潛在風險的抵抗能力很弱，很難應對需求的變更以及其他突發事件。

概述

制定測試計劃，是為了確定測試目標、測試范圍和任務，所需的各種資源和投入，遇見可能出現的問題和風險，采取正確的測試策略以指導測試的執行，最終按時按量地完成測試任務，達到測試目標。

在制定計劃前，測試負責人需要掌握項目的足夠信息，比如需要仔細閱讀有關資料，包括用戶需求規格說明書、設計文檔等，全面熟悉系統。

測試計劃：描述了要進行的測試活動的范圍、方法、資源和進度的文檔；確定測試項、被測特性、測試任務、誰執行任務、各種可能的風險。

以我司的模板為例，其主要內容如下圖：

測試計劃目錄.png

1、引言

包括文檔的目的、適用范圍、項目背景以及參考資料。

1.1.文檔目的
XXXX.....，本文檔將對現有某某業務進行優化的項目測試任務轉化為具體的測試計劃和說明，是項目在各種測試階段任務、人員分配和時間安排的工作規范。

1.2.適用范圍
本文檔介紹了XXX管理優化的測試計劃，文檔供XXX模塊相關的需求人員、開發人員和測試人員使用。

1.3.項目背景
由于業務發展，現有系統功能已經不能有效滿足用戶需求，需要做一個全新的XXX管理模塊，針對新模塊的需求說明以及老模塊需要沿用的邏輯進行測試。

1.4.參考資料
XXX項目需求規格說明書.docx
http://XX.XX.XX.XX（備注：Demo地址）
XXX開發時間及人員安排

2、測試目標及范圍

本次測試內容為新需求文檔的說明和XXX管理模塊中需要沿用的邏輯以及老數據的兼容，描述被測對象以及主要的測試內容
（需要明確“測什么”和“不測什么”）

比如，用戶登錄模塊，功能測試既需要測試瀏覽器端又需要測試移動端，同時還考慮登錄的安全和并發性能相關的非功能性需求的測試等。

測試范圍的確定通常是在測試需求分析完成后進行，所以確定測試范圍的過程在一定程度上也是對測試需求分析的進一步檢驗，這將有助于在早期階段就發現潛在的測試遺漏。

3、測試策略

明確“測試的重點”，以及“各項測試的先后順序”（先測什么后測什么）和“如何來測”（采用什么樣的測試類型和測試方法）

重要的項先測，而不重要的項要后測。

依舊以“登錄”模塊為例
“用戶無法正常登錄”和“用戶無法重置密碼”這兩個潛在問題，對業務的影響孰輕孰重一目了然，所以，應該按照優先級來先測“用戶正常登錄”，再測“用戶重置密碼”。

補充說明：測試策略設計能力是指，對于各種不同的被測軟件，能夠快速準確地理解需求，并在有限的時間和資源下，明確測試重點以及最適合的測試方法的能力，一定是需要在大量實踐的基礎上潛移默化形成的，是功能測試工程師最核心的競爭力，也是最難培養的。

3.1.功能測試策略
根據測試需求分析的思維導圖，采用等價類、邊界值、錯誤推測法等方式來設計測試用例，以及如何準備相關的測試數據

3.2. 兼容性測試策略
XXX項目兼容性測試需要做以下方面：

1. Firefox下進行完整測試；
2. IE和Chrome下主要進行XXX 幾種流程、報表查看和導出等測試

測試機操作系統：WIN8，WIN10

補充：對于兼容性測試來說，Web 測試需要確定覆蓋的瀏覽器類型和版本，移動設備測試需要確定覆蓋的設備類型和具體 iOS/Android 的版本等。

至于如何確定，可以找產品定，如果產品也定不了的，那么也可以參考市場上的主流使用情況

兼容性測試的實施，往往是在功能測試的后期，也就是說需要等功能基本都穩定了，才會開始兼容性測試。

當然也有特例，比如，對于前端引入了新的前端框架或者組件庫，往往就會先在前期做兼容性評估，以確保不會引入后期無法解決的兼容性問題。

兼容性測試用例的選取，往往來自于已經實現的自動化測試用例。道理很簡單，因為兼容性測試往往要覆蓋最常用的業務場景，而這些最常用的業務場景通常也是首批實現自動化測試的目標。

補充：如需性能測試就可以補上
對于性能測試，需要在明確了性能需求（并發用戶數、響應時間、事務吞吐量等）的前提下，結合被測系統的特點，設計性能測試場景并確定性能測試框架。

比如，是直接在 API 級別發起壓力測試，還是必須模擬終端用戶行為進行基于協議的壓力測試。再比如，是基于模塊進行壓力測試，還是發起全鏈路壓測。

如果性能是背景數據敏感的場景，還需要確定背景數據量級與分布，并決定產生背景數據的技術方案，比如是通過 API 并發調用來產生測試數據，還是直接在數據庫上做批量 insert 和 update 操作，或者是兩種方式的結合。

最后，無論采用哪種方式，都需要明確待開發的單用戶腳本的數量，以便后續能夠順利組裝壓測測試場景。

性能測試的實施，往往先要根據業務場景來決定需要開發哪些單用戶腳本，腳本的開發會涉及到很多性能測試腳本特有的概念，比如思考時間、集合點、動態關聯等等。

腳本開發完成后，你還要以腳本為單位組織測試場景（Scenario），場景定義簡單來說就是百分之多少的用戶在做登錄、百分之多少的用戶在做查詢、每個用戶的操作步驟之間需要等待多少時間、并發用戶的增速是 5 秒一個，還是 5 秒 2 個等等。

最后，才是具體的測試場景執行。和自動化功能測試不同，性能測試執行完成后性能測試報告的解讀，是整個測試過程中最關鍵的點。

另外也還有很多別的測試類型，比如接口測試、集成測試、安全測試、容量驗證、安裝測試、故障恢復測試等）

4、測試資源

各個測試階段的資源分配，軟、硬件資源和人力資源的組織和建設，包括測試人員的角色、責任和測試任務。（需要明確“誰來測”和“在哪里測”）

測試人員是最重要的，直接關系到整個測試項目的成敗和效率。測試人員的資源通常有兩個維度：一是，測試工程師的數量；二是，測試工程師的個人經驗和能力。

4.1.服務器環境
不同的項目，可能會使用共享的測試環境，也可能使用專用的測試環境，甚至還會直接使用生產環境。
另外，對于目前一些已經實現容器化部署與發布的項目，測試環境就會變得更簡單與輕量級

測試服務器 ： IP地址
集成服務器 ： IP地址
線上服務器 ： IP地址

4.2.網絡環境
公司辦公網絡環境

4.3.測試工具
Bug管理工具： TFS （注：微軟源代碼管理工具）

5、進度安排

合理的階段劃分，并定義每個測試階段進入要求和完成的標準。確定各個測試階段的結束日期和最后測試報告提交日期，制定詳細的時間表。
（需要明確各類測試的開始時間，所需工作量和預計完成時間）

5.1.測試進度及人員安排

5.2.具體模塊測試用例人員安排
功能點 開始時間 結束時間 測試人員 備注

5.3.輸出文檔

• 軟件測試計劃
• 測試用例
• 中間可發布階段性報告 （項目周期比較長）
• 發布前測試報告

6、發布標準

6.1.測試結束標準
1）測試用例100%執行
2）沒有 critical 級別的 bug，沒有影響用戶正常使用的 bug；
3）完成包含需求內容的功能測試、系統兼容性測試；
4）未修改的bug經過需求確認可以延期修改

6.2.產品發布標準
1）已按照需求文檔完全的實現需求；
2）符合交互稿的交互設計規范、符合視覺要求，已經通過設計評審；
3）允許遺留可能會對用戶正常使用造成一定影響的 normal 級缺陷，但應在發布前告知項目組，并經風險評估一致同意發布后方可發布

7、風險及約束

潛在的測試風險分析、識別，以及風險回避、監控和管理。
（需要明確如何有效應對各種潛在的變化）

1）上述工作量預估中對需求變更進行了一定的風險覆蓋，但如果需求變更超出目前預計，則可能導致編寫測試用例和執行測試相關工作量增加、 測試進度延遲
2）開發提交測試版本比該計劃延遲的風險，發生此種情況時，執行測試的時間應該合理順延
3）提交測試版本質量較低的風險，或者開發理解可能導致比該計劃更多輪次的回歸測試
4）代碼版本管理執行不力的風險，發生版本管理混亂的情況時，將只選取 一個穩定版本進行測試，不考慮中間版本的反復測試。一輪測試完成后， 再進行下一穩定版本的回歸測試
5）需求不確定，目前還有一些需求還需跟用戶確認，需求說明書可能還有沒說明到的地方。在測試用例編寫期間花費更多精力，盡量將功能細節描述模糊的地方都提出來，并及早確認，否則會對開發和測試進度影響較大

8、測試停止及恢復

1）測試停止準則：開發提交的版本出現導致系統無法測試的BUG，或出現一個嚴重問題造成50%以上功能都不能進行測試的BUG，即冒煙測試失敗；其他項目停止的事件；
2）測試恢復準則：不存在導致系統無法測試的BUG，冒煙測試通過

問題：項目延期，測試計劃要不要修改？

如果一般性的延期，可以不修改，如果項目有大改動，有新需求什么的，可以更新，也可以再制定階段性的計劃，總而言之，測試計劃要跟項目計劃一致

最后補充下測試目標和測試策略

測試目標

為了制定正確的測試目標，需要充分理解用戶的需求，將用戶的需求轉化為測試需求
比如用戶要求一個官網在使用時能快速響應，不能出錯，轉化為測試需求，即為性能測試，接下來再確定具體的目標：多少人同時在線時，響應時間應小于幾秒等。
在確定測試目標時，往往需要對軟件產品所涉及的業務功能和業務流程進行分析，從而進一步細化測試目標，設計出對應的測試用例來驗證各項具體的測試目標是否實現。

測試目標可能會根據預算或時間限制進行調整，如功能測試的不同層次：

• 最低目標：正常的輸入+正常的處理過程，有一個正確的輸出
• 基本目標：對異常的輸入有錯誤的捕獲，并進行相應提示
• 較高目標：對隱藏需求進行測試確定哪些功能特性需要測試、哪些不需要測試，包括功能特性分解、具體測試任務的確定，如功能測試、用戶界面測試、性能測試、安全性測試等。

測試策略

根據測試需求和范圍、測試風險、測試工作量和測試資源限制等來決定測試策略，是測試計劃的關鍵內容。

一般情況下，不管采用什么方法和技術，測試都是不徹底的，不能夠保證被測試程序中不存在遺漏的缺陷。
一輪系統測試過后，如果程序中遺漏的嚴重錯誤過多，說明測試是不充分的甚至是失敗的，讓用戶承擔隱藏錯誤帶來的風險。相反，如果過度測試，又會浪費很多資源，加大測試成本。
因此，有必要找到一個平衡點，依據軟件項目類型、規模以及應用背景的不同，選擇不同的測試方案，以最少的軟、硬件以及人力獲得最佳的測試效果。

在制定策略時，需要綜合考慮影響因素，如Tester本身所具有的能力、掌握的測試方法和技術、時間約束等。

如何制定測試策略？
在制定過程中，需要考慮用戶特點、系統功能之間的關系、資源配置、上個版本的測試質量、已有的測試經驗等因素的影響，找到問題的解決辦法，包括采取哪些測試方法、采用什么樣的測試工具，需要盡可能地考慮細節。