測試計畫是在需求分析之後進行的，可發現需求不合理地方。
1 測試計畫需要先列出大綱，再一步步填充 ，用於掌握整個專案進度和方向
2 規定合理的期限和目標，使人員有效率的完成任務
3 是對未來工作的規劃-對風險評估，列出影響因素，制定對應方案減少損失
4 對人員合理安排，對模組找對應的專業人員來測試。難度大的到難度小的由對應人員進行測試
5 多個部門之間的合作，工作交接在時間上做好備註
6 列出測試步驟、應留心的步驟
測試計畫的內容
測試範圍明確測什麼？比如：產品的具體業務需求有哪些？產品是web端的還是移動端的，還是兩者都有？
測試策略明確怎麼測。對不同業務需求，具體要有哪些測試型別、測試場景、測試方法。
資源安排包括測試人員的安排，測試環境是怎樣的，測試工具的選擇等。
進度安排在明確測試範圍、方法和人員之後，我們要考慮什麼時候開始測試，預計要測試多久？以便和開發計畫、上線計畫銜接。
發布標準發布標準是測試完成和產品上線需要滿足的條件，以便專案內所有角色都有一致認可的目標。怎樣才算是測完了？達到怎樣的標準才可以上線？
風險預防最後，我們需要對整個測試過程中可能存在的風險，以及當這些風險發生時的應對措施提前進行一些考慮和準備，並在測試計畫中體現出來
測試範圍的確定**於需求文件
1 引言
1.1 編寫目的
根據專案需求文件，提煉測試功能點、制定測試策略、評估測試風險、預估編寫測試用例、執行功能測試和回歸測試的工作量，進行進度、人員安排
1.2 預期讀者
專案經理、產品、開發、測試
1.3 參考資料
需求稿.doc 需求分析
2 測試範圍
x專案功能模組：瀏覽課程、參加課程、學習課程；
根據產品應用場景和架構設計，還需要做效能測試和相容性測試
測試型別：功能測試、相容性測試、效能測試、介面測試、安全性測試
將需要用到的測試型別按測試場景、測試方法等以引用檔案的形式填寫到測試計畫中去。以便讓所有專案人員清楚的知道要做哪些測試工作以及怎麼做
3 測試策略
對需求中的功能改進進行完整測試，並根據應用場景和併發數考慮相容性和效能測試方案
3.1 功能測試策略
具體見 xx專案測試用例
3.2 系統相容性測試
1 瀏覽器：ie10/chrome/firfox下進行完整測試
2 在 ios9 ios8/iphone6s/iphone5s 上進行測試
3 在android 5.0 4.4系統上進行完成的測試，手機選取市場點有率高的三星、華為、小公尺等 ，解析度覆蓋800*480、1280*720
3.3 效能測試
1 登入模組，大批使用者用時登入，伺服器負載情況，頁面響應速度
2 參加課程模組，大批量使用者同時參加乙個課程，或者同時參加多個課程，伺服器負載和響應速度。
測試資源一般包括兩方面：測試人力資源和測試環境資源。
測試人力資源包含2個維度：測試人員數量和測試人員經驗、能力。
環境資源：測試伺服器環境
與線上伺服器的差異
終端測試環境
pc的配置
手機的型號
測試工具
bug管理工具
用例管理工具
效能測試工具
在測試計畫中，測試人員分配、測試環境資源、網路資源、工具使用都要明確寫出來
4 測試資源
4.1 測試人員
測試負責人 ：，團隊成員：
4.2 測試環境
1 伺服器環境： 試服、線上服
2 終端環境：pc：win10 ie10 chrome
iphone手機：iphone5s
android手機：紅公尺、華為
3 網路環境：辦公網路環境：移動4g、電信4g
4.3 bug管理工具
在測試過程發現缺陷後使用禪道進行記錄，提交記錄時應清晰、準確的描述缺陷發生的條件 步驟，並設定缺陷嚴重重等級，導致程式崩潰的缺陷設為 1級，嚴重影響程式執行或阻礙使用的設為 2級，對使用者使用造成一定影響的缺陷設為 3 級。可用性或改進意見設為 4 級
5 進度安排
測試工作進度安排依賴於開發工作的節點和提交測試進度的時間，並且直接影響預期上線時間。
需要根據業務複雜度、測試型別的複雜度、產品上線的質量要求的高低、測試人員的數量、能力和經驗這些因素，來評估不同階段、不同型別的測試工作的工作量。然後對測試人員的分工進行安排，明確職責。最終來預估測試工作開始和結束的時間節點。
列明測試過賬中需要輸出的文件。
專案的里程碑：開發節點、提測節點、上線節點
評估因素：業務複雜度、測試複雜度、產品質量要求、人員數量能力
進度安排：評估工作量、分配人力、預估時間
輸出文件：測試計畫、測試用例、bug資料、測試報告
5.1 測試進度及工作量估算 ：任務、時間、執行人員、預期工作量
6 發布標準
這個標準包含2個方面：一是測試工作完成的標準，二是產品可以上線發布的標準
測試完成標準：1 測試計畫裡所有測試型別都已經完成了
2 功能上、相容性上沒有影響使用者使用的bug
3 允許遺留小部分影響不是很大的bug，但這個數量應該小於乙個值
4 效能上符合設計目標和上線要求 這些標準都是針對測試工作本身的要求
產品發布標準：1 產品需求都已完成
2 互動視覺走查都已完成
3 小部分bug專案組完成了風險評估 都認為且問題不大
4 產品使用說明或使用者手冊或更新log都已完備等
6.1 測試完成標準
1 沒在影響使用者正常傅的缺陷
2 完成測試內容中的功能測試/系統相容性測試和服務端效能測試
3 未修改的缺陷不超過10個
6.2 產品發布標準：
1 已按需求文件實現需求
2 符合互動設計規範/符合視覺要求/通過設計評審
3 允許遺留可能會對使用者正常使用造成一定影響的缺陷，但在發布前告知專案組，並經風險評估一至同意發布後可發布
7 風險說明
一是測試範圍的風險：需求不準確 不到位漏了測試點，甚至某個測試型別遺漏了。這是產品需求變更的風險，加需求/減需求/改需求都需要重新進行測試/分析，需要測的要測到，不需要測試的不浪費人力工作量
二是測試進度的風險：工作量估計不准/開發沒有按時或改缺陷不及時，測試人員請假/變動
三是產品質量風險：**質量低/不熟悉業務/能力經驗有限
測試範圍風險;測試遺漏、需求變更
測試進度風險：工作量預估不準確
合作任務延遲
測試 人員變動
產品質量風險：**質量
測試 人員能力
平台測試小記
從6月初著手開發始，整個專案進行了3個月有餘。現在最大的感受是，辛苦，長時間阻塞在乙個懸而未決的問題沖淡了之前所有進展甚至是飛躍帶來的喜悅。在這個依舊阻塞的晚上，問題稍有眉目，3人經協商，決定給明天留點希望，於是得以喘息，來此記錄一下。前瞻性專案意味著你可以放開手腳，同時也意味著會遇到各類未曾出現的...
測試計畫編寫
1.文件的要求 好的模板是經驗和智慧型的積累，是團隊的財富。它可以將乙個團隊中最好的工作方法迅速傳播給每個成員。從而使整個團隊的戰鬥力增強。大企業不惜重金引入 模板 例如，聯想。2.微軟實踐 從做好需求開始 要像法律條文一樣。剛性不強的法律執行起來難度很大，容易偏差。3.軟體測試計畫的目標 計畫先行...
軟體測試計畫
1.測試計畫是什麼？是在軟體測試工作正式實施之前明確測試的物件，並且通過對資源 時間 風險 測試範圍和預算等方面的綜合分析和規劃，保證有效的實時軟體測試。2.為什麼要制定測試計畫？1 對專案執行過程過程中的風險進行分析，並制定相關的應對策略 2 把知識和經驗轉化為執行任務的具體方法 3 促進團隊間關...