项目名称确认测试报告
变更记录
序号版本号修改单号修改条款及内容修改人/日期批准人/日期
说明中哪个版本中修改的
日期+序号，如：2008030901
日期+序号，如：2008030902
注：对该文件内容增加、删除或修改均需填写此变更记录，详细记载变更信息，以保证其可追溯性。

1. 前言
1.1 测试概要
//概括描述各测试项目的测试计划与实际测试执行情况之间是否有差异。

如与测试计划有差异，描述产生差异的原因。

//示例：测试执行时间延后，原因是测试机器没有到位。

1.2 相关文档
《确认测试计划》
1.3 测试环境
//详细描述实际测试环境，如硬件环境、软件环境、网络环境等
//示例：
硬件环境：
应用服务器：华为刀片服务器T8000\CPU×2：AMD2.2GHz（双核）\内存：4GB\硬盘：80GB 数据库服务器：华为刀片服务器T8000\CPU×2：AMD2.2GHz（双核）\内存：4GB\硬盘：80GB 软件环境：
应用服务器：Windows 2003 SP1、Weblogic 9.2
数据库服务器：：Windows 2003 SP1、Oracle 10g
网络环境：100M局域网
2. 测试结果
2.1 功能模块1
用例ID 功能点测试结果遗留问题描述
Fjyd－
房间查询不通过//查询结果不正确
01
Fjyd－
房间预定通过/
02
Fjyd－
…未测试
03
……………………
2.2 功能模块2
用例ID 功能点测试结果遗留问题描述
Fjyd－
房间查询不通过//查询结果不正确
01
Fjyd－
房间预定通过/
02
Fjyd－
…未测试
03
……………………
2.3 文档测试
用例ID 测试点测试结果遗留问题描述
Wdcs－
用户手册通过/
01
……………………
2.4 //可根据实际测试内容拟定标题
3. 测试总结
//本章是对测试过程中发现的问题进行分类统计，并重点对问题原因进行分析，从而得出测试结论，给出改进建议。

3.1 问题分类和统计
//对测试过程中记录的软件问题进行分类统计（可以根据计划中制定问题划分原则分类，下面提供的分类方法只是参考，不需都进行统计，但按照问题原因分类必须要统计，可以采用图形的方式进行统计）
//示例：
按照问题严重程度分类（可选）：
功能问题状态分类统计小计总计
严重未修改0
50
242 已修改50
一般未修改0
109 已修改109
建议未修改17
83 已修改66
或者
按照问题所属功能模块进行分类（可选）
功能模块问题状态分类统计小计总计
房间预定未修改0
50 242 已修改50
或者利用图形的形式
按照问题原因分类（必选）：（请根据项目的实际测试情况，加入问题详细原因分类）问题引入阶段问题详细原因分类统计
需求
需求不明确0
需求变更0
… … 设计
设计缺陷
2 设计与需求不符
1 … …
开发
不理解设计或需求
6 编码错误
50 版本管理造成问题重复出现
1 … …
测试
不理解设计和需求
2 操作不当
测试案例设计不合理
… …
其他（//测试环境等原因造成的其他问题） …
合计
分析问题在测试过程中的趋势
问题发现趋势
10203040
50第一轮
第二轮第三轮
第四轮
测试轮次
个数
严重
一般建议
3.2 问题原因分析
请结合实际项目，进行了以上问题的分类统计后，对问题出现的原因进行详细分析，下述例子仅为参考。

//示例：
测试时发现的问题主要集中在房间查询模块，经过两次测试，已发现的××和×××问题均被修改。

发现的问题主要有以下几类：
●查询功能
●易用性差
问题原因主要为：
●编码实现问题较多，代码检查和单元测试工作力度不够
●测试人员不理解需求，没有培训。

●……
3.3 测试结论
描述测试总体情况，是否达到了测试目的，
总结出软件是否达到了《概要设计说明书》要求
//示例：
本次测试严格按照测试计划和测试用例进行的测试，测试出的问题都已经解决，基本达到了测试目的。

软件达到了《概要设计说明书》要求。

3.4 改进建议
无。

//提供一些系统设计、操作和软件测试的改进建议，并分析每一建议对项目的影响。

若无建议，则标明“无”。

//示例：
软件存在一些错误和界面风格不统一的地方，应修改错误、提高产品质量；发现的问题多数是开发人员编码问题，建议加强单元测试
3.5 测试局限性
阐述本次测试中未测试内容及原因，测试过程中出现的问题及影响
//示例：本次测试环境未包括门卡管理系统，故未对相关门卡的功能进行功能验证。

4. 产品缺陷清单
详细内容请参见附录。

确认测试报告附录
//可以用测试管理工具导出的问题清单或者采用公司《产品缺陷清单》，作为附录
- 7 -。