测试分析报告
前言：本站为你精心整理了测试分析报告范文，希望能为你的创作提供参考价值，我们的客服老师可以帮助你提供个性化的参考范文，欢迎咨询。
1.概述
1.1项目简介
本章节中简介项目的基本情况
1.2术语定义
将该测试报告中的术语、缩写进行定义，包括用户应用领域与计算机领域的术语与缩略语等。
1.3参考资料
说明该测试报告使用的参考资料：如
【1】……
【2】……
1.4版本更新信息
版本更新记录格式，如下所表示：
表1－1版本更新记录
版本号
创建者
创建日期
维护者
维护日期
维护记录
V1.0
大林
2008/01/12
—
—
—
V1.01
—
—
萧萧
2008/03/24
不符合项测试
2.目标系统界面需求
由《用户需求报告》/《需求规格说明书》拷贝到的用户界面需求点列表，如下表所示：
编号功能名称使用部门使用岗位功能描述输入内容输出内容
1
2
3
3.目标系统功能需求
由《用户需求报告》/《需求规格说明书》拷贝到的功能需求点列表，如下表所示：
表1-2功能需求点列表
编号功能名称使用部门使用岗位功能描述输入内容输出内容
1
2
3
4.目标系统性能需求
由《用户需求报功能告》/《需求规格说明书》拷贝到的需求性能点列表，如下表所示：
表1-3需求性能点列表
编号性能名称使用部门使用岗位功能描述输入内容输出内容
1
2
3
5.目标系统接口需求
由《用户需求报功能告》/《需求规格说明书》拷贝到的接口列表，如下表所示：
表1-4需求性能点列表
编号接口名称接口规范接口标准入口参数出口参数传输频率
1
2
3
6.用户界面测试报告
搭建系统测试平台，使测试平台与运行平台一致。按照用户界面描述列表内容，设计测试用例（输入/输出）内容，进行现场测试，记录测试数据，评定测试结果。测试活动的记录格式如下表所示：
用户界面测试列表
编号界面名称界面描述输入内容输出内容发现问题测试结果测试时间测试人
1
√
2
√
3
√
4
×
7.功能测试报告
搭建功能测试平台，使测试平台与运行平台一致。按照功能点列表内容，设计测试用例（输入/输出）内容，进行现场测试，记录测试数据，评定测试结果。测试活动的记录格式如下表所示：
功能测试记录表
编号功能名称功能描述输入内容输出内容发现问题测试结果测试时间测试人
1
√
2
√
3
√
4
×
8.性能测试报告
搭建性能测试平台，使测试平台与运行平台一致。按照性能点列表内容，设计测试用例（输入/输出）内容，进行现场测试，记录测试数据，评定测试结果。测试活动的记录格式如下表所示：
性能测试记录表
编号
性能名称
性能描述
输入内容
输出内容
发现问题
测试结果
测试时间
测试人
1
√
2
√
3
×
4
√
9.接口测试报告
搭建功能测试平台，使测试平台与运行平台一致。按照接口列表内容，设计测试用例（输入/输出）内容，进行现场测试，记录测试数据，评定测试结果。测试活动的记录格式如下表所示：
接口测试记录表
编号
接口名称
入口参数
出口参数
传输频率
发现问题
测试结果
测试时间
测试人
1
×
2
√
3
√
10.数据库测试
数据库操作响应时间；
数据库容量；
数据库设计检查；
数据库连接；
11.安装、卸载测试
1）安装正确性和完整性核对
2）安装卸载测试兼容性检查点
12.不符合项列表
将测试中的所有不符合项(bug项)，整理后分别记录到下面三个表中：
功能测试不符合项列表
编号
功能名称
功能描述
输入内容
输出内容
发现问题
测试结果
测试时间
测试人
1
×
2
×
3
×
4
×
性能测试不符合项列表
编号
性能名称
性能描述
输入内容
输出内容
发现问题
测试结果
测试时间
测试人
1
×
2
×
3
×
4
×
接口测试不符合项列表
编号
接口名称
入口参数
出口参数
传输频率
发现问题
测试结果
测试时间
测试人
1
×
2
×
3
×
以上不符合项限期××天内改正。改正完毕后重新进行回归测试。
13.测试结果及缺陷分析
13.1测试执行情况与记录
描述测试资源消耗情况，记录实际数据。（测试、项目经理关注部分）
13.1.1测试组织
可列出简单的测试组架构图，包括：
测试组架构（如存在分组、用户参与等情况）
测试经理（领导人员）
主要测试人员
参与测试人员
13.1.2测试时间
列出测试的跨度和工作量，最好区分测试文档和活动的时间。数据可供过程度量使用。
例如XXX子系统/子功能
实际开始时间－实际结束时间
总工时/总工作日
任务开始时间结束时间总计
合计
对于大系统/项目来说最终要统计资源的总投入，必要时要增加成本一栏，以便管理者清楚的知道究竟花费了多少人力去完成测试。
测试类型人员成本工具设备其他费用
总计
在数据汇总时可以统计个人的平均投入时间和总体时间、整体投入平均时间和总体时间，还可以算出每一个功能点所花费的时/人。
用时人员编写用例执行测试总计
合计
这部分用于过程度量的数据包括文档生产率和测试执行率。
生产率人员用例/编写时间用例/执行时间平均
合计
13.1.3测试版本
给出测试的版本，如果是最终报告，可能要报告测试次数回归测试多少次。列出表格清单则便于知道那个子系统/子模块的测试频度，对于多次回归的子系统/子模块将引起开发者关注。
13.2覆盖分析
13.2.1需求覆盖
需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。
需求/功能（或编号）测试类型是否通过备注
[Y][P][N][N/A]
根据测试结果，按编号给出每一测试需求的通过与否结论。P表示部分通过，N/A表示不可测试或者用例不适用。实际上，需求跟踪矩阵列出了一一对应的用例情况以避免遗漏，此表作用为传达需求的测试信息以供检查和审核。
需求覆盖率计算Y项/需求总数×100％
13.2.2测试覆盖
需求/功能（或编号）用例个数执行总数未执行未/漏测分析和原因
实际上，测试用例已经记载了预期结果数据，测试缺陷上说明了实测结果数据和与预期结果数据的偏差；因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差，列表的目的仅在于更好的查看测试结果。
测试覆盖率计算执行数/用例总数×100％
13.3缺陷的统计与分析
缺陷统计主要涉及到被测系统的质量，因此，这部分成为开发人员、质量人员重点关注的部分。
13.3.1缺陷汇总
被测系统系统测试回归测试总计
合计
按严重程度
严重一般微小
按缺陷类型
用户界面一致性功能算法接口文档用户界面其他
按功能分布
功能一功能二功能三功能四功能五功能六功能七
最好给出缺陷的饼状图和柱状图以便直观查看。俗话说一图胜千言，图标能够使阅读者迅速获得信息，尤其是各层面管理人员没有时间去逐项阅读文章。
图例
13.3.2缺陷分析
本部分对上述缺陷和其他收集数据进行综合分析
缺陷综合分析
缺陷发现效率＝缺陷总数/执行测试用时
可到具体人员得出平均指标
用例质量＝缺陷总数/测试用例总数×100％
缺陷密度＝缺陷总数/功能点总数
缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需求缺陷最多，从而在今后开发注意避免并注意在实施时予与关注，测试经验表明，测试缺陷越多的部分，其隐藏的缺陷也越多。
测试曲线图
描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向
重要缺陷摘要
缺陷编号简要描述分析结果备注
13.3.3残留缺陷与未解决问题
残留缺陷
编号：BUG号
缺陷概要：该缺陷描述的事实
原因分析：如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因
预防和改进措施：弥补手段和长期策略
未解决问题
功能/测试类型：
测试结果：与预期结果的偏差
缺陷：具体描述
评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响
14.测试结论与建议
报告到了这个部分就是一个总结了，对上述过程、缺陷分析之后该下个结论，此部分为项目经理、部门经理以及高层经理关注，请清晰扼要的下定论。
14.1测试结论
1．测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
2．对测试风险的控制措施和成效
3．测试目标是否完成
4．测试是否通过
5．是否可以进入下一阶段项目目标
14.2建议
1．对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响
2．可能存在的潜在缺陷和后续工作
3．对缺陷修改和产品设计的建议
4．对过程改进方面的建议
