2014缺陷管理规.docxVIP

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缺陷管理规范背景说明报告了大量的bug，如何有效地通过bug分析出当前产品的状况？报告了大量的bug，如何能快速地筛选出必须修复的缺陷？报告的bug如何被有效地处理存在问题：归类不准确，归类缺少，导致无法生成有效、准确的报告。在做报告时，要花大量的时间处理无效的bug要重新书写bug，因为bug写的不准确要重新归类，以确保报告的准确性根本就看不懂那些bug，怎么办啊？没有考虑对客户的影响分析，导致无法快速地筛选出哪些是必须修复的bug报告的bug不清楚、无效，导致投入大量的交互工作量报告了大量重复的bug报告了很多需要讨论但不会在当前版本实现的需求性bug。有些bug经过一个版本后自动消失了，所以为确保准确性，每次都需要对旧的bug进行反复确认验证。目的快速形成产品质量报告（通过提高bug规范质量，提高bug原始数据的有效性，科学性）使缺陷能够得到有效的处理，减少交互成本，提高问题的处理率提高缺陷处理效率，能够快速地找出需要特殊处理的bug减低无效bug率无效bug：描述错误、不准确的bug重复的bug归类不准确的bug未经确认的需求类bug错误的建议性bug基本规范原则其他人经常问测试部门的问题你觉得现在产品怎么样？他的问题集中在哪些地方？你觉得现在产品优势是什么？劣势是什么？隐患是什么？你觉得还要测试多久才能发布？请报告有效的bug？怎么来回答以上问题呢？告诉别人你的测试安排是怎样的？已经进行到什么阶段？每个阶段是针对什么方面进行的测试。每个测试阶段的开发单元测试通过率怎样、系统测试通过率怎样？[通过用例还是功能列表来体现？]Bug的状况怎样？Bug的处理状况怎样？ ------- 严重程度/bug状态表Bug的模块分布情况怎样？ ------- 模块/bug状态表Bug的模块都是什么类型的问题？ -----模块/问题类型分布图未处理的bug主要集中在哪些模块？有争议的bug主要集中在哪些模块？残留的问题哪些是被高频度使用、对客户严重影响的问题。Bug处理效率和走势怎样？处理效率必须尽可能地接近bug产生趋势；bug走势在后期回归测试必须处于收敛状态。工作量主要集中在谁身上，他的以往处理效率怎样？会不会出现瓶颈？前置条件:需要给别人讲清楚你的测试策划需要让别人通过你的测试用例设计，了解你的测试覆盖情况通过以上分析在bug中有些内容就很重要测试阶段的划分和明确（测试版本的定义），每个测试版本都要对应不同目的的测试阶段。系统模块的划分问题严重程度的明确定义问题类型的明确定义影响分析数据的积累。Bug状态的明确性。3.1 严重程度描述： 反映bug造成的影响价值： 通过这个字段反映需求质量和需求开发实现质量。 此字段+测试版本：可以反映出当前版本的开发质量。 此字段+模块：可以反映出当前某个模块的bug严重性。前置说明：以下规则基于将需求分为三级核心业务需求：需求中定义优先级别最高的模块；基础维护模块的新增模块。业务的核心基础逻辑：每个业务模块中最核心的实现业务的细节逻辑：每个模块的详细细节。例如：人员查询功能人员查询--非核心需求基础查询（录入所有查询字段 或者空字段，执行查询）为业务的核心基础逻辑-4级模糊查询，各种组合查询都为细节测试---3级功能实现错误分为3-5，3个级别反应到TD系统中，加强性bug体现在1-2级别级别定义5-urgent核心业务逻辑出错，导致系统无法使用核心需求无法满足实际情况核心需求，功能没有实现正确核心需求基础实现错误（基础常用数据测试）核心业务数据错误核心业务的脚本错误[非功能性问题]高并发性导致核心业务数据错误（实际业务会经常出现的并发）“合理业务量内”的性能问题系统响应比较慢或者无响应系统服务器崩溃导致重要数据丢失的安全性问题异常测试导致的系统无法恢复的崩溃系统黄页问题4-very high非核心需求的基础功能点失败非核心需求的主逻辑失败数据集成错误系统实际应用无法使用的功能建议（客户常用操作）压力或异常操作下，系统异常崩溃（超出常用场景的压力测试问题）普通的脚本错误（兼容错误）3-high细节需求规则、功能实现