文章目录
一、缺陷管理
1、缺陷相关概念
1）什么是缺陷
被测的产品不符合需求和用户使用的实际结果，不符合法律法规
软件：满足某个功能的逻辑体
系统：硬件、支撑软件、人员、数据等，综合起来满足某个业务需求的集合体
2）缺陷的分类
- 缺陷defect：产品设计和需求设计不符合
- 错误error：没有定义的或者未知的错误信息
- 故障fault：由于一些原因导致产品失效，重新启动调整后可以恢复用户使用
- 失效failure：由于一些原因产品失效，无法自行恢复
3）缺陷提出的目的和意义
对开发：
更好发现缺陷现象，重现和定位缺陷，查找原因，保证所有的缺陷都被修复
对测试：
记录保证BUG完整一致，回归保证所有的BUG都验证
提出问题，把问题交给开发去改
跟踪缺陷，看是否已经修改
测试报告，统计数据
2、缺陷管理相关概念
1）BUG管理的目的
- 保证每个缺陷都被修改
- 保证每个缺陷都被回归
- 缺陷的完整性和一致性
- 避免纠纷，降低沟通成本
2）缺陷管理的意义：
- 提高工作效率（BUG分类，状态负责人）
- 记录唯一的缺陷信息，保证BUG完整一致(通过设置权限实现)
- 记录中间环节，使BUG可追溯
- 统计为测试报告提供数据
3）参与缺陷管理的角色：
测试工程师：发现和回归BUG
测试经理：判断BUG的有效性
开发经理：分配BUG
开发工程师：修改BUG
评审：解决矛盾
4）缺陷的分类(属性)
i、按模块分类
例如：登录模块，查询模块
ii、按严重级别分类
blocker 阻碍的（不修改该BUG的话之后的开发测试无法执行）
critical 崩溃（系统不能用）
major 严重的 （严重影响功能使用流程）
anormal 一般的（不会影响主要的功能流程）
minor 轻微的 （不会影响业务流程也不影响使用）
trvival 界面的
suggestion 建议（可用性，易用性，侧重用户体验）
iii、按优先级别分类
P1~P5（同意 BUG可能会变）
3、BUG管理基本流程
1）缺陷管理常见流程
- BUG回归时没有修改好：测试工程师reopen–开发工程师
- 测试经理认为BUG无效
- 原因：不是BUG，对需求的理解误差，描述不清楚。BUG不全，重复
- 测试工程师NEW–测试经理can open —rejected—测试工程师closed
- 开发工程师拒绝修改BUG
- 原因：修复提高项目风险，理解分歧，技术难度大，修复成本高修改范围广，优先级低
- 开发经理拒绝修改或分配BUG
- 原因：开发和测试已经不同意，偶发，项目风险高，关系进度成败，技术难度大，无法实现，修改成本高，难度大，影响进度优先级别低
- 测试工程师NEW–测试经理open–开发经理assigned–评审委员会can later–Y(later)–N开发经理
- 一般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单模板
| 项目 | 内容 | 用于quexiang |
|---|---|---|
| 缺陷ID | 必须有 | 用于quexian管理中的唯一编号 |
| 测试用例ID | 可以没有 | |
| 发现日期 | ||
| 测试者 | ||
| 缺陷描述 | 在哪个模块，做了什么，出了什么错误结果；必须有 | 用一句话简单的描述清楚问题 |
| 重现缺陷操作 | 测试环境 | 建议必须有，实际不一定有，有统一测试环境可不写 |
| 重现缺陷操作 | 操作步骤 | 必须有 |
| 重现缺陷操作 | 测试数据 | 必须有 |
| 重缺陷操作 | 预期结果 | 必须有 |
| 重现缺陷操作 | 实际结果 | (报错信息、截图)必须有 |
| 重现缺陷操作 | 简单分析 | 建议有 |
| 重现缺陷操作 | 附件 | 建议有 |
| 状态 | 必须有 | 属性 |
| 缺陷严重程度 | 建议有 | 属性 |
| 缺陷优先级别 | 建议有 | 属性 |
| 版本号 | 必须有 | 被测试软件的版本 |
| 缺陷解决方法 | 开发人员填写，一般无 | 修改人信息 |
| 解决人&日期 | 开发人员填写，一般无 | |
| 验证人&日期 | 一般无 |
4、注意
- 一定可以重现的BUG可以不写“重复几次操作，出现几次”，标题中不能使用主观的话描述，比如：“我在，我认为”，禁止使用“某些好像等”不确定的话，以及“然后”等
- 需求规格说明书以外的错误可以当建议报告，不当BUG报告，开发可以改，也可以不改
- 若是随机出现的BUG，要写出操作几次，出现几次
- 若被测试软件是跨平台软件，要写上在其他平台下无误
- 禁止写冗余的操作步骤。常识性的步骤不用写进缺陷操作步骤
- 写明环境数据，如何选择数据，数据如何被破坏
- 一定要交代清楚测试书记，明确处理对哪些数据进行操作
二、配置管理
1、基本概念
- 对所有配置项进行标识，解决了在不同时间周期内，这些文档贯穿整个项目的生命周期，对配置项进行权限的控制
- 配置管理的目的：解决了保证了软件产品的完整性、一致性、共享性、权限、变更可控、可追溯性
- 配置管理包括什么：
- 配置型：项目过程中每个阶段的文档产物(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)