提到測試計劃，是否會首先想到一份龐大、正式的測試計劃文件？

在早期傳統瀑布模式下，測試計劃一般是一份很重的文件。但是現在敏捷模式盛行，很少再去制定傳統意義上的測試計劃了。但是，並不是說測試計劃沒意義了，而是形式上變得更輕盈，可以隨著專案情況實時調整。

所以說，測試計劃依舊存在，只是從原來的一次性集中制定測試計劃，變成了以迭代的方式持續制定測試計劃。

通常，一份好的測試計劃應該具備以下內容：測試範圍、測試策略、測試資源、測試進度和測試風險預估。

一、測試範圍

測試範圍，需要明確：

• 測什麼
• 不測什麼

比如，對於使用者登入模組，功能測試既需要測試瀏覽器還要測試移動端，同時還考慮登入的安全、併發等非功能性需求的測試等等。

同時，由於不可能進行窮盡測試，而且測試的時間和資源都是有限的，所以必須有所取捨，進行有針對性的測試。

二、測試策略

測試策略，需要明確：

• 先測什麼後測什麼
• 如何來測

1. 測試順序

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

比如，對使用者登入模組來講，“使用者無法正常登入”和“使用者無法重置密碼”這兩個潛在問題，顯然前者影響更大。所以，應該來先測“使用者正常登入”，再測“使用者重置密碼”。

2. 測試型別或方法

1）功能測試

這個是必備方法，包含了介面測試、GUI測試，無須多說。

另外，主線業務的功能測試經常需要執行迴歸測試，所以條件允許的話，還可以考慮實施自動化測試（優先實現主幹業務流程）。

2）相容性測試

通常在功能測試的後期，這時候功能基本都穩定，方便開展相容性測試。

主要針對：不同瀏覽器和版本、不同移動裝置型別和作業系統等，選用覆蓋最常用業務場景的測試用例進行測試。

3）效能測試

需要在明確了效能需求（併發使用者數、響應時間、事務吞吐量等）的前提下，結合被測系統的特點，設計效能測試場景並確定性能測試框架。

效能測試涉及內容繁多，這裡不展開了，後續會單獨分享。

三、測試資源

通常包括：測試人員、測試環境。

一、測試人員

確認誰來測。

通常需要你對團隊的成員有較全面的瞭解，把每個人放到合適的位置，做合適的事情。

比如，難度較大的工作，或者一些新工具、新方法的應用，又或者自動化測試開發工作，通常由資深的測試工程師來承擔；而那些相對機械性、難度較小的工作，則由初級工程師完成。

強烈建議把具體的任務清晰地落實到每個人的身上，這將有利於清晰責任，避免後續可能發生的扯皮。

二、測試環境

確認在哪裡測。

根據不同的專案，可能會使用共享的測試環境，也可能使用專用的測試環境，甚至還會直接使用生產環境。不管是用哪種，確認測試環境的可用，或者誰來搭建交付是必要的。

四、測試進度

測試進度主要描述各類測試的開始時間，所需工作量，預計完成時間，從而進一步推出上線釋出時間。

五、測試風險預估

計劃趕不上變化，通常很少有整個測試過程是完全按照原本測試計劃執行的。可能存在：

• 需求變更：比如增加需求、刪減需求、修改需求等，一定要重新進行測試需求分析，確定變更後的測試範圍和資源評估，並與專案成員及時溝通因此引起的測試進度變化。
• 測試工作量預估不準：隨著測試的開展，你可能會發現前期對於測試工作量的預估不夠準確，也可能發現需要增加更多的測試型別，也可能發現因為要修改測試架構的嚴重缺陷而導致很多的測試需要全迴歸，還有可能出現開發遞交測試版本延期，或者人員變動等各種情況。

所以，在制定測試計劃時，就要預估整個測試過程中可能存在的潛在風險，以及當這些風險發生時的應對策略。做到心中不慌，有條不紊地應對這些挑戰。

本文參考：
茹炳晟 老師《軟體測試52講》