枫格Bug和Task处理流程文档V1.1介绍.ppt

BugTask的处理流程 FG.研发部 作者：余西鹏 目 录 软件Bug处理流程图； Bug的提交和跟踪（测试）； Bug的处理（开发）； 测试任务提交与跟踪； Jira的基本使用； 一、BUG的处理流程 1.1 Bug处理流程图 提交一个新的Bug到缺陷管理库（JIRA）； TL检查是否Bug并指派给模块负责人； 模块DL分配Bug给相关开发人员； 开发人员分析/修改Bug； 测试人员验证关闭Bug； 特殊情况的处理； 一、BUG的处理流程 1.2 Bug处理步骤分解 二、Bug的提交和跟踪 2.1 提交Bug必要元素 新建Bug包含元素： 概 要：简述bug出现的结果 * 模 块：选择Bug属于Android/ios/CMS/Java等模块 * Build_V：发现Bug的版本，如 V 2.3.3 * 级 别：选择Bug严重级别，如 致命/严重/一般 * 缺陷类型：如 功能错误/用户界面 Found：内部发现版本号B01/B02 * 概 率：填写Bug出现的概率 * 开发者：将问题指派给测试负责人 * 前提条件： 描述Bug发生的必要前提条件 描 述：描述复现Bug的详细步骤 实际结果：描述Bug出现的结果 预期结果：描述复现步骤期望达到的结果 注意：标准*的项目为必填项目 Submitted 一个新的Bug被提交到库中； Checked 测试Leader将check后的Bug指派给开发人员； Assigned 开发Leader分配Bug给指定开发人员； Opened 开发人员解决分配给自己的Bug;或修改的Bug未通过验证，Resolved后被重新open Resolved 开发人员对Bug修正完毕； Duplicate 测试人员所报的重复Bug Postponed Bug延期解决 Monitor Bug重现频率较低，要求测试人员跟踪 Not bug 误报或者客户理解错误，由测试leader与产品或PM确认是否成立 Unsure 开发人员对认为非Bug忽略的问题由测试负责人确定是否成立； Closed Bug修改通过测试验证后被关闭； 注意：bug在Jira库中最终只有两个状态 Not bug 和 Closed 二、Bug的提交和跟踪 2.2 Bug的状态说明 二、Bug的提交和跟踪 2.3 Bug的状态转化图 二、Bug的提交和跟踪 2.4 提交Bug的填写说明 Resolved 对修正完的Bug进行回归验证，通过关闭，否则重开并添加回归说明； Monitor 对重现率较低的Bug需在不同环境下重现并加验证说明（终端、网络等不同条件） Unsure 开发人员对认为非Bug忽略的Bug测试负责人确定成立则确认，否则重开； 二、Bug的提交和跟踪 2.4 测试人员对Bug的状态的跟踪 解决bug时，需要开发人员选择处理结果，并需要在“备注”中分析Bug产生原因，以避免Bug的再次出现。处理结果如下： Resolutions Fixed：仅仅对真正解决了该问题的才能选择此项 Won’t Fixed：通常为“忽略该未知问题”的操作选择此项 Duplicate：通常对选择“问题重复”的操作选择此项 Incomplete：对“需要测试人员协助”选择此项 Cannot Reproduce：对“需要测试人员协助”的操作选择此项 三、Bug的处理（开发） 3.1 开发对Bug产生原因进行分析 三、Bug的处理（开发） 3.2 Assigned状态下的BUG处理说明 三、Bug的处理（开发） 3.2 Opened状态下的BUG处理说明 三、Bug的处理（开发） 3.2 Resolve状态下的BUG处理说明 New 开发人员提交测试测试任务至Jira库中，测试负责人需要指派任务 Open 测试人员接收到任务后，能执行任务的状态 Close 当测试通过后，Jira在库中的状态 Rejected 当测试不通过，测试拒绝继续后将返回给开发人员，此时需要重新更新版本后重新打开任务进行提交测试 注意：最终任务只存在close的状态 四、测试任务的提交与跟踪 4.1 Task状态说明 开发提交任务 开发人员有新版本或回归需求时可将Task提交到JIRA中 新建Task含以下主要元素： 概 述：简洁描述任务内容。如 【Android 2.3.4】活