系统测试报告
软件系统测试报告
项目名称：XXX智能公交平台_行业监管与决策支持系统
项目类型：二次开发
编制：张X 2016 年 3 月10 日
审核：贾XX 2016 年 3 月10 日
批准：杨XX 2016 年 3 月10 日
版本历史
文档审阅信息
文档批准信息
目录
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)
附录：[HIOSE 1.3.0] 所有缺陷列表 (9)
1.概述
1.1编写目的
本报告编写主要有以下目的：
1、通过对测试结果的分析，得到对软件质量的评价。
2、分析测试的过程、产品、资源、信息，为以后制定测试方案提供参考
3、分析系统存在的缺陷，为预防和修复BUG提供建议。
1.2项目背景
XX 市城市公共交通智能化应用示范工程公交行业决策分析系统通过整合现有公共交通资源信息，以促进公共交通管理部门与公交企业之间的信息互通互连，达到资源综合利用，实现政府掌握公交运行情况，实施行业监管，支撑信息服务等的目标。
该系统主要包含基础资源统计分析、公交运营状况分析、安全应急数据分析、线网辅助优化分析、发展水平评价等模块功能需求。
系统面向的主要用户包括：XX 市交通局及公交企业等。
1.3参考资料
需求调研报告_XX市城市公共交通智能化应用示范工程V1.0.doc 产品
变更设计报告_XX市城市公共交通智能化应用示范工程V1.0.doc XX市
城市公共交通智能化- 软件系统测试方案(XX)v1.0.doc OSE 1.3.0 测
试用例库和问题追踪库
1.4 测试环境
[HIOSE1.3.0] 系统运行软硬件环境如下：
2.测试结果
2.1千行代码缺陷率的统计结果
本项目总代码行数为1379958行，有效缺陷数为185 个，千行代码缺陷率为0.13 。
2.2按照缺陷修复情况的统计结果
缺陷报告按照修复情况统计的结果包括：已修复（已修复、不再重现（超三个月）、需求变更）、未修复（未修复、不修复、升级解决、正在修复、不再重现（三个月内））等
[HIOSE 1.3.0] 测试缺陷修复情况统计表
注：修复率= （已修复/ 错误总数）%
分析：其中运营监管模块占比72.51%，基础设施模块缺陷占比16.59%。
[HIOSE 1.3.0] 遗留问题列表
2.3按照缺陷类型的统计结果
缺陷按照缺陷类型包括：1 、产品崩溃或挂起，2、未实现的需求，3、功能错误与失效，4、性能缺陷，5、易用性，6、语言描述错误，7、安全性问题。
[HIOSE 1.3.0] 测试缺陷类型统计表
缺陷类型分布
产品崩溃或挂起未实现的需求功能错误与失
效性能缺陷易用性语言描述错误安全性问
题
2.16%
注：表中的百分比= （每个分项
的缺陷数量/ 总缺陷数量）%；分析：功能错误与失效占比为74.59%，这其中有很多是由于开发人员自测不充分导致；如果开发人员自己充分测试后再提交测试，这一比例应该会大大降低。
2.4按照缺陷严重程度的统计结果缺陷按照缺陷严重程度包括：1 、致命，2、严重，3、主要，4、一般，5、轻微。
[HIOSE 1.3.0] 测试缺陷严重程度统计表
缺陷严重程度总数百分比
致命 1 0.54%
严重 3 1.62%
主要23 12.43%
一般142 76.76%
轻微16 8.65%
总计185 100%
缺陷严重程度分布
0.54% 1.62% 8.65%
致命 严重 主要 一般 轻微
注：表中的百分比 = （每个分项
的缺陷数量 / 总缺陷数量） %；
分析：致命及严重缺陷数量为 4 个，占总体缺陷数量的 2.16%。行业监管主要 实现业务数据结存及查询功能，所以崩溃问题相对较少，缺陷主要集中在功能 实现方面，一般类型错误。
致命及严重问题列表
Key
严重程度
模块
概要
解决方式 OSE-697 致命
运营监管
20150928-8 【发展水平评价】【行业
评 价指标体系管理】对一个指标设置下 级指标时允许被设置为自己，保存时 出现死循环，浏览器崩溃。
已修复
OSE-711 严重 运营监管 【公交运营状况分析】 【客运量分析】 点击打印按钮后，页面崩溃
已修复 OSE-709 严重 运营监管 【公交运营状况分析】 【站点时段客 流】点击打印按钮后，页面崩溃
已修复 OSE-587 严重
运营监管
OSE-425 【按类型统计客流量】点击
【打印】按钮进行打印后，页面失去 响应
已修复
3. 评价
3.1 对被测软件的全面评估
[HIOSE 1.3.0] 系统测试结果列表
项目 编号
项目描述 测试结果 测试人 备注
1 功能测试 通过
范兴华、辛丽、李芳彦、 符合需求规格书中的业务
12.43%
76.76%
[HIOSE 1.3.0] 性能测试结果列表
根据测试方案，运营监管系统一般只是对结存表查询，不会有特别大的数据量。所以本次测试仅针对公交运营状况分析推荐环境下页面的响应时间是否在标准范围内。
3.2测试环境的影响
[HIOSE 1.3.0] 测试环境和操作环境差异分析评估
3.3测试结论
系统测试结束标准：
1、测试用例执行率100%，测试需求覆盖率100%。
2、缺陷在每一版本呈现递减趋势。
3、最后一个版本无严重及以上缺陷，其他缺陷不超过10 个。
4、主要及以上缺陷修复率达到100%，一般及轻微缺陷修复率达到85%且遗
留缺陷（未解决、升级解决、不再复现、不解决）不超过20 个。形成报告，项目经理组织部门研发经理、测试经理、产品经理召开会议，完成测试报告内容及结论确认，如有测试问题不修复、延期处理由研发经理、测试经理、产品经理共同认定。
测试情况：
综合单项测试及系统测试情况，HIOSE 1.3.0 当前状况如下：
1、测试用例执行率100%，测试需求覆盖率100%，此标准满足。
2、缺陷在每一版本呈现递减趋势，此标准满足。
3、最后一个版本无严重及以上缺陷，其他缺陷6 个，此标准满足。
4、主要及以上缺陷修复率达到100%，一般及轻微缺陷修复率达到98.9%，
遗留缺陷（未解决、升级解决、不再复现、不解决）2 个。经研发经理、测试经理、产品经理共同认定，同意遗留，此标准满足。
测试结论：
HIOSE 1.3.0 功能、性能等各方面符合需求规格，满足系统测试出口标准。
3.4改进建议
3.4.1被测软件设计和操作改进建议
1、进一步提高编码人员的工作质量。
本次二次开发活动中，编码人员中有较多新手和外包人员，他们对系统、写代码、编码规范等不够熟悉，导致产生较多缺陷；并且还有很多是脚本不规范，程序版本混乱的情况，耽误了开发和测试时间，也降低了质量可控性。
另外也有部分开发人员对测试人员还存在依赖心理，对测试发现的问题发现一个改一个，对于是否有可能还存在类似的问题或者是否会引起其他问题不去思考，导致后期缺陷修复成本增加。因此项目经理应该进一步向开发人员宣贯产品质量的重要性, 提高开发人员的质量意识。
2、加强程序代码检查力度。
在本次二次开发活动中，由于开发时间紧张，代码检查人员参与其他事情较多，后期很多开发任务没有经过代码检查或代码检查不充分。在本次参与编码人员整体水平不高的情况下，应该说代码检查环节还是非常必要的。如果这个环节不充分，那么到测试环节的压力就会比较大。项目经理应该认真分析缺陷分布情况, 加强重点模块和质量较差开发人员的代码走查力度,不能因为个人能力不足的问题导致产品质量整体下滑。
3.4.2 被测软件的测试改进建议
1、准确把握用户需求，提高测试针对性。
本次二次开发项目测试人员没有参与需求调研，参与需求分析和讨论的时间也比较少，对用户需求把握不准，导致一些任务测试不够深入。而我们的测试都应当是追溯到用户需求的。试想如果测试人员连用户想要什么都没搞清楚的话，可能得到什么样的测试结果。因此只有前期充分的参与需求分析，充分
的与规划人员进行沟通，才能得到比较好的测试效果。
4．测试工作总结
4.1人力资源消耗
4.2测试计划差异分析
与测试方案计划相比，在人员上辛丽和李芳彦主要参与前两轮单项测试；张雪、崔燕奇去XX现场参与第三、第四轮单项测试，张雪在实验室环境下进行
系统测试。人员变动比较频繁，对产品质量也可能造成风险。
附录：[HIOSE 1.3.0] 所有缺陷列表
O SECS.xl sx