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