测试计划报告.docx
- 文档编号:23132112
- 上传时间:2023-05-08
- 格式:DOCX
- 页数:17
- 大小:21.92KB
测试计划报告.docx
《测试计划报告.docx》由会员分享,可在线阅读,更多相关《测试计划报告.docx(17页珍藏版)》请在冰豆网上搜索。
测试计划报告
七、测试计划
1.引言1
1.1编写目的1
1.2项目背景2
1.3定义2
1.4参考资料2
2.任务概述2
2.1目标2
2.2运行环境2
2.3需求概述2
2.4条件与限制2
3.计划3
3.1测试方案3
3.2测试项目3
3.3测试准备3
3.4测试机构及人员3
4.测试项目说明3
4.1测试项目名称及测试内容3
4.2测试用例3
4.3进度3
4.4条件3
4.5测试资料3
5.评价3
5.1范围3
5.2准则3
1.引言
1.1编写目的
该文档的目的是,火车票售票管理系统的系统测试设计,其主要内容包括:
●测试总体设计
●测试用例设计
本文档的预期的读者是:
●项目管理人员
●测试人员
1.2项目背景
a.待开发系统的名称:
火车票售票管理系统
b.项目的任务项目任务提出者:
天津科技大学
开发者:
天津科技大学计算机学院08101132薛姣
08101332王倩
08101333于漫
将运行该项软件的单位:
天津铁路局
用户:
火车站售票管理人员和购票旅客。
1.3定义
1、MySQL:
系统服务器所使用的数据库管理系统(DBMS)。
2、SQL:
一种用于访问查询数据库的语言
3、事务流:
数据进入模块后可能有多种路径进行处理。
4、主键:
数据库表中的关键域。
值互不相同。
5、外部主键:
数据库表中与其他表主键关联的域。
6、ROLLBACK:
数据库的错误恢复机制。
7、SQL:
StructuredQueryLanguage(结构化查询语言)。
1.4参考资料
1、《软件工程》(第二版)张海藩北京人民邮电出版社2006.
2、RogerS.Pressman.SoftwareEngineering---APractioner’sApproach,FourthEdition
北京,机械工业出版社,1999.
3、《软件开发指南》何培民北京清华大学出版社1991.
4、《使用软件工程》郑人杰北京清华大学出版社1991.
5、《需求分析》(美)DavidC.Hay孙学涛赵凯朱建东译清华大学出版社1991.
6、JacksonMA.PrinciplesofProgramDesign.OxfordAcademicPress1975.
7、《概要设计说明书》.
2.任务概述
2.1目标
登陆测试:
前台用户登陆系统安全管理模块,用户输入用户名和密码,模块通过连接到数据库查找用户信息进行检验。
火车信息录入测试:
录入车次信息
火车票信息查询测试:
输入终点站或车次信息,查询相关火车的信息
火车票退票测试:
售票人员输入相关火车票删除信息,删除此火车票
火车票信息修改测试:
售票人员对相应的火车票信息进行修改,此火车票票务信息得到修改。
2.2运行环境
a硬件环境:
●客户机:
普通PC
⏹CPU:
P41.8GHz
⏹内存:
256MB以上
⏹分辨率:
推荐使用1024*768像素
●数据库服务器
⏹CPU:
P41.8GHz
⏹内存:
256MB以上
b软件环境:
●操作系统:
Windows2000
●数据库:
SQLServer2000
●开发工具包:
JDKVersion1.4.2
●JSP服务器:
Tomcat
●浏览器:
IE6.0
2.3需求概述
2.3.1输入输出项目
1.售票人员账号、密码均为char型。
2.火车票车次、始发站、终点站为char型,票价为float型数据,数值范围(0到1000.00)
2.3.2该软件的时间特性要求:
a.响应时间为1秒;
b.更新处理时间5分钟以内;
c.数据的转换和传送时间3分钟以内;
2.3.3其他需求
a.进行系统概要设计的时间不超过2星期;
b.运行环境建议在火车站专业计算机系统下;
c.可调查利用用目前和铁路局和其他部门的信息建造系统。
2.4条件与限制
一个更完善的火车票售票系统,应提供更为便捷与强大的查询购买功能,如相应的网络操作及服务,由于开发时间和计算机数量有限,该系统并未提供这一功能,对于信息的保护手段仅限制于设置用户级别,以记名提供数据文件的备份,比较简单,不能防止恶意的破坏,安全性能有待进一步完善。
3.计划
3.1测试方案
说明确定测试方法和选取测试用例的原则
测试工件为四个阶段:
单元测试、组装测试、确认测试、系统测试
a.单元测试:
采用白盒法和黑盒法相结合的方法,对于逻辑结构复杂的模块采用白盒法,对于以输入、输出为主的模块采用黑盒法测试,以提高测试的效率。
b.组装测试:
混合法(对软件结构中较上层使用的自顶向下与对软件结构中较下层使用的自底向上方法相结合)。
c.确认测试:
由用户参与按需求规格说明书验收。
d.系统测试:
采用人工测试方法。
3.2测试项目
在测试过程中,首先需要对各子单元过程进行测试。
在各子单元过程测试完毕后,再对各模块(包括各子单元过程之间的接口)进行测试,处理好各模块之间的接口,最后对系统进行测试和维护。
各模块包括:
身分验证功能测试
查询功能测试
修改功能测试
删除功能测试
系统测试
3.3测试准备
在测试前,与各模块的主要负责人共同协商讨论,以概要设计说明书.详细设计说明书作为总的提纲,选择合适的输入输出数据,并加以意义列举说明。
3.4测试机构及人员
a.测试人员:
负责编写测试计划,组织测试,对测试过程进行记录,收集、整理测试记录数据,对测试结果进行分析,编写测试总结报告。
即测试组全体人员共计3人。
b.软件工程师:
负责编写、调试客户端测试软件;数据库管理系统的安装
c.系统工程师:
负责测试用的硬件维护及操作系统安装、CEWMS配置。
d.总工程师:
负责对测试计划及测试总结报告进行批准。
e.用户:
必要时可参加测试,并提出具体的测试要求,也可要求暂停测试。
f.测试机构:
天津科技大学计算机学院
4.测试项目说明
4.1测试项目名称及测试内容
a.登陆、密码模块测试
本测试是采用黑盒测试法:
为了检测不同权限的用户在登陆时,是否能进入对应的模块并得到应有的权限,检验密码模块的正确有效性。
b.火车票售票管理测试
本测试采用白盒测试法:
主要内容是插入商品信息的测试。
在测试过程中,首先需要对各子单元过程进行测试。
在各子单元过程测试完毕后,再对各模块(包括各子单元过程之间的接口)进行测试,处理好各模块之间的接口,最后对系统进行测试和维护。
各子模块测试名称如下:
身分验证功能测试
查询功能测试
修改功能测试
删除功能测试
添加功能测试
4.2测试用例
4.2.1输入
4.2.2输出
输入输出详见各测试用例
表A-1:
TestCase-FUNC-01测试用例
测试项目名称:
火车票售票管理系统
测试用例编号:
TestCase-FUNC-01
测试人员:
薛姣
王倩
于漫
测试时间:
2010-12
测试项目标题:
身份验证功能测试
测试内容:
验证身份验证功能正常
测试环境与系统配置:
详见《测试计划》
测试输入数据
1.happy
2.空
3.其他
测试次数:
每个测试过程做2次。
预期结果:
可以正确验证身份
测试过程:
按提示输入以下三种数据:
1.Happy
2.空
3.其他
测试结果:
1.进入管理员界面
2.输出登陆信息错误
3.转到普通界面
测试结论:
身份验证功能正常
实现限制:
备注:
表A-2:
TestCase-FUNC-02测试用例
测试项目名称:
火车票售票管理系统
测试用例编号:
TestCase-FUNC-02
测试人员:
薛姣
王倩
于漫
测试时间:
2010-12
测试项目标题:
添加功能测试
测试内容:
添加功能正常
测试环境与系统配置:
详见《测试计划》
测试输入数据
122:
00天津杭州18.02000150140
27:
45北京上海20.0107056880
测试次数:
每个测试过程做2次。
预期结果:
可以正确添加信息
测试过程:
按提示输入数据
测试结果:
能正常添加数据
测试结论:
添加功能正常
实现限制:
备注:
表A-3:
TestCase-FUNC-03测试用例
测试项目名称:
火车票售票管理系统
测试用例编号:
TestCase-FUNC-03
测试人员:
薛姣
王倩
于漫
测试时间:
2010-12
测试项目标题:
查询功能测试
测试内容:
查询功能正常
测试环境与系统配置:
详见《测试计划》
测试输入数据
3
北京
90
测试次数:
每个测试过程做3次。
预期结果:
可以正确执行查询
测试过程:
按提示输入以下两组数据:
1.3
2.北京
3.90
测试结果:
输出对应信息
1.显示车次、发车时间、起始站、终点站、里程、额定载量、已售票数、票价
2.显示车次、发车时间、起始站、终点站、里程、额定载量、已售票数、票价
3.查无此列车
测试结论:
查询功能正常
实现限制:
备注:
表A-4:
TestCase-FUNC-04试用例
测试项目名称:
火车票售票管理系统
测试用例编号:
TestCase-FUNC-04
测试人员:
薛姣
王倩
于漫
测试时间:
2010-12
测试项目标题:
修改功能测试
测试内容:
修改功能正常
测试环境与系统配置:
详见《测试计划》
测试输入数据
1.22:
00天津杭州18.02000150140
2.78
测试次数:
每个测试过程做2次。
预期结果:
可以正确修改信息
测试过程:
按提示输入以下两组数据:
22:
00天津杭州18.02000150140
78
测试结果:
1.正确修改信息
2.输出查无此列车
测试结论:
修改功能正常
实现限制:
备注:
表A-5:
TestCase-FUNC-05试用例
测试项目名称:
火车票售票管理系统
测试用例编号:
TestCase-FUNC-05
测试人员:
薛姣
王倩
于漫
测试时间:
2010-12
测试项目标题:
删除功能测试
测试内容:
删除功能正常
测试环境与系统配置:
详见《测试计划》
测试输入数据
1.8
2.900
测试次数:
每个测试过程做2次。
预期结果:
可以正确删除信息
测试过程:
按提示输入以下两组数据:
1.8
2.900
测试结果:
1.输出此列车信息已删除
2.输出查无此列车
测试结论:
删除功能正常
实现限制:
备注:
表A-6:
TestCase-FUNC-06试用例
测试项目名称:
火车票售票管理系统
测试用例编号:
TestCase-FUNC-06
测试人员:
薛姣
王倩
于漫
测试时间:
2010-12
测试项目标题:
系统功能测试
测试内容:
系统正常
测试环境与系统配置:
详见《测试计划》
测试输入数据
测试次数:
每个测试过程做2次。
预期结果:
系统正常
测试过程:
进入系统,正确显示menu信息,选择各个子功能,均能自由进出入,系统稳定正常
测试结果:
系统正常,各子功能连接正常,系统稳定
测试结论:
系统正常
实现限制:
备注:
4.2.3步骤及操作
在测试过程中,首先需要对各子单元过程进行测试。
各子单元过程的测试必须先在程序设计员调试并编译通过后才能进行。
在各子单元过程测试完毕后,再对各模块(包括各子单元过程之间的接口)进行测试,处理好各模块之间的接口,最后对系统进行测试和维护。
其操作过程如下:
1.在客户机接受信息模块过程中,先对各子单元过程分别进行测试,然后根据白盒法按照详细设计说明书中的流程图对其进行跟踪测试。
2.同样,在客户机输出信息模块.网络接受和发送模块结构和服务器模块(包括数据库)过程中先对各子单元过程分别进行测试,然后根据白盒法按照详细设计说明书中的流程图对其进行跟踪测试。
,
3.然后,根据各模块之间的各种关系,对其接口进行测试。
4.在系统测试中,要注意对各种意外情况(列如断电.硬盘损坏等)加以处理,对数据库要注意其安全性.可靠性.健壮性.效率。
网络传输更要注意其安全性。
4.2.4允许偏差
输入的数据允许偏差在0.005~0.01之间
4.3进度
需要对各子单元程序.各模块及它们之间的接口分别进行测试进度.一般测试过程都伴随其概要设计.详细设计过程一起进行。
表B-1是测试进度的计划与实际结果比较。
从度量数据看实际进度与计划基本相符。
表B-1:
测试进度的度量数据
任务
计划开始
计划结束
实际开始
实际结束
测试计划与设计
2010-6
2011-2
2010-11
2010-12
测试执行
2011-1
2011-1
2010-12
2010-12
测试总结
2011-2
2011-2
2010-12
2010-12
表B-2是实际测试工作量的数据,与计划基本相符。
表B-2:
测试工作量度量
执行任务
开始时间
结束时间
工作量
(人时)
测试计划与设计
2010-11
2010-12
12×3人时
测试执行
2010-12
2010-12
10×3人时
测试总结
2010-12
2010-12
6×3人时
4.4条件
必须在保证各硬件设备.软件系统齐备的情况下,资金充足,人员齐备,各方面互相配合,齐心协力,共同完成。
a硬件环境:
●客户机:
普通PC
⏹CPU:
P41.8GHz
⏹内存:
256MB以上
⏹分辨率:
推荐使用1024*768像素
●数据库服务器
⏹CPU:
P41.8GHz
⏹内存:
256MB以上
输入及输出设备:
需要打印机,型号不限
b软件环境:
●操作系统:
Windows2000
●数据库:
SQLServer2000
●开发工具包:
JDKVersion1.4.2
●浏览器:
IE6.0
C人员:
测试组全体成员,理解测试基本知识
4.5测试资料
售票人员信息、火车票信息、票务信息。
1、《软件工程》(第二版)张海藩北京人民邮电出版社2006.
2、RogerS.Pressman.SoftwareEngineering---APractioner’sApproach,FourthEdition
北京,机械工业出版社,1999.
3、《软件开发指南》何培民北京清华大学出版社1991.
4、《使用软件工程》郑人杰北京清华大学出版社1991.
5.评价
5.1范围
在用户使用时,对输入数据的不符合以及错误的格式输入都能做出测试,对价格进行调整时,对输入的不符合数据以及错误格式能做出测试,增加票务信息时也能做出正常的测试,但是当输入的数据过大或者字符长度过长时,可能会使程序发生中断而停止执行。
5.2准则
测试中发现的缺陷按照严重程度分为4个级别,如表C-1,级别不同,严重程度也不同。
表C-1:
缺陷严重级别
严重级别
严重程度
1-提示(Low)
•微小的错误,不会影响系统的功能
•不准确或容易误解的行为和语句
2-一般(Medium)
•该问题增加了测试或用户操作的复杂度
•该问题轻微降低了系统的性能,但系统仍然能工作
3-严重(High)
•该问题会严重降低系统的性能
•不符合客户端需求说明
4-致命(VeryHigh)
•系统不能正常启动或启动后无法正常工作
测试完成的标准是执行完所有系统测试的功能、性能测试用例,无2级以上遗留问题。
如果进行系统测试时,存在严重的质量问题,导致无法继续,并且在可接受的时间范围内无法修复,系统测试终止。
此次测试后系统运行基本正常,该软件已基本可投入使用。
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 测试 计划 报告
![提示](https://static.bdocx.com/images/bang_tan.gif)