包裹追踪测试分析报告.docx
《包裹追踪测试分析报告.docx》由会员分享,可在线阅读,更多相关《包裹追踪测试分析报告.docx(14页珍藏版)》请在冰豆网上搜索。
包裹追踪测试分析报告
包裹追踪系统
测
试
分
析
报
告
测试分析报告
1引言1
1.1编写目的1
1.2背景1
1.3定义2
1.4参考资料2
2测试概要2
3测试结果及发现2
3.1测试1(标识符)2
3.2测试2(标识符)2
4对软件功能的结论2
4.1功能1(标识符)2
4.1.1能力2
4.1.2限制3
4.2功能2(标识符)3
5分析摘要3
5.1能力3
5.2缺陷和限制3
5.3建议3
5.4评价3
6测试资源消耗4
1引言
1.1编写目的
目的:
a、测试包裹追踪软件的性能,看软件是否运行正常,是否会出现死机、异常退出、功能模块无法运行等异常状况,是否能够满足客户的所有要求。
b、测试包裹追踪软件是否能够按照《用户操作手册》顺利完成所有功能,并给出正确的结果。
c、测试包裹追踪软件的性能,如系统的响应性能、长时间运行后的性能状态等是否满足设计的要求。
d、测试包裹追踪软件是否设计的足够及关系周到,是否能够包含任何可能出现的情
况。
e、测试包裹追踪软件界面设计是否友好,布局是否美观,操作是否简单无歧义。
f、测试包裹追踪软件是否有逻辑错误,或不符合实际情况的设计。
预期的阅读范围:
软件开发小组成员及测试小组成员。
1.2背景
说明:
a.待开发的软件系统的名称:
包裹查询追踪系统;
b.本项目的任务提出者:
XXX快递公司;
c.开发者:
刘XX、胡XX、薛XX、赵XX;
d.用户:
XXX快递公司的员工及其客户;
e.实现该软件的计算中心:
软件学院机房;
1.3定义
软件:
包裹追踪软件;
1.4参考资料
a.《软件工程导论》 (第五版) ,张海藩编著,清华大学出版社,2008 年 2 月 ;
b.《软件测试:
第二版》 Paul C.Jorgensen著/机械工业出版社;
c.项目开发计划书,
d.需求规格说明书 ,
e.概要详细设计说明书;
f.测试计划书。
2测试概要
用表格的形式列出每一项测试的标识符及其测试内容,并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别,说明作出这种改变的原因。
3测试结果及发现
3.1测试
把本项测试中实际得到的动态输出(包括内部生成数据输出)结果同对于动态输出的要求进行比较,陈述其中的各项发现。
用户类型选择:
(选择管理员用户类型,输入“1”)
测试正常
进入管理员系统:
(输入密码:
11111)
测试正常
密码输入错误:
测试正常
修改包裹信息:
(先输入包裹号,再选择修改包裹信息(输入“1”))
测试正常
添加包裹新增信息并标注经办人:
正确输入实例:
测试正常
各种错误的输入:
地点错误(此地点为C地,输入为其他地址如B或是E):
测试正常
测试正常
对已到达目的地的包裹继续进行修改:
测试异常,应返回错误提示,但软件停止工作了
时间错误(太快,或是太慢):
太快(返回错误提示):
测试正常
太慢:
测试正常
其他时间错误1(输入时间早于上一地点的到达时间则无法写入,需要返回错误提示):
测试正常
其他时间错误2(输入非数字字符):
测试异常,应返回错误提示,但系统直接崩溃了
进入客户系统进行查询:
正确的输入查询:
测试正常
测试正常
测试正常
各种输入错误查询:
选择错误(应输入“1”输入“2”则返回输入):
测试正常
包裹号错误
测试正常
应输入数字的地方输入其他字符(软件界面闪烁,不能正常运行):
测试异常,需要改进
注意:
软件只初始化了8个包裹,并将其存入文件,包裹号为1、2、3……
包裹送达及途径的地点以A、B、C……表示;
包裹需要在一个地点停留2小时才会发往下一地点,否则返回错误提示;
在数字输入项输入其他字符会导致软件不能正常运行,次项错误未解决。
4对软件功能的结论
4.1功能
4.1.1能力
软件可以完成对已有包裹的修改和查询,分别通过管理员和客户的两种不同用户实现,使用此软件方便了管理员对包裹信息的修改,也方便了客户对包裹状态的查询。
为满足只有管理员才可以修改包裹信息设置了密码,使得包裹信息具有可靠性;为方便客户查询包裹,只要求客户输入包裹号即可,方便快捷。
4.1.2限制
a.软件只能对已经存在的包裹进行修改和查询,不能初始化包裹。
b.软件对要输入的数据有很雅阁的要求,输入错误的数据会导致软件无法正常运行,而不是给出提示返回输入。
c.客户查询包裹状态时不能看到预期到达时间,只能查询包裹已经走过的路线。
5分析摘要
5.1能力
经测试证实了的本软件的能力。
按照程序的执行过程输入正确(或错误)的数据,程序运行结果经测试几乎完全正确,一些错误经修改已经改正,但还有一些错误由于技术限制未能修改正确。
5.2缺陷和限制
a.测用例包含了整体性能、功能测试,能够检查的范围应覆盖到设计内容所规定的整体指标90%以上,能完成软件的测试,但不能保证完全排除软件错误。
b.补充测试用例的过程应按照项目计划的变更控制所规定的内容进行。
c.测试用例的范围包含了第二部分的功能要求、性能要求,其局限性在于没有大量重复的数据进行输入,这些是由于系统规模、产品开发集成度所决定的。
d.软件测试出的一些错误,由于技术限制,未能完全修改。
5.3建议
对每项缺陷提出改进建议,如:
a.各项修改可采用的修改方法:
对软件的输入进行判定,若输入错误则返回重新输入;
b.各项修改的紧迫程度:
修改时间不足;
c.各项修改的负责人:
刘XX。
5.4评价
软件界面美观,且经过修改严重错误几乎已完全排除,虽然存在一点小错误,但未出现逻辑上的漏洞,客户查询很方便,管理员经过培训也能很好的使用本软件。
6测试资源消耗
工作人员:
赵XX;
机时消耗:
两天;