关于缺陷预防技术，楼上有很多总结得挺不错。这里就不再重复说了。
第一方面：制定有效地开发规范和流程。
如果没有一个规则，那么即使有测试人员，缺陷仍会存在。我们知道缺陷在需求和设计阶段是最多的，那么如何在这两个环节有效的控制，是很重要的。
现在我说说我们公司在这两个环节上的一些改进：（个人觉得效果不错）
1)成立用户代表组和专家组，由他们两个组进行1周的开会与演示，最会制定需求方案，并经过用户签字。
2)针对web的需求的获取：由专家组和策划设计组组成。专家组负责分析网上的很多系统的技术驾构及和我们所要开发的网站有什么好的地方值得吸取，设计组负责版面的架构，做到能吸引客户访问网站。（这个周期会长些，1个月的时间）经过两个小组共同设计出方案，然后放到公司的服务器上让很多人来提建议。而后定出最终的方案。
（呵呵，对于有异议的地方，我们通常中采取投票或问卷调查形式）
（经过以上的做法，可以预防需求的bug)
3))需求方案出来后，由技术总监和高级工程师一起制定最终的技术方案，看采用什么的技术来完成作品。（再这过程中由售前工程师提供一些技术方案作为参考，将系统的稳定性，扩展性，可移植性作为重点考察对象）这是改进的地方，以前主要由总工一人来写方案，这样的话个人主观性占很大的方面）
（时间大约2周，确定好后，就开始构建了）
4)然后就是开发工程师进行概要设计阶段（程序，数据库）
这块的话公司改进的地方是：
设计时，以小组为单位进行。以前就是一个人来设计。设计完成后虽然有评审，但是思路上还是扩展不开，现在就是有多套方案进行评审，以接近最终需求为目标，加上设计结构上扩展性和可靠性好。则选中它。
（改进后，时间比以前长了，但是效果不错，返工率低了）
5)进行详细设计阶段。（这块主要是通过单元测试和编码规范来把控的）
（因为以前公司做单元测试很简单，build一下无问题就OK，不是很正规）
以上主要是需求和设计阶段预防。（靠规则来约束）
第二方面：借助工具来管理测试。
效率高，而且利于与其它部门间的沟通。工具可以帮助你快速生成bug图表。帮助你来分析bug。
预防bug措施：
公司用TD来做管理，生成bug一些图表记录（密度图，龄期图，趋势图）,然后按优先级来整理这些bug。要求开发人员详细记录bug的原因。测试人员每周负责整理并归类，提交给测试主管。技术经理审核后，将一些问题加到开发规范中做为例子，每周五下午，开发人员和测试员共同学习开发规范，重点是看例子，时刻记住不要犯这样的错误。每周一汇报，每周一学习）呵呵，时间不长，但是收获很多，尤其是对于我们测试人员来说增长开发知识。
现在我们还将一些典型的bug做成小册子。要求新来的员工都看。:) 今天上午看到的资料，写上了和大家一起分享。并谢谢大家热心的回答，本人再次表示感谢！！
常用的统计分析工具：
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) 精彩。:)
我来说几句
前几天我们项目组为了参加公司2008年亚太地区技术论坛，考虑出一篇论文，有个同事就打算写类似的题目，但是我看过之后，发现她的文章还是仅仅停留在技术层面上的，也就是我们都知道的从类型 严重级别，状态等等去考虑，而我认为她的题目绝对是个好题目，但是不好写，因为缺陷分析真的要做好了，涉及的东西或者说知识很多，除了技术层面的外，还涉及到审计 概率 风险控制 数理统计等等多学科的知识请问一下版主天网，你写的那些缺陷分析方法的出处在哪？
能够问一下版主天网，你写的那些缺陷分析方法是在那本书中找到的吗？请回复一下，谢谢！！zhuzx
我很想详细学习一下缺陷分析的相关技术
我很想详细了解，并学习一下缺陷分析的相关技术 我晕~来晚了~没想到这问题都被人回答成这样了...不过没关系...我有创新有创新嘿嘿！！！！
首先，对于缺陷预防...我的第一个思路是...完全可以把软件产品干掉~没有软件就没有缺陷...嗯...彻底的防止了缺陷的发生...
大家先把手里的酒瓶放下...我不是来砸场子的...我还有第二个思路...:lol
嗯，那就是我们主动控制引导缺陷...也就是最好的防守就是进攻...让软件存在一部分缺陷，保证其他主要功能的质量...让产品刚好达到客户满意又能带来利润...哼哼...差不多就这意思吧...
最终，考虑结合第一种思路，彻底抛弃质量差的阵地...不过别最后一点都不剩就行...
其次，对于缺陷分析...9楼的那些图应该说已经很全面很好了...毕竟图表很直观...但是大家不要失望~我还是有创新有补充...
自动化执行用例，自动化计算出图表啥的供测试人员来分析...此方面LR，QTP等等都有这样的功能...就是目前缺陷分析技术充其量也就这样了.靠自动化工具也就能生成一些图表啥的最终还得靠人来分析...
不过~缺陷分析最重要的是搞清楚意图...也就是说缺陷分析是为了什么...
光有一大堆数字啊图表阿一点意义都没有嘛....
比如从缺陷分布图得知有的模块bug很多，我们可以向有关部门提出到底是为什么呢？是需求不明确还是开发有问题？还是我们对此投入的测试精力比较大导致发现的bug比较多？或者我们的技术存在薄弱环节？我们可以多派点人或者投入更多的精力来重点测一测呢？等等能够说明很多问题...
再比如根据缺陷趋势曲线，随着缺陷越来越少，是不是该考虑测试大军撤退小部分人留守呢？
但是有时候图表也不是很精确，在分析的时候得考虑一些人为或者意外的因素...那就具体情况具体分析了...
总体上来讲根据各种图表我们可以跟踪控制项目的进展、发现一些不足之处、总结一些经验教训...目的就是让过程和质量做得越来越好吧...
哎~下回早点来搅和搅和...
常用的软件缺陷预防技术和缺陷分析技术
软件缺陷预防技术：做好需求说明。我们测试的时候发现了一些BUG之后跟开发人员讨论，开发人员经常解释说“就是这样设计的”。这让人很郁闷。如果明确了需求说明，开发人员严格按照需求说明来写程序，这种解释为“就是这样设计的”BUG应该会少很多的。
再别的，制定编码规范等等之类。
缺陷分析技术：
这个我们还没有专门做过。就以前用EXCEL和缺陷数据库建立连接之后，把BUG信息导出来，自动生成分析图表，再自己分析总结。
（以上是我就一年多的软件测试工作情况对这两个问题的小小感受，没有什么技术含量。奋斗ing~~）
回复 25# 的帖子
没看到哪本书专门写这些分析技术，但会有些书涉及到其中某个方法。可以上网或者图书馆查些资料看看。 楼主自己出题，自己又回答，这么搞叫偶们如何参与？好的命题者应该是引导，而不应该是大篇幅的长篇累牍的自问自答。
[ 本帖最后由 huior 于 2008-6-19 13:47 编辑 ] 很强大，很厉害，真是受益匪浅啊!
30楼主，huior可能是误会了
huior您好，也许是您误会了，首先向版主申明，我不参加抽奖。我出这个题目的用意：就是想在我现有的基础上，给我一些新思想的启发和提示，找出一些好的创新的idea。同时，我也很欣赏，huior讲的“引导”型的出题方式，本人一定虚心接受，并深表歉意，谢谢！！
楼主要展开自我批评阿
:lol :lol楼主其实已经说的很全了，没给吾等留什么机会呀~~
所以要展开自我批评~~~~~~~~~:lol :lol
我也谈了一下我的看法
虽然楼主说得已经很完美了，不过我想这个问题是非常大非常广的，偶也谈谈自己的看法。在此奉上答案：
http://www.51testing.com/?1592/action_viewspace_itemid_85427.html
欢迎批评指正~~~~探讨交流 大方向大家都说的已经很全很了，下面偶就来点具体的，看看具体如何实施错误预防。下面的描述参考了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 产生最大效益，必须向整个团队提供必需的技术、体系和培训，正确并始终如一地执行错误预防实践。
缺陷分析，我没什么补充的 好精彩啊
我只知道,测试应尽早介入,要学习的地方实在太多太多拉 以后我也要常来泡泡
好好向大家学习 原帖由 vivian2008 于 2008-6-16 11:38 发表 http://bbs.51testing.com/images/common/back.gif
首先,要先知道什么是缺陷,缺陷既指静态存在于软件工作产品(文档、代码)中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。从定义可以看出什么情况下会容易产生缺陷，一般性测试越早进 ...
太过理论化，呵呵
不知道是不是测试做久了，就喜欢挑刺
实际项目中，请问你有多少时间来做这些
其实这个问题本来就是理论化的问题，我不否认楼上楼下说得都有道理
我觉得缺陷预防的技术及分析缺陷的技术再多，但不用到你的实际工作场景中，再好的技术也只是镜中花，水中月，看得见摸不着
有时候我觉得测试者的经验可能是另一种有效的预防缺陷的措施
还有就是开发人员的负责精神，一个负责的开发人员会对自己写好的模块作个小小的测试，可能都不是单元测试，仅仅只是看有没有完成要实现的功能，
这就已经很好的预防了基本的缺陷
我不是说没有软件缺陷预防技术和缺陷分析技术，^_^，我只是想表达学以致用以及与开发人员很好的配合才能更好的避免缺陷 管理经验+流程+管理工具+思想+讨论 看了上面好多介绍，确实全，但是真正能实用，应用项目有多少，以下是我做测试管理目前采用的一些方法：
一 缺陷分析技术：
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 编辑 ]
