软件测试报告模板.docx
《软件测试报告模板.docx》由会员分享，可在线阅读，更多相关《软件测试报告模板.docx（13页珍藏版）》请在冰豆网上搜索。
软件测试报告模板
第XX轮
功能/性能/稳定性/兼容性测试报告
编号
JLNXDZ-001
文件状态
[]草稿[√]正式发布[]正在修改
当前版本
V1.0．1
拟制
报告编写人名字
日期
审核
组长名字
日期
批准
部门经理名字
日期
修订历史记录
A-增加M-修订D-删除
变更版本号
版本日期
变更类型
修改者
修订记录
1.0．1
2017-3-10
M
XXX
修改软硬件配置说明以及增加bug数据的统计、测试过程版本打包次数统计、用例覆盖率统计
1.1.1
2017-3-13
M
XXX
修改测试结果列表，增加功能、性能、稳定性等测试结果
1.概述4
1.1测试目的4
1.2测试背景4
1.3测试资源投入4
1.4测试功能4
1.5术语和缩略词5
1.6测试范围5
2.测试环境6
2.1测试软件环境6
2.2测试硬件资源6
2.3测试组网图6
3.测试用例执行情况6
4.测试结果分析（大项目）7
4.1Bug趋势图7
4.2Bug严重程度7
4.3Bug模块分布7
4.4Bug来源7
5.测试结果与建议7
5.1测试结果7
5.2建议8
5.3测试差异分析8
6.测试缺陷分析8
7.未实现需求列表9
8.测试风险9
9.缺陷列表9
1.概述
1.1测试目的
本报告编写目的，指出预期读者范围。
1.2测试背景
对项目目标和目的进行简要说明，必要时包括该项目历史做一些简介。
1.3测试资源投入
测试项
测试人力
测试时间
安装&卸载&升级测试
1人×2日=2人日
2012-02-24~2012-02-26，两个工作日
功能性测试
2人×2.5日+2人×2日+2×1.5日=12人日
2012-02-27~2012-02-29,两个工作日
接口测试
稳定性测试
1人×7日=7人日
2/28~3/2，目前处于第一个阶段的稳定性测试，共,3个工作日
原计划：
2/28~3/28开始稳定性测试?
（分3个阶段执行测试：
3*24H、7*24H、30*24H）
//针对本轮测试的一个分析
//测试项：
功能测试、性能测试、稳定性测试等
//测试时间投入：
用了多少天
//测试人力投入：
需要多少人投入
//如果是稳定性测试的话，需要说明整个周期多长，当前属于第几个阶段，如上所示
1.4测试功能
1，测试功能、内容
//测试概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是介绍测试情况。
（其他测试经理和质量人员关注部分）。
//测试哪些功能，测试功能、测试步骤描述。
//测试内容大纲。
2，版本功能对比
1，与上一个版本功能对比，增加功能、修改功能、删除功能
2，增加了哪些定制功能
3，差异化功能特别介绍
4，借调设备投入：
需要借调主要设备
1.5术语和缩略词
列出本系统/项目的专用术语和缩写语。
对于技术的相关名词和与多义词注明清楚，以便查阅时产生歧义。
编号
专业术语
描述
备注
1
2
3
1.6测试过程版本打包次数
打包次数
原因
搭建环境过程
0
测试过程
0
2.测试环境
2.1测试组网图
设备连接示意图。
2.2测试软件环境
操作系统
数量
类型
配置
网络环境
安装软件/程序
Windowsserver201264bit
1台
后台服务
内存：
8G
硬盘/磁盘大小：
1T
固态硬盘大小：
32G
4M
插件：
1、VC2008sp1
2、vc2010sp1
数据库：
Mysql5.6
服务：
Windows7旗舰版64bit
N台
客户端
内存：
4G
硬盘/磁盘大小：
1T
固态硬盘大小：
32G
插件：
1、TTS语音（可选）
2、.NETFramework4.0
3、.NETFramework4.5
IE：
1、IE11或谷歌
程序：
2、搜索工具
2.3测试硬件资源
本次测试过程中，使用到的硬件使用资源包括：
设备型号/软件版本/固件版本/硬件版本：
设备名称
实测数量
设备型号/防伪编码
软件版本
固件版本
硬件版本
NVR
交换机
摄像枪
3.测试用例执行情况
3.1用例覆盖率
数量（条）
比例（%）
备注
通过数
实际通过的用例数
（通过数/用例总数）*100
不通过数
实际不通过的用例数
（不通过数/用例总数）*100
未测试数
未测试的用例数
（未测试数/用例总数）*100
本轮新增用例数
在本轮测试中，新增用例数
（新增用例数/用例总数）*100
用例总数
用例总数
3.2用例测试结果
插入测试用例测试结果的附件表。
每条测试用例需要包括：
测试结果（通过/不通过/未测试/需求未实现），测试人员等。
不通过：
需要标记出对应的bug编号，以及实际的测试结果
未测试：
需要备注未测试的原因
需求未实现：
要备注需求未实现
4.缺陷分析
4.1bug类别统计
BUG类别
新增-旧BUG引起
新增-漏测
新增-新功能
原有BUG
重新激活
总计
汇总
1
7
99
1
7
115
说明：
1）新增-漏测（上次版本未测到的BUG）
2）新增-新功能（本次版本新增功能的BUG）
3）新增-旧BUG引起（开发解BUG产生的新BUG）
4）重新激活（本次版本开发已解决，但回归发现仍然存在问题的）
5）原有BUG（本次版本开发未解决的）
4.2未关闭的bug统计
严重程度
不予解决
外部原因
无法解决
无法重现
延期处理
遗留问题
已解决
长期跟踪
重复Bug
转为需求
激活
1（致命）
2（严重）
3（一般）
4（建议/优化）
总计
4.3Bug收敛趋势图
//此bug收敛趋势图：
是统计每一轮的bug提交数和关闭数，需要线性体现趋势，如上图所示（具体可参考如下附件的统计）
-
4.4Bug严重程度（大项目）
//从缺陷工具截取，测试视图->报表->选择“Bug严重程度统计”点击生成报表，截图
//是针对没有解决的BUG的一个分析
4.5Bug模块分布（大项目）
//从缺陷工具截取，测试视图->报表->选择“模块Bug数量”点击生成报表，截图
//是针对没有解决的BUG的一个分析
5.测试结果与建议
5.1测试结果
编号
模块
测试负责人
测试结果
主要问题描述
1
视频预览
XX
不通过
配置正确，无法正常预览
2
日志统计
XX
通过
统计及日志记录功能正常，但是仍存在需要优化的问题，例如：
表单样式、搜索校验等（已提bug）
3
4
5
6
//测试结果：
针对该表格，如果是功能测试，则列出功能测试相关的统计；如果是稳定性测试，则列出稳定性相关的统计；其他项测试，以此类推。
//模块：
如果主模块下有多个子模块，主模块所在行用黑体字表示，下面是其子模块。
用非黑子体表示
//该模块的测试执行人员
//结果：
通过、不通过、未测试（备注清楚未测试原因）
//主要问题描述：
如果结果是不通过的，简述致命或是严重类问题
功能性测试结果：
性能测试结果：
可靠性测试结果：
稳定性测试结果：
兼容性测试结果：
容错性测试结果：
EMC测试结果（硬）：
安规测试结果（硬）：
环境试验结果（硬）：
热传测试结果（硬）：
总体结论：
当前版本大部分的需求已经实现，具体见《需求跟踪表》，日志统计基本功能正常，存在部分需要优化的地方。
常用的预览模块，无法正常预览。
故测试角度认为不通过。
//给出总体结论，每一项后面写清楚本轮是否测试，如果没有测试请注明原因，及计划什么时候测试。
如果已经测试写清楚结果是“通过”还是“不通过”。
//如果是外购内产品测试的话，各项功能测试结果则可去掉，可以输出一段总结性的结论。
插入定制功能验收表/外购选型类测试数据
//插入定制功能验收表：
如果是仿真测试或是定制类项目，则需要插入该表
//插入外购选型类测试数据：
如果是外购选型，则需要插入该表
5.2建议
1，测试执行是否充分
2，测试目标是否完成
3，对系统存在问题的说明，描述当前测试所揭露的缺陷和不足，以及带来的影响
4，对缺陷修改和产品设计的建议
5.3测试差异分析
1，测试环境和测试方案是否一致
2，测试用例执行是否有偏差
6.测试缺陷分析
1，缺陷发现效率：
BUG总数/天数=个/天
2，缺陷密度：
BUG总数/模块=个/模块
3，系统测试缺陷发现密度：
系统测试发现的缺陷数/测试用例数*100%＝%
7.未实现需求列表
需求编号
需求名称
需求描述
8.测试风险
编号
风险项名称
风险描述
风险影响
影响等级
//风险影响：
说明该风险对该项目的影响
//影响等级：
分高、中、低三级
9.缺陷列表
插入buglist的附件表（保留关键列即可，如下）
//从缺陷管理工具导出，以附件的形式
//测试视图->搜索->搜索出自己要导出的BUG,点击【导出】
//保留关键字段列（Bug编号、所属模块、Bug标题、严重程度、优先级、重现步骤、Bug状态、激活次数、由谁创建、创建日期、指派给、解决方案、关闭日期、bug类别、bug来源），保存成EXCEL各式。
Bug类别分为几项：
1）新增-漏测（上次版本未测到的BUG）
2）新增-新功能（本次版本新增功能的BUG）
3）新增-旧BUG引起（开发解BUG产生的新BUG）
4）重新激活（本次版本开发已解决，但回归发现仍然存在问题的）
5）原有BUG（本次版本开发未解决的）
bug来源：
分为稳定性bug、功能性bug
//灰色字体都是试用说明，实际使用的时候请去掉。
升级会员 