测试报告XX项目测试环境.docx

测试报告XX项目测试环境.docx

《测试报告XX项目测试环境.docx》由会员分享，可在线阅读，更多相关《测试报告XX项目测试环境.docx（18页珍藏版）》请在冰点文库上搜索。

测试报告XX项目测试环境

XX项目

测试报告

{

版本信息

日期

版本

状态

>

简要描述

编写

审核

批准

2018-07-18

）

首次建立项目测试报告（标准版）模板

xxx

'

注：

状态可以为N-新建、A-增加、M-更改、D-删除

{

1编写目的

本测试报告为【XX】项目的测试报告，目的在于总结测试阶段的测试情况以及分析测试结果，描述系统是否符合需求并对测试质量进行分析。

本报告作为测试质量参考文档提供给用户、测试人员、开发人员、项目管理者、其他质量管理人员和需要阅读本报告的高层经理阅读。

2测试参考文档

*

《用户需求说明书》

《软件需求规格说明书》

《软件开发计划》

《软件测试计划》

《软件测试方案》

《软件测试策略》

《软件测试用例》

&

《缺陷分类指南》

《功能及UI测试标准》

3项目信息

项目名称

xx

项目编号

xxx

】

项目周期

2018/1/19~2018/2/26

项目性质

全新产品/大版本升级/小版本升级（只能选择一个）

项目版本号

v80712_01_beta

项目经理

"

xxx

测试经理

xxx

测试工程师

xxx

开发工程师

xxx

/

4测试概述

4.1基本信息

本次测试的基本信息如下：

测试时间

2018/1/19~2018/2/26

测试环境

；

硬件

处理器：

InterCorei5，

内存：

8GB

操作系统：

Windows10

软件

NavicatPremium、xshell、IE，FireFox，CoogleChrome等浏览器

测试站点

；

4.2

^

、

。

无

无

无

无

^

编写测试策略

…

%

编写测试方案

-

编写测试用例

#

评审测试用例

。

测试环境准备

\

测试数据准备

@

@

测试脚本准备

】

测试执行

系统测试

'

回归测试

/

！

测试结束

编写测试报告

！

编写用户手册

#

项目实施

[

培训

、

项目部署

:

：

4.3测试范围

任务

测试覆盖功能点

一级功能

`

二级功能

三级功能

历史

：

^

"

!

-

?

{

、

~

-

…

新增及修改

》

&

{

5测试过程评估

5.1

5.2·

5.3测试设计

5.3.1测试用例

1、测试用例的设计方法采用等价类划分、边界值、因果图、错误推测法等。

2、依据需求文档和原型图设计测试用例，测试用例覆盖所有需求功能点，在评审通过后执行测试。

5.3.2测试方法

根据系统需求规格说明书的描述，明确指出了系统应该具有的功能。

在完全不考虑程序内部结构和内部特性的情况下，测试者只需检查程序功能是否按照系统需求规格说明书的规定正常使用，是否能在输入适当的数锯下产生正确的输出信息，并且能保持外部信息（如数据库或文件）的完整性。

因此采用了着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试的测试方法：

黑盒测试。

本次测试的重点集中在基本数据录入、业务流程和各功能模块间的接口。

5.4测试执行

5.4.1~

5.4.2

5.4.3测试用例覆盖总结

1、执行的测试用例数覆盖了所有的功能点

模块名称

用例数（条）

覆盖情况

执行情况

客户管理

《

94

系统测试2轮，验收测试2轮

执行94条，未通过1条

用例通过率：

%

\

（

%

?

【

5.4.4

5.4.5测试用例执行总结

…

测试执行统计表

测试用例版本号

工作量投入（人天）

测试用例规模

总用例数

（

新增用例数

执行结果统计表

计划执行的用例数

实际执行的用例数

通过的用例数

执行率

覆盖率

通过率

发现缺陷数

【

执行率=实际执行的用例数÷计划执行的用例数

覆盖率=实际执行的用例数÷总用例数

通过率=通过的用例数÷实际执行的用例数

发现缺陷数=本次版本一共提交了多少个BUG单

<案例总数与计划执行案例数不一致，请说明原因。

（指本次测试总案例数与本次测试总的计划执行案例数），与本文最后一个章节的风险相对应。

>

<计划执行案例数与实际执行案例数不一致，请说明原因。

（指本次测试总的计划执行案例数与本次执行总的实际执行案例数），与本文最后一个章节的风险相对应。

>

[

&

6缺陷统计与分析

6.1缺陷统计

缺陷总计：

28个；

打开：

17个；

处理中：

2个；

重新打开：

3个；

已解决：

5个；

已关闭：

1个

6.2缺陷分析

6.2.1

6.2.2缺陷分布--按严重等级划分

缺陷严重等级

。

合计

已关闭

未解决

已关闭所占百分比

轻微-Trivial

·

一般-Minor

[

重要-Major

严重-Critical

.

阻塞-Blocker

￥

6.2.3

6.2.4缺陷分布--按功能模块划分

模块名称

合计

已关闭

未解决

已关闭所占百分比

—

"

`

$

'

6.2.5缺陷分布--按缺陷类型划分

缺陷类型

合计

]

已关闭

未解决

已关闭所占百分比

需求问题

4

1

3

、

25%

代码问题

3

1

2

33%

设计问题

6

2

4

33%

配置问题

4

2

2

;

50%

环境问题

4

3

1

75%

兼容问题

/

9

4

5

44%

安全问题

3

1

`

2

33%

性能问题

3

3

0

100%

/

脚本问题

3

1

2

33%

数据问题

4

*

3

1

75%

其他

7

4

3

\

57%

非缺陷

5

1

4

20%

6.2.6缺陷趋势--新增缺陷

6.2.7缺陷趋势--重新打开缺陷

]

6.2.8缺陷趋势--修改缺陷

6.2.9缺陷趋势--关闭缺陷

7：

8

9版本需求变更分析

9.1需求变更描述

本次版本测试共收到35个需求变更：

其中14个为测试过程中已有项目的需求变更，主要集中在准时装项目、海外购二期项目、在线支付异常同步商家需求等需求中；4个技术优化，17个为新增的需求变更。

本次版本需求变更数量依旧不少，需求变更方面的控制还需加强，版本的变更对版本质量的影响很大，本次版本发布风险较高。

9.2需求变更统计

新增需求：

12个

变更需求：

1个

需求优化：

23个

（

10

11版本演进轨迹

罗列本项目内的所有分支及各个分支合并后的回归测试

版本号

发布时间

是否合并

回归测试结果

。

v80712_01_beta

2018-07-19

否

通过

￥

12测试总结

12.1测试结论

<对测试的过程和结果进行简要分析，给出测试结论和建议>

<测试结论要明确，即通过或者不通过，不能附带任何条件。

对于有条件通过的需求，需要在后续“风险分析”章节进行描述>，有条件通过是根据准出条件有部分条件不通过，具体准则如下：

通过----达到准出条件，如：

测试案例执行率达到95%、阻塞和致命的缺陷全部修复且测试通过、严重缺陷修复率超过95%、一般缺陷修复率已超过85%、提示缺陷修复率超过75%；

不通过----未达到准出条件，如：

测试案例执行率低于95%、阻塞和致命缺陷未全部修复或复测未通过、严重缺陷修复率未达到95%、一般缺陷修复率未达到85%，提示缺陷修复率未达到75%；

有条件通过----指未达到准出条件但项目责任人确认相关风险，或风险可以得到处理，在此条件下同意测试有条件通过。

1、通过对本系统的两轮测试工作，将系统所存在的缺陷全部暴露并交予开发人员进行bug修复，再经过回归测试确保了所有功能及模块已经实现，并且满足客户需求。

2、本系统的测试充分有效，主要业务模块的测试覆盖达到100%，缺陷解决率达到100%。

3、目前的测试工作基本达到了预定目标，即完成除原有的系统功能外的所有功能及模块功能的功能测试，测试任务已全面完成。

4、根据测试结果、BUG的修复率和测试计划中的测试通过标准得出该项目功能测试通过，可以交付使用。

12.2测试建议

1、从测试的整个过程来看，比较常见的问题是：

编辑框中数据输入过长不能正确处理或者页面变形，页面样式不统一（翻页、提示语等），数据添加成功，上传附件不显示，查询冗余数据等。

开发人员在编码过程中，系统在实现基本功能的前提下需要注意页面样式的一致性和操作界面友好性等非功能的方面。

2、在这次测试过程中，提出建议：

测试人员在提交bug时，需要详细描述：

版本号、操作步骤、期望结果、实际结果，以便开发人员读懂并能重现bug，避免将bug直接打回，延长bug的存在周期。

同时开发人员必须将打回bug之前需给予问题解答的简单描述，以利于回归测试。

在本次测试中因没有按照标准执行，导致有些bug在回归几次后才有效解决，所以必须在以后的测试项目中测试人员和开发人员严格按照标准执行。

3、在本次测试过程中存在一个问题多次修改的情况。

造成此问题出现的最主要原因是开发人员在提交新版本时未进行单元测试。

所以，我们建议开发人员将程序包提交给测试人员之前先对程序代码进行检查，这样能有效地缩短BUG的生存周期，提高测试人员和开发人员的工作效率。

12.3遗留问题列表

<给出遗留的影响到系统上线或者进入下一个环节的问题，比如，状态为“致命”的测试缺陷，或者需要重点关注的状态为“严重”的测试缺陷。

对于其他需要需求负责人、开发负责人、版本负责人等加以关注或者加以改进的问题，也需要在此处列出>

缺陷编号

缺陷描述

严重级别

重现概率

影响说明

遗留原因

致命

100%

导致系统崩溃

需求变更，待确认需求后统一修改

严重

100%

导致数据丢失

数据库迁移，待迁移后修复

12.4风险分析

<对系统上线或者进入下一个环节有可能存在的风险进行分析，并提出规避的措施或者建议，以便相关人员对此进行关注或者解决问题>

序号

风险问题类型

风险问题描述

风险等级

提出人

提出时间

责任人

应对解决方案

计划解决日期

问题状态

备注

1

第三方插件问题

第三方插件无法正常加载

中　

XXX　

XXX

开发在查问题中

未解决

2

代码重构

代码重构后，引发大量BUG

高

XXX

XXX

开发修改

未解决

3

需求变更

需求变更过于频繁，无法及时开发完成

中

XXX

XXX

下个版本迭代开发