de_DEen_USes_ESfa_IRfr_FRid_IDjapl_PLpt_PTru_RUvizh_CNzh_TW

什么是软件测试?

软件测试是通过验证和确认来检查被测软件的产物和行为的过程。软件测试还提供了对软件的客观、独立的视角,使公司能够认识和理解软件实施的风险。

软件测试可以为用户或赞助方提供关于软件质量及软件故障风险的客观、独立信息。测试的主要目的之一是检测软件故障,以发现并纠正缺陷。测试无法确定产品在所有条件下都能正常工作,只能确定它在某些特定条件下无法正常工作。

用例测试

用例测试是一种功能性的黑盒测试技术,有助于测试人员定义测试场景,并按照Ivar Jacobson在其著作《面向对象的软件工程》中所述,以事务为单位从头到尾全面测试整个系统。通过使用该技术,测试团队可以基于每个功能的特性创建测试场景,从而从头到尾全面测试整个软件。用例测试是用户与软件应用程序之间的交互,因此有助于从用户的角度测试系统。以下是其中的一些优势。

什么是用例?

  • 用例使用叙述性语言编写,从最终用户的角度描述系统的功能需求。
  • 用例图使用统一建模语言创建,每个步骤以椭圆形表示其名称;
  • 参与者用一个带名字的简笔人形表示;每个动作通过参与者与用例之间的连线表示;
  • 系统边界用一个围绕用例的矩形表示。

用例的组成部分

根据您想要或需要的深度和复杂程度,用例描述了以下元素的组合。

  • 参与者——任何执行行为的个体或事物(即使用系统的人或物)
  • 主要参与者——为了实现目标而启动与系统交互的利益相关者
  • 次要参与者系统需要其协助才能完成用例的参与者.
  • 前置条件——必须在用例执行前或执行后真实存在或发生
  • 触发事件——引发用例启动的事件

用例场景以及替代路径路径

用例建模是一种正式的方法,用于表示业务系统与其环境的交互方式,并展示系统用户执行的活动。它也是UML中一种基于场景的技术。用例是一组完成特定任务或目标所需的步骤。通常,一个用例可以有多个路径;每条路径被视为一个用例场景。简而言之,用例是一个目标及其相关流程,而用例场景则代表了这些操作中的一条线性且直接的路径。

场景是展示与一个提议系统交互的某种情境。场景是需求分析过程中使用的一种工具,用于描述提议系统的一种具体用途。场景通过具体示例从外部(例如用户)视角来捕捉系统的行为。一个用例可能包含用户与系统交互时可选择的多个“路径”;每条路径被称为一个场景。

  • 主要成功场景 [基本流程] – 用例中没有错误。
  • 替代路径 [替代流程] – 这些路径是主主题的变体。它们是在系统层面出现问题时发生的异常情况。

用例测试示例

用例场景被视为应用程序与参与者(用户)之间的交互。这些用例用于描述需求,因此也可作为验收测试的基础。

以ATM为例,我们展示成功和失败的情况。在此图中,我们可以看到A(参与者——在此为人员)与S(系统)之间的交互。步骤1到5为成功案例,表明卡片和密码已验证,参与者被允许访问账户。

  1. A:插入卡片,
  2. S:验证卡片并要求输入PIN码,
  3. A:输入PIN码,
  4. S:验证PIN码,并
  5. S:允许访问账户。

然而,在扩展过程中可能会出现其他三种场景,例如在验证卡片时,系统发现存在错误。这些扩展情况可列于下方。它们分别是图中所示的2a、4a和4b。

2a)S:卡片无效(显示消息并拒绝卡片)
3a)S:密码无效(显示消息并要求重试——两次),以及
4a)S:密码连续三次无效(吞卡并退出)

用例场景作为测试用例

用例场景本质上是用例的文档。换句话说,它描述了用户在使用应用程序或系统时可能采取的操作。它还描述了用户在使用软件时可能遇到的情境。为了创建准确的测试场景,我们通常会收集客户、最终用户和/或利益相关者的意见。这有助于全面覆盖所有可能的用例场景,从而实现对用例所有业务流程的全面测试。

用例与测试用例

用例和测试用例是软件测试领域中经常使用的术语,它们也密切相关。用例用于说明为完成特定任务而设计的系统应如何使用。相比之下,测试用例是一组为特定测试目标而设计的测试输入、执行条件和预期结果。

比较参数 用例 测试用例
定义 一系列按顺序执行的操作,用于描述角色与系统之间的交互,以实现特定目标, 一组测试输入、条件和变量,用于定义软件的特性。
目标 通过执行所有顺序操作,达到最终操作 验证软件是否运行正常。
迭代 它遵循不同的路径 它遵循单个测试用例一次测试一个
依赖 它依赖于需求 它依赖于用例
需求 需要文档和研究 测试输入脚本,每个测试脚本完成一个步骤
完成 一次性完成所有步骤 测试反复进行,直到完成。
交互 用户 结果
工作 它按照软件的逐步功能能力运行。 在测试人员的帮助下运行,以验证软件