测试质量报告.docVIP

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