阅读 50

JB的测试之旅-复盘技巧

相信无论在哪行哪业,总会有“线上问题”,比如购买电子产品,使用有问题进行维权等等,每行每业都有内部的处理手段及问题复盘手段,那在互联网,或者说在移动端,该如何复盘呢?

关于复盘,JB看法是,无论大事小事,只要是有意义,复盘这个事情都值得去做~
最粗暴的方式,举例子:
某app,在A日晚上,某同学在后台配置参数,结果在E日,出现大量用户反馈称该app出现某严重功能问题,最终定位是因为A日配置参数错误导致问题发生,解决方案是重新配置正确的参数即可解决;

这个事情,从上面文字上看,有3个疑问:
1)为什么配置几天后才暴露问题?
2)为什么配置后不进行验证上是否正常?
3)为什么配置错误内容后就会出现问题?

收到的回复是:
1)因为这个参数是活动配置参数,定的就是在E天才开放给用户;
2)验证比较麻烦,而且配置同学不懂怎么验证;
3)配置的内容不符合代码规范,当时明确要求配置的同学要按照文档来配置的;

到了这步,也许有同学会说,哦,然后就没然后了~

但实际,这背后有潜在的问题:
1)查看埋点数据,发现A日配置参数了,从当天就已经有出现异常的埋点信息,只是数量比较少,而且没有用户反馈,当到E日开放,用户量暴增,才把问题暴露;
这是否就变成了,线上监控预警不到位,出现问题没有及时通知对应负责人?还是通知了,负责人因预警邮件太多没有看到?麻痹性疏忽?
方案:如果是没有通知,配置通知;如果是因为预警邮件过多而疏忽,重新梳理预警邮件,减少不必要的预警;如果没有埋点日志,新增并形成预警链路闭环。

2)是否有工具提供验证?工具是否灵活好用?
方案:提供校验工具,小白式教学使用,越简单越好;

3)这问题主要围绕2方面,文档的约束力是很低的,客户端代码健壮性及容错率、配置平台的异常提示,发现是明显错误,从源头上不允许发布;

上面这个例子是很普遍的例子,却隐藏了背后的问题,上面也提供一些解决方案~

但,这只是复盘内容的一环;

复盘应包含以下几部分:
1)问题回顾, 收到首条问题反馈时间+量级、问题引入具体时间、本地解决时间、线上用户解决时间;
2)问题影响范围;
3)问题出现原因&解决方案;
4)后续改进计划,正如例子所述,了解问题原因及背景,哪个环节出问题,是否有深挖可能等;
复制代码

小结:

问题的解决方案有很多种,但哪个才是问题的本质~

感兴趣的同学可以看看下面的截图~

关注下面的标签,发现更多相似文章
评论