测试计划如何编写
作為一個想成為leader(不論是整個測試部門還是小項目組的leader)的人,測試計劃編寫是必備技能。
言歸正傳,直入主題。測試計劃具體包含的內容包括以下:
1、概述?
1.1?項目標識
項目編號 | 項目名稱 | ||
項目類別 | ■新建類 ?□升級類 | 合作供應商 |
?
1.2 目的?
1.2.1 根據需求列表確認現有功能,保證軟件質量
1.2.2 驗證軟件的一致性、穩定性、兼容性、安全性、可靠性、有效性、功能性
1.2.3 通過分析以前項目的測試狀態,預估該項目的測試狀態,確保軟件測試的有效性
1.2.4 分析漏測原因,提前做好解決方案,降低風險
1.2.5 分析每個階段計劃的有效性并且及時更新,保證各階段測試的質量
1.2.6 根據計劃,及時對文檔、測試用例進行評審,保證文檔的正確性和測試用例的有效性、可執行性 1.2.7 根據計劃,及時對文檔、測試用例進行評審,保證文檔的正確性和測試用例的有效性、可執行性 1.2.8 保證測試報告的交付時間
1.2.9 提前計劃所需測試資源,確保測試工作的正常進行
1.2.10 明確缺陷級別定義,規范提交缺陷模板,以便及時解決缺陷
1.2.11 組織結構圖說明每個角色的具體任務,在實際工作中起指導作用
?1.2.12 針對各種測試類型的測試目的來判斷測試的有效性
1.3 范圍
[描述測試的各個階段(例如集成測試和系統測試),并說明本計劃所針對的測試類型(如功能測試或性能測試)。 簡要地列出測試對象中將接受測試或將不接受測試的那些性能和功能。
如果在編寫此文檔的過程中做出的某些假設可能會影響測試設計、開發或實施,則列出所有這些假設。?列出可能會影響測試設計、開發或實施的所有風險或意外事件。
列出可能會影響測試設計、開發或實施的所有約束。
1.4 參考資料
主要參考項目總體計劃、需求規格說明書
?
2、組織結構
人員角色 | 姓名 | 單位 | 職責 | 移動電話 | 電子郵件 | 備注 |
項目經理 | ||||||
測試經理 | ||||||
測試組組長 | ||||||
測試組成員 | ||||||
?
3、測試資源需求
測試過程中,根據項目各階段需根據項目的情況進行資源調整。
3.1 人力資源需求
角色 | 地點 | 數量 | 所需知識技能 | 期望到位時間 | 計劃釋放時間 | 是否需要培訓 | 備注 |
?
3.2 辦公位需求
類型 | 地點 | 數量 | 期望到位時間 | 計劃釋放時間 | 備注 |
辦公座位 | |||||
辦公網絡 | |||||
開發測試網絡 | |||||
其它 |
?
3.3 測試環境
測試環境類型 | 主機 | 存儲 | 網絡 | 外圍設備 | 操作系統軟件 | 數據庫 | 中間件 | 系統配置參數 | 測試用業務數據 |
web服務器 | |||||||||
?
3.4 其它軟件/系統
類型 | 型號 | 數量 | 備注 |
測試工具 | |||
缺陷跟蹤工具 | |||
測試案例管理工具 | |||
瀏覽器 | |||
關聯系統 | |||
其它 |
?
4、測試范圍
xxx項目功能列表
?一級菜單 | 二級 | 三級 | 研發負責人 | 測試案例設計人 | 優先級 |
?
5、測試目標
5.1 測試目標
類別 | 目標 |
進度目標 | 系統測試完成日期: |
性能測試工作完成日期: | |
性能指標 | |
執行目標 | 缺陷清除率:100% |
測試用例覆蓋率:100% | |
測試用例通過率:100% | |
文檔質量目標 | 交付文檔: |
\ |
?
5.2 測試類型
序號 | 測試類型 | 子測試項 | 測試目的 | 是否采用 | 備注 |
1 | 功能性測試 | 根據系統需求文檔和設計文檔,檢查產品是否正確實現了功能 | |||
3 | 用戶界面 (UI) 測試 | 檢查界面是否美觀合理 | |||
4 | 兼容性測試 | 在不同瀏覽器上能正常運行 | |||
5 | 流程測試 | 按操作流程進行的測試,主要有業務流程、數據流程、邏輯流程、正反流程, | |||
6 | 回歸測試 | 檢查程序修改后有沒有引起新的錯誤、是否能夠正常工作以及能否滿足系統的需求 | |||
7 | 性能測試 | 提取系統性能數據,檢查系統是否 | |||
8 | 接口測試 | 檢查系統能否與外部接口正常工作 | |||
9 | 安全性和訪問控制測試 | 應用程序級別的安全性:檢查用戶只能訪問其所屬用戶類型已被授權訪問的那些功能或數據。 |
?
6、測試里程碑
序號 | 測試階段 | 任務描述 | 責任人 | 階段目標 | 計劃開始時間 | 計劃結束時間 |
1 | 制定測試計劃 | 識別需求功能,預估工作量 | 工作量預估完成 | |||
2 | 系統測試案例 | 測試需求分解 | 測試案例編寫完成 | |||
3 | 系統測試 | 驗證系統軟件是否與需求相符,執行業務流程通順 | 模塊集成后的系統業務流程正確 | |||
4 | 性能測試 | 驗證系統集成后,軟件是否符合各項性能指標 | 軟件在模擬真實環境的條件下各項性能達到需求指標 | |||
5 | 業務驗收測試 | 根據業務需求和《業務需求功能規格說明書》/《業務需求功能說明單》編寫測試案例,測試是否實現所有功能 | 業務測試小組完成測試工作(測試案例編寫、記錄發現的缺陷、復測缺陷、完成測試記錄和測試報告) | |||
6 | 文檔編寫 | 記錄測試記錄、完成測試報告、對測試案例進行維護 | 完成測試報告及相關文檔整理,測試案例更新歸檔 |
?
7、測試進度安排
開始時間: | |||
任務名稱 | 負責人 | 開始時間 | 完成時間 |
1.制定測試計劃 | |||
編寫測試方案與計劃 | |||
2.測試案例設計 | |||
3.集成/系統/驗收測試 | |||
第一階段測試 | |||
第二階段測試 | |||
第三階段測試 | |||
4.性能測試 | |||
5.文檔編寫 | |||
?
?
8、風險評估
風險描述 | 影響程度 | 應對措施 | 責任人 |
測試目標不清晰或不夠明確 | 嚴重 | 明確測試目標 | |
測試時間有限 | 嚴重 | 推遲上線或加班 | |
測試人員的不足 | 嚴重 | ||
代碼編寫的質量 | 嚴重 | ||
缺陷修改進度 | 嚴重 | ||
回歸測試不充分(一般不運行全部測試用例,是有選擇性的執行) | 一般 | ||
案例功能點覆蓋率未達到100% | 一般 | ||
測試案例不能100%執行 | 一般 | ||
開發計劃變更 | 嚴重 | ||
需求的變更 | 嚴重 |
?
9、交付物
序號 | 交付物 | 提交時間 |
1 | 測試計劃 | |
2 | 測試方案 | |
3 | 系統測試記錄 | |
4 | 系統測試報告 | |
5 | 性能測試用例 | |
6 | 性能測試報告 | |
7 | 缺陷 |
?
10、缺陷級別標準
描述需求階段與客戶確定的缺陷等級定義;
缺陷 級別 | 描述 |
一級 | 致命問題 |
1. 程序運行過程中不斷申請,但沒有完全釋放資源,造成系統性能越來越低,并出現無規律的死機現象。 | |
二級 | 嚴重問題 |
1. 因錯誤操作導致的程序中斷。 | |
三級 | 一般問題 |
1. 操作界面錯誤。(包括數據窗口內列名定義、含義是否一致,界面中英文混雜,界面元素參差不齊,文字顯示不全) | |
四級 | 改進建議 |
1. 輔助說明描述不清楚。 |
?
?
11、培訓計劃
序號 | 分類 | 培訓內容 | 培訓日期 | 培訓人 | 參加人 | 備注 |
1 | 業務培訓 | 詳見培訓計劃 | ||||
2 | 技能培訓 | |||||
3 | 工具培訓 |
?
12、相關軟件
在測試過程中將使用到以下軟件?
1 .缺陷跟蹤工具
管理bug并跟蹤bug狀態:禪道
2 .用例與文檔管理工具
管理項目文檔和需求:SVN
?
以上就是測試計劃中包含的所有內容,如果公司沒有模板的話,直接按照這個來寫吧,no趴笨~
總結
- 上一篇: C++知识点打结(一)
- 下一篇: Finance_finacial_eng