测试计划具体包含的内容包括以下:
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
以上就是测试计划中包含的所有内容