bug描述规范
目的：减少沟通成本，协助开发快速定位问题
欢迎补充～
1、bug标题
作用：让开发扫一眼就能识别所属模块 + 核心异常，快速判断问题范围
要求：
1、格式：【模块 / 页面】+ 操作行为 + 异常现象，只保留核心信息，不堆砌细节
2、突出关键按钮、弹窗、报错文案，用【】标注
3、禁止模糊描述（例：页面有 bug、功能异常）
2、重现几率
作用：
1、帮助开发定位问题原因，必现 bug 大概率是代码逻辑漏洞
2、判定问题的严重程度及修复优先级
要求：写明复现概率，尽量找出复现步骤。
分为必现、大概率偶现：50%～100%、小概率偶现：10%～50%、极小概率偶现：0%～10%
3、设备信息
作用：主要用于前端、客户端开发排查机型、系统兼容类问题
要求：写明设备机型 + 完整系统版本
4、运行环境
作用：区分不同环境，避免开发切错环境排查，节约沟通时间
要求：填写 QA 测试环境、预发布环境、线上环境
5、用户ID
作用：
1、后端：根据用户 ID 检索服务端运行日志，定位接口报错、数据异常；
2、前端：使用手机号复现用户侧问题，使用用户ID通过日志定位问题
要求：
1、问题涉及单侧时，只给单侧ID即可；涉及双侧，要给出双侧ID并标明，例如在A的推荐列表中，应该有用户B，但实际没有，写为A 用户（ID：123456）推荐列表缺失 B 用户（ID：654321）
2、写明问题的触发对象：标注「某类用户通用问题」/「仅个别用户复现」
3、写ID时，标明ID的运行环境，
4、兼顾前后端排查需求：不确定排查方向时，同时填写用户 ID + 登录手机号
5、前置条件、测试步骤、测试结果、预期结果
1、前置条件
记录复现 Bug 前需要满足的状态
2、测试步骤
目的：
给开发完整、可落地的操作流程，不用反复询问操作细节，直接复现问题
要求：
1、写明是哪个模块的问题，是否有前置条件
2、尽可能详细，使零基础同事、不熟悉业务的开发，跟随步骤可 100% 复现
3、测试结果
完整描述报错文案、弹窗、页面错乱、数据缺失、接口失败等全部现象
4、预期结果
对照产品需求文档，写明操作后应当展示、返回、加载的标准效果
6、截图/录屏
作用：可视化展示异常现象，直观降低文字描述的理解偏差，快速锁定问题位置
要求：
1、页面 UI、弹窗报错问题：截图，用箭头 / 方框标注异常区域；
2、流程中的bug：上传完整录屏；
3、接口异常：附上接口返回截图、复制文字版完整 Request/Response 报文；
7、问题严重程度
作用：评估 bug 紧急程度，帮助开发快速安排修复排期
要求：
1、P0 - 致命
标准：核心业务流程完全阻断、大面积用户无法使用，线上会造成资损、客诉爆发、系统崩溃
典型场景：登录 / 支付功能完全失效、线上全量闪退、资金计算错误、用户隐私泄露等
2、P1 - 严重
高频核心功能异常，大量用户受影响，业务流程受阻，但存在临时规避方案，产生大量客诉。
典型场景：商品无法加购、主流机型大范围兼容故障、页面长时间加载超时等
3、P2 - 一般
- 非核心业务模块异常，仅部分用户会遇到
- 对整体业务、核心流程无致命影响
4、P3 - 较小
边缘功能、低频操作出现问题，影响用户极少，不干扰任何核心业务流程
5、P4 - 轻微
纯视觉美化、体验优化类问题，不存在功能故障，用户完全可以正常使用