软件缺陷度量

       缺陷度量是软件度量的一部分，其本身并不能发现缺陷、剔除缺陷，但是有助于这些问题的解决。另外，当正确、持续地进行了缺陷度量时，产品以及过程的质量属性的数据为实施和管理过程改进活动提供了有效的基础。

       软件产品的质量度量，主要集中在软件的缺陷度量上。

        缺陷度量就是对项目过程中产生的缺陷数据进行采集和量化，将分散的缺陷数据统一管理，使其有序而清晰，然后通过采用一系列数学函数，对数据进行处理，分析缺陷密度和趋势等信息，从而提高产品质量和改进开发过程。

    （1）组织级缺陷度量，目的是了解组织的整体缺陷情况，了解客户对组织的质量满意度，建立组织基线，确定改进活动。

    （2）项目级缺陷度量，目的是了解项目实时质量情况（很多项目只在最后度量，包括那些迭代式开发的项目，实际上为时已晚），预测缺陷造成的发布后维护工作量，了解客户对项目的质量满意度。

    （3）个体缺陷度量，目的是了解个体缺陷产生的详细原因，并实施行动进行改进。

       前两种度量大家接触较多，但第三种度量常常被忽略。这常常导致：项目反复得到关于自己的质量评价，但很难了解如何去提高；测试组常常能做一些改进（如增加测试覆盖、延长测试周期）来提高缺陷排除效率，但开发组没有降低缺陷产生数量的有效措施；软件开发遵循了编码规范，但似乎对提高质量没有太多帮助。

       缺陷度量元的选择，也需要从度量目标出发，确定适当的度量元。例如，可以按照如下表所示的思路确定组织整体或者项目组个体使用哪些缺陷度量元。

       除了上边重点描述的度量元外，还可以考虑其他与缺陷度量有关的因素。例如：缺陷分布度量、基于时间的缺陷到达模式、PTR累积模型、测试用例的深度、质量和有效性、测试执行的效率和质量、基于需求的测试覆盖评估、基于代码的测试覆盖评估。

       再说一下前面的“前人栽树、后人乘凉“的5个度量元。通过需求变化率、同一需求变化次数、配置项变化率、同一配置项变化次数、同一缺陷变化率这5个度量元的度量数据，查找一下是不是由变化最多的需求引起的，是不是由变化最大的配置项引起的，可以使维护的效率提高40%左右。有效选择缺陷度量元，对缺陷预防、缺陷清除和缺陷管理有着至关重要的意义和作用。

        对于一个软件工作产品，软件缺陷可以分为通过评审或测试等方法发现的已知缺陷（known defect）和尚未发现的潜在缺陷（1atency defect）两种。

        Myers有一个关于软件测试的著名反直觉原则：在测试中发现缺陷多的地方，还有更多的潜在缺陷将会被发现。这个原则背后的原因是，发现缺陷越多的地方，漏掉的缺陷可能性也会越大，或者说测试效率没有被显著改善之前，在纠正缺陷时将引入较多的错误。其数学表达就是缺陷密度的度量—每KLOC或每个功能点（或类似的度量—对象点、数据点、特征点等）的缺陷数，缺陷密度越低意味着产品质量越高。

       缺陷密度的定义如下：缺陷密度=已知缺陷数量/产品规模

       缺陷密度与缺陷率、整体缺陷清除率、缺陷趋势、预期缺陷发现率等都有一定的关系。

       缺陷密度是软件缺陷的基本度量，可用于设定产品质量目标，支持软件可靠性模型（如Rayleigh模型）预测潜伏的软件缺陷，进而对软件质量进行跟踪和管理，支持基于缺陷计数的软件可靠性增长模型（如Musa-Okumoto模型），对软件质量目标进行跟踪并评判能否结束软件测试。

       如果缺陷密度跟上一个版本相同或更低，就应该分析当前版本的测试效率是不是降低了果不是，意味着质量的前景是乐观的；如果是，那么就需要额外的测试，还需要对开发和测试的过程进行改善。 

       如果缺陷密度比上一个版本高，那么就应该考虑在此之前是否为显著提高测试效率进行了有效的策划，并在本次测试中得到实施果是，虽然需要开发人员更多的努力去修正缺陷，但质量还是得到更好的保证；如果没有，意味着质量恶化，质量很难得到保证。这时，要保证质量，就必须延长开发周期或投入更多的资源。 

       当软件产品或者项目首次发布，并规定使用LOC计数时，可以比较容易地说出它的计划或者实际的质量等级，如“本产品共有83KLOC，在今后的3年时间里，潜在的缺陷率是2.0个缺陷/KLOC”。但当进行了修改、增强后进行产品的后续发布时，问题就会越来越复杂。

       缺陷跟踪：缺陷必须被跟踪到版本源头，其中包含此缺陷的代码段，以及在哪个版本中加入、修改或增强的。当计算整个产品的缺陷率时，要用到所有缺陷；当计算新的和更改代码的缺陷率时，则只需要包含新的和更改代码的版本源头中的缺陷即可。

       缺陷率度量在每个单位的基础上度量代码质量。

       从用户的角度来看，缺陷率远没有缺陷总数那么重要，对他们来说，产品应该确保缺陷总数与发布版本大小无关，而随着发布版本下降。如果一个新发布版本的大小比它的前一版本大很多，则需要新的和更改代码的缺陷率应该明显地好于以往版本。

       我们可以考虑如下假设的例子：

       产品A最初发布时代码总量为50KLOC，估计残留缺陷总数是100个，平均有2个缺陷/KLOC。

       发布第二版时，新增代码行为20KLOC，包括修改原来的4KLOC行代码（需要剔除，避免重复计算），可以计算出该版本代码总数为50 20 4 66KLOC，该版本对上一版本的缺陷率有10%的改进，估计当前版本残留缺陷新增总数可以控制在36个以内，则平均残留缺陷数为1.8个/KLOC。此时，由于此次发布版本较小，在缺陷率有10%的改进的同时，用户在缺陷数方面经历了(100 36)/100 64%的明显下降。

       如果进行第三版的发布时，新增代码行为40KLOC，这比第二次发布大得多，其中包括修改原来的10KLOC行代码，则该版本代码总数为66 40 10 96KLOC，为了使用户的缺陷体验不至于失望，增加的缺陷总数不应该多于上个版本的36个，所以缺陷率目标需要控制在36/40 0.9或者更低，即该版本的缺陷率必须比第二版的好50%。

       从缺陷发现、缺陷修复，直到缺陷解决、经验证、关闭缺陷为止，在缺陷管理的整个生命周期中记录了大量相关资料，它们是进行缺陷分析、提高产品质量所需要的宝贵信息。度量这些缺陷的发现成本、修改效益，对缺陷管理及其改进是非常有帮助的。

       一般地，要求将通过同行评审、测试、管理评审、PPQA发现、项目组内部发现以及客户反馈等几种手段发现的缺陷，都需要统一存放在缺陷跟踪系统（如TD、BUGZILLA等）中，进行统一管理、统计。其中涉及缺陷的基本信息在第1章已经描述过，包括缺陷标识、缺陷描述/主题、发现时间、所处阶段、发现手段、缺陷原因、发生条件、发生缺陷的子系统、所处的模块、发生缺陷的机器、软硬件平台、严重程度、优先级、缺陷状态、缺陷起源、发现人、计划修正时间、修正方法、跟踪验证人等信息项。

其中，软件发布前的缺陷原因关键字，可能包括以下几种：

    （1）需求文档：需求分析文档不明确、不详尽等原因引起。

    （2）信息交流：信息交流不畅，开发成员间沟通不及时引起。

    （3）编程：原始编程出错，没有客观原因。

    （4）修改：由于修改缺陷而引入的新缺陷，并且引发的变更与原变更的错误是相关的。

    （5）外部问题：涉及软件模块外部问题而引起。

    （6）培训：项目组新成员培训不充分，或使用新工具不熟练引发。

    （7）其他：指以上各种原因之外所产生的缺陷。

    软件发布后缺陷原因的关键字，可以有以下几种实例：

    （1）需求分析：需求分析不足等原因引起。

    （2）系统设计：软件系统设计种种原因引起。

    （3）程序编码：软件开发阶段中编程错误引起。

    （4）维护：软件发布后程序维护时引起。

    （5）实施：实施人员做软件初始化设置或系统参数设置不当等所引发。

    （6）用户：泛指用户不了解业务和软件、不熟悉操作等原因产生的异常问题。

    （7）数据异常：运行中不明原因引起的用户数据混乱和异常。

来源：xiaomi9024