软件测试--测试基础8--缺陷管理、配置管理

一、缺陷管理

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、一级：致命问题

子项	概述	具体描述
A-1	操作系统崩溃	运行软件系统后会导致操作系统崩溃()内存漏留严重或CPU占用100%
A-2	导致软件系统崩溃	因操作某项功能而导致软件系统自动崩溃或死机
A-3	导致整个模块或软件按系统不能使用	因操作某个功能，导致整个模块或软件系统不能使用
A-4	信息丢失	1.数据库数据会丢失2.打印出来的报告与实际内容不相符 3. 出现串报告或串影响原因
A-5	业务流错误	1. 业务流程没达到设计要求 2. 因业务流程中的某个功能没有实现而导致整个业务流程不能完整的实现
A-6	核心功能不能使用	1. 客户端核心功能无法使用或报错（例如：登记、采图、写报告、打印等）2. 服务端无法加载或启动，导致客户端无法使用

b、二级：严重问题

子项	概述	具体描述
B-1	重要数据计算错误	1.重要数据统计信息存在较大的差异 2. 重要数据计算方法有错
B-2	数据库发生错误	1. 执行某一操作时会出现数据库死锁现象 2. 数据库通讯错误
B-3	系统不稳定	1. 系统在操作主要功能中会出现偶发的报错 2. 系统在使用过程中会出现闪退 3. 查询、打开速度很慢，超过正常范围的2倍 4. 操作某个功能有时无反应 5.系统在运行一段时间后会明显变慢，影响业务操作
B-4	安全性问题	1. 系统没有建立用户账号，没有设置密码访问 2. 数据库敏感内容没有加密(如：密码等) 3. 同一份报告可同时多人编辑 4. 客户端没有授权也可以正常登录（加密狗权限）

c、三级：一般问题

子项	概述	具体描述
C-1	一般功能未实现	1. 一般的功能不能使用 2. 一般的功能实现达不到用户需求
C-2	无信息合法性检查	1. 没有对输入的数据类型进行检验（如日期型文本框中输入字符型数据时没有弹出提示信息）2. 输入框不允许为空，而用户输入为空时没有相应的提示信息 3. 输入非法字符、输入的字符长度超出允许的长度范围时出错 4. 输入超大、超小值溢出错误（数值型、日期型字段）
C-3	兼容性问题	1. 业务系统对操作系统的兼容性不好 2. 对于浏览器的兼容性不好 3. 对主流的数据库兼容性不好
C-4	软件使用不便	1. 输入或选择无法正常得到焦点 2. 进行某项操作后，显示出的光标所在焦点与实际所在的焦点不一致 3. 没有使用数据调用而导致用户重复输入量过多 4. 进行某操作后返回，无法回到原来所在的位置 5. 新增记录没有排在首行 6. 不符合用户䣌操作习惯（如Windows操作习惯，没使用常用的默认键、快捷键、TAB顺序与使用顺序不一致等）
C-5	数据不能立即更新	1. 界面中的统计数据没有及时更新 2. 用户添加/修改/删除的数据没有及时更新 3. 按钮或选项状态(有效/无效)没有及时变更 4. 界面数据刷新不正确
C-6	删除操作没给出提示	1.对于关键性数据删除时没有给出提示 2. 重要信息删除后不能恢复

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

子项	概述	具体描述
D-1	界面显示错误	1. 排版不规则 2. 文字、图片不能完全显示或错误 3. 打印排版、格式错误（格式根据客户需求，一般打印一幅画以A4为准）4. 不同分辨率下界面显示不正常
D-2	信息提示不清	1.信息提示不易理解、有歧义或不统一 2. 提供给用户过多无用或过少的信息 3.当鼠标移到图片或按钮上时，无浮动的提示语 4. 提示信息先后无序（针对嵌套提示框）
D-3	界面不规范	1. 界面风格、操作方式不统一（控件、文字、颜色等）2. 标题不规范或各处信息描述不一致
D-4	界面文字错误	1.文字拼写错误 2. 语法错误 3. 标点符号错误或全、半角混杂等
D-5	界面操作性建议	1. 对界面的优化建议 2. 对操作方便性的建议

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单模板

项目	内容	用于quexiang
缺陷ID	必须有	用于quexian管理中的唯一编号
测试用例ID	可以没有
发现日期
测试者
缺陷描述	在哪个模块，做了什么，出了什么错误结果；必须有	用一句话简单的描述清楚问题
重现缺陷操作	测试环境	建议必须有，实际不一定有，有统一测试环境可不写
重现缺陷操作	操作步骤	必须有
重现缺陷操作	测试数据	必须有
重缺陷操作	预期结果	必须有
重现缺陷操作	实际结果	(报错信息、截图)必须有
重现缺陷操作	简单分析	建议有
重现缺陷操作	附件	建议有
状态	必须有	属性
缺陷严重程度	建议有	属性
缺陷优先级别	建议有	属性
版本号	必须有	被测试软件的版本
缺陷解决方法	开发人员填写，一般无	修改人信息
解决人&日期	开发人员填写，一般无
验证人&日期	一般无

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)