系统测试报告文档格式.docx
《系统测试报告文档格式.docx》由会员分享，可在线阅读，更多相关《系统测试报告文档格式.docx（15页珍藏版）》请在冰点文库上搜索。
研发经理
1.概述1
1.1编写目的1
1.2项目背景1
1.3参考资料1
1.4测试环境1
2.测试结果2
2.1千行代码缺陷率的统计结果2
2.2按照缺陷修复情况的统计结果2
2.3按照缺陷类型的统计结果3
2.4按照缺陷严重程度的统计结果4
3.评价5
3.1对被测软件的全面评估5
3.2测试环境的影响7
3.3测试结论7
3.4改进建议8
3.4.1被测软件设计和操作改进建议8
3.4.2被测软件的测试改进建议8
4．测试工作总结9
4.1人力资源消耗9
4.2测试计划差异分析9
附录：
[HIOSE1.3.0]所有缺陷列表9
1.概述
1.1编写目的
本报告编写主要有以下目的：
1、通过对测试结果的分析，得到对软件质量的评价。
2、分析测试的过程、产品、资源、信息，为以后制定测试方案提供参考
3、分析系统存在的缺陷，为预防和修复BUG提供建议。
1.2项目背景
XX市城市公共交通智能化应用示范工程公交行业决策分析系统通过整合现有公共交通资源信息，以促进公共交通管理部门与公交企业之间的信息互通互连，达到资源综合利用，实现政府掌握公交运行情况，实施行业监管，支撑信息服务等的目标。
该系统主要包含基础资源统计分析、公交运营状况分析、安全应急数据分析、线网辅助优化分析、发展水平评价等模块功能需求。
系统面向的主要用户包括：
XX市交通局及公交企业等。
1.3参考资料
需求调研报告_XX市城市公共交通智能化应用示范工程V1.0.doc产品变更设计报告_XX市城市公共交通智能化应用示范工程V1.0.docXX市城市公共交通智能化-软件系统测试方案（XX）v1.0.docOSE1.3.0测试用例库和问题追踪库
1.4测试环境
[HIOSE1.3.0]系统运行软硬件环境如下：
配置
数据库
硬件：
X3850X57145两个Xeon四核E7520（1.86GHZ,18M缓存）、32GRAM、100/1000M网卡
操作系统：
Windows2008Server64bit
数据库：
Oracle10g数据管理系统
业务服务器
X3850X57145两个Xeon四核E7520（1.86GHZ,18M缓存）32GRAM、100/1000M网卡
Windows2008Server32bit
通讯服务器
Intel（R）Xeon（R）CPUE5-2603（1.80GHz），12GRAM、100/1000M网卡
Win7（32位&
64位）；
客户端
普通双屏PC,CPU主频3.3GHz双核、4G内存操作系统：
64位）；
IE11分辨率：
1440*900
网络条件
中间件与数据库100M局域网；
客户端与服务器100M局域网
2.测试结果
2.1千行代码缺陷率的统计结果
本项目总代码行数为1379958行，有效缺陷数为185个，千行代码缺陷率为0.13。
2.2按照缺陷修复情况的统计结果
缺陷报告按照修复情况统计的结果包括：
已修复（已修复、不再重现（超三个月）、需求变更）、未修复（未修复、不修复、升级解决、正在修复、不再重现（三个月内））等
[HIOSE1.3.0]测试缺陷修复情况统计表
缺陷总数
未修复
已修复
修复率
185
2
未修复：
0
183
已修复：
183
98.92%
不修复：
1
升级解决：
不再重现（三个月
内）：
不再重现（超三个
月）：
正在修复：
注：
修复率=（已修复/错误总数）%
分析：
其中运营监管模块占比72.51%，基础设施模块缺陷占比16.59%。
[HIOSE1.3.0]遗留问题列表
Key
严重程度
概要
解决方式
问题分析
OSE-550
一般
【XX行业监管】时间控件里可以输入非法字符或者字符
升级解决
控件问题，暂时不做修复
OSE-726
【基础资源统计分析-线路数据分析】查询XX市2015-8和2015-9月份数据，公交线路分析图表中，坐标中少了一个数据。
不修
复
不影响使用，不修复
2.3按照缺陷类型的统计结果
缺陷按照缺陷类型包括：
1、产品崩溃或挂起，2、未实现的需求，3、功能错误与失效，4、性能缺陷，5、易用性，6、语言描述错误，7、安全性问题。
[HIOSE1.3.0]测试缺陷类型统计表
缺陷种类
总计
数量
百分比
产品崩溃或挂起
4
2.16%
未实现的需求
1
0.54%
功能错误与失效
138
74.59%
性能缺陷
易用性
18
9.73%
语言描述错误
20
10.81%
安全性问题
0.00%
100.00%
缺陷类型分布
产品崩溃或挂起未实现的需求功能错误与失效性能缺陷易用性语言描述错误安全性问题
表中的百分比=（每个分项的缺陷数量/总缺陷数量）%；
分析：
功能错误与失效占比为74.59%，这其中有很多是由于开发人员自测不充分导致；
如果开发人员自己充分测试后再提交测试，这一比例应该会大大降低。
2.4按照缺陷严重程度的统计结果缺陷按照缺陷严重程度包括：
1、致命，2、严重，3、主要，4、一般，5、轻微。
[HIOSE1.3.0]测试缺陷严重程度统计表
缺陷严重程度
总数
致命
严重
3
1.62%
主要
23
12.43%
142
76.76%
轻微
16
8.65%
100%
缺陷严重程度分布
0.54%1.62%
致命严重主要一般轻微
致命及严重缺陷数量为4个，占总体缺陷数量的2.16%。
行业监管主要实现业务数据结存及查询功能，所以崩溃问题相对较少，缺陷主要集中在功能实现方面，一般类型错误。
[HIOSE1.3.0]致命及严重问题列表
严重程度
模块
解决方式
OSE-697
运营监管
20150928-8【发展水平评价】【行业评价指标体系管理】对一个指标设置下级指标时允许被设置为自己，保存时出现死循环，浏览器崩溃。
OSE-711
【公交运营状况分析】【客运量分析】点击打印按钮后，页面崩溃
OSE-709
【公交运营状况分析】【站点时段客流】点击打印按钮后，页面崩溃
OSE-587
OSE-425【按类型统计客流量】点击【打印】按钮进行打印后，页面失去响应
3.评价
3.1对被测软件的全面评估
[HIOSE1.3.0]系统测试结果列表
项目编号
项目描述
测试结果
测试人
功能测试
通过
范兴华、辛丽、李芳彦、
符合需求规格书中的业务
韩飞、张雪、崔燕奇
功能要求
性能测试
辛丽、张雪
符合需求规格书中的性能
要求
安全性测试
符合需求规格书安全性要
求
易用性测试
符合需求规格书易用性要
5
兼容性测试
符合需求规格书兼容性要
6
安装测试
符合需求规格书安装升级
7
版权加密测试
符合需求规格书版权加密
8
用户手册测试
[HIOSE1.3.0]性能测试结果列表
测试项
测试次数
推荐配置下常规值
日
月
年
车辆利用率分析
1秒
班次明细记录
4秒
-
车辆日运营里程
6秒
组织日运营里程
车辆运营里程分析
车辆日运营里程和时间分析
2秒
车辆日客流
3秒
组织日客流
站点日客流
站点时段客流
客运量分析
客流与运力配置关系分析
线网时段运行速度分析
线路时段运行速度
站点时段运行速度分析
公众投诉分析
根据测试方案，运营监管系统一般只是对结存表查询，不会有特别大的数据量。
所以本次测试仅针对公交运营状况分析推荐环境下页面的响应时间是否在标准范围内。
3.2测试环境的影响
[HIOSE1.3.0]测试环境和操作环境差异分析评估
环境说明差异说明
测试环境
操作环境
网络流量
用户少,网络流量小
用户稍多,网络流量大
配置性能
测试环境和操作环境可能存在软件配置和硬件性能上的差异
操作流程
符合标准的操作流程
可能出现各种测试中无法预料的操作流程
3.3测试结论
系统测试结束标准：
1、测试用例执行率100%，测试需求覆盖率100%。
2、缺陷在每一版本呈现递减趋势。
3、最后一个版本无严重及以上缺陷，其他缺陷不超过10个。
4、主要及以上缺陷修复率达到100%，一般及轻微缺陷修复率达到85%且遗留缺陷（未解决、升级解决、不再复现、不解决）不超过20个。
形成报告，项目经理组织部门研发经理、测试经理、产品经理召开会议，完成测试报告内容及结论确认，如有测试问题不修复、延期处理由研发经理、测试经理、产品经理共同认定。
测试情况：
综合单项测试及系统测试情况，HIOSE1.3.0当前状况如下：
1、测试用例执行率100%，测试需求覆盖率100%，此标准满足。
2、缺陷在每一版本呈现递减趋势，此标准满足。
3、最后一个版本无严重及以上缺陷，其他缺陷6个，此标准满足。
4、主要及以上缺陷修复率达到100%，一般及轻微缺陷修复率达到98.9%，遗留缺陷（未解决、升级解决、不再复现、不解决）2个。
经研发经理、测试经理、产品经理共同认定，同意遗留，此标准满足。
测试结论：
HIOSE1.3.0功能、性能等各方面符合需求规格，满足系统测试出口标准。
3.4改进建议
3.4.1被测软件设计和操作改进建议
1、进一步提高编码人员的工作质量。
本次二次开发活动中，编码人员中有较多新手和外包人员，他们对系统、写代码、编码规范等不够熟悉，导致产生较多缺陷；
并且还有很多是脚本不规范，程序版本混乱的情况，耽误了开发和测试时间，也降低了质量可控性。
另外也有部分开发人员对测试人员还存在依赖心理，对测试发现的问题发现一个改一个，对于是否有可能还存在类似的问题或者是否会引起其他问题不去思考，导致后期缺陷修复成本增加。
因此项目经理应该进一步向开发人员宣贯产品质量的重要性,提高开发人员的质量意识。
2、加强程序代码检查力度。
在本次二次开发活动中，由于开发时间紧张，代码检查人员参与其他事情较多，后期很多开发任务没有经过代码检查或代码检查不充分。
在本次参与编码人员整体水平不高的情况下，应该说代码检查环节还是非常必要的。
如果这个环节不充分，那么到测试环节的压力就会比较大。
项目经理应该认真分析缺陷分布情况,加强重点模块和质量较差开发人员的代码走查力度,不能因为个人能力不足的问题导致产品质量整体下滑。
3.4.2被测软件的测试改进建议
1、准确把握用户需求，提高测试针对性。
本次二次开发项目测试人员没有参与需求调研，参与需求分析和讨论的时间也比较少，对用户需求把握不准，导致一些任务测试不够深入。
而我们的测试都应当是追溯到用户需求的。
试想如果测试人员连用户想要什么都没搞清楚的话，可能得到什么样的测试结果。
因此只有前期充分的参与需求分析，充分
的与规划人员进行沟通，才能得到比较好的测试效果。
4．测试工作总结
4.1人力资源消耗
测试任务
测试人员
测试实施日期
时间统计
（小时）
测试方案制定
范兴华
2015.07.01-2015.07.20
10
测试用例设计
辛丽、李芳彦
2015.07.21-2015.08.21
90
单项测试实施
辛丽、李芳彦、韩飞、张雪、崔燕奇
2015.08.12-2015.10.15
380
第一轮系统测试实施
张雪
2015.10.15-2015.10.23
92
第二轮系统测试实施
2015.10.23-2015.11.04
32
第三轮系统测试实施
2015.11.04-2015.11.10
测试报告编写
2015.11.10
合计
587
4.2测试计划差异分析
与测试方案计划相比，在人员上辛丽和李芳彦主要参与前两轮单项测试；
张雪、崔燕奇去XX现场参与第三、第四轮单项测试，张雪在实验室环境下进行系统测试。
人员变动比较频繁，对产品质量也可能造成风险。
[HIOSE1.3.0]所有缺陷列表
OSECS.xlsx
升级会员 