xswl：一些关于提bug的梗图
会不会提bug是体现测试同学专业性的一个很重要的方面，关于这方面的讨论也是相对比较多的，最近发现了一些有意思的梗图，有些真的挺有意思的，跟大家分享一下。
关于是不是真的需要提个bug
开发和测试总有不同的理解。
问题根因分析
很多时候我们发现的问题其实只是误会，或者说是无效的，比如在不小心部署的中间版本上测试，某些全局配置项设置有误等，这时候需要测试同学进行根因分析，实锤是bug之后再提会更合适一些。那么问题就来了，如何进行有效的分析呢？下面是一些我们可以尝试的方向
- 日志
- 监控
- 代码分支
- 配置文件或配置中心
很多时候我们感到困难的是如何去获得上面的数据，比如如何获取用户机器上的日志？
标题党
好的标题可能意味着一切，标题可以尽量消除歧义，让人一目了然，当然长篇大论也是不可取的，总之写bug的标题经常会让经验不是非常丰富的同学感到挣扎。
重现步骤
我们需要确保我们的缺陷是可重现的，我们需要添加关于如何重现问题的确切步骤，单步应该代表一个单一的动作，避免在重现步骤中使用“and”和“or”，因为这些添加了不必要的模棱两可。在描述客户出现的问题时，可以理解的重现步骤就更加重要了。
包含截图screenshot
英文表示截屏的单词唤作screenshot，就像下面一样
一张好的截图胜过万语千言了，而且很多开发其实只看图，一般情况下，对于web应用而言，尽量用全屏截图，因为这样可以包含浏览器的url，对排查问题很有帮助；另外有条件的情况下可以把开发者工具（windows操作系统上可以按F12打开）中的console或者network标签页也截进去，出错的地方重点高亮一下。
录屏
录屏我觉得可以分两种
- 录成视频
- 录成可以自动执行回放的脚本
第二种比较困难，但在web上也有不少可以尝试的工具
实际结果和预期结果
- 预期 - 系统应该做什么
- 实际 - 实际发生了什么
- 描述应该简明扼要，避免歧义，比如不要用“是否”， “有没有”， “是不是”
日志和堆栈
有条件的话我们应该提供相关的日志和堆栈，特别是在移动端进行测试的情景下。
软件版本和分支信息
对于客户端来说软件版本，比如操作系统版本，客户端版本等信息非常重要，对于后台系统来说分支信息对于错误分析也是相当有帮助的，所以有条件的情况下最好都包括上。
数据库查询结果
在bug里贴上数据库查询语句和查询结果是非常高效且专业的。
确定严重性和优先级
可以像下面这张表一样，用4个象限去区分优先级
- 高严重性和高优先级
- 低严重性和高优先级
- 低严重性高优先级
- 低严重性低优先级
保持专业
最后但并非最不重要的一点是，在报告缺陷时，重要的是要坚持事实并使用专业和尊重的语言，避免添加个人意见，关于如何解决问题的建议，推卸责任和指责，吐槽的内容就留给之后的复盘会议好了。
