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