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

上一篇 / 下一篇  2008-06-27 10:35:38 / 个人分类：测试设计

测试总结和报告

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

下面是一个项目的测试报告的纲要：
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．缺陷类型分布报告

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

图一  缺陷分布报告

2.缺陷区域分布报告

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

图二  缺陷区域分布报告

3.缺陷状态分布报告

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

图三  缺陷状态分布报告

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

二、缺陷趋势报告

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

　　　　　　　　　　　　　图四  缺陷趋势图

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

图五 零Bug反弹

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

三、典型缺陷与Bug模式

   软件开发有设计模式，测试其实也有模式存在，需要测试人员进行总结和归纳。测试人员应从经常出现的Bug中学习，总结出Bug模式，用于指导测试。如果开发人员能关注这些Bug模式，还能起到预防错误的效果。
   要成为典型缺陷，必须满足以下条件：
   ＊　重复出现、经常出现；
   ＊　能代表某种类型的错误；
   ＊　能通过相对固定的测试方法或测试手段来发现这些错误。
   总结这些典型缺陷出现的现象，出现的原因，以及测试方法，就能成为一个Bug模式。

    说明：根据不同的开发平台、开发工具、开发语言、产品类型、采用的架构等，可以总结出不同的Bug模式，不同的Bug模式可能在不同的平台、语言、产品类型中才会出现。测试人员应该总结适合自己项目特点的Bug模式。

　　提炼Bug模式的一般步骤如下：
    步骤1：分析缺陷报告，找出经常出现的Bug类型。
    步骤2：分析Bug的根源，找出Bug产生的深层次原因。
    步骤3：分析找到Bug的方法，总结如何才能每次都发现该类型的Bug。
   下面举一个例子来说明这个过程。
   首先，测试人员在分析缺陷报告时发现，有一类Bug经常出现，并且错误现象一致：执行某功能时提示Time Out。
    测试人员与程序员一起分析原因，发现这些错误都是在操作数据库时发生，发送的SQL语句被数据库长时间执行未返回，因此提示Time Out。通过进一步地分析表明，.NET的SqlCommand的CommandTimeOut属性是用于获取或设置在终止执行命令的尝试并生成错误之前的等待时间。等待命令执行的时间（以秒为单位）默认为30s，而数据库操作在较大数据量的情况下一般都超过这个时间，因此会提示超时的错误信息。
    这样就可以把这种类型的Bug归纳为“数据库操作超时Bug模式”。
    那么，如何才能找出这样的Bug呢？一般情况下，这类Bug基本上不会出现，只有数据量足够大时才会出现，因此需要设置大批数据，结合性能测试或压力测试来发现此类问题。也可以通过白盒的方式，查找程序在使用SqlCommand时是否合理地设置了Command TimeOut属性，这样将更有针对性地揭露上述的错误。
    至此就完成了一个Bug模式的归纳、提炼和总结，如果程序员积极地参与到该总结和分析过程中来，则可形成一个良性的反馈，当下次程序员编写相同的程序时就会避免类似的错误发生。

四、测试中的PDCA循环

    PDCA循环是一种放之四海皆准的原则。在软件测试的过程中，也充斥着各种PDCA循环。PDCA循环是一个自我完善和改进的全闭环模型，如图六所示，对质量的不断提高和改进非常有效。

 图六 PDCA循环模型

   在软件测试中应用PDCA循环的目的是为了提高测试质量和产品质量。大到整个测试过程，小到执行一个测试或者录入一个Bug，都可以体现PDCA的精神。
   首先制定好测试计划，执行测试计划，通过测试执行结果来检查测试计划制定的合理性，然后分析计划偏离的原因，把总结出来的经验用于指导下一次测试的计划，这样就形成了一个PDCA循环过程。
   编写一份测试报告或者一个Bug也可以应用PDCA循环。例如，先策划好报告的主题和内容，打好腹稿，再写下来，写完要检查，看是否准确，是否有错别字，然后提交审核，对提出的意见进行分析，将总结的经验用于指导下一次报告的编写，这样的过程同样也是一个PDCA。
   编写测试用例也是一个PDCA。首先计划测试用例的编写方式，搭建测试用例的大纲和框架，然后设计和编写测试用例，并自行检查或与同行一起交叉检查，最后通过评审来发现更多的问题，如有哪些没有考虑周全的，或设计不完善的地方；或者通过执行测试用例，发现Bug，再根据执行的情况和Bug的情况来分析测试用例的有效性，把这些总结出来的经验用于指导下一次的测试用例设计。
    测试的执行过程则是一个可间接用于改进产品质量和程序员能力的PDCA循环。例如，首先开发人员写出代码，策划拥有一定质量水平的产品，测试人员对产品执行测试，发现Bug，通过分析Bug出现的原因，对开发人员的开发方式做出新的指导，从而避免下一次错误的出现。通过这种方式改进质量，同时也提高了程序员编写高质量代码的能力，把错误遏制在产生的源头。

五、客观全面的测试报告

    测试需要以一个完美的方式结束，编写一份出色的测试总结报告可为一个完美的测试过程划上一个圆满的句号。
    一份测试报告应该包括测试资源的使用情况：投入了多少测试人员，所用时间多长，执行了多少测试用例，以及覆盖了多少功能模块等。
    另外，对测试对象的缺陷分析也是必须的，包括共发现了多少缺陷，缺陷的类型主要是哪些，缺陷集中在哪些功能模块，缺陷主要发生在哪几个开发人员的身上。这些信息都是大家关心的，需要及时报告，项目经理或QA需要根据这些信息做出决策。

        注意：报告应该尽可能客观、尽可能全面地反应测试情况和缺陷情况。

六、实用测试经验的总结
    测试总结报告应该包括测试过程的成功与失败经验，从测试过程的管理经验，具体到某个Bug的分析总结，或者是与开发人员合作交流的经验，都可以总结出来。
    测试总结报告应该分析测试的整个过程，如是否合理安排了测试资源，测试进度是否按计划进行，如果没有其原因是什么，如何避免下次出现类似的问题？风险是如何控制的？出现了什么意外情况？下次能否预计到这些问题，等等。
   测试总结报告还应包括某些专门类型的测试经验总结。例如，性能测试采用了什么好的方法？碰到的问题是如何解决的？自动化测试脚本如何编写？应该选取哪些功能模块进行自动化测试？等等。
   测试总结报告应该包括对测试用例的分析。例如，测试用例的设计经验总结，哪些用例设计得好，能非常有效地发现Bug，总结的这些东西无论是对本项目组的测试人员，还是对其他项目组的测试人员都会大有帮助。
   如果能分析总结出Bug模式，那么总结报告还应该包括Bug模式的总结。