这应该是测试工程师最最基础的能力了。表达不清楚的Bug会让开发一脸懵逼、浪费团队时间；表达清楚的Bug能帮助开发快速定位问题。虽然是基础能力，但事实上有些测试同学、其是入行没多久的新人，并不知道如何清楚表达一个bug。那么，一个让开发看得懂的Bug到底是什么样的呢？首先我们要清楚什么是Bug？一般情况下，我们只要能判断软件当前的实现效果和需求设计的预期效果不相符，就可以判定为这个是软件的Bug。接着我们要理解提交Bug的主要目的，提交Bug是为了告诉开发哪里有问题、并尽可能地告诉开发产生问题的原因是什么。因此，我们提交的Bug能达到这个目的即可，为了达到这个目的，大部分情况下我们提交的Bug要包括以下几点：

1. Bug标题。Bug标题是软件缺陷的精简描述，通常可以采用“在什么情况下进行什么操作发生了什么问题”的模式来描述。注意，标题尽量直指问题本质，不要过长。详细的描述可以放在报告正文里。

2. 功能模块。告诉开发问题是发生在哪个功能模块，比如pc端登录，还是app支付等。

3. 优先级。基于对业务的重要性程度评判优先级，比如订单支付失败的Bug当然是优先级高的Bug，而一些UI小Bug可以视为优先级低的Bug。通过评估bug的优先级，团队可以决定是否要花时间精力去修复这个bug，如果要修复，什么时候修复等。

4. 对应的负责人（前端Bug or 后端Bug or 产品Bug等）。提交Bug后需要指定对应功能模块的负责人，这样Bug才会有人修。

5. 前置条件。例如，为了复现Bug，可能需要某个具有对应权限的账号、或者已经具备相关测试数据，因此可以在前置条件里把复现Bug需要的条件讲清楚。

6. 操作步骤。这也是非常重要的，操作步骤可以告诉开发如何稳定地复现Bug，对开发定位问题原因非常重要。很多时候，我们要在操作步骤中附上复现该Bug的测试数据（出现问题的页面地址、登录账号等）。

7. 实际结果。实际结果是软件当前实现的效果，通过实际结果告诉开发，当前的Bug具体效果、表现是什么。实际结果最好有图片就附上图片、有视频就附上视频、后端Bug往往也要附上接口（包括接口的请求体、返回体等）

8. 预期结果。预期效果是产品设计想要的效果，通过预期结果告诉开发，软件想要做成什么、需要做成什么样。必要的情况下，可以附上产品的需求图。

9. 原因分析。基于对业务、对程序的理解，测试同学要尽可能定位产生Bug可能的原因。比如接口请求错误、接口响应错误、计算错误、需求理解错误等。当然，有些Bug测试同学是无法定位出原因的，这种情况可以和开发同学一起定位原因。

10. 所属环境和配置。大部分情况下，测试是在测试环境中进行软件测试的，因此所属环境可以不写，但对于特殊的Bug，比如线上Bug、部分机型的Bug等，是需要写清楚环境的。

11. 备注。大部分情况下，提交Bug也不需要写备注，备注的目的也是为了说明清楚、补充说明Bug，只要有助于这个目的，而又无法归类到以上几点，就可以在备注中说明。