开发还来找麻烦？测试人必备全面的记录缺陷，看还有话说不......

前言

如果说你提了一个Bug之后，一个开发不断的来跟你沟通，你的操作是什么样子的，你有什么前提条件，你要准备什么样的数据、环境。有这些问题就表示你的Bug提交得不到位。

这个肯定会影响开发修改的效率，在这中间他怀疑你提交的Bug不好，你怀疑他的理解能力不够，一来一回就很容易起冲突。

所以对于我们软件测试工程师第二职责就是如何去提交一个高质量的Bug，当然第一个职责是找Bug。

很多朋友在软件测试这条路上，都具有很强的业务逻辑分析能力，甚至具有多门语言的编码能力，认为bug找到了，开发也确诊了，记录bug就不那么重要了，可事实是真的如此么？

你是否：
在测试新版本时，接二连三的被开发拉去重现bug？
在测试思路清晰的时候，开发跑过来跟你再三确诊bug现象？
在同事帮你回归bug的时候，直接口头跟你总结bug的步骤？
在新人刚来公司不久，回归你提的问题单是，只回归了一种场景？
……

这些都是可以通过更好的记录bug问题单而解决的。那么bug记录单应该都包含哪些内容呢？

一、测试环境

几乎在所有公司，测试环境都不只一套，只在一个环境上存在问题其它测试环境没有问题的情况并不少见，这是其一；

其二：只要开发跟你确诊过测试环境正常，就可以自己去环境上取相关定位信息，省去了不少因为环境而引发的问题；

其三：回归时也都尽量保证验证了原测试环境的情况下多回归几个其它的环境，哪怕是在测试环境只有一个的情况下，也为了规范bug记录而写上。

二、预置条件

并不是所有bug所存在预置条件，一般是在特定的bug步骤或现象下才会有，但是一般编写bug问题单时，预置条件也会算成其中一项。

比如，当用户登录时存在异常，那么在预置条件中，一定要写清楚存在的用户名与密码，这样会减轻编写操作步骤的压力，从而让步骤看起来更简单易懂。

三、操作步骤

操作步