目录

1.              引言... 1

1.1.         编写目的、内容、读者... 1

1.2.         项目背景... 1

1.3.         用户群... 1

1.4.         基本定义... 1

1.5.         测试对象... 1

1.6.         测试阶段... 1

1.7.         术语和缩写词... 1

1.8.         测试工具... 1

1.9.         参考资料... 1

2.              测试概要... 1

2.1.         测试环境... 1

2.1.1.        软硬件配置... 1

2.1.2.        网络拓扑图... 1

2.2.         测试计划... 1

2.3.         测试执行... 1

2.4.         测试用例... 1

2.4.1.        功能性... 1

2.4.2.        易用性... 1

2.5.         版本定义... 1

2.6.         覆盖分析... 1

2.6.1.        需求覆盖... 1

2.6.2.        测试覆盖... 1

3.              测试用例... 1

3.1.         功能测试... 1

3.1.1.        审批业务管理... 1

3.2.         性能测试... 1

3.3.         压力测试... 1

4.              测试结果... 1

4.1.         Bug趋势图... 1

4.2.         Bug严重程度... 1

4.3.         Bug状态分布... 1

5.              测试结论... 1

5.1.         功能性... 1

5.2.         易用性... 1

5.3.         可靠性... 1

5.4.         兼容性... 1

5.5.         安全性... 1

6.              分析摘要... 1

6.1.         覆盖率... 1

遗留缺陷的影响... 1

6.2.         建议... 1

7.              度量... 1

7.1.         资源消耗... 1

7.2.         缺陷密度... 1

8.              典型缺陷引入原因分析... 1

8.1.         需求定义不明确... 1

8.2.         功能性错误... 1

8.3.         界面设计易用性缺陷... 1

8.4.         开发人员疏忽引起的缺陷... 1

1.    引言

1.1.  编写目的、内容、读者

编写本测试报告主要有以下几个目的：

1.        通过对测试结果的分析，得到对软件质量的评价；

2.        分析测试的过程，产品，资源，信息，为以后制定测试计划提供参考；

3.        评估测试测试执行和测试计划是否符合；

4.        分析系统存在的缺陷，为修复和预防bug提供建议

测试包括以下具体内容：

1.                                          用户测试：主要测试系统的功能，操作性，性能，人机对话，系统界面，安全性等，主要参考对象为业主用户。需要了解此部分情况请参祥《测试结论》；

2.                                          功能测试：主要测试系统是否实现预计结果，此测试为软件的基本测试，主要参考对象为业主用户，开发人员，测试人员等。需要了解此部分情况请参祥《测试用例》。

3.                                          压力测试：压力测试用来评估在超越最大负载的情况下系统将如何运行。主要参考对象为项目经理，开发经理，测试人员。需要了解此部分情况请参祥《压力测试》。

4.                                          性能测试：性能测试主反应系统反应时间，CPU使用率，占用内存大小，系统反应速度等硬性指标。主要参考对象为业主用户，开发经理，开发人员，测试人员等。需要了解此部分情况请参祥《性能测试》。

5.                                          连接数测试：连接数测试主要测试系统服务器同时可以支持多少个用户使用，最大并发连接数是多少。主要参生对象为开发经理，开发人员，测试人员等。需要了解此部分情况请参祥《压力测试》。

实例：本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。预期参考人员包括用户、测试人员、、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理。

1.2.  项目背景

对项目目标和目的进行简要说明。必要时包括简史，这部分不需要脑力劳动，直接从需求或者招标文件中拷贝即可。

1.3.  用户群

1.        主要读者：项目管理人员，项目测试经理，业主相关人员；

2.        其他读者：项目其他相关人员。

2.

1.4.  基本定义

严重bug：出现以下缺陷，测试定义为严重bug：

3.        系统无响应，处于死机状态，需要其他人工修复系统才可复原。

4.        点击某个菜单后返回异常错误。

5.        进行某个操作（增加、修改、删除等）后，返回异常错误。

6.        当对必填字段进行校验时，未输入必输字段，返回异常错误。

7.        系统定义不能重复的字段输入重复数据后，返回异常错误。

1.5.  测试对象

根据软件定义，软件包括程序、数据和文档，所以软件测试并不仅仅是程序测试。软件测试应贯穿于整个软件生命周期中。在整个软件生命周期中，各阶段有不同的测试对象，形成了不同开发阶段的不同类型的测试。需求分析、概要设计、详细设计以及程序编码等各阶段所得到的文档，包括需求规格说明、概要设计规格说明、详细设计规格说明以及源程序，都应成为“软件测试”的对象。

在软件编码结束后，对编写的每一个程序模块进行测试，称为“模块测试”或“单元测试”；在模块集成后，对集成在一起的模块组件，有时也可称为“部 件”，进行测试，称为“集成测试”；在集成测试后，需要检测与证实软件是否满足软件需求说明书中规定的要求，这就称为“确认测试”。将整个程序模块集成为 软件系统，安装在运行环境下，对硬件、网络、操作系统及支撑平台构成的整体系统进行测试，称为“系统测试”。

为了把握各个环节的正确性，需要进行各种验证和确认工作。

验证是保证软件正确实现特定功能的一系列活动和过程，目的是保证软件生命周期中的每一个阶段的成果满足上一个阶段所设定的目标。

确认是保证软件满足用户需求的一系列的活动和过程，目的是在软件开发完成后保证软件与用户需求相符合。

验证与确认都属于软件测试，它包括对软件分析、设计以及程序的验证和确认。

在测试过程中，我们将充分考虑以上表述的相关对象，有针对性的加强一些内容的参考，保证做到一个全面、完整的测试。

1.6.  测试阶段

1.7.  术语和缩写词

l  在本文件中出现的“系统”一词，除非特别说明，均指“XXXXX系统”。

l  MTBF：平均无故障时间。

l  MTTR：平均维修时间。

l  SMS（Short Message Service）：短消息业务。

l  结构化查询语言：是关系数据库中使用的标准数据查询语言。

l  系    统：子系统的集合。

l  子 系 统： 模块的集合。

l  模    块：功能的集合。

l  功    能：处理任务的最小单元。

l  系统参数：控制系统的行为及流程的参数，内容存贮在系统数据库中，一般只由系统管理员维护。

l  用户参数：控制各工作站的界面、输入法等参数，内容存贮在各工作站软件安装目录下，用户可以修改。

l  运行参数：控制程序的启动以及与数据库的连接等，内容存贮在Windows系统的注册表中，第一次使用程序时系统会自动提示输入各种参数。

l  角   色：一组具有相同权限的用户集合。

l  权   限：执行某个功能，或操作某个模块、某个子系统的钥匙。

l  用   户：操作系统的人。

1.8.  测试工具

测试管理工具：Bugfree

性能自动化测试工具：Jmeter；

功能自动化测试工具：Watir

1.9.  参考资料

1.        《中华人民共和国标准化法》

2.        《信息技术 软件包 质量要求和测试》（GB/T17544-1998）

3.        《信息技术 软件产品评价 质量特性及其使用指南》（GB/T16260-1996）

4.        《软件工程 产品评价》（GB/T18905-2002）

5.        《软件产品管理办法》

6.        《XX需求和设计说明书》

7.        《XX数据字典》

8.        《XX后台管理系统测试计划》

9.        《XX后台管理系统测试用例》

10.    《XX项目计划》

11.    《XX祥细设计》

12.    《XX数据库设计》

2.    测试概要

（用例）

XX管理系统测试从xxxx年xx月xx日开始到xxxx年xx月xx日结束，共持续xx天，测试功能点xxx个，执行xxx个测试用例，平均每个功能点执行测试用例xx个，测试共发现xxx个bug，其中严重级别的bug xx个，无效bug  xx个，平均每个测试功能点xx个bug。

本次测试总共发布11个测试版本，其中xxxx为计划内迭代开发版本（针对项目计划的基线标识），xxxxx为回归测试版本。计划内测试版本，xxx测试进度依项目计划时间准时完成测试并提交报告，其中B4版本推迟一天发布版本，测试通过增加一个人日，准时完成测试。B5版本推迟发布2天，测试增加2个人日，准时完成测试。

B6－B11为计划外回归测试版本，测试增加5个工作人日的资源，准时完成测试。

XX测试通过Bugzilla缺陷管理工具进行缺陷跟踪管理，B1-B4测试阶段都有详细的bug分析表和阶段测试报告。

2.1.  测试环境

2.1.1.   软硬件配置

硬件环境应用服务器数据库服务器客户端

2.1.2. 网络拓扑图

（提供相关网络拓扑图，下面是示例图）

2.2.  测试计划

版本/时间计划开始实际开始计划完成实际完成加班增加资源：

计划任务祥细分解情况表：

2.3.  测试执行

此次测试严格按项目计划和测试计划执行，按时完成了测试计划规定的测试对象的测试。针对测试计划规定的测试策略，在测试执行中都有体现，在测试执行过程中，依据测试计划和测试用例，对系统进行了完整的测试。

2.4. 测试用例

2.4.1. 功能性

u 系统实现的主要功能，包括查询，添加，修改，删除。

u 系统实现的次要功能，包括为用户分配，为用户分配权限，渠道绑定，渠道RATE绑定，权限控制菜单按钮。

u 需求规定的输入输出字段，以及需求规定的输入限制

u

2.4.2. 易用性

u 操作按钮提示信息正确性，一致性，可理解性。

u 限制条件提示信息正确性，一致性，可理解性。

u 必填项标识。

u 输入方式可理解性。

2.5. 版本定义

给出测试版本，分为三个主要版本：

0字头为初稿，定好文档格式和测试方向和测试组织机构人员。

1.0版本完成全部功能测试，未经正式发布，未经审核；

2.0版整合所有测试人员的测试文档，完成所有测试，几经修改，经过测试经理，项目经理审核，达到正式发布的要求。

其中小数点后面的数字为修正了其中内容达到3个模块以上时相应增加0.1。

2.6. 覆盖分析

2.6.1. 需求覆盖

需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。

表格中“是否通过”的四种状态：

[Y]：全部通过

[P]：部分通过

[N]：不通过

[N/A] ：不可测试或者用例不适用

2.6.2. 测试覆盖

3.    测试用例

3.1.  功能测试

3.1.1. 审批业务管理

3.2.  性能测试

3.3.  压力测试

4.    测试结果

4.1.  Bug趋势图

（提供分析图）

此次黑盒测试总共发布11个版本，B1-B5为计划内迭代开发版本（针对项目计划的基线标识），B6-B11为进行的回归测试版本，bug版本趋势图如下图所示：

第一阶段，增量确认测试。

时间从20##年7月2日到20##年8月3日。从Bug趋势图中可以看出，每个版本的bug数基本维持在60个左右。

B1：从图中看到B1共有33个BUG，因为B1版本有一个功能模块在B2版本才开始测试，B1测试模块相对较少，所以B1版本bug相对较少。

B2：由于B1中的一个功能模块增加到Build2中进行测试，这一版本除了对B1中的BUG进行验证时对B1进行了回归测试，所以B2中的bug数相对B1出现了明显的增长趋势，

B3：B3版本因为有B2版本的bug验收测试，以及B1,B2的回归测试，共发现67个bug，和B2基本保持一致。

B4：B4版本bug数有一个下降的趋势，是因为B4版本推迟发布，新增加了测试人员参与测试，对系统不够熟悉，以及测试时间紧张，部分测试用例没有执行，测试覆盖度不够，所以发现bug数呈下降趋势。

B5：B5版本bug数又有一个增加的趋势，主要是由于开发功能模块多，该版本需求定义不明确。

第二阶段，BUG验证和功能回归确认测试。

时间从20##年8月4日到20##年8月14日。B6和B7进行了回归测试，B8没有进行回归测试，只验证了B1－B7的bug。

B6：进行第一轮回归测试，发现的bug数为33个，遗留一个问题，为数据字典种类默认值问题

B7：进行第二轮回归测试，第一次回归测试没有涉及到权限控制菜单按钮的测试，在本次回归测试的时候，重点进行了这个方面的测试，又发现了大量的权限相关的bug。

B8：B8没有进行全面的回归测试，只验证了B1－B7未通过验证的bug，所以该版本的bug数明显比较少。

B9：B9版本进行了全面的回归测试，时重点测试了权限控制，所以发先的bug数又呈现上升的趋势。测试发现44个bug，严重级别的bug为14个，严重级别的bug集中在权限控制上，功能性严重bug没有发现，说明权限控制依旧不稳定，但是系统功能已经稳定。

B10：B10版本验证了B9版本发现得bug，没有进行全面的回归测试。B10版本在验证bug的时候，重现打开Bug6个，新增bug2个，重新打开bug有5个为严重级别bug，是关于权限控制的bug，而新发现的bug，1个为严重级别的bug，也是属于权限控制的。说明，权限控制还存在着问题，需要修改权限管理bug，重新发布版本后进行全面的回归测试。B10版本新发现的bug详细分析见遗留bug分析。

B11：B11中验证了B1—B10未验证的bug，重点测试了权限控制，时进行了查询，添加，删除，修改的功能测试，测试过程中未发现bug。

4.2.  Bug严重程度

（提供几个分析图）

测试发现的bug主要集中在normal和minor阶段，属于一般性的缺陷，但是测试的时候，出现了68个严重级别的bug，出现严重级别的bug主要表现在以下几个方面

1.   系统主要功能没有实现

2.   添加数据代码重复后，出现的找不到页面的错误

3.   多语言处理，未考虑非语种代码的情况

4.   数据库设计未考虑系统管理员角色，导致用系统管理员进行操作的时候出现找不到页面错误

5.   权限控制异常

5.

严重级别bug按版本分布如下：

由严重bug版本分布图可以看出，严重级别的bug版本趋势和bug版本趋势基本是一致的，但是，在B7和B9版本中年，严重级别的bug明显增多，主要原因是B7和B9版本测试了权限控制按钮功能，权限问题出现的严重级别的bug比较多。

权限bug主要表现：

1.   具有相应按钮操作的权限，页面无相应按钮，无法执行该功能

2.   无相应按钮操作权限，页面有相应按钮，点击按钮能出现权限异常错误

Bug引入阶段

有相应按钮操作权限，有相应按钮，执行该功能出现权限异常错误

Bug引入原因

4.3.  Bug状态分布

（提供分析图）

由bug状态图可以看出，未解决的bug有4个，主要是B8中新提交的bug，是关于用户管理的bug，因为用户权限管理需要重新设计所以，该部分的bug暂时没有解决。

5.    测试结论

5.1.  功能性

系统正确实现了通过数据字典管理基础数据的功能，实现了数据内容的多语言功能，实现了中英文界面。实现了基础数据管理，集团管理，基础信息管理，渠道管理，代理管理，用户管理的查询，添加，修改，删除的功能，系统还实现了将权限控制细化到菜单按钮的功能。

系统在实现用户管理下的权限管理功能时，存在重大的缺陷，权限控制不严密，权限设计有遗漏。

5.2.  易用性

现有系统实现了如下易用性：

1.        查询，添加，删除，修改操作相关提示信息的一致性，可理解性

2.        输入限制的正确性

3.        输入限制提示信息的正确性，可理解性，一致性

3.

现有系统存在如下易用性缺陷：

1.        界面排版不美观

2.        输入，输出字段的可理解性差

3.        输入缺少解释性说明

4.        中英文对应的正确性

5.        中英文混排

5.

5.3.  可靠性

现有系统的可靠性控制不够严密，很多控制是通过页面控制实现的，如果页面控制失效，可以向数据库插入数据，引发错误。

现有系统的容错性不高，如果系统出现错误，返回错误类型为找不到页面错误，无法回复到出错前的状态。

5.4.  兼容性

现有系统未进行其他兼容性测试

5.5.  安全性

现有系统控制了以下安全性问题：

1.   把某一个登录后的页面保存下来，不能单独对其进行操作不进行登录

2.   直接输入某一页面的Url能否打开页面并进行操作不应该允许。

2.

现有系统未控制以下安全性问题：

1.   用户名和密码应对大小写敏感

2.   登陆错误次数限制

2.

6.    分析摘要

6.1.  覆盖率

测试用例覆盖率分析图：

此次测试，所有测试用例都是在中文界面下执行，测试不包括英文界面下的测试，也不包括正对英文翻译的测试。

此次测试，部分页面需求描述无明确的定义，对输入限制无详细定义，无明确的测试依据，在测试过程中，测试是根据输入字段含义，测试人员理解，以及和项目经理，开发人员沟通获得测试依据，无法保证测试依据的正确性和完整性，因此，没有进行完整的，正确的无效数据的测试，测试覆盖率不够，无法保证测试的有效性和正确性。

遗留缺陷的影响

1． 缺陷描述：xx项添加页面，“距离”字段无单位，建议增加单位。

缺陷影响：距离字段无单位说明，无衡量标准，用户易用性不好。

推迟原因：需求定义无单位定义，统一在升级版本中解决

2． 缺陷描述：基础信息管理模块，默认语言设置不一致。

缺陷影响：相功能模块默认语言设置不一致，一致性不好。

推迟原因：默认语言设置，目前无统一标准，升级版本中统一

3． 缺陷描述：tomcat日志有乱码，日志无项目名称，查看不方便。

缺陷影响：其他项目日志都有项目名称，日志无项目名称，查看不方便。

推迟原因：目前的日志为了调试方便，显示了很多其它信息，在项目正式发布时会统一处理的。

。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。。

6.2.  建议

在项目开始的时候应该制定码标准，数据库标准，需求变更标准，开发和测试人员都严格按标准进行，可以在后期减少因为开发，测试不一致而导致的问题，有时也可以降低沟通成本。

发布版本的时候，正确布置测试环境，减少因为测试环境，测试数据库数据的问题而出现的无效bug。

开发人员解决bug的时候，填写bug原因以及解决方式，方便bug的跟踪。

开发人员在开发版本上发现bug，可以通知测试人员，因为开发人员发现的bug很有可能在测试版本上出现，而测试人员和开发人员的思路不，有可能测试人员没有发现该bug，而且，这样可以保证发现的bug都能够被跟踪。

7.    度量

7.1.  资源消耗

测试时间：xxxx年xx月xx日至xxxx年xx月xx日共xx天

测试人力：2人×7天＋1人×35天＝49人天

服务器：2台

硬件资源

客户端：PC 4台

7.2.  缺陷密度

（提供分析图）

8.    典型缺陷引入原因分析

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

8.1.  需求定义不明确

需求文档中，存在功能定义错误，输入输出字段描述错误，输入输出字段限制定义错误，输入输出限制定义缺失这几种类型的缺陷。使得开发人员根据需求进行设计时，没有考虑相关功能的关联性，以及需求错误的地方，在测试过程中，需求相关的问题表现出来。需求做改正，设计必须跟着做改动，浪费时间和影响开发人员的积性，降低开发人员对需求的信任，可能会导致开发人员不按需求进行设计而根据自己的经验来进行设计。

8.2.  功能性错误

1、  功能没有实现，导致无法进行需求规定的功能的测试。

主要是无法进入设施管理，会议室管理页面，安全项管理无法保存信息，地区，房型删除功能缺失。

2、    功能实现错误，实现了需求未定义的功能，执行需求定义的功能时系统出现错误。主要是角色拥有不属于自己的权限，联系人删除页面跳转错误等。

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

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

8.3.  界面设计易用性缺陷

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

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

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

3、

8.4.  开发人员疏忽引起的缺陷

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

1.

2.