常用软件缺陷预防技术和缺陷分析技术有哪些？（08-06-13）（获奖名单已公布）

【引题】请介绍常用软件缺陷预防技术和缺陷分析技术有哪些？希望在常用方法上提出一些新的观点或自己独到的观点？

【题外话】对于这个问题，我一点思路都没有，只知道软件测试的目的就是尽早的尽可能地找出软件缺陷，从而保证软件的质量。尽早地参与，尽可能多的去发现问题。这只是原则，但是对于方法，我知之甚少，一方面，没有经过系统的学习和培训，也没有专人指导，工作经验一年多点，但也仅限于一些基本的功能测试。整理了大家的精彩回答作为学习源。

【正题】Zhuzx这个会思考又有经验的人，是这个问题的提出者，源于他面谈一家公司的测试经理的时候，被总监和老总问的问题，当然了，他的回答也很详细！看了之后，我不知道这些方法能有多少会被经常用到的呢：）

常用的主要缺陷分析技术如下：
1）、散布图：2）、柱状图：3）、饼图：4）、折线图：

常用的软件缺陷分析方法：
1）、缺陷分布报告：
通过对功能上的分布情况进行分析，可以了解哪些模块处理比较难，哪些模块程序质量比较差，有利于程序质量的改进和提高。缺陷起源分布报告，显示了缺陷的根本原因上的分布情况，这种分析会帮助程序代码质量的改进。
2）、缺陷趋势报告：
一个产品的开发过程，一般都会遵循一种比较接近的模式向前发展。在生命周期的初期，缺陷率增长较快。在到达顶峰以后，就随时间以较慢的速度下降。同时，缺陷趋势分析，还可以延伸用来评估开发所做的努力，同时也是判断测试完成标准的重要基础。
3）、缺陷年龄报告：
缺陷年龄报告是一种特殊类型的缺陷分布报告，显示缺陷目前的活动（New、Reject、Open、Fix、Reopen、Suspended、Closed）状态的时间，展示一个缺陷处于某种状态的时间长短，从而了解处理这些缺陷的时间进度情况。通过发现的缺陷数量和关闭的缺陷数趋势图，找到缺陷的收敛点，来预测产品下一个阶段的测试计划。
4）、测试结果进度报告：
展示测试在被测应用的几个版本中的执行结果以及测试周期，显示对应用程序进行若干次迭代和测试生命周期后的测试过程执行结果。

针对目前项目的实际情况，主要的缺陷预防方法如下：
1）、重点评审需求中不明确的功能模块和存在分歧的模块：
2）、根据需求开发Demo，让测试人员和用户确认：
3）、业务功能交叉的模块，最好做好代码走查：
4）、开发过程和需求更新要及时监控，并形成文档：
5）、对用户业务场景常用的模块，要重点评审；
6）、制定一个比较规范的测试规范；

针对目前软件企业的现状我总结的缺陷预防方法如下：

1、采用Demo技术设计低缺陷需求：
   
随着软件开发新技术的飞速发展和业务需求的不断增加，一般来说，软件业务比较复杂，单靠客户代表通过文字讲清全部的需求比较困难，并且也不太现实。加之开发方和客户在一些文字上理解的差异性，也就导致了开发方开发的需求和用户的实际需求相差越来越远，到最后缺陷也许就无法修复。
   针对目前需求的实际情况，我们通常把业务的常用模块、关键模块和核心模块做成Demo让用户确认，让用户真实体验使用软件的真是感受，如果发现使用不方便或者效果不佳，马上修改方案，减少许多不必要的损失。

2、采用统一的编码技术开发源代码：

  由于软件开发工作性质的特殊性，加之编码工作都属于脑力劳动，特别具有个性。软件的编码，对于从事软件程序开发的程序员来说，编程语言掌握的熟练程度和对编程思想的理解不同，决定不同编程人员的编程习惯上的差别。如果没有一个统一的代码风格，那么一个程序员的变动，也许就会导致另外一个程序员看不懂，给维护也带来较大的困难，因此，统一的代码规范（如：Windows命名规则、GNU命名规则和习惯以及函数处理规则等等）就显得非常重要。
  在有了良好的代码风格那是远远不够的，还必须有统一的编码规范（如C++规范、Java规范等）来提高代码的质量，让所有的开发人员都学习该规范，达成统一共识，严格按照规范编写程序。

3、采用技术评审手段减少缺陷产生：

   技术评审作为软件开发生命周期中的一中非常重要的手段，理论上来说可以减少缺陷。我们可以通过对开发过程中的每一个阶段，进行评审来保证产品的质量。
  对客户和开发方的需求确定以后，需要客户代表和开发方对需求规格说明书进行评审，修改不合理需求或理解有分歧的需求后，再最终定稿需求。接下来就是对开发方重点评审需求分析人员编写的概要设计文档和开发人员编写的详细设计文档。对于测试人员编写的单元测试、集成测试和系统测试文档，包括测试计划、测试用例和测试报告，都必须有开发人员、测试人员、项目经理和需求分析人员等人的共同评审。只有不断修改评审后的文档，才会起到缺陷减少的目的。

4、采用成熟的开发技术和开发工具：

软件开发过程中缺陷的引入，大多数是在使用新的开发工具和新技术的情况下产生的。由于大部分的开发人员对一些新技术的认识和了解不够，加上开发时间的压力，缺乏新开发工具的使用经验开发人员不得不加班加点，学习和探索新技术，追赶开发进度，导致大量的缺陷被引入软件中。
   采用成熟的开发技术和开发工具，加上相关设计人员和开发人员丰富的经验，能够较大限度的避免缺陷的发生。

5、采用单元测试技术降低软件缺陷：

  单元测试是软件测试中一个比较关键的阶段，根据项目的实际经验，大约有50%到80%的缺陷，都可以通过单元测试发现，并立即消除。通过单元测试这样一个非常重要的环节，规范单元测试流程，切实做好单元测试，提高单元测试技巧，更高更好的完成软件测试工作。

这个人又很好学，回答完这个问题又回去“翻书”找了更为详尽的答案，作为补充，我也一并收藏

常用的统计分析工具：
1）散布图：
散布图通常作为研究因果关系的一部分，是考察数据的第一步。有时假定一个变量是独立的，另一个变量是非独立的。当系统处于稳定状态时，散布图通常是回归分析的前导，当它显示二个变量之间存在某种关系时，可紧接着采用更正式的统计方法。
2）运行图：
是散布图的时间序列表，可用于快速检验数据和非正式地显示在一个时间段中的趋势。它非常像控制图，但没有界限和中心线。
运行图能用于监视一个过程的趋势或过程变化的情况，如：产量、产品规模、团队大小、发现的缺陷数、库存、累计或每日的消耗等。能真实地显示任何时间段或范围的情况。
3）因果图：
也称鱼刺图或石川图，创建于1943年。用于表述、图解和区分一个特殊过程、问题或结果的因果关系，了解什么是可能引发问题的原因。因果图通常是由集体讨论时绘制的。虽然因果图具有主观的因素，但它是基于实际的信息的，如度量值和问题出现的日期。
因果图分为三类：
偏差分析因果图――它是通过反复提问“为什么会出现偏差？”来建立的。它的强项是帮助理清引起产品或其它过程偏差的因素。不足是依赖个人的观点，有可能引入次要因素。
生产过程分类因果图――它是通过生产过程的步骤了建立的。通过1）将每一步原因设置在鱼刺的主要肋骨上，2）在背瘠上画一个方框，每个框中是一个生产步骤。它的强项是容易汇总和明了，不足是类似的原因可能出现在多个地方，使问题的结果难于描述。
原因枚举因果图――首先列出所有可能的在产品或过程质量方面的原因，然后将它们组织起来表示它们之间的关系，这些可能的因素可由头脑风暴法产生。它的强项是可以枚举大量的可能的原因，减少忽视主要问题的可能性。只要做得好，能产生更为完整的结果。它的不足是树的树梢难于整合到结果中去。
4）柱状图（直方图、频数分布图）
能显示经验观察结果的分布情况，显示给定观察时间段内出现的事件的频率。可用于刻划任何过程或产品属性的观察值，如，模块大小、Bug的修复时间、两个故障间的时间、每次测试或检查发现的缺陷数、每天的订单等。对揭示过程、项目、或时间中的差异很有帮助。它能显示频率计数，容易比较分布情况和看到主要趋势与偏差。具体算法：
1）收集数据（数据越多越能说明问题）；
2）计算极差R＝Xmax－Xmin；
3）确定分组数：50～100个数据，分为6～10组；100～250个数据，分为7～12组；250以上，分为10～20组；
4）确定测定值最小单位，如：2；
5）计算组间距：H＝R/组数；
6）计算第1组的下限值：Xmin－测定值最小单位/2； 第2组的下限值＝第1组的下限值＋组间距；
7）计算组中心值＝（组上限值＋组下限值）/2；
8）计算频数表：
9）画柱状图；
10）分析过程状态：
正常型，服从正态分布；
偏向型，可能由习惯作业造成；
双峰型，可能来自两个总体的数据混在一起；
孤岛型，可能由于短时间的异常因素作用所致；
低峰型，可能由于过程中某种倾向性因素缓慢作用所致；
高峰型，可能数据经过筛选；
5）条形图：
大部分情况类似柱状图，但它不需要连续的测量或频数计数，是基于离散的范围的数据。用于研究数据集的形态，显示确定实体、产品集或过程中相关的总的规模、成本、和消耗的时间。
6）Pareto图：
称佩瑞多图，佩瑞多（1848～1923意大利经济学家和社会学家）。它是柱形图或条形图的一种特殊形式。对发现分类的问题、原因、依据总量的活动、出现的频率、或经济结果很有帮助。对于组织从众多的事件中分离出主要的少数事件，将采取何种高优先级的改进活动提供帮助，有助于明确哪一类缺陷应该特别关注？所检测到的问题中，哪一个部分贡献最大？
Pareto图一般采取降序的方式显示频率计数或总量。它总是与相应的时间段相关，时间界限必须清楚；它对用于比较改进措施采取的前后状态是敏感的。但如果过程不稳定，可能导致错误的结论。
7）检查表：
分析识别方法
写出所有问题的清单
按重要性整理这个清单
识别出重要少数（Vital few）
识别出不重要多数(Trivial many)

天网作为版主，也给出了自己简明的见解：

常见缺陷分析技术：
1、ODC缺陷分析：由IBM的waston中心推出。将一个缺陷在生命周期的各环节的属性组织起来，从单维度、多维度来对缺陷进行分析，从不同角度得到各类缺陷的缺陷密度和缺陷比率，从而积累得到各类缺陷的基线值，用于评估测试活动、指导测试改进和整个研发流程的改进；同时根据各阶段缺陷分布得到缺陷去除过程特征模型，用于对测试活动进行评估和预测。上面回答中涉及到的缺陷分布、缺陷趋势等都属于这个方法中的一个角度而已。
2、Gompertz分析：根据测试的累积投入时间和累积缺陷增长情况，拟合得到符合自己过程能力的缺陷增长Gompertz曲线，用来评估软件测试的充分性、预测软件极限缺陷数和退出测试所需时间、作为测试退出的判断依据、指导测试计划和策略的调整；
3、Rayleigh分析：通过生命周期各阶段缺陷发现情况得到缺陷Rayleigh曲线，用于评估软件质量、预测软件现场质量；
4、四象限分析：根据软件内部各模块、子系统、特性测试所累积时间和缺陷去除情况，和累积时间和缺陷去除情况的基线进行比较，得到各个模块、子系统、特性测试分别所位于的区间，从而判断哪些部分测试可以退出、哪些测试还需加强，用于指导测试计划和策略的调整；
5、根本原因分析：利用鱼骨图、柏拉图等分析缺陷产生的根本原因，根据这些根本原因采取措施，改进开发和测试过程；
6、缺陷注入分析：对被测软件注入一些缺陷，通过已有用例进行测试，根据这些刻意注入缺陷的发现情况，判断测试的有效性、充分性，预测软件残留缺陷数。在06年软件评测师考试中有一题就是考这个思路，参见这个帖子我的回复：http://bbs.51testing.com/thread-114979-1-1.html
7、DRE/DRM分析：通过已有项目历史数据，得到软件生命周期各阶段缺陷注入和排除的模型，用于设定各阶段质量目标，评估测试活动.

至于缺陷预防，基本上是两个方面：
1、测试活动尽量提前，通过及时消除开发前期阶段引入的缺陷，防止这些缺陷遗留并放大到后续环节；
2、通过对已有缺陷进行分析（例如上面的ODC分析等），找出产生这些缺陷的技术上不足和流程上不足，通过对这些不足进行改进，防止类似缺陷再次发生。

超级版主fengyun32从分析Bug根源的角度给出自己的阐释。

bug预防策略
   我们的策略是发现bug，找出bug的根源，然后寻找一个方法来预防类似的bug在将来出现。因为QC过程已经用于在目前的产品中发现bug，因此该策略的大部分工作实际上已经执行，大多数开发过程缺少的正是分析在QC过程中发现的bug。正如你将看到，尽管策略的这一部分并不需要昂贵的花费，但是却带来了极大的额外价值。
分析过程
(1) Bug发现和初步分析
   如前所述，bug分析的第一步是发现bug。然而，发现bug的QC工程师（注：测试工程师）不应该满足于记录bug的表面症状。QC工程师的一个重要职责就是试图发现bug的根本原因。QC小组在检验产品质量时，不应该将产品看作一个黑盒，而应该像开发人员那样了解产品的内在，包括深入源代码，理解产品的设计和实现。这些能力都是QC小组开始bug分析的基本要求。熟悉了产品的代码，QC工程师就可能推测出bug的根本原因。我要强调是下面这个短语的本质：bug的根本原因？bug的根本原因并不是产生这bug的源代码所在，尽管这些信息可能和分析过程关系密切。但是，发现bug的根本原因意味着找到造成这些错误的原因。通过一些实例来说明这个问题可能更清楚一些。
   让我们看一个普遍存在的关于线程同步的问题。假设一个多线程的应用程序需要同步地访问某个数据结构。被指派测试这个产品的QC工程师发现在某种情景下，应用程序尽管没有Crash，但是会停止响应。正常的QC过程是，这个bug被记录在bug跟踪系统中，并描述了测试情景和停止响应的实际结果。然而，如果这个QA工程师熟悉源代码，就可以进行bug产生原因的初步分析。例如，这个QC工程师可能断定这个bug产生的原因是之前的线程没有释放mutex，从而造成了冲突。这些分析可以记录在bug的详细说明中，作为bug分析的一个基础。
(2) Bug修订和进一步分析
   一如既往，发现一个bug之后，开发人员应该负责处理它。但是，如果bug的发现过程包含了bug根本原因的初步分析，那么关于如何解决这个bug，开发人员可能拥有了更多的信息。虽然这不是QC工程师bug初步分析的目的，但是它可能为开发人员提供了更多的观点。除了修正缺陷以及记录实现的具体步骤，开发人员还应该对bug进行进一步的分析。这次分析应该着眼于导致bug产生的开发情景。
   在线程同步的例子中，开发人员不应该仅仅记录增加了一个调用来释放mutex（注：Mutal Exclusion =互斥锁，保证了共享数据不会同时被多个线程访问，只向一个线程授予对共享资源的独占访问权）。反之，开发人员应该找出没有释放mutex的原因。假设分析的原因是：因为需要同步的方法超过一个的返回点，因此开发人员在某些控制路径上忘记清理代码。
   这一类简单的分析实际带来了非常大的价值。不同于记录具体问题的具体解决办法，我们现在有了可以解决许多情况的经验，有些情况甚至并不涉及到线程同步和释放mutex。但是，分析过程并没有结束，我们需要进一步的分析来将收集的所有数据转换为实践，从而帮助在将来避免类似bug的发生。
(3) bug预防分析
   分析的最后一步就是寻找一个预防类似错误的方法。这一方法不仅涉及到开发、QC工程师，还涉及到不直接负责代码编写的资深开发人员。
   这一阶段的成果是一些有用的实践经验，开发人员可以通过这些实践预防bug而不是修正bug。这些实践不应该是某个具体问题的解决方案。在我们线程同步的例子中，可能得到这样一个实践：是否有审计范围机制来获取和释放资源？这种实践（不一定适合所有编程语言）可以指导开发人员用一个类（class）封装资源,这样构造(constructor)函数容易分配和而与析构(destructor)函数释放资源。如果遵守这样的约定,当程序结束这方法时，不管控制路径是怎样的，资源（上述例子中获得的mutex）总能被释放。
    Bug预防分析是整个bug分析过程的核心。这一阶段总结出的实践可以在更广泛的范围内预防潜在的缺陷。由于分析结果的广泛应用性，分析某个具体问题的投入将很容易被收回。
   非常重要的是我们前面所举的例子是一个随机性的bug。开发人员由于疏忽而忘记了释放资源。在代码实现时，这样的bug是随机产生的，但是类似bug产生的几率却非常高。所以，尽管这一类bug是随机的，但仍然可以被预见并防止发生。
(4)发布经验
   分析得出的实践经验应该被记录并发布，这样其他的开发人员就可以通过学习这些经验避免类似的错误。一个发布经验最好的办法就是知识库。这将使得新的知识在组织内流动并被相关的开发人员所学习。
   如果不将分析结果传达给组织内相关的其他人员，那么分析的目的就没有达到。避免下一个bug出现的唯一办法就是让开发人员知道如何避免它，并鼓励他们这么做。
Bug分析实例
   让我们研究另外一个例子，以便更好地理解bug分析的益处。在这个事例中，QC工程师进行了如下的操作：当输入一个长字符串到应用程序时造成其崩溃(crash)。这一结论本身就需要一定程度的分析，但这个QC工程师并不满足于这样的分析，进一步研究了相关的代码，发现crash的原因是输入字符串时的处理有问题。其中一个步骤是将输入的字符缓存在一个固定大小的数组中，而这个数组有时候显得太小了。和线程同步的例子一样，QC工程师的初步分析带来了很大的价值，开发可以更容易的发现和修正这个bug。此外，记录缺陷的真正原因而不是表象，将帮助其他人避免类似的bug。
   接着，开发人员开始修正这个bug。当修正的时候，她不仅记录了解决措施，并说明了导致缺陷产生的原因。在这个例子中，造成bug的原因是在操作未经处理的C/C++缓冲区时，没有经常检验缓冲区的大小是否不够。然而，这个结论甚至可以被进一步总结为更广泛应用的经验以便帮助开发人员在以后避免类似的缺陷发生。所以，在分析的最后阶段，开发人员在组内更资深的开发人员的帮助下，得到了下面的实践经验：避免使用未经处理的C/C++缓冲区，尽量使用安全的collections和strings，如标准模版数据库中提供的可用collections和strings。这样就完全可以避免前面发现的这个bug。
益处
    Bug分析带来了很多的好处。第一个好处就是帮助产生错误的开发人员总结经验，并使他在将来避免类似的错误。有时，只修正一个具体的bug而不去分析它产生的原因并不会帮助在日后得到提高。在这种情况下，只有深入分析和资深开发人员的指导才能使开发人员成长和提高能力。
   更广泛的好处是使得其他开发人员从同事的错误中吸取教训。分析总结的实践经验可以预防bug的产生，这样的知识在组织内的成员间共享。某个开发人员产生的bug可以帮助组织内的其他人避免类似的bug出现。
   从更一般的角度来看，发布最佳实践（如bug分析总结的实践）促进了组织内成员的学习和自我提高。这样看来，Bug分析的价值还不仅仅是缺陷的预防。
   另一个好处是通过从更广的角度上记录bug，组织内的其他QC工程师将知道如何发现类似的错误。除了分享组织内的测试知识和经验，bug分析过程可以促进开发更好的测试技术和工具，从而帮助发现类似的bug。所以，就算缺陷没有被完全预防，也能更容易被发现。
   作为上面所有好处的结果，QC在一轮测试中将有更多的时间来测试更复杂的情景并发现更“狡猾的”bug。如果类似的bug都已经被预防而不容易产生，而且QC都有更好的技术来发现类似的bug，就有了更充裕的时间来进行更高级的测试。当然，组织所生产的产品的质量也将得到提高。
   最后，我想强调的是bug分析不仅收集了执行中的问题，而且从这些问题中总结了实践经验。举例来说，导致一个bug产生的原因可能是需求不够清楚。这样，通过bug分析得到的经验提供了一种方法来预防需求不清楚。这个经验可能不会对组织中的开发人员产生效果。所以尽管QC工程师开始验证开发人员的实现结果，但是还需要改善开发流程，如需求收集、设计流程等。
   真正的质量是生产没有bug的产品。任何其他目标都使组织内的成员从思想上接受软件缺陷是正常工作流的一部分。所以，第一步就是防止相同的bug再次发生。我们可以很轻易地执行这个目标。我们可以通过某个开发人员产生的一个bug提高整个组织的实践经验