测试计划实例
xx系统
测试计划
文件版本:V1.0
目 录
1 引言. 1
1.1 编写目的. 1
1.2 预期读者. 1
1.3 参考资料. 1
1.4 项目概述. 1
1.5 参考资料. 2
1.6 业务流程图. 3
2 测试策略. 5
2.1 开始标准. 5
2.2 中止标准. 5
2.3 完成标准(第一轮交付). 5
3 项目参与人员. 6
4 测试环境. 6
4.1 硬件环境(待补充及修改). 6
4.2 软件环境. 7
5 测试进度计划. 7
6 风险分析. 9
6.1 测试人员资源不足:. 9
6.2 测试不够全面:. 9
6.3 需求变更导致工作量变动:. 9
6.4 开发提交测试版本比该计划延迟:. 9
6.5 提交测试版本质量较低:. 10
6.6 代码版本管理混乱:. 10
6.7 应对方案:. 10
7 输出文档. 10
文件修改记录
修改日期 |
版本号 |
修改内容 |
修改人 |
审核人 |
批准人/日期 |
2019-04-04 |
V1.0 |
创建 |
xxx |
|
|
2019-04-08 |
V1.1 |
新增风险分析内容,输出文档,业务流程图;补充测试环境内容。 |
|
|
|
|
|
|
|
|
|
1 引言
1.1 编写目的
本文档为xx系统测试计划,用来规划2019年4月4日至4月30日的测试任务,阐述该项目测试资源配置、进度控制、测试目标确认以及其他测试管理活动。
1.2 预期读者
xx项目项目经理,产品,开发,测试
1.3 参考资料
《xx原型v1.0》
1.4 项目概述
项目背景描述
1.5 参考资料
xx原型
1.6 业务流程图
2 测试策略
1、 采用手工测试。
2、 测试管理工具选用X-mind思维导图单,bug跟踪工具选用禅道。Bug级别分类:1级-导致程序崩溃的缺陷;2级-严重影响程序云关系或者严重阻碍用户使用的缺陷;3级-对用户使用造成一定影响的缺陷;4-可用性问题或改进意见。
3、 主要为基本业务流程测试、功能测试,基本的界面测试。
1)测试目标:验证软件提供的功能是否都可以实现,业务流程能走通
2)测试方法和技术:检验在输入正确数据时结果能否与设计期望相符合,检验在输入错误数据时软件能否报警并正常运行
3)完成标准:所有的功能都通过测试,且达到目标
2.1 开始标准
测试环境搭建完成。
测试相关人员准备就绪。
现场测试环境达到可测要求。
2.2 中止标准
1、测试中出现一级缺陷较多。
2、测试环境不稳定。
3、客户需求变更。
2.3 完成标准(第一轮交付)
1、测试需求覆盖率达到100%
2、业务基本主流程及主要功能测试通过
3、系统死锁、系统崩溃、严重错误不能多于1个
4、次要错误不能多于2个
5、不合理或者别扭,文字错误,微不足道错误不能多于10个
6、以上错误均不能出现影响用户使用的Bug
3 项目参与人员
职务 |
姓名 |
产品 |
xxx |
UI |
xxx |
后端 |
xxx |
前端 |
xxx |
测试部 |
xxx |
4 测试环境
4.1 硬件环境(待补充及修改)
资源名称 |
资源项 |
描述 |
浏览器测试 PC |
操作系统 |
Windows 10(共1台) |
硬件配置 |
CPU:酷睿双核 P8600 内存:8G 网络:局域网100M
|
4.2 软件环境
资源名称 |
资源项 |
描述 |
测试应用服务器 |
操作系统 |
|
应用服务器 |
Tomcat5.6 |
|
数据库服务器 |
操作系统 |
|
数据库版本 |
Mysql |
|
浏览器端 |
操作系统 |
Windows 10 |
浏览器 |
Google Chrome版本 67.0.3396.87 |
|
Flash版本 |
10.0 |
|
|
Office |
2010,2016 |
pc适配的系统、浏览器、分辨率(待补充)
系统:Windows10操作系统,版本因素暂时不考虑
浏览器:基本业务流程在chrome和360浏览器极速模式测试。
分辨率:此次测试暂时不考虑这个因素
移动端适配的手机:
1,iphone6,ios12。0 ;
2,荣耀9i,android 8
5 测试进度计划
测试范围
测试人员:xxx
日期(2019 年) |
规划 |
系统 |
测试内容(模块) |
备注 |
4月8日至4月19日 |
测试用例编写 |
xx前端(pc端,移动端),后台管理设置 |
xx前端(pc端,移动端),后台管理设置; |
移动端原型尚未出来 |
4月22日 |
第一轮测试 |
xx前端(pc端,移动端),后台管理设置 |
覆盖基本业务流程 |
流程走通后才能进行第一轮测试 |
4月26日 |
第二轮测试 |
xx前端(pc端,移动端),后台管理设置 |
回归之前的bug |
|
4月30日 |
上线测试 |
|
禅道上提的Bug回归,及回归测试 |
早上需要开发改完前2天的Bug,下午发布一个版本 |
6 风险分析
6.1 测试人员资源不足:
本项目前台有pc端和移动端,还有pc端后台设置系统,都需要在7个工作日测试两轮,即使加班时间也比较紧张。
6.2 测试不够全面:
考虑项目时间进度,主要为基本业务流程测试、及功能测试,其它方面测试(如性能、安全、兼容性等)暂时不考虑,存在一定的风险。
6.3 需求变更导致工作量变动:
上述工作了预估中对需求变更进行了一定的风险覆盖,如需求变更超出目前预计,可能导致编写测试用例及执行测试相关工作量增加;
6.4 开发提交测试版本比该计划延迟:
发生此种情况时,执行测试的时间应合理顺延;
6.5 提交测试版本质量较低:
可能导致比该计划更多轮次回归测试;
6.6 代码版本管理混乱:
,将只选取一个稳定版本进行测试,不考虑中间版本的反复测试。一轮测试完成后,再进行下一稳定版本的回归测试。
6.7 应对方案:
1,需求原型阶段多评审,尽量把问题解决在需求端;
2,后端接口开发完成与前端联调阶段进行接口测试;
3,通过招聘引进人员来解决。
7 输出文档
测试输出文档:《xx测试计划v1.0》,《xxx测试用例v1.0》,《xxx测试报告v1.0》