问题1：在测试发现问题时，是先跟研发沟通还是先提Bug？
解决：
（1） 在测试项目的初期，对程序不熟悉的情况下，可以先沟通，再提Bug；
（2） 后续对项目熟悉了，理论上是先提Bug，必要时再沟通（偶现或可能是偶现的问题；录像回放的问题）
原因：
（1） 对于测试人员来说，是站在用户的角度去测试，认为不可接受的，那90%以上（排除操作上的错误）属于是问题，不管是哪边的问题，总是要解决的，所以没有必要所有问题都要先跟研发沟通；
（2） 偶现问题必须沟通，以免破坏环境，后续不好定位；
（3） 回放问题要及时通知研发及时定位，以免录像被覆盖或被格式化。
（4） 先去沟通对双方的工作打断和耗时，也是个考虑的因子。（共同的一个团队，共同目标是为了更快更好的产品，减少内耗）
问题2：测试出的问题，研发说是工具的问题，如何处理，是否要提单？
解决：
（1） 找产品线的发布程序来测试，并跟产品线测试人员沟通，若产品线也说是工具问题，那可做认可处理；
（2） 使用其他合理的第三方工具测试，比如VLC的问题，可以用Quicktime player再测试一下；
（3） 产品线测试人员不知道或没遇到过此种情况（有可能是项目的特殊/新功能），研发也认定是工具问题，需要有项目经理同时确认是工具问题，并在问题后面添加注释，写明是工具问题，方可做关闭处理；
（4） 工具固有问题也需提单；
原因：
（1） 对比测试，若产品线发布程序也有该问题，那说明是产品线研发定位过的，可做认可处理；
（2） 一个研发说是工具问题没有说服力，需要有项目经理同时认可；
（3） 提单留作记录，若后面测试人员再遇到类似问题，有单可循，不需要再花费时间去确认；
问题3：测试出的问题，研发A说是外部原因问题，如何处理？
解决：研发A首先定位，写明定位结果，然后将问题转出给对应部门的研发B（邮件或者禅道指派的方式）
（1） 若研发B有回复，说确实是他们的问题，短时间内，研发B修复，研发A重新打包，测试人员验证，验证通过，关闭；
（2） 若研发B有回复，说确实是他们的问题，长时间内都未修复，或不可修复，要么研发B邮件回复承认问题，说明一个修复时间或无法修复的原因；要么在禅道上添加备注，证实确实是自己的问题，禅道里需添加一个新的问题状态，以区分这类问题；
（3） 若研发B不承认是他们的问题，需要研发A继续跟踪问题，且问题不可关闭；
（4） 外部原因问题也需提单；
原因：
（1） 就算问题是外部原因，其表现也是在我们的产品上，所以，不管是哪方的原因，问题始终都是要修复的，所以外部原因的问题，理论上来讲，是需要跟踪到问题修复的；
（2） 提单留作记录，若后面测试人员再遇到类似问题，有单可循，不需要再花费时间去确认；
研发认为的重复bug
解决：
（1） 重复问题表现的现象不一样的也应提单，且不应定义为重复问题；
原因：
（1） 从研发角度考虑，定位出来的是一个原因导致的现象不一样的问题，所以可以定义为重复bug，但是，从测试人员的角度考虑，认为现象不一样的问题不应认定为重复bug；
（2） 在客户使用的过程中，只会看问题的现象，而不会专注于问题的根因，所以现象不一样，根因一样的问题也不应定义为重复bug。
————————————————
版权声明：本文为CSDN博主「jackson_liuhuili」的原创文章，遵循CC 4.0 BY-SA版权协议，转载请附上原文出处链接及本声明。
原文链接：https://blog.csdn.net/jackson_liuhuili/article/details/48809949