验收测试

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

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

在此，我们仅关注客户经常使用的功能和场景，或者业务的大多数用户场景，或者最终用户或客户每天使用的场景。

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

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

验收测试的原因

一旦对软件进行了单元测试，集成测试和系统测试，验收测试就显得多余了，但是由于以下原因，它是必需的。

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

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

一旦该应用程序没有错误，我们将其移交给客户，没有客户在使用它之前盲目接受该应用程序。因此，他们会对其满意度进行一轮测试，这就是用户接受度测试。

谁执行用户验收测试?

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

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

8月10日，测试经理告诉项目经理该应用程序中存在一个严重的错误，这将需要另外四天时间对其进行修复。

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

情况1

在本文中，我们将讨论验收测试的执行方式，而测试工程师将在此处进行验收测试。

通常，在上图中可以看到测试应用程序的实际流程，但是在这里几乎没有什么区别，因为我们知道端到端测试或系统测试在何处结束以及验收测试将在哪里进行。要了解这种情况，请执行以下过程：

蓝镖提供了要求，TCS开发了应用程序并执行了所有测试并移交给了蓝镖公司。

现在，问题来了，蓝箭人一旦从TCS那里获得该应用程序，便会立即使用该应用程序?否，blue dart公司在获得软件后会有一组测试工程师，并且该团队将开始测试应用程序，并且这种端到端测试是在客户环境中完成的，这称为“用户接受测试” 。

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

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

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

• 提出要求的人是蓝镖测试工程师
• 飞镖工程师非常了解产品
• 这位飞镖工程师是领域专家。
• 他们在应用程序上测试实时数据。

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

将应用程序提供给飞镖测试工程师后，他们将进行测试，并且应用程序应生成一条文本消息“已创建包裹1发票ID ”。需求中没有提到它，或者它在那里，并且TCS不会解决它。然后，TCS的罚款(罚款)仅计入TCS，而TCS的测试工程师不会知道这一点，因此，我们可以看到在TCS和Blue-dart进行的测试之间的区别。

案例2

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

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

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

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

“增强请求”意味着如果蓝箭认为可以更好地改进和开发特定模块，然后他们可以发送客户需求规范[CRS]，因为REF和TCS将遵循CRS并确保进行必要的更改。

变更请求意味着，如果未正确指定需求，则蓝箭会提供确切的需求和变更请求。

因此，验收测试也可以定义为端到端测试，可以由在客户端环境中工作的工程师来完成。在这里，他们采用实时方案并检查应用程序是否运行良好，并且由于最终用户知道业务流程的工作原理，因此我们可以制定实时业务方案。

注意：

如果我们有更多的版本用于验收测试，则意味着：

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

案例3

在这种情况下，如果飞镖客户成为最终用户。

在这里，该应用程序是在蓝飞镖的生产服务器上开发，测试和实现的，并且第一个版本中有n个用户开始使用该应用程序。在使用该应用程序时，蓝箭具有更多的功能和增强功能，这些功能和增强功能随CRS一起发送到TCS，之后TCS将对模块进行进一步的更改并将其发送回蓝箭。

因此，这里的问题是，blue-dart从他们的最终用户和客户那里收集需求时，便开发了该应用程序。

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

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

注意：

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

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

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

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

短发布

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

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

执行验收测试的步骤

需求分析：

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

测试计划创建：

测试用例设计：

测试用例执行：

目标确认：

验收测试中使用的工具

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

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

瓦特尔：

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

健身工具：

该工具用于输入输入值并自动生成测试用例。用户需要输入值，这些值由工具用于执行测试用例并产生输出。它使用Java语言进行进程间通信。该工具使创建测试用例以及以表格形式记录下来变得容易。

验收测试的优势

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

验收测试的缺点

根据测试计划，客户必须以自己的语言和自己编写要求，但

• 客户不愿意这样做；它击败了验收测试的全部要点。
• 如果测试用例是由其他人编写的，那么客户将无法理解它们，因此测试人员只能自己进行检查。

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