验收测试

验收测试是基于用户需求和功能处理的正式测试。它决定了软件是否符合规定的要求和用户需求。它是一种黑盒测试，其中涉及的必要用户数量在测试系统的验收级别。它是软件测试的第四个也是最后一个级别。

用户验收测试 (UAT) 是一种在最终产品被接受之前由客户进行的测试。通常，UAT 由客户（领域专家）为确保其满意度而进行，并检查应用程序是否按照给定的业务场景、实时场景运行。

在这种情况下，我们只关注客户经常使用的功能和场景，或者对业务而言最常用的用户场景，或者最终用户或客户每天使用的场景。

然而，软件已经通过了三个测试级别（单元测试、集成测试、系统测试）。但在系统由最终用户在实际场景中使用时，仍然可能发现一些小错误。

验收测试是对之前完成的所有测试过程的精炼。

验收测试的原因

一旦软件通过了单元测试、集成测试和系统测试，验收测试似乎是多余的，但由于以下原因，它是必需的。

• 在项目开发过程中，如果需求发生变化，可能没有有效地传达给开发团队。
• 开发人员根据自己的理解来开发功能，并可能不理解客户的实际需求。
• 可能存在一些小错误，只有当系统由最终用户在实际场景中使用时才能发现，因此，为了找出这些小错误，验收测试是必不可少的。

注意
一旦我们收集了客户的需求并完成了所有编码过程，测试工程师就会开始进行所有不同类型的测试，直到应用程序稳定为止。

一旦应用程序没有错误，我们就将其交给客户。客户在实际使用之前不会盲目接受应用程序。因此，他们会进行一轮测试以确保满意度，这就是用户验收测试。

谁执行用户验收测试？

在不同情况下，验收测试可以由不同的人员执行。

例如，Blue-Dart 公司将开发应用程序的需求提供给 TCS，TCS 将接受需求并同意在两个版本中交付应用程序，正如我们在下图中所看到的。

8月10日，测试经理告知项目经理应用程序中存在一个严重错误，需要再花四天时间修复。

但是项目经理说我们必须在规定的时间内交付软件。修复缺陷需要额外 30 天，否则我们将为每个逾期版本日期支付罚款。这是真实情况吗？不是，让我们看三种不同的情况，了解谁执行验收测试。

情况 1

在本例中，我们将讨论验收测试是如何执行的，在这里将由测试工程师执行验收测试。

大多数情况下，测试应用程序的实际流程将如上图所示，但这里略有不同，正如我们所知，端到端测试或系统测试结束，验收测试将继续。为了理解这种情况，请遵循以下过程。

Blue-Dart 提供需求，TCS 开发应用程序并执行所有测试，然后交付给 Blue-Dart 公司。

现在的问题来了，Blue-Dart 在收到 TCS 的应用程序后会立即使用吗？不，Blue-Dart 公司有一组测试工程师，他们在收到软件后，这个团队将开始测试应用程序，并且此端到端测试在客户环境进行，称为**用户验收测试**。

让我们看看**TCS 测试工程师**和**Blue-Dart 工程师**之间的区别。

**TCS** 中的测试人员将执行**功能测试、集成测试和系统测试**，而在**Blue-Dart** 中，测试人员仅执行**端到端或系统测试，这称为验收测试**。

TCS 和 Blue-Dart 的端到端测试之间的区别如下：

• Blue-Dart 的测试工程师是提供需求的人。
• Blue-Dart 工程师对产品有很好的理解。
• Blue-Dart 工程师是领域专家。
• 他们会在应用程序上测试实时数据。

为了理解这一点，我们可以看下面的例子，或者如果我们的应用程序格式是这样的。

当应用程序交给 Blue-Dart 的测试工程师时，他们将执行测试，并且应用程序应该生成一条文本消息“**包裹 1 发票 ID 已创建**。”这在需求中没有提及，或者即使提及了，TCS 也未修复。那么 TCS 的罚款（或称违约金）就从这里开始计算，而 TCS 的测试工程师对此一无所知，因此，我们可以看到 TCS 和 Blue-Dart 的测试之间的区别。

情况 2

在这种情况下，我们将看到员工如何成为最终用户并执行验收测试。

应用程序在 TCS 环境中开发和测试，然后发送到 Blue-Dart。在 Blue-Dart，他们的测试工程师较少，因此他们无法进行验收测试。因此，在 Blue-Dart 的 300 名员工中，他们会将应用程序提供给 30 名员工，并将应用程序安装到他们的系统上，让他们开始使用应用程序并找出任何缺陷或问题。

现在，这 30 名员工将进行模拟实施，这意味着他们将数据输入应用程序，并且还手动记录这些数据。在这里，员工成为最终用户，并在使用应用程序时发现错误和问题。

这些问题将根据需求进行验证，然后 TCS 将被收取罚款（有时罚款按小时收取）。如果发现的 bug 不符合要求，那么 Blue-Dart 可以进行**增强请求 [REF] 和变更请求 [CR]**。

其中，**增强请求**是指如果 Blue-Dart 认为某个特定模块可以改进并以更好的方式开发，那么他们可以发送**客户需求规范 [CRS]** 作为 REF，TCS 将遵循 CRS 并进行必要的更改。

而**变更请求**是指，如果需求没有准确说明，那么 Blue-Dart 提供确切的需求并请求更改。

因此，验收测试也可以定义为端到端测试，它可以由在客户环境中工作的工程师执行。在这里，他们采用实时场景并检查应用程序是否正常运行，我们还可以创建实时业务场景，因为最终用户知道业务流程是如何工作的。

注意

如果我们收到更多用于验收测试的构建，这意味着：

• 收到应用程序后，客户会获得越来越多的想法，因此他们会要求越来越多的更改。
• 交付给客户的软件质量不合适，开发和测试都没有正确完成。
• 开始时给出的需求不清楚。

情况 3

在这种情况下，如果 Blue-Dart 的客户成为最终用户。

在这里，应用程序已在 Blue-Dart 生产服务器上开发、测试和实施，n 个用户开始使用应用程序，这是第一个版本。在使用应用程序时，Blue-Dart 会提出更多功能和增强功能，这些功能将通过 CRS 发送给 TCS，之后 TCS 将对模块进行进一步更改并发送回 Blue-Dart。

因此，这里发生的是，在收集了 Blue-Dart 从其最终用户和客户那里收集的需求后，应用程序才得到开发。

发布的数量取决于以下事实：

• 模块的难度
• 模块的数量。
• 新模块如何影响旧模块。

注意

**热修复：**在生产环境中，每当客户发现严重错误时，我们将执行以下操作：

• 开发人员修复错误。
• 一小组测试工程师将测试软件。
• 将应用程序重新安装到客户环境中。
• 客户开始使用新软件。

整个过程称为热修复，可以在几个小时或一天内完成。

例如：如果一个重要模块，例如登录模块本身在生产服务器上无法工作，那么客户会立即发送进行修复，并且必须尽快完成。

短期发布

在两次主要发布之间，这是一个改进的短期发布，当客户需要紧急更改一些小功能时会发生。

例如，如果我们有 60 名开发人员，其中 10 名开发人员将参与，在 40 名测试工程师中，3 名测试工程师将参与，他们开发和测试应用程序。在将其添加到生产服务器之前，客户会进行一次短期验收测试。

执行验收测试的步骤

需求分析

在此步骤中，测试团队分析需求文档，以找出已开发软件的目标。测试计划通过使用需求文档、流程图、系统需求规范、业务用例、业务需求文档和项目章程来完成。

测试计划创建

测试用例设计

测试用例执行

目标确认

验收测试中使用的工具

验收测试可以使用多种工具进行；以下是一些工具：

可以使用多种工具进行；以下是一些工具：

Watir

验收测试使用此工具执行自动化的基于浏览器的测试用例。它使用 Ruby 语言进行进程间通信。

Fitness 工具

此工具用于输入值并自动生成测试用例。用户需要输入值，这些值由工具用于执行测试用例并生成输出。它使用 Java 语言进行进程间通信。此工具可以轻松创建测试用例并以表格形式记录它们。

验收测试的优点

• 它提高了客户的满意度，因为他们自己测试了应用程序。
• 软件的质量标准在早期阶段就已定义，以便测试人员已经确定了测试点。它为测试策略提供了清晰的视图。
• 利益相关者通过验收测试收集的信息用于更好地理解目标受众的需求。
• 它改进了需求定义，因为客户根据自己的需求测试需求定义。

验收测试的缺点

根据测试计划，客户必须用自己的话自己编写需求，但是

1. 客户不愿意这样做，这违背了验收测试的全部目的。
2. 如果测试用例由其他人编写，客户不理解它们，那么测试人员只能自己进行检查。

如果以这种方式进行过程，它将破坏验收测试的存在。