测试报告项目测试环境

XX项目

测试报告

版本信息

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

目录

1编写目的 (2)

2测试参考文档 (2)

3项目信息 (2)

4测试概述 (3)

4.1基本信息 (3)

4.2测试过程 (3)

4.3测试范围 (4)

5测试过程评估 (5)

5.1测试设计 (5)

5.1.1测试用例 (5)

5.1.2测试方法 (5)

5.2测试执行 (5)

5.2.1测试用例覆盖总结 (5)

5.2.2测试用例执行总结 (6)

6缺陷统计与分析 (6)

6.1缺陷统计 (6)

6.2缺陷分析 (6)

6.2.1缺陷分布--按严重等级划分 (6)

6.2.2缺陷分布--按功能模块划分 (7)

6.2.3缺陷分布--按缺陷类型划分 (7)

6.2.4缺陷趋势--新增缺陷 (7)

6.2.5缺陷趋势--重新打开缺陷 (7)

6.2.6缺陷趋势--修改缺陷 (7)

6.2.7缺陷趋势--关闭缺陷 (7)

7版本需求变更分析 (7)

7.1需求变更描述 (7)

7.2需求变更统计 (8)

8版本演进轨迹 (8)

9测试总结 (8)

9.1测试结论 (8)

9.2测试建议 (9)

9.3遗留问题列表 (9)

9.4风险分析 (10)

1编写目的

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

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

2测试参考文档

《用户需求说明书》

《软件需求规格说明书》

《软件开发计划》

《软件测试计划》

《软件测试方案》

《软件测试策略》

《软件测试用例》

《缺陷分类指南》

《功能及UI测试标准》

3项目信息

4测试概述

4.1基本信息

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

4.2测试过程

4.3测试范围

5测试过程评估

5.1测试设计

5.1.1测试用例

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

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

后执行测试。

5.1.2测试方法

根据系统需求规格说明书的描述，明确指出了系统应该具有的功能。在完全不考虑程序内部结构和内部特性的情况下，测试者只需检查程序功能是否按照系统需求规格说明书的规定正常使用，是否能在输入适当的数锯下产生正确的输出信息，并且能保持外部信息（如数据库或文件）的完整性。因此采用了着眼于程序外部结构、不考虑内部逻辑结构、针对软件界面和软件功能进行测试的测试方法：黑盒测试。

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

5.2测试执行

5.2.1测试用例覆盖总结

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

5.2.2测试用例执行总结

测试执行统计表

执行结果统计表

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

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

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

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

<案例总数与计划执行案例数不一致，请说明原因。（指本次测试总案例数与本次测试总的计划执行案例数），与本文最后一个章节的风险相对应。>

<计划执行案例数与实际执行案例数不一致，请说明原因。（指本次测试总的计划执行案例数与本次执行总的实际执行案例数），与本文最后一个章节的风险相对应。>

6缺陷统计与分析

6.1缺陷统计

缺陷总计：28个；

打开：17个；

处理中：2个；

重新打开：3个；

已解决：5个；

已关闭：1个

6.2缺陷分析

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

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

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

6.2.4缺陷趋势--新增缺陷

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

6.2.6缺陷趋势--修改缺陷

6.2.7缺陷趋势--关闭缺陷

7版本需求变更分析

7.1需求变更描述

本次版本测试共收到35个需求变更：其中14个为测试过程中已有项目的需求变更，主要集中在准时装项目、海外购二期项目、在线支付异常同步商家需求等需求中；4个技术优

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

7.2需求变更统计

新增需求：12个

变更需求：1个

需求优化：23个

8版本演进轨迹

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

9测试总结

9.1测试结论

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

<测试结论要明确，即通过或者不通过，不能附带任何条件。对于有条件通过的需求，需要在后续“风险分析”章节进行描述>，有条件通过是根据准出条件有部分条件不通过，具体准则如下：

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

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

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