缺陷分析——精选推荐

缺陷分析
1. 引⾔：缺陷分析现状
⽬前我们测试⼈员是如何利⽤缺陷的呢？
多数中⼩型企业对于缺陷的控制和管理处于⼀种混乱的状态，对测试前期的设计和后期的缺陷数据统计分析的重视程度严重不⾜。

⼀种典型的情况就是测试⼈员在将 bug 提交后，仅做 bug 的修复验证，⽽没有进⼀步的⼯作。

也有⼀些公司的测试⼈员，会在测试报告中对 bug 做⼀些数据统计，以此评估当前软件的质量状况，并作为判定软件是否能发布或交付的依据。

可能会再提⼀提由 bug 所反映出来的问题，但也⽌步于此，没有进⼀步的⼯作。

只有极少数的公司会做⼀些 bug 的分析⼯作，通过 bug 分析来改进产品质量、优化研发流程和项⽬管理⽅式。

很多时候项⽬开发周期难以控制，原因之⼀就是缺乏缺陷数据的统计与分析，及缺陷的预防机制。

现在市场上有很多缺陷管理系⼯具，不过这些缺陷管理⼯具在特性上基本上都⼤同⼩异，对于缺陷的分类⽅法没有⼀个统⼀的标准，并且在缺陷分析⽅⾯普遍⽐较薄弱，通常只是提供⼀些缺陷数量的简单统计功能，⽤户不得不借助⼀些其它的统计分析软件或⾃⾏开发缺陷分析⼯具来进⾏缺陷数据的分析。

2. 什么是缺陷分析？
讨论这个问题，⾸先要明确什么是缺陷？
通常意义上的缺陷：程序中存在的错误，俗称 bug。

⼴义上的缺陷：项⽬计划、需求规格说明书、设计⽂档、测试⽤例、⽤户⼿册等存在的错误或问题。

可以说在软件⼯程整个⽣命周期中，任何导致⽆法满⾜⽤户所要求的的功能活导致系统失败的问题都都属于缺陷的范畴。

再说说什么是缺陷分析？
通常意义上的缺陷分析：包含两个阶段，⼀是发现 bug 后进⾏ bug 定位和排查原因的活动；⼆是系统测试结束前后对软件开发各个阶段产⽣的缺陷进⾏分类、分析和汇总统计、改进缺陷度量和分析的模型、编写分析报告的活动。

这个活动中可能会伴随着其他活动，⽐如输出缺陷预防的⽅案。

毕竟我们做分析的最终⽬的是为了提⾼产品质量和优化项⽬管理流程。

⼴义上的缺陷分析：对应“⼴义缺陷”的定义，对项⽬开发的整个⽣命周期中出现的各类问题（不局限于 bug）进⾏分类和分析，进⽽改进项⽬管理流程的活动。

3. 为什么要做缺陷分析？
⼴义上的缺陷分析⽐较复杂，本⽂只讨论通常意义上的缺陷分析。

发现 bug 后进⾏缺陷分析可以帮助我们：
1. 排查是否有遗漏的同类缺陷：⽐如我们发现某个 bug 产⽣的根源是因为开发修改了某个接⼝，我们会推测其他调⽤该接⼝的模块可能
也存在风险。

这种情况我们就可以更好的保障测试范围没有遗漏。

2. 验证代码逻辑的合理性：开发⼈员⽔平参差不齐，对于同⼀个功能可能有多种实现⽅式，年轻的程序员⾮常可能选择较差的实现⽅
式，他们的修复可能不但更复杂，也可能会引⼊新的 bug。

⽽有经验的测试员可以指导程序员更简单⾼效的⽅式。

这个过程中的分析经历，⽆论是对测试员还是程序员都是⼀种经验的积累。

3. 有助于确定开发⼈员是否真正修复了 bug：如果不了解 bug 产⽣的原因，很多时候测试⼈员⽆法确定 bug 是否被正确修复。

⽐如有 N
种情况都可能导致 bug 的出现，但程序员只修复了其中⼀种情况；有时候对于⼀些偶发性的 bug，如果不清楚原因，就很可能⽆法设计出正确的测试⽅式，进⽽导致不能保证 bug 被真正修复（这种情况中，程序员没有提交本地的修复代码到主⼲，测试⼈员可能都不清楚）。

4. 改善缺陷分类：通过缺陷分析结果的反馈，改进缺陷度量分类标准和分析⽬标，提⾼缺陷分析结果的准确性。

5. 有助于项⽬结束后的分析：出现 bug 时不做分析，项⽬结束后想做分析可能都做不到了。

系统测试结束前后的缺陷分析可能帮助我们：
1. 确定当前产品的质量状况。

2. 指导后期⼯作重点，明确产品上线前回归测试以及上线后重点关注的模块：⽐如上线前⼀般需要再重点测试缺陷集中的区域。

3. 明确缺陷发展趋势，确定是否可以结束测试：我们都知道 bug 是找不完的，缺陷发展趋势是作为判断是否可以结束测试的重要标志。

如果发现趋势不正常，那缺陷分析可以帮助我们制定出遏制缺陷发⽣的措施、降低缺陷数量。

4. 发现测试员⼯作技能上的不⾜，提升⼈员能⼒。

测试经理经常需要通过测试员提交的 bug，来分析每个测试员存在的弱项，从⽽判断
产品测试的质量，以及制定测试员的培训⽅案。

5. 提升开发和测试⼈员的素质以及责任⼼。

6. 改进测试流程，优化测试⽅式。

有经验的测试经理对于⼀个项⽬可能出现的 bug 总数量，对于每个模块可能隐藏的 bug 数量，以及每
天测试⼈员应该发现的 bug 数量会有⼀个估计。

如果实际情况偏离了预估，测试经理需要做的其中⼀项⼯作就是考虑是否⽬前的测试流程和测试⽅式存在不⾜。

7. 改善项⽬管理流程。

质量是⽣产出来的，不是检验出来的。

软件产品的⽣产过程决定了所开发出的软件的质量，提⾼软件质量是软件
⽣产过程中各项活动的共同⽬标。

可以通过 bug 中反映出来的问题，优化项⽬管理过程，促进对软件⽣产过程的质量控制与管理。

8. 预防缺陷发⽣。

⽬前多数测试⼈员都是在项⽬送测后进⾏检测，这是⼀种“事后检测”⾏为，我们希望找到⼀些⽅式来“事前控制”，来提
⾼开发和测试效率，保证项⽬成功率。

时间成本是衡量项⽬成功的⼀个重要因素，⽽项⽬⽆法如期交付的原因之⼀就是花费过多的时间在修改 bug 上，做好缺陷预防，可以在很⼤程度上缩短项⽬周期。

9. CMMI4 认证的需要，或者改善组织的软件能⼒成熟度。

认证 CMMI4 要求在项⽬中定量管理，建⽴组织级过程性能，构成完整的量化
管理，采⽤统计或其它定量⽅法管理软件过程，并通过对过程中出现的⽅法，技术等问题进⾏因果分析和寻找解决⽅案。

4. 开展缺陷分析⼯作的难点
1. 缺陷产⽣原因复杂：运⾏环境（操作系统、数据库等）、第三⽅⼯具或软件、⽹络、⽤户操作习惯等都可能导致缺陷的产⽣，这会直
接导致定位缺陷原因成本的上升。

2. 公司或项⽬团队的不⽀持：有时候是不帮助测试⼈员做 bug 分析⼯作；有时候是制定了 bug 预防⽅案却因为公司或团队的不⽀持⽽难
以推进。

3. 程序员的不配合：⽐如我们希望程序员在 bug 修复时顺便备注 bug 的根源和修复⽅式，这个要求很可能导致程序员的抵触。

4. 测试⼈员不懂如何分析。

5. 团队⼈员没有质量管理的意识。

6. 缺陷分析⼯作完成后，后续⼯作难以落地。

7. 其他。

5. 谁来做缺陷分析？
开发团队中的所有⼲系⼈，以测试⼈员为主导，最重要是需要⾼层领导⽀持。

6. 什么时候进⾏缺陷分析？
前⽂有提到，发现 bug 时和测试结束前后都需要进⾏ bug 分析。

另外，可以在开发过程中做⼀些阶段性的 bug 分析，也可以在测试阶段每天都做⼀次 bug 分析。

最好让团队同意使⽤ bug 管理⼯具来管理 bug，否则会⼤⼤增加这项⼯作的难度（很多中⼩型企业仍然⽤ word 来管理 bug）。

7. 对哪些 bug 进⾏分析？
在前⽂提到，软件缺陷的范围很⼴，不仅仅指在测试过程中发现的缺陷，⽽是指在整个软件⽣命周期中发现的所有缺陷。

但是否所有的缺陷都需要分析呢？显然不是。

做分析之前⾸先要明确我们的⽬的，⽬的的不同也决定了分析内容的不同。

⽐如有的团队，可能只需要对上线后发现的漏测 bug 进⾏分析；有的团队需要对上线后暴露的 bug 以及测试阶段发现的典型 bug 进⾏分析。

总之，需要根据团队需要进⾏确定。

8. 如何进⾏缺陷分析？
如何进⾏缺陷分析，前提还是要想清楚⾃⼰做缺陷分析的⽬的是什么，有了⽅向，再考虑如何开展后续⼯作。

1. ⽐如产品上线后质量较差，频繁出现线上 bug。

那我们可以联合其他部门针对线上 bug 进⾏分析，排查每⼀个线上 bug 产⽣的原因，
确定是否是测试⼈员漏测导致，如果是，那我们再分析⼀下之前是怎么测试的（需要保留之前的测试记录），当时为什么没有测试出来，以后怎么改进⼯作。

这项⼯作需要长期进⾏，才能真正提⾼测试⼈员的“bug检出率”。

2. ⽐如我们希望做⼀做 bug 预防的⼯作。

不过这项⼯作的难点在于执⾏和落地。

换句话说，当我们已经得到了 bug 根源和预防措施后，
后续怎么让⼯作落地？
3. ⽐如感觉⽬前的软件开发过程混乱，也可以通过缺陷分析来进⾏优化。

例如通过优化缺陷分类⽅式、增减缺陷属性等，再根据缺陷的
统计属性来确定软件开发的哪个环境问题较多；通过缺陷流转中出现的问题来优化缺陷管理流程等。

可以读⼀读《探索式测试》这本书，了解更多的缺陷分析⽅式。

缺陷描述属性是指：缺陷信息描述、缺陷处理时间、缺陷引⼊原因分析、缺陷处理结果、缺陷调查分析等。

缺陷统计属性是指：缺陷⽣命周期状态、缺陷流出的开发阶段、缺陷流出的部门、缺陷流出的功能模块、缺陷表现类型、缺陷的严重等级等基于缺陷数量统计其分布的属性。

缺陷控制属性是指：处理缺陷的⾓⾊、缺陷的分配、处理缺陷的时间、缺陷数据之间的关联关系等基于缺陷分配流程管理的属性。