测试报告143001.pdf

《测试报告143001.pdf》由会员分享，可在线阅读，更多相关《测试报告143001.pdf（10页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、勿以恶小而为之，勿以善小而不为。刘备先天下之忧而忧，后天下之乐而乐。范仲淹 目 录 1 前言.2 1.1 编写目的.2 1.5 参考资料.2 2 测试总体情况.2 2.1 测试用例设计.2 2.2 测试环境与配置.3 2.2.3.测试辅助工具.3 2.3 测试方法.3 3 测试结果及缺陷分析.3 3.1 测试执行情况与记录.3 3.1.1 测试组织.3 3.1.2 测试时间.3 3.2 覆盖分析.4 3.2.1 需求覆盖.4 3.2.2 测试覆盖.7 3.3 兼容性分析.7 3.4 边界值测试分析.7 3.5 缺陷的统计与分析.7 3.5.1 缺陷汇总.7 3.5.2 缺陷分析.7 3.5.3

2、 残留缺陷与未解决问题.错误!未定义书签。4 测试结论与建议.9 4.1 测试结论.9 4.2 建议.9 志不强者智不达，言不信者行不果。墨翟人不知而不愠，不亦君子乎？论语 2/10 1 前言 测试报告是测试阶段最后的文档产出物，优秀的测试经理应该具备良好的文档编写能力，一份详细的测试报告包含足够的信息，包括产品质量和测试过程的评价，测试报告基于测试中的数据采集以及对最终的测试结果分析。下面以通用的测试报告模板为例，详细展开对测试报告编写的具体描述。1.1 编写目的 本测试报告为智慧停车系统功能测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求，并依据结果对该产品做出评

3、价和建议。适用范围包括公司信息化建设客户管理系统项目的用户、测试人员、开发人员、项目管理其他质量管理人员和需要阅读本报告的高层经理。1.5 参考资料 parkingManager(PC 端 V1.1.3）.docx 咪网城管端 APP1.2_概要设计.xlsx 城管执法客户端产品需求文档.docx 2 测试总体情况 2.1 测试用例设计 测试用例的设计方法采用等价类划分、边界值、因果图、错误推测法等。百川东到海，何时复西归？少壮不尽力，老大徒伤悲。汉乐府长歌行谋事在人，成事在天！增广贤文 3/10 2.2 测试环境与配置 2.2.3.测试辅助工具 工具类型 工具名称 BUG 管理工具 阿里云缺

4、陷管理平台 2.3 测试方法 测试方法：根据系统需求规格说明书的描述，明确指出了系统应该具有的功能。在完全不考虑程序内部结构和内部特性的情况下，测试者只需检查程序功能是否按照系统需求规格说明书的规定正常使用，是否能在输入适当的数锯下产生正确的输出信息，并且能保持外部信息（如数据库或文件）的完整性。因此采用了着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试的测试方法：黑盒测试。3 测试结果及缺陷分析 3.1 测试执行情况与记录 3.1.1 测试组织 姓名 邮箱 测试内容 江菲菲*测试人员 颜传赞*测试人员 邵奔*技术总监检查 3.1.2 测试时间 咪网智慧停车 v1.0 第

5、一轮测试 任务 开始时间 主要测试 接口测试 2017-03-14 系统内接口测试 联调测试 2017-04-16 各个系统之间的联调测试 人不知而不愠，不亦君子乎？论语云路鹏程九万里，雪窗萤火二十年。王实甫 4/10 咪网智慧停车 v3.0 第二轮测试 任务 开始时间 主要测试 功能测试 2017-05-20 功能验证 对外接口 2015-05-20 支付宝，海口系统，微信等接口对接 回归测试 2017-06-18 回归测试 3.2 覆盖分析 3.2.1 需求覆盖 需求/功能 测试类型 是否通过 登录注册 注册 注册是否正常 pass 登录 用户登录登出 pass 停车数据 停车数据 1.平

6、均车位周转率 2.近 30 天停车收费数据总览 3.停车方式占比 4.停车时间占比 pass 车位管理 车位地图 1.展示车位地图 2.全部、违停、空闲、计费数据 3.搜索支持 pass 车位列表 1.搜索条件：路段，巡检员，查询是否正确 2.车位列表展示 3.可分页显示 pass 违停监控 取证记录 1.搜索条件检查：停车路段、巡检员、车辆信pass 海纳百川，有容乃大；壁立千仞，无欲则刚。林则徐万两黄金容易得，知心一个也难求。曹雪芹 5/10 需求/功能 测试类型 是否通过 息、审核状态、提交时间 2.取证记录审核，取消 3.数据列表展示 4.分页显示 人员管理 管理员 1.新增 2.编辑

7、 3.重置密码 4.删除 pass 巡检员 1.查看：账户信息、出勤记录、数据统计 2.新增 3.编辑 4.删除 5.重置密码 pass 权限管理 1.角色添加 2.角色编辑 3.角色删除 4.权限配置 pass 停车管理 停车记录 1.查询条件检查：停车路段、停车状态、手机号、泊车卡号、停车方式、开始时间 2.数据检查 3.分页检查 pass 硬件监控 咪表健康管理 1.查询条件检查：所属路段、健康状态、咪表编号 pass 老当益壮，宁移白首之心；穷且益坚，不坠青云之志。唐王勃丹青不知老将至，贫贱于我如浮云。杜甫 6/10 需求/功能 测试类型 是否通过 2.数据检查 3.分页检查 卡管理

8、发卡记录 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

9、百学须先立志。朱熹古之立大事者，不惟有超世之才，亦必有坚忍不拔之志。苏轼 7/10 需求/功能 测试类型 是否通过 界面 pass 页面风格 风格统一 pass 数据库管理 配置管理 pass 3.3 兼容性分析 本系统进行了多浏览器的兼容性测试，使用到的浏览器版本包括：IE9.0 浏览器、IE10.0浏览器、IE11.0 浏览器、360 安全浏览器 V8.5.0.142、Chrome 浏览器 V51.0.2704.103、firefox浏览器 V47.0、Safari 浏览器 V 5.1.7；在进行多浏览器的测试过程中，覆盖了前、后台的所有页面以及全部的功能，在测试过程中着重进行了对页面样式

10、、布局以及数据展示的测试工作。目前可以确定，在上述浏览器中，本系统的前端页面展示基本完全兼容。3.4 边界值测试分析 在进行对系统的测试过程中，对于文本输入框、最小起订量、限制条件等操作进行了必要的边界值测试，较好的验证了当前系统的健壮性和稳定性。在进行边界测试的时候，验证了在本系统会根据当前业务场景进行对临界值的判断和处理，确保了系统的正确使用。3.5 缺陷的统计与分析 3.5.1 缺陷汇总 缺陷发现率（功能测试缺陷总数/工作日）：1084/10=108.4 缺陷密度（功能测试缺陷总数/模块数）：1084/159=6.818 3.5.2 缺陷分析 表一：bug 的缺陷类型分布表 总 BUG

11、数 1084 致命 严重 一般 轻微 谋事在人，成事在天！增广贤文人人好公，则天下太平；人人营私，则天下大乱。刘鹗 8/10 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

12、延期处理 7 致命 严重 一般 轻微 1 6 0 测试用例执行情况表 BUG 关闭率（已关闭/总 BUG 数）94%遗留率 6%用例执行率 100%用例通过率 100%累计执行用例数 3697 用例通过数 3688 总用例数 3697 Bug 缺陷类型分布表 缺陷类型 数量 比值 代码错误 909 84%设计缺陷 116 11%穷则独善其身，达则兼善天下。孟子人人好公，则天下太平；人人营私，则天下大乱。刘鹗 9/10 界面优化 33 3%其他 24 2%配置相关 2 0%4 测试结论与建议 4.1 测试结论 1通过对本系统的两轮测试工作，将系统所存在的缺陷全部暴露并交予开发人员进行 bug修复

13、，再经过回归测试确保了所有功能及模块已经实现，并且满足客户需求。2本系统的测试充分有效，主要业务模块的测试覆盖达到 100%，缺陷解决率达到 100%。3目前的测试工作基本达到了预定目标，即完成除原有的系统功能外的所有功能及模块功能的功能测试，测试任务已全面完成。4根据测试结果、BUG 的修复率和测试计划中的测试通过标准得出该项目功能测试通过，可以交付使用。4.2 建议 1、从测试的整个过程来看，比较常见的问题是：编辑框中数据输入过长不能正确处理或者页面变形，页面样式不统一（翻页、提示语等），数据添加成功，上传附件不显示，查询冗余数据等。开发人员在编码过程中，系统在实现基本功能的前提下需要注意

14、页面样式的一致性和操作界面友好性等非功能的方面。2、在这次测试过程中，提出建议：测试人员在提交 bug 时，需要详细描述：版本号、操作步骤、期望结果、实际结果，以便开发人员读懂并能重现 bug，避免将 bug 直接打回，延长 bug的存在周期。同时开发人员必须将打回 bug 之前需给予问题解答的简单描述，以利于回归测试。在本次测试中因没有按照标准执行，导致有些 bug 在回归几次后才有效解决，所以必须在以后的测试项目中测试人员和开发人员严格按照标准执行。3、在本次测试过程中存在一个问题多次修改的情况。造成此问题出现的最主要原因是开发人员在提交新版本时未进行单元测试。所以，我们建议开发人员将程序包提交给测试人员之前先对程序代码进行检查，这样能有效地缩短 BUG 的生存周期，提高测试人员和开发人员的工作效率。大丈夫处世，不能立功建业，几与草木同腐乎？罗贯中大丈夫处世，不能立功建业，几与草木同腐乎？罗贯中 10/10