测试计划实例
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》
