缺陷分析及实例

1、缺陷分析及实例缺陷分析及实例 如果失败是成功之母的话，BUG 无疑是高质量之母。很多开发人员忽略了其 中的关系。Watts Hamphery 1在研究时统计发现，开发人员引入缺陷率与其从事 开发时间长短无关。优秀开发人员能从自己失败经验中迅速的成长，而普通开发 人员则需要花很长的时间， 其中最主要的差异原因就在于是否会有意识的对自己 的 BUG 进行分析、学习 2。 前言：前言：BUG 分析简介分析简介 BUG 分析顾名思义，就是对产品产生缺陷进行规律性分析，确定缺陷产生的 原因，制定改进、预防措施并监督执行，形成改进闭环等等。BUG 分析对部门、 团队、个人质量提升都有很大的好处。在 CMM5 级中有专门的 KPA：DP 缺陷预防 （对应 CMMI5 级的 CAR 原因分析及解决方案） 。BUG 分析重要程度毋庸置疑。本 文主要描述的就是 BUG 分析方法。 在介绍 BUG 分析方法之前首先要强调的是：BUG 分析最为主要的是后续要开 展活动，将分析与后续措施形成一个改进的闭环。BUG 分析产物一般会是开发规 范、代码复查 Checklist、改进措施等等。针对这些结果应作为团队、项

2、目、个 人改进计划的输入并对这些情况监督执行。 缺陷分析 改进计划 执行改进 检查/调整执行活动 图 1：缺陷分析改进 BUG 分析一般会分多个层次来进行：公司、部门、团队、项目、个人。针对 于部门、团队、个人，BUG 分析的时机一般会定期、事件驱动的对缺陷进行缺陷 分析。针对于项目来说，一般在项目中 BUG 主要通过评审、代码走查、测试等质 量控制环节在工程活动各个阶段得到识别。 因此在项目各个工程活动阶段都会存 在 BUG 分析。 1 CMM 创始人 2 PSP 过程改进Watts Humphery 1997 BUG 分析有很多种类，实质上在软件总部已经开展了若干 BUG 分析工作，譬 如在各阶段会将排除缺陷与质量目标相互对比的分析、 代码复查发现缺陷的控制 图分析，在系统测试阶段会有 Gompertz 来分析缺陷是否满足等等，这些内容作 为公司的标准分析方法不再一一列举。 以下主要探讨一下针对缺陷注入的分析。 缺陷注入分析基本上都会回答以下 问题： 1. 哪些模块问题较多？产生原因是什么？ 2. 哪些阶段问题较多？产生原因是什么？ 3. 哪些缺陷排除环节需要加强？如何加强？ 4.

3、 严重缺陷产生阶段及原因 5. 以后需要做什么样的改进才能帮助减少缺陷。 通过 GQM 方法 2得到 BUG 需要收集的基本特征：BUG 描述、解决方法、原因 分析、缺陷类别、引入阶段、排除阶段、所属模块、经验教训、严重程度、最佳 排除方式等等。以上特征只是最为基本的属性，能够回答如上问题。如果要开展 更为深入、有针对性的 BUG 分析就需要针对问题利用 GQM 方法更多的 BUG 特征。 譬如软件总部使用控制图来评判代码复查过程是否稳定， 那么就需要收集缺陷归 属哪支程序的信息等。 BUG 分析的一般的流程如下，注意后续的改进活动，使得 BUG 分析、过程改 进形成一个闭环： 1) 对 BUG 进行收集、分析，并确定以上特征。 2) 基于对以上特征的统计分析，利用统计分析工具（以下介绍）找出 BUG 产生的主要原因及规律。这一步是 BUG 分析中比较重要的环节，如果深 入开展工作需要统计学、软件工程的知识。但如果只是回答上述问题则 相对简单。 3) 根据原因制定改进措施。譬如在哪些环节加大工作量投入、哪些环节需 要注意改善方法等等，完善开发规范、Checklist、加大培训及后续工

4、作的监督力度等等。 4) 根据以上改进措施制定改进计划。 5) 监督改进计划的执行实施。 2 Goal- Questions- Measure 目标驱动的软件度量方法 BUG 分析常采用的统计工具：控制图、直方图、pareto 图、鱼骨图、饼图、 相关图、趋势图等等，主要使用此来附带分析原因。BUG 分析是一个不断深入的 过程。其中控制图用来确定缺陷排除过程是否稳定；直方图用来统计缺陷种类、 排除阶段、 产生原因等等； 鱼骨图用来由粗至细的分析缺陷可能产生原因； Pareto 图用来分析缺陷主要、次要原因；相关图用来试探两个变量是否存在某种关系， 趋势图用来判断缺陷增长等等。 以上工具使用的一般流程是：收据完 BUG 相关数据进行初始试探性分析，可 使用趋势图、控制图、直方图来检测缺陷排除过程是否异常，是否稳定性（可以 参考中心规范指南开展工作） 。在开始分析的时候也会用到散点图去观察两个变 量之间是否有关系找出缺陷规律等等。 接着可以采用鱼骨图因果图由粗至细列出 可能原因。可以用饼图来展示过程中各原因的比例；由 pareto 图找出主要原因； 改进主要原因；最后还可以用 pareto

5、 图比较一下改进后的效果。提醒注意是为 了 BUG 分析用工具而不是为了用工具而用工具。 以下为 BigOne2008 年 BIGONE3.0 BUG 分析的实例，供参考 一、一、BUG 取样范围取样范围 2008 年 BUG 分析范围主要是 BIGONE2.0 SIT、UAT、准生产、投产期间的 缺陷，SIT 提取关键问题，准生产、投产期间无生产问题。 以上问题共计 125 个。其中 SIT 期间提取问题 117 个；UAT、准生产、投产 期间 8 个，较 2.0 二期大幅下降。就以上数据简单来看，随着 BFW 框架的逐渐 稳定，业务部门的逐步成熟，开发人员水平的逐渐提升，BigOne 产品质量得到 控制并呈稳步上升趋势。 二、二、BUG 分析方法分析方法 本次主要对这 125 个 BUG 进行分析，确定以上缺陷产生的原因、缺陷的类 型、应该在何阶段排除等等，希望通过这样的分析，获取一些对质量改进有益的 方法， 更新团队的 Checklist， 为团队质量提升尽一份力， 因此本任务作为 BigOne 团队的质量管理小组工作内容之一。 在分析的过程中，我们主要关注缺陷产生原因、缺陷类型

6、、缺陷排除阶段等 几个关键内容。以下对这几个方面做简单介绍： 缺陷产生原因是针对具体缺陷的具体分析，分析缺陷症状的根本原因何在。 缺陷类型主要分为：需求缺陷、设计缺陷、编码缺陷、业务变更、变更缺陷、 其他等等。各缺陷定义如下： 需求缺陷：因需求没有分析清楚或分析错误而引发的缺陷，通俗的讲就是要 做什么没有搞清楚、讲清楚或讲错了。 设计缺陷： 需求讲明白了， 但因设计没有分析清楚或分析错误而引发的缺陷， 跟实际情况（设计文档粒度较粗）相互结合通俗的讲就是干什么想明白了，但咋 做的没有想清楚。设计缺陷包括总体设计缺陷、详细设计缺陷。 编码缺陷：因编码失误而导致的缺陷，通俗讲就是讲清楚、想清楚了，但是 没有写正确。 业务变更：属于需求细化内容，譬如页面字段名称变化等等细微不能称之为 需求变更的需求细化或者是需求扰动，因此类问题过多且并入需求缺陷不合适， 因此专门划分一项。请不要对“变更”产生误解。 变更缺陷：因变更而引发的缺陷。其中变更包括需求、设计等中途变化但没 有通知到相关干系人而引发的缺陷。变更缺陷实际可以分解为需求、设计、编码 等等， 但在分析的过程中发现因变更引发的缺陷较多，因此将

7、变更专门作为一类 去做相应的分析。 其他：因以上之外的各种原因引发的，譬如版本引发，环境不同引发参数变 更等等缺陷。 以上并没有采用传统软件工程的划分模式，甚至不是单一维度的划分缺陷， 譬如有业务变更、变更缺陷等种类。主要是因为该类缺陷较多，需要专门提出分 析引起注意。以上分类之间可能会有交集，划分原则就是缺陷偏重于哪个分类就 划分为哪个分类。 最佳排除方式：很多缺陷实际上使用那种方法都可能排除，但哪种方法排除 代价最小，哪种方法排除此类缺陷最为有效，因此在本次 BUG 分析中添加了最佳 排除方式分析。排除方式主要有：评审/走查、内部测试、系统测试、UAT 测试、 准生产测试等等。 本次 BUG 分析尤以最佳排除方式特征最为含糊。选择的标准就是：排除代 价最小、最容易排除该类缺陷、实际情况制约只能采用某种方式排除。解释最后 一种标准： 譬如英文版类缺陷， 英文版的准备是在 BIGONE3.0 系统测试阶段开始， 可能延续到 UAT 阶段，而且系统测试期间用户会真正参与确认英文版事宜，因此 英文类缺陷定的最佳排除方式就是系统测试、UAT 测试。 三、三、BUG 分析分析 针对附件BIGO

8、NE SIT、UAT、生产主要 BUG 分析表 ，在各位分析人分 析的基础上，团队质量管理小组进行汇总，统计分析如下。 3.1 BUG 主要分布主要分布 39 30 29 14 10 3 78.40% 0 5 10 15 20 25 30 35 40 45 编码错误业务变更设计错误其他变更错误需求错误 0.00% 20.00% 40.00% 60.00% 80.00% 100.00% 120.00% 按 BUG 类型统计，80%的错误主要集中在编码错误、业务变更、设计错误 等三类缺陷上面。 针对编码错误：主要通过代码复查、开发规范培训、Checklist 推广等方式来 减少，另外还需要加大开发人员对需求的掌握，以及对各后台业务的了解。 针对业务变更 BUG：业务变更其实质就是需求没有开发完全（这是符合软 件工程的） ，针对此类问题，BigOne 已通过 DEMO 制作等前期方式来辅助进行 需求挖掘，起到很好的效果，需要加大力度的就是需求文档的评审工作，以及业 务代表更深一步、尽早的加入到项目组的需求开发、系统测试等工作中（最佳实 践） 。 针对设计错误：设计错误与业务变更数量相当，需要

9、引起注意。本次设计错 误主要包括总体设计、详细设计错误。设计类错误的高占比意味着目前设计力度 还有待加强，粒度还需要细化、深入。 其中变更 BUG 也不容忽视，变更 BUG 意味着因变更引发、在实施过程中 未能充分考虑等情况引发的错误。 针对此类错误， 要做好变更的影响域分析等等。 3.2 BUG 严重程度分布严重程度分布 46 37 33 6 3 92.80% 0 5 10 15 20 25 30 35 40 45 50 5、功能运行瑕疵 6、修饰性问题 4、功能性错误 3、功能未实现 7、其他 0.00% 20.00% 40.00% 60.00% 80.00% 100.00% 120.00% 严重程度由低至高共分为 7 类：7、其他,6、修饰性问题,5、功能运行瑕疵,4、 功能性错误,3、 功能未实现,2、 系统/子系统运行不佳,1、 系统/子系统不能使用等。 其中可以发现本次 BUG 主要集中在：5、功能运行瑕疵、6、修饰性错误、 4、功能性错误上。分析 6、修饰性错误大多为业务变更引发，因此针对此类修 饰性错误，需要加强业务部门对 DEMO 的确认，中期加大业务部门的参与，尤 其关注系统测试期间业务部门参与对需求的确认工作， 后期要加大业务变更控制 等等。 6、修饰性错误原因分析 编码错误 21% 变更错误 5% 其他 5% 业务变更 69% 随着 BUG 严重程度的提升， BUG 的原因逐渐由业务变更引发缺陷转变为因 设计、编码错误等等引发缺陷，需要关注需要关注！从下图来看：本次 BIGONE 开发中 需求开发工作较为成功，因业务变更（需求开发相关）引发的缺陷多为修饰性等 轻微缺陷。造成较为严重缺陷的是设计、编码等环节，尤其是设计环节（图中粗 线- 淡蓝色线条）是 4、5 级缺陷的主要原因。 0 5 10 15 20 25 30 6、修饰性错误原因 5、功能运行瑕疵 4、功能性错误 编码错误 变更错误 其他 设计错误 需求错误 业务变更 加大设计开发力度， 加大设计文档走查评审力度； 加大编码开发人员的培训、 代码走查等等，加大开发人员对需求的理解力度；后期加大测试力度。 3.3 BUG 最佳排除方式最佳排除方式 42 25 23 19 15 1 72.000% 0 5 10 15 20 25 30 35 40 4

《缺陷分析及实例》由会员n****分享，可在线阅读，更多相关《缺陷分析及实例》请在金锄头文库上搜索。