缺陷管理

缺陷相关概念

1什么是缺陷：被测得产品部符合需求和用户使用的实际结果，不符合法律法规

软件：满足某个功能的逻辑体

系统：硬件、支撑软件、人员、数据等，综合起来满足某个业务需求的集合体

2什么可以被定义为缺陷：（缺陷的分类）

①缺陷（defect）产品设计与需求设计部符合

②错误（error）没有定义的或者未知的错误信息

③故障（fault）由于一些原因导致产品失效，重新启动调整后可以恢复用户使用

④失效（failure）由于一些原因产品失效，无法自行恢复

3缺陷提出的目的和意义

对开发：更好发现缺陷现象，重现和定位缺陷，查找原因，保证所有的缺陷都被修复

对测试：记录和保证BUG完整一致，回归保证所有的 BUG都验证

提出问题，把问题交给开发去改

               跟踪缺陷，看是否已经修改

               测试报告，统计数据

缺陷管理相关概念

1．BUG管理的目的：

①.保证每个缺陷都被修改

②.保证每个缺陷都被回归

③.缺陷的完整性和一致性

④.避免纠纷，降低沟通成本

2缺陷管理的意义：

①提高工作效率（BUG分类，状态负责人）

②记录唯一的缺陷信息，保证BUG完整一致（通过设置权限实现）

③记录中间环节，是BUG可追溯

④统计为测试报告提供数据

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

测试工程师：发现和回归BUG

测试经理：判断BUG的有效性

开发经理：分配BUG

开发工程师：修改BUG

评审：解决矛盾

4．缺陷的分类（属性）

①按模块分类：例如：登录模块，查询模块

②按严重级别分类：blocker阻碍的（不修改该BUG之后的开发测试无法执行）

Critical崩溃（系统部能用） 

major严重的（严重影响功能使用流程） 

anormal一般的（不会影响主要的功能流程） 

minor轻微的（不会2影响业务流程也不影响使用） 

trvival 界面的

suggestion建议（可用性，易用性，侧重用户体验）

③按优先级别分类：P1----P5(同意 BUG可能会变)

BUG管理基本流程：

BUG管理基本流程及相关角色

1缺陷管理常见流程

1）  BUG回归时没有修改好：测试工程师REOPEN——开发工程师

2）  测试经理认为BUG无效，原因：不是BGU，对需求的理解误差，描述不清楚。BUG不全，重复

测试工程师NEW----测试经理CAN OPEN-----REJECTED-----测试工程师CLOSED

3）  开发工程师拒绝修改BUG，原因：修复提高项目风险，理解分歧，技术难度大，修复成本高，修改范围广，优先级低

测试工程师NEW----测试经理OPEN-----开发经理ASSIGNED-----开发工程师CANFIX------开发经理

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 → Faild  Faild → Abandon

BUG单

1．BUG单写作准则（5C）：

correct(准确)每个组成部分的描述准确，不会引起误解

clear(清晰)每个组成部分的描述清晰，易于理解

concise(简洁)只包含必不可少的信息，不包括任何多余的内容

complete(完整) 包含复现改缺陷的完整步骤和其他本质信息

consistent(一致)按照一致的格式书写全部缺陷报告

2．BUG单模板

注意：

1一定可以重现的BUG可以不写“重复几次操作，出现几次，我认为，标题里不能写步骤，不能用主观的话描述，我在 。。。。的，不确定语句：某些好像，禁止使用”之后”，然后之类的语句”之类的话

2需求规格说明书以外的错误可以当建议报告，不当BUG报告，开发可以改，也可以不改

3若是随机出现的BUG，要写出操作几次，出现几次

4若被测软件是跨平台软件，要写上在其他平台下无误

5禁止写冗余的操作的步骤。常识性的步骤不用写进缺陷操作步骤

6写明环境数据，如何选择数据，数据如何被破坏

7一定要交代清楚测试书记，明确处理对那些数据进行操作

转载于:https://www.cnblogs.com/SETtest/p/10820413.html