“应急能力指数系统(UGI) V1.0”

测试报告

重庆联美科技公司受重庆市电力公司电网检修分公司的委托，于20##年10月8日至20##年11月9日，根据GB/T 17544《信息技术软件包质量要求和测试》的国家标准，对重庆市电力公司电网检修分公司研发的“应急能力指数系统（UGI） V1.0”分别在安装与卸载、功能实现、数据计算准确性、用户界面、安全可靠性、兼容性、可扩充性、易用性、用户文档和病毒检查等十个方面进行了全面严格的测试。测试结果表明：“应急能力指数系统（UGI） V1.0”符合GB/T 17544《信息技术软件包质量要求和测试》的国家标准，并具有以下特点：

1、软件结构设计合理：软件采用客户端与服务器的B/S架构。客户端使用Windows操作系统，服务器采用Windows Server系统。

2、软件功能完整。

3、模块化设计，功能配置灵活。系统采用模块化设计，各模块功能相对独立，能够通过灵活的配置来设置系统的功能。

4、系统安全可靠性。该系统对不同用户有明确的权限限制，具有比较严格的用户密码管理，错误提示基本准确，具有数据录入的有效性检验。系统操作日志记录了用户主要操作的内容，实现了快捷安全的备份与恢复。

5、操作便捷，易于掌握。系统各功能界面简洁美观，风格一致，布局合理；系统工作界面、对话框等设置合理，方便用户使用。

6、系统用户文档。系统提供了各种技术文档及操作手册，提供文档有目录表，信息基本，用户文档易于浏览。

测试结果

测试环境

测试结论

通过项目组人员几个月的测试及系统的试运行,系统完全实现了设计要求,功能完善、运行高效、系统稳定、运算结果准确无误，维护及操作简单、界面美观大方，各项指标符合要求，达到预期目标，测试通过。

 

第二篇：测试报告范例

测试总结和报告

    测试人员的工作通常并不像开发人员那样能直接体现出来，让大家一目了然。开发人员做的是建设性的工作，如开发了哪些功能，写了几行代码，设计了几个类，都能直观地看到，而且，通过软件能很鲜活地演示开发人员的工作成果。
    但是测试人员的工作相对隐蔽一点，测试人员做的是破坏性的工作，并且没有很多可以直观体现测试人员贡献的东西。笔者曾经听到公司人事部的一位同事说：“你们做测试的真好，整天坐在那里”。当然，这是外行人看内行时说的话，但是给笔者的一个启示是：测试人员需要更多地表现自己，展现自己的工作成果。
    说明：由于缺陷列表太细、太大，测试用例过于专业，很多人对其不感兴趣，因此测试报告能很好地展示自己的工作状况，测试报告是提供给很多人看的一份文档。

    下面是一个项目的测试报告的纲要：
1 简介
1.1 编写目的
1.2 项目背景
1.3 术语和缩略词
1.4 参考资料
2 目标及范围
2.1 测试目的及标准
2.2 测试范围
3 测试过程
3.1 测试内容
3.2 测试时间
3.3 测试环境
3.4 测试方法及测试用例设计
4 测试情况分析
4.1 测试概要
4.2 测试用例执行情况
4.3 缺陷情况
4.4 测试覆盖率分析
4.5 产品质量情况分析
5 测试总结
5.1 测试资源消耗情况
5.2 测试经验总结
6 附件
附件1 测试用例清单
附件2 缺陷清单
一、缺陷分类报告
        缺陷分类报告是测试报告的重要组成部分，可以再细分为：缺陷类型分布报告、缺陷区域分布报告和缺陷状态分布报告等。
1．缺陷类型分布报告
        缺陷类型分布报告主要描述缺陷类型的分布情况，看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意，并分析缺陷为什么会集中在这种类型。例如，如果缺陷主要是界面类型的，如界面提示信息不规范、界面布局凌乱等问题，那么就要讨论是否需要制定相应的界面规范，让开发人员遵循，从而防止类似问题的出现。
缺陷类型分布报告一般用饼图或柱状图显示。如图7.29所示，用饼图表示了几种类型的缺陷各自所占的比例。

图  缺陷分布报告

2.缺陷区域分布报告
        缺陷区域分布报告主要描述缺陷在不同功能模块出现的情况，这些信息有助于开发人员分析为什么缺陷会集中出现在某个功能模块。例如，如果缺陷主要集中在单据的审批过程中，那么就要分析是否是审批流程调用的工作流接口设计不合理。
        缺陷区域分布报告一般使用饼图或柱状图表示。如图7.30所示，用柱状图表示缺陷分布在不同的功能模块的个数。

                                                         图  缺陷区域分布报告
3.缺陷状态分布报告
        缺陷状态分布报告主要描述缺陷各种状态的比例情况，例如Open、Fixed、Closed、Reopen、Rejected、Delay的Bug分别占了百分之多少。这些信息有助于评估测试和产品的现状：
        如果Open的Bug比例过高，则考虑让开发人员暂停开发新功能，先集中精力修改Bug；
        如果Fixed状态的Bug很多，则考虑让测试人员暂停测试新功能，先集中精力做一次回归测试，把修改的Bug验证完；
        如果Closed的Bug居多，则可能意味着功能模块趋于稳定；
        如果Reopen的Bug比较多，则需要分析开发人员的开发状态，是什么原因造成缺陷修改不彻底；
        如果Rejected的Bug比例过高，则要看开发人员与测试人员是否对需求存在理解上的分歧；
        如果Delay的Bug比例过高，则要考虑这个版本是否满足用户的要求，是否缺少了太多应该在这个版本出现的功能特性。
        缺陷状态分布报告一般使用饼图或柱状图表示。如图7.31所示，用饼图表示各种状态的缺陷个数以及所占的百分比。

图  缺陷状态分布报告

注意：其他的缺陷分类报告也可以写到测试报告中，例如，严重级别分类报告、优先级别分类报告、负责人分类报告、发现人分类报告、版本分类报告等。但是要注意，应该用这些分类报告来说明问题，而不要用来指责别人，例如使用负责人分类报告来嘲笑某个开发人员是“Bug大王”等。

二、缺陷趋势报告
        缺陷趋势报告主要描述一段时间内的缺陷情况。如果项目管理比较规范，缺陷管理和测试流程比较正常的话，缺陷趋势报告还可以用来估算软件可发布的日期。
例如，如图7.32所示的缺陷趋势图，表示在20##年9月3号至20##年9月24号之间的Bug状态变化。

                                                   图  缺陷趋势图
        从图7.32可以看出，Open状态的Bug在不断地增加，Fixed状态的Bug在20##年9月16号后开始骤然下降，这表示，这段时间开发人员有可能在开发几种新的功能，忽略了Bug的修改工作。
        发现并录入Bug，与修改并关闭Bug是一对互相对冲的两个变量，软件产品就是在这样此消彼涨的过程中不断完善和改进质量的。有经验的项目经理和测试人员会非常关注这样的发展曲线，从而判断项目产品的质量状态和发展趋势。笔者曾经在某个项目中与一位项目经理在项目的待发布阶段每天都在观察缺陷趋势图，这位项目经理甚至把它戏称为软件产品的“股市”技术图。
        但是确实能从这些图中看出一个产品的质量趋势，如果项目管理得比较规范的话，甚至可以从这些图的某些关键点推算出可发布版本的日期。在微软的项目管理中，把这种关键点称为零Bug反弹点。例如，图7.33中就有几个零Bug反弹点（用圆圈圈住的地方）。

图 零Bug反弹

        项目在第一次达到零缺陷，即所有Bug（或者大部分Bug）都基本处理掉了，没有发现新的Bug时，还不能马上发布版本，因为Bug会反弹。由于缺陷的“隐蔽特性”和“免疫特性”，第一个零缺陷点是一个质量安全的假像，测试人员很快就会在新版本中发现更多的Bug，有些项目甚至要到第三个或第四个零Bug点才能安全地发布，这取决于项目的实际控制方式。

已投稿到： 排行榜 圈子

阅读(2473)|评论(2)|收藏(0)|打印|举报

　　2测试概要

　　用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。

　　

　　3测试结果及发现

　　3.1测试1（标识符）

　　把本项测试中实际得到的动态输出（包括内部生成数据输出）结果同对于动态输出的要求进行比较，陈述其中的各项发现。

　　

　　3.2测试2（标识符）

　　用类似本报告3.1条的方式给出第 2项及其后各项测试内容的测试结果和发现。

　　

　　4对软件功能的结论

　　4.1功能1（标识符）

　　4.1.1能力

　　简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实的能力。

　　

　　4.1.2限制

　　说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。

　　

　　4.2功能2（标识符）

　　用类似本报告4.l的方式给出第2项及其后各项功能的测试结论。

　　

　　．．．．．．

　　

　　5分析摘要

　　5.1能力

　　陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异 对能力的测试所带来的影响。

　　

　　5.2缺陷和限制

　　陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软件性能的影响，并说明全部测得的性能缺陷的累积影响和总影响。

　　

　　5.3建议

　　对每项缺陷提出改进建议，如：

　　

　　a． 各项修改可采用的修改方法；

　　

　　b． 各项修改的紧迫程度；

　　

　　c． 各项修改预计的工作量；

　　

　　d． 各项修改的负责人。

　　

　　5.4评价

　　说明该项软件的开发是否已达到预定目标，能否交付使用。

　　

　　6测试资源消耗

　　总结测试工作的资源消耗数据，如工作人员的水平级别数量、机时消耗等。