本文探讨了如何提交高质量的bug报告，避免与开发人员之间的沟通问题，提高工作效率。从测试环境、预置条件、操作步骤、预期结果、实际结果、错误截图、日志定位和附件上传等方面详细说明了bug报告应包含的内容，强调了详尽记录的重要性，以促进团队协作和问题解决。
前言
如果说你提了一个Bug之后，一个开发不断的来跟你沟通，你的操作是什么样子的，你有什么前提条件，你要准备什么样的数据、环境。有这些问题就表示你的Bug提交得不到位。
这个肯定会影响开发修改的效率，在这中间他怀疑你提交的Bug不好，你怀疑他的理解能力不够，一来一回就很容易起冲突。
所以对于我们软件测试工程师第二职责就是如何去提交一个高质量的Bug，当然第一个职责是找Bug。
很多朋友在软件测试这条路上，都具有很强的业务逻辑分析能力，甚至具有多门语言的编码能力，认为bug找到了，开发也确诊了，记录bug就不那么重要了，可事实是真的如此么？
你是否：
在测试新版本时，接二连三的被开发拉去重现bug？
在测试思路清晰的时候，开发跑过来跟你再三确诊bug现象？
在同事帮你回归bug的时候，直接口头跟你总结bug的步骤？
在新人刚来公司不久，回归你提的问题单是，只回归了一种场景？
……
这些都是可以通过更好的记录bug问题单而解决的。那么bug记录单应该都包含哪些内容呢？
一、测试环境
几乎在所有公司，测试环境都不只一套，只在一个环境上存在问题其它测试环境没有问题的情况并不少见，这是其一；
其二：只要开发跟你确诊过测试环境正常，就可以自己去环境上取相关定位信息，省去了不少因为环境而引发的问题；
其三：回归时也都尽量保证验证了原测试环境的情况下多回归
最低0.47元/天 解锁文章
643
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
