考试报告模版.docx

考试报告模版.docx

《考试报告模版.docx》由会员分享，可在线阅读，更多相关《考试报告模版.docx（9页珍藏版）》请在冰豆网上搜索。

考试报告模版

测试报告（模版）

————————————————————————————————　作者:

————————————————————————————————日期:

XXX　项目测试报告

部　　门：

撰　写：

日　　　期:

文档修订记录

版本号

日期

修订页/修订描述

作者

审批人

１概述1

1.1目的1

1.２背景ﻩ１

１.3范围ﻩ１

１．４引用文档1

2.1ﻩ测试环境２

2.2人力资源ﻩ２

2．3ﻩ测试工作量ﻩ3

２．４ﻩ测试版本ﻩ３

2.5ﻩ测试功能点列表ﻩ3

3ﻩ测试结果及缺陷分析4

3．１测试数据统计汇总4

3.2ﻩ测试用例统计分析4

３.3缺陷统计分析５

3．３.1按模块、缺陷级别统计5

3.3.2ﻩ按模块、缺陷状态统计ﻩ5

3.3.3ﻩ按开发人员、缺陷状态统计ﻩ5

3.３．4按缺陷生命周期统计ﻩ5

3.3.6ﻩ按缺陷类型统计ﻩ5

3．４ﻩ残留缺陷汇总６

3.4.１ﻩ残留缺陷１ﻩ6

3.4．2ﻩ残留缺陷26

4ﻩ测试结论与建议ﻩ7

４．1软件能力ﻩ7

4.2ﻩ缺陷和限制ﻩ7

4.3ﻩ建议7

4.4ﻩ测试结论ﻩ７

1概述

1.1目的

本测试报告的具体编写目的，指出预期的读者范围。

实例:

本测试报告为XXX项目的测试报告,目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XＸＸ功能目标）。

预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。

提示：

通常，用户对测试结论部分感兴趣,开发人员希望从缺陷结果以及分析得到产品开发质量的信息，项目管理者对测试执行中成本、资源和时间予与重视，而高层经理希望能够阅读到简单的图表并且能够与其他项目进行同向比较。

此部分可以具体描述为什么类型的人可参考本报告XXＸ页ＸXX章节,你的报告读者越多,你的工作越容易被人重视，前提是必须让阅读者感到你的报告是有价值而且值得去关注的。

1.2背景

[输入测试对象（组件、应用程序、系统等）及其目标的的简要说明。

需要包括的信息有：

主要的功能和特性、测试对象的构架以及项目的简史。

本节应该只包含3　至5个段落。

]

1.3范围

［描述测试的各个阶段，例如:

单元测试、集成测试或系统测试,并说明所针对的测试类型（如功能测试或性能测试）。

简要地列出测试对象中将接受测试或将不接受测试的那些特性和功能。

]

1.4引用文档

下表列出了执行测试过程所引用的文档:

文档名称

版本号

作者或来源

备注

2测试概要

2.1测试环境

下表描述测试该项目所需要的硬件环境:

设备名称

数量

型号

备注

下表描述测试该项目所需要的软件环境：

软件名称

版本号

备注

[如需要，以拓扑图方式给出网络环境。

]

2.2人力资源

下表列出了所有参与此项目的测试人员:

角色

资源数量／具体人员

具体职责或注释

测试经理，

测试项目经理

进行管理监督。

职责：

提供技术指导、获取适当的资源、提供管理报告

测试设计员

确定测试用例、确定测试用例的优先级并实施测试用例。

职责:

生成测试计划、生成测试模型、评估测试工作的有效性

测试员

执行测试。

职责：

执行测试、记录结果、从错误中恢复、记录变更请求

测试系统管理员

确保测试环境和资产得到管理和维护。

职责:

管理测试系统、授予和管理角色对测试系统的访问权

数据库管理员

确保测试数据（数据库）环境和资产得到管理和维护。

职责:

管理测试数据（数据库）

2.3测试工作量

任务

开始时间

结束时间

总计（天数）

总计（人时）

计划

测试计划

测试设计

测试执行

测试总结

实际

测试计划

测试设计

测试执行

测试总结

2.4测试版本

给出测试的版本,及回归测试的次数。

建议以表格清单方式列出，便于了解各个子系统/子模块的测试频度，对于多次回归的子系统/子模块将引起开发者关注。

2.5测试功能点列表

建议以表格形式列出测试中包含的功能点列表：

需求编号

功能点概述

用例个数

是否通过

备注

2.6未测试功能点列表

建议以表格形式列出测试中未包含的功能点列表:

需求编号

功能点概述

未测试原因

[注]未测试的理由包括：

需求不明确，测试环境不具备，不支持等

3测试结果及缺陷分析

汇总各种数据并进行度量，度量包括对测试过程的度量和能力评估、对软件产品的质量度量和产品评估。

对于不需要过程度量或者相对较小的项目,例如用于验收时提交用户的测试报告、小型项目的测试报告,可省略过程方面的度量部分;而对于公司内部产品或项目测试，过程度量数据必须列出,为产品改进和缺陷预防提供参考数据。

数据应来源于测试管理系统。

3.1测试数据统计汇总

该部分统计的测试数据与“测试月度计划与报告”中数据统计部分的统计指标一致,可利用其模板计算获得。

测试阶段

／模块

基线测试用例数（个）

变更测试用例数（个）

用例总数（个）

用例执行成功数（个）

用例执行失败数（个）

未执行用例数（个）

用例执行率（%）

用例执行成功率（%）

Bｕg按时处理数（个）

Bug　超时处理数（个）

Bｕｇ总数（个）

Bug按时处理率（%）

用例产生Bug率（％）

测试阶段

/模块A

测试阶段

/模块B

测试阶段

/模块C

……

合计

3.2测试用例统计分析

描述测试用例执行情况统计图及简要分析。

3.3缺陷统计分析

3.3.1按模块、缺陷级别统计

描述按模块、缺陷级别统计图及简要分析。

3.3.2按模块、缺陷状态统计

描述按模块、缺陷状态统计图及简要分析。

3.3.3按开发人员、缺陷状态统计

描述按开发人员、缺陷状态统计图及简要分析。

3.3.4按缺陷生命周期统计

描述按Ｂｕg生命周期统计图及简要分析。

3.3.5按缺陷引入阶段统计

描述按缺陷引入阶段统计图及简要分析。

测试阶段/模块

需求阶段

设计阶段

编码阶段

发布阶段

测试阶段

/模块A

测试阶段

/模块Ｂ

测试阶段

／模块C

……

合计

3.3.6按缺陷类型统计

描述按缺陷类型统计图及简要分析。

测试阶段/模块

功能

性能

界面

文档

接口

测试阶段

／模块Ａ

测试阶段

/模块B

测试阶段

/模块C

……

合计

3.4残留缺陷汇总

3.4.1残留缺陷1

　编号：

[BＵG编号]

　缺陷概要：

该缺陷描述的事实

　原因分析：

如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因

预防和改进措施:

弥补手段和长期策略

3.4.2残留缺陷2

　　编号:

[BUG编号]

缺陷概要：

该缺陷描述的事实

　原因分析:

如何引起缺陷，缺陷的后果,描述造成软件局限性和其他限制性的原因

预防和改进措施:

弥补手段和长期策略

4测试结论与建议

4.1缺陷和限制

测试执行是否充分；

对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响；

可能存在的潜在缺陷和后续工作。

4.2建议

提出为弥补上述缺陷的建议;

对缺陷修改和产品设计的建议；

对过程改进方面的建议。

4.3测试结论

说明该测试能否通过。