《测试报告(模版)》由会员分享，可在线阅读，更多相关《测试报告(模版)（12页珍藏版）》请在金锄头文库上搜索。
1、 X 项目测试报告部 门:撰 写：日 期:文档修订记录版本号日期修订页/修订描述作者审批人目录1概述11目的1.2背景1.范畴11引用文档2测试概要2.1测试环境22.人力资源22测试工作量2.4测试版本2.测试功能点列表326未测试功能点列表3测试成果及缺陷分析3.1测试数据记录汇总.2测试用例记录分析3缺陷记录分析53.按模块、缺陷级别记录53.3.按模块、缺陷状态记录53.3.3按开发人员、缺陷状态记录533.4按缺陷生命周期记录3.3.5按缺陷引入阶段记录5.6按缺陷类型记录53.残留缺陷汇总6.4.1残留缺陷3.2残留缺陷264测试结论与建议4软件能力742缺陷和限制743建议74测
2、试结论71 概述1.1 目的本测试报告的具体编写目的，指出预期的读者范畴。实例：本测试报告为XX项目的测试报告,目的在于总结测试阶段的测试以及分析测试成果,描述系统与否符合需求（或达到功能目的)。预期参照人员涉及顾客、测试人员、开发人员、项目管理者、其她质量管理人员和需要阅读本报告的高层经理。提示:一般,顾客对测试结论部分感爱好，开发人员但愿从缺陷成果以及分析得到产品开发质量的信息,项目管理者对测试执行中成本、资源和时间予与注重，而高层经理但愿可以阅读到简朴的图表并且可以与其她项目进行同向比较。此部分可以具体描述为什么类型的人可参照本报告XX页章节,你的报告读者越多，你的工作越容易被人注重，前
3、提是必须让阅读者感到你的报告是有价值并且值得去关注的。1.2 背景输入测试对象(组件、应用程序、系统等)及其目的的的简要阐明。需要涉及的信息有：重要的功能和特性、测试对象的构架以及项目的简史。本节应当只涉及 3至5 个段落。1.3 范畴描述测试的各个阶段,例如:单元测试、集成测试或系统测试，并阐明所针对的测试类型（如功能测试或性能测试)。简要地列出测试对象中将接受测试或将不接受测试的那些特性和功能。1.4 引用文档下表列出了执行测试过程所引用的文档：文档名称版本号作者或来源备注2 测试概要2.1 测试环境下表描述测试该项目所需要的硬件环境:设备名称数量型号备注下表描述测试该项目所需要的软件环境
4、：软件名称版本号备注如需要，以拓扑图方式给出网络环境。2.2 人力资源下表列出了所有参与此项目的测试人员:角色资源数量/具体人员具体职责或注释测试经理,测试项目经理进行管理监督。职责:提供技术指引、获取合适的资源、提供管理报告测试设计员拟定测试用例、拟定测试用例的优先级并实行测试用例。职责:生成测试筹划、生成测试模型、评估测试工作的有效性测试员执行测试。职责:执行测试、记录成果、从错误中恢复、记录变更祈求测试系统管理员保证测试环境和资产得到管理和维护。职责:管理测试系统、授予和管理角色对测试系统的访问权数据库管理员保证测试数据(数据库)环境和资产得到管理和维护。职责:管理测试数据(数据库)2.
5、3 测试工作量任务开始时间结束时间总计(天数)总计(人时）筹划测试筹划测试设计测试执行测试总结实际测试筹划测试设计测试执行测试总结2.4 测试版本给出测试的版本，及回归测试的次数。建议以表格清单方式列出，便于理解各个子系统/子模块的测试频度,对于多次回归的子系统/子模块将引起开发者关注。2.5 测试功能点列表建议以表格形式列出测试中涉及的功能点列表：需求编号功能点概述用例个数与否通过备注2.6 未测试功能点列表建议以表格形式列出测试中未涉及的功能点列表:需求编号功能点概述未测试因素注未测试的理由涉及：需求不明确,测试环境不具有,不支持等3 测试成果及缺陷分析汇总多种数据并进行度量，度量涉及对测
6、试过程的度量和能力评估、对软件产品的质量度量和产品评估。对于不需要过限度量或者相对较小的项目,例如用于验收时提交顾客的测试报告、小型项目的测试报告,可省略过程方面的度量部分；而对于公司内部产品或项目测试，过限度量数据必须列出,为产品改善和缺陷避免提供参照数据。数据应来源于测试管理系统。3.1 测试数据记录汇总该部分记录的测试数据与“测试月度筹划与报告”中数据记录部分的记录指标一致,可运用其模板计算获得。测试阶段模块基线测试用例数(个) 基线测试用例数：评审后的测试用例数变更测试用例数(个） 变更测试用例数：新增用例+修改用例+删除用例用例总数(个)用例执行成功数(个)用例执行失败数(个)未执行
7、用例数(个)用例执行率(%） 用例执行率(%)=用例执行成功数+用例执行失败数/用例总数*100%用例执行成功率() 用例执行成功率(%)=用例执行成功数/用例总数*100%Bg准时解决数(个) Bug 准时解决：5 个工作日解决的 Bug 为“准时”解决Bg 超时解决数（个) 5 个工作日解决的 Bug 为“超时”解决；对于多次被 Active 的 Bug，若其中有超过 5 个工作日解决时间的，算超时解决。Bu总数(个）Bg 准时解决率（) Bug 准时解决率(%)=Bug 准时解决数/ Bug 总数*100%用例产生 ug 率() 用例产生 Bug 率(%)=Bug 总数/用例总数*100
8、%测试阶段模块测试阶段模块B测试阶段/模块C合计3.2 测试用例记录分析描述测试用例执行状况记录图及简要分析。3.3 缺陷记录分析3.3.1 按模块、缺陷级别记录描述按模块、缺陷级别记录图及简要分析。3.3.2 按模块、缺陷状态记录描述按模块、缺陷状态记录图及简要分析。3.3.3 按开发人员、缺陷状态记录描述按开发人员、缺陷状态记录图及简要分析。3.3.4 按缺陷生命周期记录描述按Bug 生命周期记录图及简要分析。3.3.5 按缺陷引入阶段记录描述按缺陷引入阶段记录图及简要分析。测试阶段/模块需求阶段设计阶段编码阶段发布阶段测试阶段/模块A测试阶段/模块B测试阶段/模块C合计3.3.6 按缺陷
9、类型记录描述按缺陷类型记录图及简要分析。测试阶段/模块功能性能界面文档接口测试阶段/模块A测试阶段/模块B测试阶段/模块C合计3.4 残留缺陷汇总3.4.1 残留缺陷1 编号:UG编号 缺陷概要:该缺陷描述的事实 因素分析:如何引起缺陷，缺陷的后果,描述导致软件局限性和其她限制性的因素 避免和改善措施：弥补手段和长期方略3.4.2 残留缺陷2 编号：BG编号缺陷概要：该缺陷描述的事实 因素分析:如何引起缺陷,缺陷的后果,描述导致软件局限性和其她限制性的因素 避免和改善措施:弥补手段和长期方略4 测试结论与建议4.1 缺陷和限制测试执行与否充足;对系统存在问题的阐明，描述测试所揭发的软件缺陷和局限性,以及也许给软件实行和运营带来的影响；也许存在的潜在缺陷和后续工作。4.2 建议提出为弥补上述缺陷的建议;对缺陷修改和产品设计的建议;对过程改善方面的建议。4.3 测试结论阐明该测试能否通过。
