blocks|key|2977413|text|在test+case中，您可以尝试确定某些内容在定义的条件下是否按预期工作。在test+scenario中，条件是基于一个假设的故事。在这个观点下，测试场景是测试用例的一个特例。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|2977414|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Test_case|1|http://en.wikipedia.org/wiki/Scenario_test^0|1|9|0|13|D|1|0^^$0|@$1|2|3|4|5|6|7|N|8|@]|9|@$A|O|B|P|1|Q]|$A|R|B|S|1|T]]|C|$]]|$1|D|3|-4|5|6|7|U|8|@]|9|@]|C|$]]]|E|$F|$5|G|H|I|C|$J|K]]|L|$5|G|H|I|C|$J|M]]]]

In a <a href="http://en.wikipedia.org/wiki/Test_case" rel="nofollow">test case</a> you try to determine if something works as expected under defined conditions. In a <a href="http://en.wikipedia.org/wiki/Scenario_test" rel="nofollow">test scenario</a> the conditions are based on a hypothetical story. Under this viewpoint the test scenario is a special case of a test case.

blocks|key|2977502|text|测试方案|type|unstyled|depth|inlineStyleRanges|offset|length|style|BOLD|entityRanges|data|2977503|测试场景是测试用例的输入。测试场景的生成通常发生在与项目干系人的头脑风暴会议中，项目干系人提出场景或询问关于体系结构将如何响应各种情况的问题。场景用于表示利益相关者的兴趣和质量属性要求。场景应该涵盖系统的一系列预期用途(用例场景)、预期变化(增长场景)和意外压力(探索性场景)。|2977504|一个好的情景清楚地说明了导致它的刺激是什么，以及人们感兴趣的反应是什么。例如，一个用例场景可能是：“远程用户在高峰期通过Web请求数据库报告，并在5秒内收到它。”增长场景可能是：“添加新的数据服务器，以将场景1中的延迟减少到1人周内的2.5秒”，而探索性场景可能是：“一半的服务器在正常运行期间停机，而不会影响整体系统可用性。”场景应该尽可能具体，识别刺激、反应和环境。|2977505|以模糊的术语描述的场景，例如“通信中继节点失败”，实际上不是有效的场景。您需要(从利益相关者处)获得更多详细信息，例如预期的操作后果、涉及的系统资产、涉及的最终用户、场景对系统操作的潜在影响以及可能出现的异常情况。更多细节将包括哪个设施或节点检测到故障、对故障的预期自动响应(如果有)、预期的手动干预是什么、哪些功能将在停机期间降级以及为使继电器恢复服务而采取的预期操作。|2977506|场景通常在迭代中被区分优先级，并且最初的几个场景被用于进一步的测试用例开发。|2977507|测试用例|2977508|测试用例开发通常将每个选定的场景从语句和列表转换为记录良好的测试用例。测试用例可以组合和/或扩展场景，添加假设和澄清，定义问题，并提出相关问题。与测试场景生成活动不同，测试用例开发是一个迭代活动，其中添加了新的测试用例，并改进了旧的测试用例以支持场景。|2977509|首先，您必须定义测试用例的上下文。例如，在涉及通信中继节点故障的测试用例中，测试用例的上下文可以定义：|2977510|在repair+is+underway|2977511|restoring+|unordered-list-item|2977512|+system+to+|2977513|2977514|2977515|期间，当系统对正常操作做出反应时，故障时的操作将立即发生什么|2977516|2977517|2977518|一旦你有了上下文，你就必须探索和记录上下文所暗示的问题和问题。例如，问题可能是“如何检测到故障？”问题可能是“哪个子系统检测到故障？”，“检测故障需要多长时间？”和“在这个时间间隔内发生了什么？”其他质量问题可能与安全性、可用性、性能等有关。|2977519|架构师通常审查这些问题和问题，并确定系统将如何对场景做出反应。他们可能会改进架构以帮助回答这些问题。细化测试用例并添加新的测试用例。当所有问题的答案都被记录下来时，测试用例开发就被认为是完成的。|2977520|来源：http://www.sei.cmu.edu|2977521|entityMap|0|LINK|mutability|MUTABLE|url|http://www.sei.cmu.edu/^0|0|4|0|0|0|0|0|0|4|0|0|0|0|0|1|1|1|0|0|0|0|0|3|M|0|0^^$0|@$1|2|3|4|5|6|7|1K|8|@$9|1L|A|1M|B|C]]|D|@]|E|$]]|$1|F|3|G|5|6|7|1N|8|@]|D|@]|E|$]]|$1|H|3|I|5|6|7|1O|8|@]|D|@]|E|$]]|$1|J|3|K|5|6|7|1P|8|@]|D|@]|E|$]]|$1|L|3|M|5|6|7|1Q|8|@]|D|@]|E|$]]|$1|N|3|O|5|6|7|1R|8|@$9|1S|A|1T|B|C]]|D|@]|E|$]]|$1|P|3|Q|5|6|7|1U|8|@]|D|@]|E|$]]|$1|R|3|S|5|6|7|1V|8|@]|D|@]|E|$]]|$1|T|3|U|5|6|7|1W|8|@]|D|@]|E|$]]|$1|V|3|W|5|X|7|1X|8|@]|D|@]|E|$]]|$1|Y|3|Z|5|X|7|1Y|8|@]|D|@]|E|$]]|$1|10|3|-4|5|X|7|1Z|8|@]|D|@]|E|$]]|$1|11|3|-4|5|X|7|20|8|@]|D|@]|E|$]]|$1|12|3|13|5|6|7|21|8|@]|D|@]|E|$]]|$1|14|3|-4|5|6|7|22|8|@]|D|@]|E|$]]|$1|15|3|-4|5|6|7|23|8|@]|D|@]|E|$]]|$1|16|3|17|5|6|7|24|8|@]|D|@]|E|$]]|$1|18|3|19|5|6|7|25|8|@]|D|@]|E|$]]|$1|1A|3|1B|5|6|7|26|8|@]|D|@$9|27|A|28|1|29]]|E|$]]|$1|1C|3|-4|5|6|7|2A|8|@]|D|@]|E|$]]]|1D|$1E|$5|1F|1G|1H|E|$1I|1J]]]]

Test Scenarios 
Test Scenarios are inputs to test cases. Generation of test scenarios usually takes place in a brainstormig session with project stakeholders, who propose scenarios or ask questions about the way in which the architecture will respond to various situations. Scenarios are used to represent stakeholders' interests and quality attribute requirements. Scenarios should cover a range of anticipated uses of (use case scenarios), anticipated changes (growth scenarios), and unanticipated stresses (exploratory scenarios) to the system. 

A good scenario makes clear what the stimulus is that causes it and what responses are of 
interest. For example, a use case scenario might be: “Remote user requests a database report 
via the Web during peak period and receives it within 5 seconds.” A growth scenario might be: “Add a new data server to reduce latency in scenario 1 to 2.5 seconds within 1 person-week,” and a exploratory scenario might be: “Half of the servers go down during normal operation without affecting overall system availability.” Scenarios should be as specific as possible, identifying stimuli, responses, and environment.

A scenario described in vague terms such as 'a communication relay node failed' is not really a valid scenario. You need to get (from stakeholders) further details such as the expected operational consequences, the system assets involved, the end-users involved, the potential affects of the scenario on system operation, and the exceptional circumstances that may arise. More details would include which facility or node detects failure, what is the expected automated response to failure (if any), what is the expected manual intervention, which capabilities will be degraded during the outage, and the expected actions taken to return the relay to service.

Scenarios are often prioritized in an iteration and first few scenarios are taken for further test case development.

Test Cases 
Test case development usually transforms each of the selected scenarios from a statement and list of bullets into a well-documented test case. The test cases may combine and/or extend the scenarios, add assumptions and clarifications, define issues, and pose relevant questions. Unlike the test scenarios generation activity, the test cases development is an iterative activity in that new test cases are added and old test cases are refined to support a scenario. 

First you have to define context of a test case. In a test case involving a communication relay node failure, for example, the context of a test case may define:

<ul>
<li>the operation at the time of failure</li>
<li>what happens immediately after, when the system is reacting to the failure</li>
<li>degraded operation during the interval when repair is underway</li>
<li>restoring the system to normal operation</li>
</ul>

Once you have context in place, you have to explore and document issues and questions that are implied by context. For example, the issue could be "how failure is detected?". Questions could be "What subsystem detects the failure?", "How long does it take to detect the failure?" and "What happens during this interval?". Other quality issues could be related to security, availability, performance etc.

Architects usually review those issues and questions and determine how a system would react to a scenario. They might refine the architecture to help answer the questions. Test cases are refined and new test cases are added. Test case development is considered complete when all answers to questions are documented.

Source: <a href="http://www.sei.cmu.edu" rel="nofollow">http://www.sei.cmu.edu</a>

I faced this question in interview. When I searched on internet I found different answers. Please provide specific example.

Could someone please explain the difference between test scenario and test case

翻译质量差，导致语言生硬或混乱。

没有提供实际的解决方法或示例。

解答不清晰，无法理解或解决问题。

页面排版不美观，阅读体验差。

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

我在面试中遇到了这个问题。当我在网上搜索时，我找到了不同的答案。请提供具体的例子。

问有人能解释一下测试场景和测试用例之间的区别吗
EN

Stack Overflow用户

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问有人能解释一下测试场景和测试用例之间的区别吗EN