3、按功能分析缺陷

　　我们一般会看不同功能上发现多少缺陷。有些功能逻辑比较复杂，涉及的方面较多。这种情况所发现缺陷比例会稍大。有些功能较简单，和其他功能没有太大交集，所发现缺陷会相应较少。

　　如图9-5所示，功能2所发现缺陷占总数的41%，而功能4仅为7%。这说明功能2的复杂度相对大些，可能有必要再重新看看测试范围并增加一些测试案例。

　　4、按修复时间分析缺陷

　　一般来讲，一级严重缺陷需要开发人员之内解决，二级严重缺陷需要两天之内解决，三级严重缺陷要在一周内解决，四级严重缺陷应在两周内解决。

　　所以大部分缺陷从开始报告到终核对并确认修复的周期应在一周内。不同测试类型缺陷修复时间是会稍微有一些差别的。例如性能测试的缺陷和迁移测试的缺陷由于测试环境较为复杂，并且较难找出造成缺陷原因，所以这两个测试类型的缺陷完成周期会相应长一些。

　　图9-6和图9-7分别是安装测试缺陷修复时间和性能测试缺陷修复时间数据图，从图中可看出，性能测试缺陷修复在20天以上的明显增多。这是由性能问题的复杂性决定的。依照经验，解决一个复杂的性能问题，有时候需要一个月甚至两个月的时间。所以对缺陷修复时间的分析要根据不同测试类别去进行。不同测试类别的缺陷修复数据可以用来作为今后各测试团队做项目测试计划的参考数据，例如性能测试要计划出足够的时间来核查缺陷修复。

　　5、按所属类别分析缺陷

　　理想情况下，各测试团队在测试时只发现自己所测类型的缺陷。但现实情况是所有测试类型虽然测试有先后，但也存在很大程度的时间重迭。

　　例如，由于性能测试的环境和数据要求很复杂，性能测试的测试成本远远大于功能测试的测试成本。所以性能测试一般会在其所需要的主要功能测试基本完成的情况下开始。但主要功能测试基本完成，并不代表此功能不存在缺陷。另外，主要功能在测试成功后，也可能由于后来的某些相关代码改动而存在回归缺陷。这造成性能测试中不可避免地发现功能方面的问题。