17-缺陷

缺陷

• 缺陷的主要表现有：
  • （1）需求要求的功能没有实现
  • （2）实现了需求没有要求的功能
  • （3）软件中出现了明确指明不应该出现的错误
  • （4）需求中虽未明确说明，但是应该实现的功能没有实现，（说明：需求不是完美的，有可能有遗漏，测试人员因为需求的问题，影响测试结果的提交）
  • （5）软件不易使用，难以理解，运行缓慢等，站在用户角度上，一切觉得不好的地方。
• 缺陷的内容
  • 缺陷的编号：一般由管理工具自动生成
  • 缺陷标题（概要描述）：使用简明扼要的语言描述清楚缺陷的表象
    • 例：商品出库时优惠金额大于商品销售时交易成功，与需求不符
  • 发现人：一般由管理工具自动填写
  • 发现时间：一般由管理工具自动填写
  • 修复时间：开发人员填写
  • 所属版本：填写发现时间的应用版本
  • 所属模块：缺陷属于那个功能模块
  • 重现步骤（功能描述）：描述发现缺陷的步骤，测试数据 ，测试环境（基本原则就是根据该描述重现缺陷） 
  • 缺陷状态：缺陷当前所处的状态，根据该状态知道缺陷当前的处理进度
  • 缺陷的状态：
    • new：缺陷的初始状态
    • open：开发人员开始修改缺陷
    • fixed：开发人员修改缺陷完毕
    • closed：回归测试通过
    • postpone：推迟修改
    • rejected：开发人员不认为是程序问题，拒绝缺陷
    • duplicate：与已经提交的defect重复
    • abandon：被reject和duplicate的defect，测试人员确定后的确不是问题，将defect置为此状态
  • 禅道
    • 激活
    • 已解决
    • 已关闭
  • 严重的程度
    • urgent，缺陷的出现已发大面积的功能错误，业务中断，系统崩溃等问题
    • very high，缺陷的出现引起系统功能的不可用
    • high，缺陷的出现引起系统功能问题
    • medium，一般为显示错误，提示信息错误等问题
    • low，一般为用户体验的问题
  • 优先级
    • 描述缺陷的修复排序，大多数情况与缺陷的严重程度正相关
  • 下一步处理人
    • 代表下一步的处理人
  • 附件
    • 发现问题的截图，方便处理bug
• 缺陷的管理流程
  • 测试人员：发现并提交缺陷，验证缺陷，关闭缺陷
  • 测试负责人：审批测试人员提交的缺陷，分配给缺陷给开发，评审存在争议的缺陷
  • 开发负责人：审批缺陷，分配缺陷给开发人员，评审存在争议的缺陷
  • 开发人员：修改存在的缺陷
  • 产品或者业务人员：评审存在争议的缺陷
  • 项目经理：评审存在争议的缺陷