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