测试报告.docx

测试报告.docx

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

测试报告

Documentnumber文档编号

Confidentialitylevel密级

TestReport-01

[绝密/秘密/内部公开]

Documentversion文档版本

Total10pages共10页

V1.0

测试报告

Preparedby

拟制

Date

日期

yyyy-mm-dd

Reviewedby

评审人

Date

日期

yyyy-mm-dd

Approvedby

批准

Date

日期

yyyy-mm-dd

RevisionRecord修订记录

Date

日期

RevisionVersion

修订版本

SecNo.

修改章节

ChangeDescription

修改描述

Author

作者

yyyy-mm-dd

Vx.xx

TableofContents目录

TableList表目录

1概述

描述本报告是哪一个测试活动的总结，指明被测对象及其版本/修订级别。

概述本次测试活动，同时，指明该测试活动所依据的测试计划，测试方案、测试用例等本测试报告文档的参考文档。

2测试时间、地点及人员

描述本次测试的时间，地点和测试人员。

表1测试时间、地点及人员

版本名称

测试时间

测试人员

测试地点

起始时间

结束时间

3环境描述

描述本次测试的测试环境。

包括硬件配置、软件配置、版本配套、测试组网等，尤其要注意组网图应为测试实际组网，并对此种组网可能导致的测试风险进行描述。

硬件配置：

软件配置：

版本配套关系表

测试组网图（物理组网，即测试时实际的组网）

测试组网风险说明

3.1硬件（软件）配置：

Iphone5（ios8）

4测试对象质量评估

4.1总体评价结论

从需求符合度、功能正确性、性能指标、运行稳定性、互联互通、文档、可用性、可维护性、兼容性、风险评估等多个维度对版本质量进行总体评价。

根据上述各个维度评估的结果，给出此版本是否可用的结论。

结论必须是能够代表测试部意见的明确结论，比如：

该版本满足上网条件，可以上网使用；

该版本存在质量风险，只可在XX局受限使用；

该版本存在严重质量问题，不满足上网条件等。

【建议】由于本部分对于所有的读者来说都希望在看报告时越早看到越好，因此建议放在测试对象质量评估的最前面部分，并以显著字体显示。

下面各个部分的内容是对前面结论的支撑。

4.2缺陷统计

给出各特性或模块缺陷的分布或分类统计以及缺陷走势分析，此部分内容可采用TD缺陷管理支撑工具的“版本缺陷统计”和“缺陷走势分析”进行分析和获取，该工具可以从缺陷库中将缺陷导入进行自动统计，结果可以按版本、按缺陷分布、按问题状态统计，并能够以图表的方式直观显示，非常方便。

如果手工统计的话，至少需要给出下面两方面的结果：

1、以版本为单位的缺陷统计，示例格式如下：

表2从版本缺陷统计

版本号

致命

严重

一般

提示

总计

2、以特性为单位的缺陷统计，示例格式如下：

表3从特性统计缺陷

模块/特性

致命

严重

一般

提示

总计

4.3缺陷分析

缺陷分析的目的是为了得出：

缺陷原因、缺陷趋势、遗留缺陷以及规避措施等。

那么对缺陷的分析可由测试组定性给出，定性的结论应包括：

测试趋势

质量评价

遗留问题风险分析

遗留问题规避

4.3.1测试趋势分析结果

在此提供缺陷分析结果，给出版本缺陷走势，比如：

通过N轮的测试，测试问题的发现趋势是否是收敛的，发布前遗留问题是否在版本正常运行可以允许的范围内

4.4覆盖率统计

覆盖率统计对于版本决策者具有重要的意义，一定要提供详细的覆盖率统计。

原则上，对于测试策略确定的测试范围及选定的测试用例执行覆盖率应该达到100％，对于不能达到100％覆盖率的版本应该给出测试、项目经理等共同认可的原因，相关原因的分析应该在此处明确给出作为版本测试回溯的依据，原则上环境不充分，技能不具备不能成为版本不测试，测试不充分的理由。

测试没有覆盖到的部分，还应进行详细的风险分析。

4.5性能测试评估

性能测试结论应该按如下方式给出：

对于指标类测试目的，明确给出某种测试条件下（软硬件配置、数据量、话务模型等）下的主要性能指标。

对于稳定类测试目的，明确给出系统总体是否稳定的结论，或者系统哪些特性稳定，那些特性不稳定的结论。

对于对比类测试目的，明确给出对各种对比系统的测试结论，说明各种对比系统中那种性能表现好、那种性能表现差。

对于验证类测试目的，明确给出验证结果，主要是有没有达到要求、可不可行。

对于优化类测试目的，按优化的优先级给出重要的各种优化方向，并说明可能的优化效果。

4.6兼容性评估

对被测对象的版本兼容性、硬件平台兼容性、操作系统兼容性给出明确的结论。

没有测过的要说明没有测过，提醒上下游注意版本在正确的环境下使用。

5测试过程评估

5.1测试执行评估

提供对本次测试活动的测试执行过程的评估结论。

描述对测试执行活动的改进建议，以供后续测试执行活动中借鉴参考；

测试执行活动评估结论可依据以下提供的“测试执行统计数据”及“测试用例执行结果统计数据”进行分析而给出。

5.1.1测试执行统计数据

本节的目的是提供足够的测试数据以满足第5节“测试评估”的需要。

本节内容除下面这个汇总表必填外，其他可以根据实际测试情况进行相应裁剪。

表4测试执行统计

版本名称

工作量投入（人天）

测试用例规模

用例执行

发现缺陷数

总用例数

新增用例数

数据项说明：

工作量投入－－与本活动相关的所有工作量投入，包括测试计划、方案、用例、脚本、执行等所有与本测试相关的活动所花的投入，单位“人天”；不包括以前已经统计的投入，不包括开局、用户支援等非测试相关投入；

总测试用例数－－到本测试活动结束时，本测试活动中所有可用测试用例数，单元测试用例数、集成测试用例数、系统测试、SDV测试用例数分开；

新增测试用例数－－在本测试活动中新增加的测试用例数。

如果是新产品的第一次总结，新增测试用例数包括从老版本继承来的可用测试用例数；

手工执行用例数――在本测试活动中人工执行测试用例数，多次重复执行同一用例计算为1个

发现缺陷数－－本测试活动总共发现的缺陷数；

5.1.2测试用例执行结果统计数据

对本次测试用例执行结果进行统计，其中的字段可根据实际情况进行设计和裁剪：

详细的测试项通过情况清单放在附件部分。

表5系统测试结果统计表

统计

总测试

用例数

实际测试的用例数

Pass

Fail

Block

Cancel

无需测试用例数

第一轮测试

第二轮测试

总数

百分比

6附件

遗留问题报告、交付的测试工作产品和测试项通过情况清单为必需的附件，其余可根据实际测试内容进行裁剪，不同的测试报告根据需要可以给出不同类型的附件。

附件的目的是帮助本报告的使用者理解报告，记录修改情况和有用的数据等。

6.1附件1：

遗留问题报告

如存在独立的遗留问题报告文档，可在此直接粘贴文档；如无，可按以下内容填写；

6.1.1遗留问题统计

遗留问题是指测试过程中发生的并且在测试报告时仍没有得到解决的测试问题。

测试报告时已经得到解决，并已经过回归验证的测试问题不记入其中。

在详细的遗留问题报告前可以先建立一个遗留问题统计表格，以便对遗留问题的相关分布信息有整体的了解，如果遗留问题数比较少，可以将此表格省去，因此此表格根据实际情况可选。

建立遗留问题统计表格，可对遗留问题数和级别进行统计，包括问题总数，致命，严重，一般和提示问题的数目及百分比等，遗留问题统计一般可用以下表格描述，其中的字段可根据实际情况进行设计和裁剪：

表6遗留问题统计表

问题总数

致命问题

严重问题

一般问题

提示问题

其他统计项

数目

百分比

6.1.2遗留问题列表

以下部分详细记录每一个遗留问题，也可视时间情况只详细记录问题级别比较高的遗留问题，低级别的遗留问题采用简单列表进行罗列。

所有进行详细记录的遗留问题都统一采用表格的形式来描述，

6.1.3其他风险和规避措施

描述被测对象在运行时，除遗留问题列表中描述之外的其他需注意的操作规避措施，包括但不限于测试过程中发现的需要下游部门注意的版本问题。

6.2附件2：

交付的测试工作产品

指明本测试完成后交付的测试文档、测试代码及测试工具等测试工作产品，以及指明配置管理位置和物理媒介等，一般包括但不限于如下工作产品：

1.测试计划

2.测试用例

3.测试报告

4.测试代码及设计文档