需求：第一步 A ，第二步 B ，得到结果 C 。

测试：第一步 A ，没有结果 C 。

开发×：你没点 B 。好好看看文档。
开发√：第一步 A ，第二步不点 B ，结果应该是 D 。 @产品。

我相信需求里肯定是没有写不执行 B 结果是怎么样的，否则肯定是测试的问题，你也不会来抱怨了。

没有明确文档化的行为都是有一定周旋空间的，友好讨论。

==================================
（以下是如果真的吵起来，从开发角度怎么维护自己。）
==================================

如果你觉得从流程上讲，测试不应该——或者说无权——给未定义的行为定性为 BUG ，你可以向经理反馈。可以要求测试先与开发或者产品讨论，达成一致再发 BUG 。

也可以要求对测试提交的 BUG 有效率进行评估。如果测试最近发的十个 BUG 里有至少三个都是无效 BUG ，那你可以说测试没理解需求，瞎点。

=================================
（以下是如果真的吵起来，测试角度可能怎么针对。）
=================================

作为测试，可以申明立场：需求文档中能明确覆盖的只是真实测试工作量的十分之一。

如果只需要测文档中写的内容，那测试可太轻松了。评估测试工作量的主要参数就是测试能想到多少文档外的未定义路径。

测试可能明确提问：如果文档里没写的用例，不让测试去负责，那么用户点了发现问题，是谁的锅呢？

测试可以向管理要求，明确测试有对未定义行为发 BUG 的权力。

测试可以评估所发 BUG 中，有文档定义的 bug 的比例。如果比例大于 50%，说明开发质量太差，基本的需求都实现不了，一测就一堆问题。如果比例小于 50%，强调测试自由发挥的重要性，大部分 BUG 都是测试在探索未定义行为时候发现的问题。