常用软件缺陷预防技术和缺陷分析技术有哪些？（08-06-13）（获奖名单已公布）
请介绍常用软件缺陷预防技术和缺陷分析技术有哪些？希望在常用方法上提出一些新的观点或自己独到的观点？感谢会员zhuzx提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！
非常感谢各位会员积极参与，截止至6月20日17：30分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。
获奖名单奖项获奖名单奖励答案链接一等奖天网当当购物卡50元18#二等奖fengyun32300论坛积分20#fmsbai535#三等奖sunwenjuan100论坛积分
8#tiantian01016#卖烧烤的鱼40# 沙发……
:loveliness:
非常想知道…… 痴痴地等着你的回答…… 学习，学习.......happy
是哪位高人，能够提出这么高深的问题？？
版主，是哪位高人提出的这个高深的问题？？我做了3、4年的测试，也算是公司的一个小Leader了，面试了很多公司几乎都没有人问到我这样的问题？并且对这样的问题，回答起来也很棘手呀。也许是面试测试经理的吧！！
是哪位高人出的这道题目，能否把您当时的答案回答给我们听听，让我们也增长见识，谢谢哈！！
:handshake
同意楼上的观点
同意楼上的观点，希望出题的同行朋友看到我们这么多帖子以后，给给你的答案吧，我们都期望好久了。到时候，我们推举您是最最受欢迎的问题怎样？？哈哈！！
常见软件缺陷预防技术和缺陷分析技术有哪些？
首先,要先知道什么是缺陷,缺陷既指静态存在于软件工作产品(文档、代码)中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。从定义可以看出什么情况下会容易产生缺陷，一般性测试越早进行越好，主要是越早测试越容易发现致使的缺陷，也能够减少成本。由些，可以看出最好的预防缺陷的方法是在开发人员着手写代码的时候，我们的单元测试也同步进行。缺陷的分析技术包括：
1、缺陷分布图：可按属性分布——模块、提交人、严重级别（一般、严重等）、引入阶段（SRS、HLD、LLD）、类型（功能、性能、GUI等）。
2、缺陷趋势图：也可叫发展趋向，一个版本内工作量一致的情况下的发展趋向。
3、缺陷龄期图
这些缺陷图可以在Mercury QualityCenter（QC）的Defects模块里可以设置看到。
以上是我个人的愚见，还请大家多多指教。 就缺陷预防，我觉得主要有两点
一个是项目过程中的预防，主要借助于评审，在需求、设计完成之后进行严格有效的评审，并做原因分析，这样可以很好的避免需求和设计阶段的缺陷遗留到后期，无限扩大缺陷修复成本，评审完成之后，跟踪评审缺陷直至关闭；其次是变更管理、配置管理。 编码阶段完成之后的单元测试，以及后边的各个阶段的测试，这个自然不必多说。
两外一个因为缺陷分析需要大量的缺陷信息，所以要形成缺陷库，长期积累分析指标数据，才可以对以后的缺陷预防起到知道意义
缺陷的分析，我觉得主要从以下几个方面去考虑
事物都是有两面性的，所以进行分析也要进行两方面分析，一般在分析缺陷之前，我们首先会关注缺陷的数量（其实缺陷的数量并不能说明软件质量）
发现的缺陷比较少时，就要分析到底是被测对象的质量高，还是测试方法有问题，测试范围是否完全覆盖到了，测试用例设计的是否不够 等等总之要保证测试的有效性；
发现大量的缺陷，就要分析这些缺陷所在的模块，缺陷的类型，缺陷趋势等
1、缺陷所在的模块，我记得曾经说过80%的缺陷存在于20%的模块中，通过缺陷所在模块可以分析出哪些模块不稳定，接下来就要对这些不稳定模块着重测试。另外还要关注缺陷是由需求变更引起的还是缺陷修复引起的。
2、缺陷的类型，有时发现的缺陷大部分都是严重级别比较低的缺陷（例如界面、提示信息等），而功能方面的却比较少，它就有两种可能，一种是这个系统经过测试证明系统是比较稳定的，质量是比较高的；另一种是我们测试的时候，功能部分关注的不充分，有遗漏。
3、缺陷趋势，从缺陷趋势中，可以了解到缺陷的收敛是否正常，还是在无限制扩大，如果是无限制扩大就要采取相应的措施，观察缺陷趋势，还可以了解到软件之来那个再什么时候已经得到了很好的控制，也可以为是否可以停止测试工作做一个指导。
另外在软件测试过程当中会出现缺陷重复的情况，就要分析缺陷重复的原因在哪里了（我遇见的比较多的就是版本出了问题）
在缺陷分析过程中也有很多指标，例如有缺陷密度、缺陷的修复率、缺陷的平均修复时间、返工的工作量、测试用例的有效性 等等，比较常用的应该有这些（暂时也就能想到这些^_^）
我在工作中基本上用到的差不多就这些吧，可能还有遗漏的，写的也可能比较片面，有不当之处，还请多多指教
谢谢大家对这个问题的关心，我当时回答的大致内容
不好意思，由于大部分内容涉及到我的毕业论文，暂时修改一下，忘理解。[ 本帖最后由 zhuzx 于 2008-11-15 21:46 编辑 ]
不愧为测试经理
不愧为测试经理呀？您已经总结的比较好了，向您学习学习！！并希望您以后，天天上51testing答题，给我们更多的学习机会。
如果愿意，很想交个朋友yaoyao@163.com，我的邮箱。
大家回答得都很棒
大家辛苦了，回答得都很棒，学到了不少东西！！希望高手继续回答，呵呵！！缺陷预防技术和缺陷分析技术
很赞同9楼的观点，很详细很透彻！:)“常用方法上提出一些新的观点或自己独到的观点”，我就针对缺陷预防技术谈谈自己两点不同的看法：
1、行业背景及用户使用的特点
当拿到××行业的项目单子时，我们不仅仅局限于从客户获取需求，还要发掘该行业的隐性需求。如替税务局开发一个项目，不仅考虑跟税务相关业务，可能还要考虑法律、发规等行业背景。
以前有使用过系统的用户，对于新系统开发，是特别挑剔的。所以在开发系统时，我们需要抽取时间来关注前系统，了解用户的操作和使用习惯。
2、采用外包模式
一般来说，每个公司都有自己的薄弱地方，如有些公司，可能在需求做得很差，不妨考虑将需求外包。既可以得到一份质量较高的需求， 从而在前期减少缺陷的产生，又可以加快项目进度，何乐而不为呢。
[ 本帖最后由 lshy1113 于 2008-6-16 19:13 编辑 ]
这个问题很有挑战，我喜欢
嘿嘿，这个问题真好，很有深度，有难度，我觉得大家不要泛泛而谈，拿出一些可执行性比较强的方案。获益匪浅
这个模块开展的真好。前辈们的回答也很精彩，真是让我获益匪浅。眼前一亮啊。。希望大家以后对我这个后辈多多给予指导哦。
希望大家以后把软件测试工程师入职面试题目拿来讨论
希望大家以后把软件测试工程师入职面试题目拿来讨论，让大家共同进步，共同提高！！同意13楼观点，拿出一些“可执行性比较强”的方案。 同意9楼的意见:
对于缺陷预防:
我主要从生命周期和部门间的沟通方面来阐述一下个人观点;
对于软件开发周期来说，控制环节越早对于降低和预防软件缺陷的效果越明显;软件测试也同样的应该尽早的介入,在项目启动之时,就开始准备。
1 、在需求设计阶段，做好评审工作和需求确认工作是较少软件缺陷的关键；
在这个阶段开发部门和测试部门之间以及和用户之间对于需求的沟通是致关重要的，它可以减少后期由于开发人员、测试人员和用户对需求理解歧义而引发的缺陷；
2 、在软件概要设计的时候，应该做好规划，搭好框架、做好逻辑设计、用例设计、部署设计；这些都是减少软件缺陷的有力保障；
同时测试人员也因该了解概要设计并参与概要设计的评审;从系统测试的角度进行考虑并及早发现概要设计可能产生的缺陷；
3 、在软件的详细设计的时候，同样的要做好，用例设计、接口设计、权限设计，最后做好《软件详细设计规格说明书>>的评审.
和概要设计一样,测试人员也因该了解详细设计所选择的技术和实现方式并参与详细设计的评审；从集成测试的角度进行考虑并及早发现接口等原因可能产生的缺陷；
4 、在软件编码的阶段,编码人员应该按照编码规范进行编写,同时编码人员的技术水平和写代码的能力和选择的实现方法也决定了软件缺陷的多少,在这个环节开发项目经理对人员的分配和安排以及对代码的评审工作是在本阶段减少软件缺陷的又一重要环节;
同时测试组织的单元测试是减少因编码导致缺陷的一个重要的环节.因此做好单元测试计划选择合适的单元测试工具,实用适当的单元测试技巧可以降低软件缺陷;
需要说明的是测试计划、测试用例的好与坏虽然不能产生软件缺陷,但是好的测试计划和测试用例能够发现更多的软件缺陷；同时测试人员的测试技术水平和经验对发现更过的软件缺陷也是非常关键的；
以上是个人的拙见，希望大侠们多多指点和补充； 补充一些我的观点:
我看过一本书:<程序调试思想与实践>,里面有一些典型错误或者缺陷产生的原因分析,精确到代码级别.这本书很不错,推荐给大家看,不管是做测试还是开发.
不管什么行业,软件设计,开发中难的地方以及容易犯错误的地方对大家一样. 我们要做的是把原因找到或者借鉴别人的经验(<程序调试思想与实践>里有很多可以借鉴)避免以后重复犯错.
我曾经在一个ERP产品的项目中,曾参加过缺陷预防的活动. 当时大家只是收集统计了大概缺陷产生的范围以及有哪些类别的缺陷.感觉比较粗糙,不详细,效果不是很好. 现在我倒是有个提议: 工作中大家建立一个缺陷原因分析库, 里面还有补充借鉴别人或者书上的经验,里面缺陷原因的分析要到代码级别.另外测试人员加入的相关的test case或注释(就是通过哪个test case发现的,没有case的话, 是具体怎么测试出来的). 这个分析库, 对公司所有的项目都开放,也可以去完善. 对于开发人员经常学习,可以避免犯错; 对于测试人员,通过学习,可以设计出发现那些隐藏在系统中潜在的缺陷和bug的高质量的test case. 关于缺陷原因的分析我在工作中一直有意识的去主动总结.
欢迎大家指正或讨论! 常见缺陷分析技术：
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分析等），找出产生这些缺陷的技术上不足和流程上不足，通过对这些不足进行改进，防止类似缺陷再次发生。
[ 本帖最后由 天网 于 2008-6-17 14:37 编辑 ] 看了以上各位的回答，真是受益匪浅 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提高整个组织的实践经验。
[ 本帖最后由 fengyun32 于 2008-6-18 10:37 编辑 ]
