51Testing软件测试论坛

标题: 常用软件缺陷预防技术和缺陷分析技术有哪些？（08-06-13）（获奖名单已公布） [打印本页]

作者: 51testing 时间: 2008-6-13 18:09
标题: 常用软件缺陷预防技术和缺陷分析技术有哪些？（08-06-13）（获奖名单已公布）
请介绍常用软件缺陷预防技术和缺陷分析技术有哪些？希望在常用方法上提出一些新的观点或自己独到的观点？

感谢会员zhuzx提供此精彩问题！如果你也有问题想提出来和大家一起讨论，请点击此处>>
说不定下期讨论的问题就是由你提出的哦，请快快参与吧！

非常感谢各位会员积极参与，截止至6月20日17：30分，从该贴所有评论中选出部分作出精彩评论的会员予以奖励。礼品和积分将在下周内送出。

获奖名单
奖项	获奖名单	奖励	答案链接
一等奖	天网	当当购物卡50元	18#
二等奖	fengyun32	300论坛积分	20#
二等奖	fmsbai5	300论坛积分	35#
三等奖	sunwenjuan	100论坛积分	8#
	tiantian010		16#
	卖烧烤的鱼		40#

作者: hehekouke 时间: 2008-6-14 14:21
沙发……

非常想知道……

作者: andyyoung 时间: 2008-6-15 00:21
痴痴地等着你的回答……

作者: 贱王之王 时间: 2008-6-16 08:53
学习，学习.......happy

作者: pepper 时间: 2008-6-16 10:04
标题: 是哪位高人，能够提出这么高深的问题？？
版主，是哪位高人提出的这个高深的问题？？
我做了3、4年的测试，也算是公司的一个小Leader了，面试了很多公司几乎都没有人问到我这样的问题？并且对这样的问题，回答起来也很棘手呀。也许是面试测试经理的吧！！
是哪位高人出的这道题目，能否把您当时的答案回答给我们听听，让我们也增长见识，谢谢哈！！

作者: vandagroup 时间: 2008-6-16 10:34
标题: 同意楼上的观点
同意楼上的观点，希望出题的同行朋友看到我们这么多帖子以后，给给你的答案吧，我们都期望好久了。

到时候，我们推举您是最最受欢迎的问题怎样？？哈哈！！

作者: vivian2008 时间: 2008-6-16 11:38
标题: 常见软件缺陷预防技术和缺陷分析技术有哪些？
首先,要先知道什么是缺陷,缺陷既指静态存在于软件工作产品(文档、代码)中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。从定义可以看出什么情况下会容易产生缺陷，一般性测试越早进行越好，主要是越早测试越容易发现致使的缺陷，也能够减少成本。由些，可以看出最好的预防缺陷的方法是在开发人员着手写代码的时候，我们的单元测试也同步进行。
   缺陷的分析技术包括：
   1、缺陷分布图：可按属性分布——模块、提交人、严重级别（一般、严重等）、引入阶段（SRS、HLD、LLD）、类型（功能、性能、GUI等）。
   2、缺陷趋势图：也可叫发展趋向，一个版本内工作量一致的情况下的发展趋向。
   3、缺陷龄期图
   这些缺陷图可以在Mercury QualityCenter（QC）的Defects模块里可以设置看到。
   以上是我个人的愚见，还请大家多多指教。

作者: sunwenjuan 时间: 2008-6-16 12:28
就缺陷预防，我觉得主要有两点
   一个是项目过程中的预防，主要借助于评审，在需求、设计完成之后进行严格有效的评审，并做原因分析，这样可以很好的避免需求和设计阶段的缺陷遗留到后期，无限扩大缺陷修复成本，评审完成之后，跟踪评审缺陷直至关闭；其次是变更管理、配置管理。编码阶段完成之后的单元测试，以及后边的各个阶段的测试，这个自然不必多说。
   两外一个因为缺陷分析需要大量的缺陷信息，所以要形成缺陷库，长期积累分析指标数据，才可以对以后的缺陷预防起到知道意义

缺陷的分析，我觉得主要从以下几个方面去考虑
事物都是有两面性的，所以进行分析也要进行两方面分析，一般在分析缺陷之前，我们首先会关注缺陷的数量（其实缺陷的数量并不能说明软件质量）
发现的缺陷比较少时，就要分析到底是被测对象的质量高，还是测试方法有问题，测试范围是否完全覆盖到了，测试用例设计的是否不够等等总之要保证测试的有效性；
发现大量的缺陷，就要分析这些缺陷所在的模块，缺陷的类型，缺陷趋势等
1、缺陷所在的模块，我记得曾经说过80%的缺陷存在于20%的模块中，通过缺陷所在模块可以分析出哪些模块不稳定，接下来就要对这些不稳定模块着重测试。另外还要关注缺陷是由需求变更引起的还是缺陷修复引起的。
2、缺陷的类型，有时发现的缺陷大部分都是严重级别比较低的缺陷（例如界面、提示信息等），而功能方面的却比较少，它就有两种可能，一种是这个系统经过测试证明系统是比较稳定的，质量是比较高的；另一种是我们测试的时候，功能部分关注的不充分，有遗漏。
3、缺陷趋势，从缺陷趋势中，可以了解到缺陷的收敛是否正常，还是在无限制扩大，如果是无限制扩大就要采取相应的措施，观察缺陷趋势，还可以了解到软件之来那个再什么时候已经得到了很好的控制，也可以为是否可以停止测试工作做一个指导。
  另外在软件测试过程当中会出现缺陷重复的情况，就要分析缺陷重复的原因在哪里了（我遇见的比较多的就是版本出了问题）

在缺陷分析过程中也有很多指标，例如有缺陷密度、缺陷的修复率、缺陷的平均修复时间、返工的工作量、测试用例的有效性等等，比较常用的应该有这些（暂时也就能想到这些^_^）

我在工作中基本上用到的差不多就这些吧，可能还有遗漏的，写的也可能比较片面，有不当之处，还请多多指教

作者: zhuzx 时间: 2008-6-16 12:35
标题: 谢谢大家对这个问题的关心，我当时回答的大致内容
不好意思，由于大部分内容涉及到我的毕业论文，暂时修改一下，忘理解。

[ 本帖最后由 zhuzx 于 2008-11-15 21:46 编辑 ]

作者: yao123456 时间: 2008-6-16 15:11
标题: 不愧为测试经理
不愧为测试经理呀？您已经总结的比较好了，向您学习学习！！
并希望您以后，天天上51testing答题，给我们更多的学习机会。

如果愿意，很想交个朋友yaoyao@163.com，我的邮箱。

作者: vandagroup 时间: 2008-6-16 17:08
标题: 大家回答得都很棒
大家辛苦了，回答得都很棒，学到了不少东西！！希望高手继续回答，呵呵！！

作者: lshy1113 时间: 2008-6-16 19:12
标题: 缺陷预防技术和缺陷分析技术
很赞同9楼的观点，很详细很透彻！

“常用方法上提出一些新的观点或自己独到的观点”，我就针对缺陷预防技术谈谈自己两点不同的看法：
1、行业背景及用户使用的特点
当拿到××行业的项目单子时，我们不仅仅局限于从客户获取需求，还要发掘该行业的隐性需求。如替税务局开发一个项目，不仅考虑跟税务相关业务，可能还要考虑法律、发规等行业背景。
以前有使用过系统的用户，对于新系统开发，是特别挑剔的。所以在开发系统时，我们需要抽取时间来关注前系统，了解用户的操作和使用习惯。
2、采用外包模式
一般来说，每个公司都有自己的薄弱地方，如有些公司，可能在需求做得很差，不妨考虑将需求外包。既可以得到一份质量较高的需求，从而在前期减少缺陷的产生，又可以加快项目进度，何乐而不为呢。

[ 本帖最后由 lshy1113 于 2008-6-16 19:13 编辑 ]

作者: godn_1981 时间: 2008-6-16 22:40
标题: 这个问题很有挑战，我喜欢
嘿嘿，这个问题真好，很有深度，有难度，我觉得大家不要泛泛而谈，拿出一些可执行性比较强的方案。

作者: nicole830 时间: 2008-6-17 10:44
标题: 获益匪浅
这个模块开展的真好。前辈们的回答也很精彩，真是让我获益匪浅。眼前一亮啊。。
希望大家以后对我这个后辈多多给予指导哦。

作者: vandagroup 时间: 2008-6-17 11:05
标题: 希望大家以后把软件测试工程师入职面试题目拿来讨论
希望大家以后把软件测试工程师入职面试题目拿来讨论，让大家共同进步，共同提高！！

同意13楼观点，拿出一些“可执行性比较强”的方案。

作者: tiantian010 时间: 2008-6-17 12:32
同意9楼的意见:
对于缺陷预防:
我主要从生命周期和部门间的沟通方面来阐述一下个人观点;
对于软件开发周期来说，控制环节越早对于降低和预防软件缺陷的效果越明显;软件测试也同样的应该尽早的介入,在项目启动之时,就开始准备。
1 、在需求设计阶段，做好评审工作和需求确认工作是较少软件缺陷的关键；
在这个阶段开发部门和测试部门之间以及和用户之间对于需求的沟通是致关重要的，它可以减少后期由于开发人员、测试人员和用户对需求理解歧义而引发的缺陷；
2 、在软件概要设计的时候，应该做好规划，搭好框架、做好逻辑设计、用例设计、部署设计；这些都是减少软件缺陷的有力保障；
同时测试人员也因该了解概要设计并参与概要设计的评审;从系统测试的角度进行考虑并及早发现概要设计可能产生的缺陷；
3 、在软件的详细设计的时候，同样的要做好，用例设计、接口设计、权限设计，最后做好《软件详细设计规格说明书>>的评审.
和概要设计一样,测试人员也因该了解详细设计所选择的技术和实现方式并参与详细设计的评审；从集成测试的角度进行考虑并及早发现接口等原因可能产生的缺陷；
4 、在软件编码的阶段,编码人员应该按照编码规范进行编写,同时编码人员的技术水平和写代码的能力和选择的实现方法也决定了软件缺陷的多少,在这个环节开发项目经理对人员的分配和安排以及对代码的评审工作是在本阶段减少软件缺陷的又一重要环节;
同时测试组织的单元测试是减少因编码导致缺陷的一个重要的环节.因此做好单元测试计划选择合适的单元测试工具,实用适当的单元测试技巧可以降低软件缺陷;
需要说明的是测试计划、测试用例的好与坏虽然不能产生软件缺陷,但是好的测试计划和测试用例能够发现更多的软件缺陷；同时测试人员的测试技术水平和经验对发现更过的软件缺陷也是非常关键的；
以上是个人的拙见，希望大侠们多多指点和补充；

作者: stevenremember 时间: 2008-6-17 12:53
补充一些我的观点:
我看过一本书:<程序调试思想与实践>,里面有一些典型错误或者缺陷产生的原因分析,精确到代码级别.这本书很不错,推荐给大家看,不管是做测试还是开发.

不管什么行业,软件设计,开发中难的地方以及容易犯错误的地方对大家一样. 我们要做的是把原因找到或者借鉴别人的经验(<程序调试思想与实践>里有很多可以借鉴)避免以后重复犯错.

我曾经在一个ERP产品的项目中,曾参加过缺陷预防的活动. 当时大家只是收集统计了大概缺陷产生的范围以及有哪些类别的缺陷.感觉比较粗糙,不详细,效果不是很好. 现在我倒是有个提议: 工作中大家建立一个缺陷原因分析库, 里面还有补充借鉴别人或者书上的经验,里面缺陷原因的分析要到代码级别.另外测试人员加入的相关的test case或注释(就是通过哪个test case发现的,没有case的话, 是具体怎么测试出来的). 这个分析库, 对公司所有的项目都开放,也可以去完善. 对于开发人员经常学习,可以避免犯错; 对于测试人员,通过学习,可以设计出发现那些隐藏在系统中潜在的缺陷和bug的高质量的test case. 关于缺陷原因的分析我在工作中一直有意识的去主动总结.

欢迎大家指正或讨论!

作者: 天网 时间: 2008-6-17 13:44
常见缺陷分析技术：
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 编辑 ]

作者: sunwenjuan 时间: 2008-6-17 16:36
看了以上各位的回答，真是受益匪浅

作者: fengyun32 时间: 2008-6-18 10:35
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 编辑 ]

作者: marysnow 时间: 2008-6-18 12:43
同意楼上的说法。说说自己的想法。
关于缺陷预防技术，楼上有很多总结得挺不错。这里就不再重复说了。

第一方面：制定有效地开发规范和流程。
如果没有一个规则，那么即使有测试人员，缺陷仍会存在。我们知道缺陷在需求和设计阶段是最多的，那么如何在这两个环节有效的控制，是很重要的。
现在我说说我们公司在这两个环节上的一些改进：（个人觉得效果不错）
1) 成立用户代表组和专家组，由他们两个组进行1周的开会与演示，最会制定需求方案，并经过用户签字。
2)针对web的需求的获取：由专家组和策划设计组组成。专家组负责分析网上的很多系统的技术驾构及和我们所要开发的网站有什么好的地方值得吸取，设计组负责版面的架构，做到能吸引客户访问网站。（这个周期会长些，1个月的时间）经过两个小组共同设计出方案，然后放到公司的服务器上让很多人来提建议。而后定出最终的方案。
（呵呵，对于有异议的地方，我们通常中采取投票或问卷调查形式）
（经过以上的做法，可以预防需求的bug)

3))需求方案出来后，由技术总监和高级工程师一起制定最终的技术方案，看采用什么的技术来完成作品。（再这过程中由售前工程师提供一些技术方案作为参考，将系统的稳定性，扩展性，可移植性作为重点考察对象）这是改进的地方，以前主要由总工一人来写方案，这样的话个人主观性占很大的方面）
（时间大约2周，确定好后，就开始构建了）

4)然后就是开发工程师进行概要设计阶段（程序，数据库）
这块的话公司改进的地方是：
设计时，以小组为单位进行。以前就是一个人来设计。设计完成后虽然有评审，但是思路上还是扩展不开，现在就是有多套方案进行评审，以接近最终需求为目标，加上设计结构上扩展性和可靠性好。则选中它。
（改进后，时间比以前长了，但是效果不错，返工率低了）

5)进行详细设计阶段。（这块主要是通过单元测试和编码规范来把控的）
（因为以前公司做单元测试很简单，build一下无问题就OK，不是很正规）

以上主要是需求和设计阶段预防。（靠规则来约束）

第二方面：借助工具来管理测试。
效率高，而且利于与其它部门间的沟通。工具可以帮助你快速生成bug图表。帮助你来分析bug。
预防bug措施：
公司用TD来做管理，生成bug一些图表记录（密度图，龄期图，趋势图）,然后按优先级来整理这些bug。要求开发人员详细记录bug的原因。测试人员每周负责整理并归类，提交给测试主管。技术经理审核后，将一些问题加到开发规范中做为例子，每周五下午，开发人员和测试员共同学习开发规范，重点是看例子，时刻记住不要犯这样的错误。每周一汇报，每周一学习）呵呵，时间不长，但是收获很多，尤其是对于我们测试人员来说增长开发知识。
现在我们还将一些典型的bug做成小册子。要求新来的员工都看。

作者: zhuzx 时间: 2008-6-18 12:45
今天上午看到的资料，写上了和大家一起分享。并谢谢大家热心的回答，本人再次表示感谢！！

常用的统计分析工具：
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)

作者: tingtingc 时间: 2008-6-18 13:28
精彩。

作者: red-hat 时间: 2008-6-18 15:35
标题: 我来说几句
前几天我们项目组为了参加公司2008年亚太地区技术论坛，考虑出一篇论文，有个同事就打算写类似的题目，但是我看过之后，发现她的文章还是仅仅停留在技术层面上的，也就是我们都知道的从类型严重级别，状态等等去考虑，而我认为她的题目绝对是个好题目，但是不好写，因为缺陷分析真的要做好了，涉及的东西或者说知识很多，除了技术层面的外，还涉及到审计概率风险控制数理统计等等多学科的知识

作者: zhuzx 时间: 2008-6-18 16:43
标题: 请问一下版主天网，你写的那些缺陷分析方法的出处在哪？
能够问一下版主天网，你写的那些缺陷分析方法是在那本书中找到的吗？请回复一下，谢谢！！

zhuzx

作者: zhuzx 时间: 2008-6-18 16:47
标题: 我很想详细学习一下缺陷分析的相关技术
我很想详细了解，并学习一下缺陷分析的相关技术

作者: dabeixiong 时间: 2008-6-18 17:58
我晕~来晚了~没想到这问题都被人回答成这样了...
不过没关系...我有创新有创新嘿嘿！！！！
首先，对于缺陷预防...我的第一个思路是...完全可以把软件产品干掉~没有软件就没有缺陷...嗯...彻底的防止了缺陷的发生...
大家先把手里的酒瓶放下...我不是来砸场子的...我还有第二个思路...

嗯，那就是我们主动控制引导缺陷...也就是最好的防守就是进攻...让软件存在一部分缺陷，保证其他主要功能的质量...让产品刚好达到客户满意又能带来利润...哼哼...差不多就这意思吧...
最终，考虑结合第一种思路，彻底抛弃质量差的阵地...不过别最后一点都不剩就行...
其次，对于缺陷分析...9楼的那些图应该说已经很全面很好了...毕竟图表很直观...但是大家不要失望~我还是有创新有补充...
自动化执行用例，自动化计算出图表啥的供测试人员来分析...此方面LR，QTP等等都有这样的功能...就是目前缺陷分析技术充其量也就这样了.靠自动化工具也就能生成一些图表啥的最终还得靠人来分析...
不过~缺陷分析最重要的是搞清楚意图...也就是说缺陷分析是为了什么...
光有一大堆数字啊图表阿一点意义都没有嘛....
比如从缺陷分布图得知有的模块bug很多，我们可以向有关部门提出到底是为什么呢？是需求不明确还是开发有问题？还是我们对此投入的测试精力比较大导致发现的bug比较多？或者我们的技术存在薄弱环节？我们可以多派点人或者投入更多的精力来重点测一测呢？等等能够说明很多问题...
再比如根据缺陷趋势曲线，随着缺陷越来越少，是不是该考虑测试大军撤退小部分人留守呢？
但是有时候图表也不是很精确，在分析的时候得考虑一些人为或者意外的因素...那就具体情况具体分析了...
总体上来讲根据各种图表我们可以跟踪控制项目的进展、发现一些不足之处、总结一些经验教训...目的就是让过程和质量做得越来越好吧...
哎~下回早点来搅和搅和...

作者: scym578 时间: 2008-6-18 20:50
标题: 常用的软件缺陷预防技术和缺陷分析技术
软件缺陷预防技术：
做好需求说明。我们测试的时候发现了一些BUG之后跟开发人员讨论，开发人员经常解释说“就是这样设计的”。这让人很郁闷。如果明确了需求说明，开发人员严格按照需求说明来写程序，这种解释为“就是这样设计的”BUG应该会少很多的。
再别的，制定编码规范等等之类。

缺陷分析技术：
这个我们还没有专门做过。就以前用EXCEL和缺陷数据库建立连接之后，把BUG信息导出来，自动生成分析图表，再自己分析总结。

（以上是我就一年多的软件测试工作情况对这两个问题的小小感受，没有什么技术含量。奋斗ing~~）

作者: 天网 时间: 2008-6-18 23:55
标题: 回复 25# 的帖子
没看到哪本书专门写这些分析技术，但会有些书涉及到其中某个方法。可以上网或者图书馆查些资料看看。

作者: huior 时间: 2008-6-19 09:43
楼主自己出题，自己又回答，这么搞叫偶们如何参与？
好的命题者应该是引导，而不应该是大篇幅的长篇累牍的自问自答。

[ 本帖最后由 huior 于 2008-6-19 13:47 编辑 ]

作者: bzfyhfyh 时间: 2008-6-19 10:27
很强大，很厉害，真是受益匪浅啊!

作者: zhuzx 时间: 2008-6-19 11:58
标题: 30楼主，huior可能是误会了
huior您好，也许是您误会了，首先向版主申明，我不参加抽奖。我出这个题目的用意：就是想在我现有的基础上，给我一些新思想的启发和提示，找出一些好的创新的idea。

同时，我也很欣赏，huior讲的“引导”型的出题方式，本人一定虚心接受，并深表歉意，谢谢！！

作者: godn_1981 时间: 2008-6-19 18:43
标题: 楼主要展开自我批评阿

楼主其实已经说的很全了，没给吾等留什么机会呀~~
所以要展开自我批评~~~~~~~~~

作者: godn_1981 时间: 2008-6-20 00:15
标题: 我也谈了一下我的看法
虽然楼主说得已经很完美了，不过我想这个问题是非常大非常广的，偶也谈谈自己的看法。
在此奉上答案：
http://www.51testing.com/?1592/action_viewspace_itemid_85427.html
欢迎批评指正~~~~探讨交流

作者: huior 时间: 2008-6-20 09:59
大方向大家都说的已经很全很了，下面偶就来点具体的，看看具体如何实施错误预防。下面的描述参考了Parasoft 的理论。

自动错误预防（AEP）

AEP Methodology 是一种改进软件质量、提高软件开发生命周期效率的新方法。它基于 AEP 概念，此概念的核心，在于从自身及其它人的错误中吸取教训，然后将学到的东西应用到软件生命周期中，使软件成功运行。AEP 概念提倡以下五个特定过程的自动化，可以把这五个过程组合起来，以改进生产流程、并预防错误：
1. 识别错误。
2. 找到错误原因。
3. 定位产品产生错误的地方。
4. 修改现有的实践（或者添加一些新的）、以确保相同的错误不再出现。
5. 监视流程。
至于如何应用 AEP 概念的例子，请想象您有一个n层的系统，包括客户机、用 Java 编写的中间件、以及数据库。假定负载测试显示系统由于负载过重而停止了工作。在经过详细分析之后，您发现资料从开放式连接泄漏到了数据库中。通常，您只需修改代码以关闭连接。不过，如果您要从 AEP 的角度来解决此问题，则还应设法确定如何预防错误再次出现。在将问题单独处理为开放式连接之后，您可以确定流程中出现错误的原因，在于某个开发人员编写代码打开了连接、但没有关闭该连接。然后，您可能会设法采取一项措施，以确保编写的打开连接代码中始终伴随有关闭该连接的代码，从而避免再次出现此类错误。
实现此措施的一种方法，在于建立一条 Java 代码规范，要求每个打开连接的类必须有一个finalize ( ) 方法，使用finally块来关闭连接。如果代码遵循此规则，那么错误就不会再次出现。但您如何能实施该项措施呢？您可以通过让团队进行代码复审来实施该项措施。不过，这缺乏效率，因为团队需要人工审查和分析所有的代码，以确定是否所有连接都已关闭。更有效率的策略，是将产品整合到流程中，该产品会自动检查代码规范，然后让该产品分析您的代码，自动识别违反此代码规范的情况。
这就是 AEP 概念所蕴含的原理。您在负载测试期间发现一条错误，然后将来自于 Java 中间件内开放式连接的错误源码，作为资料泄露单独处理出来。您发现 Java 代码缺少finally块和finalize ( ) 方法，于是定义了一个代码规范，规定将来应该如何编写代码，并使流程自动化，以确保遵循此项标准。通过此方式，可以预防所有这一类的性能问题。

AEP Methodology 有五条主要原则，该方法提供了一个经过良好测试的蓝图，用以在团队环境中实现五步AEP概念：
1. 应用行业最佳实践来防止普遍错误，并建立全寿命周期的错误预防基础。
2. 按需修改的方法，以预防特殊的错误。
3. 确保每个小组都能正确并始终如一地执行 AEP。
a. 按小组逐个引入 AEP。
b. 确保每个组都有一个合适的支持体系。
c. 建立小组的工作流程，以确保错误预防被恰当地执行。
4. 循序渐进地采用每一个实践。
5. 利用统计来稳定每一个过程，让它发挥价值。
为让 AEP 产生最大效益，必须向整个团队提供必需的技术、体系和培训，正确并始终如一地执行错误预防实践。

缺陷分析，我没什么补充的

作者: 植树贝贝 时间: 2008-6-20 10:15
好精彩啊
我只知道,测试应尽早介入,要学习的地方实在太多太多拉

作者: 植树贝贝 时间: 2008-6-20 10:18
以后我也要常来泡泡
好好向大家学习

作者: 博一笑 时间: 2008-6-20 14:28

原帖由 vivian2008 于 2008-6-16 11:38 发表
首先,要先知道什么是缺陷,缺陷既指静态存在于软件工作产品(文档、代码)中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。从定义可以看出什么情况下会容易产生缺陷，一般性测试越早进 ...

太过理论化，呵呵
不知道是不是测试做久了，就喜欢挑刺
实际项目中，请问你有多少时间来做这些
其实这个问题本来就是理论化的问题，我不否认楼上楼下说得都有道理
我觉得缺陷预防的技术及分析缺陷的技术再多，但不用到你的实际工作场景中，再好的技术也只是镜中花，水中月，看得见摸不着
有时候我觉得测试者的经验可能是另一种有效的预防缺陷的措施
还有就是开发人员的负责精神，一个负责的开发人员会对自己写好的模块作个小小的测试，可能都不是单元测试，仅仅只是看有没有完成要实现的功能，
这就已经很好的预防了基本的缺陷
我不是说没有软件缺陷预防技术和缺陷分析技术，^_^，我只是想表达学以致用以及与开发人员很好的配合才能更好的避免缺陷

作者: 杀手太冷 时间: 2008-6-20 15:22
管理经验+流程+管理工具+思想+讨论

作者: 卖烧烤的鱼 时间: 2008-6-20 16:33
看了上面好多介绍，确实全，但是真正能实用，应用项目有多少，以下是我做测试管理目前采用的一些方法：

一缺陷分析技术：
1 利用缺陷来源和发现阶段矩阵分析：缺陷来源和发现阶段，构造矩阵，跟踪软件开发各环节，目的是找到项目中最需要改进的环节，当然是缺陷数量和严重性比较多的地方；
2 利用缺陷分布在项目模块分析：将产品化分为各模块，分析具体模块的数据，找出影响产生质量关键的模块；
3 利用缺陷分类来进行缺陷的根源分析, 对于测试出来的BUG进行缺陷分类，按照缺陷的类型分布，找出那些关键的缺陷类型，分析其产生的根源；
举个例子：
以前公司项目利用此方法分析，系统中问题多产生在”接口“原因造成，最后我和经理与相关人员沟通确定”接口评审策略“，“接口变更策略”，“接口文档编写CheckList”等，从哪以后项目接口问题减少了很多！
所以缺陷分析应是这样去做，发现具体的原因，需要制定相应的流程改进，这才是我们真正需要的！
4缺陷趋势报告:按各种状态将缺陷计数作为时间的函数显示，如缺陷数量在整个测试周期的时间分布，此方法比较实用于项目测试过程中或是回归测试中
5 缺陷年龄分析：缺陷活动状态的时间，分析一个缺陷处于某种状态的时间，了解处理这些缺陷的进度情况，通常情况我是结合缺陷严重性一起分析，因为我上面的技术总监更为关心的项目中存在多少严重问题，是否可以上线；
6 借用缺陷工具分析，推荐像TestDiretor,JIRA等工具

二缺陷预防技术
1 与项目中相关人员达到共同“认识”，什么是缺陷？常见的缺陷有哪些？缺陷的危害,也许有人会问为什么将些列举在最前面，因为假如你的团队工作人员对缺陷都没一个清醒的认识，你认为预防二字如何谈起？
2 缺陷预防应从软件生命周期开如，一个字“早”，测试应早介入，当然从需求->构架->设计->编码->测试等环节入手，渗入不同的测试方法和技术
3 借用对已有缺陷进行分析，例如我上面的介绍的项目“接口”缺陷很多的问题，最后分析通过改进流程及方法，最终将缺陷减少了许多
4 最后特别注意一点，缺陷预防应采用好的工具收集数据分析，如Bug管理工具，需求管理工具，变更管理工具，只有有效的数据，才能真实的度量出我们的项目真正的本质，只有这样才能有可信只处^_^

欢迎访问我的博客:卖烧烤的鱼测试博客探讨软件测试软件测试架构测试流程测试过程改进测试管理需求管理缺陷管理配置管理项目管理性能测试安全性测试可用性测试可靠性测试 LoadRunner 易用性测试敏捷测试快速测试软件质量保证质量度量
http://mayingbao.cnblogs.com

[ 本帖最后由卖烧烤的鱼于 2008-6-20 16:36 编辑 ]

作者: sun_0910 时间: 2008-6-24 15:26
标题: 唉，遗憾颁奖了就没有人回答了吗？
唉，遗憾颁奖了就没有人回答了吗？我还想看看创新的呢？？

作者: 思渝 时间: 2008-9-11 12:38
标题: 这个题目很有挑战性

原帖由 zhuzx 于 2008-6-16 12:35 发表
不好意思，这个时候才上来看看。
首先，谢谢版主把这个问题拿出来讨论。这是我面谈一家公司的测试经理的时候，总监和老总问我的问题，确实比较难回答，没有固定的标准答案。幸好当时我有一些准备，看了这方面的资料 ...

这个题目很有挑战性，很好！！！

作者: xxlxyh 时间: 2009-12-7 10:20
高手太多了，学习中。。。。。。

作者: Carina_yan 时间: 2009-12-31 15:49
标题: 回复 20# 的帖子
说得太好了，对你的敬意有如涛涛江水~~

作者: roger_ge 时间: 2010-7-2 13:49
鄙人曾经写过一篇博文，题为《基于缺陷数据的度量与分析》，文中也涉及到了缺陷分析技术的实际应用例子，文章地址为http://blog.csdn.net/roger_ge/archive/2010/02/25/5327331.aspx

作者: leonazsy 时间: 2010-8-15 16:37
学习了，有很多点可以应用于实际工作中!

作者: tcltest 时间: 2011-10-13 19:20
学习

欢迎光临 51Testing软件测试论坛 (http://bbs.51testing.com/)