修订历史记录

版本号	修订日期	AMD	修订人	修订内容说明

（N-新建，A-添加，M-修改，D-删除）

目录

1.    项目简介... 4

1.1      编写文档目的... 4

1.2      项目简述... 4

1.3      定义... 4

1.4      参考文档... 4

2.    测试概要... 4

2.1      测试用例设计方法和工具... 4

2.2      测试环境与配置... 4

3.    测试情况... 4

3.1      测试版本情况... 4

3.2      差异... 4

3.3      测试充分性评价... 4

3.4      测试组织... 5

3.4.1       测试时间... 5

4.    测试结果及分析... 5

4.1      测试情况统计分析... 5

4.2      覆盖分析... 5

4.2.1       需求覆盖... 5

4.2.2       测试覆盖... 5

4.3      缺陷的统计与分析... 6

4.3.1       缺陷汇总... 6

4.4      缺陷分析... 6

5.    测试结论... 6

5.1      残留缺陷与未解决问题... 6

6.    批准... 6

XXXXXX测试报告

1.     项目简介

1.1     编写文档目的

本测试报告反映在<项目名称>的一个版本内的质量情况。包含该版本经开发部发布后测试组的接受结果与原因、存在的问题描述与分析。

1.2     项目简述

简单介绍项目概况（参照功能说明书）。

1.3     定义

列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以便阅读时不会产生歧义。

1.4     参考文档

1．需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的文档。

2．测试使用的国家标准、行业指标、公司规范和质量手册等等。

 

2.     测试概要

测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经理和质量人员关注部分）。归纳对测试项的评价，指明被测试项及其版本修订级别指出测试活动的发生环境，对于每个测试项如果存在测试计，划测试设计说明，测试规程说明，测试项传递报告，测试日志和测试事件报告等文件则可以引用它们。

2.1     测试用例设计方法和工具

简要介绍测试用例的设计方法和工具。例如：等价类划分、边界值、因果图，以及用这类方法

提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。重点测试部分一定要保证有两种以上不同的用例设计方法。

2.2     测试环境与配置

    简要介绍测试环境及其配置。

    提示：清单如下，如果系统/项目比较大，则用表格方式列出

 

3.     测试情况

3.1     测试版本情况

测试版本版本号，是否接受该版本以及原因表述

3.2     差异

报告测试项与它们的设计说明之间的差别并指出与测试计划测试设计说明或测试规程说明中

描述或涉及的测试间的差别说明产生差别的原因。

3.3     测试充分性评价

根据测试计划规定的充分性准则如果存在的话对测试过程作充分性评价指出未被充分测试

的特性或特性组合并说明理由。

3.4     测试组织

总结主要的测试活动和事件总结资源消耗数据如人员的总体水平总机时和每项主要测试

活动所花费的时间

3.4.1     测试时间

    列出测试的跨度和工作量，最好区分测试文档和活动的时间。数据可供过程度量使用。
例如 对XXX子系统/子功能

子系统/子模块	实际开始时间	实际结束时间	总工时/总工作日

 

测试人员用工统计

角色	开始时间	结束时间	总计

 

4.     测试结果及分析

总结测试的结果指出所有已解决的事件并总结其解决方法指出尚未解决的事件

4.1     测试情况统计分析

 列举发现问题数量，属于问题数量（包含确认通过问题数量、确认未通过问题数量、以后版本修改数量、需求问题数量、不修改问题数量），不属于问题数量。

a、  合格率（以案例数）= 测试通过案例数/使用测试案例总数；

b、  合格率（以联机交易数）= 测试通过联机交易数/需要测试联机交易总数；

c、  合格率（以批量报表数）= 测试通过报表数/需要测试报表总数；

d、  测试完成率 = 使用案例数/设计案例总数；

若测试完成率≠100%时，须文字加以说明

e、  问题更正率=问题修改确认通过数/出现问题案例总数；

描述系统的实现能力、缺陷和限制、建议和评价；

 

4.2     覆盖分析

4.2.1     需求覆盖

需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。

指出 需求/功能（或编号） 测试类型 是否通过 备注

根据测试结果 ，按编号给出每一测试需求的通过与否结论。P表示部分通过，N/A表示不可测试或者用例不适用。实际上，需求跟踪矩阵列出了一一对应的用例情况以避免遗漏，此表作用为传达需求的测试信息以供检查和审核。

需求覆盖率计算 Y项/需求总数 ×100％

4.2.2     测试覆盖

   指出 需求/功能（或编号） 用例个数 执行总数 未执行 未/漏测分析和原因

    实际上，测试用例已经记载了预期结果数据，测试缺陷上说明了实测结果数据和与预期结果数据的偏差；因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差，列表的目的仅在于更好的查看测试结果。

测试覆盖率计算执行数/用例总数 ×100％

4.3     缺陷的统计与分析

缺陷统计主要涉及到被测系统的质量，

4.3.1     缺陷汇总

将被测系统，进行的单元，集成，系统测试， 回归测试，进行总计。还可以按缺陷类型， (用户界面 一致性 功能 算法 接口文档 用户界面 )进行统计。

4.4     缺陷分析

本部分对上述缺陷和其他收集数据进行综合分析缺陷综合分析

缺陷发现效率 ＝ 缺陷总数/执行测试用时

可到具体人员得出平均指标

用例质量 ＝ 缺陷总数/测试用例总数 ×100％

缺陷密度 ＝ 缺陷总数/功能点总数

缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷最多，测试缺陷越多的部分，其隐藏的缺陷也越多。

5.     测试结论

5.1     残留缺陷与未解决问题

1． 测试执行是否充分（对安全性、可靠性、可维护性和功能性描述）
2． 对测试风险的控制措施和成效
3． 测试目标是否完成
4． 测试是否通过
5、记录下缺陷和未解决的问题

残留缺陷

编号：

BUG号

缺陷概要：

该缺陷描述的事实

原因分析：如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因
预防和改进措施：弥补手段和长期策略

未解决问题

功能/测试类型：

测试结果：与预期结果的偏差

缺陷：具体描述

评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响

6、建议与其他

针对存在问题或其他的建议

6.     批准

规定本报告必须由哪些人姓名和职务审批并为签名和日期留出位置