5 UAT的位置

在本书的这一中心章节中，我们将从准备工作的细节中抽身出来，在沉浸于我们的分步方法的细节之前，先从大局出发。UAT 在更大的计划中处于什么位置？它的核心功能和属性是什么？它的总体贡献是什么？
本章涉及的主题

• 作为一系列过渡的 IS 生命周期
• 过渡规划
• 作为过渡阶段的 UAT
• 作为事件的 UAT 和作为过程的 UAT

5.0 习题

您正在实施的项目正在采购一套基于 COTS 的应用程序，其配置可满足贵公司的需求，但在功能方面存在一些已知的潜在差距。计划提前 12 个月实施，并将在 UAT 前 1 个月成立 UAT 小组。

• a. 作为 UAT 小组组长，你被要求审查计划。您会给出哪些反馈意见？
• b. 作为 UAT 小组指定的最终用户测试员，您有什么建议？

5.1 生命周期由一系列转换组成

在引言中，我们介绍了 IS 生命周期的概念，这里我们再现生命周期模型。该模型提醒我们，UAT 不仅是开发的结束，也是服务使用期的开始。生命周期模型让我们清楚地了解到事物随着时间的推移是如何变化的，以及工作和成本的去向，这些都是需要牢记的重要内容。
但是，UAT 也是另一个关键转变的把关人：它标志着软件所体现的理念的所有权从开发团队回到了用户手中。还记得早些时候在需求和开发之间发生的另一个棘手的转变吗？实际上是从用户理解他们需要什么到开发人员理解他们需要什么的过渡，使用 RS 作为翻译文件和交换的符号。
因此，看待生命周期的另一种方式是将其视为一系列通过事务从一种状态到另一种状态的过渡。RS 的生成是第一个事务；UAT 将是第二个事务。
未来还有更多重要的过渡。一旦系统得以实施，初期问题得到解决，系统将转入例行维护，这就需要在开发团队和维护团队之间进行交易。

随后会有一段增强和改进的时期，发起人将在用户群的帮助下寻求从信息系统中获取最大价值。一旦实现了这一目标，就会发生进一步的过渡，将所有权从发起人转移到业务部门，由业务部门与维护团队共同管理任何进一步的改进工作。请注意，每个过渡都涉及两个群体之间的交换：

所有这些都说明，这些过渡点是项目中发生变化、释放价值和可能出现问题的点。它们是整个信息系统生命周期中的关键点。
我们之所以对过渡点特别感兴趣，是因为它们有可能引发问题。这也是我们为什么要精心准备的原因之一。我们已经解释了从想法到 RS 的过渡要花费多少精力（即使如此，过渡也很少能顺利进行），在第 4 章中，我们提到了培训作为准备 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

5.2 计划过渡UAT

我们将重点关注的关键过渡，但值得简要指出的是，我们已经确定的一系列过渡都需要精心准备。在整个生命周期中，需要持续开展两项活动，以促进和鼓励最终用户在观念上的艰难转变，尤其是他们必须面对的转变：这两项活动就是沟通和培训。
这里不适合对这两项活动进行详细讨论，只能说这两项活动都很重要，需要进行详细规划，以确保在正确的阶段开展正确的活动。

附录 C 提供了一个稍为详细的视角，介绍了如何在整个项目中将培训作为一个与 UAT 相关的改变认知的过程来管理。类似的沟通计划也是一种宝贵的工具，不仅能让各方了解情况，还能为下一步做好准备。

5.3 过渡阶段的可用性测试

可用性测试的最终目标是了解系统的当前状态，要么我们知道系统已经准备好部署，要么我们了解系统准备部署所需的条件。不成功的 UAT 意味着系统部署将面临危险。
UAT 是开发团队对项目的所有权与业务部门对系统的所有权之间的关键转换点，因为它为整个在役使用阶段（可能需要 10-20 年）的系统提供了价值。
下图展示了作为过渡阶段的 UAT。过渡阶段需要准备，因为它们涉及到观念和流程的改变--人类认为这种改变是困难和紧张的--因此我们需要在一段时间内为它们做好准备。统一测试的准备工作是实现有效统一测试的重要组成部分，而这反过来又直接影响到所接受系统的质量。我们不仅要验证系统的质量，还要验证系统为用户群提供服务的情况、实现业务目标的情况以及应对未来变化和更新的情况。
请记住，生命周期中的 “在役使用 ”约占生命周期总成本的 80%，而成本的高低取决于两个参数：

• 已验收系统的质量（因为这是今后所有更改和开发的基础）；
• 最终用户群体的接受程度（因为这将对最终实现多少商业利益产生影响）。

我们知道，最终用户的认同对信息系统的成功非常重要，但最终用户的认同却很难界定和实现。我们需要让用户群体愿意接受系统的所有权（瑕疵和所有问题），并承诺与系统一起实现业务需求。如果没有这种认同感，每一个小缺陷都可能成为 “障眼法”，未来的变革也很难实现。

5.4 作为事件的 UAT 和作为过程的 UAT

为了使 UAT 过渡顺利有效，需要尽早开始准备工作。需要对从未测试过系统的最终用户进行培训。
在这种情况下，培训内容不仅包括他们不熟悉的领域，还要求他们以不同的方式思考他们所使用的系统。这就需要改变观念，而这种改变不可能在 UAT 开始前的一次性培训课程中实现；需要在一段时间内进行温和的介绍、强化和逐步推广，从而使观念的改变不仅仅是表面的。我们将在接下来的几章中看到，最终用户还需要为 UAT “活动 ”做准备，包括规划、分析和设计，以及熟悉系统、业务流程和一些工具，这样才能有效、高效地完成测试执行和报告阶段。

UAT “事件 ”实际上是一个在生命周期早期就开始的过程，如果要使 UAT 取得成功，许多关键决策和准备行动都需要在 “事件 ”发生之前进行。

在我们逐步推进 UAT 过程的各个阶段时，必须牢记我们所描述的行动和培训的时间安排。关于何时应开始 UAT 流程，有许多观点，但我们将介绍的流程至少与开发流程同等重要，而且我们认为应同时开始。它的进展速度会慢一些，消耗的资源也会少很多，但它和培训一样，应该自始至终与开发并行。

5.5 小结

本章从整体上将 UAT 视为一个过渡阶段和一个需要及早准备的连续过程。读完本章后，你应该能够回答以下问题：
如何将信息系统开发视为一系列过渡？

• 作为关键过渡阶段，UAT 的作用是什么？
• 在 UAT 过渡期间，各小组之间需要进行哪些交易？
• UAT 过程应何时开始？

5.6 参考答案

我们对需要考虑的问题的答复 您正在实施的项目是获取一套基于 COTS 的应用程序，其配置可满足贵公司的需求，但在功能方面存在一些已知的潜在差距。计划提前 12 个月实施，并将在 UAT 前 1 个月成立 UAT 小组。
a. 作为 UAT 小组组长，你被要求审查计划。您会给出哪些反馈意见？

这里有一些挑战。COTS 方法意味着合同验收和内部验收，而且必须在合同验收时付款，因此必须彻底。团队需要尽快熟悉 COTS 模块，并在 UAT 之前牢牢掌握需求，这就需要尽早进行培训，并在 UAT 之前至少三个月开始需求审查和学习。这都是风险问题。是值得提早组建团队以获得一个良好的开端，还是冒着因测试不够好而无法证明弱点的风险默认接受一个系统？

b. 作为 UAT 团队的最终用户测试员，您有什么建议？

作为最终用户，我知道在准备 UAT 的同时，我还要继续我的 “日常工作”。在这种情况下，我越早开始准备工作越好，这样我就可以错开较长的时间。在我开始需求评审之前，我需要一些培训，因此我建议，一旦有了评审需求，就立即为团队安排培训，然后在一段时间内给团队一定的时间来完成评审并开始准备测试。