我被MSpec吸引，希望有一天能够与非开发人员*分享我的测试报告，但如果我讨论业务（用户），这是最有价值的（对吧？）测试/场景名称中的经验）（而不是实际测试中的单个C＃对象/成员）。
但是，由于我的低级功能，我正在努力引用我的测试/方案名称中的非开发人员问题。对UI的关注越远，命名方案的难度越大，a）与非开发人员相关，b）描述正在测试的低级功能。
随着您越来越远离UI，是否有一点不能与非开发人员共享测试/方案名称？我觉得答案应该是“不”，因为我不应该测试行为，除非这是非开发人员关心的事情，但我经常失败，我不知道是什么我失踪了。
如果某处有明显的答案，我会很感激引用/引用。
*例如最终用户或其他利益相关者（“利益相关者”可能包括未来开发者 - 或者我在一年半之内 - 使用这些规范来深入了解为什么系统）
答案 0 :(得分：4)
我们通常使用“情景”一词来描述全系统，用户POV情景。
如果您想要一个词来描述类级行为，请尝试“示例”。
您的示例将来自您班级用户的观点。如果这些用户类特别需要以开发人员为中心的行为，那么，是的，您的示例将最终以其中以开发人员为中心的关注点。
话虽如此，这里有一些词汇变化，我发现让我用最面向商业的方式说出我正在寻找的价值：
基本上，如果你使用的是一个开发人员的行话，想象一下用一些单词向某人解释，然后使用它。
但是，我不会过分夸大它。在场景中使用利益相关者的特定领域术语的原因是因为利益相关者对阅读和（希望）编写它们感兴趣。课堂级示例的受众是技术性的，因此如果我们对其中存在技术问题则无关紧要。