XXXX系统测试报告.docx

XXXX系统测试报告.docx

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

XXXX系统测试报告

卷号

卷内编号

文档编号

密级

项目编号：

《XXX》

测试总结报告

Version:

1.0

项目承担部门：

撰写人（签名）：

完成日期：

本文档使用部门：

■主管领导■项目组

■客户（市场）□维护人员

■用户

评审负责人（签名）：

评审日期：

修订历史记录

日期

版本

说明

作者

2013-10-18

0.9

初稿

2013-10-21

1.0

修订

目录

1.简介4

1.1.编写目的4

1.2.项目背景4

1.3.系统简介4

1.4.术语和缩写5

1.5.参考资料5

2.测试概要5

2.1.测试用例设计5

2.2.测试环境与配置7

2.3.测试方法7

3.测试结果及缺陷分析11

3.1.测试执行情况与记录11

3.2.覆盖分析12

3.3.缺陷的统计与分析15

4.测试结论17

5.建议18

1.

简介

1.1.编写目的

本测试报告为《XXX》项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求。

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

1.2.项目背景

XXX是针对汽车美容店，为汽车美容行业前台提供客户服务、会员管理、业务管理、仓库管理、员工管理、系统管理等功能。

1.3.系统简介

XXX是根据汽车的要求而开发的汽车美容应用软件是目前XXX中比较有代表性的一套汽车美容系统。

主要有五大模块：

客户服务、会员管理、仓库管理、员工管理、系统管理。

1.4.术语和缩写

术语/缩写

解释

需求覆盖率

经过测试的需求/功能和需求规格说明书中所有需求/功能的比值

测试覆盖率

最终执行的测试用例数量和测试用例总数的比值

功能测试

功能测试：

本部分的测试主要根据需求要求，检查是否开发的功能满足了需求中的要求。

同时，检查在满足功能的同时，是否在使用非正规的操作是系统给予了正确的约束等。

性能测试

性能测试：

检查系统性能测试是否达到相应指标

1.5.参考资料

《XXX项目软件需求规格说明书.txt》

《XXX项目测试大纲.xls》

《XXX项目测试用例.xls》

《XXX项目测试计划.doc》

2.测试概要

2.1.测试用例设计

本系统测试工作以功能测试、性能测试为主，评估系统是否达到预定的质量目标。

根据XXX的特点，其测试策略考虑重点在登陆功能、会员管理。

根据项目的特点和日程，拟不特地安排进行功能测试、性能测试（根据测试状况，在有需要的情况下，针对特定测试对象可考虑单独进行）。

在系统测试的规划中，根据项目特点，以系统登陆功能为优先关注内容，整理系统各模块（客户服务、会员管理、仓库管理、员工管理、系统管理），保证对基本业务功能的覆盖，保证对用户常见业务操作的覆盖；同时关注用户界面的完成，所以也要考虑对页面本身的测试。

2.2.测试环境与配置

软件环境

操作系统

Win7Sp1

数据库

Sql

硬件环境

CPU

Inter（R）Celeron（TM）i3-2330CPU@2.26GHz2.26GHz

内存

2GHz

硬盘

300GB

网络

局域网100Mbps

2.3.测试方法

对于主要的功能测试,依据项目需求规格说明书，需要验证前条所列的功能项目，由于项目特点中流程性要求和限制较为突出，所以在测试内容的安排上，可以根据场景法分析基本流程和分支流程。

对于功能的每个正常执行步骤和可能性出现的每种例外情况.在这里可以使用采用测试方法为黑盒测试方法，采用黑盒测试技术来编写测试用例，包括等价类划分法，边界值分析法，因果图分析方法，错误推测方法等测试技术，进行分析。

对于模块、数据相互联系比较紧密的，可以使用特性交互或关联图的方法,测试各种功能交互情况。

对于纳入本轮测试的其他测试项目内容，根据上述条目括号中考虑内容加入到测试项目和用例中，同时其中某些需求的覆盖可以使用某些用例来重复关联，测试设计的时候应该予以考虑。

性能测试：

工具测试以LoadRunner为主的登陆功能的性能。

在测试用例的测试数据准备（由测试员模拟用户提供）。

功能测试

任务

负责人

日期

测试目标

确保测试的功能正常，其中包括菜单导航，数据输入处理等功能。

张航

杨潺潺

张宇

喻永强

李超

2013-09-27—2013-10-15

测试范围：

系统各大功能点

技术：

利用有效的和无效的数据来执行各测试用例检查以下内容：

在使用有效数据时得到预期的结果；

在使用无效数据时显示相应的错误消息或警告消息；

各业务规则都得到了正确的应用；

开始标准：

系统测试通过，并无明显缺陷

完成标准：

所有测试用例执行完成并通过，完全满足需求要求；

功能测试覆盖模块

编号

模块

功能

备注

1

客户服务

会员卡绑定服务

会员卡打折服务

无卡普通服务

查看服务记录

2

会员管理

会员信息管理

卡号数据刷新

新增会员（开卡）

查询卡号信息

会员续卡

开续卡记录

积分兑换礼品

3

业务管理

添加服务

服务管理

添加套餐

套餐管理

4

仓库管理

库存信息管理

5

员工管理

员工管理

职位管理

修改个人密码

6

系统管理

备份数据库

恢复数据库

退出程序

性能测试

任务

负责人

日期

测试目标

确保系统登陆功能达到相应性能指标

张航

杨潺潺

张宇

喻永强

李超

2013-09-27—2013-10-15

测试范围：

系统登陆功能

技术：

采用LR自动测试工具

对XXX登陆功能

进行登陆压力测试

开始标准：

功能测试通过

完成标准：

达到相应性能指标

在具体的测试设计过程中，建议首先整理测试项目，细化到用例组级别，再根据这个结果来设计用例，同时应当给出用例覆盖说明。

根据项目规模和日程，建议测试文档及记录采用一般文档和表格即可，以方便成员浏览和处理。

另外在测试设计完成后，测试人员需要选择测试对象的基本测试用例，用例数不用太多，但应包括测试对象的核心流程和基本功能，以用于开发人员在提交版本前做自我检查，应该在自我检查通过后，方能进入测试组测试。

测试评价上应参考相关的质量目标加以评价，可能会涉及对测试设计的复查。

性能测试：

工具测试以LoadRunner为主的登陆功能的性能。

3.测试结果及缺陷分析

3.1.测试执行情况与记录

3.1.1.测试组织

角色

人员

职责

测试组长

张航

监管项目的测试进度、测试过程规范

测试负责人

张航

编写测试计划、测试报告，搭建测试环境

测试设计人员

张航，杨潺潺，张宇，喻永强，李超

编写测试用例

测试执行人员

张航，杨潺潺，张宇，喻永强，李超

执行测试用例，记录并跟踪缺陷

3.1.2.测试时间

测试任务

开始时间

结束时间

总计

Version:

2013-10-16

2013-10-18

120工时/15工作日

合计：

120工时/15工作日

3.1.3.测试版本

Version：

1.0

3.2.覆盖分析

3.2.1.需求覆盖

编号

模块

功能

是否通过

备注

1

客户服务

会员卡绑定服务

PASS

会员卡打折服务

PASS

无卡普通服务

PASS

查看服务记录

PASS

2

会员管理

会员信息管理

PASS

卡号数据刷新

PASS

新增会员（开卡）

PASS

查询卡号信息

PASS

会员续卡

PASS

开续卡记录

PASS

积分兑换礼品

PASS

3

业务管理

添加服务

PASS

服务管理

PASS

添加套餐

PASS

套餐管理

PASS

4

仓库管理

库存信息管理

PASS

5

员工管理

员工管理

PASS

职位管理

PASS

修改个人密码

PASS

6

系统管理

备份数据库

PASS

恢复数据库

PASS

退出程序

PASS

XXX6大模块需求覆盖率=100.00%

性能测试场景

测试类型

系统功能

用户登陆系统

性能测试指标：

响应时间<3s

CUP<75%

内存率<75%

性能测试达到相应指标：

序号

功能名称

场景子序号

并发人数

循环时间

1

用户登陆

1

20

40

60

80

100

20分钟

实际结果

测试项

响应时间

业务成功率

并发数

CPU使用率

内存使用率

用户登陆

2.54

100%

100

70%

73%

采用每秒钟增加3个用户，场景结束时每秒钟退出3个用户。

每次间隔时间5秒，即设置thinktime时间；

3.2.2.测试覆盖

对需求的各模块的功能测试点，执行测试用例达到100%。

测试覆盖统计表

模块

已设计测试用例的需求数（个）

需求总数（个）

测试覆盖率

客户服务

62

62

100.00%

会员管理

102

102

100.00%

业务管理

100

100

100.00%

仓库管理

28

28

100.00%

员工管理

90

90

100.00%

系统管理

10

10

100.00%

3.3.缺陷的统计与分析

3.3.1.缺陷汇总

根据本项目特点：

项目组人数较少，交流状况简单，采用飞秋局域网在线交流；

项目纳入组织现有缺陷管理系统中（bugfree缺陷管理平台），以进行良好的历史保存和积累。

缺陷汇总见《XXX缺陷汇总.xml》

3.3.2.

缺陷分析

BUG模块分布统计

一、测试执行通过

测试执行统计表

模块

执行结果为“通过”的测试用例数（个）

实际执行的测试用例总数（个）

测试执行通过率

客户服务

40

53

75.47%

会员管理

87

100

87.00%

业务管理

76

97

78.35%

仓库管理

23

25

92.00%

员工管理

78

85

91.76%

系统管理

7

8

87.50%

以上为测试执行通过相关数据，经过分析测试用例设计基本通过。

二、缺陷探测

缺陷解决统计表

模块

测试员发现的缺陷（个）

总缺陷（个）

缺陷探测率

客户服务

40

42

95.24%

会员管理

35

43

81.40%

业务管理

24

30

80.00%

仓库管理

3

5

60.00%

员工管理

12

14

85.71%

系统管理

2

2

100.00%

以上为缺陷探测率，测试人员在测试中发现的缺陷比例。

三、缺陷解决

缺陷解决统计表

模块

已关闭的缺陷（个）

缺陷总数（个）

缺陷解决率

客户服务

40

42

95.24%

会员管理

42

43

97.67%

业务管理

27

30

90.00%

仓库管理

3

5

60.00%

员工管理

13

14

92.86%

系统管理

1

2

50.00%

以上为缺陷解决相关数据，开发员解决后，由测试员再次校验，最后关闭。

3.3.3.遗留缺陷与未解决问题

无

4.测试结论

经过模拟仿真测试，对XXX功能测试、性能测试都测试比较充分。

需求覆盖率100%，测试执行覆盖率100%，功能测试通过；性能测试达到相应指标，测试通过。

5.

5.建议

⏹配置安装环境的变更

措施：

保存旧的数据尽快适应新的配置环境

⏹人员不能及时到位

措施：

1、提前报告人员需求，2、细分工作

⏹人员技能不足，需要加强

措施：

1、加强培训和练习；2、适当修改计划，减少任务强度

⏹人员变动引起的项目不稳定

措施：

提前安排候补人员

⏹用户需求变更

措施：

1、细化前期需求调研，对需求变更加以控制；2、制定变更周期约定尽快调整变更测试经理应在变更矩阵上做记录。