4.缺陷管理流程

缺陷管理流程

一、概念

1. 缺陷：经常被称为bug，IEEE定义：计算机软件或程序中存在某种破坏正常运行能力的问题、错误、隐藏的功能错误。
   1. 内部：开发过程或维护过程引入的错误
   2. 外部：软件的功能失效或违背
   3. 辨识：错误是缺陷的静态表述，错误被激活了，变成故障，故障如果没有被修复，导致功能失效或违背 【重要】
2. 缺陷的主要表现
   1. 需求要求的功能没有实现
   2. 实现了需求没有要求的功能
   3. 软件中出现了明确要求不应该出现的错误
   4. 需求中没有明确说，但是应该实现的功能
   5. 软件使用体验层面：难以理解、不好用，可用性方面的问题
3. 产生原因
   1. 软件本身
      1. 需求不够明确
      2. 软件复杂度高
      3. 新技术采用
      4. 接口比较多
   2. 团队工作
      1. 需求理解不一致，需求管理不够严谨
      2. 开发人员内部沟通不清楚
      3. 研发团队成员的技术水平高低不一样
   3. 技术问题
      1. 算法错误
      2. 语法错误
      3. 计算精度问题
      4. 系统设计的时候没有使用科学的方法
   4. 管理方面的问题
      1. 没有质量文化，也不重视计划
      2. 时间紧，开发周期短
      3. 客户沟通问题

二、缺陷的放大模型

1. 模型图

三、缺陷的管理流程

1. 缺陷的生命周期
   1. 新建：测试工程师发现缺陷，并进行初步的定位
   2. 重复缺陷：测试主管审核之后，发现缺陷是重复提交
   3. 拒绝：经过审核发现不是缺陷
   4. 打开：经过审核之后，发现是一个有效缺陷
   5. 已修复：开发修复并验证后
   6. 关闭： 经过测试工程师回归缺陷，发现缺陷确实被修改正确了
   7. 重新打开：回归缺陷之后，发现缺陷并没有被修复
   8. 挂起：技术审核发现，缺陷因为某些特殊原因而无法被修复
2. 缺陷的状态分析
   1. 终态：重复缺陷，关闭，被拒绝
   2. 中间态：打开、已修复、挂起
3. 拒绝缺陷的处理方式
   1. 如果测试提交的缺陷被开发拒绝，首先进行自检，对着需求文档确认预期结果是没有问题，再确认测试环境和用例的正确性。然后去开发的环境进行复现，和开发进行确认。如果开发依旧拒绝，测试一定要把缺陷发给产品经理和项目负责人，由他们进行仲裁。
4. 挂起缺陷的处理方式
   1. 开发认为这个缺陷当前的技术或者某种条件的限制导致缺陷没有办法被修复，或暂时无法修复。要把这个缺陷提交给产品经理和项目负责人，由他们进行最终审核。如果最终确定可以挂起，开发必须提交应急方案。
5. 缺陷报告的编写要点
   1. 标题：在什么情况下，发生了什么问题
      1. 例如：输入错误的密码，提示：验证码错误
   2. 前置条件： 缺陷产生前所设置一些条件，数据、环境、配置项
   3. 复现步骤：同测试用例的步骤
      1. 在什么元素上进行了什么操作，需要什么数据，看到什么结果
         1. 以上数据和结果部分，不一定每个步骤都有
         2. 在用户名输入框中输入：admin
   4. 预期结果
   5. 实际结果
   6. 严重程度【重要】
      1. 致命
         1. 系统崩溃
         2. 数据丢失或大面积错乱（100个记录）
      2. 严重
         1. 功能缺失
         2. 功能实现错误
         3. 性能问题：死锁、内存泄露、资源消耗过快
         4. 安全问题
         5. 大面积的样式错乱
      3. 一般
         1. 功能的容错处理存在问题
         2. 比较难以复现的缺陷
         3. 小规模的样式问题
      4. 轻微
         1. 局部样式问题
         2. 错别字在非关键位置出现的
         3. 使用体验上的问题
   7. 优先级：开发人员
      1. 高
         1. 流程分析法设计的用例发现的bug
         2. 有效类发现的bug
         3. 状态迁移发现的bug
      2. 中
         1. 特殊的无效类
         2. 边界值离点
      3. 低
         1. 轻微级别的bug
   8. 复现率： 不是每个缺陷都是每次能够复现。
      1. 填写方式： 测试n次出现m次。 测试了10次，出现了2次

四、项目管理软件

1. QC：需求管理、用例管理、缺陷管理、项目管理于一体，支持敏捷实践。AIM
2. redmine：和QC比较像
3. jira：缺陷管理、流程管理
4. testlink：用例管理，免费
5. 禅道：免费开源，收费版

五、禅道的安装与使用

1. 释放到D盘根目录

六、测试用例编写要点

1. 标题
   1. 只需要描述当前用例的作用
2. 前置条件
   1. 预先做的准备
3. 操作步骤
   1. 在什么对象上面使用什么行为，需要什么数据，看到什么结果
4. 预期结果
   1. 描述出实际的显示的内容和形式
5. 优先级： 测试工程师关注的
   1. 高
      1. 流程分析法编写的用例
      2. 状态迁移法设计的用例
      3. 等价类方法有效类
   2. 中
      1. 等价类的普通无效类
      2. 边界值设计的用例
      3. 错误猜测法
      4. 正交实验法
   3. 低
      1. 等价类特殊无效类
      2. 其他一些重复的但感觉有必要测试

七、测试术语

1. 软件分类
   1. 项目型软件
   2. 产品型软件
2. 测试分类
   1. 按阶段分：
      1. 单元测试
      2. 集成测试
      3. 系统测试
      4. 验收测试
         1. 项目型软件：甲方验收
         2. 产品型，测试团队负责验收
      5. alpha测试：内测
      6. beta测试：公测
   2. 是否需要了解程序内部实现的逻辑
      1. 白盒测试：单元测试
      2. 灰盒测试：使用黑盒测试 的方法，进行编码实现测试
      3. 黑盒测试：
   3. 按照是否需要运行程序
      1. 静态测试
      2. 动态测试
   4. 按照是否使用工具和脚本
      1. 手工测试
      2. 自动化测试
   5. 是否具备特殊作用
      1. 冒烟测试:第一次提交刚刚经过编译的软件，对其主要的功能进行正确性严重的测试
         1. 开发先做一遍
         2. 测试再做一遍
         3. 测试需要给开发提供冒烟测试用例，流程分析法设计编写
      2. 随机测试：猴子测试
      3. 探索测试：在随机测试的基础上，预先制定一些目标，然后围绕这个目标进行有规范随机测试。
      4. 回归测试：把原来执行过的用例再执行一遍
3. 概要设计：在设计阶段把各项需求转换为技术系统结构的过程。
4. 详细设计：对每个模块要完成的工作进行具体的描述。

法设计编写
2. 随机测试：猴子测试
3. 探索测试：在随机测试的基础上，预先制定一些目标，然后围绕这个目标进行有规范随机测试。
4. 回归测试：把原来执行过的用例再执行一遍
3. 概要设计：在设计阶段把各项需求转换为技术系统结构的过程。
4. 详细设计：对每个模块要完成的工作进行具体的描述。