??相信大多數的軟件測試工程師都聽說過或者簡單了解過測試計劃，但是你真的知道什么是測試計劃么？你真的知道如何編寫測試計劃么？大多數人應該是一臉茫然。百度的結果五花八門，有沒有相對規范的標準呢？答案是沒有，至少我沒有找到。那么今天我就結合經驗和對一些國內技術前沿的公司跟大家聊一聊什么是測試計劃以及如何編寫測試計劃。
??計劃的必要性：
??在我們日常的工作和生活中，經常需要做計劃。古人云：凡事預則立，不預則廢（《禮記.中庸》），也就是強調預先計劃的重要性和必要性。
??我們做項目，項目需要定項目計劃；測試作為項目中的一部分，當然也需要制定測試計劃。

• 測試計劃就像是我們寫論文一樣，首先做好提綱，才能一步一步的完善填充，有了測試計劃就掌握了整個項目的進度和方向，在工作中可以有個指導的作用，不至于偏離工作方向；
• 測試計劃規定預期的目標，以什么樣的程度完成和在預期多久內完成，這樣的規定能夠使工作人員做好心理準備，合理的期限和目標能夠使工作人員不松懈，有效率的完成一個項目；
• 計劃作為對未來工作的規劃，肯定會受到突發的或者不穩定的因素影響而導致整個項目出現延期甚至無法進行的結果。因此計劃中對于風險評估的必要性就在于羅列出影響整個項目進行的因素，并制定相應緊急方案，將損失降至最小化；
• 人員的安排呈現合理化。任何一個項目內的工作都有難易繁簡的劃分，因而才需要有專長的工程師進行對應的測試。難度較大的由資深測試人員安排，難度小的由新進實習生來進行，整個項目的進行就會顯得合理化層次化條理化。同時將職責清晰地具體劃分到個人身上，也有利于日后的糾錯，及時發現哪個環節出現問題；
• 測試計劃的制作是在需求分析完成之后所進行，所以測試計劃的執行在一定程度上也是對需求分析的進一步的檢驗，若在制定過程中，發現有不合理的因素存在，還能及時反饋，進行調整，不至于使眾多的人力做了無用功；
• 測試計劃的安排也是一個項目中多個部門間合作的工作指導，一環扣一環，工作的交接在時間上做好詳細的備注，才能讓部門的合作顯得默契。

??一個測試計劃制定者的素養：

• 有多年從事測試工作的經驗，能夠條例清晰的羅列出測試中的流程和應當留心的步驟，以及不可缺少的風險規避的意識
• 對于部門的員工能力要有一定程度的了解，才能合理的安排工作內容
• 高壓下的冷靜處理能力，一旦項目出現突發的嚴重問題，能夠冷靜找出出錯環節。
• 人際溝通的能力，一個測試計劃也是有與其他部門之間的合作關系，需要與其保持及時有效的溝通，了解到他們的需求

??那么我們什么時候來做測試計劃呢？
??一般來說，在產品需求確認，做過測試需求分析之后我們就要開始編寫測試計劃。當然測試計劃編寫的工作要根據工作實際來決定，也就是具體情況具體分析（政治課學的哈~）
??其實，要想做好測試計劃必須有一定的測試經驗。那么下面我就結合工作實際，跟大家聊一聊測試計劃的內容。
??測試計劃的內容：

• 測試范圍 明確測什么？比如：產品的具體業務需求有哪些？產品是web端的還是移動端的，還是兩者都有？

• 測試策略 明確怎么測？對不同業務需求，具體要有哪些測試類型、測試場景、測試方法。

• 資源安排 包括測試人員的安排，測試環境是怎樣的，測試工具的選擇等。

• 進度安排 在明確測試范圍、方法和人員之后，我們要考慮什么時候開始測試，預計要測試多久？以便和開發計劃、上線計劃銜接。

• 發布標準 發布標準是測試完成和產品上線需要滿足的條件，以便項目內所有角色都有一致認可的目標。怎樣才算是測完了？達到怎樣的標準才可以上線？

• 風險預防 最后，我們需要對整個測試過程中可能存在的風險，以及當這些風險發生時的應對措施提前進行一些考慮和準備，并在測試計劃中體現出來。

??我們把這些內容模板化，形成測試計劃的模板。無論是在實際的工作中還是大家學習編寫測試計劃，都可以用這樣的模板來使用。

在此模板的基礎上，我們一點點來剖析如何編寫測試計劃。

這里的參考資料可以有：（可行性分析報告、軟件需求定義、軟件系統分析、軟件概要設計、軟件詳細設計、軟件測試需求、硬件可行性分析報告、硬件需求分析、硬件概要設計、硬件原理圖設計、硬件結構設計、硬件測試需求、模塊開發手冊、測試時間表及人員安排、測試計劃、測試方案、測試報告、測試分析報告、用戶操作手冊、安裝指南等）
2 測試范圍
測試范圍的確定來自于需求文檔，依據是項目的交互稿和需求分析結果
2.1功能測試范圍的分析
功能點的拆分、接口測試、UI測試
2.2系統測試范圍的分析
（1）容錯處理
（2）兼容性要求
（3）配置要求
（4）性能要求
（5）安全性要求
（6）可靠性、日志文件

3.測試策略
為了更好確定軟件測試策略，可以問如下一些問題：
(1).回歸測試的范圍如何確定？
(2).如何利用可重復性的測試？
(3).測試缺乏可預見性，如何收集衡量測試結果的指標？
(4).如何建立穩定的、模擬系統實際運行的測試環境？
(5).如何從無窮的輸入數據中選擇合理的、有效的測試數據集？
(6).如何衡量這份測試策略的有效性？
1、基于測試技術的測試策略
(1).任何情況下都要使用邊界值分析方法
(2).等價類劃分法是對邊界值分析方法的有效補充
(3).如果功能的輸入數據/條件存在多種組合情況，則使用因果圖
(4).錯誤推測法
(5).對照程序邏輯來審查已有測試用例的邏輯覆蓋程度
(6).白盒測試
2、分階段的測試策略
(1).嚴格執行代碼審查
(2).單元測試和集成測試，準備自動化測試
(3).系統測試中，以每次發布用戶基線為結束標志
(4).不能忽略安全性測試、可用性測試、配置測試和數據完整性測試
(5).在功能測試、安全性測試、配置測試中進行探索性測試
3、基于測試方案的綜合測試策略
(1).測試優先級，優先級越高，越早測試，測試力度越大
(2).使用盡可能少的測試用例，發現盡可能多的程序錯誤
(3).測試策略盡量簡單、清晰
(4).基于缺陷分析的測試策略

4、測試資源
測試人力資源包含兩個維度：
1、測試人員數量
2、測試人員經驗、能力。
環境資源一般包括：
1、測試服務器環境（盡量與線上環境保持一致）
2、終端環境（PC配置，手機型號）
3、測試工具（bug管理工具，用例管理工具，性能測試工具等）
在我們的測試計劃中，測試人員分配、測試環境資源、網絡資源、工具使用都要明確寫出來。

5、進度安排
測試工作的進度安排依賴于開發工作的節點和提交測試進度的時間，并且直接影響預期的上線時間。所以我們需要根據產品業務的復雜度、所需要進行的不同的測試類型的復雜度、產品上線的質量要求的高低、測試人員的數量、能力和經驗這些因素，來評估不同階段、不同類型的測試工作的工作量。
可以用工作分解結構表方法評估工作量：
1、列出本項目需要完成的各項任務
2、細化每個任務，尤其是測試階段，需要對模塊進行拆分，拆分到可衡量和細化的維度
3、預先設計測試點，按照測試點來估算
4、給每個維度估算時間，需要優化和重復操作的部分
5、在已估算結果上浮動10%-15%

6、發布標準
測試完成的標準，也就是說做到什么樣算是測試工作做完了。主要包括：
1、測試計劃里所有測試類型都已經完成了
2、功能上、兼容性上沒有影響用戶使用的Bug
3、允許遺留小部分影響不是很大的Bug，但這個數量應該小于一個值
4、性能上符合設計目標和上線要求 這些標準都是針對測試工作本身的要求。
在滿足了測試本身的前提下，產品要發布還需要滿足要求：
1、產品需求都已完成
2、交互視覺走查都已完成
3、一流的小部分Bug項目組完成了風險評估，都認可且問題不大
4、產品使用說明或用戶手冊或更新log都已完備等等。

7、風險說明
測試風險分類：
1、測試范圍的風險，測試遺漏、需求變更；比如說一開始測試需求分析不準確、不到位漏了測試點，甚至某個測試類型遺漏了，這樣問題就比較大了，所以測試需求分析是整個測試工作的基礎，還有就是產品需求變更的風險，加需求、減需求、改需求都需要重新進行測試需求分析，需要測得一定要測到，不需要測的就不要浪費人力物力和工作量；
2、測試進度的風險，工作量預估不準確、耦合任務延遲、測試人員變動；比如說做計劃時工作量估計的不準，測試做著做著發現時間不夠導致項目延期，還有測試依賴開發，可能開發工作沒有按時完成或改bug不及時導致進度延后，還有可能測試人員因為別的項目更重要抽調走了或者請假、離職等原因造成人員變動；
3、產品質量的風險，代碼質量、測試人員能力；比如開發的代碼質量比較低或者測試人員是新人對業務不熟悉，能力和經驗有所欠缺等等。
測試風險的控制方法：
1、根據風險發生的概率和帶來的影響確定風險的優先級，然后才去措施避免那些可以避免的風險；
2、風險轉移，比如去掉新功能，轉移風險；
3、不可避免的風險，就設法降低風險，如提高測試用例的覆蓋率；
4、事先做好風險管理計劃，喜歡里程碑和驗收管理；
5、有一套應急、有效的處理方法，比如全員了解，注意日常觀察，及時發現風險出現的征兆；
6、做計劃時，要留有余地
7、制定文檔標準。

??到這里我們就完成了一份測試計劃。有的人可能依舊存在疑問：做計劃真的有那么重要么？我們實際工作中有很多項目根本就沒有計劃依舊可以完成的啊！我們來看一下不做計劃可能會有哪些問題~
?首先，如果沒有計劃我們無法預估工作量和需要的測試人員數量。一個項目的工作量和需要的人員數量都沒有依據，在公司里怎么來協調和安排呢？
?其次，測試人員的分工明確，會導致工作重復和遺漏。出了問題大家可能都覺得不是自己的問題，導致工作混亂效率低下。
再就是測試進度失控。到底什么時候做完沒有一個預期，其他的團隊怎么安排工作呢？進度有沒有失控也沒有判斷依據，臨到預計的上線時間才發現還有很多沒有測到、沒測完，直接影響整個項目的進行。
還有就是應對需求變更困難，對可能出現的風險沒有準備。一旦出現問題，大家一片混亂，很容易導致測試遺漏和項目延期。
?最后就是沒有統一發布標準，上線意見不一致。測試團隊認為Bug太多不能上線，開發團隊認為都是小Bug不要緊，先上線再說，導致爭執不下的局面。、
?當然根據項目不同還可能存在其他一些列問題…
?總而言之，測試計劃的作用非常重要。

• 指導測試過程
• 協調項目安排
• 提高測試效率
• 提高測試質量
  做測試計劃對測試人員的能力和要求是非常高的，從另一個角度來說，測試計劃可以體現一個測試人員的自我修養。一個測試人員需要很好的經驗沉淀、有很多好的全局意識才能做好一個項目的測試計劃。
  希望大家都能夠很好的勝任編寫測試計劃這項工作。

總結

以上是生活随笔為你收集整理的软件测试-测试计划的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。