如图9-3所示，在18个无效缺陷里，重复缺陷占比例最高，其次是用法错误。所以就要进一步了解造成重复缺陷比例高的原因并予以改进。例如，可通过一些方法来提高测试团队之间的沟通，来有效降低重复缺陷。但有些重复缺陷是很难避免的，尤其是那些显示不同错误信息，但造成问题的代码是相同的缺陷。这些缺陷在很多测试专家眼里可以认为是有效缺陷。
用法错误的无效缺陷，在测试过程中应该尽量避免。这就要求测试人员要对测试案例有正确的理解而避免不必要的用法错误。另一方面，有些用法错误的缺陷可以转换成提高实用性的有效缺陷。 例如，小艾在安装测试时安装失败，小艾认为是安装代码的问题而报告了这个缺陷。开发人员在经过调查后发现是小艾不小心输入了错误的数据库密码而导致安装失败，就认为是用法错误而返回缺陷。小艾咨询了安装测试负责人，安装负责人认为虽然是测试人员用法错误，但从使用性上来讲，客户会遇到相同问题，产品应该能够在客户输入错误密码时提示客户，并禁止进一步安装。最终，开发人员接受了安装负责人的建议并修改了代码。而小艾所开的缺陷也成为提高使用性的有效缺陷。 2、按严重性分析缺陷 缺陷按问题的严重程度分为以下几个等级。 一级严重：是指缺陷造成整个应用或功能不工作，从而导致产品不能交付。 二级严重：是指缺陷造成功能输出结果错误。 三级严重：是指缺陷造成功能没有按预期方式实现。 四级严重：是指功能上需要加强。 在测试过程中，一级和四级严重缺陷应占比例较少，二级和三级严重缺陷比例应该占大多数。这是因为大部分一级严重缺陷在开发过程的单元测试中应该被发现和解决，而不应该流入到测试流程。 如图9-4所示，一级严重缺陷占39%，二级严重缺陷占33%，三级严重缺陷占21%，四级严重缺陷占7%。在此图中，可以发现一级严重缺陷的比例偏高。需要分析一下为什么会出现这种状况，是否有些缺陷应该在开发过程的单元测试中发现。应该把分析结果反馈给相关开发人员，并共同完善单元测试的测试范围，尽量让一级严重缺陷在早期发现并修复。
3、按功能分析缺陷 我们一般会看不同功能上发现多少缺陷。有些功能逻辑比较复杂，涉及的方面较多。这种情况所发现缺陷比例就会稍大。有些功能较简单，和其他功能没有太大交集，所发现缺陷就会相应较少。 如图9-5所示，功能2所发现缺陷占总数的41%，而功能4仅为7%。这说明功能2的复杂度相对大些，可能有必要再重新看看测试范围并增加一些测试案例。 4、按修复时间分析缺陷 一般来讲，一级严重缺陷需要开发人员一天之内解决，二级严重缺陷需要两天之内解决，三级严重缺陷要在一周内解决，四级严重缺陷应在两周内解决。
所以大部分缺陷从开始报告到最终核对并确认修复的周期应在一周内。不同测试类型缺陷修复时间是会稍微有一些差别的。例如性能测试的缺陷和迁移测试的缺陷由于测试环境较为复杂，并且较难找出造成缺陷原因，所以这两个测试类型的缺陷完成周期会相应长一些。 图9-6和图9-7分别是安装测试缺陷修复时间和性能测试缺陷修复时间数据图，从图中可看出，性能测试缺陷修复在20天以上的明显增多。这是由性能问题的复杂性决定的。依照经验，解决一个复杂的性能问题，有时候需要一个月甚至两个月的时间。所以对缺陷修复时间的分析要根据不同测试类别去进行。不同测试类别的缺陷修复数据可以用来作为今后各测试团队做项目测试计划的参考数据，例如性能测试要计划出足够的时间来核查缺陷修复。
5、按所属类别分析缺陷 理想情况下，各测试团队在测试时只发现自己所测类型的缺陷。但现实情况是所有测试类型虽然测试有先后，但也存在很大程度的时间重迭。 例如，由于性能测试的环境和数据要求很复杂，性能测试的测试成本远远大于功能测试的测试成本。所以性能测试一般会在其所需要的主要功能测试基本完成的情况下开始。但主要功能测试基本完成，并不代表此功能不存在缺陷。另外，主要功能在测试成功后，也可能由于后来的某些相关代码改动而存在回归缺陷。这就造成性能测试中不可避免地发现功能方面的问题。 |
