测试质量报告

测试质量报告测试质量报告 拟制: 审核: 日期： 日期： yyyy-mm-dd yyyy-mm-dd 修订历史记录修订历史记录 版本号修订日期AMD修订人修订内容说明 （N-新建，A-添加，M-修改，D-删除） 目录目录 1.项目简介 . 4 1.1 1.2 1.3 1.4 编写文档目的 . 4 项目简述 . 4 定义 . 4 参考文档 . 4 2.测试概要 . 4 2.1 2.2 测试用例设计方法和工具 . 4 测试环境与配置 . 4 3.测试情况 . 4 3.1测试版本情况 . 4 3.2差异 . 4 3.3测试充分性评价 . 4 3.4测试组织 . 5 3.4.1测试时间 . 5 4.测试结果及分析 . 5 4.1测试情况统计分析 . 5 4.2覆盖分析 . 5 4.2.1需求覆盖 . 5 4.2.2测试覆盖 . 5 4.3缺陷的统计与分析 . 6 4.3.1缺陷汇总 . 6 4.4缺陷分析 . 6 5.测试结论 . 6 5.1残留缺陷与未解决问题 . 6 6.批准 . 6 XXXXXXXXXXXX测试报告测试报告 1.1. 项目简介项目简介 1.11.1 编写文档目的编写文档目的 本测试报告反映在的一个版本内的质量情况。包含该版本经开发部发布后测试组的接受结果 与原因、存在的问题描述与分析。 1.21.2 项目简述项目简述 简单介绍项目概况（参照功能说明书）。 1.31.3 定义定义 列出设计本系统/项目的专用术语和缩写语约定。对于技术相关的名词和与多义词一定要注明清楚，以 便阅读时不会产生歧义。 1.41.4 参考文档参考文档 1．需求、设计、测试用例、手册以及其他项目文档都是范围内可参考的文档。 2．测试使用的国家标准、行业指标、公司规范和质量手册等等。 2.2. 测试概要测试概要 测试的概要介绍，包括测试的一些声明、测试范围、测试目的等等，主要是测试情况简介。（其他测试经 理和质量人员关注部分）。归纳对测试项的评价，指明被测试项及其版本修订级别指出测试活动的发生环 境，对于每个测试项如果存在测试计，划测试设计说明，测试规程说明，测试项传递报告，测试日志和测 试事件报告等文件则可以引用它们。 2.12.1 测试用例设计方法和工具测试用例设计方法和工具 简要介绍测试用例的设计方法和工具。例如：等价类划分、边界值、因果图，以及用这类方法 提示：主要是黑盒测试，测试方法可以写上测试的重点和采用的测试模式，这样可以一目了然的知道是 否遗漏了重要的测试点和关键块。工具为可选项，当使用到测试工具和相关工具时，要说明。注意要注明 是自产还是厂商，版本号多少，在测试报告发布后要避免大多工具的版权问题。重点测试部分一定要保证 有两种以上不同的用例设计方法。 2.22.2 测试环境与配置测试环境与配置 简要介绍测试环境及其配置。 提示：清单如下，如果系统/项目比较大，则用表格方式列出 3.3. 测试情况测试情况 3.13.1 测试版本情况测试版本情况 测试版本版本号，是否接受该版本以及原因表述 3.23.2 差异差异 报告测试项与它们的设计说明之间的差别并指出与测试计划测试设计说明或测试规程说明中 描述或涉及的测试间的差别说明产生差别的原因。 3.33.3 测试充分性评价测试充分性评价 根据测试计划规定的充分性准则如果存在的话对测试过程作充分性评价指出未被充分测试 的特性或特性组合并说明理由。 3.43.4 测试组织测试组织 总结主要的测试活动和事件总结资源消耗数据如人员的总体水平总机时和每项主要测试 活动所花费的时间 3.4.1 测试时间 列出测试的跨度和工作量，最好区分测试文档和活动的时间。数据可供过程度量使用。 例如 对 XXX 子系统/子功能 子系统/子模块实际开始时间实际结束时间总工时/总工作日 测试人员用工统计 角色开始时间结束时间总计 4.4. 测试结果及分析测试结果及分析 总结测试的结果指出所有已解决的事件并总结其解决方法指出尚未解决的事件 4.14.1 测试情况统计分析测试情况统计分析 列举发现问题数量，属于问题数量（包含确认通过问题数量、确认未通过问题数量、以后版本修改数量、 需求问题数量、不修改问题数量），不属于问题数量。 a、 合格率（以案例数）= 测试通过案例数/使用测试案例总数； b、 合格率（以联机交易数）= 测试通过联机交易数/需要测试联机交易总数； c、 合格率（以批量报表数）= 测试通过报表数/需要测试报表总数； d、 测试完成率 = 使用案例数/设计案例总数； 若测试完成率≠100%时，须文字加以说明 e、 问题更正率=问题修改确认通过数/出现问题案例总数； 描述系统的实现能力、缺陷和限制、建议和评价； 4.24.2 覆盖分析覆盖分析 4.2.1 需求覆盖 需求覆盖率是指经过测试的需求/功能和需求规格说明书中所有需求/功能的比值，通常情况下要达到 100％的目标。 指出 需求/功能（或编号） 测试类型 是否通过 备注 根据测试结果 ，按编号给出每一测试需求的通过与否结论。P 表示部分通过，N/A 表示不可测试或者用 例不适用。实际上，需求跟踪矩阵列出了一一对应的用例情况以避免遗漏，此表作用为传达需求的测试信 息以供检查和审核。 需求覆盖率计算 Y 项/需求总数 ×100％ 4.2.2 测试覆盖 指出 需求/功能（或编号） 用例个数 执行总数 未执行 未/漏测分析和原因 实际上，测试用例已经记载了预期结果数据，测试缺陷上说明了实测结果数据和与预期结果数据的偏 差；因此没有必要对每个编号在此包含更详细的说明的缺陷记录与偏差，列表的目的仅在于更好的查看测 试结果。 测试覆盖率计算 执行数/用例总数 ×100％ 4.34.3 缺陷的统计与分析缺陷的统计与分析 缺陷统计主要涉及到被测系统的质量， 4.3.1 缺陷汇总 将被测系统，进行的单元，集成，系统测试， 回归测试，进行总计。还可以按缺陷类型， (用户界面 一 致性 功能 算法 接口 文档 用户界面 )进行统计。 4.44.4 缺陷分析缺陷分析 本部分对上述缺陷和其他收集数据进行综合分析缺陷综合分析 缺陷发现效率 ＝ 缺陷总数/执行测试用时 可到具体人员得出平均指标 用例质量 ＝ 缺陷总数/测试用例总数 ×100％ 缺陷密度 ＝ 缺陷总数/功能点总数 缺陷密度可以得出系统各功能或各需求的缺陷分布情况，开发人员可以在此分析基础上得出那部分功能/需 求缺陷最多，测试缺陷越多的部分，其隐藏的缺陷也越多。 5.5. 测试结论测试结论 5.15.1 残留缺陷与未解决问题残留缺陷与未解决问题 1． 测试执行是否充分（对安全性、可靠性、可维护性和功能性描述） 2． 对测试风险的控制措施和成效 3． 测试目标是否完成 4． 测试是否通过 5、记录下缺陷和未解决的问题 残留缺陷 编号： BUG 号 缺陷概要： 该缺陷描述的事实 原因分析：如何引起缺陷，缺陷的后果，描述造成软件局限性和其他限制性的原因 预防和改进措施：弥补手段和长期策略 未解决问题 功能/测试类型： 测试结果：与预期结果的偏差 缺陷：具体描述 评价：对这些问题的看法，也就是这些问题如果发出去了会造成什么样的影响 6、建议与其他 针对存在问题或其他的建议 6.6. 批