全国咨询热线：136-9172-9932
本章节主要学习“软件缺陷预防的特性以及缺陷预防的过程”的内容，软件测试工程师应该都知道缺陷预防(Defect Prevention)是一种用于整个软件开发生命周期中识别缺陷根本原因和防缺陷发生的策略，也是全面质量管理(Total Quality Management)的本质。DP缺陷预防处于CMM(Capability Maturity Model)能力成熟度模型的第5个级别，分析之前一些偶然发现的问题，并且在将来为类似的可能的缺陷进行检查。一个成熟的研发团队会通过实施DP来提高质量和降低研发成本。
使用DP缺陷预防后，缺陷会呈现以下特性：
(1)缺陷发现率与时间的关系
使用DP 缺陷预防策略后，每个阶段所发现的缺陷数与使用DP 缺陷预防策略前所发生缺陷数的分布如图9-27 所示。
图9-27 DP 预防缺陷策略对缺陷现率的影响
从图中可以看出，使用DP 预防缺陷策略后，缺陷的特性发生了以下几个方面的变化：
1)需求和设计阶段所发现的缺陷数占所有缺陷的比例增大，这说明前期发现的缺陷比较多，这样可以降低缺陷修复的成本。
2)缺陷总数下降，也就是发现的总的缺陷数下降了，这得益于大部分的缺陷发现在前期的研发阶段。
(2)缺陷过滤器
使用DP 预防缺陷策略后，缺陷会像漏斗一样，每一个测试阶段都可以过滤掉一些缺陷，缺陷过滤器如图9-28 所示。
从图中可以看出，每经历一个阶段，缺陷就减少20%左右，直到测试结果，系统中99%的缺陷已经被解决。
缺陷预防的过程是指：在研发过程中，使用缺陷预防的策略是一个很复杂的过程，缺陷预防的具体过程如图9-29所示。
图9-28 缺陷过滤器
图9-29 缺陷预防策略
整个缺陷预防策略的详细步骤说明如下：
第一步：项目进行研发，研发的过程主要包括需求管理、设计和编码三个阶段，这里统称为研发阶段，因为在分析缺陷预防时，研发的阶段没必要分的那么仔细。
第二步：在测试过程中就会发现一些缺陷，此时就需要记录这些缺陷并对缺陷进行跟踪，现在主要是通过缺陷管理工具来对这些缺陷进行记录和跟踪。
第三步：记录的问题会被收集到缺陷数据库中，同时可以对这些问题进行分析，分析这些缺陷出现的原因和解决的情况。
第四步：对缺陷分布的趋势和原因进行深入的分析，分析的目的是找到现阶段研发存在的问题。
第五步：经过分析过程找到改进的方法，进而对现在的研发流程进行改进。
需要注意的是，在分析过程中其实是很难一次就改进完成，可能需要多轮的分析与改进。
在使用DP策略时，管理层必须在组织层和项目层进行一些书面的说明，当然这类书面说明又包括几方面的内容：长期的一个资金计划、资源和DP 活动组织相关的内部管理。
在实施DP之前，需要对DP 项目成员进行培训，培训主要包括软件保证、配置管理、文档支持和DP 中常见的主要的统计方法。
在整个DP活动过程中，应该定期检查DP 团队沟通和协调的事项。评审过程中，通常需要确定以下几个方面的内容：
引入缺陷的原因。
缺陷的影响。
预防缺陷所花费的改进成本。
对软件质量的预期影响。
具体的关于缺陷预防和分析的步骤如下：
(1)数据文件与度量
数据文件是整个缺陷分析最基础的工作，如果没有一个数据文件来支撑，那么就无法对缺陷进行详细的分析。通常缺陷的数据会被集中记录在一个存储库中，在一些成熟的公司有专门的缺陷分析管理工具，这和我们现在用的缺陷管理工具可能还会有所不同，这样可以方便DP 团队对缺陷进行跟踪和分析。通过缺陷分析管理系统可以详细地看到缺陷的细节和开发修改的计划或建议。这个分析系统还会记录缺陷修复成本与时间的关系，以及这个缺陷最后不被修复所带来的风险。
在对缺陷进行度量时，需要定期组织缺陷预防活动的审查，这样可以更好地帮助管理人员去判断缺陷预防的情况。审查或评审的时间应该是由组织来决定，有可能这个时间会很长，而且这个过程中应该存在处理异常的机制，出现异常时应该有方法可以处理。评审需要关注的内容包括：主要缺陷、缺陷的分类和缺陷分析的频率。
此外，相关的管理层应该评审CP 策略的成效，记录活动的一些属性，缺陷实际修复的成本和预计的成本。对活动的有效性进行验证，是确保缺陷预防策略成功的有效途径。
(2)案例研究分析
在第一步我们收集了整个分析过程中的一些数据，也就是做成了数据仓库，并对这些数据进行分析和度量。完成这些后，应该实时地对这些案例数据进行分析，这是整个缺陷预防中一个最重要的步骤。案例分析的方法就是常用的缺陷分析方法，关于常用的缺陷分析方法在9.6 节中进行了详细的介绍。
(3)基准线
在对之前的项目进行分析时，需要对已分析的数据创建一个参考基线，这个参考基线主要是用于对其他项目进行分析时参考用的，包括很多的缺陷分析方法其实都应该有一个参考值，否则很难对数据进行分析。
在对数据进行分析时，应该对数据进行分类，就如ODC 缺陷分析法其实就是从不同维度对缺陷进行分析，也就是从不同的分类角度来对缺陷进行分析。分析时研发阶段从5 个阶段进行分析：需求分析、系统设计、详细设计、编码和系统测试。一般情况下从10 个角度对缺陷进行分析，并且将每个分类划分为三级，这时就可以用一个4 位数来表示每类缺陷，缺陷的10 个分类与说明见表9-11。
表9-11 缺陷分类说明
上面只是对缺陷进行简单的分类，但这个分类还是太大了，不足以找到预防的方法，所以需要对缺陷进行再次挖掘，找到更深层次的原因，这样才能更好地定位引起缺陷的原因。下面以分析需求为例，对需求引起的缺陷进行详细的分析。
下面是一个项目的实际数据，按上面的10 大类对缺陷进行分类，分类后的缺陷分布见表9-12。现在对上面10大类的的缺陷中的需求类的缺陷进行第二次挖掘，主要从四个方面对需求的缺陷进行分析：需求完整性、需求演示、需求变更和需求正确性。分类后的缺陷分布见表9-13。
表9-12 按10 大类分析缺陷分布情况
表9-13 分类后的缺陷分布
下面对需求的完整性进行第三次挖掘，分析影响需求完整性的原因，主要从三个维度进行分析：
需求不完整、丢失或未指定的需求、过于广义的需求，分类后的缺陷分布见表9-14。
表9-14 第三次挖掘后缺陷分布情况
对缺陷进行多次挖掘的目的是找到缺陷分布的根本原因，上面只是针对需求进行了分析，接下来使用同样的方法对其他维度进行分析。
当每个维度的内容都经过深度挖掘和分析后，接下来就可以根据根本原因分析法找到改进的方法或过程，防止下一版本出现类似的缺陷。当然对于常见的缺陷类型，显然在我们关注时优先级是最高的。在DP 分析过程中，将DP 预防的会议或相关培训灌输到研发阶段中，并且需要对缺陷进行记录和度量，以确定预防措施是否生效。
最后一步是分析改进后缺陷分布的情况，并与改进前的缺陷分布进行比较，以确定缺陷预防策略的有效性，之后将预防策略写入到公司的标准流程体系中，之后再次对缺陷进行分析，如此不断循环，不断完善OSSP 标准流程，这样缺陷预防的策略就会越来越有效。
(1)期望结果
期望结果是指当我们不断改进缺陷预防策略时，必须将这些预防的策略建立成一套标准流程，并列出每个阶段预防策略的检查点，形成规范文章。
需要完善的策略主要包括以下内容：
应该有一套方法对需求文档中的需求进行编号。
在描述需求时应该有一套方法来降低二义性的需求出现。
将公用的支持和实施提取为策略。
改进软件需求规格说明书的模板。
在需求阶段应该使用上下文的方式来表达，在设计阶段应该使用功能接口或界面的方式来表达。
在研发的所有阶段，改进每个阶段检查点清单。
制定原因分析的策略和会议讨论或评审策略。
测试应该有一套策略。
一般从以下四个维度来评估缺陷预防策略的质量：
在研发过程中，每个阶段总的缺陷数减少。
研发的各个阶段的缺陷分布转变，即前期发现的缺陷数占总缺陷数的比例增多。
开发的成本降低。
开发的周期缩短。
(2)改进策略的成果
通过上面的分析可以找到缺陷预防的改进策略，但这些改进策略必须应用到整个研发过程中去，这样才能达到真正意义上的对缺陷进行预防。
在项目开始时，在研发的每一个阶段都需要举行相关的会议，来表达预防缺陷和因果分析的重要性，并且在每个阶段评审时应该有相应的检查清单，在进行同行评审时，应该对照这些检查清单来评审。
在整个研发过程中，每个阶段都应该使用缺陷跟踪系统详细记录缺陷并对其原因进行分析，现在很多公司都有自己的缺陷管理系统，将缺陷记录在缺陷管理系统中，这样可以更好地跟踪缺陷解决的方法和缺陷从开始记录到处理结束后的整个解决过程。
在对缺陷进行原因分析时，缺陷的解决方案必须是要让人满意的，并且通过会议来讨论，这样可以让大家在整个过程中对缺陷的预防和改进有一个较好的理解。
以上是缺陷预防的5 个步骤，核心步骤还是缺陷分析和改进流程的确定。
本章节关于“软件缺陷预防的特性以及缺陷预防的过程”的内容就学习到这里，大家觉得文章有用的话记得每天来这里和小编一起学习涨薪节能哦。
