软件测试：测试工程师 怎么评估BUG修复的影响范围

背景：年终总结里，很多同学说目前bug的影响范围评估很多都依赖于开发的代码评估，比较被动。所以也想总结下测试过程中评估bug 影响范围的方法
​

定义BUG

​

要想评估bug范围，首先就要把bug定义清楚

• bug的业务影响，可以问下这几个问题

  • 哪些模块收到影响
  • 什么业务链路被阻断了
  • 客户在什么场景下使用会有问题

• bug的自身属性

  • 这个问题是从什么时候出现的（当前迭代的bug，还是历史bug）
  • 优先级

• 初步定位

  • 前后端问题定位
  • 后端链路环节定位（业务层、底层服务）

改动方案

和开发聊一聊问题原因、改动方案，和最后实际的改动方案

• 本来打算怎么改，这块代码是否涉及到通用逻辑、底层服务
• 最终实际的改法有没有变化

改动评估

• 提交commit的走读和开发自己评估的备注

• 横向评估：类似业务有没有问题，比如实体操作的各种类型是否都有问题

• 上下游链路：这里可以区分下业务链路和工程链路

  • 业务链路，这一步打通后，用户下一阶段会做什么操作
  • 工程链路，这部分代码结束后，实际还会有哪些代码逻辑/切面处理，例如日志、计量、算法、统计

业务链路来说，比如我们修改的新增入口的字段/交互/逻辑，那么编辑/查询入口肯定也要保持一致；详情页有什么操作入口变化，列表页也应该保持一致

• 历史问题的评估，之前踩过的坑回顾下，这个可能就需要有时间的沉淀了

提效点

1. bug定位分析的熟练度
2. bug工单的规范程度
3. 所属业务代码链路的熟练程度
4. 上下游链路的理解程度，这个平时可以通过一些技术手段来熟悉，比如sls链路日志

​

（这些提效点都不够智能，要思考怎么依赖于机器算力来提效）
​

可以看出来一整套bug改动范围的评估还是很复杂耗时的，实际迭代中肯定做不到每个bug都来做这个事情，那什么时候我们要这么来分析呢？
重点的bug我觉得需要按照这一套流程来分析，啥样的属于重点bug呢？

• 重点模块的高优先级bug，怎么定义重点模块呢？
  • 可以是当前迭代中业务链路的核心
  • 可以是迭代中已知bug量最大的模块，或者新人开发的模块
• 敏感阶段发现的bug
  • 封板时/临近封板时发现的bug
• 测试阶段发现的需求补充/遗漏的bug
  • 这类bug由于开发修复时间有限，思考的也比较匆忙，也要格外关注

其他的bug，我觉得把BUG定义清楚即可，改动范围参考开发的备注
​

其他的思考

• 业内的精准测试概念能不能解我们的问题？？
  • https://www.jianshu.com/p/db152eb539af
  • https://tech.youzan.com/thanos/
• 前端的部分bug我们怎么评估？？
  • 引导前端开发做组件化改造，组件修改的范围评估
  • 各种常见控件的操作预期
  • ……