缺陷分析及实例.pdf

1、缺陷分析及实例 如果失败是成功之母的话， BUG无疑是高质量之母。很多开发人员忽略了其 中的关系。 Watts Hamphery 1 在研究时统计发现，开发人员引入缺陷率与其从事 开发时间长短无关。优秀开发人员能从自己失败经验中迅速的成长，而普通开发 人员则需要花很长的时间，其中最主要的差异原因就在于是否会有意识的对自己 的 BUG进行分析、学习 2 。 前言： BUG分析简介 BUG分析顾名思义，就是对产品产生缺陷进行规律性分析，确定缺陷产生的 原因，制定改进、预防措施并监督执行，形成改进闭环等等。 BUG分析对部门、 团队、个人质量提升都有很大的好处。在 CMM5级中有专门的 KPA： D

2、P缺陷预防 （对应 CMMI5级的 CAR原因分析及解决方案）。 BUG分析重要程度毋庸置疑。本 文主要描述的就是 BUG分析方法。 在介绍 BUG分析方法之前首先要强调的是： BUG分析最为主要的是后 续 要 开 展活动 ， 将 分析 与 后 续 措施形成 一 个改进的闭环。 BUG分析产 物一般会 是 开发 规 范 、 代码复查 Checklist、改进措施等等。 针 对 这些结果 应 作 为团队、 项目 、个 人改进 计划 的 输入 并对 这些情况 监督执行。 缺陷分析 改进 计划 执行改进 检查 /调 整 执行 活动图 1：缺陷分析改进 BUG分析 一般会 分 多 个 层次来 进行：

3、公司 、部门、团队、 项目 、个人。 针 对 于 部门、团队、个人， BUG分析的 时机一般会 定 期 、 事件驱动 的对缺陷进行缺陷 分析。 针 对 于项目来说 ， 一般 在 项目 中 BUG主要 通过评审 、 代码走查 、 测试 等质 量 控 制环 节 在 工 程 活动各 个 阶段得到识别 。因 此 在 项目各 个 工 程 活动阶段 都 会存 在 BUG分析。 1CMM创始 人 2 PSP过 程改进 Watts Humphery 1997 BUG分析有很 多种类 ， 实 质 上 在 软件总 部 已经开展了若干 BUG分析 工作 ， 譬 如 在 各阶段会将排除 缺陷 与 质量 目标相互 对

4、比 的分析、 代码复查发现 缺陷的 控 制 图 分析，在 系统测试阶段会 有 Gompertz来 分析缺陷是 否满足 等等， 这些 内容 作 为 公司 的 标 准 分析方法 不再 一一 列举 。 以下 主要 探讨 一 下 针 对缺陷 注 入 的分析。缺陷 注 入 分析 基 本 上 都 会 回答以下 问题 ： 1. 哪 些 模块问题较 多 ？ 产生原因是 什么？ 2. 哪 些阶段 问题较 多 ？ 产生原因是 什么？ 3. 哪 些 缺陷 排除 环 节 需 要 加 强 ？ 如 何加 强 ？ 4. 严 重缺陷产生 阶段 及原因 5. 以 后 需 要 做什么样 的改进 才能帮助减少 缺陷。 通过 GQM

5、方法 2 得到 BUG需 要 收集 的 基 本 特征 ： BUG描述、解决方法、原因 分析、缺陷 类别 、 引 入阶段 、 排除阶段 、 所属模块 、 经 验教训 、 严 重程度、最 佳 排除 方 式 等等。 以 上 特征只 是最为 基 本的 属 性， 能够回答 如上 问题 。 如果 要 开展 更 为 深 入 、有 针 对性的 BUG分析就 需 要 针 对 问题利用 GQM方法 更 多 的 BUG特征 。 譬如软件总 部 使用 控 制 图来评 判 代码复查过 程是 否 稳 定， 那么 就 需 要 收集 缺陷 归 属哪支 程 序 的 信息 等。 BUG分析的 一般 的 流 程 如 下 ， 注意

6、后 续 的改进 活动 ， 使 得 BUG分析、 过 程改 进形成 一 个闭环： 1) 对 BUG进行 收集 、分析，并确定 以 上 特征 。 2) 基 于 对 以 上 特征 的 统计 分析， 利用 统计 分析 工 具 （ 以下 介绍） 找出 BUG 产生的主要原因及规律。 这一 步 是 BUG分析中 比 较 重要的环 节 ， 如果 深 入开展工作 需 要 统计 学 、 软件工 程的 知 识 。 但 如果 只 是 回答 上 述 问题则 相 对 简单 。 3) 根据 原因制定改进措施。 譬如 在 哪 些 环 节 加 大 工作 量 投 入 、 哪 些 环 节 需 要 注意 改 善 方法等等， 完善

7、开发 规 范 、 Checklist、 加 大 培训 及后 续工 作 的监督 力 度等等。 4) 根据以 上 改进措施制定改进 计划 。 5) 监督改进 计划 的执行 实 施。 2Goal-Questions-Measure目标驱动 的 软件 度量方法 BUG分析 常采用 的 统计工 具 ： 控 制 图 、 直 方 图 、 pareto图 、 鱼骨 图 、 饼 图 、 相 关 图 、 趋势 图 等等，主要 使用 此来 附带 分析原因。 BUG分析是 一 个 不断深 入 的 过 程。 其 中 控 制 图 用 来 确定缺陷 排除过 程是 否 稳 定 ；直 方 图 用 来统计 缺陷 种类 、 排除阶

8、段 、产生原因等等 ；鱼骨 图 用 来 由粗至细 的分析缺陷 可 能 产生原因 ； Pareto 图 用 来 分析缺陷主要、 次 要原因 ； 相 关 图 用 来试 探 两 个 变 量是 否存 在 某 种 关 系 ， 趋势 图 用 来 判断 缺陷 增长 等等。 以 上工 具使用 的 一般 流 程是： 收据完 BUG相 关 数 据 进行 初 始试 探 性分析， 可 使用趋势 图 、 控 制 图 、 直 方 图来检测 缺陷 排除过 程是 否 异 常 ，是 否 稳 定性（ 可 以 参考 中 心 规 范 指南 开展工作 ）。在 开始 分析的 时 候也 会 用 到 散点 图 去观察两 个 变 量之 间 是

9、 否 有 关 系 找出 缺陷规律等等。 接着可 以采用鱼骨 图 因 果图 由粗至细 列出 可 能 原因。 可 以用饼 图来展 示 过 程中 各 原因的 比 例 ； 由 pareto图 找出 主要原因 ； 改进主要原因 ； 最后 还可 以用 pareto图比 较 一 下 改进后的 效 果 。提 醒 注意 是为 了 BUG分析 用 工 具 而 不 是为 了 用 工 具 而 用 工 具 。 以下 为 BigOne2008年 BIGONE3.0 BUG分析的 实 例 ， 供参考 一、 BUG取样范围 2008年 BUG分析 范 围 主要是 BIGONE2.0 SIT、 UAT、 准 生产、 投 产 期

10、 间 的 缺陷， SIT提 取 关 键 问题 ， 准 生产、 投 产 期 间无 生产 问题 。 以 上 问题 共 计 125个。 其 中 SIT期 间 提 取 问题 117个 ； UAT、 准 生产、 投 产 期 间 8个， 较 2.0二 期 大 幅 下 降 。就 以 上 数 据简单 来 看 ， 随着 BFW框架 的 逐渐 稳 定， 业务 部门的 逐 步 成 熟 ， 开发 人 员水平 的 逐渐 提升， BigOne产品质量 得到 控 制并 呈 稳步 上 升 趋势 。 二、 BUG分析方法 本 次 主要对 这 125个 BUG进行分析，确定 以 上 缺陷产生的原因、缺陷的 类 型 、应 该 在

11、何 阶段排除 等等， 希望 通过这 样 的分析， 获取 一些 对质量改进有 益 的 方法， 更 新 团队的 Checklist，为团队质量提升 尽 一 份 力 ，因 此 本 任务 作 为 BigOne 团队的质量 管理小组 工作 内容 之 一 。 在分析的 过 程中， 我们 主要 关注 缺陷产生原因、缺陷 类 型 、缺陷 排除阶段 等几 个 关 键 内容 。 以下 对 这 几 个方 面 做简单 介绍： 缺陷产生原因是 针 对 具 体 缺陷的 具 体 分析，分析缺陷 症状 的 根 本原因 何 在。 缺陷 类 型 主要分为： 需 求 缺陷、 设 计 缺陷、 编 码 缺陷、 业务变 更 、 变 更

12、缺陷、 其 他 等等。 各 缺陷定义 如 下 ： 需求缺陷：因需求没有分析清楚或分析错误而引发的缺陷，通俗的讲就是要 做什么 没有 搞 清楚、讲清楚或讲错了。 设 计缺陷：需求讲 明白 了， 但 因 设 计没有分析清楚或分析错误而引发的缺陷， 跟实际情况（设 计 文档粒度较粗）相互结合 通俗的讲就是 干什么想明白 了， 但咋 做 的没有 想 清楚。 设 计缺陷 包括总体设 计缺陷、 详细设 计缺陷。 编码 缺陷：因 编码 失误而 导致 的缺陷，通俗讲就是讲清楚、 想 清楚了， 但 是 没有 写正确 。 业务变更 ： 属 于需求 细化内容 ， 譬 如 页面字段名称变化等等细微不 能 称 之 为

13、需求 变更 的需求 细化 或 者 是需求 扰动 ，因 此类问题过 多 且并 入需求缺陷 不合适 ， 因 此专门划 分 一项 。 请不 要对 “变更”产生 误 解 。 变更 缺陷：因 变更 而引发的缺陷。其中 变更包括 需求、 设 计 等 中 途变化但 没 有通 知到相 关 干 系人而引发的缺陷。 变更 缺陷 实际可以 分 解为 需求、 设 计、 编码 等等 ， 但 在分析的 过程 中发现因 变更 引发的缺陷 较 多，因 此将变更专门作为一类 去做相应 的分析。 其 他 ：因 以上 之 外 的 各 种 原因引发的， 譬 如 版本 引发， 环境 不 同 引发 参数 变 更等等 缺陷。 以 上 并

14、没 有 采用 传 统软件工 程的 划 分 模式 ， 甚至 不 是 单 一 维 度的 划 分缺陷， 譬如 有 业务变 更 、 变 更 缺陷等 种类 。主要是因为 该 类 缺陷 较 多 ， 需 要专门提 出 分 析 引 起 注意 。 以 上 分 类 之 间可 能 会 有 交 集 ， 划 分原 则 就是缺陷 偏 重 于 哪 个分 类 就 划 分为 哪 个分 类 。 最 佳排除方式 ：很多缺陷 实际上 使用那种方法都 可 能 排除 ， 但 哪种方法排除 代价 最 小 ， 哪种方法排除 此类 缺陷最 为 有 效 ，因 此 在 本次 BUG分析中 添加 了最 佳 排除方式 分析。 排除方式 主要有： 评审

15、 /走查 、 内 部测试 、系统 测试 、 UAT测试 、 准 生产 测试 等等 。 本 次 BUG分析 尤 以 最 佳排除方式 特征 最为 含糊 。 选择 的 标 准 就是： 排除代价 最 小 、最 容 易 排除 该 类 缺陷、 实 际 情况 制 约 只能采用 某 种 方 式 排除 。 解 释 最 后 一 种标准 ： 譬 如 英 文 版 类 缺陷， 英 文 版 的 准备 是在 BIGONE3.0系统 测试阶 段 开 始 ， 可 能 延续 到 UAT阶 段 ，而 且 系统 测试期 间 用户 会 真 正 参 与 确 认英 文 版 事 宜 ，因 此 英 文类 缺陷 定 的最 佳排除方式 就是系统

16、测试 、 UAT测试 。 三、 BUG分析 针 对 附 件 BIGONE 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%的 错误 主要 集 中在 编 码 错误

17、、 业务变 更 、 设 计 错误 等 三 类 缺陷 上 面 。 针 对 编 码 错误 ：主要 通过代码复查 、 开发 规 范 培训 、 Checklist推广 等方 式 来 减少 ， 另外 还 需 要 加 大 开发 人 员 对 需 求 的 掌握 ， 以 及对 各 后 台 业务 的 了 解。 针 对 业务变 更 BUG： 业务变 更其 实 质就是 需 求没 有 开发 完 全 （ 这 是 符合 软 件工 程的）， 针 对 此类 问题 ， BigOne已通过 DEMO制 作 等前 期 方 式 来 辅 助 进行 需 求 挖掘 ， 起 到 很好的 效 果 ， 需 要 加 大 力 度的就是 需 求 文 档

18、 的 评审工作 ， 以 及 业 务 代 表 更深 一 步 、 尽 早 的 加 入到项目 组 的 需 求 开发 、 系统测试 等 工作 中（最 佳 实践 ）。 针 对 设 计 错误 ： 设 计 错误 与 业务变 更 数 量 相 当 ， 需 要 引 起 注意 。本 次 设 计 错 误 主要 包括 总 体设 计 、 详 细设 计 错误 。 设 计类 错误 的 高占 比 意 味 着 目 前 设 计 力 度 还 有 待 加 强， 粒 度 还 需 要 细 化 、 深 入 。 其 中 变 更 BUG也 不容 忽视 ， 变 更 BUG意 味 着 因 变 更引 发 、在 实 施 过 程中 未 能 充 分 考 虑

19、 等 情况 引 发 的 错误 。 针 对 此类 错误 ，要 做 好 变 更 的 影响域 分析等等。 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、 功 能 未

20、 实现 ,2、 系统 /子 系统 运 行 不佳 ,1、 系统 /子 系统 不能使用 等。 其 中 可 以 发现 本 次 BUG主要 集 中在： 5、 功 能 运 行 瑕疵 、 6、 修饰 性 错误 、 4、 功 能 性 错误 上 。分析 6、 修饰 性 错误 大 多 为 业务变 更引 发 ，因 此针 对 此类 修 饰 性 错误 ， 需 要 加 强 业务 部门对 DEMO的确 认 ，中 期 加 大 业务 部门的 参 与 ， 尤 其关注 系统测试期 间业务 部门 参 与 对 需 求 的确 认 工作 ，后 期 要 加 大 业务变 更 控 制 等等。 6、 修饰 性 错误 原因分析 编 码 错误 21

21、% 变 更 错误 5% 其 他 5% 业务变 更 69%随着 BUG严 重程度的提升， BUG的原因 逐渐由业务变 更引 发 缺陷 转 变 为因 设 计 、 编 码 错误 等等 引 发 缺陷， 需要关注 ！从 下 图来 看 ：本 次 BIGONE开发 中 需 求 开发工作 较 为成 功 ，因 业务变 更 （ 需 求 开发相 关 ） 引 发 的缺陷 多 为 修饰 性等 轻微 缺陷。 造 成 较 为 严 重缺陷的是 设 计 、 编 码 等环 节 ， 尤 其 是 设 计 环 节 （ 图 中 粗 线 -淡蓝色线条 ）是 4、 5级缺陷的主要原因。 0 5 10 15 20 25 30 6、 修饰 性

22、错误 原因 5、 功 能 运 行 瑕疵 4、 功 能 性 错误 编 码 错误 变 更 错误 其 他 设 计 错误 需 求 错误 业务变 更加 大 设 计开发 力 度， 加 大 设 计 文 档 走查评审 力 度 ；加 大 编 码开发 人 员 的 培训 、 代码走查 等等， 加 大 开发 人 员 对 需 求 的 理 解 力 度 ； 后 期 加 大 测试 力 度。 3.3 BUG最佳排除方式 42 25 23 19 15 1 72.000% 0 5 10 15 20 25 30 35 40 45 评审 /走查系统测试 内 部 测试 其 他 UAT测试 准 生产 0.00% 20.00% 40.00%

23、 60.00% 80.00% 100.00% 120.00%根据 各 位 分析人对 BUG最 佳采用何 种 方 式 ，团队质量 小组 进行 了 调 整 、 统 计 ， 结果如 下 ： 评审 /走查 、 系统测试 、 内 部 测试 为最 佳 排除 方 式 。 该 图 从另外 一 个方 面 说 明 ：在 实 际 的 操 作 中 需 要 加 强的是 评审 /走查 、 内 部 测试 ，因为 这 两 个环 节 所 排除 的缺陷 与图 中 期 望 排除 的缺陷有很大的 差 异 。 在后 续项目开发 环 节 需 要 加 强 评审 、 走查活动 ，最好 能 结 合 CMMI4级量 化 过 程 管理 思 想 用

24、 质量 目标 数 据 指 导 以 上活动 的执行。 3.4 按小组划分缺陷 36 33 17 13 7 7 7 5 79.20% 0 5 10 15 20 25 30 35 40 对 公 客户端 对 私客户端 BNMS 对 接 海外 对 私 网 上 支 付 框架 海外 对 公 0.00% 20.00% 40.00% 60.00% 80.00% 100.00% 120.00%对 BUG进行 按 小组 划 分， 发现 本 次开发 问题 主要 集 中在对 公 客户端 、对 私 客户端 、 BNMS、对 接 等 几 个 小组 上 。 其 中对 公 客户端 问题 最 多 （ 36个 BUG）， 对 其

25、进行 深 入 分析 发现 有 20多 个 BUG是 新增业务 所 造 成的。 新增业务 的 20多个缺陷中大 多 是 页 面 修饰 类 问题 ， 究 其 原因应 该 与 业务 部门前 期 的 过 少 参 与 、 需 求 开发 不 到 位 、 开发期 间业务变 更 控 制 不 到 位 等等有 关 。 四、问题分析建议列表 在分析的 过 程中， 针 对 以 上 BUG， 我们设 置 了 “备 注 /经 验教训 (checklist)” 栏位 来 收集 分析人对 BUG的 一些 建议 以 及 总结 Checklist项 ， 便 于 今 后 代码复查 等 使用 。对 收集 建议 及 Checklist

26、项整 理 如 下 ： 4.1 Checklist需添加项： 所有层面： 1) 对 数据范围 较 大 的 数据 项 ，需 考虑使用 现有 数据 类 型 是否能 够处理当前 数据 项 ；另 外 还 需 考虑客户端由客户输 入的 该数据 项内容 超出该 字段 数 据 类 型 可 处理范围 时的 处理 。 2) 对于有 可 能 返回 结 果 超 过 1000笔 的 查询语句 需优 化 、 走查 ， 着重 DAO、 数据库层 面 。 3) 任何 开发 涉及 到 数据 结 构 相 关的 变动 ， 均 需 考虑 生产上 已 有 数据 的 迁 移 、 升级操 作 ， 避免新 旧 数据 冲突 等 。 4) 数据

27、库 中 汉 字 存储 使用 3位 字 节 实 现， 客户端处理 作 2个 字 节 处理 ，在 设 计 数据库 表 、 DAO书 写 、 服 务 层 书 写 时需关 注 。 5) DAO、 产 品 层 接口 、 页面 数据 项 限制 、 数据库 字段 长 度等 是否 匹配 需要 统 一 安 排走查 /评审 。 6) 常见 的多 线 程不 安全 的 java方法 、对 象 如 下 ： xxxxxx。在 可 能多 线 程 访 问 的 地 方避免使用 以上内容 。 产品层： 7) 产 品 层 多 个 方法都 具 备 一 个 相 同 子 功能时， 请产 品 层 做 好 各 方法 中 子 功 能的 注 释

28、 ， 以明确各 方法 相 同 子 功能之间的 区别 。 海外： 8) 海 外 金额域 需 特别注 意 外 币整 数 、 小数 位位 数 等 。 9) 海 外 需 特别注 意其 特 有的时 区转换 问题 。 环境： 10) 参数 配置 应作为 开发的 一 部 分，要进行 复 查 、 评审 。 数据库 脚 本 亦然 。 客户端： 11) 页面 提交单个 数据 项 时，需 注 意 防止 其 他 地 方 隐藏 有 相 同 名称 数据 项 提 交 ， 构 成 数 组 导致程 序 错误。 12) 页面编写 需 注 意 JS提示 语 是否与 页面 数据 项一致 13) 下拉列表选择非第 一项 时， 页面 返

29、回 、 修改 等 下拉列表框 是否 定 位 正确 。 14) 下拉列表 数据 项过 多时 注 意 下拉列表框 是否 禁 用 滚 动 条 等 。 15) 对 客户端 的 内 部 、系统 测试 ， 建议采 用 多 版本 浏览器 进行。 16) 注 意统 一 对 外 支付 中间 接支付特殊 处理 ， 包括到 账 查询 、差错 处理 等 。 4.2 BUG分析收集建议如下： 1) Checklist未执 行 到 位 ，需 加大 推 行 力 度 。很多在 Checklist中 已 经 定 义 的 问题 ，在开发的 过程 中 仍然 出 现，如 日志 输出 问题 。 2) 注 意 变更 管 理 流 程 ，

30、变更 影响域 分析 等 需要 相 关 干 系人 走查 、 达 成 一致 ； 加 强 各 子 系统、 各 层 开发人员的 直接沟 通 力 度 。 3) 需求分析、 设 计、开发、 测试 时需 注 意异 常 情况 、错误 值 、 边界值 的 业 务 流 程 处理 、 设 计、开发、 测试 等 。 4) 各 小 组 、 产 品 层 应 加大 与其 他产 品线 的 接口 、 业务 处理 、差错 处理 等 讨 论 力 度 。 注 意对 数据 来源 异 常 的 判断和 处理 。 5) 项 目 组 成员 应 加 强 对需求的 理 解 ， 增 加 对中 后 台 的了 解 。 6) 牵 涉 到 信息 中 心维护

31、 的需求 请一 定 要 尽早 与 信息 中 心 进行事 前 沟 通。 7) 定期 对 SQL语句 进行优 化 ， 并将 成果 添加 到 Checklist中。在开发 过程 中对 可 能 出 现 大 于 1000笔查询返回 结 果的 SQL语句 要有意识的优 化 。 8) 参数 文 件 的 注 释 信息 要 全 面并 能 够 指 导生产 维护 方 便 生产 维护 。 交 易 码 定 义 时 给 出 相应 的 注 释 信息 。需要 重 视 参数 配置 ， 将 参数 配置 、 数据库 脚 本 作为 开发的 一 部 分 内容 ， 安 排走查 、 评审 等等 。 9) 及 早让 业务 人员 参 与 项

32、目 开发、 确 认 需求，否则 返 工所耗费 的人 力 资源 很 大 。 10) 需 重 视 英 文 版 ， 加 强 英 文 版测试 。 五、改进计划 以 上 缺陷分析 结果已发 部门质量 小组 ， 根据 部门 负责 人及质量 小组 建议 制定 以下 改进 计划 ， 更加 细 化 内容 参考 部门质量 小组 工作计划 ： 1. 根据 分析 结果 更 新 Checklist。 由 XX负责 。 2. 以 上 分析 建议 由 部门 负责 人确定是 否 补 入开发 规 范 。 由 XX负责跟 进。 3. 各 组 对分析 结果 进行 学 习 、 培训 ，要 求 各 组 培训 、 学 习 会 议 通 知 抄送 部 门 负责 人，部门 负责 人 视 情况 参 与 监督 学 习 情况 。 由 部门 负责 人 XXX 负责 。 4. 在后 续项目 中 跟踪 监 控 以 上 问题出 现 程度，在 下 一项目结 束 时会 对 以 上 内容 进行 再 次总结 。 由 XX负责跟 进。