背景:年终总结里,很多同学说目前bug的影响范围评估很多都依赖于开发的代码评估,比较被动。所以也想总结下测试过程中评估bug 影响范围的方法
定义BUG
要想评估bug范围,首先就要把bug定义清楚
-
bug的业务影响,可以问下这几个问题
- 哪些模块收到影响
- 什么业务链路被阻断了
- 客户在什么场景下使用会有问题
-
bug的自身属性
- 这个问题是从什么时候出现的(当前迭代的bug,还是历史bug)
- 优先级
-
初步定位
- 前后端问题定位
- 后端链路环节定位(业务层、底层服务)
改动方案
和开发聊一聊问题原因、改动方案,和最后实际的改动方案
- 本来打算怎么改,这块代码是否涉及到通用逻辑、底层服务
- 最终实际的改法有没有变化
改动评估
-
提交commit的走读和开发自己评估的备注
-
横向评估:类似业务有没有问题,比如实体操作的各种类型是否都有问题
-
上下游链路:这里可以区分下业务链路和工程链路
- 业务链路,这一步打通后,用户下一阶段会做什么操作
- 工程链路,这部分代码结束后,实际还会有哪些代码逻辑/切面处理,例如日志、计量、算法、统计
业务链路来说,比如我们修改的新增入口的字段/交互/逻辑,那么编辑/查询入口肯定也要保持一致;详情页有什么操作入口变化,列表页也应该保持一致
- 历史问题的评估,之前踩过的坑回顾下,这个可能就需要有时间的沉淀了
提效点
- bug定位分析的熟练度
- bug工单的规范程度
- 所属业务代码链路的熟练程度
- 上下游链路的理解程度,这个平时可以通过一些技术手段来熟悉,比如sls链路日志
(这些提效点都不够智能,要思考怎么依赖于机器算力来提效)
可以看出来一整套bug改动范围的评估还是很复杂耗时的,实际迭代中肯定做不到每个bug都来做这个事情,那什么时候我们要这么来分析呢?
重点的bug我觉得需要按照这一套流程来分析,啥样的属于重点bug呢?
- 重点模块的高优先级bug,怎么定义重点模块呢?
- 可以是当前迭代中业务链路的核心
- 可以是迭代中已知bug量最大的模块,或者新人开发的模块
- 敏感阶段发现的bug
- 封板时/临近封板时发现的bug
- 测试阶段发现的需求补充/遗漏的bug
- 这类bug由于开发修复时间有限,思考的也比较匆忙,也要格外关注
其他的bug,我觉得把BUG定义清楚即可,改动范围参考开发的备注
其他的思考
- 业内的精准测试概念能不能解我们的问题??
- 前端的部分bug我们怎么评估??
- 引导前端开发做组件化改造,组件修改的范围评估
- 各种常见控件的操作预期
- ……