软件测试报告写作实战案例

测试总结和报告

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

        下面是一个项目的测试报告的纲要：
1 简介
1.1 编写目的
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 缺陷清单
一、缺陷分类报告
        缺陷分类报告是测试报告的重要组成部分，可以再细分为：缺陷类型分布报告、缺陷区域分布报告和缺陷状态分布报告等。
1．缺陷类型分布报告
        缺陷类型分布报告主要描述缺陷类型的分布情况，看缺陷属于哪些类型的错误。这些信息有助于引起开发人员的注意，并分析缺陷为什么会集中在这种类型。例如， 如果缺陷主要是界面类型的，如界面提示信息不规范、界面布局凌乱等问题，那么就要讨论是否需要制定相应的界面规范，让开发人员遵循，从而防止类似问题的出 现。
缺陷类型分布报告一般用饼图或柱状图显示。如图7.29所示，用饼图表示了几种类型的缺陷各自所占的比例。

图  缺陷分布报告

2.缺陷区域分布报告
        缺陷区域分布报告主要描述缺陷在不同功能模块出现的情况，这些信息有助于开发人员分析为什么缺陷会集中出现在某个功能模块。例如，如果缺陷主要集中在单据的审批过程中，那么就要分析是否是审批流程调用的工作流接口设计不合理。
        缺陷区域分布报告一般使用饼图或柱状图表示。如图7.30所示，用柱状图表示缺陷分布在不同的功能模块的个数。

                                                         图  缺陷区域分布报告
3.缺陷状态分布报告
        缺陷状态分布报告主要描述缺陷各种状态的比例情况，例如Open、Fixed、Closed、Reopen、Rejected、Delay的Bug分别占了百分之多少。这些信息有助于评估测试和产品的现状：
        如果Open的Bug比例过高，则考虑让开发人员暂停开发新功能，先集中精力修改Bug；
        如果Fixed状态的Bug很多，则考虑让测试人员暂停测试新功能，先集中精力做一次回归测试，把修改的Bug验证完；
        如果Closed的Bug居多，则可能意味着功能模块趋于稳定；
        如果Reopen的Bug比较多，则需要分析开发人员的开发状态，是什么原因造成缺陷修改不彻底；
        如果Rejected的Bug比例过高，则要看开发人员与测试人员是否对需求存在理解上的分歧；
        如果Delay的Bug比例过高，则要考虑这个版本是否满足用户的要求，是否缺少了太多应该在这个版本出现的功能特性。
        缺陷状态分布报告一般使用饼图或柱状图表示。如图7.31所示，用饼图表示各种状态的缺陷个数以及所占的百分比。

图  缺陷状态分布报告

注意：其他的缺陷分类报告也可以写到测试报告中，例如，严重级别分类报告、优先级别分类报告、负责人分类报告、发现人分类报告、版本分类报告等。但 是要注意，应该用这些分类报告来说明问题，而不要用来指责别人，例如使用负责人分类报告来嘲笑某个开发人员是“Bug大王”等。

二、缺陷趋势报告
        缺陷趋势报告主要描述一段时间内的缺陷情况。如果项目管理比较规范，缺陷管理和测试流程比较正常的话，缺陷趋势报告还可以用来估算软件可发布的日期。
例如，如图7.32所示的缺陷趋势图，表示在2001年9月3号至2001年9月24号之间的Bug状态变化。

                                                   图  缺陷趋势图
        从图7.32可以看出，Open状态的Bug在不断地增加，Fixed状态的Bug在2001年9月16号后开始骤然下降，这表示，这段时间开发人员有可能在开发几种新的功能，忽略了Bug的修改工作。
        发现并录入Bug，与修改并关闭Bug是一对互相对冲的两个变量，软件产品就是在这样此消彼涨的过程中不断完善和改进质量的。有经验的项目经理和测试人员 会非常关注这样的发展曲线，从而判断项目产品的质量状态和发展趋势。笔者曾经在某个项目中与一位项目经理在项目的待发布阶段每天都在观察缺陷趋势图，这位 项目经理甚至把它戏称为软件产品的“股市”技术图。
        但是确实能从这些图中看出一个产品的质量趋势，如果项目管理得比较规范的话，甚至可以从这些图的某些关键点推算出可发布版本的日期。在微软的项目管理中，把这种关键点称为零Bug反弹点。例如，图7.33中就有几个零Bug反弹点（用圆圈圈住的地方）。

图 零Bug反弹

        项目在第一次达到零缺陷，即所有Bug（或者大部分Bug）都基本处理掉了，没有发现新的Bug时，还不能马上发布版本，因为Bug会反弹。由于缺陷的 “隐蔽特性”和“免疫特性”，第一个零缺陷点是一个质量安全的假像，测试人员很快就会在新版本中发现更多的Bug，有些项目甚至要到第三个或第四个零 Bug点才能安全地发布，这取决于项目的实际控制方式。