怎样报告一个合格的bug

开发中会碰到各种奇怪的bug,怎样有效高质量的报告一个bug,给开发提供更多的信息,便于排查和解决问题?可以有下面几个角度

  • 手机平台和型号

    是Android还是iOS,毕竟现在是都是多端开发,由于两端不一致性,导致可能问题表现不同,所以先确定平台,方便找到对应的开发。手机的型号也很关键,像Android手机,不同厂家对ROM定制不同,而且不同版本系统本身就有差异,导致bug只在某厂商机型或者某个系统版本才能复现

  • app版本

    app在迭代中,往往某个bug,只在某个版本才能复现,所以提供版本信息,方便看这个版本代码的改动点

  • 问题发生的时间

    发生时间是非常重要的信息,越精确越好,客户端根据时间,在日志中找到发生前后的上下文,服务端也可以根据它来找到当时用户请求的数据,时间还可以判断是否因为服务端发布造成的

  • 用户id

    用户id是用户的唯一标识,很多功能都是和用户绑定的,比如圈人群、实验分桶,借助这把钥匙,可以拿到更多的信息

  • 业务域唯一性的id

    除了用户id外,在某个业务域中总会有一个标识唯一性的id,比如请求id,订单id,商品id,帖子id,评论id,跳转链接,消息id等等,这些id都是和具体业务相关的,有了它,可以在对应业务域进一步缩小排查范围

  • 发生概率

    必现还是偶现,如果是必现的问题,都比较好解决。如果是偶现,偶现的概率多少,可以评估严重程度。基于发生概率,不断尝试复现

  • 客户端日志

    Android手机可以提供抓取日志的能力,看下应用打印日志中,有无报错和异常信息,或者根据页面和点击等事件,来确认用户是怎样操作复现的

  • 复现路径

    怎样复现的?在发生前做了哪些操作,有什么异常的现象,描述清楚。在解决问题后,也好能验证确实解决了。

  • 用户类型

    内测用户、白名单用户、还是线上用户,通常一些开发阶段的功能都会给用户加了白名单,但是这些新功能不太完善,导致用户反馈。

  • 服务端最近有无发布

    看问题发生时间,是否和服务端的某次发布有关。服务端是否在做压测,攻防演练等等

  • 客户端最近有无灰度开关打开

    问题发生时,端上是否有推灰度开关,导致之前关闭的功能被打开,引发连串问题

  • 运营最近有无活动上线

    每天都会有运营活动,有的活动是借助于push消息,会带来瞬时流量,导致问题爆发

  • 网络环境

    是3G还是WiFi,来依此判断是否弱网环境,可能因为网络性能差,导致页面白屏,请求超时等情况,造成用户舆情反馈

  • 提供截图或者视频

    如果有图片和视频,最好能提供下,更容易的理解问题,减少沟通成本