缺陷管理流程说明

《缺陷管理流程说明》由会员分享，可在线阅读，更多相关《缺陷管理流程说明（21页珍藏版）》请在装配图网上搜索。

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、 因操作导致业务数据紊乱或丢失;3、 系统关键性能严峻不达标，引起

6、系统挂死或影响系统运行;4、 数据库设计未达到要求或需求规格;5、 关键业务逻辑错误;6、 内存溢出;7、 系统中断(含软件、硬件)或非法退出，且无法通过重启复原;8、 系统死循环; 9、 数据库死锁或数据库断连，且无法复原; 10、 数据通讯错误或接口不通;11、 对操作系统造成破坏 测试人员发觉堵塞级别的缺陷，须要马上汇报测试组长和测试经理 测试经理确认存在堵塞级别的缺陷，须要马上和项目经理、产品经理、开发经理进行沟通，协调解决严峻： 系统中单元模块或功能有缺失或错误 问题不影响其他模块的正常运行 可以有替代方法例如：1、 业务数据保存不完整或无法保存到数据库；2、 数据处理错误;3、 业

7、务逻辑错误，功能接口错误;4、 功能模块反应时间超出正常合理时间范围，性能不达标;5、 重要日志记录信息不正确或应记录而未记录;6、 界面校验错误或者提示信息与异样处理不符;7、 前端未合理限制并发或连续点击动作，导致后台服务无法刚好响应;8、 在产品声明支持的不同平台下，出现部分应用无法运用或错误;9、 重要单据打印格式不符合要求，查询结果错误;10、 严峻的文档错误，报表数据错误; 测试经理或测试组长在确认严峻级别的缺陷后，须要在4小时内和项目经理、产品经理、开发经理进行沟通，协调解决一般： 基本不影响系统的运行和功能的实现，但是存在与标准、规范和定义的不一样例如：1、 协助说明描述不清晰

8、，提示信息不明确或有错误；2、 输入输出不规范3、 长时间操作未给用户提示4、 输入限制未放在前台进行限制5、 拼法错误6、 界面不规范或者界面字段定义不精确7、 用户手册出现书写错误 8、 某些查询、报表导出等实时性要求不高的协助功能错误; 9、 菜单布局，焦点限制，光标，滚动条等错误或不合理;10、 日志信息不够完整或不清晰; 11、 其他的一般性数据处理错误，一般程序错误;12、 删除操作未给出提示 测试经理或测试组长当天与开发经理确认一般缺陷的修复支配提示： 功能增加与改进，或是建议优化的项，并非系统缺陷例如：1、 软件界面、菜单位置、工具条位置、相应提示不美观;2、 提示说明未采纳行

9、业规范语言; 3、 显示格式不规范，文本未对齐;4、 界面优化、功能易用性优化建议无要求2.5 缺陷引入阶段编号引入阶段描述1需求阶段在业务需求和系统需求进行评审，以挖掘需求中隐含的缺陷2设计阶段概要设计和具体设计阶段，通过评审、同行评审等手段，提前发觉设计过程中可能的缺陷3开发阶段通过白盒测试、代码评审等方式进行动态或静态测试 4测试阶段由测试人员执行案例的方式，进行缺陷挖掘；由产品人员执行测试方式，进行需求确认和缺陷挖掘5日常运维日常运维，线上维护阶段注：日常运维阶段引入的缺陷，属于运维故障，缺陷引入阶段不包含这个阶段。2.6 缺陷根源缺陷根源可用于对测试过程中所发觉的缺陷进行根因分析，识

10、别根本缘由，并依据度量结果实行有针对性的解决方法和改进措施。在测试过程中产生的缺陷通常根源于以下几个方面编号根源描述1.需求错误由于错误的需求定义或已取消的需求引发的缺陷.2.开发错误开发与需求不一样，须要开发修改的，开发造成的功能缺失，功能实现错误，功能不完善而引发的缺陷.3.设计错误由产品设计不合理或不严谨引发的缺陷，包括系统设计，概要设计和具体设计.4编码错误程序代码中的错误5.测试环境错误测试环境搭建不合理或不严谨引发的缺陷6测试数据错误测试数据打算不充分，不合理或不严谨引发的缺陷7部署错误被测版本部署方式/方法的不合理，没依据正确的部署流程部署而引发的缺陷2.7 紧急程度编号紧急程度

11、描述1重大优先级1级，要求马上解决；如系统崩溃，丢失数据或内存溢出等严峻错误;紧急需求，如重大促销活动，领导决策优先考虑的需求等2高优先级2级，要求当天内解决；如影响主营业务正常运行的错误3中优先级 3级，要求尽快解决；如主要的功能无效、新增功能建议;不影响正常业务运营的bug;紧急程度不高的一般需求4低优先级4级，如特别用功能无效或对现有系统的改进5次要问题或需求5级，拼法错误，文本未对齐等可改可不改的个人建议2.8 缺陷管理流程的角色和工作说明角色描述工作说明测试人员测试执行人员 识别缺陷 记录并提交缺陷 执行复测，检验缺陷是否胜利解决 重新打开或关闭缺陷测试组长测试组长 帮助测试经理履行

12、部分缺陷管理职能 进行测试执行识别、提交缺陷，并进行复测和关闭工作测试经理测试经理 审核缺陷的有效性 驳回不完整或描述有误的缺陷 识别重复缺陷和无效缺陷， 提交缺陷给项目经理审核安排 管理缺陷，跟踪缺陷状态项目经理项目经理技术经理开发组长 审核缺陷的有效性 驳回不完整或描述有误的缺陷 识别重复缺陷和无效缺陷， 评估须要延期修复的缺陷， 分发缺陷给开发人员、需求人员或者开发组长分析修复人员开发组长 识别重复缺陷或无效缺陷，退回给项目经理 分析缺陷，分发给开发人员修改，或转发给其他团队的适合的受理人 协调开发团队修复缺陷，参加评审或给出缺陷解决方案 对须要延期的缺陷返回给项目经理，给出看法或参加评

13、审开发人员 识别重复缺陷或无效缺陷，退回给项目经理 修改程序设计或代码的相关缺陷 修改后的代码或程序自测完成后，提交测试人员复测需求人员 识别重复缺陷或无效缺陷，退回给项目经理 解决业务需求相关的缺陷 对须要延期的缺陷供应业务分析和决策3. 流程总览3.1 流程目的缺陷管理流程的目的是规范在缺陷管理过程中各方的职责和任务，提高缺陷管理的效率。同时，胜利识别和解决测试发觉的缺陷从而提高产品的质量，在测试过程中发生的全部缺陷都须要进行记录、分析、并查找根本缘由，利用缺陷的相关度量指标进行统计分析，预料下一阶段的缺陷发生趋势。缺陷记录和相应的缺陷报告为项目供应主要管理信息，也能对于缺陷的解决方案进行

14、优先级排序。3.2 流程范围本流程的运用范围包括了系统测试、系统集成测试和验收测试阶段，适用于测试人员、测试组长、测试经理、项目经理、开发组长、开发人员、需求人员等。3.3 流程起先测试活动起先，测试执行人员识别出缺陷或继承上一版本暂不修复缺陷，本流程即起先。3.4 流程结束缺陷的JIRA状态为”已关闭”，即为缺陷在本项目中流程结束。缺陷的JIRA状态为”已关闭”，但解决结果为“问题遗留暂不修复”，视为该缺陷在项目中流程结束。但是该缺陷在产品/系统维度的生命周期未终结，在后续的相关项目中该缺陷须要被重新打开进行修复和验证。3.5 解决结果说明在解决结果被设置为以下选项时，须要确认相关的依据和证

15、据已经被提交在JIRA中，才允许关闭缺陷： 设置解决结果为“重复问题”的缺陷，必需在备注中填写被重复的缺陷单号，并由测试经理或测试组长确认后允许关闭； 设置解决结果为“需求变更”的缺陷，必需在备注中填写需求变更的JIRA单号，并由测试经理或测试组长确认后允许关闭； 设置解决结果为“非问题”的缺陷，必需在备注中填写说明为非问题的具体缘由，可以添加附件说明.，由测试经理或测试组长确认后允许关闭； 设置解决结果为“无法复现”的缺陷，开发人员必需和测试人员充分沟通，由测试经理或测试组长确认后允许关闭； 设置为“已解决”的缺陷，必需由缺陷提出人进行验证后关闭，并最终将解决结果置为“已验证通过”； 设置解

16、决结果为“问题遗留不修复”的缺陷，必需是在JIRA中留下同意遗留的证据（领导备注确认遗留信息或附件领导同意遗留的邮件、ST闲聊记录）。最终由测试经理或测试组长确认有相关的证据后，允许在本项目中关闭缺陷：n 缺陷等级为堵塞、致命的缺陷，须要供应中心领导确认同意遗留的信息至JIRA中；n 缺陷等级为严峻的缺陷，须要供应项目经理和对应产品部门的领导确认同意遗留的信息至JIRA中；n 缺陷等级为一般和提示的缺陷，须要供应项目经理和对应产品经理确认同意遗留的信息至JIRA中。3.6 遗留缺陷定期清理各中心的测试负责人有责任参加和推动遗留缺陷的清理工作。测试负责人需在每个项目起先前统计JIRA中对应系统遗

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

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

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

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

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

22、测试工程师(问题提出人)重开缺陷3. 测试人员对开发人员提交的修复缺陷进行复测/回来，但不通过4. 把缺陷状态设为“重新打开”5. 缺陷解决结果为“未解决”120测试组长/测试经理取消缺陷1. 全部经测试经理/组长推断的非有效缺陷，并在JIRA中设置为“重复问题”或“非问题”或“无法重现”2. 后续100编号活动130开发工程师(问题解决人)取消缺陷1. 全部经开发人员推断的非有效缺陷，并在JIRA中设置为“重复问题”或“非问题”2. 后续140编号活动140测试组长/测试经理推断是否取消缺陷1. 测试经理推断来自研发提交的“非问题”或“重复问题”2. 测试经理同意研发的看法3. 后续100编

23、号活动4. 测试经理不同意研发的已经5. 后续040编号活动150项目经理推断是否需求问题1. 项目经理分析后推断是需求问题2. 执行160编号活动3. 项目经理分析后推断不是需求问题4. 后续060编号活动160项目经理需求变更流程1. 项目经理记录需求变更说明2. 缺陷单解决结果为“需求变更”3. 开启需求变更流程4. 缺陷单备注中填写需求编号5. 后续100编号活动170开发工程师(问题解决人)遗留缺陷1. 开发人员把缺陷解决结果设置为“问题遗留不修复”2. 后续180编号活动180项目经理是否同意遗留1. 项目经理分析推断此缺陷同意遗留a) 在JIRA中备注项目经理同意遗留b) 依据缺陷级别收集遗留缺陷必要的纪要信息（参考3.5章节）2. 执行190编号活动3. 项目经理分析推断此缺陷不同意遗留4. 后续070编号活动190测试组长/测试经理Jira中是否有相关领导确认同意遗留的纪要信息1. 测试经理检查被遗留的缺陷单备注中是否有项目经理及相关领导的缺陷遗留纪要（参考3.5章节）2. 有匹配的缺陷遗留纪要3. 后续100编号活动4. 无匹配的缺陷遗留纪要5. 后续180编号活动第21页