怎样报告一个合格的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，来依此判断是否弱网环境，可能因为网络性能差，导致页面白屏，请求超时等情况，造成用户舆情反馈

• 提供截图或者视频

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