功能测试-测试缺陷

上一篇说了测试用例，在用例执行的过程中，不可避免的就会发现用例执行结果与期望结果不相符，如果没有进行过需求变更，一般就可以认定为缺陷了

缺陷

手工测试，工作中最主要的几件事：编写用例、执行用例、提交缺陷、回归缺陷、写报告，由此可见，除了用例，就是缺陷来体现测试的价值了。现在就从缺陷的要素说起

• 缺陷所属的项目

  • 一般情况下，与测试用例同属于一个项目组，都是与用例强关联的

• 缺陷所属的版本

  • 一个项目随着项目的进展，肯定会有多个版本，因每个版本调整的代码不同，所以缺陷也有所不同

  • 一般一个缺陷只属于一个版本（除延期解决缺陷）

• 缺陷编号

  • 一般系统自动生成，编号前缀带有项目组或者版本号+随机数或自增序列

• 缺陷标题

  • 对缺陷精要（简洁、准确）的描述，体现实际结果与期望结果的差异点，一目了然

• 缺陷重现步骤

  • 详细描述缺陷重现的前置条件和操作步骤，甚至是测试的账号、订单

  • 清楚描述期望结果与实际结果，如果有必要，贴上报错日志、报错代码、对比图等

• 缺陷状态

  • 状态的流转每个缺陷管理系统都不一样，所以状态的流转也不一样，大体的状态变化如下：

• 缺陷的严重程度

  • 每个项目组或公司根据业务的不同，对严重程度的定级也不完全一致，一般会分为5个等级

    缺陷严重 程度	描述
    致命（非常严重）	系统主要功能完全丧失，用户数据受到破坏，系统崩溃、悬挂、死机、或者危及人身安全
    严重	系统的主要功能部分丧失，数据不能保存，系统的次要功能完全丧失，系统所提供的功能或服务受到明显的影响
    一般	系统的次要功能没有完全实现
    轻微	用户操作不方便或感到麻烦，但不影响正常功能的使用
    建议	建议级别的缺陷，如不易使用、操作习惯不符合常规等

• 缺陷的备注

  • 主要是辅助说明缺陷的报错情况，一般是图片、附件、视频等，方便开发重现缺陷和查找报错代码，定位问题

• 缺陷的优先级

  • 一般有了严重程度，这个指标就不常用了，当然也可以同时使用，一般分为5个等级

    缺陷的优先级	描述
    特急	该缺陷导致系统不能使用或测试不能继续，非常紧急，需立即进行处理
    紧急	缺陷严重，影响测试版本或产品目的，需优先考虑
    正常	对产品来说不是那么关键的场景或特性，正常修复即可
    优化	对产品使用没有太大影响，如能修复这个缺陷会很好
    延时解决	对产品的影响非常小，可在开发有时间的时候再进行修复

• 缺陷类型

  • 主要是为了后期缺陷统计、缺陷分析做铺垫，方便后期持续优化，一般分为如下类型

    缺陷类型	描述
    需求缺陷	主要是需求描述有缺失甚至需求描述有问题，或需求未及时更新
    配置缺陷	业务配置或中间件配置错误导致或配置缺失导致
    编码缺陷	功能未实现或功能实现错误
    外部系统缺陷	第三方系统或者中间件的缺陷，同步修改或升级版本
    非功能缺陷	安全缺陷或者性能缺陷，及时修复或进行性能调优
    用户体验缺陷	兼容性、界面展示、排版、使用习惯等问题

• 缺陷所属的模块

  • 是从另一个角度来统计、分析缺陷，这个就会根据项目架构和业务的不同，拆分就不同，主要有如下模块

    缺陷所属模块	描述
    基础组件模块	与业务代码不是强相关的模块，例如数据库、邮件、短信、日志、监控等
    用户认证模块	用户体系的创建、更新、删除、认证等
    计划出行模块	用户的搜索、查询、对比等
    订单模块	用户订单创建、订单变更、订单查询、订单取消等
    支付模块	用户订单支付、订单退款等
    确定出行模块	用户订单出行、变更出行等
    取消出行模块	用户出行取消、变更出行取消等

• 缺陷产生的环境

  • 这个主要是针对APP类型，主要是确定缺陷在哪个内核、哪个版本、哪种配置下有问题

  • 如果是WEB页面，需要关注下浏览器的版本和内核

• 缺陷提交人员

  • 缺陷提交人员一般也是缺陷回归人员，谁提交的缺陷，谁负责跟踪到底

  • 如果开发对缺陷有疑问或无法重现时，方便寻求协助和沟通

缺陷分析

缺陷分析是形成质量闭环的很重要的一环，也是反向证明开发阶段的测试质量的高低，当然也反映了软件的整体质量。缺陷分析一般可以从三个角度出发去分析，即：缺陷 、用例、测试周期

• 缺陷

  • 缺陷可以从这几个方面出发

  • 总的缺陷数量（从整体看软件的缺陷密度）

  • 总的高等级缺陷数量（从整体看开发质量）

  • 开发阶段与测试阶段的缺陷数量占比（开发阶段占比越高，相对来说修复成本越低）

  • 缺陷所属的模块和类型（从整体上，需要重点关注哪些模块是比较容易出问题，需要重点测试）

  • 有效缺陷占比（侧面反映测试人员的水平，缺陷否决越多、一般表明对需求的理解可能有偏差）

  • 自动化用例发现的缺陷与手工发现的缺陷占比（反映自动化用例质量的高低）

  • 重复用例发现的缺陷占比（直接反映自动化用例编写人员的水平和对断言的精准程度）

• 用例

  • 总的用例数（从整体看，用例执行情况和缺陷密度）

  • 开发阶段的用例数（与开发阶段的缺陷对应，可以计算缺陷密度）

  • 测试阶段的用例数（与测试阶段的缺陷对应，可以计算缺陷密度）

  • 开发阶段与测试阶段重复的用例数（与重复缺陷对应，反映自动化用例质量）

• 测试周期（时长）

  • 总的测试周期（从整体看软件的发布频率）

  • 开发阶段的测试周期（间接反映开发的难度和开发质量）

  • 测试阶段的测试周期（直接反映开发质量）

  • 缺陷从提交到终态的周期（直接反映缺陷的修复速度，当然越快被处理越好）

  当然一定不要为了做分析而做分析，一定要有产出和后续的改进，不然分析的价值就被稀释掉了。

  比如在测试阶段发现的缺陷，及时转化成自动化用例或补充缺失的断言，这样自动化的用例场景才会越来越丰富、自动化的用例质量才会逐步提升，才可以逐渐相信自动化用例是可以部分代替手工测试的