测试报告.docx
《测试报告.docx》由会员分享,可在线阅读,更多相关《测试报告.docx(10页珍藏版)》请在冰点文库上搜索。
测试报告
1前言
测试报告是测试阶段最后的文档产出物,优秀的测试经理应该具备良好的文档编写能力,一份详细的测试报告包含足够的信息,包括产品质量和测试过程的评价,测试报告基于测试中的数据采集以及对最终的测试结果分析。
下面以通用的测试报告模板为例,详细展开对测试报告编写的具体描述。
编写目的
本测试报告为智慧停车系统功能测试报告,目的在于总结测试阶段的测试以及分析测试结果,描述系统是否符合需求,并依据结果对该产品做出评价和建议。
适用范围包括公司信息化建设客户管理系统项目的用户、测试人员、开发人员、项目管理其他质量管理人员和需要阅读本报告的高层经理。
参考资料
parkingManager(PC端).docx
咪网城管端概要设计.xlsx
城管执法客户端产品需求文档.docx
2测试总体情况
测试用例设计
测试用例的设计方法采用等价类划分、边界值、因果图、错误推测法等。
测试环境与配置
测试辅助工具
工具类型
工具名称
BUG管理工具
阿里云缺陷管理平台
测试方法
测试方法:
根据系统需求规格说明书的描述,明确指出了系统应该具有的功能。
在完全不考虑程序内部结构和内部特性的情况下,测试者只需检查程序功能是否按照系统需求规格说明书的规定正常使用,是否能在输入适当的数锯下产生正确的输出信息,并且能保持外部信息(如数据库或文件)的完整性。
因此采用了着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试的测试方法:
黑盒测试。
3测试结果及缺陷分析
测试执行情况与记录
测试组织
姓名
邮箱
测试内容
江菲菲
测试人员
颜传赞
测试人员
邵奔
技术总监检查
测试时间
咪网智慧停车第一轮测试
任务
开始时间
主要测试
接口测试
2017-03-14
系统内接口测试
联调测试
2017-04-16
各个系统之间的联调测试
咪网智慧停车第二轮测试
任务
开始时间
主要测试
功能测试
2017-05-20
功能验证
对外接口
2015-05-20
支付宝,海口系统,微信等接口对接
回归测试
2017-06-18
回归测试
覆盖分析
需求覆盖
需求/功能
测试类型
是否通过
登录注册
注册
注册是否正常
pass
登录
用户登录登出
pass
停车数据
停车数据
1.平均车位周转率
2.近30天停车收费数据总览
3.停车方式占比
4.停车时间占比
pass
车位管理
车位地图
1.展示车位地图
2.全部、违停、空闲、计费数据
3.搜索支持
pass
车位列表
1.搜索条件:
路段,巡检员,查询是否正确
2.车位列表展示
3.可分页显示
pass
违停监控
取证记录
1.搜索条件检查:
停车路段、巡检员、车辆信息、审核状态、提交时间
2.取证记录审核,取消
3.数据列表展示
4.分页显示
pass
人员管理
管理员
1.新增
2.编辑
3.重置密码
4.删除
pass
巡检员
1.查看:
账户信息、出勤记录、数据统计
2.新增
3.编辑
4.删除
5.重置密码
pass
权限管理
1.角色添加
2.角色编辑
3.角色删除
4.权限配置
pass
停车管理
停车记录
1.查询条件检查:
停车路段、停车状态、手机号、泊车卡号、停车方式、开始时间
2.数据检查
3.分页检查
pass
硬件监控
咪表健康管理
1.查询条件检查:
所属路段、健康状态、咪表编号
2.数据检查
3.分页检查
pass
卡管理
发卡记录
1.查询条件检查:
编号、开始时间
2.数据检查
3.分页检查
pass
验卡充值
1.验卡功能测试
2.充值功能测试
3.补录功能测试
pass
充值记录
1.查询条件检查:
编号、充值人员、开始时间
2.数据检查
3.分页检查
pass
刷卡消费记录
1.搜索条件检查:
咪表号、车位名称、支付类型、地区、开始结束时间
2.数据检查
3.分页检查
pass
统计报表
在线罚款缴纳记录
1.搜索条件检查:
缴纳方式、手机号、车牌号、开始结束时间
2.数据检查
3.分页检查
pass
收入汇总
1.搜索条件检查:
清算日期、清算类型
2.数据检查
3.分页检查
pass
兼容性
功能
pass
界面
pass
页面风格
风格统一
pass
数据库管理
配置管理
pass
兼容性分析
本系统进行了多浏览器的兼容性测试,使用到的浏览器版本包括:
浏览器、浏览器、浏览器、360安全浏览器、Chrome浏览器、firefox浏览器、Safari浏览器V;
在进行多浏览器的测试过程中,覆盖了前、后台的所有页面以及全部的功能,在测试过程中着重进行了对页面样式、布局以及数据展示的测试工作。
目前可以确定,在上述浏览器中,本系统的前端页面展示基本完全兼容。
边界值测试分析
在进行对系统的测试过程中,对于文本输入框、最小起订量、限制条件等操作进行了必要的边界值测试,较好的验证了当前系统的健壮性和稳定性。
在进行边界测试的时候,验证了在本系统会根据当前业务场景进行对临界值的判断和处理,确保了系统的正确使用。
缺陷的统计与分析
缺陷汇总
缺陷发现率(功能测试缺陷总数/工作日):
1084/10=
缺陷密度(功能测试缺陷总数/模块数):
1084/159=
缺陷分析
表一:
bug的缺陷类型分布表
总BUG数
1084
致命
严重
一般
轻微
218
223
620
23
表二:
bug的回归情况分布表
关闭BUG总数
1020
致命
严重
一般
轻微
204
209
585
22
表三:
bug的未修复情况分布表
未修改BUG数
12
致命
严重
一般
轻微
1
2
9
0
表四:
bug的未验证情况分布表
未验证BUG数(方案状态为已解决)
51
致命
严重
一般
轻微
13
12
25
1
表五:
bug设计如此和延期处理情况分布表
设计如此数
22
致命
严重
一般
轻微
0
3
16
3
延期处理
7
致命
严重
一般
轻微
1
6
0
测试用例执行情况表
BUG关闭率(已关闭/总BUG数)
94%
遗留率
6%
用例执行率
100%
用例通过率
100%
累计执行用例数
3697
用例通过数
3688
总用例数
3697
Bug缺陷类型分布表
缺陷类型
数量
比值
代码错误
909
84%
设计缺陷
116
11%
界面优化
33
3%
其他
24
2%
配置相关
2
0%
4测试结论与建议
测试结论
1.通过对本系统的两轮测试工作,将系统所存在的缺陷全部暴露并交予开发人员进行bug修复,再经过回归测试确保了所有功能及模块已经实现,并且满足客户需求。
2.本系统的测试充分有效,主要业务模块的测试覆盖达到100%,缺陷解决率达到100%。
3.目前的测试工作基本达到了预定目标,即完成除原有的系统功能外的所有功能及模块功能的功能测试,测试任务已全面完成。
4.根据测试结果、BUG的修复率和测试计划中的测试通过标准得出该项目功能测试通过,可以交付使用。
建议
1、从测试的整个过程来看,比较常见的问题是:
编辑框中数据输入过长不能正确处理或者页面变形,页面样式不统一(翻页、提示语等),数据添加成功,上传附件不显示,查询冗余数据等。
开发人员在编码过程中,系统在实现基本功能的前提下需要注意页面样式的一致性和操作界面友好性等非功能的方面。
2、在这次测试过程中,提出建议:
测试人员在提交bug时,需要详细描述:
版本号、操作步骤、期望结果、实际结果,以便开发人员读懂并能重现bug,避免将bug直接打回,延长bug的存在周期。
同时开发人员必须将打回bug之前需给予问题解答的简单描述,以利于回归测试。
在本次测试中因没有按照标准执行,导致有些bug在回归几次后才有效解决,所以必须在以后的测试项目中测试人员和开发人员严格按照标准执行。
3、在本次测试过程中存在一个问题多次修改的情况。
造成此问题出现的最主要原因是开发人员在提交新版本时未进行单元测试。
所以,我们建议开发人员将程序包提交给测试人员之前先对程序代码进行检查,这样能有效地缩短BUG的生存周期,提高测试人员和开发人员的工作效率。