搜索
BUG管理规范及流程郑重声明：XX软件股份有限公司版权所有。本文档中任何部分未经XX软件股份有限公司书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播。目录1前言....................................................................32术语定义.................................................................33总则....................................................................44研发阶段缺陷管理.........................................................44.1缺陷表单说明.......................................................44.2流程...............................................................75维护阶段问题反馈及处理...................................................85.1问题表单...........................................................85.2流程...............................................................96附件...................................................................116.1缺陷管理工具选择..................................................116.2问题记录表........................................................131前言本文档用于描述“XX软件股份有限公司”软件生命周期中，产生的问题及缺陷的收集处理方法和参考规范。2术语定义术语英文定义备注缺陷影响客户正常使用的任何问题缺陷分类按照缺陷的严重程度分为：重大缺陷、待确认缺陷、一般缺陷。重大缺陷：指在软件开发过程中的针对软件产品和开发过程的问题，这些问题已经影响用户的正常使用。待确认的缺陷：指该缺陷需要测试人员进行重现和确认是否为缺陷。一般缺陷：指在软件开发过程中的针对软件产品和开发过程的问题，这些问题已经影响或者可能影响软件产品的质量问题问题指系统上线后，用户反馈的所有有关软件系统的问题，包括：需求和缺陷问题级别按照问题需要处理的紧迫程度分为：非常重要、重要、一般。可以从用户的满意度和修改的影响范围两个方面来定义。非常重要：优先级高，要求能在一周之内予以解决或者给出解决办法。重要：优先级一般，要求能在两周之内予以解决。一般：优先低，要求能在一个月之内解决需求分类按照需求特性分为：待讨论需求、特殊需求及一般需求。待讨论需求：指该需求需要经过产品组人员进行讨论。特殊需求：指该需求的特殊性，一般是工作量较大或是原需求上改动较大的需求。新需求：目前产品功能无法满足的需求点，该需求具有一定的通用性，可以完善产品问题确认确认指问题流转各环节对问题的处理意见。确术语英文定义备注认结果可分为：支持：经过分析该需求有开发价值或确认修改该缺陷。不支持：经过分析该问题无开发价值或实现困难。取消：由于某种原因该问题撤销，不需要继续处理。问题状态指问题所处的处理状态。分为：待处理、处理中、验证中、确认通过、关闭等。3总则该规范作为软件缺陷管理的参考规范，不作为强制性规范软件项目生命过程中缺陷的管理分为两个阶段：未发布版本前研发阶段的缺陷管理；发版后项目维护过程中用户反馈问题的管理。研发阶段的缺陷管理目标是测试过程中发现的缺陷的管理和跟踪，确保已发现缺陷都获得修复，同时通过缺陷反映产品质量状况；维护阶段问题反馈处理是产品或者项目已经上线使用，在使用过程中用户或者技服人员反馈缺陷及问题的管理办法，因为问题的收集环境比较复杂，填写问题的人员比较多，收集的方式应该便捷（如邮件、浏览器等）填写和提交比较简单，同时有专人对反馈的问题进行一轮过滤筛选。缺陷管理的字段除必填字段外，项目可根据需要自行增减这里定义的流程为推荐的最佳处理流程也可根据具体项目情况进行细节调整4研发阶段缺陷管理4.1缺陷表单说明可追踪信息缺陷ID唯一的缺陷ID，可以根据该ID追踪缺陷缺陷基本信息缺陷状态缺陷的状态，新建、打开、正修改、待验证、待确认、关闭、遗留缺陷摘要缺陷一句话描述严重级别A:致命问题(引起软件整体运行崩溃或破坏软件敏感数据的致命问题)；B:严重问题(功能测试出错，导致功能无法使用的问题)；C:一般问题(影响软件正常完成任务但仍能产生正确结果的问题，或者该功能测试出错，但可以通过其它方式实现该功能)；D:轻微问题/描述性问题(引起操作不舒服但并不影响软件完成任务的问题，或者软件中说明不确切或含义模糊或未准确使用专业术语，容易导致误解的问题)；E:改进建议(不影响软件完成任务或功能可以实现，但操作或显示方面需要改进的问题)。F待分类问题（不确定用户是否需要该功能或该功能应用场景不清楚）优先级别描述缺陷的紧急程度，高中低缺陷提交人缺陷提交人的名字（邮件地址）缺陷提交日期缺陷提交的时间缺陷所属产品缺陷所属产品、或者产品系列缺陷所属子项目所属子项目缺陷所属模块缺陷所属的模块，最好能较精确的定位至模块产品版本号产品版本号；如CI3.2；CI关联交易2.0；CI_仪表盘1.0期望解决版本CI对外版本号缺陷处理结果描述对处理结果的描述，如果对代码进行了修改，要求在此处体现出修改缺陷修正人最终处理缺陷的处理人获得解决版本解决该缺陷的版本号，由验证人员填写。缺陷解决日期缺陷来源错误产生原因：编码错误、设计缺陷、业务需求缺陷、编译配置问题、低级缺陷缺陷类别错误的类别：功能错误、数据错误、界面问题、安装配置其他缺陷提出人提出缺陷的人名缺陷的详细描述对缺陷的详细描述；之所以把这项单独列出来，是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改，描述应该尽可能详细；操作步骤及缺陷的表现测试环境说明对测试环境的描述操作系统、浏览器、中间件、数据库必要的附件对于某些文字很难表达清楚的缺陷，使用图片等附件是必要的其他：缺陷的历史流转记录及缺陷所有的操作；缺陷关联的条目；从创建到关闭花费时间1.必填字段缺陷摘要、严重级别、优先级别、缺陷所属产品、缺陷所属模块、产品版本号、缺陷处理结果描述、缺陷来源、缺陷类别、缺陷的详细描述2.选项字段缺陷状态：新建、退回、打开、正修改、待验证、关闭、遗留、待讨论严重级别：致命、严重、一般、建议优先级别：高中低缺陷所属产品：缺陷所属项目：缺陷所属模块：产品版本号：缺陷来源：编码错误、设计缺陷、业务需求缺陷、编译配置问题、低级缺陷缺陷类别：功能错误、数据错误、界面问题、安装配置3.自动生成字段：缺陷ID、缺陷提交人、缺陷提交日期、缺陷解决日期4.缺陷处理人填写的字段：缺陷处理结果描述；验证通过填写的字段：获得解决版本；其余字段由缺陷提交人填写。4.2流程缺陷管理流程提交打开修正验证研发经理缺陷修正人缺陷分发人缺陷提交人结束1判定缺陷提交分配是否否是退回确认关闭修改验证验证通过验证不通过2否判定缺陷有争议暂不修改判定是否修改遗留是是否打开1．缺陷提交人提交缺陷（缺陷提交人可以是项目组任何成员）可能根据项目情况选择是否需要“缺陷分发人”（一位或多位），如提交缺陷的人员无法判定该缺陷应该提交给哪位研发人员处理时；特别关注、需要保证提交缺陷的质量时；需要项目经理或者主要负责人对缺陷进行处理时。也可以提交人直接将缺陷提交给最终的缺陷修改人员如果缺陷被退回，再次确认是否为缺陷或者是否描述清晰，如果不是缺陷关闭缺陷，如果描述不清修改描述并重新提交2．打开缺陷缺陷分发人对缺陷进行判断，如果是缺陷分配给对应缺陷修正人员，如果不是缺陷或者描述不清，将缺陷退回提交人缺陷修正人判定是否为缺陷，如果是缺陷转为“正修改”状态；如果不是缺陷或者描述不清，将缺陷退回提交人新版本研发开始后，研发经理检查遗留问题，需要在此版本中解决的缺陷，将缺陷打开制定给修正人3．修正缺陷修正缺陷，将缺陷置为“待验证”如果缺陷修正人对缺陷是否要修改有争议，或者需要协调修改或者修改有不明确的因素，将缺陷置为“待讨论”研发经理处理“待讨论”缺陷，如果认为需要修正转给修正人员进行修正，如果认为不用修正直接关闭缺陷，如果可以遗留到下个版本在进行解决置为“遗留”状态4．缺陷验证测试人员对“待验证”的缺陷进行回归测试，如果验证通过关闭缺陷，如果验证不通过将缺陷置为“打开”，继续进行缺陷修正5维护阶段问题反馈及处理5.1问题表单字段字段说明*编号问题统一编号*功能模块功能模块或者功能分类*问题描述问题的详细描述*性质问题性质决定问题的下一步处理流程，分为：缺陷、重大缺陷、需求、待讨论需求、特殊需求（研发产品负责人填写）*版本所用版本号*项目名称提交此问题的具体项目名称*提出人提出人姓名*提出时间出题具体时间年月日*期望解决时间期望的解决时间预计解决时间预计解决时间（研发负责人填写）问题归类问题分类，可以分为：宕机、效率问题、美观性问题、易用性问题、数据正确性*问题级别问题严重级别，分为：非常重要、重要、一般问题解决方法具体解决办法（研发负责人填写）*研发人员确认情况支持、不支持（研发产品负责人填写）研发负责人研发负责人姓名*研发完成情况完成、未完成（研发负责人填写）研发完成时间（研发负责人填写）*测试确认情况可重现、不能重现、不存在、已解决、未解决（测试负责人填写）测试确认时间（测试负责人填写）*完成版本测试通过的版本号（测试负责人填写）实施确认情况已确认、未确认（实施人员填写）实施确认时间开始时间产品维护小组填写开始时间结束时间问题最终通过时间状态不支持关闭、支持待解决、支持正解决、解决关闭、取消关闭备注附件必填字段：打星号的为必填字段。缺陷状态区分：不支持关闭、支持待解决、支持正解决、解决关闭、取消关闭5.2流程缺陷管理流程提交分类处理验证研发人员测试人员研发产品负责人产品维护小组问题提交人结束提交通过修改验证验证通过验证不通过3一般缺陷、严重缺陷不是缺陷筛选过滤分类4需测试确认的缺陷问题确认重现缺陷重现确认通过未通过未通过取消1不是问题需求分析、需求规格2.2特殊需求2.3一般需求2.1带讨论需求需求讨论确认1．问题提交项目实施人员记录用户反馈问题，包括缺陷和需求，提交给产品维护小组成员如果产品线比较大，可以分为多个小组分别负责不同业务产品维护小组成员对提交的问题进行确认、过滤，对于不用研发处理的问题（如由于实施问题、用户理解和操作方式问题）要过滤掉，对于重复提交的问题进行合并，并将处理结果反馈给提交人对于确认过的问题，梳理后提交到“问题一览表”，或者通过缺陷管理工具提交到研发部门（要填写的字段有“编号”“功能模块”“问题描述”“版本”、“项目名称”、“提出人”、“提出时间”、“期望解决时间”、“问题归类”、“问题级别”、“开始时间”），如果有需要可同时抄送给产品相关干系人2．问题分类研发产品负责人对提交过来的问题进行分类，填写“问题性质”、“研发人员确认情况”字段，如果确认支持填写对应的“研发负责人”如果确认需求不予支持，填写不支持，并通知产品维护小组如果是一般缺陷、一般需求指派给确定的研发人员进行修正，并填写“预计解决时间”，转给相应研发人员如果是重大缺陷，将严重缺陷抄送给产品相关干系人（包括研发部门经理、测试负责人等），把问题级别定为“非常重要”，并指定研发人员和预计解决时间如果认为缺陷不明确或者需要测试人员验证，将性质填为“需测试验证缺陷”，转给测试