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