软件测试报告模板

 01 为什么编写测试报告

对于软件测试人员

一方面，测试报告是测试人员成果的输出，体现了测试人员的工作与成绩。另一方面，在输出测试报告时，测试人员同时也是在自行进行测试情况的分析总结，会项目组后续的项目提供建议，更好的提升质量。比如通过分析缺陷，可以为修复和预防bug提供建议；通过分析过程，可以评估执行是否和计划相符，为以后制定计划提供参考；通过对测试结果的分析，可以得到对软件质量的评价，为后续的改进提供经验。

对于其他人员，如产品、开发人员、项目管理、领导层、用户

项目的相关人员比包括但不限于产品、开发、PM、领导层、用户等，通过阅读测试报告，可以清晰的了解每个阶段产品项目的研发完成情况，测试范围，测试过程及质量情况，以及目前还存在的风险、遗留问题，测试结论与建议等，将作为产品项目能否发布上线的评判标准。

所以，测试报告是必不可少的测试文档之一。

02 测试报告类型

在测试过程中，由于按照不同的开发模型，可能会有多次迭代或版本的测试，或是不同类型的测试，如功能测试、性能测试、安全测试等，那么每一次迭代或每一个版本的测试或每种类型的测试咱们都得记录其测试情况，以便最后的汇总，所以测试报告的类型，可以分为：迭代/版本测试报告，功能测试报告，接口测试报告，性能测试报告，安全测试报告，系统测试报告等。

迭代/版本测试报告主要记录每个迭代/版本的测试情况，包括测试范围、测试环境、测试时间、测试人员、测试结果、版本Bug分析、风险等，强调反馈版本测试情况，预测后续测试走向。

功能测试报告，接口测试报告，性能测试报告，安全测试报告，系统测试报告主要记录整体测试的情况，汇总每个迭代/版本的测试结果，主要内容也包括测试范围、测试环境、测试时间、测试人员、测试结果、整体缺陷、覆盖率等分析、风险、测试结论及建议等。其中功能、接口、性能、安全等也可以都写入系统测试报告，具体按项目要求进行即可，内容大体一致。

03 举例：测试报告主要内容

测试报告的模板如下，不同公司的模板有所不同，但大体内容差不多

1、引言

编写目的，供哪些角色人员阅读等；

项目背景，介绍项目的开发背景，研发价值等；

定义，主要是对文档中的术语或定义做解释；

参考资料，主要包括《需求规格说明书》、项目计划、测试计划、测试用例、缺陷列表、行业标准规范等

2、测试概要

1）系统简介，简要描述系统信息

2）测试环境，测试需要搭建的环境信息列表及组网图等

3）测试过程，如下表：

3、测试质量评估**

1）总体评价结论

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

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

2）需求测试结果

功能测试结果：

功能性需求即按照需求规格说明书进行功能测试，测试的功能主要如下表所示：

用户界面测试结果：

本次测试计划关于用户界面测试需求主要按照需求规格说明书的要求进行测试，要进行的界面需求如下表所示：

性能测试结果：

本次测试计划关于性能测试需求主要按照需求规格说明书的要求进行测试，要进行的性能需求如下表所示：

配置测试结果：

本次测试计划关于配置测试需求主要按照需求规格说明书并结合通用测试案例的要求进行测试，要进行的配置测试需求如下表所示：

安全和访问控制测试结果：

本次测试计划关于安全测试需求主要按照需求规格说明书并结合通用测试案例的要求进行测试，要进行的安全测试需求如下表所示：

兼容性测试结果：

安装测试结果：

易用性测试结果：

3）缺陷统计分析

1.1.1. 项目Bug统计（Bug汇总）

1.1.2. 按Bug严重程度统计

测试发现的bug主要集中在未完善功能级别major，属于一般性的功能缺陷，但是测试的时候，出现了160个涉及到程序崩溃、程序启动不了、不能完成正常制证、不能完成正常印刷等严重级别的bug，出现严重级别的bug主要表现在以下几个方面：

系统的主要功能没有实现

本系统统主要功能逻辑混乱导致意外bug

后台进程在程序关闭后没有相应停止导致程序不能启动

WebAPI接口调用错误导致核心功能不可实现

1.1.3. 版本Bug数量

由上图可以看出，在统计的十个周bug提交和解决状况比较理想，当前提交的bug都能够在很快的时间得到修复，并且随着版本的稳定解决bug数量为全部解决新增bug数量逐渐降为0，整个过程属于正常的软件版本迭代过程。

或：

由Bug的版本分布图可以看出，V1.0.1-V1.0.5版本质量非常不稳定，bug数量最高达到190个，V1.0.1作为第一个版本bug数量为58个。在版本V1.0.3验证了前面发现的所有bug的基础上遗留bug数量在120个质量表现也不够稳定，在V1.1.1新增了xx、xx、xx等功能所以bug数目骤增为232个。随着版本的迭代在版本V1.2.2  bug数量逐渐将为0。

1.1.4. 模块Bug数量

由上图可以看出，bug主要分布模块是XX模块（205个）和XX模块（207个），占到了全部bug的2/3以上。而XX模块（80个）的bug分布相对来说比较少占总体百分比为7%。XX模块（39个）的bug量最少主要原因是功能比较简单。

1.1.5. 按Bug激活次数统计

开发总结，过程改进

1.1.6. 按Bug类型统计

结论：系统的问题类型主要分布于测试过程和维护过程发现影响系统运行的缺陷bug和对现有系统功能的改进improvement。Bug占所有问题类型的百分比为：97%，improvement占所有问题类型的百分比为：3%。图上结果说明系统在需求采集、程序设计工作过程中考虑十分全面极少存在功能设计遗漏问题。

1.1.7. 未关闭Bug统计

由bug状态图可以看出，打开的bug有0个，重新打开的bug有1个。已解决bug有2个，主要是版本V1.2.2中提交的界面易用性bug，而其他的304个都是已验证修复并关闭的bug。系统整体的遗留bug数量达到测试结束标准。

1.1.8. 按用例结果统计

说明：本次迭代进行了新需求测试，通过率不高，后续将在阻塞和失败的功能模块进行改进。

4）覆盖率分析

测试需求、测试用例的覆盖率说明

5）测试评估

包括功能评估、性能评估、兼容性评估、风险评估等

6）整体分析

总结测试过程中发现的缺陷主要存在哪几个方面，比如需求定义不明确，功能性错误等

4、结论与建议

对系统整体的结论和建议

5、附件

遗留问题报告、交付的测试工作产品和测试项通过情况清单为必需的附件，其余可根据实际测试内容进行裁剪，不同的测试报告根据需要可以给出不同类型的附件。附件的目的是帮助本报告的使用者理解报告，记录修改情况和有用的数据等。

以上就是测试报告中包含的所有内容模板