一般在產品需求確認、測試需求分析完成後進行測試計畫編寫。
測試計畫應該包含的內容——
測試範圍：明確需要測試那些模組。產品的具體業務需求有哪些，產品是web端的還是移動端的，還是都有。
測試策略：明確怎麼測。對不同業務需求具體要有哪些測試型別、測試場景、測試方法等等。
資源安排：測試人員的安排，測試環境是怎樣的，測試工具的選擇。
進度安排：明確什麼時候開始測試，預計要測試多久，以便和開發計畫、上線計畫銜接。
發布標準：測試完成和產品上線需要滿足的條件，以便專案內所有角色都有一致認可的目標。
風險預防：對整個測試過程中可能出現的風險，以及當這些風險發生時的應對措施提前進行考慮和準備並在測試計畫中體現出來。
測試計畫模板
1 引言
1.1 編寫目的
1.2 預期讀者
1.3 參考資料
2 測試範圍
3 測試策略
3.1 功能測試策略
3.2 系統相容性測試
3.3 效能測試
4 測試資源
4.1 測試人員
4.2 測試環境
4.3 bug管理工具
5 進度安排
5.1 測試進度及工作量估算
5.2 輸出文件
6 發布標準
6.1 測試完成標準
6.2 產品發布標準
7 風險說明
進度安排
專案的里程碑
1、開發節點
2、提測節點
3、上線節點
測試進度依賴於開發進度和提交測試的時間，並且直接影響預期的上線時間。
評估因素
1、業務複雜度
2、測試複雜度
3、產品質量要求
4、人員數量能力
進度安排
1、評估工作量
比如冒煙測試的工作量，大概有幾輪回歸測試以及工作量，效能測試的工作量等。
2、分配人力
對測試人員的分工進行安排，明確職責。比如，誰進行功能測試，誰負責效能測試等。
3、預估時間
預估測試工作開始和結束的時間節點。比如，預計什麼時候能夠開始效能測試、預計什麼時候完成第二輪回歸測試等。
輸出文件
1、測試計畫
2、測試用例
3、bug資料
4、測試報告
發布標準
測試完成的標準和產品發布的標準這兩個測試目標之間既有關聯，又不完全相同，都需要在專案團隊內達成一致共識。
測試完成是產品發布的前提，但是產品上線前，還有其他一些需要完成的工作。
測試完成標準
1、測試計畫中包含的所有測試型別都已經完成
2、沒有影響使用者正常使用的bug
3、允許遺留影響較小的bug，但是bug數要少於一定值
4、服務端效能滿足設計目標
以上標準都是針對測試工作本身的要求。
產品發布標準
1、所有產品需求都已完成
2、互動視覺完成了走查
3、遺留bug經過風險評估
4、使用說明文件完備
風險評估
計畫本身就需要更新維護，所以需要對測試過程和產品質量可能會發生的問題和風險做好應對準備，避免問題真的發生後出現連鎖反應，影響整個測試和剩下的工作。
測試風險一般包含：
測試範圍風險
測試遺漏：一開始，測試需求分析不準確、不到位，遺漏了測試點，甚至遺漏了某個測試型別。所以測試需求分析是整個測試工作的基礎。
需求變更：加需求、改需求都需要重新進行測試需求分析。需要測試的不能遺漏、不需要測試的就不要浪費人力物力。
測試進度風險
工作量預估不準確
耦合任務延遲：測試依賴開發，開發沒有完成或者改bug不及時導致進度延後
測試人員變動
產品質量風險
**質量
測試人員能力
測試計畫編寫
1.文件的要求 好的模板是經驗和智慧型的積累，是團隊的財富。它可以將乙個團隊中最好的工作方法迅速傳播給每個成員。從而使整個團隊的戰鬥力增強。大企業不惜重金引入 模板 例如，聯想。2.微軟實踐 從做好需求開始 要像法律條文一樣。剛性不強的法律執行起來難度很大，容易偏差。3.軟體測試計畫的目標 計畫先行...
測試計畫編寫
前言 測試計畫是測試中比不可少的一部分，乙份完整的測試計畫反應了整個專案的測試安排與測試進度，讓專案在測試環節達到了可控的環節。需要注意的是，測試計畫一般在大功能改動的時候需要用到，並不是每個周版本必須的。是否編寫可根據專案需要，另外測試計畫的編寫時間，一般是你在了解了需求，分析完了需求後才開始編寫...
測試計畫編寫
軟體測試計畫包含了產品概述 測試策略 測試方法 測試區域 測試配置 測試週期 測試資源 測試交流 風險分析等內容。借助軟體測試計畫，參與測試的專案成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。why 為什麼要進行這些測...