四步提Bug的方式

这是一篇关于四步：你提的Bug——让所有人高看，让自己人轻松的思维导图。建议平时就要整理好—份设备型号、版本表格并共享，提Bug 时就可以直接复制，提高效。

四步，你提的Bug—— 让所有人高看，让自己人轻松

• 一、提Bug的可复现步骤
  • 步骤之前交代背景，时间地点要明确
    • 😃例如： 时间 2021-07-29-11:42左右 地点 测试部（或某某项目，或某某车间） ...（其它背景信息）
    • 😃理由： 研发人员根据提供的时间即可定位日志，或根据提供的地点直接前往现场， 而无需再联系测试人员，询问什么时候出现的问题、以及在哪出现的问题， 减少了不必要的沟通，且有时测试人员联系不上，有时测试人员也不记得。
  • 步骤之中注明细节，动词名词要具体
    • 😱反例如： ...（其它前置步骤） 触发门口机防水分机告警 ...（其它后续步骤）其中： “触发...告警”不够具体，无法直接执行 “门口机防水分机”不够具体，无法直接找到😃宜改为： ...（其它前置步骤） 按下门口机（注1）外接防水分机按键 ...（其它后续步骤） 注1：门口机型号xxx，版本xxx，序列号xxx其中： “按下...按键”一眼即可识别，足够具体 “门口机（注1）”注明了型号、版本、序列号，足够具体
    • 😃理由： 研发人员根据提供的名词可直接找到相关事物，并根据提供的动词可以直接操作相关事物， 而无需再联系测试人员，询问这个步骤里的这个操作怎么做、这个步骤里这个事物在哪里， 减少了不必要的沟通，且有时相关测试人员联系不上，而询问其他测试人员也不一定清楚。
    • 😃建议： 平时就要整理好一份设备型号、版本表格并共享，提 Bug 时就可以直接复制，提高效率。
• 二、提Bug的可观察结果
  • 业务角度为主，从业务角度描述执行上述步骤后出现的结果
    • 😱反例如： 服务器没有发出消息（技术角度观察的结果）😃宜改为： LED、LCD、信息发布器（注1）没有联动显示“04房02床紧急呼叫”（业务角度观察的结果） 注1： LED 型号xxx，版本xxx，序列号xxx LCD 型号xxx，版本xxx，序列号xxx 信息发布器型号xxx，版本xxx，序列号xxx
  • 技术角度为辅，从技术角度附上相关的日志、数据、分析等
    • 😃例如： 附上导出的服务器数据和日志、导出的相关设备数据和日志等； 附上复现过程中抓取的相关信令消息、网络数据、分析结果等。
  • 量化角度为补，从量化角度补充，用具体数量代替模糊词语
    • 😱反例如： 大概率白屏、一直掉线、加载很慢😃宜改为： 白屏概率、掉线次数、加载耗时
• 三、提Bug的可检验期望
  • 从业务角度描述期望，并尽量使用量化形式
    • 😱反例如： 服务器应发出控制各个显示屏联动显示消息（技术角度描述的期望）😃宜改为： LED、LCD、信息发布器应联动显示“04房02床紧急呼叫”（业务角度描述的期望）
    • 😱反例如： 不能白屏、不要掉线、加载快点😃宜改为：（注意：以下应符合产品需求，而非主观理解） 执行某某操作白屏概率应低于 0.1%、掉线每天掉线次数应不大于 1 次、首页加载时间应低于 1 秒
  • 从客观角度描述期望，不掺杂个人主观理解
    • 😱反例如： 字典列表展示杂乱。（测试人员主观理解，客观上产品并无关于字典列表展示的需求）😃建议： 向产品经理确认相关需求，产品经理确认后会作为补充需求提出，而非作为 Bug 提出。
• 四、提Bug的可速读标题
  • 标题是概要，尽量省细节
  • 字数不宜多，三十字为宜
    • 😃例如： 把步骤和结果分别提炼成 15 个字的一段话，合计 30 个字，作为标题。
• 未命名文件1
  • 未命名文件1
    • 未命名文件1
      • 未命名文件1