什么是用户验收测试(UAT)？

产品负责人和业务部门通常处理需求并关注它们。因此，他们可以在 UAT 过程中使用基于需求和基于活动的测试技术。作为测试人员，我们也可以在测试过程中使用这些技术。我将在本文中解释其中的一些技术。但首先，让我们从什么是 UAT 测试开始。

在敏捷方法论中，通常是产品所有者在故事的开发和软件测试过程完成后执行的测试活动。在瀑布和 V 模型流程中，这些测试通常由分析师或业务部门执行。UAT 的目的是确定用户对所请求作业的要求是否已得到满足，并获得现场部署的批准。

一、用户故事测试

在敏捷软件开发生命周期中，从最终用户的角度来看，用户故事可以描述为软件中所请求的特性。在用户故事中，我们必须指定需求、需求的原因以及请求它的用户。

完成的定义 (DOD)定义了完成标准，例如代码完成、单元测试完成、测试完成、UAT 完成等……Scrum 指南指出 Scrum 团队（开发人员、测试人员、产品负责人 等）拥有并负责国防部。

此外，验收标准应由产品负责人明确表达（开发团队可能会帮助产品负责人），并且在用户故事的测试过程中应为每个验收标准准备至少一个测试场景，并且必须仔细测试这些验收标准。

还必须在开始测试运行之前定义测试进入和退出标准。

二、用例测试

用例定义了用户/参与者在系统中为实现特定目的而执行的操作。可以使用用例定义和管理系统的功能需求。通过这种方式，确定了所需或请求的作业的范围。通过考虑用户为达到特定目的而确定的步骤的输入和输出来准备测试场景。在测试期间，通过比较预期输出和实际输出来确定测试结果。

在编写用例时，通常首选商业语言而不是技术语言。因此，它们经常用于编写验收测试。为了涵盖所有需求，至少为每个需求准备一个测试场景。通过这种方式，可以增加测试覆盖率，我们也可以使用追溯矩阵来衡量这个覆盖率。在追溯矩阵中，我们创建了一个包含测试场景和需求的矩阵表，如果满足每个测试用例的需求，我们在相关字段中打上叉号。目标是满足所有要求。

三、基于清单的测试

在敏捷流程中，我们创建了一个独立于用户故事创建的通用清单。如果用户故事中没有指定任何风险，则可以根据用户故事的范围使用所有或部分清单项目。在执行这些测试期间，如果您发现缺陷，您应该通过添加失败的场景来扩展检查表的范围。因此，我们可以为后续冲刺增加清单中的风险项目。

四、探索性测试

首先，探索性测试不是随机或临时测试。关于这种测试技术的最大误解之一是探索性测试被认为是一种随机的、不可测试的、不可观察的测试技术。探索性测试是基于在敏捷过程中利用测试工程师的经验、领域知识、分析知识和智力知识，同时学习和探索产品的测试方法。

在开始探索性测试之前，应做好准备工作。无论选择何种探索性测试方法，我们都应该针对功能范围、使用的工具、测试数据、环境等制定一个计划，该计划将在测试执行过程中指导测试人员。探索性测试的另一个重要点是测试完成后文档完全完成。

虽然它不是强制性的，但“基于会话的测试”技术通常是首选的探索性测试技术。

五、基于经验的测试

这种测试技术基于测试人员的知识、技能和经验。在这种测试技术中；测试计划、测试策略、测试输入和测试场景由执行测试的人的经验决定。为了更喜欢这种技术，它必须是具有足够技术和业务知识的经验丰富的候选人才能执行此测试。

由于考虑了过去项目中获得的经验，因此在测试过程中更容易理解正确或错误。此人可以使用探索性测试等技术进行测试，这将更容易使用过去的经验和智力/分析知识。当我们的测试执行时间非常短或项目缺乏足够的文档等时，使用这种测试技术是有意义的。如果正在测试的系统包含高风险，那么单独使用基于经验的测试技术是不可取的，因为应该完全涵盖需求的上下文。

六、用户旅程测试

用户旅程测试考虑了系统上典型用户的各种路线图和旅程。在这些测试中，确定用户在站点内进行的最关键的旅程，然后编写这些旅程的场景。因此，尽可能地覆盖了用户与系统的交互。这些测试通常是“端到端”测试，因此它们可能需要比其他测试更多的时间来运行，但这些测试的覆盖率高于其他测试。

由于“用户旅程”测试是全面而广泛的测试，因此与其他测试相比，数量相对较少。特别是，可以在考虑最关键的“用例”场景的情况下创建“用户旅程”测试。这里最合理的行为是应该首先运行积极的基本场景，称为“快乐路径”。

七、基于风险的测试

基于风险的测试技术最基本的目标之一是以最低的成本尽早发现最关键和最重要的错误。风险是我们不知道会发生什么的事情，但我们知道可能发生的事情的概率。简而言之，它们是可能的问题。当这些可能性未知时，它们被称为不确定性。因此，我们可以认为风险大小的一般定义是问题发生的可能性及其影响的乘积。因此，在基于风险的测试中，我们优先考虑并测试最容易出错的功能。

八、启发式基于风险的测试

在您的项目开始时，您的风险分析可能在某种程度上不完整或不正确，因为一开始不可能 100% 估计所有内容。但是，随着您的项目进展和产品改进，您的估计和风险分析将变得越来越强大。根据詹姆斯巴赫的说法，风险的两个最关键因素是经验和团队合作。一段时间后，产品或技术开始显露出特征性问题。观察和了解它们很重要。此外，与不同观点的人进行风险分析非常关键。此外，使用基于风险的列表有助于我们与管理层就测试人员的有效性进行谈判。我们可以向他们展示我们将现有的测试人员用于产品的最关键点，或者我们可能需要向他们解释我们需要额外的人员来覆盖所有风险领域。这些基于风险的清单为您提供了与管理层谈判的额外权力。