1. 什么是验收测试

验收测试是基于用户需求和功能处理的形式化测试。它确定软件是否符合指定的要求和用户要求。它作为一种黑盒测试进行，其中所需用户的数量涉及测试系统的接受度。这是软件测试的第四级，也是最后一个级别。

用户验收测试（UAT）是一种由客户在接受最终产品之前完成的测试。通常，UAT是由客户(领域专家)根据他们的满意度来完成的，并根据给定的业务场景(实时场景)检查应用程序是否在工作。

在这种情况下，我们只关注客户经常使用的特性和场景，或者业务的主要用户场景，或者最终用户或客户日常使用的场景。

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

验收测试是对以前完成的所有测试过程的挤压。

2. 验收测试背后的原因

一旦软件经历了单元测试，集成测试和系统测试，验收测试可能看起来是多余的，但由于以下原因，它是必需的。

• 在项目开发期间，如果需求发生变化并且可能无法有效地传达给开发团队。
• 开发人员通过检查自己理解的需求文档来开发功能，并且可能不了解客户的实际需求。
• 可能会有一些小错误，只有当最终用户在实际场景中使用系统时才能识别出来，因此，为了发现这些小错误，验收测试是必不可少的。

一旦应用程序没有错误，我们将其移交给客户，没有客户在使用前盲目接受应用程序。因此，他们进行一轮测试以提高他们的满意度，这称为用户验收测试。

3. 谁执行用户验收测试？

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

例如，The blue-dart 公司向TCS提出了开发应用程序的要求，TCS将接受需求并同意在两个版本中交付应用程序，如下图所示：

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

但项目经理说，我们必须在给定的时间内交付软件。修复缺陷还需要 30 天，否则，我们将不得不在给定发布日期后的每一天支付罚款。这是真实情况吗？不，让我们看看三种不同的情况，并了解谁执行验收测试。

案例1

在此，我们将讨论如何执行验收测试，在这里测试工程师将进行验收测试。

大多数情况下，测试应用程序的实际流程将在上图中看到，但这里几乎没有区别，因为我们知道端到端测试或系统测试在哪里结束，验收测试将在哪里进行。若要了解此方案，请按照以下过程操作：

The blue-dart 公司提供要求，TCS开发应用程序并执行所有测试并移交给 blue-dart 公司。

现在问题出现了，The 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收取罚款（有时罚款按小时收取）。如果识别出的错误不符合要求，则 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从其最终用户和客户那里收集需求时开发的。

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

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

注意：

修补程序：在生产环境中，每当客户发现关键错误时，我们都会执行以下操作

• 开发人员修复了错误。
• 测试工程师的小团队将测试软件。
• 在客户端环境中重新安装应用程序。
• 客户端开始使用新软件。

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

例如：如果重要模块，假设登录模块本身在生产服务器上不工作，那么客户端将立即发送它进行修复，并且必须尽快完成。

短暂的释放

在两个主要版本之间，这是一个简短的改进版本，当客户需要一些小功能紧急更改时，就会发生这种情况。

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

4. 执行验收测试的步骤

需求分析：

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

测试计划创建：

测试计划创建概述了测试过程的整个策略。此策略用于确保和验证软件是否符合指定的要求。

测试用例设计：

此步骤包括基于测试计划文档创建测试用例。测试用例的设计方式应涵盖大多数验收测试方案。

测试用例执行：

测试用例执行包括使用适当的输入值执行测试用例。测试团队从最终用户收集输入值，然后测试人员和最终用户执行所有测试用例，以确保软件在实际场景中正常工作。

目标确认：

成功完成所有测试过程后，测试团队确认软件应用程序没有错误，可以交付给客户端。

5. 验收测试中使用的工具

验收测试可以通过使用多种工具来完成；下面给出了一些：

Watir:

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

Fitness tool:

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

6. 验收测试的优点

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

7. 验收测试的缺点

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

• 客户不愿意这样做，它破坏了验收测试的全部要点。
• 如果测试用例是由其他人编写的，则客户不理解它们，因此测试人员只能自己执行检查。

如果该过程以这种方式完成，则会破坏验收测试的存在。