首先，什麼是測試計劃，說白了，就是用來指導後續測試工作的規範文檔，用來規劃測試的進度，詳細時間，人員，風險等事項。打個比喻，就象我們玩網遊，作爲一個團隊Leader，你要帶領團隊推倒某個BOSS就是目標，如何推倒，用什麼樣的戰術，配置什麼樣的人員，每人需要什麼裝備底線，需要什麼技術的，如果BOSS前有小BOSS，用什麼樣的路線來走，如果遇到問題，應該怎麼辦，是當場換戰術，還是回去總結然後捲土重來。誰來記錄人員出勤，人員貢獻度，如何分配戰利品。大致推倒這個BOSS需要多少天，每天用多長時間。是否需要與其他團隊合作，如果需要誰是聯繫人，有問題由誰來評定，如何合作等等。其實這就是一個詳細的計劃。按照計劃走，在實際執行過程中會少走路，碰到問題，大多也會很容易就得到解決，或找到合適的解決辦法。
測試計劃也有很多種類，有整體測試計劃，有階段的測試計劃，這要看你所在的組織，實際項目情況來定。總的來說有《項目測試計劃》、《系統測試計劃》、《集成測試計劃》、《單元測試計劃》。
計劃的編制是建立在豐富的項目經驗基礎上，才能充分的把控整個項目的走向。指導並引導測試工作朝着正確的方向健康的發展。
很多人都問，測試計劃在什麼時候開始編寫，是在項目計劃確定後，還是需求規格基線之後，還是詳細設計完成？其實這個問題比較籠統，要說明做什麼測試計劃？需要先明確的一點是，測試計劃都是要以需求做爲依據，明確了需要測什麼，才能確定怎麼測。《項目測試計劃》是以《項目計劃》爲輸入，服從於《項目計劃》，以《項目計劃》爲參考標準制定的，《系統測試計劃》對應的是《需求規格說明》，《集成測試計劃》和《單元測試計劃》分別是《概要設計》和《詳細設計》。如果就《項目測試計劃》而言，可以在需求調研階段就介入，開始着手編寫，在《項目計劃》確定、通過評審後正式定製。當然，實際情況中一般來說，我們只編寫一份測試計劃，這也就是大家泛講的測試計劃。這份計劃如果有條件就要從需求調研階段介入，開始瞭解項目的需求和目標，在《需求規格說明》基線後，開始制定《測試計劃》。
下面來說說測試計劃的內容。標題、摘要、範圍等通用格式部分就不講了，直進主題，主要包括：
· 測試範圍，描述本次測試哪些要測，哪些不測，包括功能，性能，模塊等；
· 測試策略，也就是怎麼測，如何測；
· 測試類型，清晰的列出都採取何種測試，如功能測試，GUI測試，易用性的測試等等，每種測試類型中還要說明測試的目標，採用的技術，完成的標準及相關的特殊事項等；
· 測試工具，測試需要用到的工具，名稱、廠商及版本號；
· 測試資源，包括軟硬件資源，人力資源等；
· 異常事項的處理，如遇到爭執不下的問題，如何解決，找誰去裁決，部門之間的合作等；
· 測試的掛起與恢復，即在什麼情況下測試不再繼續執行，什麼條件滿足了再繼續，以減少人員閒置浪費資源；
· 測試風險，需要詳細列出可能想到的測試過程中會出現的以及規避的方法，如人員可能不穩定，會被其他項目借走，那麼我們的測試工作應該如何應對；
· 測試進度，詳細的列出任務、時間、人員及所需工時；
· 測試結束標準，說明滿足什麼條件本次測試工作纔可以算結束；
· 輸出，明確測試結束後，需要交付的所有文檔。
以上就是基本的測試計劃需要包括的內容了，可以根據實際情況添加或刪減。
測試計劃的幾點注意：
· 計劃寧可時間多一些，也不要少，避免在測試執行階段因爲時間定的不夠而捉襟見肘。但要符合實際情況，不能與實際偏離，否則會導致項目反覆的變更，影響項目組的工作，以及測試人員的工作熱情。
· 測試計劃可以長達幾百頁，也可以簡單的只有一張紙，關鍵測試計劃必須實用，也不必要把大量的人力和物理花費在測試計劃上，要根據具體情況來確定。
· 不要爲了計劃而計劃，事後補來的計劃對於測試工作沒有任何意義。
· 計劃不是一成不變的，可以隨着工作的開展進行修改，但要控制修改力度、頻率，頻繁的修改就需要重新考慮計劃定的是否合理了。
· 有了計劃就要按照計劃來執行，前提是計劃是合理併合適於本項目的，只制定不執行也就完全地失去了測試計劃的作用。
測試計劃制定完成後，需要進行評審，審核計劃的正確性、全面性、可行性。在項目結束後，還應該對測試計劃的執行情況進行分析總結，作爲以後項目測試計劃的經驗，積累下來，以提高測試計劃的質量。