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

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

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

测试报告XX项目测试环境

XX项目

测试报告

版本信息

日期

版本

状态

简要描绘

编写

审查

赞同

2018-07-18

初次成立项目测试报告（标准版）

xxx

模板

注：

状态能够为N-新建、A-增添、M-改正、D-删除

目

录

1

编写目的

错误!

不决义书签。

2

测试参照文档

错误!

不决义书签。

3项目信息错误!

不决义书签。

4测试概括错误!

不决义书签。

基本信息

错误!

不决义书签。

测试过程

错误!

不决义书签。

测试范围

错误!

不决义书签。

5测试过程评估

错误!

不决义书签。

测试设计

错误!

不决义书签。

测试用例

错误!

不决义书签。

测试方法

错误!

不决义书签。

测试履行

错误!

不决义书签。

测试用例覆盖总结

错误!

不决义书签。

测试用例履行总结

错误!

不决义书签。

6缺点统计与剖析错误!

不决义书签。

缺点统计错误!

不决义书签。

缺点剖析错误!

不决义书签。

缺点散布--按严重等级区分错误!

不决义书签。

缺点散布--按功能模块区分错误!

不决义书签。

缺点散布--按缺点种类区分错误!

不决义书签。

缺点趋向--新增缺点错误!

不决义书签。

缺点趋向--从头翻开缺点

错误!

不决义书签。

缺点趋向--改正缺点

错误!

不决义书签。

缺点趋向--封闭缺点

错误!

不决义书签。

7

版本需求改正剖析

错误!

不决义书签。

需求改正描绘

错误

!

不决义书签。

需求改正统计

错误

!

不决义书签。

8

版本演进轨迹

错误

!

不决义书签。

9测试总结错误!

不决义书签。

测试结论错误!

不决义书签。

测试建议错误!

不决义书签。

遗留问题列表错误!

不决义书签。

风险剖析错误!

不决义书签。

编写目的

本测试报告为【XX】项目的测试报告，目的在于总结测试阶段的测试状况以及剖析测试结果，描绘系统能否切合需求并对测试质量进行剖析。

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

测试参照文档

《用户需求说明书》

《软件需求规格说明书》

《软件开发计划》

《软件测试计划》

《软件测试方案》

《软件测试策略》

《软件测试用例》

《缺点分类指南》

《功能及UI测试标准》

项目信息

项目名称

xx

项目编号

xxx

项目周期

2018/1/19~2018/2/26

项目性质

崭新产品

/大版本升级

/小版本升级（只好选择一个）

项目版本号

项目经理

xxx

测试经理

xxx

测试工程师

xxx

开发工程师

xxx

测试概括

基本信息

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

测试时间

2018/1/19~2018/2/26

办理器：

InterCorei5，

测试环境

硬件

内存：

8GB

操作系统：

Windows10

软件

NavicatPremium、xshell、IE，FireFox，CoogleChrome等阅读器

测试站点

无无无无

编写测试策略

编写测试方案

编写测试用例

评审测试用例

测试环境准备

测试数据准备

测试脚本准备

系统测试

测试履行

回归测试

编写测试报告

测试结束

编写用户手册

培训

项目实行

项目部署

测试范围

测试覆盖功能点

任务

一级功能二级功能三级功能

历史

新增及改正

测试过程评估

测试设计

测试用例

测试用例的设计方法采纳等价类区分、界限值、因果图、错误推断法等。

依照需求文档和原型图设计测试用例，测试用例覆盖所有需求功能点，在评审通事后履行测试。

测试方法

依据系统需求规格说明书的描绘，明确指出了系统应当拥有的功能。

在完好不考虑程序内部

构造和内部特征的状况下，测试者只要检查程序功能能否依照系统需求规格说明书的规定正

常使用，能否能在输入适合的数锯下产生正确的输出信息，而且能保持外面信息（如数据库

或文件）的完好性。

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

黑盒测试。

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

测试履行

测试用例覆盖总结

履行的测试用例数覆盖了所有的功能点

用例数

模块名称覆盖状况履行状况

（条）

履行94条，未经过1条

客户管理94系统测试2轮，查收测试2轮

用例经过率：

%

测试用例履行总结

测试履行统计表

工作量投入

测试用例规模

测试用例版本号

总用例数

新增用例数

（人天）

履行结果统计表

计划履行的

实质履行的

经过的

用例数

用例数

履行率

覆盖率

经过率

发现缺点数

用例数

履行率=实质履行的用例数÷计划履行的用例数

覆盖率=实质履行的用例数÷总用例数

经过率=经过的用例数÷实质履行的用例数

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

<事例总数与计划履行事例数不一致，请说明原由。

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

>

<计划履行事例数与实质履行事例数不一致，请说明原由。

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

>

缺点统计与剖析

缺点统计

缺点总计：

28个；

翻开：

17个；

办理中：

2个；

从头翻开：

3个；

已解决：

5个；

已封闭：

1个

缺点剖析

缺点散布--按严重等级区分

缺点严重等级共计已封闭未解决已封闭所占百分比

稍微-Trivial

一般-Minor

重要-Major

严重-Critical

堵塞-Blocker

缺点散布--按功能模块区分

模块名称共计已封闭未解决已封闭所占百分比

缺点散布--按缺点种类区分

缺点种类

共计

已封闭

未解决

已封闭所占百分比

需求问题

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%

缺点趋向--新增缺点

缺点趋向--从头翻开缺点

缺点趋向--改正缺点

缺点趋向--封闭缺点

版本需求改正剖析

需求改正描绘

本次版本测试共收到35个需求改正：

此中14个为测试过程中已有项目的需求改正，主要

集中在准时装项目、国外购二期项目、在线支付异样同步商家需求等需求中；4个技术优化，

17个为新增的需求改正。

本次版本需求改正数目仍旧许多，需求改正方面的控制还需增强，

版本的改正对版实质量的影响很大，本次版本公布风险较高。

需求改正统计

新增需求：

12个

改正需求：

1个

需求优化：

23个

版本演进轨迹

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

版本号公布时间

能否归并

回归测试结果

否

经过

测试总结

测试结论

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

<测试结论要明确，即经过或许不经过，不可以附加任何条件。

关于有条件经过的需求，需要在后续“风险剖析”章节进行描绘>，有条件经过是依据准出条件有部分条件不经过，详细准则以下：

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

测试事例履行率达到95%、堵塞和致命的缺点所有修复且测试经过、

严重缺点修复率超出95%、一般缺点修复率已超出85%、提示缺点修复率超出75%；

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

测试事例履行率低于95%、堵塞和致命缺点未所有修复或复测

未经过、严重缺点修复率未达到95%、一般缺点修复率未达到85%，提示缺点修复率未达到75%；有条件经过----指未达到准出条件但项目责任人确认有关风险，或风险能够获得办理，在此条件

下赞同测试有条件经过。

经过对本系统的两轮测试工作，将系统所存在的缺点所有裸露并交予开发人员进行bug修

复，再经过回归测试保证了所有功能及模块已经实现，而且知足客户需求。

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

当前的测试工作基本达到了预约目标，即达成除原有的系统功能外的所有功能及模块功能的

功能测试，测试任务已全面达成。

依据测试结果、BUG的修复率和测试计划中的测试经过标准得出该项目功能测试经过，能够交托使用。

测试建议

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

编写框中数据输入过长不可以正确办理或许页面

变形，页面款式不一致（翻页、提示语等）

，数据增添成功，上传附件不显示，查问冗余数

据等。

开发人员在编码过程中，系统在实现基本功能的前提下需要注意页面款式的一致性和

操作界面友善性等非功能的方面。

在此次测试过程中，提出建议：

测试人员在提交

bug时，需要详尽描绘：

版本号、操作步骤、

希望结果、实质结果，以便开发人员读懂并能重现

bug，防止将bug直接打回，延伸bug的

存在周期。

同时开发人员一定将打回

bug以前需赐予问题解答的简单描绘，以利于回归测试。

在本次测试中因没有依照标准履行，

致使有些bug在回归几次后才有效解决，所以一定在以

后的测试项目中测试人员和开发人员严格依照标准履行。

在本次测试过程中存在一个问题多次改正的状况。

造成此问题出现的最主要原由是开发人员

在提交新版本时未进行单元测试。

所以，我们建议开发人员将程序包提交给测试人员以前先

对程序代码进行检查，这样能有效地缩短

BUG的生计周期，提升测试人员和开发人员的工

作效率。

遗留问题列表

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

关于其余需要需求负责人、开发负责人、版本负责

人等加以关注或许加以改良的问题，也需要在此处列出>

缺点编号

严重级

重现

影响说明

遗留原由

缺点描绘

别

概率

致命

100%

致使系统崩

需求改正，待确认需求

溃

后一致改正