相信大多數的軟件測試工程師都聽說過或者簡單了解過測試計劃，但是你真的知道什麽是測試計劃麽？你真的知道如何編寫測試計劃麽？

大多數人應該是一臉茫然。

百度的結果五花八門，有沒有相對規範的標準呢？答案是沒有，至少我沒有找到。

那麽今天我就結合經驗和對一些國內技術前沿的公司跟大家聊一聊什麽是測試計劃以及如何編寫測試計劃。

計劃的必要性

在我們日常的工作和生活中，經常需要做計劃。古人雲：凡事預則立，不預則廢（《禮記.中庸》），也就是強調預先計劃的重要性和必要性。

我們做項目，項目需要定項目計劃；測試作為項目中的一部分，當然也需要制定測試計劃。

• 測試計劃就像是我們寫論文一樣，首先做好提綱，才能一步一步的完善填充，有了測試計劃就掌握了整個項目的進度和方向，在工作中可以有個指導的作用，不至於偏離工作方向

• 測試計劃規定預期的目標，以什麽樣的程度完成和在預期多久內完成，這樣的規定能夠使工作人員做好心理準備，合理的期限和目標能夠使工作人員不松懈，有效率的完成一個項目

• 計劃作為對未來工作的規劃，肯定會受到突發的或者不穩定的因素影響而導致整個項目出現延期甚至無法進行的結果。因此計劃中對於風險評估的必要性就在於羅列出影響整個項目進行的因素，並制定相應緊急方案，將損失降至最小化。

• 人員的安排呈現合理化。任何一個項目內的工作都有難易繁簡的劃分，因而才需要有專長的工程師進行對應的測試。難度較大的由資深測試人員安排，難度小的由新進實習生來進行，整個項目的進行就會顯得合理化層次化條理化。同時將職責清晰地具體劃分到個人身上，也有利於日後的糾錯，及時發現哪個環節出現問題。

• 測試計劃的制作是在需求分析完成之後所進行，所以測試計劃的執行在一定程度上也是對需求分析的進一步的檢驗，若在制定過程中，發現有不合理的因素存在，還能及時反饋，進行調整，不至於使眾多的人力做了無用功。

• 測試計劃的安排也是一個項目中多個部門間合作的工作指導，一環扣一環，工作的交接在時間上做好詳細的備註，才能讓部門的合作顯得默契。

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

• 有多年從事測試工作的經驗，能夠條例清晰的羅列出測試中的流程和應當留心的步驟，以及不可缺少的風險規避的意識

• 對於部門的員工能力要有一定程度的了解，才能合理的安排工作內容

• 高壓下的冷靜處理能力，一旦項目出現突發的嚴重問題，能夠冷靜找出出錯環節。

• 人際溝通的能力，一個測試計劃也是有與其他部門之間的合作關系，需要與其保持及時有效的溝通，了解到他們的需求

那麽我們什麽時候來做測試計劃呢？

一般來說，在產品需求確認，做過測試需求分析之後我們就要開始編寫測試計劃。當然測試計劃編寫的工作要根據工作實際來決定，也就是具體情況具體分析（政治課學的哈~）

其實，要想做好測試計劃必須有一定的測試經驗。那麽下面我就結合工作實際，跟大家聊一聊測試計劃的內容。

測試計劃的內容

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

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

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

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

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

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

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

在此給大家分享一個測試交流群：672899761。

我就是為了來分享一個模板麽？當然不是，那不是我的風格。

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

首先我們的依據是項目的交互稿和需求分析結果。

交互稿：

功能分析結果：

第一步我們來明確測試範圍

測試範圍的確定來自於需求文檔，比如本次需求的目標：要求用戶可以成功參加課程。我們功能測試需求分析的結果為用戶成功參加課程，涉及到瀏覽課程、參加課程、學習課程三個模塊。

然後考慮兼容性測試、性能測試這些測試類型。我們把我們分析的結果填充到模板中的測試範圍這一節中，明確需要測試的也無需求和需要測試的測試類型。

接下來我們來寫測試策略的內容

我們要根據不同的測試類型考慮不同的測試方法，對於功能測試，我們根據需求分析的思維導圖和功能測試的測試用例覆蓋瀏覽課程、參加課程、學習課程三個模塊就可以了；兼容性測試，我們要根據產品的應用場景來考慮，比如IE、Chorme、ios、android、不同機型等等；性能測試，根據產品架構、預估數據、線上數據來判斷需要執行性能測試的功能接口（比如登錄接口）；接口測試，安全性測試等等要根據實際的項目需求來確定。

然後我們將需要用到的測試類型按照測試場景、測試方法等以引用文件的形式填寫到測試計劃中去，以便讓所有項目人員清楚的知道要做哪些測試工作以及怎麽做。

接下來我們要考慮測試人員的分工和測試資源的分配

比如說，測試人員數量不夠或能力不夠的時候，就要額外申請測試人員。

測試資源我們一般包括兩方面：測試人力資源和測試環境資源。測試人力資源包含兩個維度：測試人員數量和測試人員經驗、能力。環境資源一般包括：

在我們的測試計劃中，測試人員分配、測試環境資源、網絡資源、工具使用都要明確寫出來。

接下來，需要做測試進度安排。

測試工作的進度安排依賴於開發工作的節點和提交測試進度的時間，並且直接影響預期的上線時間。所以我們需要根據產品業務的復雜度、所需要進行的不同的測試類型的復雜度、產品上線的質量要求的高低、測試人員的數量、能力和經驗這些因素，來評估不同階段、不同類型的測試工作的工作量。比如冒煙測試的工作量、大概有幾輪回歸測試以及工作量、性能測試的工作量等等。然後對測試人員的分工進行安排，明確職責；那些人進行功能測試、誰來負責性能測試。最終來預估測試工作開始和結束的時間節點，比如預計什麽時候可以開始性能測試；預計什麽時候完成第二輪回歸測試之類。在整個測試過程中，測試團隊需要輸出的文檔也都需要列明，比如測試計劃、功能測試用例、性能測試方案、bug數據、性能測試數據、測試報告等等。

在我們攜程XXX項目的例子裏，大家可以清晰地看到進度安排的詳細情況。

好的廚師需要有能夠判斷好的菜品可以出鍋的標準，同樣的道理，在測試工作中也需要有標準或一致的目標，來判斷測試階段是否可以結束、產品是否可以上線。這個標準或者目標一般來說包含兩個方面：一是測試工作完成的標準，二是產品可以上線發布的標準。這兩個目標既相互有關系，但又不完全相同，兩者都需要在項目團隊內達成一致和共識。

測試完成是產品發布的前提，但產品上線前還有其他一些需要完成的工作。我們分別來說明。

首先是測試完成的標準，也就是說做到什麽樣算是測試工作做完了。主要包括：1、測試計劃裏所有測試類型都已經完成了 2、功能上、兼容性上沒有影響用戶使用的Bug 3、允許遺留小部分影響不是很大的Bug，但這個數量應該小於一個值 4、性能上符合設計目標和上線要求 這些標準都是針對測試工作本身的要求。

在滿足了測試本身的前提下，產品要發布還需要滿足哪些要求呢？比如說：1、產品需求都已完成 2、交互視覺走查都已完成 3、一流的小部分Bug項目組完成了風險評估，都認可且問題不大 4、產品使用說明或用戶手冊或更新log都已完備等等。

在我們攜程的例子裏，測試完成標準和上限標準有如下：

在我們的生活中，網網計劃是美好的，現實是殘酷的。

測試工作亦是如此，很少有計劃是完全可以順順利利執行完的，計劃本身也需要更新維護。所以我們要對測試過程和產品質量可能會發生的一些問題和風險做好應對準備，避免問題真的發生後出現連鎖反應，影響整個測試和項目工作。

測試風險一般包含這樣幾類：一是測試範圍的風險，比如說一開始測試需求分析不準確、不到位漏了測試點，甚至某個測試類型遺漏了，這樣問題就比較大了，所以測試需求分析是整個測試工作的基礎，還有就是產品需求變更的風險，加需求、減需求、改需求都需要重新進行測試需求分析，需要測得一定要測到，不需要測的就不要浪費人力物力和工作量；二是測試進度的風險，比如說做計劃時工作量估計的不準，測試做著做著發現時間不夠導致項目延期，還有測試依賴開發，可能開發工作沒有按時完成或改bug不及時導致進度延後，還有可能測試人員因為別的項目更重要抽調走了或者請假、離職等原因造成人員變動；三是產品質量的風險，比如開發的代碼質量比較低或者測試人員是新人對業務不熟悉，能力和經驗有所欠缺等等。

在攜程某項目的例子中，列舉了一些可能遇到的風險：

到這裏我們就完成了一份測試計劃。有的人可能依舊存在疑問：做計劃真的有那麽重要麽？我們實際工作中有很多項目根本就沒有計劃依舊可以完成的啊！我們來看一下不做計劃可能會有哪些問題~

首先，如果沒有計劃我們無法預估工作量和需要的測試人員數量。一個項目的工作量和需要的人員數量都沒有依據，在公司裏怎麽來協調和安排呢？

其次，測試人員的分工明確，會導致工作重復和遺漏。出了問題大家可能都覺得不是自己的問題，導致工作混亂效率低下。

再就是測試進度失控。到底什麽時候做完沒有一個預期，其他的團隊怎麽安排工作呢？進度有沒有失控也沒有判斷依據，臨到預計的上線時間才發現還有很多沒有測到、沒測完，直接影響整個項目的進行。

還有就是應對需求變更困難，對可能出現的風險沒有準備。一旦出現問題，大家一片混亂，很容易導致測試遺漏和項目延期。

最後就是沒有統一發布標準，上線意見不一致。測試團隊認為Bug太多不能上線，開發團隊認為都是小Bug不要緊，先上線再說，導致爭執不下的局面。、

當然根據項目不同還可能存在其他一些列問題......

總而言之，測試計劃的作用非常重要。

• 指導測試過程

• 協調項目安排

• 提高測試效率

• 提高測試質量

做測試計劃對測試人員的能力和要求是非常高的，從另一個角度來說，測試計劃可以體現一個測試人員的自我修養。一個測試人員需要很好的經驗沈澱、有很多好的全局意識才能做好一個項目的測試計劃。

希望大家都能夠很好的勝任編寫測試計劃這項工作。

原文：https://www.cnblogs.com/finer/p/9170490.html

你知道測試大牛怎麽寫測試計劃的嗎？