恐怕我不知道这种措辞的起源，而且我以前从未见过，但是我很惊讶地看到这里的答案认为“如果失败”等同于“如果通过”，因为我很强烈认为这两者彼此非常不同，而且我的观点是，无论如何，对于手动测试，“如果失败”略优于“如果”则 - 如果我考虑自动化测试，它似乎只能断言“如果'通过'或'如果不失败'。

以 Glowcoder 的回答为例，需要一个向用户提示的搜索框。在测试此条件的测试步骤中，我们可以说“如果未向用户提示搜索框，则测试失败”或“如果向用户提示搜索框，则测试通过”。它们看起来是等价的——如果向用户提示搜索框，两者都不会失败，但请考虑以下结果：

实际结果：搜索框提示用户，但页面有错误

• '失败如果'通过或失败：未确定
• 'passes if' 通过或失败：通过

实际结果：向用户提示搜索框，但搜索标签拼写为“Saerch”

• '失败如果'通过或失败：未确定
• 'passes if' 通过或失败：通过

实际结果：搜索框提示给用户，但搜索框加载需要十多秒

• '失败如果'通过或失败：未确定
• 'passes if' 通过或失败：通过

希望其中没有太多内容，因为任何手动测试都希望由能够识别尽管满足通过标准的人运行，但如果在搜索框加载时发生错误，则不能真正认为该步骤通过。我只是觉得“如果通过”可能会增加测试人员的确认偏差，因为他们只需要寻找一个通过条件就可以满怀信心地进入下一步。

就个人而言，我不会在我的测试脚本中使用任何一个术语，因为我会使用更冷静、更不重要的术语，比如“会有一个向用户提示的搜索框”。我必须能够安全地假设与我一起工作的测试人员能够环顾被测软件并阅读的内容远远超过我在测试步骤中写入的内容。在我看来，可能的故障条件总是比容易识别的通过条件多得多。

这是团队中的约定问题，仅此而已。预期结果“如果登录表单不存在则测试失败”与“如果登录表单存在则测试成功”相同。

测试用例可能不完整，但如果测试人员忘记添加检查是否存在搜索字段，则使用什么约定并不重要。

需求文档应该清楚地描述预期的内容。这应该始终以任何人都可以判断软件是否成功满足该要求的方式编写。

鉴于此，我认为无论您选择哪种方式都不重要。我认为您不需要同时包含两者，但您确实需要在测试中定义决定通过或失败的因素。对我们来说，我们有一个测试步骤描述、一组执行该步骤后的预期结果，然后是一个通过/失败复选框。如果达到预期结果，则测试通过。如果不是，则测试失败。预期结果可以写成包括正面和负面。测试步骤可以是“导航到登录页面的 URL”。预期的结果可能是“存在登录页面。软件启动时未遇到错误”。如果页面出现，测试不仅成功，而且页面必须没有其他不利影响。

当然，我认为您不会希望两者都参加同一个测试。你的要求要么是排他的（失败的条件多于通过的条件，所以你想说“通过，如果...”）或包容的（通过的条件多于失败的条件，所以你想说“失败如果。 ..”）。如果两者都有，那将表明一个更复杂的要求，例如“如果向用户提示搜索框则通过，但如果配色方案与其余对话框不匹配则失败”。这会让我想对其进行两项测试，一项是提示出现，另一项是提示颜色是否正确。

我认为“根据失败来定义测试如果......”的系统范围标准并且不允许“如果......通过”方法会导致不必要的冗长（和混淆）测试用例。如果允许通过但不允许通过失败，情况也是如此。

我对文档措辞的唯一要求是它有效地将测试用例映射到需求，并解释读者需要知道什么来解释测试，或者将他们指向可以得到解释的更多信息. pass if 和 failed if 方法都适用于他们自己的情况，并且应该在它们是正确选择时使用。