项目缺陷管理流程(20140108).doc

项目缺陷管理规范1 目的为了及早发现现网系统缺陷问题、明确职责、定位问题原因，从而提高现网系统质量，缩短现网系统解决时长，制定了此现网系统缺陷管理规范。2 现网缺陷管理流程3 现网缺陷管理内容描述步骤流程任务流程责任角色输入输出操作说明1缺陷问题提出系统各使用人员：广东移动业务部门文讯各系统使用人员缺陷描述缺陷问题列表缺陷描述要求见“6、缺陷描述要求”2缺陷问题分析、分配开发组长/开发经理缺陷问题列表缺陷问题列表（处理优先级、处理人员、处理意见等）开发组长对缺陷问题进行分析、分配： 分析时，将咨询类、理解错误类等问题处理掉，不留给开发人员； 对缺陷进行分配，与需求分析、或业务运营人员确定缺陷处理优先级，并标注处理意见； 进行缺陷来源判断，进行对应的处理方案：1、代码开发问题：分配给开发人员进行处理；2、需求问题: 与需求分析人员确认，需求分析人员给出解释，给出处理意见3、使用/理解有误问题：走回归测试流程3修改BUG开发人员缺陷问题列表（处理优先级、处理意见等）BUG问题原因分析、BUG解决方案、BUG开发代码开发人员根据缺陷问题列表信息，分析缺陷问题，编写缺陷问题原因及具体的解决方案，修改BUG4测试4.1测试人员缺陷测试测试人员缺陷问题列表、修改的缺陷功能测试报告验证开发人员修改的BUG功能是否通过：u 通过后提交给缺陷提出人进行回归验证；u 不通过，则提交给开发组长进行缺陷问题分析及分配。4.2回归测试缺陷问题提出人缺陷问题列表、修改的缺陷功能、测试报告回归测试结果报告缺陷问题提出人，对使用理解有误问题以及测试人员验证缺陷通过的问题进行回归测试:u 通过后,回归通过则缺陷关闭；u 不通过，则提交给开发组长进行缺陷问题分析及分配。5问题关闭测试人员回归测试结果报告缺陷问题列表（更新）缺陷提出人回归测试通过后，测试人员关闭完成处理的缺陷问题4 角色职责说明角色名角色职责开发组长及经理1、 缺陷分析时，将咨询类、理解错误类等问题处理掉；2、 对缺陷进行分配，与需求分析、或业务运营人员确定缺陷处理优先级，并标注处理意见3、 根据缺陷来源进行缺陷分配；4、 定期对缺陷库分析，找出常出错的模块，进行代码审查及提出优化、改进建议及方案开发人员分析Bug，写出问题原因及解决方案，修改Bug缺陷问题提出人提出缺陷问题，回归验证需求分析人员1、解释需求，给出处理意见2、将缺陷库中的建议整理成需求文档。评审确定后列入需求版本开发计划测试人员验证Bug是否已被解决，对验证通过的缺陷进行关闭5 缺陷描述要求缺陷描述的要求为分类准确、叙述简洁、步骤清楚、有实例、易再现、复杂问题有据可查（截图或其它形式的附件）。测试组长/经理把关，以开发人员的角度来审查缺陷描述，看其是否描述清楚了缺陷，不好描述的把截图作为附件提交。具体要求为：l 单一：尽量一个报告只针对一个软件缺陷（在EXCEL表格中表显为一行），报告形式应方便阅读l 简洁：每个步骤的描述应尽可能简洁明了。只解释事实、演示和描述软件缺陷必要的细节，不要写无关信息； l 再现：问题尽量要在自己机器上能复现方可入库（个别严重问题复现不了也可入库，但需标明）； l 有据可查：复杂的问题应附截图补充说明或直接通知指定的修改人；考虑到网络数据传输效率，截图的文件格式建议用JPG或GIF，不建议用BMP；亦可用HyperSnap之类的专用抓图工具；l 用词准确：报告中不允许使用抽象词句：比如“有错误”之类； 有关操作系统特征问题：应在不同操作系统上进行操作，看是否能重现，并在缺陷报告中标识； 缺陷描述示例： 例一：功能点：用户管理中删除功能操作步骤：期望结果：实际结果：例二（模块或功能点也可在功能模块字段中规定，则Bug描述中就不必写了）操作：1.打开新建向导；2.在“新建”中的“项目名称”中输入80个字符；3.点击“下一步”期望结果：“项目名称”应=80个字符，输入大于80个字符，点击“下一步”应有错误提示实际结果：进入“比重调整”界面例三（程序员知道期望结果的情况下）云南98土建操作：1.输入13-1702.F53.在F5中修改3240008的名称, 处于编辑状态4.到人材机,再回来实际结果： F5中变白板注：若3不处于编辑态切换则正常例四（建议、需求类）功能：预算页，子目排序后可恢复原顺序用途：用户误操作后可复原6 缺陷列表各属性及角色说明编号属性名角色说明1缺陷描述缺陷问题提出人通过EXCEL表格填写包括浏览器，IE分版本2菜单路径3操作步骤/过程5缺陷严重级别6实际结果7缺陷提出人及联系方式8缺陷优先级开发组长9缺陷处理意见开发组长10分配人/责任人/处理人开发组长指定分配人11处理时间责任人估计，开发组长填写在BUG管理平台中填写12缺陷状态不同阶段的人填写以BUG管理平台为准13问题类型开发人员7 属性字典说明缺陷严重级别No类别名称说明备注1崩溃错误导致了死机、产品失败（“崩溃”）、系统悬挂无法操作2重要的功能未实现或导致一个特性不能运行并且不可能有替代方案3次要的错误导致了一个特性不能运行但可有一个替代方案；4微小的错误是表面化或微小的（提示信息不太准确友好、错别字、UI布局或罕见故障等），对功能几乎没有影响，产品及属性仍可使用；5建议建设性的意见或建议。缺陷优先级No类别名称说明备注15阻止相关开发人员的进一步开发活动，立即进行修复工作；阻止与此密切相关功能的进一步测试24必须修改，发版前必须修正33必须修改，不一定马上修改，但需确定在某个特定里程碑结束前须修正42如果时间允许应该修改51允许不修改缺陷处理意见No类别名称说明备注1可修改可修改。表示Bug可以被修复或更正2重复重复。表示该Bug已经被其它测试人员找出来了（纯粹重复），或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）3延后延后。由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的Bug。（注：因Bug状态字段中也有该值，根据各组各自使用情况，可以只保留一个，或者开发/测试各有侧重地使用这两个Postponed）4设计结构问题无法修改因设计结构问题无法修改。测试人员认为是Bug，不符合逻辑，也不符合用户的要求，但开发人员则认为是按照设计做的、只能如此处理，否则修改代价太大5不可复现不可复现。不能重现（如因Bug出现的环境重现不了了），或以前出现的某个Bug自动消失了（可能是在处理其他Bug的时候把这个Bug 一并修复掉了）。（注：因TD本身亦带有是否复现(Reproducible)字段，根据各组各自使用情况，可以用它来标识，或者不用它而在处理意见字段中用该值标识出）问题类型No类别名称说明备注1需求问题由于需求的问题引起的缺陷2架构问题由于构架的问题引起的缺陷3设计问题由于设计的问题引起的缺陷4代码问题由于编码的问题引起的缺陷5测试问题由于测试的问题引起的缺陷6环境问题7部署、版本问题