6 计划

我们需要像开始任何重要工作一样开始我们的 UAT 工作--决定我们要实现的目标是什么。当我们开始进行 UAT 时，您可能会认为这应该已经很明确了，但请记住，变化是计划的魔咒。很多事情都会偏离最初的计划和要求--有偶然的，也有蓄意的。此时此刻，我们必须最终确定我们认为项目的业务目标--业务意图--以及实现这些目标的系统必须是什么样的。
我们制定、计划和准备 UAT 的方式将决定其效果如何。在本章中，我们将讨论规划 UAT 的所有关键要素。然后，这些关键要素就可以打包成一个 UAT 测试计划。我们没有涉及常规测试计划的一般要素，这些要素几乎可以在任何测试教科书中找到，而且在 IEEE 828 等标准中也有很好的阐述。
本章涉及的主题 y

• 决定我们要实现的目标
• 验收标准
• UAT 目标
• 入口标准
• 确定我们需要的测试
• 为 UAT 创建测试基础
• 设置测试管理控制

英国护照管理局--计划的重要性 1999 年夏天，英国护照管理局引进了一套新的西门子计算机系统，但没有对其进行充分的测试，也没有对员工进行如何使用该系统的充分培训。与此同时，由于法律的修改，16 岁以下的儿童出国旅行时需要自己的护照，因此对护照的需求量异常之大。这两个因素结合在一起，造成了 565,000 份护照申请的积压，内政部被迫支付了数百万美元的赔偿金，用于补偿错过的假期和员工的加班费。

国家审计署关于护照延误的报告认为主要有三个原因：

• 对员工学习新程序可能需要的时间缺乏足够的规划和测试；
• 应急计划不足，导致试点测试阶段在提出的问题尚未完全解决之前就被延长；
• 缺乏与公众的沟通。

尽管试点实施表明新系统的护照办理量低于预期，但还是决定将该系统推广到其他 护照办理点。作为试点工作的一部分，旧系统已被拆除，新系统已安装完毕。之所以决定实施新系统，或者按照英国护照办公室的说法是 “扩大试点”，是因为旧系统被认为已经过时，有可能不符合 2000 年的要求，而且重新使用旧系统被认为成本高、风险大。当时人们不知道的是，对护照的预期需求被大大低估了，当护照需求增加时，增加人手和加班加点并不能对生产率产生预期的积极影响，因为额外的人力资源无法克服系统的某些局限性。
国家审计署提出的主要建议之一是

• 项目管理人员应计划在投入实际运行之前对新系统进行充分的测试，特别是让工作人员学习和使用该系统。
  英国护照管理局遇到的困难在许多方面与规划工作有关。这个例子说明了以下方面的重要性。实施工作的复杂性和外部影响因素，这些因素会影响对所需测试程度或何时停止测 试作出决定；
• 了解测试与实施之间的区别
• 了解验收标准和改变验收标准可能带来的风险。

6.0 习题

6.0.1 选择题

• 1. 以下哪项是有效的 UAT 目标？
     A. 确保系统在交付时没有缺陷 B. 在发布前消除系统的所有风险 C. 确保发布系统的风险是可接受的 D. 完成 UAT 计划中的所有工作
• 2. 以下哪两项可以作为系统的验收标准？
     A. 已完成所有计划测试 B. 没有未完成的变更请求 C. 没有未完成的测试事件 D. 没有严重缺陷 E. 已测试所有基本功能
• 3. 以下哪项必须在 UAT 中解决？
     A. 业务需求 B. 用户故事 C. 用例 D. 业务流程 E. 用户期望 F. 技术规格

6.0.2 简答题

• 1.您发现用户不愿意在系统交付时表达他们对系统的期望，而是依赖于需求中的内容。您会怎么做？
• 2.销售经理认为，验收标准不应延迟向客户交付系统，因为客户期望尽早交付。开发经理认为验收标准只应包括需求范围。市场经理担心企业形象，坚持把零严重缺陷作为验收标准。您应该怎么做？
• 3.开发团队不愿意让 UAT 团队访问事故报告系统，因为如果有人犯错，可能会导致事故数据丢失。您会怎么做？

6.1 决定我们要实现什么目标

在投入资源进行任何测试之前，我们需要确保以正确的方式测试正确的东西。我们以开发项目中的一些可交付成果为起点：

• RS 形式的一套业务需求，这些需求很可能已经改变；
• 由开发团队完成的一些测试，也许还有一些独立测试人员完成的测试，这些测试可能会也可能不会被很好地记录下来；
• 系统应该是完整的，可以进行 UAT；
• 训练有素的 UAT 团队准备开始工作。

这是我们的起点，但终点是什么？我们如何知道自己已经完成了 UAT？我们下一步要做的就是确定这些事情，这样我们就可以利用它们来确定我们的起点有多好，并计划如何达到我们期望的终点。

6.2 验收标准

我们必须有办法决定何时停止测试并将系统投入运行。决定权不在我们，但决策者需要一些客观的信息来帮助做出判断，而我们的工作就是尽可能多地提供这些信息。
验收标准是对发起人和用户需求的衡量标准，我们可以将其作为 UAT 结束时的目标，但它们也是收集和报告信息的基础。
显而易见的验收标准可能是系统工作正常、没有缺陷，并且可以在计划的发布日期发布。这些标准当然没有错，但如果不能全部达到呢？如果某些标准无法在合理的时间范围内实现，我们该如何决定该怎么做？这就是为什么发布决定可能会变得感性多于理性的原因--如果发现其中任何一个标准因某种原因而难以实现，那么制定验收标准所提供的客观性就会大打折扣，而且当参与者面临交货期限的压力时，还需要重复当初制定标准时的理性讨论。
斯坦迪什集团和其他机构的统计数据表明，我们很有可能无法同时达到所有三项 “显而易见 ”的标准。在用户和企业要求我们尽快将系统投入使用的压力下，我们必须做出决策，决定该怎么做，这就是为什么我们需要在 UAT 开始之前就制定切实可行的验收标准。所谓现实，是指认识到无法实现理想结果的可能性，并计划限制我们偏离理想的程度。如果标准是基于我们可以接受的最坏情况，那么它们就会变得现实，因为参与决策的每个人都知道，如果不能实现这些标准，就不仅仅是放弃了理想，而是真正有可能失败。
我们如何确定现实的标准？我们从 “理想 ”标准出发：

• 系统正常运行。
• 系统没有缺陷。
• 系统在启动日期准备就绪。
  现在设想一下，我们已经到了启动日期，但 UAT 尚未完成，而且还有 20 个未解决的缺陷。我们该怎么办？当然要看情况。有两个极端。一个极端是时间压力非常大，必须忽略其他标准，因此我们在问题出现时立即发布并处理。另一个极端是，我们没有时间压力，所以我们要在发布之前完成 UAT 并修复所有缺陷。
  这两种极端情况都不可能成为现实，因此我们需要决定在三个关键标准中，每个标准有多大的回旋余地。如果采用时间标准，我们需要了解发布日期的关键程度。如果系统不能在该日期发布，会发生什么情况？会产生哪些成本？业务会受到什么影响？可以容忍多长时间的延迟？延迟发布日期会以多快的速度增加成本和问题？

对于缺陷标准，我们需要确定关键性。有些缺陷比其他缺陷更严重。我们可以将缺陷分为三类：关键缺陷、严重缺陷和常规缺陷：

• 关键缺陷是指会妨碍系统提供核心功能或实现业务效益的缺陷。
• 严重缺陷是指虽不重要但会严重影响性能的缺陷。可能有抵消问题的方法--“变通方法”。
• 例行缺陷是可以例行修复的缺陷，因为它不会对系统性能产生重大影响。

我们显然不能容忍任何严重缺陷，但我们可以容忍一些严重缺陷和许多常规缺陷。请记住，数字很重要。

有 10 个常规缺陷的产品发布时应该不会对系统造成太大影响；而有数百个常规缺陷的产品发布时则可能会造成一定影响，而且还可能需要一些时间来纠正。因此，衡量标准从一端的零缺陷到另一端的零关键缺陷、“少量 ”严重缺陷和无限常规缺陷。当然，关键性的三个等级可以扩展到五个、七个或更多。
功能性标准比较简单。显然有一些功能（和一些非功能行为）对系统至关重要，同样，也有一些功能几乎只是表面现象。通常将系统功能的关键性分为三个等级：

• 基本功能是指没有这些功能，系统就无法实现其业务效益。
• 重要功能是指那些并非关键的功能，但如果没有这些功能，系统将无法达到预期 的性能（可能有办法绕过缺失的功能，但可能因此需要一些培训或再培训）。
• 外观功能肯定不是必要的，但它们可能会提高可用性或节省时间或精力。
  处理这一标准的一个简单方法是对测试功能进行优先排序，以便首先测试基本功能，但当计划的测试时间耗尽时，我们可能仍会遇到不理想的情况。

现在有三个相互影响的标准需要考虑，任何决定都会对这三个标准产生影响。
例如，如果我们决定在发布前修复所有关键缺陷，就会对测试产生影响，因为需要对修复的缺陷进行测试。
没有一个简单的公式能提供一套理想的发布标准，我们在发布时所作的任何选择也不能保证一定会有结果。这里的重点是，在使用验收标准之前，必须对其进行充分考虑，以便每个人都了解每条标准的相对重要性，收集和跟踪数据，确保准确报告每条标准的执行情况，并在需要时做出合理决策。

6.3 UAT目标

验收标准的另一面是它们所产生的策略。验收标准如果把系统功能放在首位，就会鼓励把测试进度放在缺陷修正之前的策略，这样在修复关键缺陷时可能会造成延误。验收标准如果把交付期限放在首位，就会鼓励优先修复缺陷，把延误的可能性降到最低，但这可能会影响系统发布时的完整性。验收标准只是提供了一个目标，但并没有确定战略。
验收标准确定了系统在发布时的状态，但无助于决定如何实现这一状态。我们需要考虑如何以最佳方式管理 UAT，以实现验收标准：我们需要一个 UAT 战略。除了实现目标，战略还需要确定目标的方法。就 UAT 而言，我们必须考虑进行 UAT 的原因--降低风险、增强信心、评估系统是否准备好投入实际使用，以及促进向实际使用的过渡。我们可以跟踪这些目标中的每一个目标，例如根据风险登记册核对风险，或根据检查清单衡量就绪程度。
与验收标准一样，我们需要一个目标组合，这样我们在处理验收标准时就不会忽略 UAT 的任何方面，而是通过在测试过程中衡量各方面的进展来确保对每个方面的关注。所有四个主要目标都有可能出现在 UAT 战略中，并产生关键的里程碑，使团队能够跟踪验收标准的进展情况。

6.4 进入标准

现在回顾一下我们在开发过程中的交付成果：

• RS 形式的一套业务需求，很可能已经改变；
• 开发团队完成的一些测试，也许还有一些独立测试人员完成的测试，这些测试可能会 也可能不会被很好地记录下来；
• 系统应该是完整的，可以进行 UAT；
• 训练有素的 UAT 团队随时准备开始工作。

这些都准备就绪了吗？项目和系统是否已为 UAT 做好准备？
举例来说，想象一下如果我们在有 20 个关键缺陷未解决的情况下开始 UAT 会发生什么--系统代码会频繁更改，而且是在关键区域，因此我们所做的每次测试都会在几天内因更改而失效，我们不得不重复测试。这将浪费大量时间，更糟糕的是，这将使变更控制变得非常复杂，我们将面临失去对系统代码状态或测试的控制的风险。
为了避免这种问题，我们需要为 UAT 制定一些入门标准，让 UAT 有一个合理 “干净 ”的开始。与验收标准一样，这些标准通常基于未解决的缺陷、任何未完成的测试以及开发团队提出但尚未解决的任何问题（例如由于没有测试环境而无法完成系统测试）。
与验收标准一样，进入标准也可以很简单。下面是一组可能的标准：

• 完成系统测试前的所有测试。
• 没有未解决的缺陷。
• 没有未解决的问题。
  这些都是非常合理的标准。但是，我们需要更加务实和灵活一些，以避免出现僵局。因此，更现实的标准可能是
• 完成系统测试前的所有测试，无未决事件。
• 没有关键缺陷。
• 严重缺陷不超过五个。
• 不超过 10 个常规缺陷。
• 没有未解决的影响测试的问题。

即使这些都是可以商量的，但它们确实为开发团队设定了一个目标，以实现向 UAT 的移交。同样重要的是，它们为 UAT 团队提供了一些筹码。
如果一个项目出现了问题，进度已经很晚，那么就会有很大的压力，要求尽快完成 UAT，以便系统投入使用。这种压力是可以理解的，但在这种情况下，UAT 能带来什么价值呢？根本没有。它只是完成了项目计划中的一项活动。
在任何项目的这一关键阶段，决策都必须考虑到对项目、系统、用户和企业的所有影响。入门标准没有绝对的权力，也不能阻止错误的决策，但它们至少能让决策的性质清晰可见，并能评估与决策相关的风险。
一旦我们达到了进入标准，我们就可以开始测试了，或者至少可以开始计划了。

6.5 确定我们需要的测试

我们在验收标准和 UAT 目标方面的工作为我们提供了目标。验收标准告诉我们业务需求是什么，UAT 目标告诉我们 UAT 需要实现什么。
现在，我们可以运用测试技能，决定如何以切实有效的方式实现目标。我们要制定 UAT 战略，确定需要测试的内容和程度，并根据战略制定可以执行的计划。
在这一阶段，很大程度上取决于项目的规模和复杂程度。在某些情况下，制定一套 UAT 目标、战略和计划可能会显得矫枉过正。如果项目确实小而简单，那么定义一些验收标准并直接用于定义测试，省去所有中间步骤也许是可行的。这些决定只能在项目层面做出。如果您已经了解了 UAT 战略和计划的目的，那么您就能很好地决定在这些阶段需要何种程度的细节，甚至决定是否需要这些细节。但要注意的是，您的判断必须是理性的，而不是基于时间、管理或任何其他外部压力。受人欢迎总是好事，尤其是受上级的欢迎，但如果结果对企业不利，受人欢迎的时间就会很短。

6.5.1 定义UAT战略

UAT战略是我们将验收标准和 UAT 目标结合在一起的方法，所有这些都基于利益相关者的优先级和关注点，从而得出一套里程碑和一套衡量标准，据此我们可以确定每一步的进展情况。在此基础上，我们就可以开始定义实现每个里程碑所需的测试活动。
作为测试人员，我们会对测试的优先顺序有自己的看法。是先测试最重要的功能，还是先测试最常用的功能？我们是应该测试最严重的风险是否已经避免，还是应该从简单的低风险领域开始测试以尽早建立信心？
确定战略就是要面对所有的选择，并就优先事项做出决定，从而为我们提供一条能够实现价值的道路。
下图是一个非常粗略的示意图，但显示了在一个信息系统项目中成本和价值之间的相互关系。开发阶段是成本的全部。在理想的交付情况下--按时、按预算交付并成功进行 UAT--系统开始增值，首先收回开发成本，然后随着时间的推移为企业带来净收益。在延迟交付和超预算交付的情况下，虽然测试和 UAT 部署有效，确保了最佳结果，但总成本较高，净效益交付延迟，但系统的最终成功仍有保障。在第三种情况下，通过缩短统一测试时间和降低统一测试成本，迫使延迟和超预算的开发项目按时交付，但由于交付前未解决的问题影响了系统的有效性，延缓了效益的提升，推迟了成本的回收和净效益的实现，降低了企业的最终效益，因此增值线较为平缓。

当然，这只是一个示意图，并没有指定具体的值。它只是确定了风险的性质。最终的曲线可能没有画得那么平，但也可能更平坦。
但同样也可能更平坦。示意图中没有显示的一个影响是，在问题解决之前发布产品的影响。这可能会造成进一步的延误和成本增加，因为关键问题的解决将使用户能够开始利用系统创造价值。
示意图的目的是邀请大家就发布决定的影响进行非常重要的讨论。讨论的结果将是制定一项战略，在图表上画出一条可接受的线，并将适当的 UAT 战略纳入其中。

6.5.2 高级测试计划

一旦确定了 UAT 战略，就可以制定高级计划，以确定如何进行所需级别的测试，即需要进行哪些测试，以及如何组织这些测试才能实现高效的 UAT。

6.5.3 确定测试环境

测试通常需要一个尽可能接近实际环境的测试环境。对于每项测试，我们都需要确定需要什么样的测试环境，以及如何设置测试环境以支持测试。

6.6 为UAT创建测试基础

我们有三种有用的方法来发现 RS 可能需要的更新或扩展：回顾、结构化访谈和观察。

6.6.1 审查现有的需求

第 2 章解释了为什么在 UAT 准备工作开始时 RS 几乎肯定不再是最新的或完整的。即使在项目开始时，业务代表能够完美地定义他们对信息系统的需求，但随着越来越多的人根据自己的假设来解释需求，以及随着时间的推移业务需求发生变化，错误也会逐渐出现。系统也可能已经发生了变化，而 RS 中却没有更新。

我们需要审查原始需求，以及对 RS 所做的任何更改，以确定它们是否准确地反映了正在交付的内容，以及它们现在是否反映了用户的期望。

6.6.1.1 审查小组

审查小组需要包括原始需求的作者（如果他们还在的话）、为 UAT 设计测试的人员和 UAT 负责人。事实上，所有 UAT 小组成员都参与需求评审是有好处的，因为他们可以熟悉需求和所建系统背后的原理，并能在评审中从用户角度出发，确定任何更改或补充，使 UAT 规范作为测试基础更加实用和现实。

6.6.1.2 准备工作

严格来说，走查不需要做任何准备工作，但阅读和吸收 RS 的内容有很大的价值，这是在某个阶段必须做的工作，以便测试顺利进行。现在为测试做准备比以后做准备要好，因为准备工作可以立即产生巨大的价值。
准备工作只需阅读文件，仔细记下任何似乎不完整或不正确的地方，记下你有的任何问题，并准备好自己的笔记，作为审查会议的备忘录，以免在关键时刻遗忘重要内容。核对表可以帮助审核人员，尤其是那些刚开始接触 UAT 的人员，重点关注他们需要注意的问题类型，例如：

• 问题：审核人员认为在现实生活中不可行的任何问题。
• 不准确：审核员认为是错误的或对需求的曲解。
• 含糊之处：任何可有多种解释或不易测试的要求。
• 遗漏：审核员认为现有要求中缺少的任何内容、文件中缺少的任何要求，以 及任何其他遗漏，如缺少唯一 ID。
• 清晰度：文字的拼写、语法和质量本身并不重要，但如果容易使读者混淆或阅读文件有困难，则非常重要。

核对表还可以用来传达一个重要信息，即这项工作的重点是查错，而不是纠错。这意味着审核员不需要知道需求应该是什么，只需要知道或怀疑它是不正确的。

审查的目的是找出 RS 中可能导致实施错误的重要缺陷（以帮助确定测试目标）， 并找出可能导致已实施系统无法满足真正业务要求的漏洞。

6.6.1.3 进行

走查应以轻松和非正式的方式进行，但要控制时间。通常情况下，作者会领导穿行检查，但对于 UAT 来说，请 UAT 领导主持会议可能会更有利。应鼓励审核人员自由提出问题和意见，并指定一名抄写员记录所有会导致任何行动（如更新规范）的意见。只要不浪费时间，讨论可以自由进行。重要的是要采用正确的语气，这样作者尤其不会感到受到威胁--始终记住你是在对文件而不是对其作者发表意见。评论应不带个人色彩，客观公正，没有批评或指责的意味。
主席可能需要不时介入，以确保会议取得进展，而不会陷入细节问题--一条有用的规则是，审查应发现问题，而不是试图解决这些问题。在实践中，最简单的问题可能当场就能解决，但如果不能快速解决，则需要限制讨论--然后将问题记录在案，以便日后跟进。
随着时间的推移，持续几个小时以上的审查往往会变得相当累人，效果也会大打折扣。如果显然无法在两小时内完成需求评审，就需要召开第二次评审会议来完成。

6.6.1.4 后续行动

需求评审的后续行动包括两个部分：

• 作者完成会议上同意和记录的任何行动或修改。这主要是为了进行测试计划和测试设计。
• UAT 负责人注意到需求中的完整性和正确性问题，以便有针对性地进行测试。

评审主席应负责与编写者确认是否在合理的时间内完成任何修改，因为在对需求文档进行重大修改之前，UAT 的测试设计是无法进行的。
当需求评审作为 UAT 的前奏时，文档中的重要缺陷就是那些会影响测试的缺陷。

6.6.1.5 案例研究

Excelsior 的一个插件允许用户通过系统申请批准缺勤。下表列出了缺勤申请和审批功能的一些需求。使用第 2 章中提供的 “走查清单 ”标准和 “什么是好的需求 ”信息，记下你能发现的与需求有关的任何问题，就像你是审查的一部分。

6.6.2 访谈利益相关者

了解用户期望的最好方法就是询问用户！我们可能会遇到的问题是，用户的期望值可能在需求书写之初就已经有了很大的变化，而且不一定在每种情况下都是现实或实用的，因此我们必须进行仔细的筛选。
其他利益相关者，尤其是发起人，可以起到平衡的作用，因此我们需要对所有主要群体的利益相关者的期望进行相当系统的审查，这些群体包括发起人、用户、管理人员和开发人员。我们需要把开发人员包括进来，以确保如果我们捕捉到的期望原本不是需求，那么它们实际上是可行的，并且可以在现实的时间框架内实现。因此，这是一次调整工作，而不是重写需求的机会。尽管如此，即使不能满足用户的所有期望，用户发表意见的机会也能极大地推动用户对推广工作的支持。
收集期望值的工具是半结构化访谈。结构化访谈将确保每个人都被问到同一组问题，从而为我们提供一致的信息。非结构化部分则是让每个人都有机会扩展他们的答案，并以更全面的方式表达他们的担忧和愿望。

6.6.3 观察用户流程

如果我们还不熟悉用户在组织中的工作方式，或者如果新系统将对用户的工作方式带来重大改变，或者如果该系统是组织中的第一个信息系统，我们就需要了解目前正在发生的事情，以便顺利过渡到新系统。过渡本身并不是 UAT 的一部分，但 UAT 必须确保系统能够处理用户期望的工作方式。

捕捉用户流程是一个微妙的领域，因为这在很大程度上取决于组织对变革的准备程度。在计划进行 UAT 时，用户应该已经知道系统运行后会发生什么。培训至少应该已经开始，流程也应该已经制定。如果所有这些工作都已完成，那么过渡工作就可以顺利进行，我们就可以获得所需的信息，按照新的用户流程建立测试。

但是，如果过渡工作进展得不尽如人意，我们就需要有一定的基础来构建测试，使用户能以现实的方式与系统进行交互。如果我们观察用户现在是如何工作的，我们至少可以合理地评估用户流程需要如何改变才能与新系统一起工作。观察结果可以记录下来，以便于测试设计--理想的记录方法是构建用户故事和用例，我们接下来将讨论这一点。

6.6.4 构建用例和用户故事

6.6.4.1 用户故事

正如我们在第 2 章中解释过的，用户故事并不是真正的需求，但它是捕捉和记录一些关键用户期望的好方法。在进行 UAT 时，我们需要花时间与尽可能多的现有系统用户以及新系统或更新系统的指定用户进行沟通。在用户故事中记录他们的意见是一种相对快速和一致的方法，可以为 RS 提供综合的补充信息。
我们在第 2 章中描述了用户故事的样子，下面是一个快速提示：用户故事主要在敏捷方法中作为收集需求的一种手段，但在设计测试时，它也可以作为表达需求或总结需求信息的一种有价值的手段。

用户故事是用最终用户的日常用语写成的一两句话，涵盖了用户在工作中需要做的事情。例如：

• 作为一名团队成员，我希望能够完成一份合同，以便对其进行处理。
• 作为经理，我希望能够批准我的团队创建的合同。

用户故事通常采用以下形式 作为<角色>，我希望<目标或愿望>能使<收益>实现"，尽管收益可能是隐含的，但也可以不说明。另一种语法是："为了<受益>，作为<角色>，我想实现<目标或愿望>。
例：Excelsior 需求更新： Excelsior 的业务需求是在项目开始时通过 RS 捕捉到的。然而，至少有一项关键需求被遗漏了，而且，自需求书写完后，情况发生了变化，导致一些需求已经过时：

• 公司新规定要求所有员工的开支都必须得到批准，不再像以前那样不包括管理人员。
• 系统的任何部分都不允许行政助理（EA - ）代表经理管理申请。如果不提供这一功能，行政助理就必须使用管理人员的登录信息登录，从而可能造成审计和人力资源问题。
• 没有捕获将发票识别为 “第三方账单 ”的要求，该组织需要捕获该要求以用于报告目的和管理付款--第三方因客户工作而产生的费用，可能会被税务人员区别对待。

开发团队了解前两项新要求，并编写了代码来实现这些要求，但 RS 中没有记录这些变更。UAT 团队进行了半结构化访谈，试图捕捉所有当前的用户需求，并对数据进行了整理和分 析。组织了一次会议，根据访谈结果创建用户故事。这些就是最终的用户故事：

• 1.1. 作为一名经理，我希望能够发送我的费用以供审批。
• 2.1. 作为经理，我希望能够将我的账户分配给我的 EA，这样他们就可以代表我管理申请流程。
• 2.2. 作为经理，我希望能够批准由我的 EA 管理的报销申请。
• 2.3. 作为一名 EA，我希望能够在我不在时将我的账户分配给另一名 EA。
• 3.1. 作为客户经理，我希望能将发票标记为第三方账单。
• 3.2. 作为客户经理，我希望能够取消将合同标记为第三方计费。

6.6.4.2 用例

用例通常用于捕捉当前流程，可以弥补用户以通俗语言编写的需求与技术性更强的规范语言之间的差距。正如我们在第 2 章中所解释的，用例使用图表或简单的结构化文本来描述角色（行为者）与系统之间的交互，以实现特定的结果。角色可以是一个人，也可以是我们的系统要与之交互的另一个系统。
稍后我们将回到 Excelsior 案例研究。首先，让我们以相对简单的自动取款机为例，进一步研究如何编写用例。

例：如果我们要实现的系统是自动取款机，那么用例就应该确定用户用户需要执行的高级流程。因此，我们可以首先确定用户需要做的两件事：提取现金和订购对账单。最初的用例可以在用例网格中列出，为用例练习提供基础。

用例的书写方式没有统一的标准，但常用的书写方式如下：

• 标题
• 角色
• 主要成功场景
  • 步骤
• 扩展

这里是一个提取现金的主要用例。
标题： 提取现金
行为者：银行客户（任何银行）、银行系统
主要成功场景： 任何银行客户都可以从其银行账户中提取现金
基本路径：

• 1. 客户将银行卡插入自动取款机。
• 2. 自动取款机验证银行卡的有效性。
• 3. 自动取款机检查发卡国家。
• 4. 自动取款机要求输入密码。
• 5. 客户输入密码。
• 6. 自动取款机验证密码是否对银行卡有效。
• 7. 自动取款机显示包括提取现金在内的选项。
• 8. 客户选择提取现金。
• 9. 自动取款机显示现金数额选项。
• 10. 客户选择金额或输入金额。
• 11. ATM 检查 ATM 中是否有足够的现金。
• 12. 自动取款机检查客户是否低于取款限额。
• 13. 自动取款机检查客户的银行账户是否有足够的资金。
• 14. 自动取款机从客户的银行账户中扣款。
• 15. 自动取款机提供打印收据的选项。
• 16. 客户选择打印收据选项。
• 17. ATM 返回银行卡。
• 18. 客户取出银行卡。
• 19. ATM 打印收据。
• 20. 自动取款机发放现金。
• 21. 客户取走现金。

这些步骤代表了通过系统提取现金的路径，并说明了每个角色如何与系统交互。这种用例也被称为 “晴天 ”用例或主要用例，因为在一切顺利的情况下，它是最有可能发生的路径。为了完成用例的创建，还必须编写 “雨天 ”情景或边缘用例。

用例或边缘用例。例如，如果客户的银行账户中没有足够的资金来提取所需的金额，该如何处理。
一种常用的备注方法是在主要用例下面输入备注步骤。不需要完整描述整个流程，只需描述每个替代路径的不同步骤。
在风险管理方面，先编写晴天方案并从中推导出边缘案例是更简单、更高效的良好做法。如果时间不够，可以先编写最重要的用例。
自动取款机用例的边缘案例必须包括如何处理以下情况

• 无效银行卡
• 外国银行卡
• 输入无效的密码
• 输入的金额无效
• 自动取款机内现金不足
• 客户超过取款限额
• 账户资金不足
• 自动取款机纸张不足，无法打印收据；
• 客户不取现金。

还有一些可能发生但不太可能发生的边缘情况，例如系统如何处理无法从账户中扣款的情况。我们的目标不是定义所有可能的用例或边缘案例，而是找到常见的用例，并据此确定优先级。

使用案例和边缘案例可以在 UAT 团队中传阅，以获得关于是否已涵盖最可能的重要情况的反馈意见。然后由业务部门决定应该花费多少时间和金钱来测试不太可能发生的情况。

6.6.4.2 创建工作需求集

通过审查、访谈和观察，我们现在应该对系统需要做什么才能满足预期有了一个比较完整的了解。如果我们尽可能以用户故事和用例的形式记录下所有这些信息，就能为构建测试奠定良好的基础。如果原始需求不是以这种形式记录的，我们就可以根据变化的程度和原始需求的完整程度，判断是否将所有信息转换成通用格式。

• 练习6.2：除了上面列出的用户故事，你还能想到其他三个用户故事吗？

例：Excelsior 案例研究

我们在例 6.1 中生成的用户故事定义了当前 Excelsior 需求中缺少的内容。经过进一步讨论，我们决定不需要用户故事 2.3，而改变业务流程会更有效。大家一致认为，管理人员将自行处理任何请求（原始需求中的功能），或者直接报告 EA 不在的情况。
除用户故事 2.3 外，其他用户故事已由利益相关者签署，作为需要在 RS 中添加或更改的需求，并需要在 UAT 期间进行测试。其他发现的不太重要的问题被认为无关紧要而忽略，或被添加到未来版本的变更请求列表中。然后，项目团队开始根据用户故事创建用例。

6.7 设置测试管理控制

在定义测试的同时，我们还需要注意缺陷的管理，包括那些在 UAT 开始之前就已经发现的缺陷，以及我们在测试过程中发现的缺陷。这些缺陷将影响验收决定，因此有效跟踪和准确统计至关重要。测试记录也是一门重要的学科，这样我们就能随时了解计划中的测试有多少已经完成，还有多少尚未完成。最后，我们需要确保变更控制到位，以确保系统或测试的所有变更都得到确认和跟进。每个缺陷都有可能导致系统代码和测试的更改，而系统代码的每次更新都会产生新的测试，以检查缺陷是否已得到纠正，同时也会产生回归测试，以确保其他方面没有任何变化。我们需要这样做，这不仅是为了确保在系统代码发生变更后，我们始终测试最新版本的系统代码，而且也是为了确定每次变更后的 “尾部 ”测试，以便我们知道在原计划之外还需要进行哪些额外的测试。

6.7.1 变更控制

变更控制机制已经到位，因为开发人员在整个开发过程中都会使用该机制。如果你们还没有合作，这将是与开发团队接触的一个很好的初始点。然后，开发团队可以在移交时向你展示系统代码的状态，这样你就可以亲眼看到做了哪些更改，以及最近的更改可能导致哪些测试工作尚未完成。
您需要将测试用例和测试脚本置于变更控制之下，以防日后需要对其进行更改，同时也要明确系统代码与测试代码之间的联系；维护团队日后将需要这些信息。

6.7.2 测试记录

测试记录确保我们知道哪些测试已经运行，哪些尚未运行；
因此，它还能帮助我们估计哪些测试仍需完成，以及何时完成。测试日志可能会给我们提供一些信息，我们可以利用这些信息来简化测试或在计划中添加新的测试。在开始测试之前，我们需要建立一个测试日志机制。
测试日志其实就是一份简单的测试清单，列出已设计和安排的测试，以便确定每个测试何时完成。在实践中，我们需要更多的信息，因为我们需要记录对测试所做的任何更改、因任何原因而重新安排的测试，以及测试失败后的任何后续行动，如重新测试和任何输入日志的回归测试。
日志将记录每次测试的完成情况及其结果，这样我们就能很容易地从中生成有价值的统计数据，以衡量目标进展情况，并动态预测完成日期。在开始实施测试之前，我们需要创建测试日志。第 8 章中有一个测试日志示例，可以作为起点。以电子表格的形式实施，它提供了一个简单的工具来使用和收集数据。

6.7.3 事件报告和缺陷管理

事件是任何测试失败的结果。我们之所以称之为事件，是因为我们还不知道是否发现了缺陷；我们只知道测试的实际结果与预期结果不符。这可能是由于系统存在缺陷，但也可能是测试或测试环境存在缺陷，或者测试人员只是犯了一个错误。事件报告应能让开发人员重复测试并得到相同的结果，这样他们就能诊断出原因。
当事件被诊断为系统代码或文档中的缺陷时，即时信息管理就变成了缺陷管理。其他结果则需要通过更改测试或采取其他措施来跟进。至于测试记录，IM 系统通常以数据库为基础，以便收集、分析和报告数据--我们需要这些数据来确定目标是否已经实现。
与变更控制一样，IM 系统也应到位，开发团队可以向您介绍如何提出事件并定义报告供您使用。如果即时信息管理系统是自动化的，它将包含一个工作流元素，这样清除事件所需的步骤将由该工具管理；如果不是，则会定义一个流程，您需要熟悉该流程。

参考资料

• 软件测试精品书籍文档下载持续更新 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

6.8 小结

在本章中，我们介绍了非常重要的第一步，即规划 UAT 演习。与所有复杂的活动一样，UAT 也需要精心策划，这样我们才能清楚地知道需要做什么、何时做、如何做以及与谁一起做。同样重要的是，我们需要向每个人传达将要发生的事情，以便他们能够做出自己的贡献。最后，计划需要明确当出现问题时我们该怎么办，这样我们才能有效、高效地处理情况，而不会造成延误或不确定性。

阅读本章后，你应该能够回答以下问题：

• 如何确保有正确的需求作为测试基础？
• 如何确定需要进行哪些测试？
• 我如何知道已经完成了足够的测试？
• 我如何知道结果是否可接受？
• 如果出了问题，我该怎么办？

6.9 参考答案

6.9.1 练习1

• A4.0 - 含混不清，“同事 ”应改为用户分层，例如用户分层中定义的团队成员。包含两个要求：日历对用户是可见的，包含正确的信息；日历必须在缺勤过程中的某个特定点可见。过于关注解决方案应如何工作。
• A4.1 - 可细分为两项要求：系统应显示剩余休假日的现有余额，以及系统应在将计划休 假日放入日历后重新计算新余额。
• A4.2 - OK。
• A4.3 - OK。
• A4.4 - 含糊不清，应说明假期年份，如 1 月至 12 月或从用户开始日期算起的一年。
• A4.5 - 定义不清，提及其他要求时未提及唯一 ID。
• A4.6 - 包含两个要求。
• A4.7--定义不清，应提及用户层次结构并包含多个要求。
• A4.8 - 含糊不清，不应包含 “不久 ”一词，而应定义一个具体的时间段。在提及 “系统提醒 ”时，重点放在解决方案上，而不是需求上。

6.9.2 练习2

案例研究中至少还有三个潜在的用户故事可以使用，但为了简洁起见没有使用。用户故事 1.1 比较简单，代表了系统中的现有功能。现在，UAT 将包括确保以经理角色登录的人员能够发送费用以供审批的测试。可能还有其他需要测试的经理角色没有包括在内。用户故事 2.1、2.2 和 2.3 与分配账户有关，这样一个用户就可以代表另一个用户管理任务。用户故事 2.3 暗示了这样一个事实，即经理和助理的关系可能不是唯一能从分配账户功能中获益的关系。其他用户故事也可以围绕分配账户来处理组织中多个不同角色的缺勤问题而创建。用户案例 3.1 和 3.2 涉及第三方账单以及如何在账目系统中进行记录。在第三方计费的情况下，可能需要额外的合同细节，例如第三方地址。如果是这种情况，系统必须处理第三方账单地址在合同变更后的情况，如用例 3.2 所述。也可能有其他角色需要选择或取消选择第三方账单选项，并需要处理这些问题。可能必须能够以其他方式编辑合同，特别是与应付账款部门的税务有关的方式。

6.9.3 选择题

• 1 C

答案 A 不正确。这是不可能实现的目标，需要加以限定（例如没有关键缺陷）。
答案 B 不正确。这也是一个不可能实现的目标，因为并非所有风险都是已知的，也不可能消除所有已知风险。更合理的目标是将已知风险降低到可接受的水平。
答案 D 不正确。可能无法按最初商定的方式完成 UAT 计划中的所有内容。有些方面是必不可少的（例如实现可接受的测试覆盖率），需要具体说明。

• 2 DE

答案 A 不正确。可能无法完成计划中的所有测试，但已完成的测试可以提供足够的测试覆盖率。
答案 B 不正确。变更请求可在任何时候提出，并在系统发布后继续提出。除非变更被认为是必要的，否则它们与系统发布没有任何关系，而只有当变更与某种关键缺陷有关时，才会在 UAT 中出现。
答案 C 不正确，但很有诱惑力。通常情况下，所有测试事件在发布前至少都要进行调查，即使没有被清除。从技术上讲，测试事件在被清除之前是未决的，但如果调查显示，例如，测试失败是由于测试脚本中的错误造成的，就没有理由推迟发布。

• 3 A、D、E

答案 B 和 C 不正确，因为它们是表达需求的技术，而不是需求本身。通常，用户故事可以用来捕获未记录的用户期望，用例可以用来捕获未记录的业务流程。
答案 F 不正确。技术规范是系统测试的测试基础的一部分，但不是 UAT 的测试基础。

6.9.4

• 1. 您发现用户不愿意在系统交付时表达他们对系统的期望，而是依赖于需求中的内容。您会怎么做？

如果用户对新系统将带来的变化不完全了解，或者对新系统将发生的事情不甚了解，就会出现这种反应。他们可能表示缺乏兴趣或缺乏知识。无论哪种情况，找出原因都是有益的，因为结果可能是他们对系统不满意或无法使用。

• 2. 销售经理认为，验收标准不应延迟向客户交付产品，因为客户期望尽早交付产品。开发经理认为验收标准只应包括需求范围。营销经理担心企业形象，坚持把零严重缺陷作为验收标准。你该怎么办？

优先权的冲突并不罕见，但必须加以协调，否则就没有可靠的验收基础。由所有利益相关者参加的研讨会可以很好地消除这种分歧并找到解决办法。
所有三个角色都在努力将对自己职责范围的影响降到最低，做他们认为对企业最有利的事情。总会有一个折中的立场，尤其是在个人愿意共同努力解决任何问题并尽量减少对彼此影响的情况下。

• 3. 开发团队不愿意让 UAT 团队访问事件报告系统，因为如果有人出错，可能会导致事件数据丢失。您会怎么做？

这种担心可以理解。在系统进入 UAT 之前，开发团队拥有所有权和控制权，但这可能是要求开发团队提供一些工具培训的好时机，这样最终用户在使用这些工具时就不容易出错。培训可能会建立足够的信心，鼓励开发团队在 UAT 开始之前允许访问，或者你可能会发现需要额外的控制措施来防止任何数据丢失。