有多个bug时，有些bug会直接影响到接下来的测试工作，急于处理，这类bug就属于优先级较高的bug，得优先修复。而有的bug，可能并不直接影响，可以排在后面。
bug的数量和级别都会影响到程序员的年终奖，所以很多时候测试人员和开发人员都会因为bug出现争论（甚至争吵）
开发说：这不是bug / 这个bug级别太高了，不应该是这样 / bug影响不大，我不改了
诸如此类..
为避免产生争执，需要有效沟通。
1）先检查自身提出的bug，是否描述不清楚？
能用文字描述bug，就尽量描述精准，这样就能减少沟通成本
但有时，bug的确很难用文字表达，词不达意。那么在提交bug的时候，就找到对应的开发人员对bug进行解释，确保程序员明白bug的描述
不要等到开发人员找自己，而是主动沟通。
2）站在用户角度考虑问题
应该让开发人员了解到Bug对用户可能造成的困扰，这样才能促使开发人员 更加积极地、高质量地修改Bug。在争执时，可以问一句：如果你是用户，你可以接受么？
案例： 例如：需求要求可以上传图片作为头像，但是没有定义格式。开发人员在上传时限制为只能传png格式的。 站在用户角度考虑一下：png，jpg那种格式更多？是否要用户自己进行格式转换再上传？
3）bug级别的定义要有理有据
bug定级描述文档拿出来，然后将bug的表现和bug定级描述文档进行匹配，说服程序员
4）提高自身技术和业务水平，做到不能提出问题，最好也能给出解决方案
（说话预期要委婉，不要以命令式的口吻来要求别人按照自己的逻辑来修改）
测试小白：更多的是提出问题（bug）
测试大牛：除了提出问题也能定位到问题，给出解决方案
5）开发人员比较犟，怎么说都不听的情况下，就需要进行bug评审
多轮沟通，但是开发人员仍然拒不接受。此时可以发起Bug评审。
Bug评审要注意的问题 缺陷的评审应该包括以下两个层面
● 决定如何处理Bug。
● 分析缺陷产生的原 因，找出预防的对策。
(1)决定如何处理Bug。 这一方面评审需要项目组各个方面的代表参加，通常不可缺少的是测试代表、开发代表、产品代表。
测试代表：(测试领导、一起测试的同事)
主要从Bug的具体表现、严重程度等方面提供信息，并提出自己对Bug的处理意见。需要注意 的是，测试人员不应该一味地要求对Bug进行修改，因为修改可能带来回归的风险，同时带来的是回归 测试的工作量，如果时间比较紧迫，修改后剩余的时间若不足以做一次有效的回归测试，可能不修改是 个明智的选择。
开发代表：（开发领导、开发人员）
主要从修改缺陷的难度和风险出发，考虑缺陷修改需要付出的代价，以及可能影响的范围、可 能引发的风险等，如果决定要修改，还要讨论出修改的初步方案。
产品代表:（产品经理）
主要从产品的整体计划、用户的要求等方面对缺陷的修改必要性、缺陷修改的时间和版本提出 自己的意见。 这在微软的做法叫“Bug三方讨论会”，参加者一般是测试人员、开发人员和项目经理。 案例： 某网站经常隔几天访问时会出现500错误，但是之后就不会复现。 测试人员会提出问题：网站偶发性出现500错误。 开发人员回答：不常见，不影响使用，暂不修改 资深测试人员提出问题：网站偶发性500错误，查看日志，是由于mysql数据库8小时超时问题造成。需要修改 连接池配置定期校验连接 开发人员处理：修改xml，增加校验配置项 比特就业课
(2)分析缺陷产生的原因，找出预防的对策。 缺陷评审还应该包括原因分析，找出Bug出现的原因，尤其 是那些重复出现的Bug。应该找出出现错误的根源，并且制定出相应的预防措施，确保同类型的Bug不 再出现。 例如：有些Bug出现的原因不是简单的“引用为空”之类，而是开发人员的编码不规范或者编程 习惯不好而导致，所以必须建立起正确的编程方式才能预防这些错误的出现，否则只是在玩无聊地重复 发现相同的Bug的游戏。
