作为一名优秀的软件测试工程师，除了能够设计出一组漂亮的测试用例外，提交一个有效的BUG也是必需的。这里说的“有效”，不是说提交的问题不是一个BUG。而是对开发伙伴来说，你提交的问题，开发看得懂，能够重现，不需要再来找你重现。
为什么说提交一个他人看得懂的BUG是有必要的呢？
我们假设有这样一个场景：
你正在测试一个项目，测试过程中，开发A过来问你BUG1怎么出来的，ta没有重现，这时你过去帮ta重现了。又过了一会，开发A又过来问你BUG2、BUG3、BUGx是怎么出来了。
遇到这种情况，如果是项目不忙的时候，内心可能没啥感觉。但当你正在测试一个比较紧急的项目时候，你会不会有小情绪，更严重的当场发飙说“bug不是描述了吗”之类的话？
那我们要怎样减少这种情况的发生呢？
我们可以从以下几个方面来注意，从而提交一个人人都可以看得懂的BUG，围观如下??
1、BUG要素
首页要明确提交一个bug时，要包含哪些内容：
- BUG标题；
- 描述（bug重现步骤）；
- 出现的环境；
- 当前测试的版本；
- 前置条件；
- 测试数据；
- 期望结果；
- 实际结果；
- 附件（出现问题的场景截图、视频录像等）；
2、说清楚
说清楚是指BUG的标题清晰，步骤明确，测试数据清晰，期望结果明了。
3、初步定位问题原因
当我们在测试一个app的功能时，发现页面上的某个值展示的不正确，我们是直接提一个bug给开发呢？还是会分析下不正确原因？当然直接提交一个bug给开发也不是不可以，但当我们把产生问题的可能原因也列在bug中，是不是更牛掰一点。那如果要初步定位问题出现的原因，要怎么做呢？
了解被测系统的实现逻辑（这点很重要！）
当出现页面展示不正确时，知道该功能是否和服务端有交互，如果没交互，应该是客户端自己数据传输时出错了；如果有交互，抓包查看服务端接口返回数据是什么，客户端是不是取错字段值了？
除了抓包查看服务端返回的数据外，还可以登录测试环境的服务器查看服务端的运行log。