一、测试工作完成后，你没有发现一个bug，该怎么办?
这种情况碰到的比较少吧，有可能项目版本迭代比较多，Bug 隐藏得比较深，而我们用例都是一些常规用例。
这个时候，需要跟多去从其他的异常场景，站在用户的角度，去完善用例。检查我的测试环境是不是用错了(测试环境预生产环境验收环境是不是有问题) 再看需求分析有没有问题用例有没有覆盖到位，用例设计得好不好，多补充一些覆盖无效等价类的测试用例，然后用例在评审一下，组内让老员工或者同事帮忙审核一下，再不行就开会议评审一下需求和用例，看看用例有没有覆盖完全或者需求理解到位没，预期结果有没有遗漏
可以让其他测试人员帮忙检查下用例，看有没有覆盖不全的。
二、你一般发现bug 后会怎样处理(需要答到协助开发定位问题)
1、遇到bug 第一时间我会截图，并反复复测，确认是一个Bug
2、在缺陷管理工具上提交这个Bug，指派给对应的开发，并且会将Bug 标题，描述，级别，操作步骤，预期结果，实际结果附件(截图，日志)等一并提交上去。
3、其次我会尝试分析bug 产生的原因，定位bug 是哪里产生的，主要就是抓包查数据库看日志，找到原因发给开发，同时上传bug 跟进Bug 的解决,要是找不到，也会将截图日志文件及复现步骤发给开发，协助开发解决Bug。然后做回归测试，验收通过再关闭bug。
-
后期跟进Bug 修复情况
-
如果是一些比较致命的Bug，严重Bug 比较多的话,我一般会先给开发打个招呼，然后再提。
三、碰到一些偶发性bug，开发也不认为这是bug 该怎么办?
1、首先，我会反复复测，想办法重现(换测试环境，换数据，让其他测试帮忙测下)，一旦出现马上截图
2、实在重现不了，先提交，挂起，标准为偶现(以便后期关注跟进)。
3、跟开发沟通，并向开发说明情况，我当时是做了什么操作导致这个问题的出现。看开发根据自己的经验是否可以找到具体的原因。
4、先执行完其他用例，功能测完再说，后面有时间话再回过头重现，如果还是重现不了。
5、后期会跟进1-2 个版本，如果1-2 个版本都没出现，那就关闭这个Bug。
四、如何提交一个好的BUG
1、对BUG 有一个清晰明了的描述;
2、详细描述BUG 重现的步骤;
3、对于产生BUG 的环境进行描述;
4、提交BUG 相关的图片和日志;
5、定位好BUG 的等级;
6、将预期结果与实际结果进行对比。
五、抓包怎么判断是前台还是后台的问题?
-
一般界面提示性的Bug,都是前端的Bug
-
例外，可以利用f12 或者抓包工具抓包看下，看有没有发请求，如果没有发请求，那肯定是前端Bug
3、如果发请求了，首先看发的请求是否有问题，请求的接口url 是否有错误，参数是否有错误，如果url 或传参有问题那就是前端Bug;如果请求没有问题，看下后台返回的数据是否有问题，状态码5 开头的基本都是后台问题，状态码为200，响应数据与预期不一致，那也是后台Bug;返回的数据没有问题，请求参数，url 也没有问题，那可能是前端代码是否转换有问题，那就是前端Bug。