标签：管理 bug 用例 开发 跟踪 测试 测试用例 缺陷 Bug

缺陷的管理与跟踪

1：缺陷的定义

缺陷不光是产品出现bug，宕机等情况才叫缺陷，缺陷还包括当产品不满足用户需求时也叫缺陷
还有当测试用例的预期结果于实际结果，不相同时也叫缺陷

1.1缺陷的判定标准

1）：未达需求文档指明的功能
2）：出现了需求文档指明不能出现的错误
3）：实现了需求文档以外的功能
4）：未达到需求文档未提及但是因该实现的功能或目标（性能要求）
5）：从用户角度发现的各种错误（可以依据软件质量模型）

1.2缺陷产生的原因

一：需求问题
    需求文档编写错误
    需求变更
二：设计存在错误
    代码错误
根本原因
    需求变更
    沟通不畅
    软件复杂
    进度压力

1.3提交缺陷的核心内容

标题：描述缺陷的基本信息
前置条件：测试用例中的前置条件
复现步骤：这个缺陷是怎么操作的时候出现的缺陷，要能够复现出来
实际结果：在执行测试用例的时候，系统给出的结果
预期结果：在执行这条测试用例之前，预期执行这条测试用例会出现的结果
附件：方便开发定位缺陷的关键信息/缺陷截图/系统日志

1.4bug得基本要素

id：具有唯一性
模块：根据产品进行具体划分
缺陷状态：表明缺陷的处理进度（打开，正在修改，关闭等）
严重程度：从技术角度来衡量缺陷的破坏力
优先级：从业务角度决定缺陷的修改顺序
缺陷类别：用于分类整理缺陷

1.5bug状态

new：新建/新提交的缺陷
open：打开/缺陷正在修改
fix：已修复/已经修复了缺陷现在需要进行回归测试
close：关闭/已经通过回归测试/这不是一个bug已经进行关闭
reject：已拒绝/开发认为这不是一个缺陷
reopen：重新打开/之前出现的bug修复后又重新出现了
postpone：延期/开发认为这个缺陷优先级没有当前做的工作优先级高，可以进行延期修复

1.6bug的严重程度

5-致命的/不修复这个缺陷会宕机等情况
4-非常高/影响主业务流程
3-高
2-中
1-低

1.7bug的优先级

5-致命的
4-非常高
3-高
2-中
1-低

总结：严重程度与优先级的区别

结论：优先级是从公司运营角度（人力资源配置，资金投入等）
​
•           严重程度是从技术角度来说
​
---优先级还要考虑团队的工作进度，阻塞工作的缺陷，要优先解决
---考虑解决缺陷的能力，难度，风险
+++最终优先级
    确定权：产品经理，项目经理
    建议权：测试

1.8bug的分类

功能错误
UI界面错误
易用性
该进建议
其他
主要依据分类：需求文档与软件质量模型

2：缺陷管理（软件以禅道为例）

1.1缺陷报告

缺陷报告的注意事项
1：可复现
2：唯一性
3：一个问题只提交一个bug

1.2缺陷报告的书写规范

标题：如测试用例标题同意，简短，准确，能够提供缺陷本质信息
复现步骤：包含你发现这个bug是怎么发现的具体经过了那些步骤
实际结果：复现步骤后软件的现象与行为
预期结果：通常是里出的期望结果/测试用例的预期结果
附件：对缺陷的补充说明

1.3bug的跟踪与管理

场景一：正常确认与解决
    测试（new）==》开发（open）==》开发（fix）==》测试（close）
    /测试提交bug-开发打开判定为bug-开发进行修改-开发修改完成后提交-测试进行回归测试-回归测试通过后关闭bug
场景二：回归测试没有通过
    测试（new）==》开发（open）==》开发（fix）==测试（reopen）==开发（fix）==》测试（close）
    测试提交bug-开发确认为bug-开发进行修改-修改完成后测试进行回归测试-回归测试未通过- 测试重新打开bug-开发进行修改后测试重复进行回归-知道回归通过后测试关闭bug
场景三：开发延期处理
    测试（new）==》开发（open）==》开发（postpone）开发（reopen）==》开发（fix）==》测试（close）
    测试提交bug后，开发判定是否为bug，确定为bug后，依据bug严重程度和自己档期安排决定是否要延期解决，确定延期解决后，等开发忙完当前后进行修改此bug，修改完后提测，测试通过回归后close
场景四：开发认为这个不是bug
    测试（new）==》开发（open）==开发（reject）/注意：这种情况要与开发及时确认
    造成这种情况的一般有，缓存，需求改动等，这时候就要拼人际关系了，大抵你会丢失一支烟，一杯咖啡……

3：禅道使用

1.1禅道使用流程

产品经理创建产品
产品经理提交需求
项目经理创建项目
项目经理确定项目要做的需求
项目经理分配任务，指派到人
开发人员实现需求
测试人员测试，提交bug

1.2禅道安装

一：下载
    打开禅道官网：https://www.zentao.net/
    点击下载-选择自己想要版本（只要不是最新般就可以）
    将下载好的安装包打开进行安装：注意一点一定要安装在根目录即可
    安装后，需要进行配置（一般在公司里面不需要配置，你只需要安装上就行，剩下的产品经理会给你账号和密码直接用账号和密码登录即可），注意：如果公司配置的禅道端口不是80，那么我们就需要将自己安装的禅道配置为与公司一致端口
    注意：如果是在即搭建的禅道环境：那么首次登录禅道的账号就是admin密码：123456

1.3测试使用禅道提交bug过程

创建测试用例
    测试-用例-创建用例
        测试-点击用例-点击右上角建用例的下拉菜单，选择批量添加
导入用例
    1：导出测试用例模板
        测试-用例-导出-导出用例模板，选择GBK字符，点击保存
    2;按照模板编写测试用例
    3：导入测试编写好的测试用例
        测试-用例-导入-导入csv文件，选择csv文件选择gbk点击保存
用例评审
    admin用户需要开启用例评审
    测试人员登录-点击测试-用例新建一个需要评审的用例，不勾选不需要评审
    在测试-用例对需要评审的用例点击操作栏需要评审，进行用例评审（用例评审一般有测试主管，产品经理进行用例评审）
    当产品经理/测试主管将用例从待评审状态改为正常状态证明用例评审通过
    如果用例状态被改为继续完善，说明用例评审未通过
版本关联用例
    测试登录系统-测试-版本-查看提交测试的版本
    点击操作栏中的关联用例按钮，勾线用例（正常状态的用例/用例评审通过的用例）。点击保存
执行测试用例
    测试登陆系统-测试-版本-用例，点击操作栏中的执行按钮
    用例执行结果怕【失败】【通过】【忽略】【阻塞】
    失败的用例可以直接转bug，填写bug信息，点击保存
    可以直接提bug，测试——bug，点击提bug，提交信息点击保存
禅道中BUG跟踪过程
​
- 测试提交缺陷
- 开发解决缺陷
- 测试回归验证
  - 确认修复，关闭缺陷
  - 并未修复，激活缺陷，重新指派给开发解决
- 关闭后的缺陷再次出现，测试激活该缺陷
​
​

 

标签：管理,bug,用例,开发,跟踪,测试,测试用例,缺陷,Bug
From： https://www.cnblogs.com/wh0915/p/16977432.html