bug判定标准
经典面试题：如果开发认为你提交的bug不是一个Bug，怎么办？
（考察对bug是否有判断，以及在工作中的软实力：处理问题解决问题的思路）
-
在什么情况下开发会认为你提交的bug不是一个bug呢？
-
测试人员对bug描述不清楚，比如复现步骤描述不清楚，或者bug概述没描述好，开发没看懂，所以就认为提交的bug不是一个Bug——解决办法是：提高测试人员编写bug报告的能力，复现步骤要清晰，无歧义。提交的bug有截图，录屏，或者日志信息
-
提交的bug并不是每次都出现，是偶现的。——解决思路是先提交bug（标成偶现），重要的截图，日志信息要保留下来，后续再关注这个问题，如果再次触发这个bug, 再提交更多的日志信息，帮助开发定位解决。
-
有争议性的Bug，比如建议类的（美观性的问题，易用性问题，与竞品比较觉得不太好的地方）——解决思路：可以先把自己建议类的bug提上去，然后跟产品，开发讨论，说出自己的理由，把自己的理由，建议说清楚。至于是否要改，就听上一级决定
-
功能性Bug， bug出现的原因可能是开发跟测试对需求的理解不一致。有可能是开发理解错需求了。——解决思路：把需求文档对应的说明给开发看。
-
bug优先级
bug严重程度与优先级的关系
-
有些很严重的Bug，只在极端的条件下才出现，用户碰到的概率很低，这种情况优先级就没那么高
-
有些不是很严重的Bug, 比如界面类的，拼写错误，但如果是公司名称，产品名称拼写错了，虽然不是很严重，但优先级就很高，需要立即处理
