系统测试报告模板.docx
《系统测试报告模板.docx》由会员分享，可在线阅读，更多相关《系统测试报告模板.docx（12页珍藏版）》请在冰豆网上搜索。
系统测试报告模板
项目名称
系统测试报告
文件状态：
[]草稿
[√]正式发布
[]正在修改
编制
日期
版本
文档修订记录
版本
修订人
审核人
批准
更改记录
（标注页码、章节、简要内容）
修订人
日期
审核人
日期
批准人
日期
目录
1引言1
1.1编写目的1
1.2背景1
1.3读者对象1
1.4参考资料1
1.5术语与缩写解释1
2测试执行情况2
2.1测试机构和人员2
2.2测试时间2
3缺陷统计与分析3
3.1覆盖分析3
3.2缺陷统计4
3.3缺陷分析5
4测试结论与建议7
4.1测试结论7
4.2建议7
5附录8
5.1附录1缺陷严重等级定义8
1引言
1.1编写目的
【描述本测试报告的具体编写目的。
实例：
本测试报告为XXX项目的测试报告，目的在于总结测试阶段的测试以及分析测试结果，描述系统是否符合需求（或达到XXX功能目标）。
】
1.2背景
1.3读者对象
【预期参考人员包括用户、测试人员、开发人员、项目经理、QA和需要阅读本报告的高层经理。
】
1.4参考资料
＃
资料或文献
作者
说明
1
2
1.5术语与缩写解释
＃
缩略语及名词
全称
说明
1
2
2
测试执行情况
2.1测试机构和人员
测试组架构：
【提示：
对本次测试小组的情况进行描述，如如何分组、用户参与等情况。
】
测试经理：
主要测试人员：
参与测试人员：
2.2测试时间
测试对象
开始日期
结束日期
测试人
工作量（人时）
备注
模块1
模块2
……
合计
3
缺陷统计与分析
3.1覆盖分析
Ø需求覆盖率：
＃
需求/功能（或编号）
测试类型
是否通过
是否覆盖
备注
1
子模块1
Y、P、N、N/A
覆盖、否
2
子模块2
3
子模块3
4
子模块4
5
子模块5
……
合计
需求总数：
Y项总数：
注：
Y表示通过，P表示部分通过，N表示不通过，N/A表示不可测试或者用例不适用。
【需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到100％的目标。
根据测试结果，按编号给出每一测试需求的通过与否结论。
实际上，需求跟踪矩阵列出了一一对应的用例情况以避免遗漏，此表作用为传达需求的测试信息以供检查和审核。
】
需求覆盖率＝Y项总数/需求总数×100％＝？
Ø测试覆盖率：
＃
需求/功能（或编号）
用例个数
执行个数
未执行数
未/漏测分析和原因
1
子模块1
2
子模块2
3
子模块3
4
子模块4
5
子模块5
……
合计
【实际上，测试用例已经记载了预期结果数据，测试缺陷上说明了实测结果数据和与预期结果数据的偏差；因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差，列表的目的仅在于更好的查看测试结果。
】
测试覆盖率＝执行合计数/用例合计数×100％＝？
3.2缺陷统计
Ø按缺陷严重等级：
【对本轮测试发现的缺陷按严重等级统计，并给出饼图，形象说明缺陷严重度的情况。
】
＃
功能性需求
测试人
按缺陷严重等级
S1
S2
S3
S4
S5
小计
1
功能点1
2
功能点2
……
合计
Ø按缺陷状态：
【对测试发现的所有缺陷按缺陷状态统计，并给出饼图，形象说明缺陷修复的情况。
】
＃
功能性需求
测试人
按缺陷状态
未修改
已修改
已关闭
不修改
延期修改
小计
Open
Reopen
Fixed
Closed
Rejected
Deferred
1
功能点1
2
功能点2
……
合计
3.3缺陷分析
【提示：
先对缺陷进行综合分析，然后按下面公式分别给出结果，最后画出测试曲线图，描绘被测系统每工作日/周缺陷数情况，得出缺陷走势和趋向。
粗体字的数据必须统计和计算。
（有关缺陷的具体操作规程和计算定义，请参照《度量数据操作规程》《数据度量操作定义》）】
缺陷发现效率＝本轮缺陷总数/执行测试用时＝？
用例质量＝本轮缺陷总数/测试用例总数×100％＝？
缺陷密度＝本轮缺陷总数/功能点总数＝？
系统缺陷密度（个/KLOC）＝系统阶段完成后bug数/系统规模；3级（含3级）以上bug和3级以下bug分别计算）＝？
系统缺陷消除率（%）＝消除缺陷总数/截止到阶段结束发现的缺陷总数；（3级（含3级）以上bug和3级以下bug分别计算）＝？
4
测试结论与建议
【对上述过程、缺陷分析之后下结论，此部分为项目经理、部门经理以及高层经理关注，请清晰扼要的下定论。
】
4.1测试结论
【提示：
1．测试执行是否充分（可以增加对安全性、可靠性、可维护性和功能性描述）
2．对测试风险的控制措施和成效
3．测试目标是否完成
4．测试是否通过
5．是否可以进入下一阶段项目目标】
4.2建议
【提示：
1．对系统存在问题的说明，描述测试所揭露的软件缺陷和不足，以及可能给软件实施和运行带来的影响
2．可能存在的潜在缺陷和后续工作
3．对缺陷修改和产品设计的建议
4．对过程改进方面的建议】
5
附录
5.1附录1缺陷严重等级定义
缺陷严重等级
描述
S5
致命错误。
该类错误使得系统不能正常运行。
待测系统的运行破坏永久存储数据（配置文件、数据库等）；导致系统不能重起动或重起后功能异常；按照安装使用手册正确安装配置但无法正常安装或启动；执行主要功能直接导致系统死机，挂起，非法退出，内存报错等。
包括：
1）正常安装并运行被测系统，引起操作系统崩溃或死机。
2）系统异常终止或退出：
被测系统在非人为干预的情况下，运行一段时间后，自动终止、退出或停止响应；执行正常操作过程中（包括输入边界值），系统程序自动终止、退出或停止响应。
3）系统无响应或者无法退出：
执行正常操作（包括输入边界值），系统无响应，必须退出应用程序，或杀进程，重启系统；程序进入死循环，无法退出。
4）在正常的合法操作下（包括输入边界值），被测系统自动删除了数据库中必要的数据或配置文件，造成被测系统不能继续运行、退出或停止响应。
5）严重的计算错误
6）与数据库连接错误
7）数据通讯错误
S4
严重错误。
该类错误是指系统主要功能没有实现，或者有严重错误或性能上与指标相差非常远；主要模块或功能不能满足需求或设计上的要求；不能执行完功能的全部或部分流程，或者流程有问题，或者执行结果有严重错误；执行过程过于缓慢，占用过多的系统资源，或占用资源后不能正常释放；主界面有文字错误。
包括：
1）需求中要求的主要功能没有实现。
2）主要功能失败。
3）严重的功能失常。
4）被测系统的主要功能或者性能与需求规定相差非常大。
5）被测系统中的某项主要功能无法正常运行。
6）被测系统的某项主要功能不稳定，经常出现异常现象，严重的影响了其它功能。
7）错误的发生直接会引起数据的丢失、损坏、不一致。
8）被测系统的某个BUG严重影响客户进行系统验收。
9）轻微数据计算错误
S3
一般错误。
该类错误是指系统按照功能流程执行了，执行的结果有错误，但不严重；错误的发生虽然导致某些功能不能执行，但这项功能能通过其它的操作间接实现；错误的发生不影响整体功能的实现。
包括：
1）非正常操作或输入导致系统出错。
2）系统运行过程中偶尔（出现概率<5%）有出错提示或导致系统运行不正常。
3）被测系统实现的功能或性能与需求中的规定不完全一致。
4）没有（或不恰当的）数据检查导致脏数据进入数据库。
5）非正常操作，被测系统必然或经常出现不正常的返回值、提示。
6）被测系统中一些次要的功能无法正常运行。
7）被测系统在某些极特殊的环境下必然出现主要功能无法正常运行的问题。
8）非正常操作，被测系统偶然出现主要功能无法正常运行的问题。
9）被测系统存在的一些比较严重的易用性问题。
10）界面、程序或帮助文档中文字描述或者标识有问题，造成用户难于理解。
11）数据输入没有边界值限定或不合理
12）简单的输入限制未放在前台进行控制
13）删除操作未给出提示
14）打印内容、格式错误
S2
较小缺陷。
细小的错误，使操作者不方便，但它不影响执行工作或功能实现。
包括：
1）辅助说明描述不清楚
2）显示格式不规范
3）系统处理未优化
4）长时间操作未给用户进度提示
5）提示窗口文字未采用行业术语
6）图标定义的准确性和一致性
7）安装配置文档、设计文档等与客户无直接关系的文档中存在的错误
S1
建议：
程序已经完成了规定的功能，但从使用方便、结构更好、性能更高、容错性更好等角度考虑，程序存在需要改善的地方。
该类缺陷对功能几乎没有影响，产品及属性仍可使用。
包括：
1）一般的文字或标识错误。
2）用户在极端操作（操作步骤大于10步）下出现的功能异常。
3）图标定义的准确性和一致性。
4）安装配置文档、设计文档等与客户无直接关系的文档中存在的错误。
5）在已满足需求的条件下，一般的易用性建议。
6）为使系统完善、美观、易用从系统结构、性能等方面提出的合理化建议。
升级会员 