验收测试

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

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

在这方面，我们只关注那些客户经常使用的功能和场景，或者主要是业务的用户场景，或者最终用户或客户日常使用的那些场景。

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

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

笔记：

它在客户处的单独环境中完成，称为 UAT 环境。用户验收测试由称为领域专家的不同团队完成，该团队为应用程序所知。

一般来说，小公司没有领域专家，因为应用程序不会经常发生变化。

验收测试背后的原因

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

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

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

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

谁执行用户验收测试？

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

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

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

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

情况1

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

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

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

现在问题出现了，blue-dart 会在从 TCS 获得应用程序后立即使用它吗？NO，blue dart 公司拿到软件后有一组测试工程师，这个团队会开始测试应用程序，这个端到端的测试是在客户环境中完成的，这就是所谓的用户验收测试。

让我们看看TCS 测试工程师和Blue-dart 工程师之间的区别：

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

在 TCS 和 blue-dart 的端到端测试之间的区别如下：

• blue-dart 测试工程师是提出要求的人
• blue-dart 工程师对产品很了解
• blue-dart 工程师是领域专家。
• 他们在应用程序上测试实时数据。

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

当应用程序交给 blue-dart 测试工程师时，他们将执行测试，应用程序应生成一条文本消息“ Parcel 1 invoice Id created”。需求中没有提到它，或者它就在那里，并且 TCS 没有修复它。那么罚款（罚金）仅对 TCS 计数，而 TCS 的测试工程师不会知道这一点，因此，我们可以看到在 TCS 和 Blue-dart 完成的测试之间的差异。

案例2

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

该应用程序在 TCS 环境中开发和测试，然后发送到 blue-dart。而在 Blue-dart 中，他们的测试工程师较少，因此无法进行验收测试。为此，blue-dart 的 300 名员工中，他们将向 30 名员工提供应用程序并将应用程序安装到他们的系统中，并要求他们开始使用该应用程序并发现任何缺陷或问题。

现在有 30 名员工将执行虚拟实施，这意味着他们将数据提供到应用程序中并手动写入该数据。在这里，员工成为最终用户，并在使用应用程序时识别错误和问题。

这些问题根据要求进行验证，现在对 TCS 收取罚款（有时罚款按小时收费）。如果识别出的错误不符合要求，那么 blue-dart 可以请求增强请求 [REF] 和变更请求 [CR]。

其中Request for Enhancement是指如果 blue-dart 觉得某个特定模块可以以更好的方式改进和开发，那么他们可以发送Customer Requirement Specification [CRS]作为 REF，TCS 将遵循 CRS 并确保做必要的改变。

而变更请求意味着，如果需求没有被准确地指定，那么 blue-dart 会提供准确的需求和变更请求。

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

笔记：

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

• 客户收到申请后，想法越来越多，所以要求的改变也越来越多。
• 我们交付给客户的软件质量不合适，开发和测试都没有做好。
• 开始时给出的要求不明确。

案例3

在这种情况下，如果 blue-dart 客户成为最终用户。

在这里，应用程序是在 blue-dart 生产服务器上开发、测试和实现的，并且有 n 个用户开始使用该应用程序，这是第一个版本。在使用该应用程序时，blue-dart 提出了更多的功能和增强功能，这些特性和增强功能与 CRS 一起发送到 TCS，然后 TCS 将在模块中进行进一步的更改并将其发送回 blue-dart。

因此，这里发生的事情是，当 blue-dart 从最终用户和客户那里收集需求时，开发了该应用程序。

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

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

笔记：

Hotfix：在生产环境中，每当客户发现关键bug时，我们都会做以下处理

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

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

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

Short release

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

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

执行验收测试的步骤

需求分析：

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

测试计划创建：

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

测试用例设计：

此步骤包括基于测试计划文档创建测试用例。测试用例的设计方式应该能够覆盖大部分验收测试场景。

测试用例执行：

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

确认目标：

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

验收测试中使用的工具

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

通过使用多种工具完成；下面给出了一些：

Watir:

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

Fitness tool:

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

验收测试的优势

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

验收测试的缺点

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

1. 客户不愿意这样做；它打败了验收测试的全部意义。
2. 如果测试用例是别人写的，客户看不懂，测试人员只能自己做检查。

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