需求：第一步 A ，第二步 B ，得到结果 C 。 测试：第一步 A ，没有结果 C 。 开发×：你没点 B 。好好看看文档。 开发√：第一步 A ，第二步不点 B ，结果应该是 D 。 @产品。 我相信需求里肯定是没有写不执行 B 结果是怎么样的，否则肯定是测试的问题，你也不会来抱怨了。 没有明确文档化的行为都是有一定周旋空间的，友好讨论。 ================================== （以下是如果真的吵起来，从开发角度怎么维护自己。） ================================== 如果你觉得从流程上讲，测试不应该——或者说无权——给未定义的行为定性为 BUG ，你可以向经理反馈。可以要求测试先与开发或者产品讨论，达成一致再发 BUG 。 也可以要求对测试提交的 BUG 有效率进行评估。如果测试最近发的十个 BUG 里有至少三个都是无效 BUG ，那你可以说测试没理解需求，瞎点。 ================================= （以下是如果真的吵起来，测试角度可能怎么针对。） ================================= 作为测试，可以申明立场：需求文档中能明确覆盖的只是真实测试工作量的十分之一。 如果只需要测文档中写的内容，那测试可太轻松了。评估测试工作量的主要参数就是测试能想到多少文档外的未定义路径。 测试可能明确提问：如果文档里没写的用例，不让测试去负责，那么用户点了发现问题，是谁的锅呢？ 测试可以向管理要求，明确测试有对未定义行为发 BUG 的权力。 测试可以评估所发 BUG 中，有文档定义的 bug 的比例。如果比例大于 50%，说明开发质量太差，基本的需求都实现不了，一测就一堆问题。如果比例小于 50%，强调测试自由发挥的重要性，大部分 BUG 都是测试在探索未定义行为时候发现的问题。

测试和开发应该是一边的，工作中大部分矛盾来自不合理的项目排期管理和有限的研发资源之间的矛盾，排期紧张或者需求变更导致矛盾被迫转移到了开发和测试之间

开发和测试的利益完全看公司怎么管理和设计奖惩制度的。 测试独立出来成为一个职能的目的，就是用不同于开发人员的视角（尽可能的贴近用户）来对程序功能做测试。 本质上是为了尽可能避免项目进入到投产阶段之后才发现问题，轻则导致返工，重则造成损失。 按我的理解，正常情况下，测试帮你把 bug 测出来了，是好事情。 如果是程序逻辑上的问题，那你确实要感谢他； 如果是产品设计上的问题，那你们应该一起找产品，讨论设计是不是真的不合理，不合理的话怎么修改设计； 除非你们公司属于那种被测出来 bug 就要扣绩效的，那我建议你跟管理层反馈一下这个制度的不合理，或者干脆换一家公司。

做了这么多年开发，我还真没怎么跟测试吵过架，倒是经常和产品撕逼。

我告诉你，有些用户的操作比测试人员还无厘头

测试的目的不就是帮你查漏补缺，堵死预期外的路径？只测正常路径功能是否实现，那需要测试吗？

这次我站测试。1.看描述没有提紧急 bug ，你最好的做法是商量看能不能关掉或者有时间再改 2.“根本没吃透”，指望测试吃透有点强人所难了，你说的话是有点阴阳怪气，有时间跟他说怎么回事，没时间就转产品

我和客户吵过，我和领导吵过，但从来没有和测试吵过，我认为是伙伴，就跟狙击手有个观察手一样。 测试是帮助开发找出问题的，是让产品完善的。 测试可以提 case ，但如果不是问题，开发可以解释。 如果有争议，可以开多人评审会议，集体讨论，领导拍板一下。

测试不就是瞎点吗？要是都按流程来那还有什么 bug 呢？既然有前置条件你就拦截啊，没有弄完前置条件为什么要进行下一步呢？你的问题比较大，用户管你这的那的

和 lz 的情况有点相反，有种测试更无奈，每让她测一个功能都让开发给她讲一遍测试流程和测试点，这不应该她自己读需求然后自己设计吗？倒不是怕费劲，问题是这种流程如果是开发告诉她了，那还要测试干嘛呢，开发自己就测完了，测试就是应该按照自己的方式去测才能测出问题啊