BUG 管理规范及流程 郑重声明： XX 软件股份有限公司版权所有。本文档中任何部分未经 XX 软件股份有限公 司书面授权，不得将材料泄露给第三方，不得以任何手段、任何形式进行复制与传播。 目录 1 前言..............................................................................................................3 2 术语定义........................................................................................................3 3 总则..............................................................................................................4 4 研发阶段缺陷管理...........................................................................................4 5 6 4.1 缺陷表单说明........................................................................................4 4.2 流程.....................................................................................................6 维护阶段问题反馈及处理..................................................................................7 5.1 问题表单...............................................................................................7 5.2 流程.....................................................................................................8 附件..............................................................................................................9 6.1 缺陷管理工具选择..................................................................................9 6.2 问题记录表.........................................................................................10 1 前言 本文档用于描述“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． 打开缺陷 缺陷分发人对缺陷进行判断，如果是缺陷分配给对应缺陷修正人员，如果不是 缺陷或者描述不清，将缺陷退回提交人 缺陷修正人判定是否为缺陷，如果是缺陷转为“正修改”状态；如果不是缺陷或者 描述不清，将缺陷退回提交人 新版本研发开始后，研发经理检查遗留问题，需要在此版本中解决的缺陷，将 缺陷打开制定给修正人 3． 修正缺陷 修正缺陷，将缺陷置为“待验证” 如果缺陷修正人对缺陷是否要修改有争议，或者需要协调修改或者修改有不明 确的因素，将缺陷置为“待讨论” 研发经理处理“待讨论”缺陷，如果认为需要修正转给修正人员进行修正，如果认 为不用修正直接关闭缺陷，如果可以遗留到下个版本在进行解决置为“遗留”状态 4． 缺陷验证 测试人员对“待验证”的缺陷进行回归测试，如果验证通过关闭缺陷，如果验证不 通过将缺陷置为“打开”，继续进行缺陷修正 5 维护阶段问题反馈及处理 5.1 问题表单 字段 字段说明 *编号 问题统一编号 *功能模块 功能模块或者功能分类 *问题描述