XXX系统测试总结报告.docx

XXX系统测试总结报告.docx

《XXX系统测试总结报告.docx》由会员分享，可在线阅读，更多相关《XXX系统测试总结报告.docx（13页珍藏版）》请在冰点文库上搜索。

XXX系统测试总结报告

XX系统

（XXV1.0）

测试总结报告

文件编号

文件版本V1.0

编写单位

编写人

编写日期

审核人

审核日期

批准人

批准日期

文件修订记录

版

本

修订人

修订日

期

修订内容

1引言

1.1编写目的

XXX系统测试总结报告编写的目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合客户的需求。

预期参考人员包括用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层领导。

1.2系统简介

“XXX系统”旨在采用先进的软件技术、数据库技术。

。

。

。

。

系统功能包括。

。

。

。

。

。

本系统致力于通过计算机技术和XXX业务的结合，充分发挥信息化优势，提高业务人员的办公效率和业务质量，便于。

。

。

。

，以快速把握。

。

。

。

。

。

，提高对。

。

。

的科学管理水平和信息化水平。

1.2.1

系统架构

图1系统架构

1.2.2

技术架构

图2技术架构

1.2.3

功能列表

1.3术语和缩略词

术语、缩略语

解释

XXX

XXX系统（）

1.4参考资料

XXX系统软件需求规格说明书》

XXX系统软件高层设计说明书》

XXX系统测试用例说明书》

2测试概要

2.1测试用例设计

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

黑盒测试

白盒测试

其他技术

使用单元接口和功能描述，不需了解被测单元的内部结构

使用被测单元内部如

何工作的信息

白盒测试用例设计：

使用程序设计的控制结构导出测试用例。

采用白盒测试的目的主要是:

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

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

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

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

黑盒测试用例设计：

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

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

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

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

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

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

5.初始化盒终止错误。

2.2测试环境与配置

2.2.1服务器端

硬件

配置

硬件环境

CPU

Pentium3GHz

内存

4G

硬盘

40G

软件环境

简体中文Windows桌面操作系统

OracleDatabase10gDBRelease2或更高版本

2.2.2客户端

硬件

配置

硬件环境

CPU

Pentium2GHz

内存

1G

硬盘

20G

软件环境

简体中文Windows桌面操作系统

.NETFRAMEWORK3.或5更高版本

OracleDatabase10gClientRelease2或更高版本

XXX系统V1.0

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测试人员结构

测试人员的工作分配：

编号

测试内容

责任人

1

2

3

4

5

6

3.2覆盖分析

本次测试中为了使需求覆盖率达到100％，现在对以下功能点进行了测

试。

希望对需求规格说明书中的各个功能点尽量全部测试，最大限度的找出系统错误，为完善程序提供合理的建议。

功能编号

测试点描述

是否

测试

重要等级

[Y][P][N][N/A]

1

测试系统能否正常将规范格式文件中的数据导入到数据库。

是

重要

P

2

测试系统能否正常通过手动填写和选择各项目录入数据

是

重要

P

3

测试系统能否正常将所选文件夹的中的规范格式文件的数据批量导入数据库。

是

重要

P

4

是

重要

P

5

是

重要

Y

6

是

一般

Y

7

是

重要

P

备注：

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

3.2.1测试覆盖

功能

（或编号）

用例

个数

执行

总数

未执

行数

未/漏测分析和原因

1

5

5

0

2

5

5

0

3

5

5

0

4

5

5

0

5

3

3

0

6

1

1

0

7

10

10

0

8

5

5

0

9

5

5

0

10

8

8

0

11

3

3

0

12

11

11

0

13

7

7

0

14

7

7

0

15

8

8

0

16

14

14

0

17

2

2

0

18

10

10

0

19

5

5

0

20

1

1

0

21

7

7

0

22

13

13

0

23

11

11

0

24

3

3

0

25

10

10

0

26

3

3

0

27

1

1

0

28

3

3

0

29

4

4

0

30

10

10

0

31

7

7

0

32

7

7

0

33

6

6

0

34

9

9

0

合计

214

214

0

测试覆盖率=执行总数/用例总数*100%=100%

3.3缺陷统计与分析

3.3.1缺陷汇总

Bug等级定义如下表所述

等级

描述

说明

严重

发现可重复出现的致命问题

——导致系统崩溃；

——导致程序模块丢失；——主业务流程出现断点；——内存泄漏；

——导致死机

一般

发现可重复出现的严重问题

——被测功能不能正确实现；——软件错误导致数据丢失；——被测数据处理错误；——用户需求未实现。

微小

一般性的错误或功能实现有

不完美处

——操作界面错误；

——打印内容、格式错误；

——简单的输入限制未放在前台进行控制；

——删除操作未给出提示。

——界面不规范；

——辅助说明描述不清楚；

——输入输出不规范；

——长操作未给用户提示；

——提示窗口文字未采用行业术语。

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

Bug级别

严重

一般

微小

无效

Bug数目

3

6

27

12

各类Bug数目柱状图如下：

ug数

图4各类Bug数目

3.3.2缺陷引入原因分析

测试过程中发现的缺陷主要有以下几个方面：

1．需求理解不明确开发人员根据需求进行设计时，没有考虑相关功能的关联性，以及需求错误的地方，在测试过程中，需求相关的问题表现出来。

需求做改正，设计必须跟着做改动，浪费时间和影响开发人员的积极性，降低开发人员对需求的信任，可能会导致开发人员不按照需求进行设计而根据自己的经验来进行设计。

2．功能性错误

功能实现错误，实现了需求未定义的功能，执行需求定义的功能时系统出现错误。

主要是统计分析出图时数据因编码错误出现处理异常，导致显示错误统计数据。

3．界面设计和需求不一致界面设计没有根据需求进行，输入，输出字段文字错误，用户无法理解字段含义。

界面设计没有完成需求规定的输入限制验证，导致用户可以输入错误的或者无效的数据，这些数据有可能会引起功能性错误。

4．界面设计易用性缺陷

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

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

提示信息一致性，用户在不同界面执行相同的操作，提示信息不同。

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

4测试结论

测试类别

缺陷总数

遗留问题数目

用例总数

测试功能点数

结论

功能测试

48

0

214

34

通过

安装测试

0

0

8

/

通过

5综合评价

资源消耗：

测试时间

测试人力

6人×6天+1人×10天=46人天

硬件

服务端PC1台

客户端PC6台

测试质量：

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

用例质量

缺陷总数/测试用例总数=48/214=22.43％

缺陷密度

缺陷总数/功能点数=48/34=1.41

5.1软件能力

XXX系统完整实现了需求规格说明书中的需求，主要分为。

。

。

等功能模块

5.2缺陷和限制

XXX系统中的短信发送功能需要硬件支持，基本功能按照需求完成，但在公司本部没有相应硬件支持导致无法进行详细测试。

5.3建议

下面根据此次测试，提出下面几条建议：

1．开发人员要严格的按照需求规格说明书进行系统开发。

2．开发与测试同时进行，这样可以尽早发现项目的问题，提高整个系统的开发的效率。

3．开发人员要和测试人员分开，避免定向思维，更准确快速的找到系统缺陷