由于缺陷列表太细、太大，测试用例过于专业，很多人对其不感兴趣，因此测试报告能很好地展示自己的工作状况，测试报告是提供给很多人看的一份文档。

        下面是一个项目的测试报告的纲要：
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所示，用饼图表示了几种类型的缺陷各自所占的比例。

三、典型缺陷与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循环是一个自我完善和改进的全闭环模型，如图7.34所示，对质量的不断提高和改进非常有效。

  PDCA循环模型