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