在测试过程中发现的缺陷中，无效缺陷的比例不能过多，一般在一个项目测试过程中发现的无效缺陷应该都是低于5个的。如果无效缺陷过多，则说明测试对需求的理解方面有问题，导致提交缺陷时出现过多无效缺陷。
那么是什么原因导致测试工程师对需求理解的偏差呢那最主要的是在需求评审时，需求工程师在解释需求时(也可以说是唱需求)并没有表达得很清楚，导致对需求的理解出现问题。而目前很多公司在需求评审时，其实很多是没有详细解释需求的过程，而只是在评审过程中，如果评审发现需求有问题，才对有问题的需求进行详细的介绍。所以就可以发现对需求有着不一样的理解，这样就可能提交一些无效的缺陷。当提交的无效缺陷过多时，则说明我们的在解释需求和评审需求时存在很多问题，需要找到一个有效的方法来完善需求评审的过程。
缺陷修复是在整个测试过程上，开发修改缺陷的过程也是必须要去监控和评估的，通常缺陷修复的分析需求包括以下几个方面的内容：
(1)严重和致命类的缺陷修复的情况;
产品在发布时，不能遗留严重和致命类的缺陷，所以在产品发布之前一定要确保所有的致命和严重问题都得到解决。
(2)每个版本所修复缺陷的情况;
统计每个版所修复的缺陷趋势图，当然每个版本所修复的缺陷趋势图应该与所发现的缺陷趋势图是类似的，但主要需要分析以下问题，在所修复的缺陷中，有一些缺陷可能一次性没有修复完成，或者修复后引入了新的缺陷。这类问题就是我们主要分析的对象，因为当出现这类问题时，就必然会导致修复的缺陷成本升高。当然很少有公司具体去讨论这类未能被一次性修复的缺陷所占的百分比。但如果这个比例超过一定比例时，就必须对研发修复缺陷的过程进行详细的分析，以确定这类情况的具体原因。
但本节中我们将重点讨论缺陷如何度量，其他的维度我们在本书中不进行详细的讨论。
千行代码这个度量其实很简单，主要的问题是如何精确地计数实际的代码行数，在早期的汇编语言中，一行物理代码就相当于我们要计数的一行代码，但在高级语言中可能就不会这样，一行物理行并不一定是一行代码，即使同一个代码片段使用不同的计数工具计数，也可能导致结果存在差异，通常统计代码行有以下几种方法：
上面是常见的关于代码行的统计方法，不同的公司可能会有着不同的统计方法，但不管使用什么方法进行统计，统计的方法只能使用一种。不同的项目使用不同的统计方法，这样数据之间没有参考价值。
在统计过程中，统计物理行代码和统计指令语句是存在差异的，有时候甚至会差得很多，如
源有的代码语句称之为SSI，新增的和修改的称之为CSI，SSI与CSI公式如下：SSI(当前版本)=SSI(以前的版本)+CSI(当前版本新增或修改的代码行)
产品发布后需要对缺陷进行跟踪，在跟踪缺陷过程中可以对缺陷进行分类，通常分为用户发现和内部缺陷两类，每千行SSI和每千行CSI。
主要度量的内容如下：
第(1)点主要度量总的已发布代码的质量，第(3)点主要度量新修改或增加的代码的质量，如果当前测试的版本就是发布的第一个版本，那么第(1)点和第(3)点表达的意思是一致的。第(1)点和第(3)点主要是针对过程进行度量的。第(2)点和第(4)点主要是从客户的角度进行分类度量。对千行CSI率和千行SSI率进行估计，开发工程师可以通过修复缺将对用户的影响降低到最小化。