缺陷管理规范

JINHER

缺陷管理规范系列

王锦山

2010-7-21

目录

1. 背景说明 (3)

2. 目的 (3)

3. 基本规范原则 (4)

3.1 严重程度 (4)

3.2 缺陷类别 (6)

3.3 用户影响分析 (8)

3.4 频繁性 (8)

4. 书写一个bug的基本规范 (8)

5. 特殊状况处理 (8)

5.1 Bug为什么无法重现？ (8)

5.2需求性bug怎么处理？ (9)

5.3如何处理重复bug的出现？ (9)

5.4 被取消的功能的相关bug怎么处理？ (9)

5.5 如何统计下版本需要修复的bug？ (9)

5.6一定要避免报告解决方案那样的bug？ (9)

5.7 为什么存在统计时需要重新核对bug的现象？ (9)

5.8 怎么理解开发部门提出的有效的bug的疑问？ (10)

6. 提高bug质量的检查方法 (10)

缺陷管理规范

1.背景说明

1．报告了大量的bug，如何有效地通过bug分析出当前产品的状况？

2．报告了大量的bug，如何能快速地筛选出必须修复的缺陷？

3．报告的bug如何被有效地处理

存在问题：

1．归类不准确，归类缺少，导致无法生成有效、准确的报告。

a)在做报告时，要花大量的时间处理无效的bug

b)要重新书写bug，因为bug写的不准确

c)要重新归类，以确保报告的准确性

d)根本就看不懂那些bug，怎么办啊？

2．没有考虑对客户的影响分析，导致无法快速地筛选出哪些是必须修复的bug

3．报告的bug不清楚、无效，导致投入大量的交互工作量

4．报告了大量重复的bug

5．报告了很多需要讨论但不会在当前版本实现的需求性bug。

6．有些bug经过一个版本后自动消失了，所以为确保准确性，每次都需要对旧的bug 进行反复确认验证。

2.目的

●快速形成产品质量报告（通过提高bug规范质量，提高bug原始数据的有效性，科学性）●使缺陷能够得到有效的处理，减少交互成本，提高问题的处理率

●提高缺陷处理效率，能够快速地找出需要特殊处理的bug

●减低无效bug率

无效bug：

1.描述错误、不准确的bug

2.重复的bug

3.归类不准确的bug

4.未经确认的需求类bug

5.错误的建议性bug

3.基本规范原则

其他人经常问测试部门的问题

●你觉得现在产品怎么样？他的问题集中在哪些地方？

●你觉得现在产品优势是什么？劣势是什么？隐患是什么？

●你觉得还要测试多久才能发布？

●请报告有效的bug？

怎么来回答以上问题呢？

第一.告诉别人你的测试安排是怎样的？已经进行到什么阶段？每个阶段是针对什么方面进行的测试。

第二.每个测试阶段的开发单元测试通过率怎样、系统测试通过率怎样？[通过用例还是功能列表来体现？]

第三.Bug的状况怎样？

i.Bug的处理状况怎样？------- 严重程度/bug状态表

ii.Bug的模块分布情况怎样？------- 模块/bug状态表

iii.Bug的模块都是什么类型的问题？-----模块/问题类型分布图

iv.未处理的bug主要集中在哪些模块？

v.有争议的bug主要集中在哪些模块？

第四.残留的问题哪些是被高频度使用、对客户严重影响的问题。

第五.Bug处理效率和走势怎样？处理效率必须尽可能地接近bug产生趋势；bug走势在后期回归测试必须处于收敛状态。

第六.工作量主要集中在谁身上，他的以往处理效率怎样？会不会出现瓶颈？

前置条件:

●需要给别人讲清楚你的测试策划

●需要让别人通过你的测试用例设计，了解你的测试覆盖情况

通过以上分析在bug中有些内容就很重要

1．测试阶段的划分和明确（测试版本的定义），每个测试版本都要对应不同目的的测试阶段。

2．系统模块的划分

3．问题严重程度的明确定义

4．问题类型的明确定义

5．影响分析数据的积累。

6．Bug状态的明确性。

3.1 严重程度

描述：

反映bug造成的影响

价值：

通过这个字段反映需求质量和需求开发实现质量。

此字段+测试版本：可以反映出当前版本的开发质量。

此字段+模块：可以反映出当前某个模块的bug严重性。

前置说明：

以下规则基于将需求分为三级

●核心业务需求：需求中定义优先级别最高的模块；基础维护模块的新增模块。

●业务的核心基础逻辑：每个业务模块中最核心的实现

●业务的细节逻辑：每个模块的详细细节。

例如：人员查询功能

●人员查询--非核心需求

●基础查询（录入所有查询字段或者空字段，执行查询）为业务的核心基础逻辑-4级●模糊查询，各种组合查询都为细节测试---3级

3.2 缺陷类别

价值分析：

通过类型分析，结合模块，我们可以分析出那些模块存在什么类型的问题，是需要加强那方面，是需要加强需求分析还是交互还是开发的进步技能。

主要类别说明

● 1. 需求缺陷：产品设计时存在的缺陷；

● 2. 功能错误：实现的功能与需求的功能描述不一致（包括一些潜规则需求）

● 3. 程序错误：程序开发错误，页面出错，如：黄页，白页，脚本错误，系统

崩溃、数据计算错误等；

⏹数据合法性控制缺陷：对系统录入的数据长度、类型等控制不合理等

⏹并发缺陷：并发处理造成的bug

⏹第三方兼容缺陷：IE、输入法等第三方软件与系统兼容的bug

● 4. 界面缺陷：页面风格不一致、提示用语不规范、页面布局混乱、错别字等

错误；

● 5. 易用性缺陷：使用不合理的缺陷，例如缺少友好向导提示、操作不方便等

错误

● 6. 性能问题：性能、系统稳定性的缺陷；

●7. 多语言缺陷

●8. 安装缺陷

●9. 文档缺陷

●10. 安全性缺陷

目前存在的困难是：

由于经常没有需求，分不清楚到底是需求没有说明还是开发没有做，这样要与需求人员沟通一下，看他的想法，如果他不清楚就是需求问题，如果他清楚那就定位功能错误。

◆需求缺陷：需求人员没有想明白

◆功能缺陷：需求人员想明白了，开发人员没弄明白

◆程序缺陷：两个都明白，开发代码做错了

常见的具体类型举例：

1．需求缺陷：

1503 公文套红无法在正文的任意位置进行套红[需求没有考虑实际的场景]

1505 公文类型目前只能指定至部门，而不能单独指定至人员，不符合实际使用场景862 由于流程节点名称相同，导致模板插入意见时无法区分[需求没有考虑细节设计] 2．功能缺陷

1154正文中的附件标签没有在流程中及时替换，而是流程结束后才替换, 稿纸中的及时替换（潜规则需求）

例如需求要求寻呼可以仅能转发给本部门的人，但实现不是这样的，那就是功能错误。3．程序缺陷：

1726 公文模板设置中在标签前输入字符，输入的字符也当成了标签