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