XXX系统测试总结报告

XX系统(XX V1.0)

测试总结报告

文件修订记录

1引言

1.1编写目的

XXX系统测试总结报告编写的目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合客户的需求。预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层领导。

1.2系统简介

“XXX系统”旨在采用先进的软件技术、数据库技术。。。。。系统功能包括。。。。。。本系统致力于通过计算机技术和XXX业务的结合，充分发挥信息化优势，提高业务人员的办公效率和业务质量，便于。。。。，以快速把握。。。。。。，提高对。。。的科学管理水平和信息化水平。

1.2.1系统架构

图1系统架构

1.2.2技术架构

图2技术架构

1.2.3功能列表

1.3 术语和缩略词

1.4 参考资料

《XXX 系统软件需求规格说明书》 《XXX 系统软件高层设计说明书》 《XXX 系统测试用例说明书》

2 测试概要

2.1

测试用例设计

测试用例广义地可以分为两类：

白盒测试用例设计：使用程序设计的控制结构导出测试用例。 采用白盒测试的目的主要是:

1.保证一个模块中的所有独立路径至少被执行一次；

2.对所有的逻辑值均需要测试真、假两个分支；

3.在上下边界及可操作范围内运行所有循环；

4.检查内部数据结构以确保其有效性。

黑盒测试用例设计：使用详细设计导出测试用例。

采用黑盒测试的目的主要是：

1.检查功能是否实现或遗漏；

2.检查人机交互是否错误；

3.数据结构或外部数据库访问错误；

4.性能等其它特性要求是否满足；

5.初始化盒终止错误。

2.2测试环境与配置

2.2.1服务器端

2.2.2客户端

2.3测试方法和工具

XXX系统测试主要用到了以下几种测试方法：等价类、边界值、因果图、错误猜测等，用到最多的是等价类和边界值，错误猜测的方法。

所谓等价类划分法是一种典型的、重要的黑盒测试方法，它将程序所有可能的输入数据（有效的和无效的）划分成若干个等价类。然后从每个部分中选取具有代表性的数据当做测试用例进行合理的分类，测试用例由有效等价类和无效等价类的代表组成，从而保证测试用例具有完整性和代表性。

例如：本系统中测试用户名不存在，系统应该给出什么样的提示时，就可以将所有用户名分为两类，一类是已经注册的用户，另一类是没有注册的用户，前者为有效等价类，后者为无效的等价类。

所谓边界值法是指相当于输入等价类和输出等价类而言，稍高于其边界值及稍低于其边界值的一些特定情况。基于边界的方法是根据定义域来实现的，最终演变成边界值分析、健壮性测试、最坏情况测试和健壮最坏情况测试四种技术。

例如：本系统中，对经纬度输入范围进行测试，由于经度的范围是（-180，+180），所以在选择测试数据时，我们选择（-180.000001，-180.000000，

-179.999999,-90，0,90,179.999999,180.000000,180.00001），这样就能测试出系统对经纬度的约束是否准确。

因果图法是一种适合于描述对于多种输入条件组合的测试方法，根据输入条件的组合、约束关系和输出条件的因果关系，分析输入条件的各种组合情况，从而设计测试用例的方法，它适合于检查程序输入条件涉及的各种组合情况。因果图法一般和判定表结合使用，通过映射同时发生相互影响的多个输入来确定判定条件。因果图法最终生成的就是判定表，它适合于检查程序输入条件的各种组合情况。

3测试结果及缺陷分析

3.1测试执行情况与记录

3.1.1测试组织

测试组成：

图3测试人员结构

测试人员的工作分配：

3.2覆盖分析

本次测试中为了使需求覆盖率达到100％，现在对以下功能点进行了测试。希望对需求规格说明书中的各个功能点尽量全部测试，最大限度的找出系统错误，为完善程序提供合理的建议。

备注：Y表示测试用例全部通过；P表示大部分部分测试用例通过，根据测试出现的BUG或者测试人员建议进行修正；N表示测试用例不通过，程序出现严重BUG；N/A表示不可测试或者用例不适用。

3.2.1测试覆盖

测试覆盖率=执行总数/用例总数 * 100% = 100% 3.3缺陷统计与分析

3.3.1缺陷汇总

Bug等级定义如下表所述

增量确认测试阶段Bug列表：

各类Bug数目柱状图如下：

图 4各类Bug 数目

各类bug 所占比例如下饼状图所示

图 5各类Bug 比例

3.3.2 缺陷引入原因分析

测试过程中发现的缺陷主要有以下几个方面： 1． 需求理解不明确

开发人员根据需求进行设计时，没有考虑相关功能的关联性， 以及需求错误的地方，在测试过程中，需求相关的问题表现出来。需求做改正，设计必须跟着做改动，浪费时间和影响开发人员的积极性，降低开发人员对需求的信任，可能会导致开发人员不按照需求进行设计而根据自己的经验来进行设计。 2． 功能性错误

5 10 15 20 25 30 严重

一般

微小

无效

3

6

27

12

Bug 数目

Bug 数目

6.3%

12.5%

56.3%

25.0%

Bug 类型比例

严重 一般 微小

无效

功能实现错误，实现了需求未定义的功能，执行需求定义的功能时系统出现错误。主要是统计分析出图时数据因编码错误出现处理异常，导致显示错误统计数据。

3．界面设计和需求不一致

界面设计没有根据需求进行，输入，输出字段文字错误，用户无法理解字段含义。界面设计没有完成需求规定的输入限制验证，导致用户可以输入错误的或者无效的数据，这些数据有可能会引起功能性错误。

4．界面设计易用性缺陷

界面设计不够友好，系统中很多界面的输入字段无明确的输入提示，用户无法快速理解何种输入是正确的，但是用户输入错误后，系统提示出错，增加用户负担。

提示信息错误，不同模块相同结果的提示信息不一致，用户操作后，相应的提示信息不明确，引起用户误解。

提示信息一致性，用户在不同界面执行相同的操作，提示信息不同。5．开发人员疏忽引起的缺陷

因为开发人员的疏忽，导致系统需要验证的地方，调用了错误的验证，系统需要进行输入控制的地方没有进行相应的控制。

4测试结论

5综合评价

资源消耗：

测试质量：下面给出用例质量和缺陷密度两个指标来衡量功能测试的质量