缺陷记录你需要了解的那些事

lsekfe

很多朋友在软件测试这条路上，都具有很强的业务逻辑分析能力，甚至具有多门语言的编码能力，认为
　　bug找到了，开发也确诊了，记录bug就不那么重要了，可事实是真的如此么？你是否：
　　在测试新版本时，接二连三的被开发拉去重现bug？
　　在测试思路清晰的时候，开发跑过来跟你再三确诊bug现象？
　　在同事帮你回归bug的时候，直接口头跟你总结bug的步骤？
　　在新人刚来公司不久，回归你提的问题单是，只回归了一种场景？
　　……
　　这些都是可以通过更好的记录bug问题单而解决的。那么bug记录单应该都包含哪些内容呢？
　　一、测试环境
　　几乎在所有公司，测试环境都不只一套，只在一个环境上存在问题其它测试环境没有问题的情况并不少见，这是其一；其二：只要开发跟你确诊过测试环境正常，就可以自己去环境上取相关定位信息，省去了不少因为环境而引发的问题；其三：回归时也都尽量保证验证了原测试环境的情况下多回归几个其它的环境，哪怕是在测试环境只有一个的情况下，也为了规范bug记录而写上。
　　二、预置条件
　　并不是所有bug所存在预置条件，一般是在特定的bug步骤或现象下才会有，但是一般编写bug问题单时，预置条件也会算成其中一项。比如，当用户登录时存在异常，那么在预置条件中，一定要写清楚存在的用户名与密码，这样会减轻编写操作步骤的压力，从而让步骤看起来更简单易懂。
　　三、操作步骤
　　操作步骤一定要详细与全面，但又不能啰嗦，你懂的步骤别人不一定懂，但是过于啰嗦又让别人看不下去，举例：记事本的打开：
　　正确的步骤：点击“开始”->“程序”->“附件”->“记事本”打开记事本软件。
　　错误的步骤：打开”记事本“。
　　错误的步骤：点击”开始“，再点击程序，再选择附件，选择记事本，双击打开。在操作步骤中，值的注意的是，当一个现象产生的原因有多个场景时，应该在步骤中用case进行区分与编写，要注意的是这里不是指的一个bug中记录两个问题。
　　四、预期结果
　　预期结果是每个提bug的人都会写的，但是这一块写的时候不能让人产生歧义与误解。比如，当用户名输入特殊字符时，应该给出提示，具体给出什么样的提示在预期结果中应该更具体体现，让任何一个小白遇到这个现象都能理解正常情况是什么样子。
　　同样，当操作步骤存在多种case的时候，相应的在预期结果中也应该相对应的给出不同的case。
　　五、实际结果
　　实际结果只需简单阐述存在的问题就好。当操作步骤存在多种case时，一定要在此处写上每种case所对应的实际结果。
　　六、错误截图
　　借助截图加备注来说明实际结果。
　　七、日志定位
　　对于问题出现，测试人员一定要尽所有能力收集所有相关的日志，并且根据相关的步骤，指出问题产生的时间点、日志间数据的联系、开发人员拿到日志就可以直接定位。
　　八、附件上传
　　将所有日志与附件打包上传bug的记录，虽然存在多种不同的场景，有先发现问题跟开发确认了再记录的，有先让开发定位再记录跟踪的，也有现场返回在家里做记录的，不管哪种场景也不管现象的复杂与否，bug的记录都应该保持好的风格与习惯，只有这样，才能让自己有更多的时间去测试更多的bug。