0 简介

这是一本关于多种形式的用户验收测试（UAT）及其用途的。它汇集了有关测试、项目管理、质量管理、团队行为和完整的用户验收测试经验的其他相关材料，并将它们编织成一条牢固可靠的生命线，供用户验收测试新手指南或利益相关者参考。
本书是为满足三类不同人群的需求而编写的。

• 直接参与UAT的测试。对于这部分人，我们旨在为他们提供一本实用的、相当完整的软件信息系统测试指南。我们采用了循序渐进的方法，使他们在了解软件测试的过程中，掌握必要的术语（行话）和基本原则，同时了解 UAT 的实际挑战以及如何应对这些挑战。在这个群体中，我们不仅包括那些被要求进行测试的人员（通常是系统的最终用户），还包括那些委托进行系统和测试的人员（赞助商），以及那些有望实现预期效益的人员（业务经理）。本书将这一群体作为一个整体来论述，同时也指出了具体的挑战，并为其中的每个子群体提供了实用指南。

• 支持UAT的专业测试人员或开发人员，他们可能只是希望更好地了解 UAT 为何既重要又具有挑战性。对于这部分人，我们会解释可能需要什么样的支持以及为什么，并解释 UAT 在结构化测试和开发生命周期的整体背景下的位置。

• 专业人员，对他们来说，UAT 是必不可少的 “行业工具”；例如，项目经理、质量经理和测试经理。对于这部分人，我们试图将 UAT 放在测试、质量管理和项目管理的整体学科中。

最重要的是，本书旨在解释和探讨一项工作的意义，这项工作在有关测试的书籍中通常被忽视，在有关项目管理和质量管理的书籍中也经常被忽略，但它却是这些学科之间的桥梁，而且在某些方面，它是每一学科的基本实践表现形式。

0.1 内容

0.1.1 信息系统 (ISs: IS Information systems)

一般来说，我们购买软件是为了实现一些对我们有价值的事情，比如玩游戏、在证券交易所赚取第一个一百万，或者使我们的业务更有效地运行。在某些情况下，软件可以在没有人参与的情况下实现其目的（按下按钮除外），但在大多数情况下，软件与人互动的方式可以实现预期的结果。例如，空中交通管制系统可以向空中交通管制员提供有关飞机位置、飞行方向、速度等信息。空中交通管制员决定每架飞机的去向，以确保它们都安全地分开，而系统则将这些信息转发给飞机的飞行员。因此，整个系统的目的是保证飞机的安全，而要做到这一点，就需要训练有素的人员、空中交通管制软件、一些硬件和一些组织（例如，在空中交通管制员和飞行员之间提供通信）。虽然这是一个相当复杂的例子，但它具有信息系统的所有特征。最重要的是，它表明软件不是孤立运行的。用户所关心的不仅仅是软件是否完成了它应该完成的工作，而是系统作为一个整体是否实现了它的目的，以及作为用户，他们是否能够有效地使用系统（并且不会产生过大的压力）。

• 系统的特征

系统是相互依存的组件的集合，这些组件按照计划相互作用，以实现特定的目标。

系统的关键在于 “整体大于部分之和”。因此专注于某一目标的团队所能取得的成就，要远远大于团队成员各自所能取得的成就（如果他们不是一个团队的话）。

相互依存意味着每个部分都至关重要。

只有当系统具有明确的目标时，它们才会表现得像系统。

• 信息系统的特点

信息系统是一个由人、计算机、组织、流程和单一目的（业务意图）组成的系统。
正是业务意图使这个集合成为一个系统。各组成部分相互依存，因此计算机和人类都无法单独实现业务目标。组织和流程对交互进行管理。
当我们构建或测试一个信息系统时，我们必须考虑所有的组件、交互以及共同的业务意图。下图提供了一个企业信息系统的示意图。

在商业环境中，我们的业务流程涉及人类使用信息来增加商业价值，例如超市收银员将顾客购买的所有商品的零售价值相加，准备账单让顾客付款，接受付款并提供收据。所有这些工作都可以人工完成，但为了提高效率，也为了在做出其他决策（如何时补货）时能将每笔交易的所有细节作为信息处理，这一过程通常都是自动化的。在这个例子中，整个流程的有效性可能是通过如何快速准确地处理单个客户的购物来衡量的。这里同样要衡量的是整个流程，而不仅仅是软件所做的那一部分，因为这才是为企业增值的流程。从用户的角度来看，收银员在收银台前一坐就是几个小时。对他们来说，最重要的是收银台的高效运行是可以经常实现的，而且不需要付出很大的努力。如果扫描仪拒绝扫描某些物品，输送机经常出现故障，或者出具的账单偶尔出现错误，那么对用户的影响无疑是增加压力。

因此，本书的主题是测试 IS，而不仅仅是软件，而且还要考虑所有参与系统构建、操作和使用的人员的所有观点，以实现其预期的商业利益。

0.1.2 测试IS

当我们进行UAT测试时，我们测试的是一个系统，而不仅仅是一个软件，这意味着我们真正感兴趣的是了解整个 IS 是否能正常工作。如果系统没有按照我们的预期运行，原因可能有很多，其中可能是软件没有发挥应有的作用。但也可能是软件工作得非常完美，而系统的其他方面出现了问题。

为了尽可能清楚地说明这一点，我们需要简要了解一下信息系统是如何创建的--不是详细介绍，而是作为一个高层次的概念。

这不是一个细节，而是从高层次来看待 IS 从最初的想法到最终实现的过程。这种高层次的视角通常称为生命周期。
一个信息系统的生命周期就是它从最初设想到报废所发生的一切的模型。下啊图显示了一个简单的信息系统生命周期示意图。
这个生命周期模型所描述的是这样一个过程：从需求（描述系统需要做什么的手段）开始，经过一个模糊而朦胧的阶段--开发（我们只是偶尔才会深入研究，而且只有在我们绝对需要了解它的时候才会这样做），然后到达 UAT，这是系统 “发布 ”投入使用前的最后阶段。我们将在第 2 章中仔细研究需求是如何产生和记录的。

这个生命周期的一个主要特点是时间、精力和金钱的平衡。生命周期中最受关注的部分通常是初始开发，尽管这只占总支出的 20%左右。系统生命周期的大部分时间是在使用、维护、修改和修理中度过的。系统在开发结束时越好，生命周期中的大部分成本就可能越低，而开发和生命周期其余部分之间的 “守门员 ”就是统一测试。

有效的 UAT 可以避免过高的维护成本（例如修复缺陷），降低修改成本（例如提高系统的可用性），延长系统的使用寿命，从而为开发的原始投资带来更好的回报。

UAT 是初始开发与系统生命周期之间的最后前沿，在这个前沿之外的世界里，你的新 IT 系统可能会让你的生活更轻松，预见到你的需求，节省你的时间，并总是能产生很好的结果；也可能是一个噩梦般的世界，在这个世界里，使用你的 IT 系统是一场噩梦，什么功能都不能用，系统似乎决意要阻止你完成工作，输出结果也永远不是你想要的。

任何习惯于使用 IT 系统的人都知道，这两个 “平行世界 ”实际上非常接近。

要预测系统投入运行后您会被传送到哪一个世界并不容易。这就是 UAT 的作用--及时提供未来的一瞥，以避免灾难的发生（如果你预见到灾难的发生），并为用户提供使用系统的最佳开端。

0.2 UAT测试的作用

UAT测试是从用户和其他利益相关者的角度对所建立或购置的信息系统进行的测试。UAT不仅仅是对软件的测试，也不仅仅是对系统的功能、性能、可靠性和安全性以及可用性的测试。这并不意味着 UAT 不关注这些领域中的任何一个或所有领域，而是说其主要关注点和绝对重点是，当指定用户操作系统时，系统是否能带来预期的业务效益。在开发过程中，上述所有专业领域都会或肯定应该进行过测试。但是，这些测试都不能回答 "系统是否符合目的？用户体验测试明确地回答了这个问题，即根据建立或购置系统的理由，将最终用户作为测试者，并尽可能利用为支持他们使用系统而准备的用户文档，对系统进行测试。这不仅仅是以某种随机的甚至是结构化的方式对系统进行演练，还需要使用系统来支持业务流程，从而利用现实（或实际）的场景、数据和操作来实现价值。UAT 是我们在没有实际承担系统投入使用风险的情况下最接近 “真实情况 ”的做法，也是使我们能够理性判断是否承担系统投入使用风险的做法。

0.3 UAT的成本和收益

UAT 是一项昂贵的工作。除了实际测试的硬性成本外，我们还必须考虑到开发资源在系统推出之前被占用的额外时间，以便将其释放到其他项目中。
UAT 直接成本的最大组成部分是

• 将最终用户人员从其正常工作中抽调出来计划和执行 UAT 的成本。除工资成本外，还损失了员工本应创造的收入或延迟实现收入。
• UAT 团队（以及随后所有最终用户）的培训或熟悉成本。
• UAT 的测试环境成本。

0.4 UAT 的价值

• 原因 1：风险管理--避免代价高昂的失败

美国的交易系统无法应对大量的交易，其失败造成了卖方的恐慌。1987 年 10 月 17 日星期五，美国证券交易委员会（SEC）对内幕交易进行了一系列调查，伦敦股市也因恶劣天气而关闭，美国股市的持续增长似乎要戛然而止。在 “黑色星期一”，远东市场开始崩盘，经过一个周末对股票的担忧之后，投资者大量抛售股票，市场上出现大量卖单，交易系统崩溃。结果，美国股市的价值在一天之内被抹去了 20% 以上。

新的计算机系统意味着 50 万本英国护照无法按时签发。1999 年夏天，英国护照管理局引进了一套新的西门子计算机系统，但未对其进行充分测试，也未对员工进行如何使用该系统的充分培训。与此同时，由于法律的修改，16 岁以下的儿童出国旅行时需要自己的护照，因此对护照的需求量异常之大。因此，内政部不得不为错过的假期和员工加班支付数百万美元的赔偿金。

伦敦救护车服务局的新紧急调度系统发生内存泄漏，导致 46 人死亡。1992年以前，办公室工作人员决定应向何处派遣救护车，而使用计算机系统似乎可以提高效率。新系统投入使用几个小时后就开始出现问题。造成系统主要故障的根本原因是一小部分代码的内存泄漏。即使在不再需要的情况下，系统仍保留了文件服务器上有关事件信息的内存。与任何内存泄漏一样，在足够长的时间后，内存会被填满，从而导致系统失效。第二天，救护中心又改回了部分手动操作的系统，八天后，当计算机系统完全停止工作时，救护中心彻底关闭了计算机系统。在这九天里，如果救护车能够及时赶到，可能会挽救多达 46 人的生命。

微软公司急于发布有缺陷的游戏机，以在竞争中保持领先。2005 年 11 月，微软发布了 Xbox 360 游戏机，仅次于任天堂的 PlayStation。很快，人们就发现 Xbox 存在许多技术问题和故障；其中最著名的是游戏机表面闪烁的一系列红光，后来被昵称为 “红色死亡之环”。直到 2007 年 7 月 5 日，微软才发表了一封公开信，承认游戏机存在问题，并宣布为每台出现一般硬件故障的 Xbox 360 游戏机提供为期三年的保修服务。据称，设计问题是管理决策和游戏机发布前测试资源不足的最终结果。

并非所有的基础设施服务都以高调的失败告终；许多基础设施服务都非常成功，在较长的使用寿命内没有出现任何问题，但在统计学上，基础设施服务出现故障的可能性确实相对较高。

1995 年，斯坦迪什集团根据对大量软件系统失败案例的研究发表了一份报告。该报告被称为 “CHAOS 报告”（斯坦迪什集团从未透露过该缩写词的含义，只承认组织内少数人知道），其中包含一些令人震惊的统计数据，例如，只有 16.2% 的信息系统项目能按时按预算完成。更糟糕的是，项目的完成往往需要大大降低这些系统的原始规格。这些统计数字涉及系统故障，但不一定与 UAT 有关，但 CHAOS 报告分析了这些统计数字，并确定了导致故障的关键因素。这些因素表明，在系统开发的某些方面存在问题，而 UAT 可以揭示这些问题，如缺乏用户参与和需求定义不清。

最初的 CHAOS 报告发表于很久以前，但 Standish Group 在过去几年中重复进行了研究并公布了最新结果。随着敏捷项目模式的引入以及人们对导致项目失败的问题有了更深刻的认识，研究结果也在逐步改善。斯坦迪什集团董事长吉姆-约翰逊（Jim Johnson）表示："今年的结果代表了 CHAOS 研究历史上最高的成功率。我们显然对项目成功或失败的原因有了新的认识。尽管研究结果比 1995 年的原始数据有了显著提高，但令人警醒的是，即使取得了这些前所未有的成果，研究中仍有 63% 的项目没有取得成功。尽管其他研究人员批评斯坦迪什集团对其数据提供的背景信息很少或没有提供背景信息，例如没有区分超过最后期限就意味着失败的项目和可以轻易容忍合理超期的项目，但 CHAOS 报告还是提供了一份非常有用的清单，列出了导致项目失败的关键因素，对这些因素的了解和应用可以使任何项目受益。我们将在第 1 章中探讨其中一些因素以及如何从中吸取教训。

当然，避免高调的灾难甚至是低调的失误并不仅仅是执行有效的 UAT。当我们开始进行 UAT 时，失败的种子不仅已经播下，而且很可能已经发芽；但是，计划周密的 UAT 仍有可能在灾难真正发生之前凸显其潜在的危险。这是进行 UAT 的一个重要原因，但不是唯一原因。

• 原因 2：建立信心--实现预期的业务效益

如果我们购买了一些昂贵的软件，或者一些软件的设计目的是为我们的业务做一些非常重要的事情，那么在接受它之前，我们需要确定我们已经将它不能完成我们购买它的工作的风险降到了最低。这不仅仅是重复避免灾难，而是一种 “良好的内务管理”，确保我们已经解决了开始使用该系统时可能出错的所有问题。

其中许多可能只是小问题，但累积起来就可能成为服务中的问题，而在开发过程中进行的测试可能没有解决其中一些小问题，这些测试的目的是确保系统符合规范，而不是确保用户能够有效地使用系统。在第 3 章中，我们将介绍如何使用基于风险的测试将风险降至最低。

我们还需要确保使用软件的人员能够获得预期的生产率或其他收益，并确保企业能够获得我们预期的效率或其他改进。为此，我们需要在现实环境中使用该系统，并举例说明在哪些情况下该系统有望增加价值，如简化流程或降低生产成本。这种测试将基于对如何使用系统来获得业务效益的理解，并建立一个现实的 “试验 ”来检验系统是否能够带来这些效益。我们将在第 6 章介绍如何进行此类测试。

• 理由 3：评估--使业务流程正确

除了确保系统不仅能完成其应该完成的工作，而且还能为我们的员工所用之外，我们还需要让最终用户有机会以他们同意的任何方式使用该系统，以使其发挥效用。用户需要检查系统行为，将其作为整体业务流程的一部分，并按照商定的方式使用系统。我们不仅要把系统当作 IS 来对待，测试其在预定业务交易通过时的行为，而且还要测试最终用户是否能够按照使这些流程有效运行所需的方式来操作系统。

UAT 的另一个好处是，在确定系统是否符合目的的过程中，必然要将系统的行为与用户的期望进行比较。不过，一个有价值的次要结果是，通过比较可以详细了解系统与预期的匹配程度。这种比较可以作为评估系统当前能力和业务价值的基础，反过来又可以用来支持未来的开发或改进战略。这使我们能够准确了解系统的优缺点，并评估投资开发的性价比和提高业务价值的潜力。

• 原因 4：准备工作--评估服务准备情况

最后，我们要确保软件适合发布到企业中，并且企业已经准备好使用它，因此我们需要评估准备情况。在完成基于风险、收益和可用性的测试后，我们可能会发现一些需要解决的问题、一些需要纠正的缺陷或一些需要解决的其他方面（如培训）。这些问题的结合将影响到系统何时才能完全准备好供用户使用。就绪程度这一方面涉及系统在运行中的稳健程度、与预期的吻合程度、有多少 “变通办法 ”是必要的，以及其他一系列可能影响系统是否能够为企业带来价值的因素。这通常是一个讨论和协商的问题，最终决定是否发布软件。第 9 章将探讨我们可以建立哪些机制来尽可能客观地做出这一决定。如果我们提前考虑到 UAT 这方面的问题（我们也应该这样做），我们就可以定义一套验收标准，用来决定是否发布软件，从而避免在这一阶段可能出现的冲突。

在这种情况下，有一点很重要，那就是 UAT 有别于培训、熟悉和其他所有的推广工作。它有自己的一系列目标，如果由没有准备好、没有经过培训、不熟悉使用情况的最终用户来进行用户测试，就会严重损害这些目标。

如果由没有准备好、没有经过培训、不熟悉系统的最终用户来进行用户测试，就会严重危及用户体验。尽管如此，UAT 的经验将是一个首屈一指的学习机会，在 UAT 过程中获得的经验可以在培训、熟悉和准备最终用户有效使用系统的过程中加以利用，包括处理 UAT 提出的任何问题，而这些问题的 “变通办法 ”已经确定。

软件的成本:软件的成本总是难以确定，但通常为购买软件而提出的理由--软件可以节省人事费--在大多数情况下确实是站不住脚的。软件从开始使用到报废的整个生命周期内，其购置和运行成本都很高。

软件的第二个主要特点是缺乏灵活性。我们想象中的软件是非常灵活的，我们可以随意改变它，但事实远非如此。虽然更改一行代码非常容易（从这个意义上说，代码的更新几乎不需要任何成本，因为它是电子的，而且存在于一台可以即时更改其内容的机器上），但要以一种不会产生负面影响并满足我们所有期望的方式更改软件应用程序的行为却非常困难。实际上，软件作为实现商业目的的工具是非常不灵活的。一旦安装，修改的成本和影响可能会很高，而且往往会很高。

第三，软件不可见。它没有活动部件，因此我们看不到它在运行。当软件停止工作时，它不会像物理系统那样 “崩溃”。计算机通常会继续运行并做一些事情；它们只是停止做我们希望它们做的事情。这可能会让人非常沮丧，尤其是当我们发现软件根本没有出故障，只是对一些意外输入做出了反应。

这三个特点使软件成为一种难以使用的媒介和难以操作的商业工具，除非它能完全按照我们的期望运行。

软件作为一种媒介的神秘性使得部署包含软件的信息系统具有很大的风险，而统一测试是我们为用户群管理这种风险的最佳机制。我们已经说过，UAT 值得一做的主要原因是，它可以帮助避免处理失败和软件验收后修改的一些费用。失败的潜在代价可以从案例研究中判断出来，但在商业环境中，失败的代价总是比预期的要高，因为在业务流程和信息系统之间的紧密关系中，失败会造成很大的影响。

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

0.5 利益相关者--本书的读者对象

本书的读者对象是由 UAT 的主要利益相关者共同组成的群体：

• 赞助商（通常是决定购买某种软件来提升业务的所有者或高级经理）；
• 业务经理，负责确保信息系统实现预期的业务效益；
• 最终用户，他们最关心的是如何与系统互动以完成任务；
• 专业开发人员和测试人员，他们关注的是为 UAT 提供最有效的支持；
• 流程、实践和标准的管理者，他们将关注如何利用最佳实践使 UAT 成为一个具有成本效益的流程。

在上述每个群体中，都可能有一些人完全没有测试经验，对他们来说，加入 UAT 团队是一个令人生畏的前景。
如果你属于这类人，那么这本书就是为你准备的，它将直接与你对话：

• 尽可能使用非技术性语言；
• 假定你完全没有测试方面的知识；
• 以循序渐进的方式明确你需要做什么；
• 提供案例研究、示例和练习，让你至少练习部分任务。

如果您是发起人，正在购置新的 IS，本书将明确 UAT 在确保您获得所期望的系统方面的作用，还将帮助您了解 UAT 如何与您的整体规划相匹配，以及它在培训和支持新 IS 不可避免地带来的工作实践变化方面有哪些益处。

如果您是业务经理，负责系统的有效运行以实现业务效益，那么本书将解释如何定义和衡量这些效益，以及如何确保 UAT 能够为您提供所需的信息，为系统在您的业务部门投入使用做好准备。

如果您是负责测试信息系统的最终用户，本书将为您提供成为一名有效的统一用户评估测试员所需的所有工具和技术。

如果你是 “感兴趣的专业人士”，可能需要支持 UAT，那么你会发现本书清楚地阐述了 UAT 世界如何以及在何处与专业开发人员和测试人员的工作相衔接，以及如何最好地管理这种衔接和支持 UAT 活动。

最后，如果您作为测试经理、质量经理或项目经理，其职责涉及管理和加强某种实践，您会发现本书作为一本关键技术、方法和工具手册非常有用。例如，希望改进 UAT 实践的质量经理可以在本书中找到对 UAT 的全面回顾，从中提炼出最佳实践，然后根据组织文化、规模和预算进行定制。

0.6 如何充分利用本书

本书的两个主要前提是

• 我们可以而且必须使 UAT 有效，以降低 IS 表现不佳的风险和成本。
• UAT 的收益大于成本。

为了解释为什么以及如何实现这些结果，本书的结构如下所述。
前三章提供了所有背景资料，并说明了逐步开展 UAT 的理由：

• 第 1 章--UAT 的重要性；
• 第 2 章--业务需求
• 第 3 章--UAT 的测试基础。
  接下来的两章专门讨论创建、组建、培训和部署一支有效的 UAT 团队的实际问题：
• 第 4 章 - UAT 团队；
• 第 5 章--作为过渡的 UAT。
  其余各章详细介绍了循序渐进的实用方法：
• 第 6 章--UAT 准备--规划；
• 第 7 章 - UAT 的测试设计；
• 第 8 章 - 实施测试
• 第 9 章 - 评估系统；
• 第 10 章 - UAT 之后

我们衷心希望本书的所有读者都能从头到尾读完这本书，并从中获得足够的乐趣和收获。不过，初次接触任何此类书籍都需要制定某种计划，以便在最短的时间内获取最大的价值，从而提供一个起点，开始对内容进行更详细的探索。阅读本书的初始路线自然取决于你的起点。
强烈建议所有读者阅读第 1-3 章，作为一般背景知识，并为本书后面的实践方法做准备。
负责管理 UAT 团队的人员应该阅读第 4 章和第 5 章，所有被选中参与 UAT 的人员通过阅读这两章，可以了解 UAT 团队所需的技能和运作方式。
我们鼓励所有读者阅读第 6-10 章，尽管有些章节与某些群体的关系更为密切。在这些章节中，我们考虑了所有利益相关者，并适当标注了对某个群体特别重要的信息，以指导您进行初步阅读。

0.7 检查表

无论您采用哪种方式阅读本书，您都将在第 6-10 章的指导下完成 UAT 的所有关键步骤。通过阅读，您可以了解关键步骤是什么，以及为什么要这样安排。

为了帮助您应用本书所学的知识，附录 A 中为 UAT 的所有主要步骤提供了一套核对表。这些核对表的目的是按逻辑顺序列出关键步骤，不加任何解释，同时还指出在书中哪些地方可以找到辅助材料。我们希望当你在自己的项目中应用分步法时，这些清单会对你有所帮助。

0.8 案例研究

我们将在全书中使用案例研究、示例和练习。案例研究用于提供有据可查的真实案例，以说明我们所讨论的内容；实例将为您提供如何使用我们所介绍的技术、方法和途径的实用指导；练习将为您提供尝试使用某些技术的机会。

除了这些内文内容外，我们还在每章末尾提供了一些选择题，用于检查你是否理解了本章的主要观点，我们还提供了一些你可能想思考的问题。这些问题提出了作为用户验收（UA）测试员可能会面临的一些问题和挑战，并为你提供了思考的机会。

测试人员可能面临的一些问题和挑战，让你在应对项目中的实际挑战之前有机会思考这些问题。我们在附录 B 中提供了所有练习的答案，你可以对照我们的答案来检查自己的答案。各章末尾的开放性问题没有正确答案，但我们提供了自己对这些问题的一些想法，如果你想读，可以阅读。我们并不声称这些是对问题的最佳答案，但它们是我们从自己的经验中总结出来的。

最后，在进入第 1 章并开始介绍 UAT 流程的第一步之前，我们将向您介绍一家名为 HMF 的小型假想公司，该公司正在收购一家 IS。我们将主要利用 HMF 案例研究来围绕我们提供的更重要的示例，尤其是第 6-9 章中的示例，以提供思想的连续性，并希望帮助您了解如何在该方法的每个步骤中积累信息，以便在以后的阶段中使用。

HMF 和 EXCELSIOR 系统 HMF 是一家基于网络的保险公司，为广泛的家庭和商业风险提供低成本的保险解决方案。HMF 通过收购较小的专业保险供应商并将其专业产品整合到自己的平台上，迅速发展了自己的产品范围。

最近，HMF 实施了一项合理化计划，以确保员工数量和技能达到最佳状态，以适应整合后的产品范围，并统一整个业务的流程。合理化工作表明，经过多次收购和整合，会计和人力资源（HR）实践已变得支离破碎，因此决定开发一套信息系统，以支持整个业务的通用会计实践，其次是加强人力资源流程的整合。信息系统的核心是一个名为 Excelsior 的新软件包，指定在现有的 HMF 服务器上运行。

Excelsior 会计系统是一个定制的会计解决方案，以一系列标准会计模块为基础，配置在一个支持所有模块服务全面集成的架构中，同时还能将选定的人力资源应用程序纳入其中。开发工作将以渐进的方式进行，以便在进一步增加复杂性之前完善基本功能。在目前的开发阶段，可提供的会计功能包括

• 通用会计
• 采购订单
• 合同
• 付款。
  此外，还将提供以下人力资源服务：
• 缺勤（预订休息日、病假和其他缺勤，管理团队的缺勤申请）；
• 开支（提交开支表格和收据，以便付款和批准与团队有关的开支）；
• 更改联系方式和银行信息，更新人力资源部门掌握的个人详细信息；
• 内部采购订单（申请采购和批准与团队有关的采购，标记采购订单已完成）；
• 培训（申请培训、参加在线培训、记录培训出席情况）
• 行政管理（支持和管理功能）；
• 工作（搜索、列出或申请空缺职位，批准与团队相关的申请）。

每个模块都有一个与 Excelsior 相关的独特标题，例如 Excelsior - 培训。
每项服务都列在 Excelsior 主页的主菜单上，但某些模块的访问权限受到限制。用户可根据自己的角色登录配置文件访问服务。如果访问权限被拒绝，则会出现一个链接，允许用户向相关人员申请访问权限。
希望 HMF 和 Excelsior 以及各章末尾的案例研究、示例、练习和问题能够帮助您将这些想法付诸实践，并使您能够深入了解实际的 UAT 操作。