目前，ossp已經有比較規範的測試計畫
模版。編寫測試計畫時，可以以模版為基礎進行編寫。測試計畫中各部分如何編寫可以參加模版的詳細說明。根據測試專案的規模與測試任務的複雜程度，可以對測試計畫的編寫項進行新增或裁剪。這裡對測試計畫制定中的幾個部分作詳細說明：
1.明確測試目標，確定測試需求。根據當前測試工作目標不同，測試需求的確定方式有所不同。如當前為新專案的測試工作，則測試需求可能為該專案能按時上線並按使用者需求的功能正常使用等；而對於產品的階段性測試，測試需求可以以列表形式展現，列表可以列出本次測試工作所需要測試的更新及影響的測試點等。
2.制定測試策略的時候，需要考慮：
根據測試專案特點，確定本次測試需要經歷的測試階段。確定測試階段後，確考慮每個測試階段的目標、進入條件及退出條件（完成標準）。
根據確定的測試階段，分析每個測試階段需要包含的各種測試型別，如是否需要效能測試、安裝測試等。確定測試型別後，確定每種測試的測試目標、測試方法、完成標準及特殊事項考慮。
確定測試階段、測試型別後，針對需要，確定測試方式及測試工具。
特別的：在考慮測試策略時，還應結合系統的特點及系統功能的優先順序及難易程度，分析各項測試的重點及難點。另外，根據測試時間的長短不同，測試策略也需要有相應體現。
3.確定測試資源：測試資源的確定，需要充分調研，基本確定系統規模、功能複雜度、系統執行環境等，結合測試策略，考慮所需要的測試資源。確定測試資源，主要包括：
明確測試過程中角色分配。這點在測試計畫階段必須明確到人的是測試負責人這個角色。其他角色，如測試參與人員，可以不明確到具體的人員姓名。
明確測試人力資源及測試環境：考慮人力資源時，需要考慮所需人力資源的數量、各人力的知識或技能程度等。在測試計畫階段，測試負責人就可以開始協調測試資源，需要在該階段就確定測試資源，包括人員資源及環境資源。有些專案可能測試資源比較緊張，測試計畫制定者在制定計畫時應該考慮最少測試資源與充足測試資源這兩種條件下的測試策略調整。
4.測試里程碑設計：一般測試里程碑在模版上已經列示出來，測試計畫制定者按照之前分析的測試需求、確定的測試策略及明確的測試資源，作相應的風險分析，從而確定測試里程碑及里程碑的起始時間。在制定里程碑起始時間時，可能出現專案留給測試的時間在當前實際下不足，則應及時與專案經理溝通或者重新考慮測試策略或者重新調配資源。
5.測試管理及任務的制定：這部分內容的計畫，對順利完成測試任務，保證計畫執行有著重要意義。這部分內容，主要包括接收測試條件、測試時間（測試輪次）的設計、測試人員任務的分配、測試過程管理策略、測試完成標準確定及測試過程評審機制。這裡，主要對測試時間、測試人員任務、測試過程管理作特別說明：
（1）測試時間設計和測試人員任務分配可以作為一體考慮。測試計畫制定者需要有運籌的思想，根據當前測試資源的狀況結合測試策略，確定測試需要經歷多少輪次，各人員分別承擔什麼樣的測試任務。測試計畫制定者應該始終明確，成功的測試工作是用盡可能少的時間發現最多的缺陷。對於測試時間的評估，可以根據編寫的文件頁數、測試用例條數、執行測試用例數量及回歸測試大約用時來衡量。但是目前工作中，除了上述標準，還應按專案實際情況和計畫制定者的經驗綜合考慮。
測試輪次設計：設計測試輪次時，一般必須有回歸測試環節。回歸測試之前往往會經歷多輪測試。但是建議不要設計太多輪次測試，以避免資源耗用過於頻繁。每一輪測試都應有各自明確的目標與測試策略。如第一輪保證功能正確，第二輪保證流程順暢，效能穩定等。最終應該設計回歸測試環節，保證之前缺陷被正確修改，在該階段還可以配合進行安裝測試。如果系統龐大或測試工作複雜，對每一輪次測試，可以單獨做小的測試計畫，保證更好的測試效果。在測試時間控制上，應該略微預留一點時間，以控制突發事件。
在測試任務設計上，需要統籌分析考慮，合理安排人力資源。每個人測試什麼任務，和誰一起承擔，都應有特別的考慮；測試任務分配要均衡，避免出現一些任務特別緊張，一些任務很快完成的情況。
（2）測試過程管理設計中，需要考慮bug管理流程，專案測試進度控制。
bug管理中，需要考慮： bug管理的工具是什麼，bug管理系統中各角色人員的許可權是什麼（測試準備一部分），研發人員解決bug花費的時間限制，研發人員反饋bug修改的規範、測試人員確認bug的時間限制。總之，需要制定乙個bug管理流程，從乙個bug產生到bug關閉這個流程中，所經歷的過程規範。
測試過程管理規範的約定：如是否採用週報制度，對於專案較緊時是否採用**的形式。對專案組成員可以要求進行日誌形式提交測試情況等。
測試計畫應該是整個測試流程中第乙份測試文件了，但是一般情況下去不是測試人員學習的第一站。或許是因為萬事開頭難的緣故，測試計畫確實挺讓人糾結了。
(一)——萬事開頭難
測試計畫應該是整個測試
流程中第乙份測試文件了，但是一般情況下去不是測試人員
學習的第一站。或許是因為萬事開頭難的緣故，測試計畫確實挺讓人糾結了。
很多有了一定的經驗的測試人員在教新人的時候第一步都不是按照測試流程先從測試計畫開始，而是讓從測試
用例的執行開始——這雖是無奈之舉，但是對於測試新手來講，還是可以學習很多東西的。閒話扯得有點遠，回到我要介紹的正題上面來，計畫測試。
對，是計畫測試，不是測試計畫。儘管我們剛才討論了一些關於測試計畫的內容。但是我們需要關心的的確是計畫測試，而不是測試計畫。永遠要記住，我們是在做測試，而不是在完成文件，儘管我們經常需要諸如測試計畫測試用例測試報告之類的各種各樣的文件，但是那些都不是測試的本質。
既然是計畫測試，那麼我們首先要搞明白測試到底要幹什麼。筆者將它抽象概括為：特定的人在特定的時間在特定的地方做了特定的事情以實現特定的目標。其實任何一項工作都可以抽象成前面這句話，所以我們還需要將這句話與我們所從事的測試工作聯絡起來。
所謂人，當然是指測試人員了，而「特定的人」則堅持的是「按能力分工」各司其職的原則。測試用例設計人員做測試設計，測試用例執行人員做執行用例等等。
所謂「特定的時間」，是指我們的測試過程是分成各種階段的，各種階段所側重的測試要點是不一樣的。
所謂「特定的地方」則是指測試環境，這是指我們必須在計畫我們的測試工作的時候就要考慮到某些特殊型別的測試是需要特殊的環境的，這個環境包括了硬體設施(如手機測試你總得拿個手機來試試吧，總不能一直紙上談兵來著)環境，計算機硬體環境和軟體環境。
所謂「特定的事情」即是指我們測試技術本身了，也就是諸如測試用例設計，測試用例執行，寫測試**，部署測試環境等等。
所謂「特定的目標」即是指我們測試的目的。測試是需要成本的，人力物力都是需要的，既然我們對測試有投入那麼我們是期望獲得一些東西的。測試最常喊的口號是改善質量水平，也有一些還在喊保證質量的，這就是我們所謂「目標」。不過，可惜的是這些口號並沒有多大的用處，因為在實際的軟體專案中我們更加看重的則是可度量的測試工作，也就是說我們要由乙個可度量的「目標」——亦即「特定的目標」——可能是發現了多少bug
可能是測試覆蓋率達到了多少等等。
我們在計畫測試的時候，需要考慮的不僅僅是測試本身，從上面的分析可以看出，我們要關注「人、時、地、事、責」，也就是古代中華所講究的「天時地利人和」之類的東西。需要指出的是，在我們計畫測試的過程中，最常被人忽略的就是我們測試應該達到什麼目標這個問題了。在計畫測試的時候，切記要約定好測試的目標，這一目標反映在測試計畫文件中即「測試結束標準」。
(二)——測試計畫
在前一篇文章中，我們提到了計畫測試要考慮到人、事、時等諸多問題，也提到了計畫測試重在計畫這個過程而不在測試計畫這個文件。
這篇文章卻要專門討論一些測試計畫相關的話題。網路上現在已經氾濫了關於測試計畫的模板
——用氾濫只是表示很多，並沒有貶損的意思，筆者才疏一時想不到好的詞語——這些模板
對於製作乙份測試計畫文件來講非常有用，但是生搬硬套這些文件卻並不能幫助我們很好的計畫我們的測試工作，但是這些測試計畫中的主題卻可以很好地幫助我們計畫我們的測試工作並有效避免疏漏。
我並不會給出乙份我所常用的測試計畫模板，因為這些模板實在已經太多，已經夠用了。筆者在測試工作中，曾經寫出兩種測試計畫，一種類似於當前網路上流傳的版本，另外一種則是在筆者的某篇blog文章中提到的所謂「實用主義測試計畫」——事實上是更接近測試設計書的乙個文件，但是確實有些公司把它稱之為測試計畫，而在本系列文章中筆者將不再討論這種測試計畫，也不會考慮細到「怎樣設計某個功能的測試用例」的程度的計畫工作。
原文**：
如何編寫測試計畫
俗話說 凡事預則立，不預則廢！軟體測試同樣，在測試專案之初就要制定相應的測試計畫。接下來談下如何編寫測試計畫問題。一 首先了解以下幾個問題 1 為什麼要編寫測試計畫？領導能夠根據測試計畫做巨集觀調空，進行相應資源配置等 測試人員能夠了解整個專案測試情況以及專案測試不同階段的所要進行的工作等 3 便於...
如何編寫測試計畫
俗話說 凡事預則立。軟體測試同樣，在測試專案之初就要制定相應的測試計畫。接下來談下如何編寫測試計畫問題。一 首先了解以下幾個問題 1.為什麼要編寫測試計畫？領導能夠根據測試計畫做巨集觀調空，進行相應資源配置等 測試人員能夠了解整個專案測試情況以及專案測試不同階段的所要進行的工作等 3 便於相關人員了...
如何編寫測試計畫
測試計畫是在做完需求分析之後，整個測試工作開始之前做的準備計畫，可以 5w 1h 的方法去記憶。目的 why 測試範圍 what 測試進度安排 when 測試人員 who 測試環境 where 測試方法 測試工具 how 及風險評估。軟體專案的測試計畫是描述測試目的 範圍 方法和軟體測試的重點等的文...