测试报告模板(Testing Report Template)

测试报

XX项目XX测试报告

Prepared by

拟制Date

日期

yyyy-mm-dd

Reviewed by 评审人Date

日期

yyyy-mm-dd

Approved by

批准Date

日期

yyyy-mm-dd

Revision Record 修订记录

Table of Contents 目录

1概述 (5)

2测试时间、地点及人员 (5)

3环境描述 (5)

3.1硬件配置： (5)

3.2软件配置： (5)

4测试对象质量评估 (6)

4.1总体评价结论 (6)

4.2缺陷统计 (6)

4.3缺陷分析 (7)

4.3.1测试趋势分析结果 (7)

4.3.2质量评价结果 (7)

4.3.3遗留问题风险分析与规避措施 (7)

4.4覆盖率统计 (7)

4.5性能测试评估 (8)

4.6可用性评估 (8)

4.7兼容性评估 (8)

4.8文档评估 (9)

5测试过程评估 (9)

5.1测试设计评估 (9)

5.2测试执行评估 (9)

5.2.1测试执行统计数据 (9)

5.2.2测试用例执行结果统计数据 (10)

6附件 (11)

6.1附件1：遗留问题报告 (12)

6.1.1遗留问题统计 (12)

6.1.2遗留问题列表 (12)

6.1.3其他风险和规避措施 (13)

6.2附件2：交付的测试工作产品 (13)

6.3附件3：测试项通过情况清单 (13)

6.4附件4：测试发现的所有问题列表与分析 (14)

Table List 表目录

表1测试时间、地点及人员 (5)

表2从版本缺陷统计 (6)

表3从特性统计缺陷 (6)

表4测试执行统计 (10)

表5系统测试结果统计表 (10)

表6SDV测试结果统计表 (11)

表7遗留问题统计表 (12)

Figure List 图目录

图1 错误！未定义书签。

1 概述

描述本报告是哪一个测试活动的总结，指明被测对象及其版本/修订级别。概述本次测试活动，同时，指明该测试活动所依据的测试计划，测试方案、测试用例等本测试报告文档的参考文档。

2 测试时间、地点及人员

描述本次测试的时间，地点和测试人员。

表1测试时间、地点及人员

3 环境描述

描述本次测试的测试环境。包括硬件配置、软件配置、版本配套、测试组网等，尤其要注意组网图应为测试实际组网，并对此种组网可能导致的测试风险进行描述。

硬件配置：

软件配置：

版本配套关系表

测试组网图（物理组网，即测试时实际的组网）

测试组网风险说明

3.1 硬件配置：

3.2 软件配置：

3.3 版本配套关系表

3.4 测试组网图

3.5 测试组网风险说明

4 测试对象质量评估

4.1 总体评价结论

从需求符合度、功能正确性、性能指标、运行稳定性、互联互通、文档、可用性、可维护性、兼容性、风险评估等多个维度对版本质量进行总体评价。根据上述各个维度评估的结果，给出此版本是否可用的结论。结论必须是能够代表测试部意见的明确结论，比如：

该版本满足上网条件，可以上网使用；

该版本存在质量风险，只可在XX局受限使用；

该版本存在严重质量问题，不满足上网条件等。

【建议】由于本部分对于所有的读者来说都希望在看报告时越早看到越好，因此建议放在测试对象质量评估的最前面部分，并以显著字体显示。

下面各个部分的内容是对前面结论的支撑。

4.2 缺陷统计

给出各特性或模块缺陷的分布或分类统计以及缺陷走势分析，此部分内容可采用TD缺陷管理支撑工具的“版本缺陷统计”和“缺陷走势分析”进行分析和获取，该工具可以从缺陷库中将缺陷导入进行自动统计，结果可以按版本、按缺陷分布、按问题状态统计，并能够以图表的方式直观显示，非常方便。如果手工统计的话，至少需要给出下面两方面的结果：

1、以版本为单位的缺陷统计，示例格式如下：

表2从版本缺陷统计(单位：个)

表3从特性统计缺陷(单位：个)

4.3 缺陷分析

缺陷分析的目的是为了得出：缺陷原因、缺陷趋势、遗留缺陷以及规避措施等。可结合ODC、Gompertz缺陷分析和四象限缺陷等方法对特性/模块的测试充分性和特性/模块的质量进行评估；

由于ODC、Gompertz、四象限等方法使用有一定局限性，有些情况下不能很好开展，那么对缺陷的分析可由测试组定性给出，定性的结论应包括：

测试趋势

质量评价

遗留问题风险分析

遗留问题规避

4.3.1 测试趋势分析结果

在此提供Gompertz缺陷分析结果，给出版本缺陷走势，此阶段如果不做Gompertz分析也应以文字描述的形式给出测试趋势预测，比如：通过N轮的测试，测试问题的发现趋势是否是收敛的，发布前遗留问题是否在版本正常运行可以允许的范围内

4.3.2 质量评价结果

在此提供四象限缺陷分析结果，如果未做四象限分析则要求根据四象限的原则对版本特性的测试工作量投入和遗留缺陷密度进行定性的分析，从发现问题和遗留问题的角度，对版本各个子系统/模块/特性的质量进行评价。比如，XX模块的发现XX个问题，其中XX个问题是严重影响系统运行的问题，XX模块质量差。

4.3.3 遗留问题风险分析与规避措施

对遗留问题按级别进行分类，并分别对其风险进行分析，风险分析的内容应该是切中要害的，用词准确的，严禁含糊其辞。

遗留问题的规避措施避免盲目给出，应该有测试人员和开发人员共同商讨后决定，规避措施必须是可操作性强的，尤其应该考虑到现场用服兄弟的可操作性。

4.4 覆盖率统计

给出各特性/模块的设计需求覆盖情况，可直接引用需求跟踪结果；覆盖率统计对于

版本决策者具有重要的意义，一定要提供详细的覆盖率统计。原则上，对于测试策略确定的测试范围及选定的测试用例执行覆盖率应该达到100％，对于不能达到100％覆盖率的版本应该给出测试、项目经理等共同认可的原因，相关原因的分析应该在此处明确给出作为版本测试回溯的依据，原则上环境不充分，技能不具备不能成为版本不测试，测试不充分的理由。测试没有覆盖到的部分，还应进行详细的风险分析。

表4覆盖率统计列表

4.5 性能测试评估

性能测试结论应该按如下方式给出：

对于指标类测试目的，明确给出某种测试条件下（软硬件配置、数据量、话务模型等）下的主要性能指标。

对于稳定类测试目的，明确给出系统总体是否稳定的结论，或者系统哪些特性稳定，那些特性不稳定的结论。

对于对比类测试目的，明确给出对各种对比系统的测试结论，说明各种对比系统中那种性能表现好、那种性能表现差。

对于验证类测试目的，明确给出验证结果，主要是有没有达到要求、可不可行。

对于优化类测试目的，按优化的优先级给出重要的各种优化方向，并说明可能的优化效果。

4.6 可用性评估

主要对被测对象的可学习性，提示一致性，界面美观性，容错性，使用效率等给出评价。评价结果可以直接引用可用性测试活动中的系统可用性得分及满意度调查结果。如果没有进行正规的体验测试，可以请测试人员写下自身对版本可用性和可服务性的主观感受，但不应有模糊的评价，应旗帜鲜明，好用指出哪里好用，不好用应指出哪里不好用。

4.7 兼容性评估

对被测对象的版本兼容性、硬件平台兼容性、操作系统兼容性给出明确的结论。没有测过的要说明没有测过，提醒上下游注意版本在正确的环境下使用。

4.8 文档评估

对提供给现场和用户的文档，从正确性、易理解性等方面给出评价。如果版本的文档进行了资料测试，可以直接引用资料测试的结论；如果版本未经资料测试，需要版本测试人员对文档进行正确性、易用性方面的评价。

表5文档质量评估

5 测试过程评估

5.1 测试设计评估

对测试设计的全面性（从策略角度出发，例如是否进行了性能测试、双机测试、场景测试等）、有效性（即用例命中率）进行评价，找出不足作为后续设计的改进目标。涵盖的交付件包括方案、策略、用例、自动化等。

在测试过程中形成的对测试方案、测试用例的优化策略请在测试策略文档中更新；对具体测试方案和测试用例的优化和补充请在测试方案文档和测试用例库中更新。

5.2 测试执行评估

提供对本次测试活动的测试执行过程的评估结论。描述对测试执行活动的改进建议，以供后续测试执行活动中借鉴参考；

测试执行活动评估结论可依据以下提供的“测试执行统计数据”及“测试用例执行结果统计数据”进行分析而给出。

5.2.1 测试执行统计数据

本节的目的是提供足够的测试数据以满足第5节“测试评估”的需要。本节内容除下

面这个汇总表必填外，其他可以根据实际测试情况进行相应裁剪。

表6测试执行统计

工作量投入－－与本活动相关的所有工作量投入，包括测试计划、方案、用例、脚本、执行等所有与本测试相关的活动所花的投入，单位“人天”；不包括以前已经统计的投入，不包括开局、用户支援等非测试相关投入；

总测试用例数－－到本测试活动结束时，本测试活动中所有可用测试用例数，单元测试用例数、集成测试用例数、系统测试、SDV测试用例数分开；

新增测试用例数－－在本测试活动中新增加的测试用例数。如果是新产品的第一次总结，新增测试用例数包括从老版本继承来的可用测试用例数；

手工执行用例数――在本测试活动中人工执行测试用例数，多次重复执行同一用例计算为1个

自动执行用例数――在本测试活动中采用工具自动执行的测试用例数，重复用例计算为1个

发现缺陷数－－本测试活动总共发现的缺陷数；

代码规模－－适用于软件类的产品规模统计，如果是单板硬件或逻辑，本栏目中移植代码行数、新增代码行数应改成网络标注数或逻辑门数。

移植代码行数－－从其他产品移植的，后从老产品继承的、未经过修改的代码行数，不包括注释；

非移植代码行数－－除移植代码以外的代码，不包括注释。

5.2.2 测试用例执行结果统计数据

对本次测试用例执行结果进行统计，其中的字段可根据实际情况进行设计和裁剪：详细的测试项通过情况清单放在附件部分。

表7系统测试结果统计表

表8

SDV(第一轮)测试结果统计表

表9

其中：Pass：测试结果与测试用例预期结果符合;Fail：测试结果不符合测试用例预期结果;Block：测试用例步骤无法执行;Cancel：因用例本身错误的无效用例

6 附件

遗留问题报告、交付的测试工作产品和测试项通过情况清单为必需的附件，其余可根

据实际测试内容进行裁剪，不同的测试报告根据需要可以给出不同类型的附件。附件的目的是帮助本报告的使用者理解报告，记录修改情况和有用的数据等。

6.1 附件1：遗留问题报告

如存在独立的遗留问题报告文档，可在此直接粘贴文档；如无，可按以下内容填写；

6.1.1 遗留问题统计

遗留问题是指测试过程中发生的并且在测试报告时仍没有得到解决的测试问题。测试报告时已经得到解决，并已经过回归验证的测试问题不记入其中。

在详细的遗留问题报告前可以先建立一个遗留问题统计表格，以便对遗留问题的相关分布信息有整体的了解，如果遗留问题数比较少，可以将此表格省去，因此此表格根据实际情况可选。建立遗留问题统计表格，可对遗留问题数和级别进行统计，包括问题总数，致命，严重，一般和提示问题的数目及百分比等，遗留问题统计一般可用以下表格描述，其中的字段可根据实际情况进行设计和裁剪：

表10遗留问题统计表

6.1.2 遗留问题列表

以下部分详细记录每一个遗留问题，也可视时间情况只详细记录问题级别比较高的遗留问题，低级别的遗留问题采用简单列表进行罗列。所有进行详细记录的遗留问题都统一采用表格的形式来描述，表格形式如下：

问题1名称

6.1.3 其他风险和规避措施

描述被测对象在运行时，除遗留问题列表中描述之外的其他需注意的操作规避措施，包括但不限于测试过程中发现的需要下游部门注意的版本问题。

6.2 附件2：交付的测试工作产品

指明本测试完成后交付的测试文档、测试代码及测试工具等测试工作产品，以及指明配置管理位置和物理媒介等，一般包括但不限于如下工作产品：

1.测试计划

2.测试策略

3.测试方案

4.测试用例

5.测试报告

6.测试输入及输出数据

7.测试工具

8.测试代码及设计文档

6.3 附件3：测试项通过情况清单

对所有进行的测试项结果以列表的形式反映，注意其中的测试条目编号应与测试方案或测试用例中的测试编号一致，以便查对。该表格的格式建议和测试用例的表格格式保持

一致，主要考虑可以方便的进行拷贝，也可选择采用如下的表格形式进行描述：

测试结论分为以下几类：

Pass：测试结果与测试用例预期结果符合

Fail：测试结果不符合测试用例预期结果

Block：测试用例步骤无法执行

Cancel：因用例本身错误的无效用例

斜线：无需测试项及非测试内容

6.4 附件4：测试发现的所有问题列表与分析