缺陷管理规范

1、JINHER缺陷管理规范系列王锦山2010-7-21目录1. 背景说明32. 目的33. 基本规范原则43.1严重程度43.2缺陷类另U 63.3用户影响分析83.4频繁性84. 书写一个 bug的基本规范 85. 特殊状况处理85.1 Bug为什么无法重现? 85.2需求性bug怎么处理？ 95.3如何处理重复 bug的出现？ 95.4被取消的功能的相关 bug怎么处理？ 95.5如何统计下版本需要修复的bug? 95.6 一定要避免报告解决方案那样的bug? 95.7为什么存在统计时需要重新核对bug的现象？ 95.8怎么理解开发部门提出的有效的bug的疑问？ 106. 提高bug质量的检

2、查方法 10缺陷管理规范1.背景说明1. 报告了大量的bug,如何有效地通过 bug分析出当前产品的状况？2. 报告了大量的bug,如何能快速地筛选出必须修复的缺陷？3. 报告的bug如何被有效地处理存在问题：1. 归类不准确，归类缺少，导致无法生成有效、准确的报告。a）在做报告时，要花大量的时间处理无效的bugb）要重新书写bug，因为bug写的不准确c）要重新归类，以确保报告的准确性d）根本就看不懂那些 bug,怎么办啊？2. 没有考虑对客户的影响分析，导致无法快速地筛选出哪些是必须修复的bug3. 报告的bug不清楚、无效，导致投入大量的交互工作量4. 报告了大量重复的bug5. 报告了

3、很多需要讨论但不会在当前版本实现的需求性bug。6. 有些bug经过一个版本后自动消失了，所以为确保准确性，每次都需要对旧的bug 进行反复确认验证。2.目的快速形成产品质量报告（通过提高bug规范质量，提高bug原始数据的有效性，科学性） 使缺陷能够得到有效的处理，减少交互成本，提高问题的处理率提高缺陷处理效率，能够快速地找出需要特殊处理的bug减低无效bug率无效bug:1.描述错误、不准确的bug2.3.4.5.重复的bug归类不准确的bug未经确认的需求类bug错误的建议性bug3.基本规范原则其他人经常问测试部门的问题你觉得现在产品怎么样？他的问题集中在哪些地方？你觉得现在产品优势是

4、什么？劣势是什么？隐患是什么？你觉得还要测试多久才能发布？请报告有效的bug?怎么来回答以上问题呢？第一.告诉别人你的测试安排是怎样的？已经进行到什么阶段？每个阶段是针对什么方面进行的测试。第二.每个测试阶段的开发单元测试通过率怎样、系统测试通过率怎样？通过用例还是功能列表来体现？第三.Bug的状况怎样？ii.iii.Bug的处理状况怎样？Bug的模块分布情况怎样？Bug的模块都是什么类型的问题?严重程度/bug状态表 模块/bug状态表模块/问题类型分布图iv. 未处理的bug主要集中在哪些模块？v. 有争议的bug主要集中在哪些模块？第四.残留的问题哪些是被高频度使用、对客户严重影响的问题

5、。第五.Bug处理效率和走势怎样？处理效率必须尽可能地接近bug产生趋势；bug走势在后期回归测试必须处于收敛状态。第六.工作量主要集中在谁身上，他的以往处理效率怎样？会不会出现瓶颈？前置条件：需要给别人讲清楚你的测试策划需要让别人通过你的测试用例设计，了解你的测试覆盖情况通过以上分析在 bug中有些内容就很重要1. 测试阶段的划分和明确（测试版本的定义），每个测试版本都要对应不同目的的测 试阶段。2. 系统模块的划分3. 问题严重程度的明确定义4. 问题类型的明确定义5. 影响分析数据的积累。6. Bug状态的明确性。3.1严重程度描述：反映bug造成的影响价值：通过这个字段反映需求质量和需

6、求开发实现质量。此字段+测试版本：可以反映出当前版本的开发质量。此字段+模块：可以反映出当前某个模块的bug严重性。前置说明：以下规则基于将需求分为三级核心业务需求：需求中定义优先级别最高的模块；基础维护模块的新增模块。业务的核心基础逻辑：每个业务模块中最核心的实现业务的细节逻辑：每个模块的详细细节。例如：人员查询功能人员查询-非核心需求基础查询（录入所有查询字段或者空字段，执行查询）为业务的核心基础逻辑-4级模糊查询，各种组合查询都为细节测试-3级功能实现错误分为 3-5, 3个级别反应到TD系统中，加强性bug体现在1-2级别级别定义5-urgent核心业务逻辑出错，导致系统无法使用核心需

7、求无法满足实际情况核心需求，功能没有实现正确核心需求基础实现错误（基础常用数据测试）核心业务数据错误核心业务的脚本错误非功能性问题高并发性导致核心业务数据错误 （实际业务会经常出现的并发）“合理业务量内”的性能问题系统响应比较慢或者无响应系统服务器崩溃导致重要数据丢失的安全性问题异常测试导致的系统无法恢复的崩溃系统黄页问题4-very high非核心需求的基础功能点失败非核心需求的主逻辑失败数据集成错误系统实际应用无法使用的功能建议（客户常用操作）压力或异常操作下，系统异常崩溃（超出常用场景的压力测试问题） 普通的脚本错误（兼容错误）3-high细节需求规则、功能实现的验证错误 核心贝面的界面

8、错误2-medium低并发产生的并发问题 数据合法性控制的错误 普通界面错误易用性bug文档或者帮助的错误1-low需求类bug建议性功能完善操作建议类bug建议操作性bug3.2缺陷类别价值分析:通过类型分析，结合模块，我们可以分析出那些模块存在什么类型的问题，是需要加强那方面，是需要加强需求分析还是交互还是开发的进步技能。主要类别说明1. 需求缺陷：产品设计时存在的缺陷；2. 功能错误：实现的功能与需求的功能描述不一致（包括一些潜规则需求）3. 程序错误：程序开发错误，页面出错，如：黄页，白页，脚本错误，系统 崩溃、数据计算错误等；数据合法性控制缺陷：对系统录入的数据长度、类型等控制不合理

9、等并发缺陷：并发处理造成的bug第三方兼容缺陷：IE、输入法等第三方软件与系统兼容的bug4. 界面缺陷：页面风格不一致、提示用语不规范、页面布局混乱、错别字等 错误；5. 易用性缺陷：使用不合理的缺陷，例如缺少友好向导提示、操作不方便等 错误6. 性能问题：性能、系统稳定性的缺陷；7. 多语言缺陷8. 安装缺陷9. 文档缺陷10. 安全性缺陷目前存在的困难是：由于经常没有需求，分不清楚到底是需求没有说明还是开发没有做，这样要与需求人 员沟通一下，看他的想法，如果他不清楚就是需求问题，如果他清楚那就定位功能错误。需求缺陷功能缺陷程序缺陷需求人员没有想明白需求人员想明白了，开发人员没弄明白两个都

10、明白，开发代码做错了 常见的具体类型举例：1. 需求缺陷：1503公文套红无法在正文的任意位置进行套红需求没有考虑实际的场景1505公文类型目前只能指定至部门，而不能单独指定至人员，不符合实际使用场景862由于流程节点名称相同，导致模板插入意见时无法区分需求没有考虑细节设计2. 功能缺陷1154正文中的附件标签没有在流程中及时替换，而是流程结束后才替换，稿纸中的及时替换（潜规则需求）例如需求要求寻呼可以仅能转发给本部门的人，但实现不是这样的，那就是功能错误。3. 程序缺陷：1726公文模板设置中在标签前输入字符，输入的字符也当成了标签3.1数据合法防御检测1. 对超长的字符没有控制(相对于数据

11、库保存、以及集成其他模块应用)2. 对空格(前、后)没有合理处理3. 对特殊字符没有做合理控制4. 日期先后没有控制3.2并发缺陷31并行操作时，收文流程可以使用已被删除的收文类型。4. 界面问题：1. 界面控件没有合理的显示形式a) 只读项目高亮b) 连接无链接向导显示c) 输入项目没有被聚焦2. 没有采用习惯的控件a) 唯一选择没有选用单选钮3. 界面内容不正确a) 错误的提示语，向导内容不准确b) 错别字c) 包括标题和状态栏目4. 界面实现风格不统一a) 不同的操作方式或步骤(不同的查询方式、不同新增保存方式)b) 界面样式风格不一致c) 界面字体不统一5. 界面命名不一致a)例如新增

12、、添加、保存等一个意思。6. 页面布局问题a)控件范围太小，导致内容丢失或者折行7. 界面样式不标准a)采用了更大的字体8. 提示标示不清楚a) 不符合用户习惯b) 不易分辨5. 易用性问题1. 没有正确的向导提示a) 例如删除成功没有删除提示b) 保存成功无保存提示2. 界面元素不易操作a)菜单过细过密，不太好找3. 操作方式不符合常人习惯4. 没有友好提示a)必须填写的项目没有必填标示5. 界面刷新不及时，出现错误数据显示3.3用户影响分析如果你之前准备工作做得好， 你应该已经知道你的客户是谁， 你的每个客户群中会有多少 （或 者是你希望有多少） 用户。这样你就需要判断，这个问题将会影响到

13、每位用户，还是仅仅一 部分人。如果你能追踪出客户如何使用你的产品，你就能得到更准确的数据。核心人员、核心功能、核心界面严重影响-中等影响-低影响一加强性-3.4频繁性用户碰到这个问题的频率高吗？它是程序主要工作流程中的一部分？还是隐藏在一个 并不常用的功能中？在最常用的那部分程序中存在的小问题很可能是需要修复的，而一些不常用到的那部分程序中存在的大问题，也许我们会放在一边。4. 书写一个bug的基本规范1描述一定是问题的描述，要求简练明了（一看描述就知道是什么问题）2步骤不要写成一堆（步骤是重现的步骤，要 1. 2. 3.步骤的写清楚）3 一定要抓图说明问题5. 特殊状况处理5.1 Bug为什

14、么无法重现？原因分析：1. Bug的描述不准确2. Bug重现的环境不一致3. 开发与测试的版本不一致4. Bug本身存在偶发性5. 开发没有在集成环境下验证6. 在修复另外一个 bug把其中一个bug修复了注意原则：1. Bug描述步骤必须准确2. 在测试偶发的bug必须定位（可以找开发人员一起定位）3. 开发提交一个测试版本，在开发那边会同时建立一个集成环境，与测试环境一致，如果出现在本地无法重新的bug,请到开发集成环境下验证。如果仍无重现，请找测试员确认5.2需求性bug怎么处理？需求性bug必须与需求人员讨论，并确认其对客户的影响后，才可以报告到bug库中。5.3如何处理重复 bug的出现?5.4被取消的功能的相关 bug怎么处理?5.5如何统计下版本需要修复的bug ?5.6 一定要避免报告解决方案那样的bug ?5.7为什么存在统计时需要重新核对bug的现象?在测试报告时，需要重新把 bug看一边，检查一遍，以确保它是否存在 主要原因是在每个环节对bug的处理不严谨，存在打开的bug不处理代码的修改没有