3 新媒传信_手机客户端开发部_规范和指南_缺陷提交规范1.0

缺陷提交规范 手机客户端开发部手机客户端开发部 版本 1 0 状态 编写中编写中 已提交 已发布 作者 李志彬 修改历史修改历史 修改日期修改日期版本号版本号修改内容修改内容作者作者 2009 9 21V1 0 初稿李志彬 2009 9 23V1 0 增加缺陷提交规则说明唐文郁 新媒传信新媒传信 第 2 页 Bug 提交规范 手机客户端开发部 共 10 页 Page 2 目录 1 编编写写目目的的 3 2 BUG 基基本本要要素素 3 2 1 BUG头基本要素 3 2 2 BUG体基本要素 3 2 3 TD 中 BUG基本要素的截图如下 3 3 BUG 提提交交说说明明 4 3 1 标题 SUMMARY 4 3 2 前提条件 5 3 3 操作步骤 5 3 4 预期结果和实际结果 5 3 5 附件 ATTACHMENTS 6 3 6 BUG说明 COMMENTS 6 3 7 BUG发现者 DETECTED BY 和 BUG处理者 ASSIGNED TO 7 3 8 BUG状态 STATUS 7 3 9 严重程度 SERVERITY 和优先级 PRIORITY 7 3 10 功能模块 FUNCTION 和客户端 VALIDATE CLIENT 7 3 11 测试环境 ENVIRONMENT 8 3 12 BUG类型 BUG TYPE 8 3 13 提交日期 DETECTED ON DATE 8 3 14 复现率 8 4 提提交交规规则则说说明明 8 4 1 BUG提交项 8 4 2 DESCRIPTION提交格式规范 8 5 参参考考文文档档 9 新媒传信新媒传信 第 3 页 Bug 提交规范 手机客户端开发部 共 10 页 Page 3 1 编编写写目目的的 此文档对于飞信项目组所使用之测试管理平台 TestDirector 以下简称为 TD 的 Bug 提交做 了介绍 可供手机客户端开发部相关测试人员 开发人员 产品经理 项目经理等做参考 并可作 为质量管理人员对 Bug 提交进行规范性监控的参考依据 2 缺缺陷陷基基本本要要素素 一个完整清晰的 Bug 包含诸多基本要素 概括起来可以分为 Bug 头和 Bug 体 以下是根据 Bug 的基本要素和 TD 字段的对应关系表 2 1 BUG 头基本要素 序号序号Bug 基本要素基本要素TD 对应字段对应字段备注备注 1 Bug 发现者 Detected By TD 自动生成 2 Bug 处理者 Assigned To 下拉列表选择 3 Bug 状态 Status 下拉列表选择 4 严重程度 Severity 下拉列表选择 5 优先级 Priority 下拉列表选择 6 功能模块 Function 手动填写 7 客户端 Validate Client 下拉列表选择 8 测试环境 Environment 下拉列表选择 9 Bug 类型 Bug Type 下拉列表选择 10 提交日期 Detected on Date TD 自动生成 11 复现率复现率下拉列表选择 2 2 BUG 体基本要素 序号序号Bug 基本要素基本要素TD 对应字段对应字段备注备注 1 标题 Summary 手动填写 2 前提条件 Description 手动填写 3 操作步骤 Description 手动填写 4 预期结果 Description 手动填写 5 实际结果 Description 手动填写 6 附件 Attachments 手动添加 UI 截图 日志 7 Bug 说明 Comments 手动填写 8 历史记录 History TD 自动生成 TD 中 Bug 基本要素的截图如下 新媒传信新媒传信 第 4 页 Bug 提交规范 手机客户端开发部 共 10 页 Page 4 3 缺缺陷陷提提交交说说明明 3 1 标题 SUMMARY 原则 3 1 1 标题须简明 清晰 指出问题点 让业务相关人员根据标题即能大致明了问题所在 原则 3 1 2 良好的缺陷标题应该按照下列方式书写 a 尽量按缺陷发生的原因与结果的方式书写 执行完 A 后 发生 B 或者 发生 B 当 A 执行完 后 b 避免使用模糊不清的词语 例如 功能中断 功能不正确 行为不起作用 等 应该使用具体 文字说明功能如何中断 如何不正确 或如何不起作用 例如 新媒传信新媒传信 第 5 页 Bug 提交规范 手机客户端开发部 共 10 页 Page 5 Summary 接收到共享文件 按确认键无法下载 3 2 前提条件 规范 3 2 1 前提条件包含测试所使用的版本 手机型号 测试数据 用户信息等 例如 版本 WM3 1 客户端 真机 生产环境 CAB 包 20090918 手机型号 Dopod S1 说明手机型号相关或普遍存在 测试账号15811113333 前置条件 1 用户 A 和用户 B 互为好友 注 版本和手机型号为必填内容 注 版本和手机型号为必填内容 3 3 操作步骤 规范 3 3 1 每一个步骤只记录一个操作 规范 3 3 2 使用数字对步骤编号 原则 3 3 3 操作步骤的描述要简明 尽量使用短语和短句 避免复杂句型和句式 原则 3 3 4 操作步骤要完整 准确 不缺失 不多余 原则 3 3 5 完整的操作步骤必须是可复现的 例如 操作步骤 1 A给B传送文件 2 B收到文件下载的提示信息 请按确认键下载文件 3 B按确认键 3 4 预期结果和实际结果 预期结果 在以上所描述的前提条件及操作步骤下 根据产品设计要求或者基本常识 预期要达到 的结果或者现象 实际结果 在以上所描述的前提条件及操作步骤下 客户端实际表现出来的结果或者现象 原则 3 4 1 预期结果和实际结果需要突出差异点 例如 预期结果 B能够成功下载A传过来的文件 实际结果 B无反应 无法下载A传的文件 3 5 附件 ATTACHMENTS 新媒传信新媒传信 第 6 页 Bug 提交规范 手机客户端开发部 共 10 页 Page 6 建议 3 5 1 与 Bug 相关的日志 截图等 尤其是无法固定步骤重现的 Bug 如果有客户端日志 的话 需要附上 建议 3 5 2 日志 截图等附件的命名需要能体现问题点 建议 3 5 3 日志 复现此问题 得到一个最简洁的客户端日志 建议 3 5 4 截图 需对出现问题的地方用颜色鲜明的线条进行标注 TD 中附件信息的截图参照如下 3 6 BUG 说明 COMMENTS 建议 3 6 1 Bug 状态发生变化时 需要在 TD 的 Comments 里做相应说明 Comments 里的信息 常见的有 规范 3 6 2 缺陷验证通过时 须在 comment 里标注 XX 版本 验证通过 规范 3 6 3 RCA 信息 参见 新媒传信 手机开发部 Bug Fix 流程 规范 3 6 4 Bug 不重现 Bug 状态被置为 WorksForMe NonRepeatable 时 测试人员须在 Comment 内注明连续在三个版本验证通过的信息 规范 3 6 5 Bug 无效 当 Bug 状态被置为 Invalid 时 测试人员须在 Comment 里说明 Bug 被置为 Invalid 的原因 规范 3 6 6 Bug 仍然存在 当 Bug 状态被置为 Reopen 时 测试人员 需要在 Comment 里说明 Bug 验证后 还存在什么问题是部分未修复还是全部未修复 对于由于开发人员修改 Bug 而引发的 新问题 测试人员需提交新 Bug 原则 3 6 7 TD 中 Comments 的截图参照如下 新媒传信新媒传信 第 7 页 Bug 提交规范 手机客户端开发部 共 10 页 Page 7 3 7 BUG 发现者 DETECTED BY 和 BUG 处理者 ASSIGNED TO 规范 3 7 1 Bug 发现者 Detected By 发现并提交此 Bug 的人员 Bug 发现者字段值在 Bug 的生命周期中保持不变 规范 3 7 1 Bug 处理者 Assigned To 后续需要处理此 Bug 的责任人 Bug 处理者字段值应随 Bug 责任人的变化而改变 3 8 BUG 状态 STATUS Bug 状态 Status 指 Bug 所处生命周期中某个点的状态 目前项目组定义的状态及说明如下 Bug 状态状态说明说明 New Bug 发现者提交的初始状态 Open Bug 处理者正在解决中 Reopen Bug 未被正确解决 需要重新处理 Fixed Bug 已经解决 但开发未在新版本验证 Updated Bug 已解决 且开发已在新版本验证 Passed Bug 验证通过 Closed Bug 关闭 不再处理 By Design 符合产品设计要求 Duplicate 此 Bug 与某个已知 Bug 重复 Invalid 此 Bug 无效 Next Version Later 当前大版本不解决 下一个版本解决 NonRepeatable Bug 不可重现 3 9 严重程度 SERVERITY 和优先级 PRIORITY 规范 3 9 1 参见新媒传信 手机客户端开发部 规范和指南 缺陷分级与处理规范 中缺陷分级定义 3 10 功能模块 FUNCTION 和客户端 VALIDATE CLIENT 功能模块 Function 指的是 Bug 所在功能模块 功能模块列表可以在测试准备阶段进行统一列 出 如果没有功能模块列表 则默认为 Bug 所在的客户端 客户端 Validate Client 指的是 Bug 所在客户端 如 WM Java Symbian 等 注意 如果是互通 测试 需先判断 Bug 是由哪个客户端引起之后再选择客户端 新媒传信新媒传信 第 8 页 Bug 提交规范 手机客户端开发部 共 10 页 Page 8 3 11 测试环境 ENVIRONMENT 测试环境是指客户端测试时所使用的环境 目前的测试环境包含 厂商测试环境 功能测试环境 生产环境等 3 12 BUG 类型 BUG TYPE 开发程序 默认 由程序代码的错误 遗漏造成的 Bug 部署环境 由部署环境的软硬件配置变化造成的 Bug Build 包 含更新范围 由 Build 包造成的 Bug 例如文件遗漏 版本错误等 系统设计 由系统设计的错误 遗漏造成的 Bug 产品设计 由产品设计的错误 遗漏造成的 Bug 测试用例 由测试用例的设计错误造成的 Bug 例如对产品设计的理解不正确 其它 所有未包含在以上 Bug Type 中的 Bug 3 13 提交日期 DETECTED ON DATE 测试提交 Bug 时的日期 由 TD 自动生成 3 14 复现率 复现率 指 Bug 可复现的程度 目前分为 100 复现 经常复现 偶尔复现 4 缺缺陷陷提提交交规规则则说说明明 4 1 BUG 提交项 序号序号Bug 基本要素基本要素TD 对应字段对应字段备注备注 1 Bug 发现者 Detected By 必填 TD 自动生成 2 Bug 处理者 Assigned To 必填 下拉列表选择 3 Bug 状态 Status 必填 下拉列表选择 4 严重程度 Severity 必填 下拉列表选择 5 优先级 Priority 必填 下拉列表选择 6 功能模块 Function 必填 下拉列表选择 7 客户端 Validate Client 必填 下拉列表选择 8 测试环境 Environment 必填 下拉列表选择 9 Bug 类型 Bug Type 必填 下拉列表选择 10 提交日期 Detected on Date 必填 TD 自动生成 11 复现率复现率必填 下拉列表选择 12 Bug 标题 Summary 必填 手动填写 13 Bug 详细描述 Description 必填 手动填写 4 2 DESCRIPTION 提交格式规范 规范 5 3 1 新媒传信新媒传信 第 9 页 Bug 提交规范 手机客户端开发部 共 10 页 Page 9 版本 WM3 1 客户端 真机 生产环境 CAB 包 20090918 必填 手机型号 Dopod S1 必填 说明手机型号相关或普遍