我在采访中遇到了这个问题。当我在网上搜索时，我找到了不同的答案。请提供具体的例子。
答案 0 :(得分：3)
测试方案
测试场景是测试用例的输入。测试场景的生成通常发生在与项目利益相关者的头脑风暴会议中，他们提出场景或询问架构如何响应各种情况。场景用于表示利益相关者的兴趣和质量属性要求。情景应涵盖系统的一系列预期用途（用例情景），预期变化（增长情景）和意外压力（探索性情景）。
一个好的方案可以清楚地说明导致它的刺激是什么以及回应是什么 利益。例如，用例场景可能是：“远程用户请求数据库报告 在高峰期通过网络，并在5秒内收到它。“增长方案可能是：”添加一个新的数据服务器，以减少1个人每周内情景1到2.5秒的延迟，“一个探索性的场景可能是：”在正常运行期间，有一半服务器停机，而不影响整体系统可用性。“情景应尽可能具体，识别刺激，响应和环境。
用模糊术语描述的场景，例如“通信中继节点失败”并不是真正有效的场景。您需要（从利益相关方）获得更多详细信息，例如预期的运营后果，涉及的系统资产，涉及的最终用户，方案对系统运行的潜在影响以及可能出现的特殊情况。更多细节将包括哪个设施或节点检测到故障，预期的故障自动响应是什么（如果有的话），预期的人工干预是什么，在停电期间哪些功能会降低，以及将继电器返回到服务。
方案通常在迭代中被优先考虑，并且前几个方案被用于进一步的测试用例开发。
测试用例
测试用例开发通常将每个选定的场景从一个声明和子弹列表转换为一个记录良好的测试用例。测试用例可以组合和/或扩展场景，添加假设和说明，定义问题并提出相关问题。 与测试场景生成活动不同，测试用例开发是一个迭代活动，因为新的测试用例被添加，旧的测试用例被细化以支持场景。
首先，您必须定义测试用例的上下文。例如，在涉及通信中继节点故障的测试用例中，测试用例的上下文可以定义：
一旦有了上下文，您就必须探索并记录上下文隐含的问题和问题。例如，问题可能是“如何检测到故障？”。问题可能是“什么子系统检测到故障？”，“检测故障需要多长时间？”和“在这段时间内会发生什么？”。其他质量问题可能与安全性，可用性，性能等有关。
架构师通常会审核这些问题，并确定系统如何对场景做出反应。他们可能会改进架构以帮助回答问题。改进测试用例并添加新的测试用例。当记录所有问题答案时，测试用例开发被认为是完整的。
答案 1 :(得分：2)
在test case中，您尝试确定某些内容是否在定义的条件下按预期工作。在test scenario中，条件基于假设的故事。在这种观点下，测试场景是测试用例的特例。