任何活動都是計劃先行芯勘，制定了周密計劃，活動效果就有了一定的保證腺逛。如果沒有計劃荷愕，結(jié)果往往難以預料。軟件測試也不例外屉来，通常都會有詳細的項目計劃路翻。
軟件測試作為整個項目中的重要一環(huán)，也要執(zhí)行詳細的測試計劃茄靠。正所謂運籌帷幄之中茂契，決勝千里之外，強調(diào)的就是預先計劃的重要性和必要性慨绳。

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

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

2战秋、很難預估具體的工作量和所需要的測試工程師數(shù)量璧亚，同時還會造成各個測試工程師的分工不明確，引發(fā)某些測試工作被重復執(zhí)行而有些測試則被遺漏的問題脂信；

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

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

概述

制定測試計劃，是為了確定測試目標丽声、測試范圍和任務礁蔗，所需的各種資源和投入，遇見可能出現(xiàn)的問題和風險雁社，采取正確的測試策略以指導測試的執(zhí)行瘦麸，最終按時按量地完成測試任務，達到測試目標歧胁。

在制定計劃前滋饲，測試負責人需要掌握項目的足夠信息，比如需要仔細閱讀有關(guān)資料喊巍，包括用戶需求規(guī)格說明書屠缭、設計文檔等，全面熟悉系統(tǒng)崭参。

測試計劃：描述了要進行的測試活動的范圍呵曹、方法、資源和進度的文檔何暮；確定測試項奄喂、被測特性、測試任務海洼、誰執(zhí)行任務跨新、各種可能的風險。

以我司的模板為例坏逢，其主要內(nèi)容如下圖：

測試計劃目錄.png

1域帐、引言

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

1.1.文檔目的
XXXX.....，本文檔將對現(xiàn)有某某業(yè)務進行優(yōu)化的項目測試任務轉(zhuǎn)化為具體的測試計劃和說明浮入，是項目在各種測試階段任務龙优、人員分配和時間安排的工作規(guī)范。

1.2.適用范圍
本文檔介紹了XXX管理優(yōu)化的測試計劃事秀，文檔供XXX模塊相關(guān)的需求人員彤断、開發(fā)人員和測試人員使用。

1.3.項目背景
由于業(yè)務發(fā)展秽晚，現(xiàn)有系統(tǒng)功能已經(jīng)不能有效滿足用戶需求瓦糟，需要做一個全新的XXX管理模塊，針對新模塊的需求說明以及老模塊需要沿用的邏輯進行測試赴蝇。

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

2菩浙、測試目標及范圍

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

比如句伶，用戶登錄模塊劲蜻，功能測試既需要測試瀏覽器端又需要測試移動端，同時還考慮登錄的安全和并發(fā)性能相關(guān)的非功能性需求的測試等考余。

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

3疫蔓、測試策略

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

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

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

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

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

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

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

測試機操作系統(tǒng)：WIN8，WIN10

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

至于如何確定批糟，可以找產(chǎn)品定格了，如果產(chǎn)品也定不了的，那么也可以參考市場上的主流使用情況

兼容性測試的實施徽鼎，往往是在功能測試的后期盛末，也就是說需要等功能基本都穩(wěn)定了，才會開始兼容性測試否淤。

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

兼容性測試用例的選取啰扛，往往來自于已經(jīng)實現(xiàn)的自動化測試用例嚎京。道理很簡單嗡贺，因為兼容性測試往往要覆蓋最常用的業(yè)務場景，而這些最常用的業(yè)務場景通常也是首批實現(xiàn)自動化測試的目標挖藏。

補充：如需性能測試就可以補上
對于性能測試暑刃，需要在明確了性能需求（并發(fā)用戶數(shù)、響應時間膜眠、事務吞吐量等）的前提下，結(jié)合被測系統(tǒng)的特點溜嗜，設計性能測試場景并確定性能測試框架宵膨。

比如，是直接在 API 級別發(fā)起壓力測試炸宵，還是必須模擬終端用戶行為進行基于協(xié)議的壓力測試辟躏。再比如，是基于模塊進行壓力測試土全，還是發(fā)起全鏈路壓測捎琐。

如果性能是背景數(shù)據(jù)敏感的場景，還需要確定背景數(shù)據(jù)量級與分布裹匙，并決定產(chǎn)生背景數(shù)據(jù)的技術(shù)方案瑞凑，比如是通過 API 并發(fā)調(diào)用來產(chǎn)生測試數(shù)據(jù)，還是直接在數(shù)據(jù)庫上做批量 insert 和 update 操作概页，或者是兩種方式的結(jié)合籽御。

最后，無論采用哪種方式惰匙，都需要明確待開發(fā)的單用戶腳本的數(shù)量技掏，以便后續(xù)能夠順利組裝壓測測試場景。

性能測試的實施项鬼，往往先要根據(jù)業(yè)務場景來決定需要開發(fā)哪些單用戶腳本哑梳，腳本的開發(fā)會涉及到很多性能測試腳本特有的概念，比如思考時間绘盟、集合點鸠真、動態(tài)關(guān)聯(lián)等等。

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

最后序攘，才是具體的測試場景執(zhí)行茴她。和自動化功能測試不同，性能測試執(zhí)行完成后性能測試報告的解讀程奠，是整個測試過程中最關(guān)鍵的點丈牢。

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

4、測試資源

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

測試人員是最重要的，直接關(guān)系到整個測試項目的成敗和效率疼鸟。測試人員的資源通常有兩個維度：一是后控，測試工程師的數(shù)量；二是愚臀，測試工程師的個人經(jīng)驗和能力忆蚀。

4.1.服務器環(huán)境
不同的項目，可能會使用共享的測試環(huán)境姑裂，也可能使用專用的測試環(huán)境馋袜，甚至還會直接使用生產(chǎn)環(huán)境。
另外舶斧，對于目前一些已經(jīng)實現(xiàn)容器化部署與發(fā)布的項目欣鳖，測試環(huán)境就會變得更簡單與輕量級

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

4.2.網(wǎng)絡環(huán)境
公司辦公網(wǎng)絡環(huán)境

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

5疾嗅、進度安排

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

5.1.測試進度及人員安排

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

5.3.輸出文檔

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

6友瘤、發(fā)布標準

6.1.測試結(jié)束標準
1）測試用例100%執(zhí)行
2）沒有 critical 級別的 bug，沒有影響用戶正常使用的 bug檐束；
3）完成包含需求內(nèi)容的功能測試辫秧、系統(tǒng)兼容性測試；
4）未修改的bug經(jīng)過需求確認可以延期修改

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

7格嘁、風險及約束

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

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

8、測試停止及恢復

1）測試停止準則：開發(fā)提交的版本出現(xiàn)導致系統(tǒng)無法測試的BUG尉姨，或出現(xiàn)一個嚴重問題造成50%以上功能都不能進行測試的BUG庵朝，即冒煙測試失敗；其他項目停止的事件偿短；
2）測試恢復準則：不存在導致系統(tǒng)無法測試的BUG欣孤，冒煙測試通過

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

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

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

測試目標

為了制定正確的測試目標，需要充分理解用戶的需求鉴扫，將用戶的需求轉(zhuǎn)化為測試需求
比如用戶要求一個官網(wǎng)在使用時能快速響應赞枕，不能出錯，轉(zhuǎn)化為測試需求坪创，即為性能測試炕婶，接下來再確定具體的目標：多少人同時在線時，響應時間應小于幾秒等莱预。
在確定測試目標時柠掂，往往需要對軟件產(chǎn)品所涉及的業(yè)務功能和業(yè)務流程進行分析，從而進一步細化測試目標依沮，設計出對應的測試用例來驗證各項具體的測試目標是否實現(xiàn)涯贞。

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

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

測試策略

根據(jù)測試需求和范圍态蒂、測試風險、測試工作量和測試資源限制等來決定測試策略费什，是測試計劃的關(guān)鍵內(nèi)容钾恢。

一般情況下，不管采用什么方法和技術(shù)，測試都是不徹底的瘩蚪，不能夠保證被測試程序中不存在遺漏的缺陷泉懦。
一輪系統(tǒng)測試過后，如果程序中遺漏的嚴重錯誤過多疹瘦，說明測試是不充分的甚至是失敗的崩哩，讓用戶承擔隱藏錯誤帶來的風險。相反言沐，如果過度測試邓嘹，又會浪費很多資源，加大測試成本险胰。
因此汹押，有必要找到一個平衡點，依據(jù)軟件項目類型起便、規(guī)模以及應用背景的不同棚贾，選擇不同的測試方案，以最少的軟榆综、硬件以及人力獲得最佳的測試效果鸟悴。

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

如何制定測試策略？
在制定過程中利赋，需要考慮用戶特點水评、系統(tǒng)功能之間的關(guān)系、資源配置媚送、上個版本的測試質(zhì)量中燥、已有的測試經(jīng)驗等因素的影響，找到問題的解決辦法塘偎，包括采取哪些測試方法疗涉、采用什么樣的測試工具，需要盡可能地考慮細節(jié)吟秩。