测试计划实例

测试计划实例

 

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 硬盘：250G 网络：局域网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》

 

posted @ 2019-04-08 18:33 爱穿衬衫 阅读( ...) 评论( ...) 编辑 收藏