软件测试报告模板.docx
《软件测试报告模板.docx》由会员分享，可在线阅读，更多相关《软件测试报告模板.docx（13页珍藏版）》请在冰点文库上搜索。
软件测试报告模板
（OA号：
OA号/无）XXX产品名称XX版本（提测日期：
YYYY.MM.dd）
第XX轮
功能/性能/稳定性/兼容性测试报告
编号
JLNXDZ-001
文件状态
[]草稿[√]正式发布[]正在修改
当前版本
V1.0．1
拟制
报告编写人名字
日期
YYYY.MM.dd
审核
组长名字
日期
YYYY.MM.dd
批准
部门经理名字
日期
YYYY.MM.dd
修订历史记录
A-增加M-修订D-删除
变更版本号
版本日期
变更类型
修改者
修订记录
1.0．1
2017-3-10
M
XXX
修改软硬件配置说明以及增加bug数据的统计、测试过程版本打包次数统计、用例覆盖率统计
1.1.1
2017-3-13
M
XXX
修改测试结果列表，增加功能、性能、稳定性等测试结果
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台
后台服务
处理器:
Intel（R）CPUE5-2603V2@1.8GHz
存：
8G
硬盘/磁盘大小：
1T
固态硬盘大小：
32G
4M
插件：
1、VC2008sp1
2、vc2010sp1
数据库：
Mysql5.6
服务：
1、身份认证服务（V1.1.2）
2、视频主控服务（V1.1.2）
Windows7旗舰版64bit
N台
客户端
处理器:
Intel（R）CPUE5-2603V2@1.8GHz
存：
4G
硬盘/磁盘大小：
1T
固态硬盘大小：
32G
插件：
1、TTS语音（可选）
2、.NETFramework4.0
3、.NETFramework4.5
IE：
1、IE11或谷歌
程序：
1、客户端（V2.3.1）
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
//灰色字体都是试用说明，实际使用的时候请去掉。
升级会员 