BUG
定义
软件的bug,软件程序的漏洞或缺陷 – 常见,首先发现
软件可改进的细节,或与需求文档存在差异的功能实现等
测试工程师:发现bug,定位bug,提交bug,回归bug
类型
确定bug类型,对开发解决bug意义不大,确定bug类型是为了方便后期测试报告,bug分析进行的
常见类型:
- 代码错误 – 占比最大
- 界面优化 – UI
- 设计缺陷 – 需求不合理,改进,建议性bug
优先级
bug数量和bug等级来考察绩效
但是,很多情况下,提交bug大致等级差不多即可,会影响研发绩效
判断bug等级,常见判断条件
- 致命错误 — P1
常规操作
引起的系统崩溃,死机,死循环,闪退 – 阻塞,冒烟测试都不通过- 造成数据泄露安全性问题,比如恶意攻击造成的账户私密信息泄露 – 安全漏洞
- 涉及巨额的
金钱计算
和金钱损失
– 巨额损失,银行,信贷,P2P,电商 – 看用户基数 - 阻断性测试,所有测试工作进行不下去
- 权限问题 – 用户越权,vip内容泄露
- 严重错误 — P2
- 重要功能是否实现
- 次要功能错误的波及面广,影响到其他重要功能正常实现
非常规操作
导致的程序崩溃,死机,死循环,闪退 — 网络异常情况导致,连续点击4-5次才能出现的问题- 外观界面难以接受的缺陷 — UI
- 密码明文显示 — 抓包工具来看
- 偶现的致命性bug
- 一般错误 — P3
不影响产品的运行,不会成为故障起因,但对产品外观和下道工序影响较大的缺陷- 次要功能是否正常实现
- 操作界面错误,包括数据窗口内列名定义,含义不一致
- 查询错误,数据错误显示
- 简单的输入限制未放在前端进行控制
- 删除操作未给出提示
- 偶现的严重性bug
- 细微错误 — P4
程序在一些显示上不美观,不符合用户习惯,或者用一些文字的错误- 界面不规范
- 辅助说明描述不清楚
- 提示窗口文字未采用行业术语
- 界面存在文字错误
- 改进建议 — P5
- 提高产品质量的建议,包括新需求和对需求的改进 — 同类产品,竞品产品
- 提高产品质量的建议,包括新需求和对需求的改进 — 同类产品,竞品产品
bug生命周期(重点)
bug的生命周期,就是一个bug被发现到bug被关闭的过程
一般缺陷状态:发现
=> 新建(提BUG)
=> 指派
=> 已解决
=> 待验
=> 关闭
bug跟踪流程
- 发现bug,不要着急提交,记录(截图),防止偶发性bug,
- 确认BUG(排除外界因素),确定步骤是否必现?
- 提交BUG,必现/偶现 – 提交到哪里?提交给谁?怎么提交?
- 指派BUG,根据开发计划(人员分配)-- 提交开发本人,提交开发负责人 – 分配
注意:一定要跟进BUG,P1级别BUG半天就得催 - 研发确认BUG ,从测试提交的bug的描述中判断,是不是BUG?
- 重复BUG,其他人提交过BUG,重复开
注意:一定要求开发提供重复BUGID,是,关闭,说明原因;不是,重新激活,指派开发 - .不是BUG,无效BUG,先确认是否为外部因素导致(误操作,网络,环境),然后找产品,确定产品需求
- 无法重现:
- 偶现BUG,要记录,
在标题上标记偶现
,后续版本持续的复现,尝试找到稳定的复现的步骤,提供截图,日志linux - 测试提出一个BUG,开发在开发环境无法复现,让开发来测试环境来看是否复现,修改测试环境BUG,开发修改的代码同步到开发环境
- 测试环境无法复现,持续跟踪大概5个版本,一直持续关注,临近发布版本,依旧无法复现,关闭,备注,遗留BUG
- 偶现BUG,要记录,
- 不予解决,测试开发需求理解不一致,找产品确认
- 延期BUG:本次发布项目不修复,留到下一个版本解决
- 建议性BUG,新功能,动作大
- 修复风险大,可能会引入新的bug,会导致项目延期发布
- 衡量bug对用户的影响,不修复,对用户影响不大,下次发布之前修改;不修复,对用户影响面很广,重激活,说明,产品
- 回归验证BUG,bug步骤重新测试一遍,这个bug所涉及的功能点,均要测试 – 开发改动的代码所涉及的点均要回归验证