大家好，我是阿萨。测试人员经常和Bug打交道，如果提交一张清晰的问题单？
作为测试人员/开发人员，一旦在测试系统中发现了一个错误，下一个合乎逻辑的步骤是修复它(如果它真的很小😉)，或者选择的Bug跟踪系统中编写一个Bug，以允许自己或同事查看并修复问题。
编写良好的bug报告可以为所有相关人员省去很多麻烦。
Bug要包含哪些细节
如果你在一个系统中看到大多数的错误，它们通常是在匆忙中编写的，很少注意细节，在大多数情况下可能只有一行标题。
这可能会让下一个看到它的人感到沮丧，因为他们不知道一些重要的细节，然后不得不戴上福尔摩斯的帽子去寻找答案，这通常需要在开发/测试/PM之间来回徘徊，以找出问题所在。
当开发试图修复典型的面向消费者/企业的web/移动/后端系统应用程序中的错误时，他们会问的一些常见问题：
1. 这个错误什么时候发生?他们如何复制它?
2. 错误行为是什么，预期是什么?
3. 对用户有什么影响?修复有多重要?决定现在还是以后?
4. 这种情况只发生在特定的测试数据上吗?
5. 用什么版本来测试这个(最好是标记到git提交)
6.如果漏洞是在手机上，那么手机，视口大小，操作系统细节是什么?
7. 如果bug出现在浏览器上，那么浏览器的类型、分辨率和版本是什么?
8. 如果错误是在API中，那么哪个特定的API/业务流程会受到影响，请求参数和响应是什么?
9. 屏幕截图与标记的区域，这是错误的?
10. 视频显示了找到漏洞的步骤?
11. 应用程序/服务器日志吗?
12. 当错误发生时，是否存在任何特定的功能切换/配置?
根据上下文，还有更多
报Bug之前可以做些什么？
在可用时间/环境的限制下，尽可能多地提供bug的细节，并在提出bug之前做一些前期分析。
这样做可以让你成为bug修复的有力倡导者，并减少所有人的头痛。
一个细节非常少的bug很可能会被推到产品待办事项列表的最下方，并被忽略，因为项目经理和开发人员都无法理解问题是什么，也无法进一步分析。
我们现在可不想这样，对吧?🕵🏻♂️
细节决定成败
写好bug报告的一些技巧
既然我们已经确定了编写清晰的错误报告的必要性，下面是一些善意的建议，其中包括一些关于下次编写错误报告时可以更好地做什么的具建议。
初步调查下根因
当您在系统中看到一个明显的错误时，测试人员/开发人员的典型下意识反应是，
“提出这种想法的人是谁?，“这真的很傻，他们怎么能在单元/集成测试中漏掉这个?”
我知道，我们在职业生涯中都经历过这种情况。
但是，我劝你先花点时间深吸一口气，冷静下来。
您应该理解并意识到的是，最常见的错误是在堆栈的不同层和特定条件下出现的，这些条件可能包含多个因素
所有这些条件都不能在单元/集成级别上模拟。有时开发人员面临着巨大的压力，要在最后期限内发布功能，因此只测试最基本的功能。
人无完人，有些人比其他人更有人情味。——Ashleigh Brilliant
我们应该理解在这里起作用的人为因素，并尝试将个人与错误行为分开。
有了这一点同理心，下一步是按照上面提到的必要细节收集更多的证据，并将它们起草到错误报告中。记住:当你进一步研究时，可以编辑和修改更多的细节。
让我们举一个调查流程的例子:
如果错误出现在UI(应用程序/浏览器)上，问问自己，这纯粹是UI上的表示问题，还是底层API业务逻辑中的错误，我该如何检查以确定并找到问题的根本原因?
你应该打开chrome开发工具的网络选项卡，如果浏览器或合适的代理工具，如Charles/MITM，查看网络呼叫，看看你是否可以收集更多的信息:
1. API调用是否使用了正确的请求参数(URL，报头，查询，主体)?
2. 响应返回了吗?
3. 检查响应数据中状态码/响应体中的任何错误
4. 检查相关的数据库表，看看是否写入了不正确的数据(如果需要)
5. 检查后端系统的应用程序日志
6. 服务真的好了吗?正在进行部署?
7. 依赖服务失败了吗?
总之,
“提出这种想法的人是谁?，“这真的很傻，他们怎么能在单元/集成测试中漏掉这个?”
在错误报告中描述问题相关细节细节。📝
执行上述所有步骤将暴露您正在测试的系统的许多内部细节，并最终使您成为更好的测试人员和产品专家。
为复现Bug写清晰的步骤
作为测试人员，我们常常认为，如何到达这个特定的屏幕/页面/业务流程是非常明显的。但请记住，对你来说很明显的东西对其他人或新系统的人来说可能不是这样。
帮每个人一个忙，写清楚如何重现这个问题的步骤。你甚至可以在你的笔记应用程序中捕捉一些常见的流程作为模板，并在屏幕上看到重复的错误模式时复制粘贴它们。
除了复现步骤之外，您还可以添加一些细节来支持。
1. 添加屏幕截图(在特定的问题区域标记，不要偷懒，在右下角的问题对于阅读你的错误报告的人来说是不明显的)
2. 更好的是，添加一个视频来显示流程。相信我，这非常有帮助，你的开发者/ pm会非常感谢你的。
3. 为API调用提供CURL，以及您从API中看到的带有状态码信息的响应。
这甚至适用于为开源项目编写bug。创建一个小项目来演示问题，并将其作为参考，这比给出一个模糊的问题描述要好得多。
提供版本/构建细节/日志信息
好的，所以你已经做了尽职调查，解释了bug是什么，影响是什么，它的优先级是什么，现在有了清晰的步骤来重现。
我们现在应该没事了，对吧?😌好了，差不多了!
通常情况下，bug与浏览器、移动设备、它们的视图或部署的提交/分支等特定条件密切相关。
添加这些细节可以为系统状态提供非常可靠的提示，并为开发人员指明更好的方向，以便进一步研究。
例如，在移动环境中，该错误可能发生在特定的设备和操作系统组合上，并可以为移动开发人员提供关于该版本涉及哪些特定库/框架的提示。
对于后端开发人员，Git提交细节可能特别有用，因为他们可以立即知道在环境中部署了什么分支，并帮助他们隔离要修复的问题。此外，提供应用程序日志也很有帮助，因为大多数日志框架都会提到日志生成的特定应用程序区域，这可以为开发人员节省大量时间。
结论
编写清晰的bug描述可以让项目成员在分类和修复bug时更好地协作。
所以下次你看到Bug的时候，相信你会报一个更好的Bug。
