软件系统测试总结报告模版.docx
- 文档编号:28075516
- 上传时间:2023-07-08
- 格式:DOCX
- 页数:13
- 大小:45.61KB
软件系统测试总结报告模版.docx
《软件系统测试总结报告模版.docx》由会员分享,可在线阅读,更多相关《软件系统测试总结报告模版.docx(13页珍藏版)》请在冰豆网上搜索。
软件系统测试总结报告模版
文件编号
版本号
V1.0
页码
编制人/部门
审批人
编制日期
发放对象
研发部
软件系统测试总结报告模板
文件修改控制
序号
版本
*变化状态
修改内容、页码及条款
修改人
批准人
修改日期
1
V1.0
A
初稿
*变化状态:
A——增加,M——修改,D——删除
引言
1.1编写目的
编写该系统测试总结报告主要有以下几个目的:
1)通过对测试结果的分析,得到对软件质量的评价
2)分析测试的过程,产品,资源,信息,为以后制定测试计划提供参考
3)评估测试测试执行和测试计划是否符合
4)分析系统存在的缺陷,为修复和预防bug提供建议
1.2背景
该项目背景介绍(背景重心放到测试方面)
1.3用户群体
主要读者:
XX项目负责人,XX项目测试负责人,XX项目客户代表。
以及对项目测试过程关注的其他人员。
1.4测试对象
测试相关模块二维表格,可概括为测试范围。
1.5测试阶段
集成测试、系统测试
1.6测试工具
测试工具、过程管理工具以及对特定功能编写的辅助测试工具
1.7参考资料
《XX用户需求说明书》
《XX项目需求说明书》
《XX系统架构说明书》
《XX详细设计说明书》
《XX数据库设计说明书》…
2测试概要
X后台管理系统测试从2016年X月X日开始到2016年X月X日结束,共持续X天,测试功能点X个,执行X个测试用例,平均每个功能点执行测试用例X个,测试共发现X个bug,其中严重级别的bugX个,无效bugX个,平均每个测试功能点X个bug。
XX总共发布X个测试版本,其中B1—B5为计划内迭代开发版本(针对项目计划的基线标识),B6-B8为回归测试版本。
计划内测试版本,B1—B4测试进度依照项目计划时间准时完成测试并提交报告,其中B4版本推迟一天发布版本,测试通过增加一个人日,准时完成测试。
B5版本推迟发布2天,测试增加2个人日,准时完成测试。
B6-B11划外回归测试版本,测试增加1个工作人日的资源,准时完成测试。
X测试通过X缺陷管理工具进行缺陷跟踪管理,B1—B4测试阶段都有详细的bug分析表和阶段测试报告。
2.1进度回顾
版本/时间
计划开始时间
实际开始时间
计划完成时间
实际完成时间
加班
增加资源
B1
否
否
B2
否
否
B3
否
2人日
B4
否
否
B5
1人日
否
B6
否
1人日
B7
2人日
否
B8
否
否
B9
否
否
B10
否
否
B11
否
否
总计
3人日
3人日
注意:
B*代表测试的版本。
2.2测试执行
此次测试严格按照项目计划和测试计划执行,按时完成了测试计划规定的测试对象的测试。
针对测试计划规定的测试策略,在测试执行中都有体现,在测试执行过程中,依据测试计划和测试用例,对系统进行了完整的测试。
2.3测试要点回顾
2.3.1功能性
功能类别
功能子类
Bug总数
修复数
未修复数
测试结果
Windows库
XXXX
1
1
0
通过
XXXX
1
1
0
通过
Android库
XXXX
0
0
0
通过
XXXXX
1
1
0
通过
2.3.2易用性
1)Windows库接口简单,使用方便
2)Android库提供基类方式调用
3)提供demo
2.3.3安装测试
无
2.3.4文档测试
文档测试项
测试项描述
测试指标要求
用户文档测试
用户手册
读者群、术语、正确性、完整性、一致性、易用性、图表与界面截图、样例和示例、语言主、印刷与包装
读者群。
文档面向的读者定位要明确。
对于初级用户、中级用户以及高级用户应该有不同的定位。
术语。
文档中用到的术语要适用于定位的读者群,用法一致,标准定义与业界规范相吻合。
正确性。
测试中需检查所有信息是否真实正确,查找由于过期产品说明书和销售人员夸大事实而导致的错误。
完整性。
对照软件界面检查是否有重要的分支没有描述到,甚至是否有整个大模块没有描述到。
完整性。
对照软件界面检查是否有重要的分支没有描述到,甚至是否有整个大模块没有描述到。
一致性。
按照文档描述的操作执行后,检查软件返回的结果是否与文档描述相同。
易用性。
对关键步骤以粗体或背景色给用户以提示,合理的页面布局、适量的图表都可以给用户更高的易用性。
需要注意的是文档要有助于用户排除错误,不但描述正确操作,也要描述错误处理办法。
文档对于用户看到的错误信息应当有更详细的文档解释。
图表与界面截图。
检查所有图表与界面截图是否与发行版本相同。
样例和示例。
像用户一样载入和使用样例。
如果是一段程序,就输入数据并执行它。
以每一个模版制作文件,确认它们的正确性。
语言。
不出现错别字,不要出现有二义性的说法。
特别要注意的是屏幕截图或绘制图形中的文字。
印刷与包装。
检查印刷质量;手册厚度与开本是否合适;包装盒的大小是否合适;有没有零碎易丢失的小部件等。
2.3.5接口测试
功能类别
接口名称
Bug总数
修复数
未修复数
测试结果
Windows库
XXXX
1
1
0
通过
XXXX
1
1
0
通过
Android库
XXXX
0
0
0
通过
XXXXX
1
1
0
通过
3测试环境
3.1.1软硬件环境
测试PC,测试手机
测试PC
Android手机
硬件配置
CPU:
Intel(R)Core(TM)CPU2.09GHz
Memory:
3.96GB
CPU:
单核
Memory:
1G
软件配置
OS:
windows7
OS:
android2.3.6
4测试结果
4.1Bug趋势图
此次黑盒测试总共发布11个版本,B1—B5为计划内迭代开发版本(针对项目计划的基线标识),B6-B11为进行的回归测试版本,bug版本趋势图如下图所示:
第一阶段,增量确认测试:
时间从2016年3月2日到2016年5月10日。
从Bug趋势图中可以看出,每个版本的bug数基本维持在X个左右。
B1:
从图中看到B1共有X个BUG,因为B1版本有一个功能模块在B2版本才开始测试,B1测试模块相对较少,所以B1版本bug相对较少。
B2:
由于B1中的一个功能模块增加到Build2中进行测试,这一版本除了对B1中的BUG进行验证同时对B1进行了回归测试,所以B2中的bug数相对B1出现了明显的增长趋势,
B3:
B3版本因为有B2版本的bug验收测试,以及B1,B2的回归测试,共发现67个bug,和基本保持一致。
B4:
B4版本bug数有一个下降的趋势,是因为B4版本推迟发布,新增加了测试人员参与测试,对系统不够熟悉,以及测试时间紧张,部分测试用例没有执行,测试覆盖度不够,所以发现bug数呈下降趋势。
B5:
B5版本bug数又有一个增加的趋势,主要是由于开发功能模块多,该版本需求定义不明确。
第二阶段,BUG验证和功能回归确认测试。
时间从2016年X月X日到2016年X月X日。
B6和B7进行了回归测试,B8没有进行回归测试,只验证了B1-B7的bug。
B6:
进行第一轮回归测试,发现的bug数为X个,遗留一个问题,为数据字典种类默认值问题
B7:
进行第二轮回归测试,第一次回归测试没有涉及到权限控制菜单按钮的测试,在本次回归测试的时候,重点进行了这个方面的测试,又发现了大量的权限相关的bug。
B8:
B8没有进行全面的回归测试,只验证了B1-B7未通过验证的bug,所以该版本的bug数明显比较少。
B9:
B9版本进行了全面的回归测试,同时重点测试了权限控制,所以发先的bug数又呈现上升的趋势。
测试发现X个bug,严重级别的bug为X个,严重级别的bug集中在权限控制上,功能性严重bug没有发现,说明权限控制依旧不稳定,但是系统功能已经稳定。
B10:
B10版本验证了B9版本发现得bug,没有进行全面的回归测试。
B10版本在验证bug的时候,重现打开BugX个,新增bug2个,重新打开bug有X个为严重级别bug,是关于权限控制的bug,而新发现的bug,X个为严重级别的bug,也是属于权限控制的。
说明,权限控制还存在着问题,需要修改权限管理bug,重新发布版本后进行全面的回归测试。
B10版本新发现的bug详细分析见遗留bug分析。
B11:
B11中验证了B1—B10未验证的bug,重点测试了权限控制,同时进行了查询,添加,删除,修改的功能测试,测试过程中未发现bug。
4.2Bug级别分布
由bug级别分布图可以看出,致命bug3个,严重bug5个,一般bug23个,细微bug31个。
Bug状态分布
由bug状态图可以看出,未解决的bug有4个,主要是B8中新提交的bug,是关于用户管理的bug,因为用户权限管理需要重新设计所以,该部分的bug暂时没有解决。
4.3功能Bug分布
由功能bug分布图可以看出,功能2模块的bug有X个,主要是B8中新提交的bug,是关于用户管理的bug,因为用户权限管理需要重新设计所以,该部分的bug暂时没有解决。
4.4缺陷密度
缺陷密度是以每个开发阶段统计的缺陷数量除以总的功能点数量,进行分类统计。
称为缺陷密度。
缺陷密度=缺陷数量/功能点的数量
测试中功能点数为X个,bug总数为Y个,缺陷密度=X/Y=Z,缺陷密度为Z。
5分析摘要
5.1覆盖率
在本项目中用户需求n1个,项目需求n2个,根据用户需求说明书和项目需求说明书,共设计测试要点n3个,其中n4点归为功能测试要点,n5点归为性能测试要点,其中功能性测试要点在经过3轮测试,第一轮测试要点覆盖需求n6个,第二轮测试要点覆盖需求n7个,第三轮测试要点覆盖需求n8个,第一轮测试覆盖率为:
(n6/n2)*100%=A%,第二轮测试覆盖率为:
(n7/n2)*100%=B%,第三轮测试覆盖率为:
(n8/n2)*100%=C%,所以综合覆盖率为:
(A%+B%+C%)/3=D%,最终覆盖率为:
C%。
5.2遗留缺陷影响
缺陷描述:
XXXXXXX
缺陷影响:
距离字段无单位说明,无衡量标准,用户易用性不好
推迟原因:
需求定义无单位定义,统一在升级版本中解决
确认结论:
优化/升级/二期中修订
5.3过程问题及建议
(包含过程问题等所有问题的改进建议)
1)在项目开始的时候应该制定编码标准,数据库标准,需求变更标准,开发和测试人员都严格按照标准进行,可以在后期减少因为开发,测试不一致而导致的问题,同时也可以降低沟通成本。
2)发布版本的时候,正确布置测试环境,减少因为测试环境,测试数据库数据的问题而出现的无效bug。
3)开发人员解决bug的时候,填写bug原因以及解决方式,方便bug的跟踪。
4)开发人员在开发版本上发现bug,可以通知测试人员,因为开发人员发现的bug很有可能在测试版本上出现,而测试人员和开发人员的思路不同,有可能测试人员没有发现该bug,而且,这样可以保证发现的bug都能够被跟踪。
6资源消耗
测试时间
2016年X月X日至2016年X月X日共X天
测试人力
1人*7天+1人*35天=42人天
硬件资源
服务器:
客户端:
终端:
………
7测试结论
整体结论描述
7.1功能性
(所有功能需求,以及区别以往系统特性需求的处理机制是否已正确实现,相关流程及处理机制特点如下:
1)系统正确实现了XXXX,其中包括X、Y、Z等业务流程。
2)系统正确实现了XX业务流程……
3)系统正确实现了XXX业务,断点续传,增量名单报警,联机认证
4)……
7.2易用性
现有系统实现了如下易用性:
1)查询,添加,删除,修改操作相关提示信息的一致性,可理解性
2)输入限制的正确性
3)输入限制提示信息的正确性,可理解性,一致性
现有系统存在如下易用性缺陷:
1)界面排版不美观
2)输入,输出字段的可理解性差
3)输入缺少解释性说明
4)中英文对应的正确性
5)中英文混排
6)……
7.3可靠性
1)单个工作站承载的最大设备数量
2)数据量
3)容错性
4)平均无故障时间(7*24H)
5)可恢复性
6)数据上传效率
7)……
7.4兼容性
数据库
浏览器
Windows系列操纵系统(32位64位)
硬件(UKEY\相机等)
……
7.5安全性
现有系统控制了以下安全性问题:
1)权限
2)配置信息加密
3)用户密码验证码
4)黑白名单机制
5)系统报警
6)UKEY认证
7)SOAP认证
8)终端认证
9)联机认证
10)反SQL注入
11)……
注意:
所有斜体字部分是为了提示所写内容,在正式使用的时候需删除。
根据实际情况增加或删减内容
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件 系统 测试 总结报告 模版