软件测试报告模板_2.docVIP

计时系统软件项目 遗漏学时申请 阶段测试报告 软件测试部 2015/9/9 目 录 TOC \o 1-3 \h \z \u 1. 引言 3 2. 测试参考文档 3 3. 测试设计简介 3 3.1 测试用例设计 3 3.2 测试环境与配置 3 3.3 测试方法 3 4. 测试情况 4 4.1 测试执行情况 4 4.2 测试覆盖 4 4.3 缺陷的统计 4 4.3.1 缺陷汇总和分析 4 4.3.2 具体的测试缺陷 6 5. 测试结论和建议 7 5.1 结论 7 6. 附录 7 6.1 缺陷状态定义 7 6.2 缺陷严重程度定义 7 6.3 缺陷类型定义 8  引言 本测试报告为计时系统测试报告；本报告目的在于总结测试阶段的测试以及测试结果分析，描述系统是否达到需求的目的。 本报告预期参考人员包括测试人员、测试部门经理、项目管理人员和其他质量控制人员。 测试参考文档 《用户需求说明书》； 《软件需求规格说明书》； 执行程序； 测试脚本； 《软件测试计划》； 《软件测试用例》。 测试设计简介 测试用例设计 测试用例的设计采用等价类划分、边界值、错误推测、因果图等方法， 测试环境与配置 测试环境： 数据库服务器 192.168.1.11 SQL2010 服务器 192.168.1.11 客户端 windows7 SQL2010 IE10.0 网络 公司内部局域网 10M/100M 测试方法 本次主要采用黑盒测试，以需求分析文档中的功能模块为单位，测试的重点集中在基本数据录入、业务流程和各功能模块间的接口。其中单元测试由开发人员直接完成；功能模块采用黑盒测试的常用方法；集成测试模块采用非渐增式测试，偏重系统的接口和数据提取方面。 测试情况 测试执行情况 测试范围和要求： 测试版本：V1.0 测试时间： 2015.9.8 测试机构和人员： 软件测试部： 王葵，陈明 测试覆盖 序号 用户需求编号 模块名称 功能/性能指标 是否通过 缺陷的统计 （说明：该报告为阶段性测试的统计报告，该报表统计的bug数量为3：本发布阶段内第一份申请单提交日期为起，直至填写报告这天为止的BUG数量,如果以前版本中有问题延期至本发布阶段来修正，那么该缺陷也需要统计进来；如果是功能测试报告则只统计当轮的即可，如果是功能+验证则需要统计本发布阶段的） 按BUG状态统计(表格后面可以附上柱形图,以示更直观) BUG状态 BUG数量 备注 未分配(new) 0 不是缺陷（Not Bug） 0 未修改(open) 0 已修改(fixed) 2 不予修改(Won’t Fix) 延期（Deffered） 1 被拒绝 （Declined） 无法重现 信息不足 重复的 已关闭（Closed） 2 重开启（Reopen） 0 合计 3 表3 按bug状态统计 遗留问题列表(本发布阶段发现的，以及前发布阶段延期至本阶段来修正的缺陷) 序号 问题详细描述 严重程度 图片 1 【驾校管理】【学员管理】【遗漏学时申请】申请记录页面过于简单，没有体现出学员信息；全选按钮点击没反应 微小 表10 遗留问题列表 质量风险[可选] 主要是在本发布阶段针对开发经理要求不测试且最终确实未测试,但是测试人员从质量的角度认为需要测试的功能点做简要说明 序号 风险点描述 备注 1 测试结论和建议 本次测试完全依照用户需求进行功能测试，功能测试覆盖率100%。根据测试结果可以得出：在当前的服务器软硬件、网络环境下软件系统功能符合验收标准。 附录 缺陷状态定义 缺陷状态 描述 已关闭 缺陷确认者（一般为问题生成人）验证后认为问题已解决属实 已拒绝 被拒绝的缺陷经缺陷确认者确认，确实不需要修复或不是缺陷 被拒绝 测试人员认为是系统缺陷或者是需要对系统进行优化，开发人员认为不是缺陷或者不需要优化的问题 延迟 问题的分析者认为是缺陷，但是不影响业务办理的进行延迟处理。 缺陷严重程度定义 严重等级 描述 严重 缺陷对进度的影响可能是非常致命的，或者可能是一个停止器——即终止用户继续使用系统；或者影响测试工作继续进行的缺陷。 较严重 系统基本能正常工作但同一错误现象频繁出现或者问题不解决时会给后续工作带来较大风险（如需求描述不正确导致系统设计错误）。 一般 不属于“严重”、