缺陷管理流程说明1

1、苏宁易购缺陷管理流程Error! Reference source not found.Error! Reference source not found.文档记录修订记录本次修订日期：下次修订日期： 版本号修订日期变更概述作者修订显示0.12012-8-30初始版本黄道勇否0.22013-07-1修订曹雄(IBM)，丁晓东否批准者此文档需要以下人员批准姓名职务分发此文档分发给以下部门或单位相关人员：姓名职务目 录1.综述52.缺陷定义62.1缺陷状态6Jira缺陷流程图6JIRA缺陷状态描述62.2解决结果72.3JIRA状态与解决结果对应表72.4缺陷严重程度82.5缺陷引入阶段112.6

2、缺陷根源122.7紧急程度122.8缺陷管理流程的角色和工作说明133.流程总览153.1流程目的153.2流程范围153.3流程开始153.4流程结束153.5解决结果说明153.6遗留缺陷定期清理163.7缺陷关闭和删除174.缺陷管理流程184.1流程图184.2流程解析191. 综述缺陷不仅仅是指软件的Bug，还包括需求、设计上的问题等；通常使用缺陷管理系统管理软件开发过程中所发现的缺陷。苏宁所有项目均需要统一使用JIRA工具进行缺陷管理。本文档将从缺陷定义、缺陷流程方面进行介绍，重点介绍缺陷管理的流程，涵盖的主要内容有流程目的、范围，缺陷的相关概念，缺陷管理的阶段和活动详细描述，以及

3、主要角色和工作职责。2. 缺陷定义2.1 缺陷状态2.1.1 Jira缺陷流程图2.1.2 JIRA缺陷状态描述序号状态描述1已提交新建的，已提交的缺陷2开发安排中缺陷被分配到具体解决人员3重新打开的测试人员复测不通过，被重新打开的缺陷4开发解决正在处理中的缺陷5已关闭被测试人员关闭的缺陷，表明缺陷在本项目中生命周期结束2.2 解决结果缺陷生命周期内的解决结果：序号解决结果描述1未解决新发现或者重新打开的缺陷，问题还未被处理2问题遗留暂不修复本版本内不解决，在以后的目标版本中解决。3重复问题重复的缺陷，不需要处理。4无法复现问题无法重现，没有足够的证据证明该问题存在，无法处理。5非问题经确认为

4、不是问题，不需要处理。6需求变更经确认为是需求，需要执行需求变更流程。7描述不完整缺陷单内的信息不充分，不能支持开发分析。8已解决已经被缺陷关系人处理修复的缺陷。9已验证通过缺陷报告人验证开发解决修复的缺陷，并进行关闭2.3 JIRA状态与解决结果对应表已提交开发安排中重新打开的开发解决已关闭未解决问题遗留暂不修复重复问题无法复现非问题需求变更描述不完整已解决已验证通过2.4 缺陷严重程度在测试过程中发现的缺陷按照严重程度分为五级：阻塞，致命，严重，一般，提示。只要满足定义描述中的一种情况，就可以判定为相应的严重程度。对每个严重程度的缺陷，有对修复时间的要求和对复测时间的要求，需要开发团队和测

5、试团队的响应配合，其详细定义及描述如下表：严重程度定义描述响应时间要求阻塞：· 系统不可用且需要立即解决例如：1、 重要功能未完成，主要业务流程不能完整进行，;2、 重要应用无法正常使用，重要业务流程错误或不完整; 3、 应用程序崩溃 4、 有其他计划执行的案例，由于此缺陷无法执行· 测试人员发现阻塞级别的缺陷，需要立即汇报测试组长和测试经理· 测试经理确认存在阻塞级别的缺陷，需要立即和项目经理、产品经理、开发经理进行沟通，协调解决致命：· 可能对业务功能和整个系统造成影响和损失· 系统不可用例如： 1、 安装异常，安装的数据丢失； 2、 因操

6、作导致业务数据紊乱或丢失;3、 系统关键性能严重不达标，引起系统挂死或影响系统运行;4、 数据库设计未达到要求或需求规格;5、 关键业务逻辑错误;6、 内存溢出;7、 系统中断(含软件、硬件)或非法退出，且无法通过重启恢复;8、 系统死循环; 9、 数据库死锁或数据库断连，且无法恢复; 10、 数据通讯错误或接口不通;11、 对操作系统造成破坏· 测试人员发现阻塞级别的缺陷，需要立即汇报测试组长和测试经理· 测试经理确认存在阻塞级别的缺陷，需要立即和项目经理、产品经理、开发经理进行沟通，协调解决严重：· 系统中单元模块或功能有缺失或错误· 问题不影响其他

7、模块的正常运行· 可以有替代办法例如：1、 业务数据保存不完整或无法保存到数据库；2、 数据处理错误;3、 业务逻辑错误，功能接口错误;4、 功能模块反应时间超出正常合理时间范围，性能不达标;5、 重要日志记录信息不正确或应记录而未记录;6、 界面校验错误或者提示信息与异常处理不符;7、 前端未合理控制并发或连续点击动作，导致后台服务无法及时响应;8、 在产品声明支持的不同平台下，出现部分应用无法使用或错误;9、 重要单据打印格式不符合要求，查询结果错误;10、 严重的文档错误，报表数据错误;· 测试经理或测试组长在确认严重级别的缺陷后，需要在4小时内和项目经理、产品经理、

8、开发经理进行沟通，协调解决一般： · 基本不影响系统的运行和功能的实现，但是存在与标准、规范和定义的不一致例如：1、 辅助说明描述不清楚，提示信息不明确或有错误；2、 输入输出不规范3、 长时间操作未给用户提示4、 输入限制未放在前台进行控制5、 拼写错误6、 界面不规范或者界面字段定义不准确7、 用户手册出现书写错误 8、 某些查询、报表导出等实时性要求不高的辅助功能错误; 9、 菜单布局，焦点控制，光标，滚动条等错误或不合理;10、 日志信息不够完整或不清晰; 11、 其他的一般性数据处理错误，一般程序错误;12、 删除操作未给出提示· 测试经理或测试组长当天与开发经理

9、确认一般缺陷的修复计划提示：· 功能增强与改进，或是建议优化的项，并非系统缺陷例如：1、 软件界面、菜单位置、工具条位置、相应提示不美观;2、 提示说明未采用行业规范语言; 3、 显示格式不规范，文本未对齐;4、 界面优化、功能易用性优化建议无要求2.5 缺陷引入阶段编号引入阶段描述1需求阶段在业务需求和系统需求进行评审，以挖掘需求中隐含的缺陷2设计阶段概要设计和详细设计阶段，通过评审、同行评审等手段，提前发现设计过程中可能的缺陷3开发阶段通过白盒测试、代码评审等方式进行动态或静态测试 4测试阶段由测试人员执行案例的方式，进行缺陷挖掘；由产品人员执行测试方式，进行需求确认和缺陷挖掘5

10、日常运维日常运维，线上维护阶段注：日常运维阶段引入的缺陷，属于运维故障，缺陷引入阶段不包含这个阶段。2.6 缺陷根源缺陷根源可用于对测试过程中所发现的缺陷进行根因分析，识别根本原因，并按照度量结果采取有针对性的解决方法和改进措施。在测试过程中产生的缺陷通常根源于以下几个方面编号根源描述1.需求错误由于错误的需求定义或已取消的需求引发的缺陷.2.开发错误开发与需求不一致，需要开发修改的，开发造成的功能缺失，功能实现错误，功能不完善而引发的缺陷.3.设计错误由产品设计不合理或不严谨引发的缺陷，包括系统设计，概要设计和详细设计.4编码错误程序代码中的错误5.测试环境错误测试环境搭建不合理或不严谨引发

11、的缺陷6测试数据错误测试数据准备不充分，不合理或不严谨引发的缺陷7部署错误被测版本部署方式/方法的不合理，没按照正确的部署流程部署而引发的缺陷2.7 紧急程度编号紧急程度描述1重大优先级1级，要求立即解决；如系统崩溃，丢失数据或内存溢出等严重错误;紧急需求，如重大促销活动，领导决策优先考虑的需求等2高优先级2级，要求当天内解决；如影响主营业务正常运行的错误3中优先级 3级，要求尽快解决；如主要的功能无效、新增功能建议;不影响正常业务运营的bug;紧急程度不高的一般需求4低优先级4级，如非常用功能无效或对现有系统的改进5次要问题或需求5级，拼写错误，文本未对齐等可改可不改的个人建议2.8 缺陷管

12、理流程的角色和工作说明角色描述工作说明测试人员测试执行人员· 识别缺陷· 记录并提交缺陷· 执行复测，检验缺陷是否成功解决· 重新打开或关闭缺陷测试组长测试组长· 协助测试经理履行部分缺陷管理职能· 进行测试执行识别、提交缺陷，并进行复测和关闭工作测试经理测试经理· 审核缺陷的有效性· 驳回不完整或描述有误的缺陷· 识别重复缺陷和无效缺陷，· 提交缺陷给项目经理审核分配· 管理缺陷，跟踪缺陷状态项目经理项目经理技术经理开发组长· 审核缺陷的有效性· 驳回不完整或描述

13、有误的缺陷· 识别重复缺陷和无效缺陷，· 评估需要延期修复的缺陷，· 分发缺陷给开发人员、需求人员或者开发组长分析修复人员开发组长· 识别重复缺陷或无效缺陷，退回给项目经理· 分析缺陷，分发给开发人员修改，或转发给其他团队的适合的受理人· 协调开发团队修复缺陷，参与评审或给出缺陷解决方案· 对需要延期的缺陷返回给项目经理，给出意见或参与评审开发人员· 识别重复缺陷或无效缺陷，退回给项目经理· 修改程序设计或代码的相关缺陷· 修改后的代码或程序自测完成后，提交测试人员复测需求人员· 识别

14、重复缺陷或无效缺陷，退回给项目经理· 解决业务需求相关的缺陷· 对需要延期的缺陷提供业务分析和决策3. 流程总览3.1 流程目的缺陷管理流程的目的是规范在缺陷管理过程中各方的职责和任务，提高缺陷管理的效率。同时，成功识别和解决测试发现的缺陷从而提高产品的质量，在测试过程中发生的所有缺陷都需要进行记录、分析、并查找根本原因，利用缺陷的相关度量指标进行统计分析，预测下一阶段的缺陷发生趋势。缺陷记录和相应的缺陷报告为项目提供主要管理信息，也能对于缺陷的解决方案进行优先级排序。3.2 流程范围本流程的使用范围包括了系统测试、系统集成测试和验收测试阶段，适用于测试人员、测试组长、测试

15、经理、项目经理、开发组长、开发人员、需求人员等。3.3 流程开始测试活动开始，测试执行人员识别出缺陷或继承上一版本暂不修复缺陷，本流程即开始。3.4 流程结束缺陷的JIRA状态为”已关闭”，即为缺陷在本项目中流程结束。缺陷的JIRA状态为”已关闭”，但解决结果为“问题遗留暂不修复”，视为该缺陷在项目中流程结束。但是该缺陷在产品/系统维度的生命周期未终结，在后续的相关项目中该缺陷需要被重新打开进行修复和验证。3.5 解决结果说明在解决结果被设置为以下选项时，需要确认相关的依据和证据已经被提交在JIRA中，才允许关闭缺陷：ü 设置解决结果为“重复问题”的缺陷，必须在备注中填写被重复的缺陷

16、单号，并由测试经理或测试组长确认后允许关闭；ü 设置解决结果为“需求变更”的缺陷，必须在备注中填写需求变更的JIRA单号，并由测试经理或测试组长确认后允许关闭；ü 设置解决结果为“非问题”的缺陷，必须在备注中填写说明为非问题的详细原因，可以添加附件说明.，由测试经理或测试组长确认后允许关闭；ü 设置解决结果为“无法复现”的缺陷，开发人员必须和测试人员充分沟通，由测试经理或测试组长确认后允许关闭；ü 设置为“已解决”的缺陷，必须由缺陷提出人进行验证后关闭，并最终将解决结果置为“已验证通过”；ü 设置解决结果为“问题遗留不修复”的缺陷，必须是在JI

17、RA中留下同意遗留的证据（领导备注确认遗留信息或附件领导同意遗留的邮件、ST聊天记录）。最后由测试经理或测试组长确认有相关的证据后，允许在本项目中关闭缺陷：n 缺陷等级为阻塞、致命的缺陷，需要提供中心领导确认同意遗留的信息至JIRA中；n 缺陷等级为严重的缺陷，需要提供项目经理和对应产品部门的领导确认同意遗留的信息至JIRA中；n 缺陷等级为一般和提示的缺陷，需要提供项目经理和对应产品经理确认同意遗留的信息至JIRA中。3.6 遗留缺陷定期清理各中心的测试负责人有责任参与和推动遗留缺陷的清理工作。测试负责人需在每个项目开始前统计JIRA中对应系统遗留的缺陷清单，并在该项目发布会上，由中心领导和

18、项目经理确定本次项目中需要修复的遗留缺陷。确定本次项目需要修复的遗留缺陷后：ü 由项目测试经理/测试组长，在JIRA中重开确定的遗留缺陷；n 使用JIRA中“恢复开启问题”功能按钮，重新打开遗留缺陷（缺陷状态被置为“重新打开的”，解决结果被置为“未解决”）；n 编辑缺陷，在“遗留缺陷修复项目”中填写本次项目名称。ü 遗留缺陷被修复，并在测试人员确认后，该缺陷的状态被置为“已关闭”、解决结果被置为“已验证通过”。3.7 缺陷关闭和删除ü 只有缺陷报告人才能将缺陷的JIRA状态置为“关闭”的状态。（JIRA中设定的测试经理亦有关闭权限，以备不时之需）。非缺陷报告人及测

19、试经理关闭的缺陷，该缺陷必须重新打开。ü 只有缺陷报告人才能编辑缺陷，非缺陷报告人无权编辑缺陷。ü 任何缺陷一经提交，均不允许删除。（JIRA中取消缺陷删除操作）。4. 缺陷管理流程4.1 流程图4.2 流程解析活动编号角色活动名称活动说明010测试组长/测试工程师(问题提出人)识别缺陷1. 在测试执行过程中某一操作/过程/结果是否是缺陷2. 后续020编号活动015项目经理继承本系统的历史遗留缺陷1. 在测试执行开始之前，项目经理确定需要继承并在本项目中修复的本系统历史遗留缺陷2. 后续017编号活动017测试组长/测试工程师重开缺陷1. 测试经理对重新打开历史遗留缺陷（

20、使用JIRA中“恢复开启问题”功能按钮）2. 缺陷状态设为“重新打开”3. 缺陷解决结果为“未解决“4. 编辑缺陷，添加“遗留缺陷修复项目”内容5. 后续070编号活动020测试组长/测试工程师(问题提出人)记录并提交缺陷1. 在jira中填写新的缺陷记录（需满足JIRA问题单填写规范的要求）2. 后续030编号活动030测试组长/测试经理判断缺陷是否有效1. 经测试经理/组长判断为非有效缺陷2. 后续120编号活动3. 经测试经理/组长判断为有效缺陷4. 后续040编号活动040开发工程师(问题解决人)是否非缺陷1. 开发人员判断为有效缺陷2. 后续050编号活动3. 开发人员判断为非有效缺

21、陷4. 后续130编号活动050开发工程师(问题解决人)是否需求问题1. 开发人员分析是需求问题2. 后续150编号活动3. 开发人员分析判断为非需求问题4. 后续060编号活动060开发工程师(问题解决人)是否遗留1. 开发人员分析此缺陷需要遗留2. 后续170编号活动3. 开发人员分析此缺陷不需要遗留4. 后续070编号活动070开发工程师(问题解决人)修复缺陷，并发布安装新版本1. 开发人员开始修复缺陷2. 修复完成后提交发布申请单3. 后续080编号活动080测试组长/测试工程师(问题提出人)复测缺陷1. 测试人员按照版本发布单中列出的问题修复列表，复测/回归缺陷2. 复测/回归通过3

22、. 后续090编号活动4. 复测/回归不通过5. 后续110编号活动090测试组长/测试工程师(问题提出人)是否通过复测1. 测试人员确认复测/回归通过2. 在缺陷单的备注中填写XXX版本复测/回归通过3. 后续100编号活动4. 测试人员确认复测/回归不通过5. 在缺陷单的备注中填写XXX版本复测/回归不通过6. 后续110编号活动100测试组长/测试工程师(问题提出人)关闭缺陷1. 此缺陷单流程结束2. 状态为“已关闭”3. 解决结果为“已关闭”或“问题遗留不修复”（原解决结果为“已解决”、“非问题”、“重复问题”、“需求变更”、“无法重新”的缺陷，在本活动之后，解决结果变为“已关闭”）110测试组长/测试工程师(问题提出人)重开缺陷3. 测试人员对开发人员提交的修复缺陷进行复测/回归，但不通过4. 把缺陷状态设为“重新