前言

        继测试用例执行后，进入缺陷管理阶段，该阶段就需要测试与前后端对接

缺陷介绍

1.缺陷的定义

        软件在使用过程中存在的任何问题都叫软件的缺陷，简称 bug

2.缺陷的标准定义

•         少功能：软件未实现需求说明书中明确要求的功能
•         功能错误：软件出现了需求说明书中指明不应该出现的错误
•         多功能：软件实现的功能超出需求说明书指定的范围
•         隐形功能错误：软件未实现需求说明书中虽未明确指明但应该实现的要求
•         不易使用：软件难以理解，不易使用，运行缓慢，用户体验不好

3.缺陷产生的原因

        1) 需求阶段：需求描述不易理解，有歧义，错误等。
        2) 设计阶段：设计文档存在错误或者缺陷。
        3) 编码阶段：代码出现错误。
        4) 运行阶段：软硬件系统本身故障导致软件缺陷。

4.软件缺陷的生命周期

5.软件缺陷的核心内容

        1) 缺陷的标题：描述缺陷的核心问题
        2) 缺陷的预置条件：缺陷产生的前提
        3) 缺陷的复现步骤：复现缺陷的过程
        4) 缺陷的预期管理：希望得到的结果
        5) 缺陷的实际结果：实际得到的结果
        6) 缺陷的必要附件：图片、日志等信息（证据）

6.缺陷提交要素

        1) 缺陷报告编号：

•                 缺陷的唯一性标志

        2) 严重程度：

•                 严重 (S1):主功能：冒烟正向业务用例
•                 一般 (S2):次要功能：冒烟逆向业务用例、单功能正向
•                 微小 (S3):易用性、界面：单功能逆向、UI 布局
•                 建议 (S4):建议性问题：建议

        3) 缺陷优先级：

•                 Priority 0: 24 小时之内解决
•                 Priority 1: 发布前必须修复
•                 Priority 2: 可以在下一个版本中修复

        4) Bug 类型

•                 代码错误、兼容性问题、设计缺陷、性能问题

        5) 缺陷状态

•                 New:新建
•                 Open:打开
•                 Closed:关闭
•                 Postponed:延期

7.软件缺陷类型

•         功能错误
•         界面 (UI) 错误
•         兼容性
•         数据
•         易用性
•         改进建议
•         架构

缺陷编写

1.缺陷报告示例

        缺陷标题命名：测试数据 + 预期 + 执行结果

2.缺陷的跟踪流程

3.提交缺陷的注意事项

•         可重现：缺陷可以复现
•         唯一性：一个缺陷上报一个问题
•         规范性：符合公司或者项目要求

4.缺陷编写规范

•         准确：描述的信息是正确的
•         简洁易懂：描述简单容易理解
•         具体：有细节且是真实具体的
•         次序清晰：描述缺陷过程有条件，有先后顺序

后记

        希望各位看友，能够对我的此篇文章进行 “测试”，然后进行 “缺陷管理”，与我这个 “后端” 对接。