它是用户对软件应用程序的特定使用的简要描述。基本上，它是基于用户操作而制定的。它广泛用于开发验收级别的测试用例。
用例是参与者在与系统交互以实现目标时采取的行动列表。在这里，参与者可以是任何人，可以是人类用户，也可以是任何其他外部系统。基本上，它是一种技术，可以帮助识别覆盖整个系统的测试用例，逐个事务地，从开始到结束。
在用例中，将有一组操作供用户完成。动作可以是 -
提款
余额查询，
余额转介
正在开发的与软件相关的动作
在此，我们提供了用户与系统交互以实现目标的不同方式的完整概述。更好的文档有助于以更简单的方式确定对软件系统的需求。
这可以由软件开发人员、软件测试人员以及利益相关者使用。
文件的用途 -
开发人员使用文档来实现代码和设计它。
测试人员使用它们来创建测试用例。
业务涉众使用该文档来了解软件需求。
有两种类型的用例 -
晴天用例- 当一切顺利时，这是最有可能发生的主要案例。晴天用例比其他用例具有更高的优先级。完成案例后，我们会将其提供给项目团队进行审查，并确保我们涵盖了所有必需的案例。
雨天用例- 雨天用例可以定义为边缘案例列表。此类案例的优先级将在“晴天用例”之后。我们可以在利益相关者和产品经理的帮助下进行调查以强调案例。
下面给出了用例中的各种类型的元素 -
Actor - 参与用例操作的用户。
Precondition - 案件开始前要满足的条件。
基本流程- 基本流程是系统中的正常工作流程。基本上，它是参与者在实现其目标时完成的交易流程。当演员与系统交互时，不会有任何错误，演员将得到他所期望的预期输出。
替代流程- 除了正常的工作流程外，系统还可以有一个“替代工作流程”。这是用户与系统进行的非常不常见的交互。
异常流- 异常是一种阻止用户实现某种类型目标的流。
Post Condition - 案例完成后需要检查的条件。
参与者在用例中犯的常见错误是它包含关于特定案例的太多细节或根本没有足够的细节。
如果需要，这些是文本模型，我们可能会或可能不会向其中添加可视化图表。
确定适用的先决条件。
以正确的顺序编写流程步骤。
指定过程的质量要求。
当我们尝试编写用例时，应该出现的第一个问题是“客户的主要用途是什么？”。
我们必须获得这些的模板。
它必须是富有成效的、简单的和强大的。如果有小错误，那么强用例可以给观众留下深刻印象。
我们应该给它编号。
我们应该在它的步骤 Order 中编写 Process。
给场景取适当的名字，命名必须根据目的。
这是一个迭代过程，这意味着当您第一次编写它们时，它不会是完美的。
确定系统中的参与者。
让我们考虑第一个演员。我们可以有多个演员具有相同的行为。
例如，在网上购物中，买家/卖家都可以“创建一个帐户”。买家和卖家都可以搜索项目。因此，这些是重复的行为，需要消除。除了使用重复的案例外，我们必须有更多的泛化案例来避免重复。
我们必须确定适用的先决条件。
考虑这样一个场景，一个人尝试从在线购物模式购买东西，因为用户将首先登录到系统。用户可能会开始执行搜索操作并选择搜索结果中显示的一个或多个项目，然后他会将它们添加到购物车或购买。
在这一切之后，用户将购买或结帐。因此，这是一个逻辑连接的一系列步骤的示例，用户将执行这些步骤以完成系统以完成任务。
要么，
在开发用例时，通常会开发测试用例表。用户应该完成几个步骤 -
插卡
验证卡并要求输入 PIN
输入 PIN 码
验证 PIN，以及
允许访问帐户
在此之后，表格中还会有一个扩展名列表。例如，如果系统确定某些内容不正确。
扩展名可以是 -
显示卡无效并拒绝的消息，和/或
显示 pin 无效的消息并仅要求重试次数
用例指定主体可以与一个或多个参与者协作执行的某些行为的类型。
该用例无法实施，这意味着它仅设计。另一方面，设计了测试用例，然后我们实现了它们。
的使用情况下从得到的BRS（业务需求规范），而测试案例从衍生的用例。
的使用情况下是一个图形表示的客户机的要求，而测试情况下，不表示在仅在Excel工作表记录。
该用例是一个文件，它总是描述应用程序的事件流。另一方面，测试用例是一个文档，它始终包含应用程序特定功能的操作、事件和预期输出。
该用例依赖于软件的要求。另一方面，测试用例取决于用例。
该用例收集的要求，而在另一方面，测试案例将分析这些要求。
在用例中，结果未经验证。另一方面，对测试用例结果进行验证，这意味着测试用例检查用例中显示的结果是否正常运行。