如何通过缺陷分析来改进软件工程?
什么是缺陷分析？
讨论这个问题，首先要明确什么是缺陷？
通常意义上的缺陷：程序中存在的错误，俗称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检出率”。
2.比如感觉目前的软件开发过程混乱，也可以通过缺陷分析来进行优化。比如优化缺陷分类方式、增减缺陷属性，根据缺陷的统计属性来确定软件开发的哪个环境问题较多，通过缺陷流转中出现的问题来优化缺陷管理流程等。
