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