聊聊「线上问题跟进」

注：这个系列，把整个「软件测试职业」的「做事」姿势，普及一遍；虽然阅读量不是很大，但老徐个人觉得能对大家有点价值；

-- IDO老徐

线上问题跟进，看起来很简单，人人都会，其实非常难 。可能很多同学会疑惑，不就是问题跟进么，谁不会 ？

其实，略难 。

多数情况下，用户反馈的问题的，只是一个现象，怎么操作出来的，或者什么场景下，什么数据环境下出现的，用户也说不清楚 。

而且，很多时候，是谎报（并不是问题 ）；

对于跟进线上问题，不同公司、不同业务结构的团队，流程会稍微有差异 。

很多测试从业者，可能不会去跟用户接触，完全不知道用户是怎么使用系统的、什么场景下使用系统的 ，自己也没有真实的根据场景，去测试 。

导致，测试环境下，啥问题没有；一经上线，一堆问题，甚至出现，完全不可用的情况 。

回到正题，

跟进线上问题 ，之前老徐画过流程图 ，一般来说，用户反馈，由「线上客服接收」，然后做一轮基础判断，再把觉得是Bug的，反馈给「质量部 / 或 技术团队 」。

测试同学，收到问题后，根据问题描述，去梳理、分类：

1）Bug

2）操作

3）需求

4）外部原因

等 。

对于是Bug的，如何复现 ？如何跟进 ？开发解决后，如何验证 ？

通常，公司内部，会有「Bug管理系统」，收集到的「用户反馈类Bug，会单独抽离出来，方便后续的统计分析、回顾，以及方便验证 」。

总之，

用户反馈 -》线上客服接收问题 -》做一轮初筛 -》反馈给 测试同学 -》测试同学复现，提交Bug -》反馈给开发同学，开发修复 -》测试同学验证 -》上线 -》客服通知用户 。

大概是这么个流程，不同公司，如上流程会有差异 ；而且会衍生很多分支链路 。

比如，如果是需求类的，反馈到产品部 ；如果是不会操作的，反馈给售后/客服 ；如果是无效反馈，退回给 客服部 等等 。

End ，

最后，补充：

1、Bug提的再多，抵不上一个漏测 ；

2、多分析线上每一个问题反馈；每个线上问题，都值得去思考、总结，为什么会漏 ？

3、遇到问题，遇到新知识，做好笔记；一次不会，没事；别人给你讲了多次，还不会，就略2了 ；

好了，今天先写到这 。

你有啥补充的 ？以及建设性建议 ？

底部留言，分享给同样看到此文的同行吧 。

End

补充 ，

1、业务测试工程师的终极目标：

提升测试效率的前提下，尽量少的漏测，避免Bug流入「生产环境」；至于是「自动化手段去测」还是「完全手工去测」，还是其他方式；

对应「业务测试工程师」来说，不重要，那些都是解决问题的手段 。

2、很多公司，各种流程都是不完整的，比较乱；各种乱 ；

要学会在已有的资源下，高效解决问题 ，提升自己的能力 ；

每个公司，都或多或少，有各种乱七八糟的问题 ；

接受 / 改变 / 离开 ；

/

加油 。

有想讨论的，底部留言，交流 。