《测试报告项目测试环境》由会员分享，可在线阅读，更多相关《测试报告项目测试环境（9页珍藏版）》请在金锄头文库上搜索。
1、测试报告项目测试环境Company number ：【WTUT-WT88Y-W8BBGB-BWYTT-19998 】XX 项目测试报告版本信息日期版本状态简要描述编写审核批准2018-07-18首次建立项目测试报告（标准 版）模板XXX注：状态可以为N-新建、A-增加、M-更改、D-删除 目录编写目的本测试报告为【XX】项目的测试报告，目的在于总结测试阶段的测试情况以及 分析测试结果，描述系统是否符合需求并对测试质量进行分析。本报告作为测试质量参考文档提供给用户、测试人员、开发人员、项目管理 者、其他质量管理人员和需要阅读本报告的高层经理阅读。测试参考文档用户需求说明书软件需求规格说明书软件开
2、发计划软件测试计划软件测试方案软件测试策略软件测试用例缺陷分类指南功能及UI测试标准项目信息项目名称XX项目编号XXX项目周期2018/1/19 2018/2/26项印性质全新产品/大版本升级/小版本升级（只能选择一个）项目版本号项目经理XXX测试经理XXX测试工程师XXX开发工程师XXX测试概述基本信息本次测试的基本信息如下测试时间2018/1/19 2018/2/26测试环境硬件处理器：Inter Core i5， 内存：8GB操作系统：Windows 10软件Navicat Premium、 xshell、 IE, FireFox, Coogle Chrome等 浏览器测试站点XXX测试
3、过程阶段任务说明开始时间结束时间工作量 （人/ 天）责任人计划实际计划实际计划实际计划实 际测试准备编写测试计划2018-3-252018-3-252018-3-252018-3-25XXX需求理解澄清无无无无编写测试策略编写测试方案编写测试用例评审测试用例测试环境准备测试数据准备测试脚本准备测试执行系统测试回归测试测试结束编写测试报告编写用户手册项目实施培训项目部署测试范围任务测试覆盖功能点一级功能二级功能三级功能历史测试过程评估 测试设计 测试用例1、测试用例的设计方法采用等价类划分、边界值、因果图、错误推测法等。2、依据需求文档和原型图设计测试用例，测试用例覆盖所有需求功能点，在评审通过
4、后执行测试。测试方法根据系统需求规格说明书的描述，明确指出了系统应该具有的功能。在完全不 考虑程序内部结构和内部特性的情况下，测试者只需检查程序功能是否按照系 统需求规格说明书的规定正常使用，是否能在输入适当的数锯下产生正确的输 出信息，并且能保持外部信息（如数据库或文件）的完整性。因此采用了着眼 于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试的 测试方法：黑盒测试。本次测试的重点集中在基本数据录入、业务流程和各功能模块间的接口。 测试执行测试用例覆盖总结1、 执行的测试用例数覆盖了所有的功能点模块名称用例数 （条）覆盖情况执行情况客户管理94系统测试2轮，验收测试2轮执行
5、94条，未通过1条 用例通过率：%测试用例执行总结测试执行统计表测试用例版本号工作量投入 （人天）测试用例规模总用例数新增用例数执行结果统计表计划执行的 用例数实际执行的 用例数通过的 用例数执行率覆盖率通过率发现缺陷数执行率=实际执行的用例数宁计划执行的用例数覆盖率=实际执行的用例数宁总用例数通过率=通过的用例数宁实际执行的用例数发现缺陷数=本次版本一共提交了多少个BUG单案例总数与计划执行案例数不一致，请说明原因。（指本次测试总案例 数与本次测试总的计划执行案例数），与本文最后一个章节的风险相对应。计划执行案例数与实际执行案例数不一致，请说明原因。（指本次测试总的计划执行案例数与本次执行总
6、的实际执行案例数），与本文最后一个章节 的风险相对应。缺陷统计与分析缺陷统计缺陷总计：28 个；打开：17 个；处理中：2 个；重新打开：3个；已解决：5 个；已关闭：1个缺陷分析缺陷分布-按严重等级划分缺陷严重等级合计已关闭未解决已关闭所占百分比轻微-Trivial一般-Minor重要-Major严重-Critical阻塞-Blocker缺陷分布-按功能模块划分模块名称合计已关闭未解决已关闭所占百分比缺陷分布-按缺陷类型划分缺陷类型合计已关闭未解决已关闭所占百分比需求问题41325%代码问题31233%设计问题62433%配置问题42250%环境问题43175%兼容问题94544%安全问题3
7、1233%性能问题330100%脚本问题31233%数据问题43175%其他74357%非缺陷51420%缺陷趋势-新增缺陷 缺陷趋势-重新打开缺陷 缺陷趋势-修改缺陷 缺陷趋势-关闭缺陷 版本需求变更分析 需求变更描述本次版本测试共收到 35个需求变更：其中 14个为测试过程中已有项目的需求变更， 主要集中在准时装项目、海外购二期项目、在线支付异常同步商家需求等需求中；4 个技 术优化，17 个为新增的需求变更。本次版本需求变更数量依旧不少，需求变更方面的控制 还需加强，版本的变更对版本质量的影响很大，本次版本发布风险较高。 需求变更统计 新增需求：12个 变更需求：1 个 需求优化：23个
8、 版本演进轨迹罗列本项目内的所有分支及各个*分支合并后的回归测试版本号发布时间是否合并回归测试结果2018-07-19否通过测试总结测试结论测试结论要明确，即通过或者不通过，不能附带任何条件。对于有条件通过的需求，需 要在后续“风险分析”章节进行描述，有条件通过是根据准出条件有部分条件不通过，具体准则 如下：通过达到准出条件，如：测试案例执行率达到95%、阻塞和致命的缺陷全部修复且测试通过、严重缺陷修复率超过95%、一般缺陷修复率已超过 85%、提示缺陷修复率超过75%；不通过未达到准出条件，如：测试案例执行率低于95%、阻塞和致命缺陷未全部修复或复测未通过、严重缺陷修复率未达到95%、一般缺
9、陷修复率未达到85%，提示缺陷修复率未达 到75%；有条件通过指未达到准出条件但项目责任人确认相关风险，或风险可以得到处理，在此条件下同意测试有条件通过。1、通过对本系统的两轮测试工作，将系统所存在的缺陷全部暴露并交予开发人 员进行bug修复，再经过回归测试确保了所有功能及模块已经实现，并且满 足客户需求。2、本系统的测试充分有效，主要业务模块的测试覆盖达到100%，缺陷解决率达 到 100%。3、目前的测试工作基本达到了预定目标，即完成除原有的系统功能外的所有功 能及模块功能的功能测试，测试任务已全面完成。4、根据测试结果、BUG的修复率和测试计划中的测试通过标准得出该项目功能测 试通过，可
10、以交付使用。测试建议1、从测试的整个过程来看，比较常见的问题是：编辑框中数据输入过长不能正 确处理或者页面变形，页面样式不统一（翻页、提示语等），数据添加成 功，上传附件不显示，查询冗余数据等。开发人员在编码过程中，系统在实 现基本功能的前提下需要注意页面样式的一致性和操作界面友好性等非功能 的方面。2、在这次测试过程中，提出建议：测试人员在提交bug时，需要详细描述：版 本号、操作步骤、期望结果、实际结果，以便开发人员读懂并能重现bug， 避免将 bug 直接打回，延长 bug 的存在周期。同时开发人员必须将打回 bug 之前需给予问题解答的简单描述，以利于回归测试。在本次测试中因没有按 照
11、标准执行，导致有些bug在回归几次后才有效解决，所以必须在以后的测 试项目中测试人员和开发人员严格按照标准执行。3、在本次测试过程中存在一个问题多次修改的情况。造成此问题出现的最主要原因是开发人员在提交新版本时未进行单元测试。所以，我们建议开发人员将程序包提交给测试人员之前先对程序代码进行检查，这样能有效地缩短BUG的生存周期，提高测试人员和开发人员的工作效率。遗留问题列表给出遗留的影响到系统上线或者进入下一个环节的问题，比如，状态“致为命”的测试缺 陷，或者需要重点关注的状态为“严重”的测试缺陷。对于其他需要需求负责人、开发负责人 版本负责人等加以关注或者加以改进的问题，也需要在此处列出缺陷
12、编号缺陷描述严重 级别重现 概率影响说明遗留原因致命100%导致系统 崩溃需求变更，待确认 需求后统一修改严重100%导致数据 丢失数据库迁移，待迁 移后修复风险分析对系统上线或者进入下一个环节有可能存在的风险进行分析，并提出规避的措施或者建 议，以便相关人员对此进行关注或者解决问题序号风险问 题类型风险问题 描述风险等级提出人提出 时间责任人应对解 决方案计划解决日期问题状态备注1第二方 插件问 题第三方插件 无法正常加 载中XXXXXX开发在 查问题 中未 解 决2代码重 构代码重构 后，引发大 量BUG高XXXXXX开发修 改未 解 决3需求变 更需求变更过 于频繁，无 法及时开发 完成中XXXXXX下个版
