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