测试报告范例

1、测试总结和报告测试人员的 必通常并不像开发人员那样能直接体现出来，让大家一目了然。开发人员做的是建设性的工作，如开发了哪些功能，写了几行代码，设计了几个类，都能直观地看到， 而且，通过软件能很鲜活地演示开发人员的工作成果。但是测试人员的工作相对隐蔽一点，测试人员做的是破坏性的工作，并且没有很多可以直观体现测试人员贡献的东西。笔者曾经听到公司人事部的一位同事说：“你们做测试的真好，整大坐在那里”。当然，这是外行人看内行时说的话，但是给笔者的一个启示是：测试 人员需要更多地表现自己，展现自己的工作成果。说明：由于缺陷列表太细、太大，测试用例过于专业，很多人对其不感兴趣，因此测试 报告能很好地展示自

2、己的工作状况，测试报告是提供给很多人看的一份文档。下面是一个项目的测试报告的纲要： i简介 i.i编写目的 1.2项目背景 1.3术语和缩略词 1.4参考资料 2目标及范围 2.1测试目的及标准 2.2测试范围 3测试过程 3.1测试内容 3.2测试时间 3.3测试环境3.4测试方法及测试用例设计4测试情况分析4.1测试概要4.2测试用例执行情况4.3缺陷情况4.4测试覆盖率分析4.5产品质量情况分析5测试总结5.1测试资源消耗情况5.2测试经验总结6附件附件1测试用例清单附件2缺陷清单一、缺陷分类报告缺陷分类报告是测试报告的重要组成部分，可以再细分为：缺陷类型分布报告、缺陷区域分布报告和缺陷

3、状态分布报告等。1. 缺陷类型分布报告缺陷类型分布报告主要描述缺陷类型的分布情况，看缺陷属于哪些类型的错误。 这些信息有助于引起开发人员的注意，并分析缺陷为什么会集中在这种类型。例如，如果缺陷主要是界面类型的，如界面提示信息不规范、界面布局凌乱等问题，那么就要讨论是否需要 制定相应的界面规范，让开发人员遵循，从而防止类似问题的出现。缺陷类型分布报告一般用饼图或柱状图显示。如图7.29所示，用饼图表示了几种类型的缺陷各自所占的比例。界面规范性 问题 J 1：；不正常口联机帮助问题数据显示问 题报表问题图缺陷分布报告2. 缺陷区域分布报告缺陷区域分布报告主要描述缺陷在不同功能模块出现的情况，这些信

4、息有助于开发人员分析为什么缺陷会集中出现在某个功能模块。例如，如果缺陷主要集中在单据的审批过程中，那么就要分析是否是审批流程调用的工作流接口设计不合理。缺陷区域分布报告一般使用饼图或柱状图表示。如图7.30所示，用柱状图表示缺陷分布在不同的功能模块的个数。Defects Summary Graph ClosedI NewI Open0 Rejected Reopen.s-4mj_.O i e:1 :z .巨挡 S BJnoH.2?n 潟臣 £.2芥寿E.H 2UEQ 20£6iLU=O惹一-u_Ct 吉OOJ垂suMlLrwm 一LL.Kofe胡>9岳仍 u=wa-8

5、a>ct ，uo 一一 EAlosaa 墓£ ceiclcdeop-图缺陷区域分布报告3. 缺陷状态分布报告缺陷状态分布报告主要描述缺陷各种状态的比例情况，例如Open Fixed、Closed >Reopen、Rejected、Delay的Bug分别占了百分之多少。这些信息有助于评估测试和产品的 现状：如果Open的Bug比例过高，则考虑让开发人员暂停开发新功能，先集中精力修改Bug;如果Fixed状态的Bug很多，则考虑让测试人员暂停测试新功能，先集中精力做一次回归测试，把修改的 Bug验证完；如果Closed的Bug居多，则可能意味着功能模块趋于稳定；如果Reope

6、n的Bug比较多，则需要分析开发人员的开发状态，是什么原因造成缺 陷修改不彻底；如果Rejected的Bug比例过高，则要看开发人员与测试人员是否对需求存在理解 上的分歧；如果Delay的Bug比例过高，则要考虑这个版本是否满足用户的要求，是否缺少了太多应该在这个版本出现的功能特性。缺陷状态分布报告一般使用饼图或柱状图表示。如图7.31所示，用饼图表示各种状态的缺陷个数以及所占的百分比。Defects - Sumrnary Graph图缺陷状态分布报告注意：其他的缺陷分类报告也可以写到测试报告中，例如，严重级别分类报告、优先级别分类报告、负责人分类报告、发现人分类报告、版本分类报告等。但是要注

7、意，应该用这些分类报告来说明问题，而不要用来指责别人， 例如使用负责人分类报告来嘲笑某个开发人员是 “Bug大王”等。二、缺陷趋势报告缺陷趋势报告主要描述一段时间内的缺陷情况。如果项目管理比较规范，缺陷管理和测试流程比较正常的话，缺陷趋势报告还可以用来估算软件可发布的日期。例如，如图7.32所示的缺陷趋势图，表示在 2001年9月3号至2001年9月24号之间的 Bug状态变化。如c<Dt5n名有 qEnN30 282624222018 IB- 141210864|。巳粗仁比-PnogrEss Graph2D01-9-9 2001-9-12 2001-9-15 2001-9-18 200

8、1-9-21 2001-M4Time interval0-2001-M 200136 ClosedFixedNew"OpenRejected一 Re叩酣图缺陷趋势图从图7.32可以看出，Open状态的Bug在不断地增加，Fixed状态的Bug在2001 年9月16号后开始骤然下降，这表示，这段时间开发人员有可能在开发几种新的功能，忽 略了 Bug的修改工作。发现并录入Bug，与修改并关闭Bug是一对互相对冲的两个变量，软件产品就是在 这样此消彼涨的过程中不断完善和改进质量的。有经验的项目经理和测试人员会非常关注这 样的发展曲线，从而判断项目产品的质量状态和发展趋势。 笔者曾经在某个项

9、目中与一位项 目经理在项目的待发布阶段每天都在观察缺陷趋势图， 这位项目经理甚至把它戏称为软件产 品的“股市”技术图。但是确实能从这些图中看出一个产品的质量趋势，如果项目管理得比较规范的话,在微软的项目管理中，把这种关甚至可以从这些图的某些关键点推算出可发布版本的日期。键点称为零Bug反弹点。例如，图7.33中就有几个零 Bug反弹点（用圆圈圈住的地方）。图零Bug反弹项目在第一次达到零缺陷，即所有Bug （或者大部分Bug）都基本处理掉了，没有发现新的Bug时，还不能马上发布版本，因为 Bug会反弹。由于缺陷的“隐蔽特性”和“免 疫特性”，第一个零缺陷点是一个质量安全的假像，测试人员很快就会

10、在新版本中发现更多的Bug，有些项目甚至要到第三个或第四个零Bug点才能安全地发布，这取决于项目的实际控制方式。已投稿到：排行榜圈子阅读（2473） |评论（2） |收藏（0） |打印|举报2测试概要用表格的形式列出每一项测试的标识符及其测试内容，并指明实际进行的测试工作内容与测试计划中预先设计的内容之间的差别，说明作出这种改变的原因。3测试结果及发现3.1测试1 （标识符）把本项测试中实际得到的动态输出（包括内部生成数据输出） 结果同对于动态输出的要求进行比较，陈述其中的各项发现。3.2测试2 （标识符）用类似本报告3.1条的方式给出第 2项及其后各项测试内容的测试结果和发现。4对软件功能的

11、结论4.1功能1 （标识符）4.1.1能力简述该项功能，说明为满足此项功能而设计的软件能力以及经过一项或多项测试已证实 的能力。4.1.2限制说明测试数据值的范围（包括动态数据和静态数据），列出就这项功能而言，测试期间在该软件中查出的缺陷、局限性。4.2功能2 （标识符）用类似本报告4.1的方式给出第2项及其后各项功能的测试结论。5分析摘要5.1能力陈述经测试证实了的本软件的能力。如果所进行的测试是为了验证一项或几项特定性能 要求的实现，应提供这方面的测试结果与要求之间的比较，并确定测试环境与实际运行环境之间可能存在的差异对能力的测试所带来的影响。5.2缺陷和限制陈述经测试证实的软件缺陷和限制，说明每项缺陷和限制对软