用户验收测试指南2业务需求

2 业务需求
既然我们了解了 UAT 的背景和目的，下一阶段就是要了解业务需求。本章将解释什么是需求、如何编写需求以及业务需求与 UAT 的关系。本章还将阐明为什么在进行 UAT 时，需求可能与实际业务需求不一致，以及如何克服这种限制。

本章涉及的主题

业务需求
业务意图和用户期望
验收标准
需求类型
业务需求的优先级
业务需求和 UAT 之间的关系
开发和 UAT 之间的关系
UAT的范围
构建UA测试基础
2.0 习题
2.0.1 选择题

如何最好地定义业务意图？
A. 新系统的主要原因和好处
B. 进行 UAT 的原因
C. 用户对系统如何运行的期望
D. 业务目的

什么是业务需求？
A. UAT 策略
B. 测试的基础
C. 一组描述系统应该做什么的陈述
D. （b）和（c）都对

什么是需求的局限性？
A. 可能没有记录需求
B. 自编写需求以来，情况发生了变化
C. 可能没有记录足够详细的需求
D. 以上都对

以下哪项是不合适需求的特征？
A. 太详细
B. 级别太高
C. 技术性不够
D. 只关注业务需求而不是解决方案
2.0.2 简答题

1.你是项目的新利益相关者，要求你阅读 RS 以了解项目的内容，但你不理解部分、大部分或全部需求。您会怎么做？
2.RS 与 UA 测试基础有什么区别？

2.1 业务需求
在第1章中，IS与业务用户之间的契合被称为 “量体裁衣”。用同样的比喻，需求指的是客户对即将为他们制作的服装所提出的具体要求。同样，业务需求也是企业希望对其即将建造或即将购置的基础设施服务做出的规定。换句话说，需求就是我们需要的东西，而在信息系统中，需求就是我们需要从系统中得到的东西。对预期结果和系统应该做什么的细节理解得越透彻，就越有可能实现所需的功能。需求描述了系统应该做什么，将建立什么，以及在 UAT 期间将测试什么。

在捕捉到组织的需求后，项目团队将使用简单明了的语言和用户术语将其记录在需求文档中。如果这些需求过于笼统，不能为开发人员所用，则可以使用一种旨在帮助开发团队理解和构建系统的结构，将其转化为技术性更强的版本。由此产生的文件被称为需求规格（RS），其中包含的详细业务需求就是需求。

2.1.1 了解需求的语法 需求是什么样的？

需求可以用多种不同的方式表达，它们的外观也不尽相同。需求可以记录在文档、电子表格或专门用于记录需求的软件中。

下面是一些简单的需求示例，但请注意，任何提供给你的 UAT 需求文档都可能包含比这些基本信息更多的内容。

业务需求示例1
CR1 管理员能够添加新用户
CR2 管理员能够调整现有用户的详细信息
DB1 系统支持在版本历史中提供 100 个以前版本的合同
只要所使用的语言和术语是需求者和开发者所熟悉的，那么这些就是需求的很好的例子，即对系统需求的清晰描述。然而，你可能会发现，你所得到的需求文档所包含的信息远不止这些基本信息。

业务需求示例2
这些与网站安全有关的需求是输入到系统中的，而不是写在文件中的。除了对需求的描述，这份文档还包含了其他一些有价值的信息。

项目名称
当需求文档只与一个项目相关时，可能不需要这个字段；但是，对于可以记录与多个项目相关的需求的软件来说，可能需要这个字段。

需求的唯一标识符
每个需求都应该有一个唯一的标识符，它可以确保任何进一步创建的项目文档都可以回溯到某个活动或项目与哪个需求相关。因为项目的目的是满足业务需求，所以唯一标识符是 RS 之后所有项目文档的基石之一。请注意，上述两个例子中的唯一标识符是不同的。

在第二个例子中，你可以看到有两个不同的标识符，它们把需求分成一个较大的整体需求（S_01）和属于它的详细需求（S_01.1 和 S_01.2），而在第一个例子中只有一个级别的标识符（CR1）。

类别
对大多数 RS 文档来说，把需求归类为涵盖相似内容的类别是有意义的。这些类别涵盖了项目交付功能的任何相关部分，并可以在逻辑上被归类在标题下，如：“创建合同”、“创建合同”、“创建合同”、“创建合同 ”等： 创建合同“、”开具发票“、”建议书维护“、”工作流 “或 ”用户界面设计”。这些类别可能包括系统的功能方面–它应该做什么–以及非功能方面–它如何做它应该做的事情，非功能性需求可由项目团队编写，涵盖系统的速度和可用性等主题。

优先级
了解需求的优先级在大多数情况下都是有用的，因为它有助于安排开发工作和测试的 优先级。从理论上讲，可以使用任何优先级，但使用 “关键 ”和 “非关键”，或使用 1-3 或 1-5 的优先级是很常见的，1 代表最高优先级，3 或 5 代表不太重要。编写 RS 时的假设是，所有的需求都是需要的，因此称为 “需求”，但有些需求比其他需求更重要。

状态
在需求文档中跟踪需求是否已经被提出，是否已经被建立或测试，可能重要，也可能不 重要。如果重要，可以在 RS 中创建一个状态字段或列。

编辑/删除
在项目 UNT v.02 的例子中，需求记录的系统会跟踪需求的版本历史，编辑/删除按钮允许 文档用户对需求进行修改。这可能与你的情况无关；但是，记住需求是可以改变的，而且经常会改变。在 RS 的生命周期内，应该对 RS 进行重新审视和检查，以确保文档中的需求仍然能反映项目中发生的事情和当前的业务需求。

2.1.2 练习

我们将在全文中使用的案例研究是一个名为 Excelsior 的会计系统。该系统还包含一些模块，允许工作人员执行与人力资源相关的任务。

一旦保存了请求，用户将在请求可用时收到请求更新，可以对缺勤、培训或费用等其他变更请求进行更新。

从下面的业务需求中，您可以收集到哪些信息？

请注意，如果你被要求审阅一份需求文档或规格说明，而你不理解其中的要求，你可能需要向理解的人提出一些问题。

2.2 业务意图和用户期望
我们规定，需求应在业务需求文档中收集和记录。这些需求作为一个整体应反映出企业的总体目标和期望。这些总体目标和期望虽然经常被遗忘，但也应记录在案。
每一个信息系统都是为了一个目的而创建的：实现某些商业利益，如提高员工的工作效率或降低运营成本。系统的目的通常被称为 “业务意图”。业务意图之所以重要，是因为它确定了企业在安装和运行系统后期望实现的目标。
根据业务意图，发起人、管理人员和最终用户将对系统应该做什么以及应该如何运行有一个认识。已安装系统的用户也会根据他们对当前工作方式的认识以及对系统工作方式的期望而产生期望。这些期望可能与业务意图不完全一致，但却是成功感知的一个重要因素，因此应将其作为 UAT 的一项输入加以捕捉。
成功实施信息系统的一个关键驱动因素是业务意图和用户期望的透明度，这样，包括开发人员在内的所有利益相关者都能对信息系统解决方案的要求和期望达成共识。
缺乏有效的透明度是一个关键的风险因素，因为各方可能会根据不同的假设进行操作，而 UAT 是识别和解决开发过程中可能出现的任何误解的最后机会。如果业务要求与业务意图相吻合，并且系统满足了业务要求，那么业务意图就实现了。

例 2.3–业务意图 –
能够同时管理 250 个客户账户。
小部件的吞吐量提高 10%。
能够提供五项新服务。
在 48 小时内交付客户订单。
业务意图应是可衡量的和直接的。一旦系统安装完毕，就可以确定业务意图是否已经实现，因此在 UAT 阶段测试业务意图是否实现也是可行的。而更具战略性的长期目标，如减少员工人数等，则无法在 UAT 阶段进行测试。因此，较长期目标的实现最好基于可以立即看到和验证的改进。

练习 2.2 – 业务意图
对于您目前参与的项目或以前参与的项目，请根据记忆列出构成业务意图的总体目标；如果 没有书面业务意图，请根据您对项目的了解列出总体目标：

您能够列出总体目标吗？这些目标是否足够具体，可以衡量？

除非利益相关者、管理人员、开发人员和测试人员都知道 IS 必须满足的总体要求，并了解应如何衡量这些要求，否则就很难实现这些目标。是否达到目标是 UAT 的基本要素。根据商定的衡量标准，共同决定项目是否成功，以及系统是否应该被接受，这才是 UAT 应该达到的目标。

2.3 验收标准
在详细研究需求和不同的需求类型之前，我们应该先研究验收标准。

验收标准: 组件或系统要被用户、客户或其他授权实体接受，必须满足的退出标准。(ISTQB 术语表）

业务需求告诉我们系统必须为业务做些什么，因此我们的测试将以业务需求为基础。另一方面，验收标准告诉我们如何知道系统是否适合向用户发布。换句话说，验收标准是我们确定测试工作何时完成的方法。例如：至少 90%的业务需求必须经过测试。
这一验收标准可防止出现最终只测试了一小部分需求的情况。验收标准可以与质量相关，也可以与系统相关。例如，如果所有需求都经过测试，但所有测试都失败了，我们就不希望发布这样的系统。我们可以通过实施与质量相关的标准来防止这种情况的发生。例如：在系统发布时必须没有未解决的关键缺陷。
验收标准是系统被用户或利益相关者接受之前必须满足的条件。准确定义验收标准是开发项目取得成功的最重要因素之一，而明确的验收标准则是测试成功的关键。不准确或不完整的验收标准会导致客户满意度低、错过最后期限和开发成本增加。
所有记录在案的要求都应得到满足，这将是一个隐含的验收标准，尽管也可以明示。其他标准将扩展到系统发布时的状态。例如

发布前应测试所有要求。
验收完成时，不得有关键缺陷，不得有两个以上高优先级缺陷。
没有未分配的事故报告。
这三个标准应能确保发布的产品是完整的，并处于稳定状态，这对用户群显然很重要。

验收标准还有另一个有用的目的。如果在预定的发布日期，验收标准还没有全部达到，就可以用这些标准来衡量未完成的工作，以及在所有标准都达到之前系统可能出现的延迟。例如，如果一个系统有一个关键缺陷和四个高优先级缺陷未解决，我们可以比较容易地发现清除缺陷和重新测试以确保修复正确所需的时间。这就提供了一个衡量可能延迟的标准。
我们还可以考虑是否可以通过某种 “变通方法 ”来减轻任何未解决缺陷的影响。验收标准可以在 UAT、开发人员、用户和赞助商之间建立对话，从而协商出一个各方都能接受的发布日期。

2.4 需求类型
到目前为止，我们已经确定 RS 是一份文档，通常由业务分析师或开发人员撰写，它以开发人员可以理解和响应的形式定义了业务需求。然而，需求并不是千篇一律的，我们可以确定不同类型的需求：功能需求、信息需求、行为需求和环境需求。RS 最好能包含所有不同类型的业务需求，并能表达业务意图、捕捉用户期望和定义验收标准。

业务需求类型
所有业务需求都包含企业希望新系统做什么的信息，但我们可以区分不同类型的业务需求。在许多组织中，只使用两种需求类型：功能性需求和非功能性需求，但至少有四种可区分的业务需求类型：

功能性需求

信息需求

行为需求

环境需求。

功能性需求

功能性需求是我们已经熟悉的类型，它定义了系统必须做什么。功能需求涵盖的业务流程可能与技术无关，例如 “签收采购订单 ”或 “装运”。因此，功能需求通常最容易理解和定义。系统将对输入应用逻辑并产生所需的输出。在功能要求的基础上，开发团队将构建信息系统中与最终用户交互的部分。
例如：系统应验证所有密码都包含大小写字母和至少一个数字。

信息需求
信息要求定义了提供给最终用户的信息，以帮助他们完成工作。信息需求还包括对信息共享和访问控制的要求，以及对功能需求中定义的流程所产生的输入数据、输出数据和存储数据的要求。一些与技术相关而非与流程相关的附加数据和元数据也可能被定义为信息要求的一部分。
例如：客户账户文件应包含以下字段 CustID、CustName、OrdDate、OrdQty 和 OrdPrice。

行为需求
行为要求描述了解决方案必须如何行动。它们通常被称为非功能性需求，可以定量或定性地定义。
例如：定性的行为需求可能是用户界面必须友好。这可以通过多种方式来验证：将其与现有的标准联系起来，例如微软用户体验指南（Microsoft UX Guide），它是用户体验交互的指南；或者定义用户界面的参数，例如使用的颜色数量和每种颜色的允许用途。
定量测量很容易转化为数字，但定性的行为要求也需要转化为定量测量。例如，涉及系统响应速度的用户界面要求必须以可以测量和测试的方式量化。
例如：调用客户详细地址的响应时间不得超过 1.5 秒。

环境要求
环境要求有时也被称为 “约束条件”，它描述了信息系统的运行环境。这可能包括信息系统每个组件的物理或地理位置、必须遵守的任何行业标准以及对技术使用的任何限制；例如，系统必须可从运行 MS Windows、Unix 或 Linux 的平台上访问。这些要求还应包括任何法规限制。
后三类中的许多需求，即非功能性需求，不太可能由利益相关者要求或撰写，而更有可能由项目团队添加。尽管需求描述的是企业的需要和愿望，但 RS 中的许多其它信息往往是技术性更强、更抽象的。

在实践中，RS 可能并不包含我们所需要的所有信息，我们前面提到的从业务语言到开发语言的转换可能会 “模糊 ”业务需求的某些方面。最糟糕的是，RS 可能必须在开发开始之前编写和批准，这样它就代表了开发开始时业务需求的缩影。在计划、设计和运行有效的 UAT 之前，我们很可能需要对 RS 进行补充，我们将在第 6 章中了解如何进行补充。目前，我们的工作基础是，我们所拥有的任何文档都能充分表达业务需求。

2.5 需求优先级
对于统一测试来说，时间和资源都不是无限的，因此可能必须以某种方式对测试进行优先排序，以平衡各利益相关者群体的期望。确定优先级还能确保在时间耗尽的情况下，每个人都能确信系统中最重要（优先级最高）的方面已经过测试。

发起人最关心的自然是业务意图，因此需要一种表达业务意图的方法，而业务关键性则是确定应首先测试哪些方面的一种方法。同样，用户和管理人员也会关注系统的操作方式，因此他们所关注的问题也将包含在可用性的概念中。

业务关键性
业务关键性是衡量单个需求对业务成功或实现业务目标的重要程度。我们可以定义从绝对重要到完全不重要的各种等级，但通常的做法是只定义两个等级–重要和不重要。在这两大类中，每项需求（或相关需求组）都有优先级，以便组织能够确定开发的优先级并制定相应的计划。对于 UAT，我们可以使用相同的关键性和优先级措施来管理 UAT 的优先级，或者，如果还没有为需求分配优先级，我们可以咨询发起人来确定测试的关键性。

可用性
可用性有其技术含义，是一种特殊的测试，称为可用性测试。对于 UAT 来说，我们既没有专业知识，也没有时间或资源来严格地进行可用性测试，但我们确实有一套期望值，可以用来确定一些简单的测试参数。例如，如果发起人期望系统每小时能处理 30 笔特定的交易，那么管理人员就会期望单个终端的吞吐量乘以终端的数量至少等于所要求的交易吞吐量，而最终用户则希望自己确信任何单个终端的用户界面都能使他们处理预期的总体交易数量。
对于每个需求或每组需求，业务关键性可用于确定测试的优先级，这些需求的可用性标准也可获得相同的优先级。

业务流程
UAT 的定义包括根据 “用户需求 ”和 “业务流程 ”对系统进行测试。我们至少需要对业务流程进行部分测试，因此这将是我们确定测试需求优先级的第三个重点；我们将把系统中与特定业务流程有关的方面集中在一起进行测试，以便确定系统是否正确地实现了业务流程。

2.6 业务需求与UAT 之间的关系
RS 是我们通常认为的用户、开发人员和测试人员之间的联络点。它的目的是向开发人员表达用户的需求，以便他们能够构建系统，同时向用户体验测试人员表达用户的需求，以便他们能够独立于开发人员测试系统。独立 “一词在这里非常重要，它是 UAT 的关键特征。
UAT 是 RS 的表达（由用户体验测试人员解释）；系统本身是 RS 的表达（由开发人员解释）。通过运行用户体验测试来比较这两种表达，是我们确定开发结果是否符合用户需求的唯一方法。因此，用户体验测试人员在设计他们的测试时，绝对要独立于开发人员，同样重要的是，他们要根据开发人员尚未解释过的需求表达来工作；否则，用户体验测试就会简单地反映开发人员的解释。
我们在前面已经指出，尽管 RS 应该是业务需求的体现，但 RS 可能会过时、不完整或不合适，原因如下

没有详细（或根本没有）记录业务需求。
在开发项目期间，业务需求发生了变化，而 RS 没有及时更新。
一开始就刻意只写了文档大纲，然后反复渐进地进行开发。
这些情况都有可能导致在开发结束时，交付的系统与（当前的）用户期望不一致。除了 RS 可能不完全准确这一事实外，还可能在后续工作中出现更多错误。发起人、管理人员、最终用户和开发人员在描述信息系统必须做什么时遇到的问题是，发起人了解业务背景，但（通常）不了解技术；用户和管理人员了解系统要做什么，但（通常）不了解系统如何运行；而开发人员了解技术，但（通常）不了解业务背景。由于四个利益相关者群体使用不同的沟通方式，对世界有不同的看法，因此很难找到中间立场。通常的做法是尝试用用户理解的术语来定义业务需求，然后将其 “翻译 ”成 “技术语言”。
这个过程可能会产生问题，其中有两个非常重要的原因：

翻译从来都不是简单或完全准确的，因此翻译过程会产生错误。
两组用户都有一套他们认为 “人人都知道 ”的信息。这些假设很少在要求中说明，因为作者的思维模式不承认信息中存在任何空白。
与此同时，读者会按照字面意思来理解所写的内容，并根据自己的假设来实现它。这是造成严重需求缺口的主要原因。
因此，一份 RS 很可能是对业务需求的错误表达，尤其是在项目开始时起草和批准的情况下。此外

项目开始时定义的需求可能包含需要纠正的错误和/或遗漏。
用户可能会在开发过程中获得新的见解，从而导致需求变更。
业务环境的变化可能会迫使需求发生变化（例如，在一个与税收有关的系统中， 可能会对税收法律进行修订）。
因此，我们需要对 RS 进行评估，如有必要，在项目结束时更新 RS 中的需求，并将其记录下来，作为测试的基础。

2.7 开发与UAT之间的关系
开发软件的方法有很多种，但大多分为三大类：顺序开发、迭代开发和基于组件的开发。

顺序开发
顺序开发采用一系列开发阶段，这些阶段通常呈 “V ”字形。发现和记录初始需求是这一流程的第一阶段，UAT 是最后阶段。这种方法将系统分解成易于管理的小块，功能通常要到项目结束时才交付。

注意测试级别与设计的不同阶段有关，在设计阶段，对需求进行分析，然后分解成越来越小的构件。然后，测试级别对每个设计阶段的结果进行测试。UAT 是最后的测试级别，根据需求测试已完成的系统。

迭代开发
在迭代方法（如敏捷开发）中，设计和测试都是在短期开发 “冲刺 ”期间进行的，因此在每个冲刺结束时，系统功能都会逐步实现。在这种情况下，需求是按照计划逐步实现的，但并非所有的需求都会在最初记录下来。系统推出前需要进行 UAT，以确认系统是可接受的，但没有需求文档作为测试基础。

基于组件的开发
其他常见的系统开发方法也建立在上述基本模式的基础上。例如，一个系统可以由商业上可用的组件构建而成，这些组件集成到一个满足业务需求的架构中。
在以组件为基础的系统架构中，组件 “构件 ”很可能是定义明确的，但集成的风险会更大。在系统功能方面，UAT 遇到的问题应该相对较少，但也可能出现问题，例如组件的集成并不能完全达到要求。与此相关的一种方法是使用 COTS 软件，从现有模块集合中获取大部分功能；开发工作包括对模块进行配置，以满足业务需求。在这种情况下，UAT 的重点主要是看解决方案是否符合业务意图。

2.8 UAT测试的范围
UAT测试的范围是在统一测试计划中确定的，对其成功与否至关重要。它定义了 UAT 的范围：哪些将被测试，哪些不会被测试。显然，需求将被测试，但范围解释了可交付成果的范围和界限，包括那些超出范围的东西。前面我们看到，在这个参数范围内，我们必须确保根据最重要的相关方的观点，首先测试最关键的需求。但是否还有其他我们应该测试或绝对不应该测试的内容呢？

必须测试的内容
首先，对合同要求的测试是不容讨价还价的。如果系统是根据合同交付的，那么我们就必须进行合同验收测试，以确保交付的系统满足合同中规定的所有要求。即使在这种情况下，也可能会有一些变化，有些有记录，有些没有，这些都需要考虑在内。

其次，我们必须根据每项需求的业务关键性来确定需求和可用性的优先级，从而测试业务意图和用户期望。
这必须包括合同中明确提到的可交付内容和 RS 中明确定义的内容。

第三，我们需要确保对每个业务流程进行端到端的测试。业务流程在 UAT 之前没有经过测试，但必须构成 UAT 的框架。任何功能要求都应作为已知的现有或未来流程的一部分进行测试，因为与业务流程无关的要求可能与新系统无关。

第四，我们必须测试任何未完成的缺陷修复和发现的缺陷修复。

最后，我们必须对发生的每项变更进行回归测试。回归测试检查缺陷是否已得到修复，并确认修复后的缺陷没有引起任何其他问题。

不测试的内容
由于时间和资源的限制，我们显然不可能对 IS 的所有方面都进行测试，但很多方面都已经测试过了。单元测试（测试代码）、集成测试（测试代码或系统的各个部分是否能协同工作）和系统测试（测试系统的各个部分是否能正常运行）都已经进行过了，重复这些测试不属于 UAT 的范围。

因此，UAT 不会测试任何已经在某个开发测试阶段进行过测试的内容（前提是我们有测试的证据），尤其不会测试软件的所有功能。

由于前文所述的原因，我们将不对可用性进行详细的测试，也不对性能进行测试，但我们会在业务流程测试中嵌入一些可用性和基本性能的测量。

1996 年 6 月 4 日，阿丽亚娜 5 号无人驾驶火箭发射升空，该火箭用于发射通信、地球观测和科学研究卫星。在历经十年、耗资 45 亿英镑的开发之后，阿丽亚娜 5 号火箭在升空 40 秒后爆炸，这是它的首次飞行。阿丽亚娜5号的货物价值额外增加了3.24亿英镑。失败的原因是惯性参考系统（SRI，取自其法语名称）的软件错误，该导航系统在火箭起飞时计算火箭的位置、方向和速度。SRI 设计有一个备份，这样当机载计算机（OBC）检测到关键问题时，备份 SRI 就会接管。不幸的是，主 SRI 和备份 SRI 出现了同样的错误（在数据转换过程中 SRI 软件内部出现异常，转换后的数值大于转换后数值格式所能表示的数值）。这导致操作数错误，导致两个 SRI 都失败。完全失去制导意味着发射器偏离了飞行轨道，解体并爆炸。

调查委员会在关于灾难原因的正式报告中指出就 SRI 而言，对设备进行了严格的测试，考虑到了所有环境因素，实际上超出了对阿丽亚娜 5 号的预期。但是，没有进行任何测试来验证 SRI 在倒计时和飞行时间顺序以及阿丽亚娜 5 号的轨迹下是否能正常运行。应该指出，由于物理规律的原因，除非进行完全真实的飞行测试，否则在飞行环境中把 SRI 作为 “黑盒 ”进行测试是不可行的，但可以进行地面测试，根据预测的飞行参数注入模拟加速度信号，同时使用转台模拟发射器的角度运动。如果这种测试是由供应商进行的，或者是作为验收测试的一部分，那么故障机制就会暴露出来。

范围，即需求中包含的内容，也就是 UAT 中包含的内容，是实施成功与否的关键。我们很容易根据以往的成功经验或需求测试的方式来推测应该包含哪些内容。必须根据当前项目的情况来确定范围，尽可能少做假设，并应鼓励形成一种文化，让项目团队和利益相关者共同对 IS 的内容和测试范围负责，并在发现有遗漏的地方时敢于直言。

参考资料
软件测试精品书籍文档下载持续更新 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
2.9 为UAT建立测试基础
测试基础：可以推断出组件或系统的需求的文件。测试用例所依据的文档。如果只有通过正式的修改程序才能对文件进行修改，那么测试基础就被称为冻结测试基础。

信息系统的生命周期始于确定和记录业务需求，然后将其作为开发的基础。从理论上讲，我们可以把需求文档作为统一测试的基础。但在现实中，情况并非总是如此，因此我们需要一种万无一失的方法来定义 UAT 的测试基础，而不依赖于一套完整的初始需求。测试基础定义中的关键句子（见方框）是第二句：“测试用例所依据的文档”。我们需要 UAT 的测试基础是一套文件，而我们目前拥有的是 RS。在某些情况下，我们必须严格按照原始要求进行测试；例如，如果开发合同是以原始要求为基础的。在大多数情况下，我们需要扩展 RS 中的信息。

2.9.1 评估/改进 RS

需要对整体需求和每个单独的需求进行检查，以确保其质量符合要求。如果利益相关者不熟悉业务需求是如何提出的，他们可能也会提出自己的需求：

高层次
含糊不清
注重解决方案，而不是业务需求；
泛泛而谈，对特定用户群不够关注；
包罗万象，将多种需求混为一谈。
由相关方和利益相关者组成的团队会对需求进行检查和更新。团队成员也可以单独使用核对表（例如，核对表中包含了好需求的特征）来审核文件，以便在走查之前记录下任何意见和问题。

2.9.1.1 好需求的特征

收集需求是一个不完美的过程，错误是会发生的。很少有人接受过如何获取、分析和记录高质量需求的培训。那么，在审核需求文档时，我们应该注意些什么呢？以下是一些需要考虑的关键问题。

模棱两可
好的需求是毫不含糊的。读者只能以一种方式理解需求，得出一个结论。需求不应包含行话或模棱两可的语言，如 “快速”、“用户友好”、“多个 ”或 “高效 ”等。

错误
好的需求应该是正确的。只有用户代表才能确定需求是否反映了他们的意图。最终用户或其他指定的利益相关者应签署或同意文件准确地反映了他们的需求。

可行性
好的需求是可以实现的。好的需求必须在项目的技术、预算和资源限制范围内可以实现。这不是 UAT 直接关心的问题，但任何不可行的需求都会引起对实际执行情况的质疑，这些都需要加以探讨。

必要性
好的需求是需要的。需求应满足业务的真正需要，并由具有适当权限的人提出要求或同意。

优先级
好的需求是有优先级的。特别是就 UAT 而言，风险管理的一个关键部分就是首先测试优先级最高的需求。没有优先级的 UAT 管理会变得更加困难。

可验证
好的需求是可以测试的。需求应该包含具体的量化指标，即使是与质量相关的需求也可以测试。

2.9.1.2 坏需求实例

“网站必须对用户友好且速度快”（层次太高，包含两个要求）。用户友好的具体含义是什么？如果我们发现网站对用户友好，但速度不快，会发生什么情况？是测试失败还是通过？
“所有文件都必须打上品牌”（含糊不清）。什么样的品牌？涉及哪些文件？
“我们需要看到哪些合同即将到期”（没有从用户群的角度考虑）。是影响每个用户还是只影响特定用户组？
“查询时必须自动发送电子邮件”（只关注解决方案而不是业务需求）。电子邮件是正确答案吗？也许真正的需求是通知客户？正确的答案可能是根据客户的偏好发送电子邮件、传真、信函或短信。如果查询不是通过电子邮件提出的呢？
2.9.1.3 好需求实例

设计应足够简单，以便用户经过一天培训就能熟练使用信息系统。
所有非管理层的销售人员都需要能够看到他们的哪些合同将在未来三个月内到期。
IS 应能通过 Internet Explorer 和 Google Chrome 浏览器访问。
合同应在 0.5 秒内打开。
如果 UAT 小组按照最初记录的要求工作，UAT 工作很可能会遇到各种各样的问题。我们对 RS 的审查可能会发现一些问题，但并不能解决这些问题，我们需要确保在我们认为需求有缺陷的地方进行彻底测试。如果我们发现了需求差距，我们还可以回到用户那里，通过重新审视业务意图、用户期望和业务流程来补充 RS。有了这三个来源的最新信息，我们就可以形成测试基础。

下一步，我们将研究这些额外的信息来源，以找到增强 RS 中信息的方法。

2.9.2 捕捉业务意图

如果业务意图还没有被记录下来，或者没有被很好地记录下来，或者已经发生了变化，那么 第一步就是与利益相关者讨论并记录业务意图。业务意图代表了引入信息系统的总体目标，是创建测试基础的第一步，因为它能让 UAT 非常清楚地了解需要什么。业务意图与需求一样，必须清晰、明确和可衡量。

2.9.3 捕捉用户期望

我们可以通过与用户交谈来捕捉用户期望。不过，“用户故事 ”这一简单的技术可以为我们的对话提供帮助和支持。我们可以请用户写下或帮助我们写下概括他们期望的用户故事。

用户故事（User stories）
用户故事是对系统为用户所做工作的简要描述，以帮助用户更轻松地完成工作。用户故事在敏捷开发中被用来 “促进讨论和支持规划”（Adzic, 2009: 160）。对于我们来说，用户故事是一个非常有价值的工具，因为它们避免了任何关于具体要求或如何实现这些要求的细节。它们只是简单明了地表达了用户的期望。

一个典型的用户故事由一两句话组成，使用最终用户的日常用语，涵盖了用户作为其工作职能的一部分需要做的事情。一种常见的格式是使用公式 “作为 …….. 我希望 …….，以便 …….”。这样就与预期效益有了明确的联系，而不需要用户说明具体要求的任何细节，非常适合我们的目的。

用户故事实例
作为团队成员，我希望能够完成一份合同草案。作为一名经理，我希望能够批准我的团队创建的合同。
用户故事的三个 C”（https://airfocus.com/glossary/what-are-card-conversation-and-confirmation/）为捕捉和探索用户期望提供了一个良好的实用基础。

卡片: 用户故事可以写在小的索引卡片上；小到足以捕捉关键想法，大到不足以写出完整的需求。这些卡片可以作为讨论的标记。
会话：与用户故事相关的对话可以探讨故事之间的关系，如有必要，还可以添加细节以澄清问题。
确认：每个用户故事都必须是可验证的，这样我们才有办法知道它是否已正确实施。

通过收集、记录和讨论用户故事，我们不仅可以清楚地了解用户的期望，还可以确定根据每个用户故事进行测试所期望得到的结果。这正是我们所需要的。

2.9.4 捕捉业务流程

我们需要审查业务流程，检查它们与需求的接口是否正确，例如，需求是否包含 业务流程定义的所有功能并接受输入。如有必要，我们可能需要对它们进行补充。我们将在第 3 章更详细地介绍审查技术。
在业务流程与计算机接口的地方，我们可以使用用例的概念来捕捉软件在每个用户活动中应该做的事情，然后与 RS 进行比较。

用例（Use cases）
用例是指行为者与组件或系统之间对话的事务序列，并产生有形的结果，行为者可以是用户，也可以是任何可以与系统交换信息的事物。
该定义（见方框）准确地描述了我们正在寻找的内容。它涉及行动者与系统之间的对话，这种对话构成了一连串的交易，并产生了有形的结果。行为者是某种角色的代表（如进行购买的最终用户或完成订单的最终用户）；事务是系统为行为者完成的操作。因此，这里描述的是用户角色如何与系统交互以实现某个目标（如下订单）。
除了角色外，用例通常还与场景相关联，场景是代表一个特定操作的一系列步骤。在我们的案例中，我们可以为 “正常 ”流程创建一个场景，即一切正常运行且流程成功完成的场景。然后，我们可以添加补充情景来探索 “错误 ”情况，例如，流程与 “正常 ”情况出现某种偏差的情况。
用例可以用简单的图表形式表示，也可以用编号步骤序列表示。就我们的目的而言，后者可能是更好的选择，这样用户就可以在我们创建用例的过程中与我们合作，这些用例代表了业务流程及其与系统的交互。

这是一个简单的用例，但很容易确定不涉及系统交互的业务流程步骤（步骤 1）和系统交互步骤（步骤 2-6）。可以或多或少地对交互进行详细描述，也可以对业务流程中不涉及系统的部分进行详细描述。用例可能比用户故事详细得多，通常旨在为开发人员提供完整的需求。
如果在捕捉初始需求时使用了用例，那么我们只需付出很少的额外努力就能获得收益。如果没有，用例则是获取关键信息的最简单、最快捷的方法之一。
我们将在第 6 章中了解如何在建立 UA 测试基础时部署用户故事和用例。

2.10 小结
在本章中，我们了解了什么是业务需求，以及如何为开发人员和 UAT 捕捉这些需求。我们还了解到，除了详细的需求外，还应该记录业务意图和用户期望，以便这三个方面共同满足业务目标和期望。

我们了解到有不同类型的需求，而 RS 不仅仅包含需求。我们认识到了一些可能会导致问题的陷阱，也认识到了为什么无论最初的要求有多好，都很少能在项目结束时不过时。创建测试基础就是为了克服这些问题，生成有效且最新的文档，并据此生成测试。
用户故事和用例等技术使我们能够增强 RS，为 UAT 提供最新且合理完整的测试基础。

2.11 参考答案
习题 2.1.2
该要求涉及工作人员提出的所有费用、采购订单、缺勤等申请。
该要求不涉及无需批准的员工变更，如更新地址或银行账户信息。
该要求按重要性排序，但我们不能从单个要求中看出该排序是与整个 RS 有关，因此是 RS 中第 34 位最重要的要求，还是与该要求所属的部分有关。
该要求具有高度优先性。

2.11.1 选择题

Q1 A
答案 B 不正确。业务意图与 UAT 无关，即使没有 UAT 也需要业务意图。
答案 C 不正确，尽管它是 UAT 测试的系统的另一个重要方面。
答案 D 不正确。业务目的是业务存在的总体原因。业务意图是在该业务中建立或改变信息系统的原因。

Q2 C 答案
A 不正确。业务需求是 UAT 测试基础的重要部分，但策略定义了我们将如何进行验收测试。
答案 B 不正确。虽然业务需求是用户体验测试基础的一部分，但它们不是完整的测试基础（用户期望是用户体验测试基础的另一部分）。
答案 D 不正确，因为答案 B 不正确。

问题 3 D
答案 A、B 和 C 都是对需求的可能限制，因此答案 D 是最佳答案。

问题 4 B
答案 A 不正确。需求需要有足够的相关细节使其清晰，但必须避免不必要的细节，因为这会使需求不清晰。
答案 C 不正确。不同需求的技术细节水平会有所不同，但需求是关于用户需求的，因此应该用用户术语来表达。这并不一定使它们成为非技术性的（例如，用户可能是工程师，需要在需求中提供技术细节），但技术细节应保持在最低限度，以符合清晰度和可读性。
答案 D 不正确。这是一个好需求的描述。

2.11.2 简答题

你是项目的新利益相关者，要求你阅读 RS 以了解项目的内容，但你不理解部分、大部 分或全部的需求。你会怎么做？
最好先与你的队友和团队领导确认一下，看看你需要达到什么样的理解水平。如果已经为 UAT 设置了专门的培训，您显然会从中受益；如果没有，您可以建议设置相关培训。如果其他办法都不奏效，您可以酌情咨询用户、开发人员和业务分析人员，但要记住，他们可能都是大忙人。
你需要很好地理解需求，才能设计和/或实施测试。如果你认为这可能是一个问题，你就需要把它标记出来。

RS 与 UA 测试基础的区别是什么？
RS 是需求的正式表述，已记录在案用于开发，随后可能会更新。统一用户评估的测试基础是设计和实施统一用户评估测试所需的文件集。测试基础需要包括用户期望的定义和业务流程的描述，以及业务需求的最新版本，包括自文件最初批准以来所做的任何更改。因此，用户体验测试基础通常是对 RS 的更新和扩展。