Answers:
欢迎使用法律英语。
使用“应该” ==“应该” ==合同义务。这是法制主义。它不会导致“质疑”。它将该句子标记为正式的合同义务。
使用“ would” ==“ will” ==好主意。它将句子标记为可选功能。
提问是促进，组织，帮助，建立信任的一部分。不是选择单词的结果。
使用没有修饰语的简单动词会使句子很难正式强调。对于超复杂动词，可以弄清楚如何使它变得共轭。
容易-动词，例如“ notify”或“ create”。
系统通过电子邮件通知。（无论是什么，动词“ tonot notify”与“ notify”在“ system”之间是共轭的。）
系统应通过电子邮件通知。（“通知”变为“应通知”-不可共轭。非常简单。）
困难的动词短语（例如“登录”）或特定领域的动词短语（例如“提取，清理，转换，重复数据删除和加载”）或已动词的名词（例如“ prospect”）。包含多个动词的较长短语很难被共轭：每个动词都被共轭？还是尝试将长短语当作一个单词进行共轭？由于任何名词都可以用英语动词，因此很难知道如何将这些虚构动词进行共轭。
当用户单击Enter时，系统提取，清理，转换，重复数据删除和加载。（英语琐碎地动词使用任何名词短语。）或者它是提取，清理，转换，重复数据删除和加载？
当用户单击Enter时，系统应提取，清理，转换，重复数据删除和加载。（可怕的短语保持不变，对动词变位没有任何神秘感。）
[“什么？” 你说“任何名词都可以用英语动词吗？”。是。任何名词。我要在这个问题上作废。我经常对此感到困惑。甚至规格也应对此予以阻碍。]
纯粹是风格偏好问题。归结为问，您/您的客户是否喜欢以现在或将来的时态考虑该系统？
诸如“应该”或“将要”之类的限定词表示未来时态，但这很柔和，当以当前时态思考时，读起来足够好。缺少限定词肯定表示当前时态（即此刻）。
我更喜欢使用限定符，因为在两种情况下它都能很好地读取，而在开发过程中，当一切都变得紧张时，缺少限定符的读取会有些奇怪。
无论如何，如果您决定使用限定词，我强烈建议您使用“ must”而不是“ should”。“应该”可以解释为是可选的（尽管S.Lott提出相反的主张），但是“必须”完全消除了任何歧义-必须明确地表示“不是可选的”。
而且由于我还不能发表评论（业力约束），所以这是对S.Lott关于“应/应该与将/将/将”的回应：即使在法律合同撰写中，关于意愿和意愿也有很多歧义。 请参阅本文以获取解释。
我赞成使用第三人称，现在时不带限定词。
我的主要观点是：测试就是一个故事。
故事由场景组成。每个场景描述：
例：
描述：
getReceipt功能内容：收据存在
IT：退回收据
就像一个好故事一样，一个好测试很容易阅读。
故事告诉您程序的功能，例如
另一方面，使用限定符（无论是“应该”还是“必须”都无关紧要）将测试转换为断言列表，例如：
没有连续的故事：您的思想正在评估一系列断言。
这是主观的，但是阅读自然语言（一个故事）比阅读断言列表更简单。
我认为您应该始终使用“应该”。
推理-使用BDD时，在编写测试时，该软件尚未执行您想要的操作，因此说“做某事”是错误的。它“应该做某事”，并且只要它继续做某事，测试就会通过。
从behaviour-driven.org题为“GettingTheWordsRight” ：
简而言之，我们用来描述事物的词语会影响我们（和其他人）对这些事物的思考方式。这也不是一个简单的语义问题，因为某些单词带有细微差别，这些细微差别会影响我们在知识和情感层面上对短语含义的理解。我们的语言充满描述性的单词和短语，因此使用可以清楚传达我们希望在代码中描述的元素意图的单词似乎是合理的。
就BDD而言，我个人是在命名测试时几乎总是使用“ 应该 ”一词的原因，因为它的使用暗示着尽管意图是为了使测试提供一定的结果，但可能还会产生其他意想不到的后果，需要加以解决。如果测试结果被认为是有效的。您也许可以使用期望或必须这样的词类似地，但是这些词暗示了更命令性的观点，即测试名称可能被误认为“测试没有错，假设实现被搞砸了”，而“应该”则暗示测试很可能会是正确的，但是如果测试结果似乎没有加起来，可能需要再次检查是否有错误，我喜欢这样做，因为它会影响您的思维，因此鼓励您在编写代码时保持开放的态度，这非常当您希望在尝试调试代码时避免陷入困境时发现错误，这一点很重要。
但是，我已经看到，当该单词被强制用作测试名称的前缀时，该单词的近乎“宗教”的应用应该会失败，因为它迫使所涉及的程序员经过某些心理和语言体操，以提供能够是有意义的，在这种情况下，这意味着使单词正确的意图无法满足其预期，结果，测试本身也变得难以解读。当这种情况出现时，我通常会使用“ 应该 ”一词在测试方法名称中的任何位置，以确保该名称能够简单，清晰地传达其方法。但是，如果在给定的上下文中其他单词同样合适，我当然不会强制使用特定的单词。但是，诀窍是选择那些在代码中表示什么的地方，而没有争论的余地，这些词会激起您去思考代码应该做什么而不必依靠任何暗示的事情。