缺陷定义
1.错误
静态存在于文档说明中的表述或者编写错误
- 用户名及密码
- 用户ID及密码
2、BUG
存在与代码或者硬件系统中的错误
- int a[5];
- int i
- for(i=0;i<=5;i++)
3、缺陷
被测对象实际表现与用户显性或者隐性需求间的差异
- 功能实现错误
- 功能实现遗漏
- 功能实现多余
- 功能实现不好
4、失效
因缺陷激发后导致功能的异常，无法使用的现象
- 不一定会产生，动态的
缺陷产生的原因
扫描二维码关注公众号，回复：
3454070 查看本文章
- 需求表述理解，编写过程中引起的错误
- 系统设计架构引起的错误
- 开发过程缺乏有效沟通及监督
- 程序员编码过程产生的错误
- 软件开发工具本身的错误
- 软件需求，复杂度越来越高
- 与用户需求不符合，即使本身不存在某种意义上的缺陷
缺陷格式
缺陷ID
- 用来唯一标识的字段，一般使用阿拉伯数字即可
- 缺陷ID不可以重复，并且不可以服用
概要描述
- 比如：商品查询功能：输入关键字查询后结果显示为乱码
- 概括描述缺陷的表象或者存在的形式，便于研发同事快速推测缺陷的产生原因
发现人
- 缺陷的发现者，一般为测试工程师，也可能时项目组相关成员，如开发工程师，项目经理，维护员，甚至客户
发现时间
- 缺陷发现时间
修复时间
- 缺陷何时被fix
所属版本
- 发现缺陷的版本，便于后期统计不同版本的缺陷数量，以及确定测试版本的发布风险
所属模块
- 缺陷所在的功能或者业务模块，便于后期统计每个功能或者业务模块的缺陷分布情况，从而利于回归投入确定或者研发资源分配
缺陷状态
- new 缺陷尚未进入缺陷管理流程时，定义为new，如测试工程师新发现或者新提交的BUG
- open 经过确认后确定时BUG，缺陷正式进入管理流程，一般定义状态为OPEN状态
- fix 研发同事确认为BUG，并且做了修复活动，可将对应的BUG状态设置为fix
- close 缺陷经过校验，确认已修复或者无需处理时，可将BUG设置为close
- reject (程序员)研发同事需对open的缺陷进行判断，如果确认是缺陷，则需要进行修复活动，如果因需求变化，设计变化的原因导致缺陷已不存在，则可reject该缺陷
- reopen 当已经fix或者close的缺陷再次产生或者未能修复时，测试人员可将对应的BUG设置为reopen
缺陷的严重度
- low 缺陷导致的后果不是很严重，一般而言，仅是使用户感觉使用不方便，界面不美观等感觉
- medium 一般的错别字，字体错误，显示错误，子功能实现错误或者冗余
- high 某个具体功能不能正常使用比如查询功能错误，排序功能错误等
- very high 比 high级别更高，导致大面积功能无法正常使用
- urgent 大面积功能不能使用，终止性错误，初始化错误
修复优先级
- 由研发团队确定，决定缺陷修复的先后时间
详细描述
- 对概要描述的补充，当概要描述不能细致描述缺陷现象时可在此字段中详细描述，比如说明缺陷产生的步骤，测试数据，系统的截图等等
下一步处理人
- 缺陷接下来由谁来处理
缺陷管理
角色定义
流程定义
定义流程中所有角色所遵循的规则
- 1.测试工程师发现并提交缺陷,状态：new
- 2.测试经理进行缺陷的过滤 状态：
- 3.测试经理将缺陷指派给开发经理
- 4.开发经理根据缺陷修改任务分配给相应的开发工程师
- 5.开发工程师确认缺陷，如果时缺陷，则进行fix操作，如果不是，则reject，并说明理由
- 6.r如果缺陷状态fix,则测试工程师在下一个版本进行确认活动，如果成功fix,则可将缺陷状态置为close,如果未能fix,则置为reopen
- 7.如果开发人员认为不是缺陷，则测试工程师需要说明认为时缺陷的充分原因，如果无法达成一致意见，则有项目经理协调处理
工具应用
采用何种缺陷管理工具
- 开源:Bugzila jira matins bugfree excel
- 商业 QC/ALM 禅道
模型选择
- ODC
- 四象限
- Gompertz
未完待续