缺陷的评价标准：

  1. 缺失功能
  2. 功能错误
  3. 多余功能 —
  4. 约定俗成功能缺失 —约定俗成的功能
  5. 不易使用 —软件难以理解，不易使用

缺陷出现的原因

  1. 需求阶段 —需求描述不易理解
  2. 设计阶段 — 文档出现错误，思虑不周
  3. 编码阶段 — 代码出现错误
  4. 运行系统 — 软件系统本身故障、配置项有误
  • 注意：
    测试人员，在需求阶段介入测试，产生bug最少，成本最低

缺陷的特点

  1. 二八原则
  2. 测试越到后期，越不容易发现bug
  3. 允许bug遗留延后或不解决 — 
    允许bug存在不超过2%
各种成本与产出不成比例，
修复风险太大
不算真正的软件缺陷

bug的流程-生命周期

禅道

禅道的安装：

https://www.zentao.net/
当前目录：D:\chandao\xampp\

正在启动……
正在安装服务：apachezt…安装成功。
正在启动服务：apachezt…端口:80…
成功启动服务，端口号为：80
正在安装服务：mysqlzt…安装成功。
正在启动服务：mysqlzt…端口:3306…失败。
再次尝试启动服务：mysqlzt…端口:3306…失败。
启动失败，请稍后重试。

更改端口号
禅道mysql端口不能与本地 mysql端口号不能冲突
禅道账号：admin 密码： zkf123456

A公司流程——瀑布流程，测试介入晚
产品创建计划→管理需求→指派UI→指派开发→指派测试→指派产品经理→对比

缺陷报告组成

  1. id — 全项目中唯一bug编号 — 禅道自动生成
  2. 标题 —一句话概括，描述现象，是bug的原因
  3. 模块 — 缺陷发现的模块
  4. 严重程度 —
    等级1 —致命的（urgent）—
    等级2 — 严重的（high）—主功能缺失
    等级3 — 中等的，一般的（medium） — 小功能，分支的缺失
    等级4 — 建议性小问题（low）— 页面字体小错误等
  5. bug描述：
  6. 前置条件
  7. 操作步骤
  8. 预期结果
  9. 实际结果
  10. 优先级：
    级别1   -- 立即解决（bug-urgent）
级别2   -- 下一个版本解决（bug-high）  
级别3    -- 软件发布前（bug-medium）
级别4    -- 尽量在软件产品发布前（low）
  11. 附件：发生bug时的界面截图，后添加报错日志截图，录屏
     注意：
 解决bug的成本越低，优先级越高
 开发压力越小，优先级越高
 影响范围越广，优先级越高

排查缺陷的思路

  1. 依赖重要文档《测试用例》：
  2. 对比UI搞：比对出不一致点
  3. 借助抓包工具：比对入参和出参的正确性
  4. 检查数据库： 在数据库操作增删改查
  5. 检查运行日志： 使用xshell工具链接服务器，检测后台运行日志
  6. 站在用户角度：找到对系统的不满意度

高质量缺陷的组成

要描述清楚缺陷的各种要素：缺陷标题、所属模块、重现步骤、缺陷状态、缺陷的严重等级、优先级、附件、提交人；缺陷的附件中可以加上缺陷的现象进行截图、还可以提交缺陷的日志信息；高质量的缺陷能够协助开发快速定位，可以在缺陷描述中加上缺陷的分析过程；

偶发性的缺陷的处理

1) 首先要想办法复现
2) 如果不能复现也会提交到缺陷管理工具上
3) 连续更迭超过 3 个版本，bug 没有出现，会将 bug 挂起
driver.get_screen_shot_as_png();

处理线上bug

  1. 当前的一个紧急对策：
    首先评估这个问题是否影响用户使用这个产品，如果是一个一般的缺陷对用户影响不大，我们需要把这个缺陷记录下来在下一个版本上线的时候进行修复；如果是一个严重的缺陷对用户的影响很大，需要立即反馈给项目经理，由项目经理决定是否回退到上一个版本或者发布一个紧急版本把这个缺陷修复掉；
  2. 长期对策：
    需要检讨问题为什么在测试环境没有发现，会留到生产环境，检讨是否需要优化研发流程，是否需要提升人员技能，避免以后在出现类似的问题；

代表性缺陷