用户验收测试指南1UAT的重要性

2024-09-17 07:19 由磁石空杯发表于 #其他

1 UAT的重要性

简介中介绍了一些有助于更好地理解 UAT 的一般概念，并介绍了一些备受瞩目的项目失败案例。这些失败即使不是由 UAT 引起的，也肯定不是由 UAT 避免的。第 1 章概述了 UAT、UAT 的目的、UAT 与实施项目的关系以及参与项目的人员。您将了解为什么 UAT 不同于其他类型的测试，但却经常使用相同的流程，其中之一就是基本测试流程。最后，您将了解到 UAT 的不同类型、谁是 UAT 的利益相关者，以及每个角色在 UAT 过程中的作用和收获。
本章涉及的主题

什么是 UAT？
为什么要测试信息系统？
业务脆弱性
UAT 过程
从 UAT 到服务交付
UAT 与合同
UAT 中的利益相关者

1.0 习题

1.0.1 选择题

1. UAT 与开发过程中进行的其他测试有什么不同？
  A. UAT 比其他类型的测试花费更多时间
  B. UAT 必须由最终用户进行
  C. UAT 根据需求规格评估系统
  D. 只要由用户进行，UAT 可以是非正式测试
1. 以下哪三项是 UAT 的基础？
  A. 技术规格
  B. 用户需求
  C. 需求规格
  D. 验收标准
  E. 业务流程
  F.为系统测试开发的测试
  G. 开发人员设计的自动测试
1. 为什么用户必须进行 UAT？请选择三个选项。
  A. 因为他们比开发人员和测试人员有更多的可用时间
  B. 因为他们不是系统技术性能方面的专家
  C. 因为用户将系统作为实现业务利益的工具的能力是成功的关键
  D. 因为只有用户才能识别系统行为可能产生反作用的某些情况
  E. 因为开发人员测试的价值低于 UAT
  F. 因为系统必须根据用户需求和实际业务流程进行评估

1.0.2 简答题

1.如果贵公司要求您对一款新软件进行 UAT，以支持贵公司的销售活动，您会问哪些问题？
2.如果您的老板告诉您，您要进行 UAT 的开发项目已经延期，他希望您在开发人员完成开发的同时进行 UAT，您会作何反应？
3.为什么不直接让专业测试人员做 UAT 呢？毕竟他们有正式测试的经验，知道所有的技术。

1.1 什么是 UAT？

UAT 是用户验收测试（User Acceptance Testing）的缩写，通常是指在新信息系统（IS）引入组织之前进行的最终用户软件测试。用户验收测试的主要目的是确保新系统能够完成既定任务，并满足企业的要求。以下是 ISTQB 测试术语词汇表中对 UAT 一词的定义：“针对用户需求、要求和业务流程进行的正式测试，目的是确定系统是否满足验收标准，并使用户、客户或其他授权实体能够确定是否接受该系统。”

该定义的三个方面非常重要，将推动我们准备和实施 UAT 的工作：

UAT 要求进行 “正式测试”，这意味着测试应以结构化的方式设计和执行，从而为系统是否可接受提供客观证据。
定义中的测试涉及 “用户需求、要求和业务流程”。它没有提到任何特定的规格文件，但确实提请注意用户的需求，而且它超出了软件测试的范围，还包括业务流程。
定义中提到要满足 “验收标准”，即用户可接受的标准。

我们将在本书中探讨这三个关键概念，并将围绕验收标准和对用户需求及业务流程的正式测试来开发我们的 UAT。

虽然在进行 UAT 之前还要进行其他测试，但 UAT 的独特之处在于它是用户根据用户需求对已完成系统进行的第一次测试。开发过程中的测试是为了确保所交付的系统符合相应的技术规范，但信息系统与其业务用户之间的配合更为密切，只有从用户的独特视角才能发现系统在业务环境中的适用性问题。如果没有用户测试，一个经过开发人员和专业测试人员测试并通过所有测试的系统仍然可能在实际使用的第一关就失败。
这就是为什么 UAT 需要包括 “端到端 ”测试，以检验包括计算机系统在内的完整业务流程，而不是孤立地测试计算机系统。例如，在一个在线零售系统中，对订购流程的测试必须检查客户下的订单是否被接受，以及是否触发了正确产品的识别、包装和运输。但这些流程必须触发其他流程以完成交易，例如，订单生成并发送正确的发票，收到的付款与发票正确匹配以完成交易。虽然情况很简单，但这是一套相当复杂的交互流程，而且在初始订单和发票付款之间还有一个时间间隔，因此需要对交易进行完整的端到端测试。

1.2 为什么要测试 ISs？

软件是人类创造力和努力的最伟大范例之一。近几十年来，利用计算机和软件所能实现的发展是惊人的，而且这种趋势很可能会继续下去。软件和以软件为基础的系统，如信息系统，在商业生活中越来越普遍。随着信息系统与业务之间关系的复杂性和微妙性的增加，故障的影响也越来越大，我们所说的故障是指信息系统的实际功能与我们所需要的功能之间的任何不匹配。

在增加使用信息系统的风险的同时，必须更加重视风险管理。风险管理有很多方面，但在软件和信息系统领域，测试仍然是关键的风险管理学科之一。随着软件变得越来越复杂，测试必须更有效地发现问题和潜在问题，以便在系统失效前加以解决。

正如我们将在第 3 章中解释的那样，随着开发活动复杂程度的提高，测试也必须变得更加复杂。为什么？因为随着复杂程度的提高，人类在设计和实施过程中犯错误的风险也随之提高；因为人类活动与促成人类活动的系统之间的整合程度提高，造成不匹配的机会也随之增加；还因为信息系统的许多基本特征（如可靠性、可用性和安全性）都需要得到保证，然后才能相信系统能在实际业务环境中提供服务。

企业对信息系统的依赖程度越来越高，这也使得系统与业务流程之间的关系对企业的成功变得更加重要，在许多情况下，技术规范无法充分描述信息系统的预期行为。

开发过程中的大多数测试都是以确保交付的系统符合相应的技术规范为基础的，但信息系统与其业务用户之间的契合比工匠与其工具之间的契合更亲密、更关键；它更像一件 “量体裁衣 ”的服装，使个人每天都能穿着它舒适有效地工作。至于是否达到了这种合身程度，除了用户之外，任何人都无法确定。这就是为什么 UAT 不同于所有其他类型的测试，也是为什么用户必须参与其中。正是独特的用户视角才能发现业务环境中的适用性问题，如果没有用户视角，经过开发人员和专业测试人员测试并通过所有测试的系统，仍然可能在实际使用的第一关就失败。

1.2.1 我们需要测试的原因

我们生活在一个不完美的世界里，这是最基本的原因，也是我们难以创建完美 IS 的原因，更是测试它们的重要性所在。
可能有许多原因导致要求根本不存在或不完整、不及时：

发起人或最终用户往往难以想象他们的需求是什么。随着时间的推移和开发环境的变化，关于系统应该变成什么的想法也会发生变化。
即使需求在发起人或最终用户的头脑中很清晰，他们在传达需求时也会遇到困难。因此，需求文档中的内容可能并不反映他们的意图。
如果需求反映了发起人或最终用户的意图，开发人员可能会错误地解释需求，因为他们会把自己的假设带到开发过程中。
即使想象、传达、编写和解释正确，开发人员在编写代码以创建需求中描述的功能时也可能犯错，因为他们是人，因此容易犯错。

1.3 业务脆弱性

我们在业务中与 IS 的关系是独特的。在大多数情况下，系统不只是让我们的生活更轻松一些，它实际上是在执行我们的部分或全部业务流程，而一旦系统到位，手工操作可能会很困难，甚至不可能完成。企业与为其服务的信息系统之间的密切关系，使我们在首次引入系统或对其进行更改或更新时特别容易受到影响。"业务关键"一词通常用于对企业运营和提供服务的方式有重大影响的系统。这不仅仅是为了避免高调的失败，而是为了确保我们每次启动新的 IS 或改变企业与其 IS 之间的关系时，都能保证新的关系符合我们的预期和计划。

UAT流程是IS推出前的最后一次检查，也可以说是最重要的一次检查。信息系统在业务流程和业务价值交付中的嵌入程度越来越高，因此也变得越来越复杂。
信息系统的复杂性和业务关键性相结合，几乎没有出错的余地。

CHAOS 报告于 1994 年出版，对 8380 个项目进行了研究，以确定这些项目是否成功，如果不成功，失败的原因是什么。报告发现，成功、不成功或受损的项目比例如下：

在预算范围内按时完成并包含最初规定的所有特征和功能的成功项目--16%。
有问题的项目已完工并投入使用，但超出预算、超时，提供的特性和功能比最初规定的少 - 53%。
在开发周期的任何阶段取消或完成后未使用的受损项目 - 31%。

报告还指出了失败的原因，从最常见的到最不常见的依次列出：

需求不完整；
缺乏用户参与
缺乏资源；
不切实际的期望；
其他；
缺乏行政支持；
不断变化的要求和规格；
缺乏规划；
不再需要
缺乏信息技术管理；
技术盲。

2011 年版的《CHAOS 宣言》是 Standish 集团研究软件项目成功趋势的年度报告，该报告发现，与 1994 年的数据相比，有了明显改善，37% 的项目取得了成功，42% 的项目受到了挑战，其余 21% 的项目被视为失败。但值得注意的是，根据他们的研究结果，大多数项目仍然受到质疑或受损。
并非列出的所有原因都与 UAT 相关，但我们在规划和执行 UAT 活动时，应将相关原因放在首位。

NatWest 集团在对其软件进行例行更新后，客户受到了巨大的干扰，这就是在银行业等关键业务环境中，当系统不能按预期运行时可能发生的情况的一个例子。希思罗机场新的 5 号航站楼引入新的行李处理系统是最近的另一个例子。
希斯罗机场 5 号航站楼启用 2008 年 3 月，英国航空公司（BA）首席执行官威利-沃尔什（Willie Walsh）向下议院交通委员会作证，讲述了伦敦希思罗机场 5 号航站楼启用过程中出现的问题。他在证词中说
......由于在完成建筑计划方面的延误，我们在测试制度上做了让步，而我们在建筑测试方面的让步确实影响了 T5 航站楼在启用后最初几天的运行。
在投入使用的头五天里，运营问题给巴航造成的损失估计为 1,600 万英镑，共有 23,205 个行李被 “错接”。乘客所经历的大面积延误、未完工建筑的景象以及因延误和工作人员准备不足而造成的问题，也让英国航空公司、英国机场管理局（BAA）和英国政府感到尴尬（下议院交通委员会，2008 年）。我们在本书中的主要目的之一就是解释为什么会出现这类结果，以及如何避免它们。

周密的规划、使用经验丰富、能力出众的从业人员以及良好的项目管理都是成功的关键，但仅有这些还不够。我们需要无论在建模、解决问题、焦点小组、应急计划或任何其他方面花费多少时间和金钱，都无法像计划周密、结构合理和设计精良的 UAT 那样有效地告诉我们需要了解的情况。失败的直接代价（在 BA 的案例中，几天内就损失了 1,600 万英镑）以及关键服务（如通过银行支付账单）的微小中断对企业的持续影响都是巨大的，甚至足以导致大公司倒闭。

在现阶段必须认识到，尽管迄今为止普遍可用性测试被描述为可以验证新的信息系统是否有用并使项目免于出现严重错误的活动，但其他人可能并不这样认为。有时，UAT 被认为是一种昂贵的恶行，它会干扰 “业务照常进行”，分散重要人员的精力，并花费过多的时间和金钱。与发布未准备就绪的软件系统相关的高调失败案例的数量，确保了大多数组织至少会尝试进行验收测试，通常是通过强迫不情愿的用户参与一项他们觉得远远超出其 “舒适区 ”的活动。一定要这样吗？我们能否让 UAT 成为一项独立于构建系统的 IT 社区的工作，同时又与之合作，以达到最佳效果？本书的前提是我们可以做到这一点。

在开始进行 UAT 之前，我们需要确定所花费的成本和精力是值得的，我们还需要充分了解这项活动，以便用最少的资源做最好的工作。如果我们对 UAT 活动有足够的了解，能够有效地开展这些活动，那么参与 UAT 的各方就应该做好充分的准备，测试应该能够证明系统的实用性，浪费或延误的测试时间也应该很少。

1.4 UAT 过程

我们将在本书中介绍的过程将引导您逐步完成成功实现 UAT 的每个阶段。首先，我们将介绍足够的背景知识，让您了解流程的各个部分是如何组合在一起的，并为您提供进行测试所需的工具和技术。接下来，我们将介绍如何招募和准备一支高效的 UAT 团队。最后，我们将带您一步一步地了解 UAT 项目的各个阶段，以便您能在正确的时间以正确的方式应用所有工具和技术。基本流程如图所示，它以 ISTQB 术语表中定义的基本测试流程为基础，以便您将其与其他测试流程进行比较。

基本测试流程 (FTP fundamental test process) 有五个阶段。

测试计划和控制；
测试分析和设计
测试实施和执行
评估退出标准和报告
测试结束活动。

按照 ISTQB 对 UAT 的定义，每个阶段都代表了完成正式测试所需的一系列关键任务。这些阶段也代表了执行这些任务的顺序，不过我们会发现，在现实生活中，我们很可能需要在这些阶段之间移动，特别是当发现需要测试的额外功能或修复的故障需要重新测试时。FTP 可以应用于任何测试级别或整个测试项目。
对于我们的 UAT 流程，我们将在开始阶段增加一个额外的阶段，用于 UAT 的独特要素--招募和组建 UAT 团队--之所以独特，是因为 UAT 是由最终用户而不是专业测试人员进行的；它不是简单地作为专业测试人员要做的另一个测试阶段。UAT 团队的招募、发展和培训将在第 4 章中阐述。

第二阶段与 FTP 的 “测试计划和控制 ”阶段一致；它需要建立 UAT 项目，确定其目的和目标，确保我们有一个良好的测试基础，并计划所有剩余阶段。关键的输入是需求，这可能会有问题，第 2 章将解释我们如何确保有正确的需求来开展工作。第 6 章将详细介绍我们在这一阶段需要做的工作。

第三阶段与 FTP 的 “测试分析和设计 ”阶段一致；它需要根据需求生成测试，使用我们将在第 3 章解释的定义明确的流程。这一步的结果将是我们为实现总体目标而需要实施的一整套测试；第 7 章将对此进行详细说明。

第四阶段与 FTP 的 “测试实施和执行 ”阶段一致。此时，我们需要系统本身和所需的测试环境，以便成功执行所有测试。在测试过程中，我们将生成有关系统状态的数据，并将其报告给利益相关者；我们还将向开发团队报告发现的任何问题，以便进行调查，并在适当的情况下进行纠正。第 8 章将对此进行详细说明。

接下来的步骤与 FTP 的 “评估退出标准和报告 ”阶段一致。
在我们的 UAT 流程中，这是我们收集所有测试信息以确定是否达到验收标准的阶段，如果没有达到，系统还差多远，以及如何解决任何问题。有了这些重要信息，才能做出最终验收决定，并指导从 UAT 到系统部署的后续工作。第 9 章将对此进行详细说明。

最后一个步骤与 FTP 的 “测试结束活动 ”阶段一致，并将其扩展到考虑在 UAT 中发现的问题和部署决定的影响。在 UAT 中获得的宝贵经验和知识现在可以用来确定克服系统缺陷所需的 “变通 ”解决方案，指导最终用户培训和支持用户所需的用户文档，确定所需的技术支持类型和水平，以及规划部署机制和时间范围。第 10 章将对此进行详细介绍。

合同验收测试（Contract acceptance testing）

确定是否满足合同条件的测试，因此 UAT 是基于从第三方供应商处购买的系统的原始合同中定义的要求。

工厂/现场验收测试（Factory/site acceptance testing）

对于建成后需要安装的系统，可能需要进行工厂验收测试，以确定系统在安装前是否满足工厂建成后的要求。安装可能有其自身的合同条件，每个阶段的完成可能需要分阶段付款，特别是在安装涉及海外运输的情况下。在这种情况下，工厂验收通常以合同中的要求为基础，而现场验收则以在安装地点达到同一套要求为基础。

阿尔法/贝塔测试（Alpha/beta testing）

当要求难以确定或故意不明确时，可能无法进行传统的合同验收。在这种情况下，可以进行某种形式的 “使用中测试”。
在这种情况下，可以进行某种形式的 “使用中测试”。阿尔法测试将在开发人员的办公场所进行，而贝塔测试将在客户的办公场所进行。实际测试可能基于特定的活动，但更多时候是由用户自行决定。由于显而易见的原因，这种方式很少用于定制系统，但可能用于向市场发布商业产品。

现场测试（Field testing）
现场测试适用于在使用中部署的系统，如消防控制系统。在部署地点使用的系统元件要在部署环境中进行测试，以确保其适用性和足够的稳健性，并确保与基地设施的通信是有效的。

1.5 从 UAT 到服务交付

在整个信息系统的开发过程中，测试的重要性不容低估，正如斯坦迪什集团（Standish Group）所指出的那样，我们有充分的理由让最终用户尽早参与进来，并在整个开发过程中保持他们的参与度。有些系统是以这种方式构建的，但更多的系统并非如此--无论我们以何种方式构建系统，它都必须在某个阶段从开发过渡到使用。正是在这个过渡阶段，系统中的大多数问题才会显现出来（尽管根本原因可能发生得更早）。是在过渡之前和过渡过程中发现问题，还是在过渡之后带着问题生活，这是一个抉择。对于大多数系统来说，过渡阶段涉及从开发到用户的某种交接，其中涉及金钱或其他形式的交换，因此我们需要一种机制来实现过渡。

该阶段可能有几个步骤，但 UAT 将是一个关键步骤，它将促成其他步骤。在不同的组织中，过渡阶段可能有多种形式，UAT 步骤必须适应整个过渡过程，因此 UAT 也可以有多种形式。

然后，经过测试的系统将进入其他过渡步骤，其中可能包括运行一个试点项目，以确保系统在推出之前能够在小范围内满足业务需求。在某些情况下，用户需要接受培训并熟悉新系统。推广工作可能需要分阶段进行，以减少对现有系统和流程的影响。影响过渡机制的因素可能有很多，下文概述了其中一些。过渡机制的选择会影响到 UAT 的性质以及我们规划的方式。

1.5.1 管理向实际使用的过渡

试点项目

试点项目是一种缩小规模的实施，通常是在受控环境下，由专门挑选的人员进行。其目的是证明系统已做好实施准备，并找出可能影响全面推广的任何问题。

分阶段过渡

在试点成功后，可采用分阶段推广的方式逐步扩大业务规模。这样做的目的是提供一个机会，确认试点中发现的问题，并处理与规模有关的任何问题，例如后勤问题。

培训和熟悉

在推广工作完成之前，所有用户都需要接受培训。培训可以分阶段逐步进行。用户还需要在培训后熟悉系统，这样他们才不会丢失在培训期间获得的知识和技能，并在系统投入实际运行时能够合理地熟练掌握。这是一项与 UAT 不同的工作，尽管 UAT 肯定会增强测试人员的系统知识。如果用 UAT 来培训或熟悉系统，其结果不仅会减慢测试速度，而且会影响测试质量，因为没有接受过系统培训的测试人员很可能在设计和/或执行测试时出错。

参考资料

软件测试精品书籍文档下载持续更新 https://github.com/china-testing/python-testing-examples 请点赞，谢谢！
本文涉及的python测试开发库谢谢点赞！ https://github.com/china-testing/python_cn_resouce
python精品书籍下载 https://github.com/china-testing/python_cn_resouce/blob/main/python_good_books.md
Linux精品书籍下载 https://www.cnblogs.com/testing-/p/17438558.html

1.6 UAT与合同

在开发信息系统的过程中，我们通常会看到需求在整个开发过程中不断变化，因此交付给 UAT 的系统通常与最初需求说明中指定的系统有很大不同。

然而，如果存在合同协议，合同通常是以商定的需求规格为基础的，该规格在合同开始时就已确定，因此也在项目开始时确定。即使通过合同机制为变更留出了一些余地，但几乎不可避免的是，合同要求（合同验收必须以此为基础）并不能完全描述业务和用户期望的变化。

在项目结束时，统一测试的重要性。因此，UAT 必须将合同验收纳入更广泛的 UAT 工作中。
我们需要区分获取 IS 和开发 IS。当我们使用自己的资源在内部建立系统时，我们就可以说是在开发 IS，因此不需要合同关系（尽管有些组织可能会使用内部合同使业务的一部分能够从另一部分购买服务）。尽管发起人、业务经理、最终用户和开发人员之间的关系可能相对正式，但就可接受的结果达成最终协议的可能性始终存在。如果基础设施服务是从第三方获得的，或者第三方在开发和交付过程中发挥了重要作用，那么最终结果的灵活性就非常有限。

1.6.1 获取IS软件的四种方式

获取 IS 软件的四种方式我们至少可以通过四种不同的方式获取软件：

内部构建系统（利用自身资源）。
将开发工作外包给第三方（可以是离岸公司）。
购买现成的商业解决方案（COTS），根据我们的具体需求进行配置。
授权软件供我们使用（软件即服务）。

IS可以使用上述任何一种方式获取系统的软件部分，这将对如何进行 UAT 产生影响。

1.6.1.1 内部构建

在这一类系统中，需求可能在开发开始前就已记录在案，也可能在开发过程中逐步形成。
在极端情况下，可能根本就没有记录需求，或没有记录任何细节。在所有这些情况下，都需要做一些工作，使需求中的内容与当前用户的期望相匹配。
内部构建软件的主要优势在于主要利益相关者，包括: 开发人员、发起人、管理者和最终用户都可以提供咨询。

1.6.1.2 外包

通过外包开发获得的系统很可能是在远离使用地点的地方设计和开发的。在这种情况下，需求可能是由收购方、开发商或通过某种形式的合作编写的，但很可能与我们从内部开发中获得的需求类似。开发过程也可能与内部开发类似。
相似之处在于信息的可用性和关键利益相关者的可及性。发起人、经理和最终用户都应在现场，但开发人员将不在现场，这就增加了就需求、测试和开发活动其他方面进行沟通的难度。从本质上讲，这种获取方式与内部开发类似，但沟通渠道的可靠性可能较低，沟通线路通常较长，信息可能较难获取，获取所需的时间也较长。

1.6.1.3 COTS(Commercial Off-The-Shelf)

COTS( 商用现货或商用现成软件)软件涵盖的系统范围很广，从简单的生产力工具到复杂的决策支持系统。COTS 解决方案已经定义并以模块形式构建，因此实施工作包括选择模块、在可行的情况下配置单个模块以及安装。在这种情况下，购买者（赞助商）无法获得模块构建所依据的需求，必须通过改变业务流程来对解决方案进行必要的更改。

从某些方面来说，COTS 系统的 UAT 非常简单，因为这些模块通常在其他组织中使用，而且已经使用了一段时间。软件功能方面的问题应该很少。另一方面，与业务流程的配合可能并不理想，评估解决方案在业务环境中的运行情况以及用户对其方法的适应程度将是更大的问题。在这种情况下，UAT 与其说是测试软件，不如说是评估解决方案。

1.6.1.4 软件即服务

软件即服务（SaaS Software as a service）可用于提供采购组织不希望开发或托管在自己系统上的服务。服务是根据许可安排提供的，通常是许多组织都在使用的 “标准 ”服务；因此，在使用中应该是稳定可靠的。

在某些情况下，可以对服务进行定制，使其产生变化或附加功能，以满足特定的业务需求。
就 SaaS 解决方案而言，UAT 的主要重点是解决方案与组织业务流程的匹配性。

每当我们与第三方开展业务时，我们都会签订某种形式的合同，而在签订合同的情况下，合同验收对于合同的完成以及与此相关的任何付款都是至关重要的。但是，合同验收并不能实现 UAT 的所有目标，因此我们需要确保 UAT 包括商定的合同验收。这并不意味着 UAT 只限于合同验收；我们仍然需要制定计划，以实现所有其他成果，从而从 UAT 中获益。

1.7 UAT利益相关者

在实施过程中有许多利益相关者，他们来自企业、员工和客户、开发组织、任何供应商以及潜在的其他许多人。在一个理想的世界里，所有这些利益相关者都会被识别出来，并在每个阶段被咨询和告知进展情况。在现实世界中，这种情况几乎不可能发生，但我们仍然需要考虑至少某些利益相关者所表达的需求。
就 UAT 而言，最重要的利益相关者群体包括

发起人，即委托开发系统（并确定业务意图）的个人或团体；
负责从信息系统实施中实现预期业务效益的管理人员；
实际操作系统的最终用户；
开发人员和其他技术人员，他们负责实施工作，并将支持普遍测试工作。

这些利益相关者群体中的每一个都有自己独特的观点，都会影响到 UAT 工作，而且每一个群体都有自己的责任。每个小组都要提供特定的信息和服务，每个小组都需要信息才能成功履行职责。

1.7.1 发起人

发起人是签支票的人。在小公司中，发起人通常是公司所有者；在大公司中，发起人通常是某个级别的高管，他拥有为公司购买软件的预算。在这两种情况下，发起人的利益都是通过确保所购买的软件符合目的、对购买对象可用并满足验收标准来实现物有所值。

发起人通常会发起风险分析，并在此基础上确定测试的优先次序，然后由发起人做出发布决定。除非公司规模很小（个体经营者或合伙企业），否则发起人不太可能是进行测试的用户，但可能会参与 UAT 工作的规划。

发起人主要关注的是实现预期的业务效益，因此他们关注的重点是识别潜在的风险和成功的障碍。在进行风险分析后，发起人最感兴趣的是确定测试方案，在现实环境中对软件进行测试，并对软件的性能及其在推动关键业务成功参数（如收入、利润和成本）方面的有效性进行一些测量。

1.7.2 业务经理

业务经理是委托使用软件并实现预期效益的人，因此他们需要软件可用并能实现所宣称效益的保证。对于这部分人来说，关心的范围可能比简单的适用性更广，所定义的测试需要使围绕软件设计的业务流程能够在现实场景中被用户使用。这些情景将以发起人设定的成功标准为基础，并确保用户在现实的时间范围内与软件和业务流程在现实的水平上进行交互。

举例来说，可以利用现有系统实际处理过程中保存的数据，进行几天的交易，以确保交易结果优于首次使用时的结果。这种演练需要保存和储存原始交易的详细资料，还需要建立完整的系统，让用户作好适当的准备，用新系统重复这组交易并衡量结果。这项工作可能会超出正常运行测试的范围，但必须包括正常运行测试部分，以便达到预期的测试范围，并根据验收标准衡量结果。作为一种试验或试点形式的整体工作，可以实现有效的 UAT 以及新系统业务绩效的基准。
还有其他一些管理角色也将参与到 UAT 工作中。其中最重要的可能是质量经理，他主要关注交付系统的整体质量；或者是测试经理，他负责测试的整体质量和有效性，并为 UAT 团队提供建议和指导，使他们能够利用现有资源实现最佳的 UAT。

1.7.3 最终用户

最终用户是那些与系统直接交互的人，他们可以是组织内部的（员工），也可以是组织外部的（供应商和客户）。因此，最终用户群体并不一定是具有单一期望值的同质群体；

可能有多种观点和多组期望需要满足。由于最终用户直接与系统互动，因此由这一群体在用户界面上进行实际测试显然是合适的，为此应成立一个由尽可能多的最终用户观点组成的小组。该小组的主要职责是协助设计测试，然后执行测试并报告结果。然而，一个重要的次要角色是提出测试过程中出现的任何问题或见解，以便尽可能全面地探讨和记录用户对系统的看法。

对于最终用户来说，测试的本质是在实际环境中进行的，因此测试用例应复制现实的场景，使用现实的数据，使测试人员能够操作软件，因为软件将被用来实现 IS 的总体目标。
软件的最终用户可能来自任何专业，也可能没有任何专业。他们可能有丰富的计算机经验，也可能没有。他们的共同特点是，希望通过使用新系统来实现自己的业务目标。根据用户以前使用计算机的经验水平，特别是使用所测试的系统的经验水平，可以鼓励用户确定需要使用软件来实现特定业务成果的情景。那些有丰富经验的用户可以提出测试中感兴趣的情景，如那些将在测试中使用软件的情景。

用户测试的重要性：对系统特别具有挑战性的测试，特别容易出错的测试，以及涉及高水平用户交互的测试。这些场景将确保测试以真实业务活动为基础，同时还可以定义其他测试，以提供足够的测试覆盖面，并确保所有高风险操作领域都得到充分演练。

虽然最终用户应是 UAT 团队的主体，但业务经理和发起人也必须意识到，UAT 演练也应包括演练他们与系统的预期交互。在一个平衡良好的 UAT 团队中，所有三个角色都将在 UAT 工作中直接发挥作用，但即使无法做到这一点，也需要充分了解各角色之间的依赖关系。

1.7.4 开发人员和技术支持人员

虽然开发人员的主要工作在 UAT 开始时应该已经完成，而技术支持人员的工作尚未真正开始，但这两类人员可以为 UAT 的成功做出重要贡献。开发人员在帮助用户体验测试人员熟悉已构建的系统方面发挥着重要作用，他们将对用户体验测试期间提出的任何事件报告进行评估，以确定可能需要进行哪些补救工作。及时完成这项工作会对完成 UAT 所需的时间产生重大影响。技术支持人员将负责管理为 UAT 设置的任何测试环境，并使测试中的系统处于可服务和可用的状态。如果没有他们，整个测试工作可能还没开始就已经停止了。

1.8 小结

本章的主要目的是从最广泛的层面对 UAT 的内涵提供一个总体认识。本章提供了对什么是 UAT 的基本理解，并概述了 UAT 的独特作用和目的，为本书其余部分的内容做好了准备。

UAT 的定义指出了正式测试的必要性，以及验收标准和了解用户真实需求的重要性，而不是依赖于开发项目开始时编写的说明书。我们已经介绍了业务需求的基本概念，这将在第 2 章中进一步阐述，但我们需要记住，业务需求代表了构建系统的原因，而这可能与最初在需求规格中捕捉到的内容大相径庭。

我们已经说明了 UAT 在整个信息系统实施过程中的位置、UAT 在测试顺序中的位置（无论项目采用哪种模式）、由谁进行 UAT 以及在 UAT 过程中主要考虑谁的需求。我们还确定了系统建立或获取的方式可能对普遍测试产生的影响。

我们考虑了有证据表明信息系统在引入时或变革后经常失败的情况，并研究了使其容易发生潜在事故的信息系统的特点。对 CHAOS 报告的分析提供了令人惊讶和有趣的信息，说明了信息系统在多大程度上反映了最初的业务需求，并得出了关于让利益相关者参与整个开发过程的价值的重要结论。

为避免出现破坏性故障而进行的 UAT 是风险管理的一种形式，UAT 在建立用户信心、评估系统部署准备情况和准备推广方面也发挥着重要作用。

最后，我们确定了 UAT 的主要利益相关者及其角色，并概述了与 UAT 相关的主要成本领域。

读完第 1 章后，你应该了解 UAT 的目的和好处，了解谁参与了 UAT，了解 UAT 的成本并证明其合理性。

1.9 参考答案

1.9.1 选择题

1 B
答案 A 不正确。UAT 可能需要更长的时间，但通常比其他测试花费的时间少。
答案 C 不正确。UAT 根据业务需求（不一定包含在需求规格说明中）、业务流程和用户期望来评估系统。
答案 D 不正确。UAT 是正式测试。
2 B、D、E
答案 A 不正确。技术规范用于开发过程中的测试，但不用于 UAT，因为它们是从技术角度而不是用户角度出发的。
答案 C 不正确。业务需求是用户测试的部分基础，但它们可能没有在需求规格中完全定义。
答案 F 不正确。重复已进行的系统测试没有价值。
答案 G 不正确。虽然测试可以自动进行，但不应由开发人员设计，因为用户测试必须从最终用户的角度出发。
问题 3 C、D、F
答案 A 不正确。这可能是对的，也可能不是，但这不是用户进行 UAT 的原因。
答案 B 不正确。用户可能是也可能不是技术性能方面的专家，但这不是他们进行 UAT 的原因。
答案 E 不正确。开发人员测试是必要的，但它不同于 UAT，两个层次的测试都需要。

1.9.2 简答题

1. 如果贵组织要求您对一款新软件进行 UAT，以支持贵企业的销售活动，您会提出哪些问题？

进行UAT 的人员应该提出一些关键问题，尤其是在以前没有参与过该项目的情况下。例如

项目的总体目标是什么？
利益相关者是谁？
项目处于哪个开发阶段？
何时进行 UAT挂起？
项目是基于瀑布模型还是敏捷模型？
是否有与标准验收相关的合同？
利益相关者是否参与了项目，他们是否支持项目？
需求是否反映了当前的业务需求？

目标必须是建立一个能提高销售人员工作效率的系统，因此需要销售人员的参与。他们可能忙于销售，不想进行测试，但你至少需要让他们参与对话，了解他们的需求和期望。

如果你的老板告诉你，你将要做 UAT 的开发项目已经延期，他希望你在开发人员完成开发的同时做 UAT，你会作何反应？

与开发同步进行 UAT 不仅浪费时间和精力（因为系统很可能每天都在变化），而且还会带来虚假的安全感。即使 UA 测试成功通过，也不能保证最终交付的产品一定能正常运行。另一方面，让用户在开发过程中熟悉系统也有一定的价值--只要这不会妨碍开发！
理解 UAT 的价值和目的以及进入和退出标准对整个项目的成功至关重要。如果项目经理不了解这些限制的原因，就必须指出来。他们可能没有意识到，与开发同步进行会损害 UAT 的价值，而且总体上可能会造成更大的延误。

为什么不直接让专业测试人员进行 UAT？毕竟他们有正式测试的经验，知道所有的技术。

成功的 UAT 是将有关业务及其现有流程的专业知识、有关新系统及其运行方式的专业知识以及 UAT 专业知识结合在一起的结果。顾名思义，测试的目的是让用户接受系统，没有用户的参与通常是不可能实现的。测试专家在进行测试时也会出现偏差，因为他们很可能会测试他们所知道的系统工作方式，而不是用户的使用方式，原因很简单，因为他们缺乏重现用户操作的经验和知识。在某些情况下，如果用户无法进行 UAT，那么用户可以明确说明需要测试哪些内容以达到验收目的，然后让其他人进行测试，尽管这总是会影响 UAT 的质量。