功能测试Ⅲ——缺陷及缺陷管理

总目录

测试开发系列(功能+接口+性能+自动化)

缺陷及缺陷管理

目标

  • 能够说出缺陷的判定标准

  • 能够说出描述缺陷的6大核心内容

  • 能够描述缺陷状态、严重程度、优先级的作用

  • 能够按照提供的缺陷模版完成一个缺陷的提交

  • 能够说出缺陷的跟踪流程

  • 能够在禅道中提交测试用例

  • 能够在禅道中提交缺陷

1. 缺陷

1.1 缺陷的定义(重点)

  • 产品实现不满足用户需求
  • 测试执行时,实际结果和预期结果不一致

1.2 缺陷的判定标准(重点)

  • 未达到需求说明书指明的功能
  • 出现了需求说明书指明不应该出现的错误
  • 实现了需求说明书之外的功能
  • 未达到需求说明书虽未明确提及但是应该实现的目标(如:性能要求等)
  • 用户角度发现的各种问题与错误

1.3 缺陷产生的原因及根本原因

  • 缺陷产生的原因

    • 需求文档存在错误
    • 需求变更
  • 设计存在错误

    • 代码错误
  • 缺陷产生的根本原因

    • 需求变更
    • 沟通不畅、信息不同步
    • 软件复杂
    • 进度压力

1.4 软件缺陷的核心内容(重点)

  • 标题:描述缺陷的基本信息,如(输入密码长度为5时,注册成功。)
  • 前置条件:描述缺陷出现依赖的相关基础条件,如(未注册手机号)
  • 复现步骤:测试用例里面的执行步骤
  • 实际结果:执行被测试软件过程中,系统给出的结果
  • 预期结果:参照需求说明书,在测试用例中设计的预期结果
  • 附件:方便开发定位bug的关键信息,包含图片、日志log等

1.5 缺陷基本要素(重点)

  • ID编号:唯一

  • 模块:根据产品进行具体的划分,如登录、注册

  • 缺陷状态:表明缺陷处理进度

  • 严重程度:从技术维度来衡量,bug的破坏力

  • 优先级:从业务的角度,决定bug修改的先后顺序

  • 缺陷类别:用于分类整理缺陷

1.6 缺陷的状态(重点)

  • new:新建
  • open:打开
  • fix:已修复
  • close:关闭
  • reopen:重新打开
  • reject:已拒绝
  • postpone:延期

1.7 缺陷严重程度(重点)

  • 5-致命的

  • 4-非常高

  • 3-高

  • 2-中

  • 1-低

1.8 缺陷优先级(重点)

  • 5-紧急的
  • 4-非常高
  • 3-高
  • 2-中
  • 1-低
### 思考题:优先级和严重程度的区别(了解)

+ Priority is Business【优先级是从公司运营角度(人力配置,资金投入等)】
+ Severity is Technical【严重级别是从技术角度】

- 优先级还要考虑团队的工作进度,阻塞工作的缺陷,要优先解决
- 考虑解决缺陷的能力,难度,风险

+ 最终优先级

  + 确定权:产品经理、项目经理等

  + 建议权:测试

1.9 缺陷类别(了解)

  • 功能错误

  • UI界面错误

  • 兼容性

  • 易用性

  • 改进建议

  • 其他

2. 缺陷管理

2.1 缺陷信息(重点)

  • 核心要素

    • 标题:描述缺陷的基本信息,如(输入密码长度为5时,注册成功。)
    • 前置条件:描述缺陷出现依赖的相关基础条件,如(未注册手机号)
    • 复现步骤:测试用例里面的执行步骤
    • 实际结果:执行被测试软件过程中,系统给出的结果
    • 预期结果:参照需求说明书,在测试用例中设计的预期结果
    • 附件:方便开发定位bug的关键信息,包含图片、日志log等
  • 基本要素

    • ID编号:唯一
    • 模块:根据产品进行具体的划分,如登录、注册
    • 缺陷状态:表明缺陷处理进度
    • 严重程度:从技术维度来衡量,bug的破坏力
    • 优先级:从业务的角度,决定bug修改的先后顺序
    • 缺陷类别:用于分类整理缺陷

2.2 缺陷报告的重要性(了解)

  • 体现测试的一个专业性

  • 多站在开发的角度去思考问题(换位思考)

2.3 编写缺陷报告注意事项(理解)

  • 可复现
  • 唯一性
  • 一个问题只提交一个bug记录

2.4 缺陷书写规范(理解)

  • 标题:应保持简短、准确,提供缺陷的本质信息
  • 复现步骤:应包含如何使别人能够很容易的复现该缺陷的完整步骤
  • 实际结果:是执行复现步骤后软件的现象和产生的行为
  • 预期结果:通常需要列出期望的结果是什么
  • 附件:对缺陷描述的补充说明

2.5 缺陷跟踪流程(重点)

场景1:确认BUG解决

  • 测试【new】-》开发【open】-》开发【fix】-》测试【close】

场景2:验证未通过,缺陷仍存在

  • 测试【new】-》开发【open】-》开发【fix】-》测试【reopen】

场景3:开发延期处理

  • 测试【new】-》开发【open】-》开发【postpone】

场景4:拒绝处理

  • 测试【new】-》开发【open】-》开发【reject】

2.6 缺陷的统计(了解)

  • 严重程度
  • 提交人
  • 缺陷类型

3. 禅道(重点)

3.1 禅道使用流程

1.产品经理创建产品

2.产品经理创建需求

3.项目经理创建项目

4.项目经理确定项目要做的需求

5.项目经理分解任务,指派到人

6.开发人员实现需求

7.测试人员测试,提交bug

3.2 禅道用户角色(了解)

  • 超级管理员
  • 产品经理
  • 项目经理
  • 开发
  • 测试

3.3 超级管理员使用禅道(扩展)

  • 取消弱口令:【系统】–【安全】

    • 密码安全:不检查
    • 修改弱口令密码:不强制
  • 修改密码

  • 修改公司信息:【组织】–【公司】–【编辑】–【公司名称】

  • 添加部门:【组织】–【部门】

  • 添加用户:【组织】–【用户】–【添加用户】/【批量添加】

    • 注意:
      • 用户名是数字,字母,下划线,大于3位
      • 注意:用户的职位和分组,决定了用户的相应权限
    • 添加用户

    • 批量添加

3.4 产品经理使用禅道(扩展)

  • 创建产品:【产品】–【添加产品】–编辑产品信息
  • 维护模块:【产品】–【模块】–按层级编辑模块信息
  • 维护计划:【产品】–【计划】
  • 产品经理提需求:【产品】–【需求】–【提需求】
    • 默认不开启评审,需求是激活状态
  • 需求评审
    • 需要评审的需求处于‘草稿’状态
    • 评审是一个线下的活动(开会),只在禅道中更新评审结果
    • 评审的结果
      • 确认通过
      • 有待明确
      • 拒绝
  • 需求变更
    • 需要评审的变更需求处于‘变更中’状态
    • 评审结果
      • 确认通过
      • 有待明确
      • 撤销

3.5 项目经理使用禅道(扩展)

  • 创建项目:【项目】–【添加项目】–编辑具体项目信息
  • 创建团队:【项目】–【团队】–【团队管理】
  • 关联需求:【项目】–【需求】–【关联需求】
  • 分解任务:【项目】–【需求】–【分解任务】/【批量分解】

3.6 开发使用禅道(扩展)

  • 领取任务:
    • 方式1:【项目】–【任务】–选择开始
    • 方式2:【我的地盘】–【任务】–选择开始
  • 提测
    • 1.打版本:【项目】–【版本】–【创建版本】
    • 2.提交测试:【项目】–【版本】–【提交测试】

3.7 测试使用禅道(重点)

3.7.1 创建用例
  • 【测试账号】登录
  • 【测试】–【用例】–【建用例】
  • 【测试】—【用例】-- 点击右上角“建用例”的下拉菜单,选择【批量添加】
3.7.2 导入用例
  • 第一步:导出测试用例模板

    • 进入【测试】—【用例】,右上角按钮【导出】–【导出模板】,选择【GBK】字符,点击保存
  • 第二步:按照模板编写测试用例

  • 第三步:导入编写好的用例文件

    • 进入【测试】–【用例】,右上角【导入】–【导入CSV】,选择测试用例文件,选择“GBK”,点击保存
3.7.3 评审用例
  • 【admin】登录,进入【后台】–【自定义】–【用例】—【评审流程】,【开启评审】的功能
  • 测试人员登录,进入【测试】–【用例】,新建一个需要评审的用例(不勾选“不需要评审”)
  • 在【测试】–【用例】,对需要评审的用例,点击操作栏“评审”按钮,进行评审。
    • “确认通过”:用例从【待评审】状态改为【正常】状态
    • “继续完善”:用例保持【待评审】状态
3.7.4 版本关联用例
  • 测试人员登录系统,进入【测试】—【版本】,查看提交测试的版本

  • 点击操作栏中的“关联用例”按钮,勾选用例(正常状态),点击保存。

3.7.5 执行用例
  • 测试登录系统,进入【测试】—【版本】—【用例】,点击操作栏中的执行按钮

  • 用例执行的结果:【通过】,【失败】,【阻塞】,【忽略】

  • 失败的用例,可以点击“转BUG”,填写BUG信息,点击保存。

  • 可以直接提BUG:进入测试–BUG,点击“提BUG”,填写信息,点击保存

3.7.6 禅道中BUG跟踪过程
  • 测试提交缺陷
  • 开发解决缺陷
  • 测试回归验证
    • 确认修复,关闭缺陷
    • 并未修复,激活缺陷,重新指派给开发解决
  • 关闭后的缺陷再次出现,测试激活该缺陷

目标

  • 能够说出缺陷的判定标准
  • 能够说出描述缺陷的6大核心内容
  • 能够描述缺陷状态、严重程度、优先级的作用
  • 能够按照提供的缺陷模版完成一个缺陷的提交
  • 能够说出缺陷的跟踪流程
  • 能够在禅道中提交测试用例
  • 能够在禅道中提交缺陷

作业

作业:
1.梳理今日知识点,结合课上知识讲解补充完善今日总结内容,以xmind形式输出
2.TPShop商城前台【注册】功能测试用例设计、执行、并将发现的bug记录在缺陷报告和禅道
3.TPShop商城后台【添加会员】功能测试用例设计、执行、并将发现的bug记录在缺陷报告和禅道
说明:
后台访问地址:http://localhost/Admin/Admin/login
用户名:admin
密码:123456
测试功能:【系统】==》【会员】==》【会员列表】==》点击【添加会员】按钮

要求:
1.作业需要上交,命名格式:
姓名_作业_【XXX】测试用例设计,例如:张飞_作业_注册测试用例设计
  • 0
    点赞
  • 4
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

zkFun

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值