测试报告是 测试人员在测试过程中用于反映测试状况的文档，其重要性通过网上哀求、跪求、旋转360度冰天雪地各种求测试报告模块的帖子中就可见一斑。其实测试报告的 内容基本都是模板的那些，只是在实际测试过程中，如何去整理内容结构，使得报告的通常阅读者：开发人员、测试经理、产品经理、项目负责人能够一目了然地查 看想要了解的内容才是测试报告最值得注意的地方。
产品要想有广阔的市场，得需要切实了解用户的需求及感受，同理测试报告要想能够让阅读 者能够满意，也需要能将质量情况条理性地列出。通常来说，开发人员往往希望能从报告中了解缺陷的情况，而测试经理还关心用例的执行情况及覆盖率、项目责任 人则最关心还有多少问题，此次版本是否测试通过。因此测试报告根据内容的侧重点，分为『版本测试报告』和『总结测试报告』，目的也是希望不将所有内容列举 在一个报告中，造成内容臃肿繁杂。
〖版本测试报告〗
● 主要反映开发人员提交的测试版本的质量状况。
● 测试用例设计与执行、缺陷概况及问题概要是版本测试报告中的主要内容。
● 测试人员在每个轮次测试结束时编写提交。
其内容结构如下：
对版本测试报告的每个章节的编写内容进行说明：
大纲 | 子章节 | 详细内容 |
测试简介 | 测试目的 | 本次测试的背景及主要内容 |
测试资源 | 测试人员、本次测试开始和截止日期、花费工作日 |
测试环境 | 硬件环境 | 实际情况的详细列举，过低的配置、软件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力，也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。 |
软件版本 |
网络拓扑图 |
测试方法 | 无 | 本次测试的功能点、各功能点对应的测试用例设计、测试用到的测试工具 |
测试用例 | 用例分析 | 测试用例维护记录 |
用例执行情况 | 用例执行总数、通过用例数、未通过用例数、阻塞用例数 测试执行率=（已执行的用例数）/用例总数 测试用例效率=发现的缺陷总数/测试用例的数量 |
测试过程 | 缺陷统计 | 新建bug数、修复bug数、未修复bug数、bug总数 |
问题摘要 | 遗留问题、拒绝问题、挂起问题、长期验证问题、待评估问题 |
测试结果 | 资源占用 | 测试项目的启动、退出时间 测试项目的CPU占用率初始值、峰值（如果项目启动会有多个进程，则分多个进程进行统计） 测试项目的内存占用初始值、峰值 |
测试结论 | 测试结论不论仅仅只是测试通过或不通过，应该使用详细的数据来支持测试结论，需要列举的数据有: 『测试用例通过率』 『遗留bug情况』 |
备注 | 用例执行记录 | 插入测试用例的详细执行结果文档 |
资源监控记录 | 说明资源占用监控的场景，详细列举各场景的监控时长、监控内容，场景操作 |
〖总结测试报告〗
● 主要偏重于各已测试版本的缺陷变化分析，风险预估。
● 各测试版本质量情况概况统计、缺陷分布统计、风险分析是总结测试报告中的主要内容。
● 测试人员在项目发布上线前编写提交。
其内容结构如下：
对总结测试报告的每个章节的编写内容进行说明：
| 标题 | 子章节 | 详细内容 |
| 测试简介 | 测试目的 | 本次测试的背景及主要内容 |
| 测试资源 | 测试人员、第一轮测试的开始日期和最后一轮测试的截止日期、总共花费工作日统计 |
| 测试环境 | 硬件环境 | 实际情况的详细列举，过低的配置、软件版本的不匹配、网络拓扑的错误都会让提交的缺陷缺乏说服力，也会让开发人员对于某些缺陷是否由于环境因素导致而产生疑惑。 |
| 软件版本 |
| 网络拓扑图 |
| 测试过程 | 各版本测试状况 | 各测试版本的计划提交日期、实际提交日期、测试类型（回归或全量）、测试耗时、备注（被打回或提交补丁次数） |
| 各版本bug统计 | 各测试版本的新建bug数、修复bug数、遗留bug数，表格统计、线形图或饼状图辅助表示 |
| 测试分析 | 缺陷分析 | 缺陷的总体分布情况，以线形图或饼状图辅助表示 根据功能模块进行划分 根据严重、较严重、普通、轻微级别进行划分 |
| 遗留问题 | 打开状态bug、长期验证bug、用户体验问题 |
| 测试小结 | 资源占用 | 测试项目的启动、退出时间 测试项目的CPU占用率初始值、峰值（如果项目启动会有多个进程，则分多个进程进行统计） 测试项目的内存占用初始值、峰值 |
| 风险分析 | 测试进度、人员安排导致的风险 测试内容考虑范围之外导致的风险 测试环境不全面导致的风险 其他因素导致的风险 |
以上是对功能测试报告编写的总结，性能测试报告、兼容性测试报告因为内容的不同是不能套用以上测试报告的结构进行编写，功能测试报告的编写就是要做到简约而不简单。