前言：
測試計畫是測試中比不可少的一部分，乙份完整的測試計畫反應了整個專案的測試安排與測試進度，讓專案在測試環節達到了可控的環節。需要注意的是，測試計畫一般在大功能改動的時候需要用到，並不是每個周版本必須的。是否編寫可根據專案需要，另外測試計畫的編寫時間，一般是你在了解了需求，分析完了需求後才開始編寫。要不然你都不知道自己測試什麼，怎麼測試。
1. 測試目標：
根據***需求，提煉測試功能點、制定測試策略、評估測試 風險，預估編寫測試用例、執行功能測試和回歸測試的工作量，進行人員和進度 安排。
2. 測試範圍：
功能模組：（需要結合實際情況）
3. 測試策略：
對需求中的功能改進進行完整測試，並根據應用場景和併發數考慮相容性和 效能測試方案。 並需要指定出測試工具。
3.1 功能測試
見測試用例表
3.2 效能測試
3.3 系統相容性測試
4. 測試資源
4.1 人員安排
4.2 測試環境
4.3 bug管理
5. 測試進度安排
5.1測試進度安排
任務時間
執行人員
工作量編寫測試計畫
測試環境準備
第一次功能測試
效能測試
回歸測試
測試報告總結
5.2輸出文件
測試計畫
測試報告
6.1 測試驗收標準
1.完成所有型別測試
2. 沒有影響到使用者業務使用的bug
3. bug數量少於一定數量
4. 功能業務，效能指標符合需求
產品 checkelist
1. 已按照互動文件、需求文件完全的實現需求；
2. 符合互動稿的互動設計規範、符合視覺要求，已經通過設計評審；
3. 允許遺留可能會對使用者正常使用造成一定影響的 normal 級缺陷，但應在 發布前告知專案組，並經風險評估一致同意發布後方可發布
主要包括三個方面：
測試範圍風險 （測試遺漏，需求變更）
測試進度風險（預估量不準確，測試人員變動，其他業務工作，）
產品質量風險（**質量，測試人員能力）
比如：1. 上述工作量預估中對需求變更進行了一定的風險覆蓋，但如果需求變更 超出目前預計，則可能導致編寫測試用例和執行測試相關工作量增加、 測試進度延遲。。 2. 開發提交測試版本比該計畫延遲的風險，發生此種情況時，執行測試的 時間應該合理順延。 3.提交測試版本質量較低的風險，可能導致比該計畫更多輪次的回歸測試。
4.**版本管理執行不力的風險，發生版本管理混亂的情況時，將只選取 乙個穩定版本進行測試，不考慮中間版本的反覆測試。一輪測試完成後， 再進行下一穩定版本的回歸測試。 5. 雲課堂所依賴的測試伺服器環境，如果伺服器端測試環境不穩定，會影 響開發提交測試版本和測試的進度
最後箴言：
每次我們測試的時候都可以用5w+h思考方法，
1）why——為什麼要進行這些測試；
2）what一測試哪些方面，不同階段的工作內容；
3）when一測試不同階段的起止時間；
4）where一相應文件，缺陷的存放位置，測試環境等；
5）who一專案有關人員組成，安排哪些測試人員進行測試
6）how一-如何去做，使用哪些測試工縣以及測試方法進行
測試計畫編寫
1.文件的要求 好的模板是經驗和智慧型的積累，是團隊的財富。它可以將乙個團隊中最好的工作方法迅速傳播給每個成員。從而使整個團隊的戰鬥力增強。大企業不惜重金引入 模板 例如，聯想。2.微軟實踐 從做好需求開始 要像法律條文一樣。剛性不強的法律執行起來難度很大，容易偏差。3.軟體測試計畫的目標 計畫先行...
測試計畫編寫
軟體測試計畫包含了產品概述 測試策略 測試方法 測試區域 測試配置 測試週期 測試資源 測試交流 風險分析等內容。借助軟體測試計畫，參與測試的專案成員，尤其是測試管理人員，可以明確測試任務和測試方法，保持測試實施過程的順暢溝通，跟蹤和控制測試進度，應對測試過程中的各種變更。why 為什麼要進行這些測...
編寫測試計畫
軟體測試計畫就是在軟體測試工作正式實施之前明確測試物件，並且通過對資源，時間，風險，測試範圍和預算等方面的綜合分析和規劃，保證有效的實施軟體測試。軟體測試計畫是開展軟體測試得第一步，各個公司可能都會根據自己得情況定義乙份測試計畫得規格或模版 但是測試計畫得內容確大同小異，下邊是我認為需要在測試計畫書...