缺陷分类报告
缺陷分类报告是测试报告的重要组成部分，可以再细分出缺陷类型分部报告、缺陷区域报告、缺陷状态分部报告等。
缺陷类型分部报告
缺陷类型分部报告主要描述缺陷的类型分部情况，看缺陷主要是哪类的错误，这些信息有助于引起开发人员的注意，并分析为什么集中在这类。
例如，主要缺陷是界面类，界面提示信息不规范、界面布局凌乱不统一等问题，那么就要讨论是否需要定制界面规范，让开发人员遵循，从而防止类似问题的出现。
缺陷类型分分布报告一般用柱状图或者饼图显示。
缺陷区域分布报告
缺陷区域分布报告主要描述缺陷再不同功能模块的出现情况，这些信息有助于开发人员分析为什么缺陷集中再某个地方，某个模块，例如，如果缺陷集中在单据的审批前后，那就要分析是否审批流程调用的工作流接口存在不合理的设计。
缺陷状态分布报告
缺陷状态分布报告主要是描述缺陷中各种状态的比例情况，例如 open、fixed、closed、reopen、rejected、delay的bug占比各为多少。这些信息有助于评估测试和产品的现状，
如果open的bug比例高些，则可能要考虑让开发人员停止开发新的功能，先集中经理处理下bug
如果fixed状态的bug很多，组需要考虑让测试人员停止测试新功能，先集中精力做一次回归测试，把bug验证完。
如果colsed的bug居多，则可能意味着模块趋于稳定
如果reopend的bug比较多，则需要分析开发人员的开发状态，是什么原因造成缺陷修改不能彻底，
如果rejected的bug比例过高，就要看开发人员与测试人员是否对需求的理解存在分歧。
如果delay的bug比例过高，则要看这个版本是否满足用户的需求，是否缺了套多应该在这个版本本应有的功能特性。
缺陷趋势报告
缺陷趋势报告主要描述一段时间内的缺陷情况，如项目管理比较规范，缺陷管理和测试流程比较正常，从缺陷趋势报告还可以估算出软件可发布的日期。发现并录入bug 与修改并关闭bug是一对互相对立的两个变量，软件产品就是在这样的此消彼长中不断完善和改进质量的。有经验的项目经理和测试人员会非常关注这个发展趋势，从而判断项目产品的质量状态和变化趋势。
典型缺陷与BUG模式
软件开发有设计模式，测试其实也有模式存在，需要测试人员进行总结和归纳。从经常出现的Bug的学习，总结出BUG的模式，用于指导开发，如果开发人员能关注这些bug的模式，还能起到预防错误的效果。
要成为典型缺陷，需要满足以下条件：
<1重复出现 经常出现
<2能代表某种类型的错误
<3能通过相对固定的测试方法或者手段来发现这些错误。
总结这些典型缺陷出现的现象，出现的原因，以及测试的方法。就成为一个bug的模式。
提炼bug模式的一般步骤如下
<1分析缺陷报告， 找出经常出现的bug类型
<2分析找到bug的方法，总结如何才能发现每次都发现这类的bug
需求规格说明书的评价和检查是需求阶段乃至整个软件开发过程最重要的质量环节之一。需要注意把缺陷堵在源头，重在预防错误的出现。
对于新手而言，在设计测试用例时，应该从简单有效的方法开始。需要注意的是，不要把测试用例的设计用例的编写。测试用例的设计旨在设计，重在测试思想。新手一般不重视bug描述的质量，只是一味强调找到bug，没有注意好好地重现一个bug，描述一个bug，与开发人员沟通一个bug。要注意发现最多地bug的测试人员未必是一个好的测试人员，而能让开发人员修改最多的bug的测试人员才是最好的测试人员。
新手一般缺乏编写测试报告的经验和技巧，大部分新手在写测试报告之前都忙着找模板其实模板只是一个格式上的参考，以及对需要报告哪些内容做出规定，真正要写好一个测试报告，需要从报告的内容出发，把测试的客观情况反映出来，把自己的测试心得体会贡献出来，要能体现出报告的价值，而不是盲目的按照模板来填充内容。