软件测试缺陷预防的过程

        在软件测试研发过程中，使用缺陷预防的策略是一个很复杂的过程，缺陷预防的具体过程如图 9-29 所示。

        整个缺陷预防策略的详细步骤说明如下： 第一步：项目进行研发，研发的过程主要包括需求管理、设计和编码三个阶段，这里统称为研 发阶段，因为在分析缺陷预防时，研发的阶段没必要分的那么仔细。 第二步：在测试过程中就会发现一些缺陷，此时就需要记录这些缺陷并对缺陷进行跟踪，现在 主要是通过缺陷管理工具来对这些缺陷进行记录和跟踪。 第三步：记录的问题会被收集到缺陷数据库中，同时可以对这些问题进行分析，分析这些缺陷 出现的原因和解决的情况。 第四步：对缺陷分布的趋势和原因进行深入的分析，分析的目的是找到现阶段研发存在的问题。 第五步：经过分析过程找到改进的方法，进而对现在的研发流程进行改进。 需要注意的是，在分析过程中其实是很难一次就改进完成，可能需要多轮的分析与改进。 在使用 DP 策略时，管理层必须在组织层和项目层进行一些书面的说明，当然这类书面说明又 包括几方面的内容：长期的一个资金计划、资源和 DP 活动组织相关的内部管理。 在实施 DP 之前，需要对 DP 项目成员进行培训，培训主要包括软件保证、配置管理、文档支 持和 DP 中常见的主要的统计方法。 在整个 DP 活动过程中，应该定期检查 DP 团队沟通和协调的事项。评审过程中，通常需要确 定以下几个方面的内容：  引入缺陷的原因。  缺陷的影响。  预防缺陷所花费的改进成本。  对软件质量的预期影响。 具体的关于缺陷预防和分析的步骤如下：

        （1）数据文件与度量 数据文件是整个缺陷分析最基础的工作，如果没有一个数据文件来支撑，那么就无法对缺陷 进行详细的分析。通常缺陷的数据会被集中记录在一个存储库中，在一些成熟的公司有专门的缺 陷分析管理工具，这和我们现在用的缺陷管理工具可能还会有所不同，这样可以方便 DP 团队对 缺陷进行跟踪和分析。通过缺陷分析管理系统可以详细地看到缺陷的细节和开发修改的计划或 建议。这个分析系统还会记录缺陷修复成本与时间的关系，以及这个缺陷最后不被修复所带来的 风险。 在对缺陷进行度量时，需要定期组织缺陷预防活动的审查，这样可以更好地帮助管理人员去判 断缺陷预防的情况。审查或评审的时间应该是由组织来决定，有可能这个时间会很长，而且这个过 程中应该存在处理异常的机制，出现异常时应该有方法可以处理。评审需要关注的内容包括：主要 缺陷、缺陷的分类和缺陷分析的频率。 此外，相关的管理层应该评审 CP 策略的成效，记录活动的一些属性，缺陷实际修复的成本和 预计的成本。对活动的有效性进行验证，是确保缺陷预防策略成功的有效途径。

        （2）案例研究分析 在第一步我们收集了整个分析过程中的一些数据，也就是做成了数据仓库，并对这些数据进行 分析和度量。完成这些后，应该实时地对这些案例数据进行分析，这是整个缺陷预防中一个最重要 的步骤。案例分析的方法就是常用的缺陷分析方法，关于常用的缺陷分析方法在 9.6 节中进行了详 细的介绍。 （3）基准线 在对之前的项目进行分析时，需要对已分析的数据创建一个参考基线，这个参考基线主要是用 于对其他项目进行分析时参考用的，包括很多的缺陷分析方法其实都应该有一个参考值，否则很难 对数据进行分析。 在对数据进行分析时，应该对数据进行分类，就如 ODC 缺陷分析法其实就是从不同维度对缺 陷进行分析，也就是从不同的分类角度来对缺陷进行分析。分析时研发阶段从 5 个阶段进行分析： 需求分析、系统设计、详细设计、编码和系统测试。一般情况下从 10 个角度对缺陷进行分析，并 且将每个分类划分为三级，这时就可以用一个 4 位数来表示每类缺陷，缺陷的 10 个分类与说明见 表 9-11。

        上面只是对缺陷进行简单的分类，但这个分类还是太大了，不足以找到预防的方法，所以需要 对缺陷进行再次挖掘，找到更深层次的原因，这样才能更好地定位引起缺陷的原因。下面以分析需 求为例，对需求引起的缺陷进行详细的分析。 下面是一个项目的实际数据，按上面的 10 大类对缺陷进行分类，分类后的缺陷分布见表 9-12。 现在对上面 10 大类的的缺陷中的需求类的缺陷进行第二次挖掘，主要从四个方面对需求的缺 陷进行分析：需求完整性、需求演示、需求变更和需求正确性。分类后的缺陷分布见表 9-13。

        下面对需求的完整性进行第三次挖掘，分析影响需求完整性的原因，主要从三个维度进行分析： 需求不完整、丢失或未指定的需求、过于广义的需求，分类后的缺陷分布见表 9-14。

        对缺陷进行多次挖掘的目的是找到缺陷分布的根本原因，上面只是针对需求进行了分析，接下 来使用同样的方法对其他维度进行分析。 当每个维度的内容都经过深度挖掘和分析后，接下来就可以根据根本原因分析法找到改进的方 法或过程，防止下一版本出现类似的缺陷。当然对于常见的缺陷类型，显然在我们关注时优先级是 最高的。在 DP 分析过程中，将 DP 预防的会议或相关培训灌输到研发阶段中，并且需要对缺陷进 行记录和度量，以确定预防措施是否生效。

        最后一步是分析改进后缺陷分布的情况，并与改进前的缺陷分布进行比较，以确定缺陷预防策 略的有效性，之后将预防策略写入到公司的标准流程体系中，之后再次对缺陷进行分析，如此不断 循环，不断完善 OSSP 标准流程，这样缺陷预防的策略就会越来越有效。 （1）期望结果 期望结果是指当我们不断改进缺陷预防策略时，必须将这些预防的策略建立成一套标准流程， 并列出每个阶段预防策略的检查点，形成规范文章。 需要完善的策略主要包括以下内容：  应该有一套方法对需求文档中的需求进行编号。  在描述需求时应该有一套方法来降低二义性的需求出现。  将公用的支持和实施提取为策略。  改进软件需求规格说明书的模板。  在需求阶段应该使用上下文的方式来表达，在设计阶段应该使用功能接口或界面的方式 来表达。  在研发的所有阶段，改进每个阶段检查点清单。  制定原因分析的策略和会议讨论或评审策略。  测试应该有一套策略。 一般从以下四个维度来评估缺陷预防策略的质量：  在研发过程中，每个阶段总的缺陷数减少。  研发的各个阶段的缺陷分布转变，即前期发现的缺陷数占总缺陷数的比例增多。  开发的成本降低。  开发的周期缩短。 （2）改进策略的成果 通过上面的分析可以找到缺陷预防的改进策略，但这些改进策略必须应用到整个研发过程中 去，这样才能达到真正意义上的对缺陷进行预防。 在项目开始时，在研发的每一个阶段都需要举行相关的会议，来表达预防缺陷和因果分析的重 要性，并且在每个阶段评审时应该有相应的检查清单，在进行同行评审时，应该对照这些检查清单 来评审。 在整个研发过程中，每个阶段都应该使用缺陷跟踪系统详细记录缺陷并对其原因进行分析，现 在很多公司都有自己的缺陷管理系统，将缺陷记录在缺陷管理系统中，这样可以更好地跟踪缺陷解 决的方法和缺陷从开始记录到处理结束后的整个解决过程。 在对缺陷进行原因分析时，缺陷的解决方案必须是要让人满意的，并且通过会议来讨论，这样 可以让大家在整个过程中对缺陷的预防和改进有一个较好的理解。 以上是缺陷预防的 5 个步骤，核心步骤还是缺陷分析和改进流程的确定。