了解什么是用户验收测试（UAT），以及其定义、类型、步骤和例子：
在试图理解一个新概念时，我的第一条规则是：： 名字永远都是相关的，而且大多是字面的意思 (在技术方面)。
找出那是什么，将对它有一个初步的了解，并帮助我开始进行。
=>； 点击这里查看完整的测试计划教程系列
让我们来测试一下这个概念。
=>； 阅读所有教程 在我们的验收测试系列中。
什么是用户验收测试？
我们知道什么是测试，验收意味着批准或同意。 在软件产品的背景下，用户要么是软件的消费者，要么是要求为他/她建造软件的人（客户）。
因此，按照我的规则--定义将是：
用户验收测试（UAT），也被称为测试版或最终用户测试，被定义为由用户或客户测试软件，以确定它是否可以被接受。 这是功能、系统和回归测试完成后进行的最后测试。
这种测试的主要目的是根据业务需求对软件进行验证。 这种验证是由熟悉业务需求的最终用户进行的。
UAT、alpha和beta测试是验收测试的不同类型。
由于用户验收测试是软件上线前进行的最后一次测试，显然这是客户测试软件的最后机会，衡量它是否适合于目的。
何时进行？
这通常是产品上线前或接受产品交付前的最后一步。 这是在产品本身被彻底测试后进行的（即系统测试后）。
谁来执行UAT？
用户或客户--这可以是购买产品的人（在商业软件的情况下），也可以是通过软件服务提供商定制软件的人，或者是最终用户，如果软件提前提供给他们，在征求他们的反馈意见时。
这个团队可以由测试人员组成，或者客户应该在内部从组织的每个小组中选择UAT成员，以便每个用户角色都能得到相应的测试。
用户验收测试的必要性
开发人员和功能测试人员是根据功能规格验证软件的技术人员。 他们根据自己的知识解释需求并开发/测试软件（这里是领域知识的重要性）。
这个软件根据功能规范是完整的，但有一些只有最终用户知道的业务需求和流程要么是错过了沟通，要么是被误解了。
在发布软件供市场使用之前，这种测试在验证所有业务需求是否得到满足方面起着重要作用。 对实时数据和真实用例的使用使这种测试成为发布周期的重要组成部分。
许多因发布后的问题而遭受巨大损失的企业都知道成功的用户验收测试的重要性。 发布后修复缺陷的成本要比发布前修复的成本高许多倍。
UAT真的有必要吗？
在进行了大量的系统、集成和回归测试后，人们会想知道这种测试的必要性。 实际上，这是项目最重要的阶段，因为这是真正要使用该系统的用户验证该系统是否适合使用的时候。
UAT是一个测试阶段，主要取决于终端用户的观点和代表终端用户的部门的领域知识。
事实上，如果业务团队很早就参与到项目中来，这对他们真的很有帮助，这样他们就可以提供他们的意见和贡献，帮助系统在现实世界中的有效使用。
用户验收测试过程
理解这一过程的最简单方法是将其视为一个自主测试项目--这意味着，它将有计划、设计和执行阶段。
以下是规划阶段开始前的先决条件：
#1）收集关键的验收标准
简单地说，验收标准是在验收产品前要评估的事项清单。
这可能有两种类型：
(i) 应用功能或业务相关
理想情况下，所有的关键业务功能都应该得到验证，但由于各种原因，包括时间，要做到这一点是不现实的。 因此，与客户或要参与这个测试的用户开一两次会，可以让我们了解到要涉及多少测试，以及要测试哪些方面。
(二)合同性 - 我们不打算讨论这个问题，而且QA团队在所有这些方面的参与几乎是没有的。 甚至在SDLC开始之前就已经起草了最初的合同，并就合同的所有方面是否已经交付达成了协议。
我们将只关注应用程序的功能。
#2）确定质量保证的参与范围。
QA团队的角色是以下之一：
(i) 不参与 - 这是很罕见的。
(ii) 协助这一测试 -- 在这种情况下，我们的参与可能是培训UAT用户如何使用应用程序，并在这个测试过程中待命，以确保我们能在用户遇到任何困难时提供帮助。 或者在某些情况下，除了待命和协助外，我们可能在用户进行实际测试时分享他们的反应并记录结果或记录bug等等。
(iii) 执行UAT并提交结果 -- 如果是这种情况，用户将指出他们想要评估的AUT领域，评估本身由QA团队执行。 一旦完成，结果将提交给客户/用户，他们将决定他们手中的结果是否足够，是否符合他们的期望，以便接受AUT。 决定绝不是说的QA团队。
根据手头的案件，我们决定哪种方法是最好的。
主要目标和期望：
通常，UAT由主题专家（SME）和/或商业用户承担，他们可能是被测系统的所有者或客户。 与系统测试阶段类似，UAT阶段在结束前也包括宗教阶段。
每个UAT阶段的关键活动定义如下：
UAT治理
与系统测试类似，对UAT实施有效的管理，以确保强大的质量关口以及定义的进入和退出标准（在下面提供**）。
** 请注意，这只是一个指导，可以根据项目需要和要求进行修改。
UAT测试规划
这个过程与系统阶段的常规测试计划几乎相同。
在大多数项目中，最常见的方法是同时计划系统和UAT测试阶段。 关于UAT测试计划的更多信息以及样本，请查看所附测试计划文件的UAT部分。
用户验收测试计划
(这与你在我们网站上找到的QA培训系列是一样的）。
点击下面的图片并向下滚动，找到各种格式的测试计划文件样本。 在该模板中，检查UAT部分。
日期、环境、演员（谁）、通信协议、角色和责任、模板、结果及其分析过程、进入-退出标准-所有这些以及其他任何相关的东西都将在UAT测试计划中找到。
无论QA团队是参与、部分参与还是根本不参与这个测试，我们的工作是计划这个阶段，并确保一切都被考虑在内。
用户验收测试设计
从用户那里收集的验收标准被用于这一步。 样本可以如下所示。
(这些是CSTE CBOK的摘录，这是关于这个测试最好的参考资料之一）。
用户验收测试模板：
基于这些标准，我们（QA团队）给用户一个UAT测试案例的清单。 这些测试案例与我们常规的系统测试案例没有区别。 它们只是一个子集，因为我们测试所有的应用程序，而不是仅仅测试关键的功能区域。
除此以外，数据、记录测试结果的模板、管理程序、缺陷记录机制等，在我们进入下一阶段之前，都必须到位。
测试执行
通常，在可能的情况下，这种测试发生在一个会议或作战室，用户、PM、QA团队的代表都坐在一起一两天，通过所有的验收测试案例进行工作。
或者在QA团队执行测试的情况下，我们在AUT上运行测试案例。
一旦所有的测试都进行了，而且结果在手，那么 接受决定 这也被称为 去/不去的决定 如果用户满意的话，就可以进行，否则就不可以。
达成接受决定通常是这个阶段的结束。
工具和方法论
通常情况下，在这个测试阶段使用的软件工具类型与进行功能测试时使用的工具类似。
工具：
由于这一阶段涉及验证应用程序的完整的端到端流程，可能很难有一个工具来完全自动验证。 然而，在某种程度上，我们将能够利用系统测试期间开发的自动化脚本。
与系统测试类似，用户也会使用测试管理和缺陷管理工具，如QC、JIRA等。这些工具可以被配置为用户验收阶段的数据积累。
方法：
虽然传统的方法，如特定的商业用户进行产品的UAT仍然是相关的，但在今天这样一个真正的全球化世界中，用户验收测试有时必须根据产品涉及不同国家的客户。
例如 、 在这样的情况下，人群测试将是最好的可行选择。
群众测试 是一种方法，来自世界各地的人们可以参与并验证产品的使用，并提出意见和建议。
众测平台已经建成，并被许多组织使用。 一个需要众测的网站或产品被托管在平台上，客户可以提名自己来做验证。 然后对提供的反馈进行分析和优先排序。
群众测试方法被证明是更有效的，因为可以很容易地了解全球客户的脉搏。
敏捷环境中的UAT
敏捷环境在本质上是更加动态的。 在敏捷的世界里，商业用户将参与整个项目的冲刺，项目将根据他们的反馈回路得到加强。
在项目开始时，商业用户将是提供需求的关键利益相关者，从而更新产品积压。 在每个冲刺结束时，商业用户将参与冲刺演示，并可提供任何反馈。
此外，在冲刺完成之前，将计划一个UAT阶段，由业务用户进行验证。
在冲刺演示和冲刺UAT期间收到的反馈被整理并添加到产品积压中，而产品积压会被不断审查和优先处理。 因此，在敏捷世界中，商业用户更接近项目，他们更频繁地评估项目的使用，这与传统瀑布项目不同。
UAT团队 - 角色和责任
一个典型的UAT组织将有以下角色和职责。 UAT团队将由项目经理、开发和测试团队根据他们的需要提供支持。
| 角色 | 职责 | 可交付的成果 |
|---|---|---|
| 业务方案经理 | - 创建和维护项目交付计划 - 审查和批准UAT测试策略和计划 - 确保按计划和预算成功完成方案 - 与IT项目经理联系并监督项目的进展情况 - 与业务运营团队紧密合作，为他们提供第一天的运营装备 - 签定业务需求文件 - 审查电子学习课程内容 | - 方案进展报告 - 每周状况报告 |
| UAT测试经理 | - 克里特UAT战略 - 确保IT和商业BA以及PMO之间的有效合作 - 参加需求演练会议 - 审查工作估算，测试计划 - 确保需求的可追溯性 - 推动衡量标准的收集，以量化从更新的测试方法、工具和环境使用中获得的好处。 | - 主测试策略 - 审查& 批准测试方案 - 审查& 批准测试案例 - 审查& 批准需求追踪矩阵 - 每周状况报告 |
| UAT测试负责人& 团队 | - 验证&；根据业务流程验证业务需求 - UAT的估算 - 创建& 执行UAT测试计划 - 参加需求JAD会议 - 根据业务流程准备测试方案、测试案例和测试数据。 - 保持可追溯性 - 执行测试案例并准备测试日志 - 在测试管理工具中报告缺陷，并在其整个生命周期中管理它们 - 编写UAT测试结束报告 - 提供业务准备支持和现场证明 | - 测试日志 - 每周状况报告 - 缺陷报告 - 测试执行指标 - 测试总结报告 - 归档的可重复使用的测试工件 |
UAT的7项挑战和缓解计划
不管你是亿万富翁的一员，还是创业团队的一员，你都应该克服所有这些挑战，为终端用户成功交付软件。
#1）环境设置和部署过程：
在功能测试团队使用的相同环境中进行这种测试，最终肯定会忽略真实世界的用例。 另外，像性能测试这样的关键测试活动不能在测试数据不完整的测试环境中进行。
应该为这个测试建立一个单独的类似生产的环境。
一旦UAT环境与测试环境分离，你需要有效地控制发布周期。 不受控制的发布周期可能导致测试和UAT环境中的软件版本不同。 当软件没有在最新版本上测试时，宝贵的验收测试时间就被浪费了。
同时，对不正确的软件版本进行问题跟踪所需的时间也很高。
#2）测试规划：
这种测试应该在需求分析和设计阶段用明确的验收测试计划来规划。
在战略规划中，应该确定一组真实世界的用例来执行。 为这个测试确定测试目标是非常重要的，因为在这个测试阶段，大型的应用程序不可能有完整的测试执行。 测试应该首先对关键业务目标进行优先排序。
这个测试是在测试周期的最后进行的。 很明显，这是软件发布最关键的时期。 前面任何一个开发和测试阶段的延迟都会吞噬掉UAT的时间。
不恰当的测试计划，在最坏的情况下，会导致系统测试和UAT之间的重叠。 由于时间少和满足最后期限的压力，即使功能测试没有完成，软件也会被部署到这个环境中。 在这种情况下，这种测试的核心目标就无法实现。
UAT测试计划应该在开始测试前准备好并告知团队，这将有助于他们进行测试计划、编写测试用例和测试脚本以及创建UAT环境。
#3）将新的业务需求作为事件/缺陷来处理：
UAT测试人员发现由于需求不明确而产生的问题（通过查看需求收集阶段没有的完整用户界面），并将其记录为缺陷。
客户希望在当前版本中修复这些问题，而不考虑变更请求的时间。 如果项目管理部门没有对这些最后一刻的变更作出及时的决定，那么这可能导致发布失败。
#4）不熟练的测试人员或没有业务知识的测试人员：
当没有固定的团队时，公司从内部各部门挑选UAT人员。
即使员工非常熟悉业务需求，或者他们没有接受过正在开发的新需求的培训，他们也不能进行有效的UAT。 另外，一个非技术性的业务团队在执行测试用例时可能会面临许多技术困难。
同时，在UAT周期结束时指派测试人员并不能为项目增加任何价值。 花一点时间培训UAT人员可以大大增加UAT的成功机会。
#5）不适当的沟通渠道：
远程开发、测试和UAT团队之间的沟通更加困难。 当你有一个离岸技术团队时，电子邮件沟通往往非常困难。 事件报告中的一个小的模糊之处可能会推迟其修复一天。
适当的计划和有效的沟通对于有效的团队协作至关重要。 项目团队应该使用基于网络的工具来记录缺陷和问题。 这将有助于平均分配工作量，避免报告重复的问题。
#6）要求功能测试团队进行这项测试：
没有比要求功能测试团队进行UAT更糟糕的情况了。
由于缺乏资源，客户把他们的责任推给了测试团队。 在这种情况下，这种测试的整个目的就会受到影响。 一旦软件上线，最终用户会很快发现问题，而功能测试人员并没有考虑到这些问题的真实情况。
解决这个问题的方法是将这种测试分配给具有业务知识的专门和熟练的测试人员。
#7）责备游戏
有时，商业用户只是试图找到拒绝软件的理由。 这可能是他们的自我王国，以显示他们有多么优越，或者指责开发和测试团队，以获得商业团队的尊重。 这种情况非常罕见，但在有内部政治的团队中发生。
处理这种情况是非常困难的。 然而，与企业团队建立积极的关系肯定会有助于避免指责游戏。
我希望这些指南一定会帮助你克服各种挑战，成功地执行用户验收计划。 正确的计划、沟通、执行和积极的团队是成功的用户验收测试的关键。
系统测试与用户验收测试
测试团队的参与在项目的早期就开始了，就在需求分析阶段。
在整个项目生命周期中，都会对项目进行某种验证，即静态测试、单元测试、系统测试、集成测试、端到端测试或回归测试。 这让我们更好地了解在UAT阶段进行的测试，以及它与之前进行的其他测试有什么不同。
虽然我们看到了SIT和UAT的区别，但重要的是我们要利用协同效应，但仍要保持这两个阶段的独立性，这将使产品更快地进入市场。
总结
#1) UAT不是关于页面、字段或按钮的问题。 底层的 假设 在这个测试开始之前，所有这些基本的东西都已经测试过了，而且工作正常。 上帝保佑，用户发现一个如此基本的错误--这对QA团队来说是一个非常糟糕的消息。
#2) 这种测试是关于企业中主要元素的实体。
让我给你举个例子： 如果AUT是一个票务系统，那么UAT就不是关于搜索打开页面的菜单等，而是关于票务及其预订，它可以采取的状态，它在系统中的旅程等。
另一个 例子、 如果该网站是一个汽车经销商网站，那么重点是 "汽车及其销售"，而不是真正的网站。 因此，核心业务是验证和确认的内容，谁能比企业主更好地做到这一点。 这就是为什么当客户在很大程度上参与时，这种测试是最合理的。
#3) UAT的核心也是一种测试形式，这意味着 在这个阶段也有很大的机会发现一些错误。 这有时会发生。 除了这是QA团队的一个重要升级外，UAT错误通常意味着要开会讨论如何处理它们，因为在这个测试之后，通常没有时间来修复和重新测试。
该决定将是要么：
- 推迟上线日期，先解决这个问题，然后继续前进。
- 让这只虫子保持原样。
- 考虑将其作为未来版本的变更请求的一部分。
#4) UAT被划分为Alpha和Beta测试，但在服务型行业的典型软件开发项目中，这种分类并不那么重要。
- 阿尔法测试 当UAT在软件构建者的环境中进行时，在商业现成软件的背景下更为重要。
- Beta测试 是在生产环境或客户环境中进行的UAT。 这对面向客户的应用来说是比较常见的。 这里的用户是实际的客户，比如你和我。
#5) 在普通的软件开发项目中，如果没有暂存环境或UAT环境，大多数时候UAT是在QA环境下进行的。
简而言之、 发现你的产品是否可以接受和适合使用的最好方法是将其实际放在用户面前。
组织正在进入敏捷交付的方式，商业用户越来越多地参与进来，项目正在通过反馈回路得到加强和交付。 所有这些都完成了，用户验收阶段被认为是进入实施和生产的大门。
你的UAT经验是什么？ 你是在待命还是为你的用户进行测试？ 用户有没有发现任何问题？ 如果有，你是如何处理的？
=>； 访问这里获取完整的测试计划教程系列