文章目录

• 一、缺陷管理
• • 1、缺陷相关概念
  • • 1）什么是缺陷
    • 2）缺陷的分类
    • 3）缺陷提出的目的和意义
  • 2、缺陷管理相关概念
  • • 1）BUG管理的目的
    • 2）缺陷管理的意义：
    • 3）参与缺陷管理的角色：
    • 4）缺陷的分类(属性)
    • • i、按模块分类
      • ii、按严重级别分类
      • • • a、一级：致命问题
          • b、二级：严重问题
          • c、三级：一般问题
          • d、四级：提示及建议问题
      • iii、按优先级别分类
  • 3、BUG管理基本流程
  • • 1）缺陷管理常见流程
    • 2）缺陷状态
  • 3、BUG单
  • • 1）BUG单写作准则(5C)
    • 2）BUG单模板
  • 4、注意
• 二、配置管理
• • 1、基本概念
  • 2、配置管理流程

一、缺陷管理

1、缺陷相关概念

1）什么是缺陷

被测的产品不符合需求和用户使用的实际结果，不符合法律法规
软件：满足某个功能的逻辑体
系统：硬件、支撑软件、人员、数据等，综合起来满足某个业务需求的集合体

2）缺陷的分类

1. 缺陷defect：产品设计和需求设计不符合
2. 错误error：没有定义的或者未知的错误信息
3. 故障fault：由于一些原因导致产品失效，重新启动调整后可以恢复用户使用
4. 失效failure：由于一些原因产品失效，无法自行恢复

3）缺陷提出的目的和意义

对开发：
更好发现缺陷现象，重现和定位缺陷，查找原因，保证所有的缺陷都被修复
对测试：
记录保证BUG完整一致，回归保证所有的BUG都验证
提出问题，把问题交给开发去改
跟踪缺陷，看是否已经修改
测试 告，统计数据

2、缺陷管理相关概念

1）BUG管理的目的

1. 保证每个缺陷都被修改
2. 保证每个缺陷都被回归
3. 缺陷的完整性和一致性
4. 避免纠纷，降低沟通成本

2）缺陷管理的意义：

1. 提高工作效率（BUG分类，状态负责人）
2. 记录唯一的缺陷信息，保证BUG完整一致(通过设置权限实现)
3. 记录中间环节，使BUG可追溯
4. 统计为测试 告提供数据

3）参与缺陷管理的角色：

测试工程师：发现和回归BUG
测试经理：判断BUG的有效性
开发经理：分配BUG
开发工程师：修改BUG
评审：解决矛盾

4）缺陷的分类(属性)

i、按模块分类

例如：登录模块，查询模块

ii、按严重级别分类

blocker 阻碍的（不修改该BUG的话之后的开发测试无法执行）
critical 崩溃（系统不能用）
major 严重的 （严重影响功能使用流程）
anormal 一般的（不会影响主要的功能流程）
minor 轻微的 （不会影响业务流程也不影响使用）
trvival 界面的
suggestion 建议（可用性，易用性，侧重用户体验）

a、一级：致命问题

b、二级：严重问题

c、三级：一般问题

d、四级：提示及建议问题

iii、按优先级别分类

P1~P5（同意 BUG可能会变）

3、BUG管理基本流程

1）缺陷管理常见流程

1. BUG回归时没有修改好：测试工程师reopen–开发工程师
2. 测试经理认为BUG无效
   • 原因：不是BUG，对需求的理解误差，描述不清楚。BUG不全，重复
   • 测试工程师NEW–测试经理can open —rejected—测试工程师closed
3. 开发工程师拒绝修改BUG
   • 原因：修复提高项目风险，理解分歧，技术难度大，修复成本高修改范围广，优先级低
4. 开发经理拒绝修改或分配BUG
   • 原因：开发和测试已经不同意，偶发，项目风险高，关系进度成败，技术难度大，无法实现，修改成本高，难度大，影响进度优先级别低
   • 测试工程师NEW–测试经理open–开发经理assigned–评审委员会can later–Y(later)–N开发经理
5. 一般BUG生命周期
   • 测试工程师NEW—测试经理open—开发经理assigned—开发工程师fixed—测试工程师closed

2）缺陷状态

NEW新BUG单 open确认 reject拒绝 assigned已分配 fixed已修复 reopen回归时未修改正确就重新开放 closed关闭 later稍后再改 postpone延迟 abandon放弃 duplicate重复 verify验证
测试人员：无–NEW fixed–reopen fixed–close
测试组长：NEW–open NEW—abandon
开发经理：open–reject open–postpone open–assign
开发人员：assign–fixed
项目经理：reject–passed reject–failed failed–abandon

3、BUG单

1）BUG单写作准则(5C)

• correct(准确)每个组成部分的描述准确，不会引起误解
• clear（清晰）每个组成部分的描述清晰，易于理解
• concise(简洁)只包含必不可少的信息，不包括任何多余的内容
• complete（完整）包含复现改缺陷的完整步骤和其他本质信息
• consistent（一致）按照一致的格式书写全部缺陷 告

2）BUG单模板

4、注意

1. 一定可以重现的BUG可以不写“重复几次操作，出现几次”，标题中不能使用主观的话描述，比如：“我在，我认为”，禁止使用“某些好像等”不确定的话，以及“然后”等
2. 需求规格说明书以外的错误可以当建议 告，不当BUG 告，开发可以改，也可以不改
3. 若是随机出现的BUG，要写出操作几次，出现几次
4. 若被测试软件是跨平台软件，要写上在其他平台下无误
5. 禁止写冗余的操作步骤。常识性的步骤不用写进缺陷操作步骤
6. 写明环境数据，如何选择数据，数据如何被破坏
7. 一定要交代清楚测试书记，明确处理对哪些数据进行操作

二、配置管理

1、基本概念

1. 对所有配置项进行标识，解决了在不同时间周期内，这些文档贯穿整个项目的生命周期，对配置项进行权限的控制
2. 配置管理的目的：解决了保证了软件产品的完整性、一致性、共享性、权限、变更可控、可追溯性
3. 配置管理包括什么：
   • 配置型：项目过程中每个阶段的文档产物(SRS、HLD、LLD)，代码，开发工具，测试工具，环境(应用服务器，数据库服务器)，第三方软件，用户手册，方案，用例等
   • 对象的版本：XX、YY、ZZ、PP
     • XX：主版本 –内核程序，核心代
     • YY：子版本 –主要功能、添加功能
     • ZZ：维护版本 –增加次要功能，功能改进
     • PP：补丁 –SP
   • 对象的状态：未检查、入基线、冲突、锁

注： BUG单也算配置项，但是一般单独管理，常用管理工具：QC，Jira，Bugfree，Bugzila

2、配置管理流程

项目经理PM(project maneger) 、配置管理员CMO(Configuration Manage Officer )、开发经理DM(Development Manger)、测试经理、开发工程师、测试工程师、质量保证人员QA(Quality Assurance) 、变更控制委员会CCB(Change Control Board)