很多朋友在软件测试这条路上，都具有很强的业务逻辑分析能力，甚至具有多门语言的编码能力，认为

bug找到了，开发也确诊了，记录bug就不那么重要了，可事实是真的如此么？你是否：

在测试新版本时，接二连三的被开发拉去重现bug？

在测试思路清晰的时候，开发跑过来跟你再三确诊bug现象？

在同事帮你回归bug的时候，直接口头跟你总结bug的步骤？

在新人刚来公司不久，回归你提的问题单是，只回归了一种场景？

……

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

一、测试环境

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

见，这是其一；其二：只要开发跟你确诊过测试环境正常，就可以自己去环境上取相关定位信息，省去

了不少因为环境而引发的问题；其三：回归时也都尽量保证验证了原测试环境的情况下多回归几个其它

的环境，哪怕是在测试环境只有一个的情况下，也为了规范bug记录而写上。

二、预置条件

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

预置条件也会算成其中一项。比如，当用户登录时存在异常，那么在预置条件中，一定要写清楚存在的

用户名与密码，这样会减轻编写操作步骤的压力，从而让步骤看起来更简单易懂。

三、操作步骤

操作步骤一定要详细与全面，但又不能啰嗦，你懂的步骤别人不一定懂，但是过于啰嗦又让别人看不下

去，举例：记事本的打开

正确的步骤：点击“开始”->“程序” ->“附件” ->“记事本”打开记事本软件；

错误的步骤：打开”记事本“

错误的步骤：点击”开始“，再点击程序，再选择附件，选择记事本，双击打开

在操作步骤中，值的注意的是，当一个现象产生的原因有多个场景时，应该在步骤中用case进行区分与

编写，要注意的是这里不是指的一个bug中记录两个问题

四、预期结果

预期结果是每个提bug的人都会写的，但是这一块写的时候不能让人产生歧义与误解。比如，当用户名输

入特殊字符时，应该给出提示，具体给出什么样的提示在预期结果中应该更具体体现，让任何一个小白

遇到这个现象都能理解正常情况是什么样子。

同样，当操作步骤存在多种case的时候，相应的在预期结果中也应该相对应的给出不同的case

五、实际结果

实际结果只需简单阐述存在的问题就好。

当操作步骤存在多种case时，一定要在此处写上每种case所对应的实际结果

六、错误截图

借助截图加备注来说明实际结果

七、日志定位

对于问题出现，测试人员一定要尽所有能力收集所有相关的日志，并且根据相关的步骤，指出问题产生

的时间点、日志间数据的联系、开发人员拿到日志就可以直接定位。

八、附件上传

将所有日志与附件打包上传

bug的记录，虽然存在多种不同的场景，有先发现问题跟开发确认了再记录的，有先让开发定位再记录跟

踪的，也有现场返回在家里做记录的，不管哪种场景也不管现象的复杂与否，bug的记录都应该保持好的

风格与习惯，只有这样，才能让自己有更多的时间去测试更多的bug