【软件测试】软件缺陷报告如何编写

废话不多说,三张图说明 软件缺陷报告如何编写 以及 报告的跟踪流程

软件缺陷报告格式

【软件测试】软件缺陷报告如何编写_第1张图片

软件缺陷报告内容说明

  1. 缺陷状态 - 分为 新建、打开、修复、关闭
    - 新建 - 测试人员第一次发现缺陷
    - 打开 - 测试将报告交给开发,开发确认缺陷,准备动手解决
    - 修复 - 开发解决缺陷
    - 关闭 - 测试确定缺陷被解决
  2. 缺陷类型 - 分为 致命、严重、一般、建议
    - 代码错误 - 开发人员编码出错
    - 设计缺陷 - 前期设计问题,比如:架构问题、UI设计问题
    - 性能问题 - 功能没问题,但是速度太慢
    - 安全相关 - 不解释,见名知意
  3. 严重程度 - 分为 严重、致命、一般、建议
    - 致命 - 软件无法运行,如:闪退、无法打开
    - 严重 - 软件大部分功能无法使用
    - 一般 - 某个功能有问题
    - 建议 - 可改可不改,仅是测试人员的改进建议
  4. 优先级 - 分为 高、中、低 ,一般 严重程度高的,优先级也就越高,但两个不完全一样
  5. 缺陷标题 - 概括缺陷
  6. 详细描述 - 包含 预置条件、重现步骤、实际结果、预期结果
    【软件测试】软件缺陷报告如何编写_第2张图片

软件缺陷报告的跟踪流程

整个流程涉及两个角色 - 测试人员 和 开发人员

流程示意图如下
测试人员环节 - 提交 回归 关闭
开发人员环节 - 确认 打开 关闭
【软件测试】软件缺陷报告如何编写_第3张图片
第一步 提交 - 测试人员提交缺陷报告
第二步 确认 - 开发人员确认是否确实存在这个缺陷,还是测试人员的误报
第三步 打开 - 开发人员明示确认缺陷、开始修复
第四步 修复 - 开发人员修复过程
第五步 回归 - 测试人员判断是否成功修复缺陷
第六步 关闭 - 测试人员明示缺陷被修复

上面展示的是顺利流程
有可能在确认阶段,开发人员驳回报告,因为测试人员对需求文档理解有误
也有可能回归阶段,测试人员认为开发人员未成功修复缺陷

你可能感兴趣的:(软件测试,软件测试)