缺陷管理规范

JINHER缺陷管理规范系列王锦山2010-7-21目录1.背景说明...................................................................................................................................32.目的...........................................................................................................................................33.基本规范原则...........................................................................................................................43.1严重程度............................................................................................................................43.2缺陷类别............................................................................................................................63.3用户影响分析....................................................................................................................83.4频繁性................................................................................................................................84.书写一个bug的基本规范.......................................................................................................85.特殊状况处理...........................................................................................................................85.1Bug为什么无法重现？......................................................................................................85.2需求性bug怎么处理？.....................................................................................................95.3如何处理重复bug的出现？.............................................................................................95.4被取消的功能的相关bug怎么处理？............................................................................95.5如何统计下版本需要修复的bug？.................................................................................95.6一定要避免报告解决方案那样的bug？..........................................................................95.7为什么存在统计时需要重新核对bug的现象？............................................................95.8怎么理解开发部门提出的有效的bug的疑问？..........................................................106.提高bug质量的检查方法.....................................................................................................10缺陷管理规范1.背景说明1．报告了大量的bug，如何有效地通过bug分析出当前产品的状况？2．报告了大量的bug，如何能快速地筛选出必须修复的缺陷？3．报告的bug如何被有效地处理存在问题：1．归类不准确，归类缺少，导致无法生成有效、准确的报告。a)在做报告时，要花大量的时间处理无效的bugb)要重新书写bug，因为bug写的不准确c)要重新归类，以确保报告的准确性d)根本就看不懂那些bug，怎么办啊？2．没有考虑对客户的影响分析，导致无法快速地筛选出哪些是必须修复的bug3．报告的bug不清楚、无效，导致投入大量的交互工作量4．报告了大量重复的bug5．报告了很多需要讨论但不会在当前版本实现的需求性bug。6．有些bug经过一个版本后自动消失了，所以为确保准确性，每次都需要对旧的bug进行反复确认验证。2.目的快速形成产品质量报告（通过提高bug规范质量，提高bug原始数据的有效性，科学性）使缺陷能够得到有效的处理，减少交互成本，提高问题的处理率提高缺陷处理效率，能够快速地找出需要特殊处理的bug减低无效bug率无效bug：1.描述错误、不准确的bug2.重复的bug3.归类不准确的bug4.未经确认的需求类bug5.错误的建议性bug3.基本规范原则其他人经常问测试部门的问题你觉得现在产品怎么样？他的问题集中在哪些地方？你觉得现在产品优势是什么？劣势是什么？隐患是什么？你觉得还要测试多久才能发布？请报告有效的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-5，3个级别反应到TD系统中，加强性bug体现在1-2级别级别定义5-urgent核心业务逻辑出错，导致系统无法使用核心需求无法满足实际情况核心需求，功能没有实现正确核心需求基础实现错误（基础常用数据测试）核心业务数据错误核心业务的脚本错误[非功能性问题]高并发性导致核心业务数据错误（实际业务会经常出现的并发）“合理业务量内”的性能问题系统响应比较慢或者无响应系统服务器崩溃导致重要数据丢失的安全性问题异常测试导致的系统无法恢复的崩溃系统黄页问题4-veryhigh非核心需求的基础功能点失败非核心需求的主逻辑失败数据集成错误系统实际应用无法使用的功能建议（客户常用操作）压力或异常操作下，系统异常崩溃（超出常用场景的压力测试问题）普通的脚本错误（兼容错误）3-high细节需求规则、功能实现的验证错误核心页面的界面错误2-medium低并发产生的并发问题数据合法性控制的错误普通界面错误易用性bug文档或者帮助的错误1-low[需求类bug]建议性功能完善[操作建议类bug]建议操作性bug3.2缺陷类别价值分析：通过类型分析，结合模块，我们可以分析出那些模块存在什么类型的问题，是需要加强那方面，是需要加强需求分析还是交互还是开发的进步技能。主要类别说明1.需求缺陷：产品设计时存在的缺陷；2.功能错误：实现的功能与需求的功能描述不一致（包括一些潜规则需求）3.程序错误：程序开发错误，页面出错，如：黄页，白页，脚本错误，系统崩溃、数据计算错误等；数据合法性控制缺陷：对系统录入的数据长度、类型等控制不合理等并发缺陷：并发处理造成的bug第三方兼容缺陷：IE、输入法等第三方软件与系统兼容的bug4.界面缺陷：页面风格不一致、提示用语不规范、页面布局混乱、错别字等错误；5.易用性缺陷：使用不合理的缺陷，例如缺少友好向导提示、操作不方便等错误6.性能问题：性能、系统稳定性的缺陷；7.多语言缺陷8.安装缺陷9.文档缺陷10.安全性缺陷目前存在的困难是：由于经常没有需求，分不清楚到底是需求没有说明还是开发没有做，这样要与需求人员沟通一下，看他的想法，如果他不清楚就是需求问题，如果他清楚那就定位功能错误。需求缺陷：需求人员没有想明白功能缺陷：需求人员想明白了，开发人员没弄明白程序缺陷：两个都明白，开发代码做错了常见的具体类型举例：1．需求缺陷：1503公文套红无法在正文的任意位置进行套红[需求没有考虑实际的场景]1505公文类型目前只能指定至部门，而不能单独指定至人员，不符合实际使用场景862由于流程节点名称相同，导致模板插入意见时无法区分[需求没有考虑细节设计]2．功能缺陷1154正文中的附件标签没有在流程中及时替换，而是流程结束后才替换,稿纸中的及时替换（潜规则需求）例如需求要求寻呼可以仅能转发给本部门的人，但实现不是这样的，那就是功能错误。3．程序缺陷：1726公文模板设置中在标签前输入字符，输入的字符也当成了标签3.1数据合法防御检测1.对超长的字符没有控制（相对于数据库保存、以及集成其他模块应用）2.对空格（前、后）没有合理处理3.对特殊字符没有做合理控制4.日期先后没有控制3.2并发缺陷31并行操作时，收文流程可以使用已被删除的收文类型。4．界面问题：1.界面控件没有合理的显示形式a)只读项目高亮b