引言
"BUG有价值吗？“
笔者曾多次这样提问求职者。毫无例外的每个求职者都会给出肯定回答。可如果接着问：
“有什么价值呢？”
“你曾经做过什么事情来利用bug库中的bug呢？”
“项目结束后的总结工作中，是否对bug做过详细的总结和分析呢？如果有，是怎么做的呢？”
“听说过缺陷预防吗？或者了解缺陷预防具体是做什么工作吗？”
十之八九的人没有给出令人满意的回答。
补充：
1、笔者提问这类面试题是基于团队需要。这类面试题不适用于作为硬性考察指标，没有相关经历不代表测试能力不足。若有面试官读到本文，请谨慎选择。
2、本文按照5W1H的方式排版，读者可根据自身情况进行阅读。
缺陷分析现状
目前我们测试人员是如何利用缺陷呢？
目前多数中小型企业对于缺陷的控制和管理处于一种混乱的状态,对测试前期的设计和后期的缺陷数据统计分析的重视程度严重不足。
一种典型的情况就是测试人员在将bug提交后，仅做bug的修复验证，而没有进一步的工作。
也有一些公司的测试人员，会在《测试报告》中对bug做一些数据统计，以此评估当前软件的质量状况，并作为判定软件是否能发布或交付的依据。可能会再提一提由bug所反映出来的问题，但也止步于此，没有进一步的工作。
只有极少数的公司会做一些bug的分析工作，通过bug分析来改进产品质量、优化研发流程和项目管理方式。很多时候项目开发周期难以控制，原因之一就是缺乏缺陷数据的统计与分析,及缺陷的预防机制。
现在市场上有很多缺陷管理系工具，不过这些缺陷管理工具在特性上基本上都大同小异，对于缺陷的分类方法没有一个统一的标准，并且在缺陷分析方面普遍比较薄弱，通常只是提供一些缺陷数量的简单统计功能，用户不得不借助一些其它的统计分析软件或自行开发缺陷分析工具来进行缺陷数据的分析。
什么是缺陷分析？
讨论这个问题，首先要明确什么是缺陷？
通常意义上的缺陷：程序中存在的错误，俗称bug。
广义上的缺陷：项目计划、需求规格说明书、设计文档、测试用例、用户手册等存在的错误或问题。可以说在软件工程整个生命周期中，任何导致无法满足用户所要求的的功能活导致系统失败的问题都都属于缺陷的范畴。
再说说什么是缺陷分析？
通常意义上的缺陷分析包含两个阶段：一是发现bug后进行bug定位和排查原因的活动；二是系统测试结束前后对软件开发各个阶段产生的缺陷进行分类、分析和汇总统计，改进缺陷度量和分析的模型，编写分析报告的活动。这个活动中可能会伴随着其他活动，比如输出缺陷预防的方案。毕竟我们做分析的最终目的是为了提高产品质量和优化项目管理流程。
广义上的缺陷分析：对应“广义缺陷”的定义，对项目开发的整个生命周期中出现的各类问题（不局限于bug）进行分类和分析，进而改进项目管理过程的活动。
为什么要做缺陷分析？
广义上的缺陷分析比较复杂，本文只讨论通常意义上的缺陷分析。
发现bug后进行缺陷分析可以帮助我们：
排查是否有遗漏的同类缺陷：比如我们发现某个bug产生的根源是因为开发修改了某个接口，我们会推测其他调用该接口的模块可能也存在风险。这种情况我们就可以更好的保障测试范围没有遗漏。
验证代码逻辑的合理性：开发人员水平参差不齐，对于同一个功能可能有多种实现方式，年轻的程序员非常可能选择较差的实现方式，他们的修复可能不但更复杂，也可能会引入新的bug。而有经验的测试员可以指导程序员更简单高效的方式。这个过程中的分析经历，无论是对测试员还是程序员都是一种经验的积累。
有助于确定开发人员是否真正修复了bug。如果不了解bug产生的原因，很多时候测试人员无法确定bug是否被正确修复。笔者多次遇到这种情况，有N种情况都可能导致bug的出现但程序员只修复了其中一种情况；有时候对于一些偶发性的bug，如果不清楚原因，就很可能无法设计出正确的测试方式，进而导致不能保证bug被真正修复（这种情况中，程序员没有提交本地的修复代码到主干，测试人员可能都不清楚）。
改善缺陷分类。通过缺陷分析结果的反馈，改进缺陷度量分类标准和分析目标，提高缺陷分析结果的准确性。
有助于项目结束后的分析。出现时bug不做分析，项目结束后想做分析可能都做不到了。
系统测试结束前后的缺陷分析可能帮助我们：
确定当前产品的质量状况
指导后期工作重点，明确产品上线前回归测试以及上线后重点关注的模块：比如上线前一般需要再重点测试缺陷集中的区域。
明确缺陷发展趋势，确定是否可以结束测试：我们都知道bug是找不完的，缺陷发展趋势是作为判断是否可以结束测试的重要标志。如果发现趋势不正常，那缺陷分析可以帮助我们制定出遏制缺陷发生的措施、降低缺陷数量。
发现测试员工作技能上的不足，提升人员能力。笔者作为测试经理的那些年，经常需要通过测试员提交的bug，来分析每个测试员存在的弱项，从而判断产品测试的质量，以及制定测试员的培训方案。
提升开发和测试人员的素质以及责任心。
改进测试流程，优化测试方式。有经验的测试经理对于一个项目可能出现的bug总数量，对于每个模块可能隐藏的bug数量，以及每天测试人员应该发现的bug数量会有一个估计。如果实际情况偏离了预估，测试经理需要做的其中一项工作就是考虑是否目前的测试流程和测试方式存在不足。
改善项目管理流程。质量是生产出来的，不是检验出来的。软件产品的生产过程决定了所开发出的软件的质量，提高软件质量是软件生产过程中各项活动的共同目标。可以通过bug中反映出来的问题，优化项目管理过程，促进对软件生产过程的质量控制与管理。
预防缺陷发生。目前多数测试人员都是在项目送测后进行检测，这是一种“事后检测”行为，我们希望找到一些方式来“事前控制”。
提高项目成功率。时间成本是衡量项目成功的一个重要因素，而项目无法如期交付的原因之一就是花费过多的时间在修改bug上，如果上一条能推进，可以在很大程度上缩短项目周期。
提高软件开发和测试效率。
CMMI4认证需要或改善组织的软件能力成熟度。认证CMMI4要求在项目中定量管理，建立组织级过程性能，构成完整的量化管理，采用统计或其它定量方法管理软件过程，并通过对过程中出现的方法，技术等问题进行因果分析和寻找解决方案。
开展缺陷分析工作的难点
缺陷产生原因复杂：运行环境（操作系统、数据库等）、第三方工具或软件、网络、用户操作习惯等都可能导致缺陷的产生，这会直接导致定位缺陷原因成本的上升。
公司或项目团队的不支持。有时是不帮助测试人员做bug分析工作，有时候制定了bug预防方案却因为公司或团队的不支持而难以推进。
程序员的不配合：比如我们希望程序员在bug修复时顺便备注bug的根源和修复方式，这个要求很可能导致程序员的抵触。
测试人员不懂如何分析。
团队人员没有质量管理的意识。
缺陷分析工作完成后，后续工作难以落地。
其他。
谁来做缺陷分析？
开发团队中的所有干系人，以测试人员为主导。
什么时候做缺陷分析？
前文有提到，发现bug时和测试结束前后都需要进行bug分析，另外，可以在开发过程中做一些阶段性的bug分析，也可以在测试阶段每天都做一次bug分析。
最好让团队同意使用bug管理工具来管理bug，否则会大大增加这项工作的难度。（很多中小型企业仍然用word来管理bug）
对哪些bug进行缺陷分析？
在前文提到，软件缺陷的范围很广，不仅仅指在测试过程中发现的缺陷，而是指在整个软件生命周期中发现的所有缺陷。但是否所有的缺陷都需要分析呢？
显然不是。
做分析之前首先要明确我们的目的，目的的不同也决定了分析内容的不同。
比如有的团队，可能只需要对上线后发现的漏测bug进行分析；有的团队需要对上线后暴露的bug以及测试阶段发现的典型bug进行分析。
需要根据团队需要进行确定。
怎么做缺陷分析？
本章节是本文的重点。不过限于篇幅，笔者也不想将本文写成一篇学术论文，所以仅给出笔者的几点经验。若有疑惑，欢迎留言区讨论。
如何进行缺陷分析，前提还是要想清楚自己做缺陷分析的目的是什么，有了方向，再考虑如何开展后续工作。
比如产品上线后质量较差，频繁出现线上bug。那我们可以联合其他部门针对线上bug进行分析，排查每一个线上bug产生的原因，确定是否是测试人员漏测导致，如果是，那我们再分析一下之前是怎么测试的（需要保留之前的测试记录），当时为什么没有测试出来，以后怎么改进工作。这项工作需要长期进行，才能真正提高测试人员的“bug检出率”。
比如我们希望做一做bug预防的工作。光荣之路创始人吴老曾经做过相关的专题（可以到他的公众号中搜索相关文章），也曾经给出他的一些经验。不过根据笔者的经验，这项工作的难点在于执行和落地。换句话说，当我们已经得到了bug根源和预防措施后，后续怎么让工作落地？（关于工作的推进技巧，可以阅读笔者的相关文章）
比如感觉目前的软件开发过程混乱，也可以通过缺陷分析来进行优化。比如优化缺陷分类方式、增减缺陷属性，根据缺陷的统计属性来确定软件开发的哪个环境问题较多，通过缺陷流转中出现的问题来优化缺陷管理流程等。
补充：
可以读一读《探索式测试》这本书，了解更多的缺陷分析方式。
缺陷描述属性是指:缺陷信息描述,缺陷处理时间,缺陷引入原因分析,缺陷处理结果,缺陷调查分析等。
缺陷统计属性是指:缺陷生命周期状态,缺陷流出的开发阶段,缺陷流出的部门,缺陷流出的功能模块,缺陷表现类型,缺陷的严重等级等基于缺陷数量统计其分布的属性。
缺陷控制属性是指:处理缺陷的角色,缺陷的分配,处理缺陷的时间,缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。
随时随地看视频
