缺陷管理规范

1、. .JINHER缺陷管理规范系列王锦山2010-7-21目录1.背景说明32.目的33.根本标准原那么43.1 严重程度43.2 缺陷类别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质量的检查方法10缺陷管理

2、标准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. 目的l 快速形成产品质量报告通过提高bug标准质量，提高bug原始数据的有效性，科学性l 使缺陷能够得到有效的处理，减少交互本钱，提高问题的处理率l 提高缺陷处理效率，能够快速地找出需要特殊处理的bugl 减低无效bug率无效bug：1. 描述错误、不准确的bug2. 重复的bug3. 归类不准确的bug4. 未经确认的需求类bug5. 错误的建议性bug3. 根本标准原那么其他人经常问测试部门的问题l 你觉得现在产品怎么样？他的问题集中在哪些地方？l 你觉得现在产品优势是

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

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

6、价值：通过这个字段反映需求质量和需求开发实现质量。此字段+测试版本：可以反映出当前版本的开发质量。此字段+模块：可以反映出当前某个模块的bug严重性。前置说明：以下规那么基于将需求分为三级l 核心业务需求：需求中定义优先级别最高的模块；根底维护模块的新增模块。l 业务的核心根底逻辑：每个业务模块中最核心的实现l 业务的细节逻辑：每个模块的详细细节。例如：人员查询功能l 人员查询-非核心需求l 根底查询录入所有查询字段或者空字段，执行查询为业务的核心根底逻辑-4级l 模糊查询，各种组合查询都为细节测试-3级功能实现错误分为3-5，3个级别反响到TD系统中，加强性bug表达在1-2级别5-urge

7、nt核心业务逻辑出错，导致系统无法使用l 核心需求无法满足实际情况l 核心需求，功能没有实现正确l 核心需求根底实现错误根底常用数据测试l 核心业务数据错误l 核心业务的脚本错误非功能性问题l 高并发性导致核心业务数据错误实际业务会经常出现的并发l “合理业务量内的性能问题n 系统响应比较慢或者无响应n 系统效劳器崩溃l 导致重要数据丧失的平安性问题l 异常测试导致的系统无法恢复的崩溃l 系统黄页问题4-very highl 非核心需求的根底功能点失败l 非核心需求的主逻辑失败l 数据集成错误l 系统实际应用无法使用的功能建议客户常用操作l 压力或异常操作下，系统异常崩溃超出常用场景的压力测试

8、问题l 普通的脚本错误兼容错误3-highl 细节需求规那么、功能实现的验证错误l 核心页面的界面错误2-mediuml 低并发产生的并发问题l 数据合法性控制的错误l 普通界面错误l 易用性bugl 文档或者帮助的错误1-low需求类bugl 建议性功能完善操作建议类bugl 建议操作性bug3.2 缺陷类别价值分析：通过类型分析，结合模块，我们可以分析出那些模块存在什么类型的问题，是需要加强那方面，是需要加强需求分析还是交互还是开发的进步技能。主要类别说明l 1. 需求缺陷：产品设计时存在的缺陷；l 2. 功能错误：实现的功能与需求的功能描述不一致包括一些潜规那么需求l 3. 程序错误：程

9、序开发错误，页面出错，如：黄页，白页，脚本错误，系统崩溃、数据计算错误等；n 数据合法性控制缺陷：对系统录入的数据长度、类型等控制不合理等n 并发缺陷：并发处理造成的bugn 第三方兼容缺陷：IE、输入法等第三方软件与系统兼容的bugl 4. 界面缺陷：页面风格不一致、提示用语不标准、页面布局混乱、错别字等错误；l 5. 易用性缺陷：使用不合理的缺陷，例如缺少友好向导提示、操作不方便等错误l 6. 性能问题：性能、系统稳定性的缺陷；l 7. 多语言缺陷l 8. 安装缺陷l 9. 文档缺陷l 10. 平安性缺陷目前存在的困难是：由于经常没有需求，分不清楚到底是需求没有说明还是开发没有做，这样要与

10、需求人员沟通一下，看他的想法，如果他不清楚就是需求问题，如果他清楚那就定位功能错误。u 需求缺陷：需求人员没有想明白u 功能缺陷：需求人员想明白了，开发人员没弄明白u 程序缺陷：两个都明白，开发代码做错了常见的具体类型举例：1需求缺陷：1503 公文套红无法在正文的任意位置进展套红需求没有考虑实际的场景1505 公文类型目前只能指定至部门，而不能单独指定至人员，不符合实际使用场景 862 由于流程节点名称一样，导致模板插入意见时无法区分需求没有考虑细节设计2功能缺陷1154正文中的附件标签没有在流程中及时替换，而是流程完毕后才替换, 稿纸中的及时替换潜规那么需求例如需求要求寻呼可以仅能转发给本

11、部门的人，但实现不是这样的，那就是功能错误。3程序缺陷：1726公文模板设置中在标签前输入字符，输入的字符也当成了标签3.1 数据合法防御检测1. 对超长的字符没有控制相对于数据库保存、以及集成其他模块应用2. 对空格前、后没有合理处理3. 对特殊字符没有做合理控制4. 日期先后没有控制3.2 并发缺陷31 并行操作时，收文流程可以使用已被删除的收文类型。4界面问题：1. 界面控件没有合理的显示形式a) 只读工程高亮b) 连接无向导显示c) 输入工程没有被聚焦2. 没有采用习惯的控件a) 唯一选择没有选用单项选择钮3. 界面内容不正确a) 错误的提示语，向导内容不准确b) 错别字c) 包括标题

12、和状态栏目4. 界面实现风格不统一a) 不同的操作方式或步骤不同的查询方式、不同新增保存方式b) 界面样式风格不一致c) 界面字体不统一5. 界面命名不一致a) 例如新增、添加、保存等一个意思。6. 页面布局问题a) 控件范围太小，导致内容丧失或者折行7. 界面样式不标准a) 采用了更大的字体8. 提示标示不清楚a) 不符合用户习惯b) 不易分辨5易用性问题1. 没有正确的向导提示a) 例如删除成功没有删除提示b) 保存成功无保存提示2. 界面元素不易操作a) 菜单过细过密，不太好找3. 操作方式不符合常人习惯4. 没有友好提示a) 必须填写的工程没有必填标示5. 界面刷新不及时，出现错误数据

13、显示3.3 用户影响分析如果你之前准备工作做得好，你应该已经知道你的客户是谁，你的每个客户群中会有多少或者是你希望有多少用户。这样你就需要判断，这个问题将会影响到每位用户，还是仅仅一局部人。如果你能追踪出客户如何使用你的产品，你就能得到更准确的数据。核心人员、核心功能、核心界面严重影响-中等影响-低影响加强性-3.4 频繁性用户碰到这个问题的频率高吗？它是程序主要工作流程中的一局部？还是隐藏在一个并不常用的功能中？在最常用的那局部程序中存在的小问题很可能是需要修复的，而一些不常用到的那局部程序中存在的大问题，也许我们会放在一边。4. 书写一个bug的根本标准 1 描述一定是问题的描述，要求简练

14、明了一看描述就知道是什么问题2 步骤不要写成一堆步骤是重现的步骤，要1. 2. 3. 步骤的写清楚3 一定要抓图说明问题5. 特殊状况处理5.1 Bug为什么无法重现？原因分析：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不处理代码的修改