7 测试设计

第 3 章介绍了测试开发流程（TDP test development process），即创建 UAT 测试的流程。测试开发流程的三个组成部分，即测试条件、测试用例和测试过程规范（测试脚本），每一个都代表了一个流程或层次结构中的一个步骤，这个流程或层次结构从需求定义开始，到 UAT 结束。

在本章中，我们将探讨这一层次结构，更详细地解释如何建立测试条件、测试用例和测试脚本，并将其直接应用到我们的 UAT 实践中。

本章涉及的主题

• 测试设计的层次结构
• 确定测试条件
• 设计测试用例
• 设计测试脚本
• 数据创建

7.0 习题

7.0.1 选择题：

• 1. 可追溯性之所以重要，是因为：

A. 它将测试条件、案例和脚本与需求联系起来 B. 它是风险的衡量标准 C. 它确保测试数据的完整性 D. 它确保每个需求都有唯一的 ID

• 2. 测试条件是：
     A. 测试必须满足的条件 B. 作为方案一部分进行测试的功能组合 C. 关于可通过测试用例验证的功能的声明 D. UAT 的退出标准
• 3. 在设计测试用例时，您最应该注意哪三件事？
     A. 需求是否已涵盖？
     B. 有多少测试人员？
     C. 案例是否涵盖流程？
     D. 用户界面是否得到充分测试？
     E. 哪些案例风险最大？

4. 以下哪项是应用 BVA 的最重要原因？
   A. 将否定测试用例的数量保持在最低水平 B. 识别所有否定测试用例 C. 识别最有可能发现问题的否定测试用例 D. 识别相等数据集之间的分区

7.0.2 简答题：

1.测试用例已经创建。在决定测试用例的顺序时，项目经理希望您关注风险，而项目发起人希望您关注流程。您如何决定它们的顺序？
2.在 UAT 的第一天，一半的团队成员因感冒请假。您将如何决定是否进行测试？您认为可以进行哪些测试？

7.1 测试设计的层次结构

测试设计：将一般测试目标转化为实际测试条件和测试用例的过程。

测试设计的层次结构如下：

• 业务需求代表业务需要。
• 测试条件说明应测试给定需求的哪些方面。
• 测试用例说明每个测试条件适用的前提条件、输入、预期结果和后置条件。
• 测试过程规范列出 UA 测试人员对每个测试用例要执行的步骤，并确定每个测试要使用的测试数据。

测试设计流程从层次结构的顶层开始：从测试基础中确定测试条件，将测试条件转化为测试用例，并用测试用例创建测试脚本。
通过为需求分配一个唯一的参考编号，并将所有后续文档回溯到其产生的需求，来保持文档层级之间的关系。这就是所谓的可追溯性。可追溯性是确保测试设计涵盖 RS 中所有需求的关键。它在管理文件更改方面也非常有价值，这样当层次结构中的任何文件更改时，就能很容易地找到哪些相关的测试条件、测试用例和测试脚本也必须更改。
测试设计并不只涉及如何编写测试条件、测试用例和测试脚本的单个例子；它还定义了如何以高效和有效的方式管理编写所有测试条件、测试用例和测试脚本的过程。所有测试设计阶段，尤其是测试条件和测试用例的创建，都应在 UAT 团队最终用户的协助下进行，将 UAT 的专业知识与业务的专业知识结合起来，以创建最佳和最相关的测试材料。至少必须有一名业务代表签字确认需求、测试条件和测试用例的完整性和准确性，但这并不能取代最终用户直接参与测试设计。由他人定义的测试几乎肯定缺乏独特的最终用户视角，而最终用户视角正是 UAT 降低风险的有效工具。

7.2 确定测试条件

测试条件是创建测试的第一步。测试条件是代表需求某些方面的逻辑语句。换句话说，一个测试条件就是 “可以测试的东西”。每个测试条件代表一个功能的单个组件，可被评估为真或假，只有当所有条件都为真时，该功能才能正确实现。

根据业务需求的编写方式，一个需求可以产生多个测试条件。在第 3 章中，我们使用了一个登录示例，并指出了一些需要测试的变体。每个变化都等于一个测试条件。我们将使用相同的示例，更详细地了解登录系统的要求。

测试条件必须代表测试的每一个变体，这些变体加在一起才能确认需求已被满足。我们在第 3 章中确定的三个测试条件如下：

• 如果输入了有效的用户名和正确的密码，用户就可以登录系统。
• 如果输入的用户名有效，但密码不正确，则会出现错误信息。
• 如果输入了无效用户名和密码，则会出现错误信息。

以上是需求 4.1 的相关测试条件，但我们还可以根据需求 4.1.1 至 4.1.3 确定更多条件。

• 当输入有效的大写用户名和正确的密码时，用户将登录系统。
• 当输入有效的小写用户名和正确的密码时，用户将登录系统。
• 当输入有效的大小写字母用户名和正确的密码时，用户即可登录系统。
• 当输入的有效用户名和密码少于 6 个字符时，会出现错误信息。
• 如果输入的用户名有效，但密码不含数字，则会出现错误信息。

更有效的做法是记下所有可能的测试条件，即使它们之间似乎有重叠。合并重复的测试条件比发现遗漏的测试条件更容易。无论如何，测试条件清单，即使是基于需求的清单，也不能保证是详尽无遗的，而只能是我们能想到的要测试的东西的清单。

让团队成员或其他最终用户对测试条件进行审核，应能获得有用的反馈，并为进一步的测试条件提出想法。在我们的例子中，什么是重叠取决于错误信息。如果需要出现独特的错误信息，例如 密码长度至少为六个字符 “或 ”密码至少包含一个数字"，那么需要的测试条件就比所有登录失败的通用错误信息要多。
由于条件 4、5 和 6 都要求输入有效的用户名和密码，其中一个条件是用户名以大写字母输入，第二个条件是密码以小写字母输入，第三个条件是用户名同时以大写字母和小写字母输入，因此不再需要测试条件 1。你也可以说不需要测试条件 6，测试条件 4 和 5 的组合已经足够了。另一方面，如果把条件 4（检查是否允许输入全大写的密码）和条件 7（检查是否不允许输入少于 6 个字符的密码）结合起来，就无法在一次测试中同时给出两个条件的答案。
如果我们输入一个少于 6 个字符的大写密码，但登录成功了，我们就知道出现了问题，要求 7 没有得到满足；但如果登录失败，我们就无法从测试结果中推断出系统是否允许用户名中包含大写字母。
创建测试条件是测试设计过程中的一个关键阶段。对于简单的功能，如登录系统，你仍然可以从逻辑上推断出需要进行哪些测试，而无需写下测试条件，但当涉及到更复杂的系统功能时，能够设想出所有可能的测试条件就至关重要了。为了确保所有需求都已涵盖，并且足够详细，创建一个矩阵可能是有用的。矩阵在测试中应用广泛，有助于将一个文档的内容与另一个文档的内容进行比较。例如，矩阵可以显示为每个业务需求创建的功能需求。
同样，也可以创建一个电子表格，横向显示需求 ID 和需求描述，纵向显示需求旁边的每个测试条件。表 7.2 是将 Excelsior 合同功能相关条件与业务需求相匹配的矩阵示例。需求确定了所需的功能和为测试功能是否有效而应进行的基本测试的条件。

这类矩阵便于所有相关方理解并签字确认。
大多数实施都会产生大量测试条件，可能需要进行风险分析，以确定哪些测试条件最重要。将测试条件输入电子表格或矩阵的另一个好处是，测试条件可以与需求（以及需求的优先级）相联系，创建测试用例所需的信息也可以添加到同一张电子表格中。

7.3 设计测试用例

我们以前学过，测试用例指定了测试条件是否为真的前提条件、输入、预期输出和后置条件：

• 前置条件和后置条件分别确定了测试执行前系统必须处于的状态和测试执行后系统将处于的状态。了解每个测试的开始和结束 “状态 ”有助于确定测试的顺序，以实现最高效的 UAT 会话。如果一些测试用例的先决条件是用户已登录系统，那么首先运行登录测试是合理的。这样，执行非测试任务所需的时间就会降到最低。

• 测试输入数据说明为测试条件而输入系统的内容。定义测试用例的数据项是准备 UAT 测试数据的重要部分。上例中除非实施是为了更改或增加现有系统（在这种情况下，可以复制真实用户账 户），否则就需要创建带有用户名和密码的测试账户。这些账户必须支持访问新系统的不同用户角色。

• 测试用例的预期输出是我们在执行测试时能够立即、客观和一致地确定测试是通 过还是失败的重要因素。

• 测试用例包含了测试所需的所有基本信息，但没有最终用户所需的表格（测试脚本）来确定测试执行时使用的特定数据和记录测试结果。

下面是一个登录程序的简单测试用例。

7.3.1 实用的用户测试

在第 3 章中，我们讨论了使用标准测试用例设计技术和更实用的方法来构建测试的不同方法，如基于需求的测试、基于风险的测试和基于流程的测试。
基于需求、基于风险和基于流程的测试。事实证明，测试用例设计技术非常有助于生成具体的测试用例，以支持我们的总体方法，但我们也应利用我们的应用常识和经验，生成对用户有用的测试，并提供有意义的结果。
我们还了解到，我们测试的是一个系统，而不仅仅是一个软件。我们对软件的性能是否符合技术规范并不特别感兴趣，因为开发人员和测试人员已经从这个角度对系统进行了测试。我们关注的不是是否符合技术规范；我们使用 RS 作为测试计划的基础，主要是因为它为我们的操作提供了一个明确的范围。

7.3.2 关注重点--按风险进行测试

基于风险的测试理念在这里很有用。如果我们了解了系统的哪些方面最重要，如果这些方面无效可能会导致严重问题，也就是说，如果这些方面代表着风险，我们就可以按风险等级确定测试的优先次序，并首先测试风险最高的领域。首先，我们可以确定每个需求或每组需求的风险等级，并按优先顺序排列。这至少是开发测试用例的一个实用起点。

7.3.3 在边缘进行测试

边界和边缘容易出现问题，因此最好将注意力集中在边缘。为此，您可以使用 BVA，也可以不使用 EP。只要发现边界，就可以利用 BVA。
请记住，我们不仅对程序内的边界感兴趣。业务流程也有边缘和边界，这些也是探索的好地方。
因此，在为业务流程构建测试用例时，要确保其中一些测试用例能探索流程的边缘。

7.3.4 保持测试简单--通过实际场景进行测试

如果我们知道最终用户希望如何使用系统，以及哪些业务流程将与系统接口，我们就可以设置一些代表常用流程的实际场景，并围绕这些场景构建测试用例。流程集合会有一些模式--分层模式、基于时间的模式、基于客户的模式或其他模式。我们可以利用这些模式将类似的流程联系在一起，这样我们就可以使用相对较少的测试用例和测试数据集，一次性测试整个系统区域。
还需要考虑的一点是测试的排序。请记住，在定义测试用例时，我们遇到了 “执行前置条件 ”和 “执行后置条件”。这不过是定义了运行特定场景所需的系统设置方式（即执行前置条件）和测试场景完成时系统所处的状态（即执行后置条件）。确定这些前置条件和后置条件的好处是，我们可以将它们匹配起来：一个测试场景的前置条件与另一个场景的后置条件相匹配，就可以在该场景之后立即运行，而无需额外设置。
我们还可以用其他方法将测试方案连接起来，使测试更有意义，运行起来更方便，从而节省设置时间。我们可以按日期和时间对测试进行排序，使每个场景都与其前一个场景有自然的日期和时间顺序。如果有的场景没有时间间隔，我们就可以运行它们，而无需重新设置系统日期和时间。同样，如果一个测试更新了数据库，另一个测试读取了数据库，我们也可以使用自然顺序来节省时间。

关键的思路是按场景组织测试，然后寻找可以利用的模式，使测试更容易、更自然。UAT 的总体目标是确定系统是否能被预期的最终用户有效使用，所有测试都应反映这一点。我们需要的是简单的测试--易于实施和解释--直接测试用户需要发生的事情。

7.3.5 专注于典型场景和不需要的场景

如果难以按照关键性、频率或价值来确定测试场景的优先次序，我们可以利用以往的经验来确定什么是 “典型 ”场景，即经常使用的场景，它可能是其他更复杂场景的基础。这就是 “主流 ”活动的测试。即使它们不是最关键的，也会是最经常使用的，因此它们出现问题会让用户感到沮丧，并可能损害工作效率。
同样，我们也可以寻找那些最可怕的噩梦--那些绝对不应该发生的事情。如果我们对这些情况进行测试，就会发现最糟糕的情况实际上不会发生，从而增强信心，或者我们可以及早发现可能对验收造成致命影响的情况。这就是极端情况的一个例子；一些处于系统行为边缘或边界的情况。在这里，BVA 测试用例设计技术非常有用，它可以测试相对较少的处于或接近该边界的情况--要么在边界内，要么在边界外--并获得系统不会偏离边界的信心。

例外是指不符合正常规则的情况。它们与边缘情况类似，因为它们可能会产生与系统主体不同的数据处理方式。如果这些区域出现任何问题，可能只涉及系统中相对较小的区域，但却会产生那些似乎永远无法解决的神秘错误。
在 RS、业务流程、用户界面或其他你能想到的地方查找任何异常情况。这样做是值得的。

7.3.6 场景组合

从端到端测试的想法到关联情景的想法，只是一小步。
建立一个代表典型工作日的场景序列是将场景联系在一起的一种方法。这不仅能使测试更切合实际，也更容易实施，而且在许多情况下，一个测试的后
条件会自动匹配另一个测试的前提条件。再进一步，把工作日作为一周、一个月、一个时期或一年的开始或结束，我们就可以测试一些对企业来说最重要的边界情况了。
在发明和连接情景以实现多种测试目标时，只要有一点想象力，就会事半功倍。它能节省时间、增加真实感、提高效率，最重要的是，它意味着 UAT 能够在可用时间内最大限度地完成测试任务。

7.3.7 利用业务流程

在此阶段，业务流程应该已经记录在案。它们几乎肯定会涉及数据输入和输出数据的使用，以及一些与计算机的交互对话。我们需要确定这些流程，以便对业务流程进行端到端测试。在端到端测试中，我们有机会引入感兴趣的特定测试用例，因此我们需要用在端到端测试期间将流经系统的数据构建场景。这样，我们才能对流程、系统与流程的接口以及流程中的特定数据处理有信心。

7.3.8 循环测试

测试的设置既费时又费钱，因为我们必须测试许多场景，而每个场景的起始条件可能都不相同。如果我们能将具有共同起点或使用共同测试环境的测试组合在一起，就能使测试更有效、更快速、更经济高效地执行，同时也更易于管理。
我们还可以通过循环运行测试来测试系统中与时间相关的方面。每个测试周期都有不同的时间起点和系统状态，因此可以先运行输入周期，然后再运行更新周期，以此类推。这样，我们就能根据之前的周期为每个周期生成输入数据。

7.3.9 关注用户界面

让用户在系统投入使用前对其进行测试的主要原因之一，是用户对用户界面是否真正 “有效 ”有着独特的见解。可能对系统进行过详细的可用性测试，也可能没有，但无论是否进行过，系统都需要用户的评估。
屏幕布局有多 “舒适”？如何输入数据？字段位置是否合理，便于输入数据？执行最常见操作的速度如何？

你能达到系统规定的吞吐量吗？用户有一个良好用户界面的内部规范，系统需要根据该规范进行测试。这些测试将是非正式的，主要是嵌入到其他测试中，如业务流程测试，但至关重要的是，要通过事件报告来强调对用户界面的关注。
这与可用性测试不同，后者是技术性更强的系统测试，但用户将与系统进行交互。如果在开始测试之前，你已经接受了如何使用系统的培训，那么你就能够发现培训中没有准备好的任何用户界面问题，而且你对哪些工作得好，哪些工作得不好的见解也应该记录下来。因此，虽然我们不会设计可用性、可靠性、可用性或其他一系列专业测试，但我们可以就系统的任何方面提出事件报告，因为这些方面会让我们担心，当新培训的用户要使用该系统交付实际结果时，系统会有怎样的表现。

7.3.10 考虑性能

与用户界面评估相关的是，我们需要了解我们在处理业务流程数据要求时有多方便快捷。这不是一个正式的性能测试（在系统测试过程中很可能已经进行了一些正式的性能测试），但它是对系统是否能提供所需的吞吐量以实现建议的业务效益的最后检查。

7.3.11 负面测试

我们在研究 BVA 时探讨了一些负面测试案例，但需要注意的是，UAT 通常侧重于正面测试。正面测试是指证明应该发生的事情确实发生了--例如，功能可以工作。
负面测试则是确保不应该发生的事情不会发生。这是一种更困难、更耗时的测试方法，因为负测试用例比正测试用例多得多。下面是一个非常简单的例子。

输入字段定义为六个字符的字母字段。有效输入最多有六个字母字符。任何其他输入都是无效的，都会引发错误信息。
作为正面测试，我们可以输入一个字母字符、两个字母字符，以此类推，最多输入六个字母字符。系统应根据输入的数据做出响应。
阴性测试现在必须填写所有其他可能性：空字段、包含五个字母字符和一个数字字符的字段、包含一个或多个非字母和数字字符的字段。
包含一个或多个非字母数字字符的字段。一套完整的否定测试需要包括不在 1 到 6 个字母字符范围内的 6 个键盘字符的所有可能组合。
这令人生畏，但它重要吗？显然，重要的是要确认系统能够识别无效输入并作出适当的反应，因为用户在未来的某个时候难免会犯错误，我们不希望系统的反应方式会造成问题（例如 “冻结 ”输入屏幕）。

我们不可能对每一种情况都穷尽所有可能的负面测试，因为这将耗费无限的时间。同样，我们也不能忽视负面测试，因为不恰当的响应所造成的影响是未知的。必须有一个折衷方案。
最有效的折中办法是，利用我们已经了解的用户行为（如最常见的键入错误），在每个正面测试中增加一些负面测试。如果我们对用户最容易犯的错误进行一些思考，并围绕这些错误进行有限的负面测试，我们就能确保系统比原来更加强大。负面测试是利用 EP 和 BVA 优点的一种好方法。

7.3.12 不应该测试的东西

为了加强前面关于可用性测试和性能测试的内容，我们不应该测试已经测试过的东西，也不应该测试我们在技术上没有能力测试的东西，更不应该测试我们没有测试环境的东西。

7.3.13 回归

如果我们提出的事件报告发现的缺陷随后得到了修复，我们就需要重新运行最初失败的测试。我们还需要安排一些回归测试，以检查所做的更改是否影响了系统的其他部分。

7.3.14 测试视角

在考虑并权衡了所有这些替代方法后，请始终牢记 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

7.4 设计测试脚本

7.4.1 详细还是概要？

有些用户测试设计得非常详细，用户只需执行测试脚本并报告程序是否通过。如果你的目标是对系统进行精心设计的脚本演示，涵盖所有需要测试的过程和输入，那么这是一种很好的测试设计方法。

如果你的目标是发现用户在实际使用系统时会遇到的问题，那么你的任务就比较困难了。用户体验测试的实施成本相当高，而且有可能得不到什么有用的信息。一个好的用户测试必须为用户的认知活动留出足够的空间，同时为用户提供足够的结构，使其能够以对解决问题的人有用的方式报告结果。

答案是，既要进行概要测试，也要进行更详细的测试，以便捕捉需要涵盖的所有流程和数据，以及最终用户以更直观的方式使用系统时可能出现的问题。
概要测试可以包含 “登录并预订培训课程 ”这样的少量信息，而详细的测试脚本则可以详细说明测试用例中定义的所有步骤。

7.4.2 编写简单的测试脚本

测试脚本是运行测试所需的最底层细节。通常，当我们提到测试脚本时，我们指的是详细描述测试步骤和预期结果的正式文件，并允许测试人员对照这些详细步骤指出任何错误。测试脚本也可以是非正式的，你可能会发现很多有用的反馈都来自于测试脚本，其中只简单地写道：“登录并申请休息一天”。正式测试是 UAT 所必需的，因此一定要记住，从非正式测试中获得的反馈可能与是否满足特定要求没有直接关系。我们可以通过创建一个简单的脚本，轻松地将非正式测试正式化。

7.4.3 测试脚本与测试用例

如果测试用例描述了需要测试的单一功能，那么每个测试用例都需要一个测试脚本。每个测试用例都应创建一个测试脚本，因为测试脚本的目的是向 UA 测试人员提供详细的测试步骤。基本上，对于给定的测试计划，只需运行一个测试脚本，就可以认为测试用例已执行。如果需要运行多个测试脚本，则说明测试用例包含多个条件，需要更多的测试脚本（每个条件一个）。
然而，测试脚本比这更灵活。一个测试用例可以用一个测试脚本以不同的输入数据运行多次，也可以在同一套测试脚本中测试多个不同的数据项，以涵盖多个不同的测试用例。
测试脚本通常不是单独执行的，而是组合成一个集合，代表一种情况，可能与单个业务流程或用户界面的不同元素有关。测试场景应代表一个流程或动作，这些流程或动作在逻辑上相互关联，或代表测试同一字段或功能的不同数据项。
示例：合同系统

本示例涉及 Excelsior 系统中名为 “合同 ”的部分。合同功能允许用户创建、管理和存储企业与供应商和第三方签订或打算签订的合同。有两种用户角色以特定方式与合同功能交互：

• 合同团队成员可以创建和管理合同，但不能批准合同。
• 合同团队经理不能创建或管理合同，但可以批准合同。

合同系统允许用户从代表合同状态的多个不同视图查看和访问合同：

• 新
• 进行中
• 等待批准
• 已批准
• 已拒绝
• 已签署
• 存档。

以下测试脚本的目的是检查系统是否能在 “进行中 ”屏幕上为两个用户角色分别显示正 确的状态、列、数据和链接。进行中列出了所有尚未定稿和尚未送交审批的合同。

• 测试脚本：检查 “进行中 ”视图的功能

目的：确保 “进行中 ”视图包含预期的列和正确的数据映射，显示与用户角色相适应的状态为 “进行中 ”的文档。

测试标准/步骤：

1.检查 “进行中 ”视图是否包含 “合同团队成员 ”角色用户的预期列。检查文档详细信息是否符合合同小组成员用户的预期，视图上的数据内容是否映射到正确的列，屏幕上的链接是否按预期运行。
2.检查 “进行中 ”视图是否包含具有 “合同团队经理 ”角色的用户所期望的列，检查具有 “合同团队经理 ”角色的用户所期望的文档详细信息，视图上的数据内容是否映射到正确的列，以及是否向 “合同团队经理 ”提供了批准文档详细信息的链接。

测试 #1 - 检查 “进行中 ”视图是否包含具有 “合同团队成员 ”角色用户的预期列。

测试 #2 - 检查 “进行中 ”视图是否包含具有 “合同团队经理 ”角色的用户所需的列。

请注意，如上例所示，测试程序和测试用例中的信息，如预期结果和前提条件，也可以出现在测试过程规范中。这样，无需阅读测试步骤，就能更容易地理解和安排每个测试用例。

7.5 数据创建

创建业务用户可用于测试的主数据是准备 UAT 的关键部分。在执行任何测试脚本之前，系统中必须有正确的测试数据，不能因为测试团队无法选择或使用正确的数据而导致测试失败。

7.5.1 什么是测试数据？

创建测试用例时，会在测试用例上注明输入数据，或为 UAT 提供可能的输入值列表。因此，所有要测试的输入数据都应是已知量。测试数据还包括为成功完成测试而需要在系统中提供的数据。测试数据包括任何类型的输入、应用程序加载的任何类型的文件或从数据库读取的条目。这可能需要创建登录名和密码，以及测试人员必须验证或使用的任何数据。要确定需要哪些数据，一个很好的起点是查看业务流程，然后再查看脚本。例如，如果您正在测试一个培训系统，请上传培训课程样本供测试人员在 UAT 期间使用。
输入数据可以包含在测试脚本中，也可以按测试用例以列表或电子表格的形式单独提供，并注明每个脚本中应使用哪些数据。
对于任何测试用例或测试脚本来说，测试所需的数据都是前提条件，因此我们必须在测试设计时考虑所有测试数据。这项工作越早做越好，因为为测试建立用户账户并填充数据可能会很耗时，而且需要专家的支持，而这些专家可能无法在短时间内提供支持。

根据 UAT 的数据要求，系统中可用的数据可以是以前的测试数据、标准生产数据或实时环境中的数据副本。
也可以在一个测试脚本中创建数据，以支持后面的测试脚本。例如，如果一个测试脚本要求用户体验测试员创建一个新账户，那么后面的测试脚本可能需要测试员登录到一个现有账户，为此可以使用之前创建的账户的详细信息。标准生产数据不可能完全不变，可能需要添加一些测试专用数据。
如果要求检查系统的性能，则需要大量的数据集。如果系统从大型数据库获取数据或更新数据，那么在测试系统性能时，大数据量就会发挥重要作用。

显然，在所有条件都相同的情况下，数据量极少的系统会比数据量大的系统更快地完成这些任务。如果你需要的实时数据无法手动创建，那么你可以要求项目经理从实时环境中提供这些数据。如果做不到这一点，那么作为系统测试的一部分，应该已经进行了一些性能测试，可以让业务代表对系统的性能放心。
实时环境是一个诱人的数据来源，但要注意，使用实时数据副本或实时环境可能会违反《数据保护法》，损害商业敏感信息，并给组织带来重大风险。
如果考虑使用实时数据，必须获得最高级别的批准，即使获得批准，也必须将数据安全放在首位：

• 是否对数据库进行了加密保护？
• 测试数据是否被泄露？
• 谁负责确保测试数据的安全？
• 数据是否包含敏感的员工或客户信息？

即使所有这些问题都能得到满意的回答，请记住，如果在测试过程中显示了真实数据，即使数据库已加密，也可以通过简单的屏幕抓取下载或复制。如果使用真实数据对 UAT 至关重要，并且使用真实数据已获得批准，那么可以使用数据屏蔽来保留数据属性，同时创建新的非个性化数据。最后，请记住，实时数据的传输可能会覆盖任何手动创建的测试数据。

7.5.2 如何定义好的测试数据？

完美的测试数据是最小的数据集，能让 UAT 识别系统中的所有错误。测试数据显然应包含被测系统的所有方面，但不应超出准备测试数据和运行测试的成本和时间限制。这一规则的例外情况是，使用实时环境的副本比从头开始或从标准生产数据中创建测试数据更快，在这种情况下，数据可能比需要的多，但提供这些多余的数据不会影响项目的时 间表或成本。
准备适当的测试数据是 UAT 准备工作的关键部分。在成本和时间方面，测试数据集应尽可能接近完美。

7.5.3 测试脚本是什么样的？

一份完整的测试脚本应确定测试条件和测试用例。它还必须定义测试前提条件、输入数据、预期结果和后置条件。最后，它还必须包含运行测试时使用的测试数据，这些数据可以嵌入测试脚本，也可以存在测试脚本引用的文件中。
下面是测试脚本的一个示例。有许多有效的变体，但有效的测试脚本必须包括示例中记录的细节。

示例 :Excelsior 的要求之一是，用户只能访问他们被允许访问的系统部分。例如，公司的每个人都可以访问人力资源模块，但只有某些角色才允许访问合同模块。这意味着系统需要检查已登录 Excelsior 的人员是否在允许访问他们试图访问的特定模块的名单上。这可以通过系统登录详细信息来完成。

测试方案

• 1.检查未经验证的用户是否无法登录 Contracts。
• 2.检查经验证的用户可登录 Contracts。

这些都是测试脚本应包含信息的简短示例，单独运行时可能不是最有效的。
问题
1.您认为还应进行哪些相关测试？
2.这些测试可以作为哪些其他测试方案的一部分来运行？

示例：数据输入表

您可以将要输入的测试数据作为测试脚本的一部分，以便在测试描述栏中给出要输入 的值。但是，如果希望最终用户在同一屏幕上测试多个不同的值，也可以考虑提供一个单独的数据输入表，与测试脚本一起使用。在本章中使用的 BVA 示例中，为了节省时间，您可能希望测试人员尝试输入 0、1、6 和 7 个字符，作为单个字段测试的一部分。这些值可以单独列在一张纸上，与测试脚本一起使用。当需要测试一组复杂的值组合时，数据输入表也很有用，例如需要测试多个不同类型的合同，每个合同都包含不同的字段，需要不同的用户角色来访问。将数据输入值与测试脚本分开，还能在测试人员减少的情况下更好地控制测试内容，并避免从缺失的测试人员脚本中推断数据。请注意，在可能的情况下，让最终用户根据真实例子（但不使用真实数据）、客户或地址详情输入信息，会增加测试的实用性。
阴影区域表示该字段无需填写。

请注意，数据输入表可以包含每个测试脚本的相关数据，也可以包含多个条目，这些条目应作为同一测试脚本的一部分加以应用。测试人员应如何使用数据输入表应包括在 UAT 培训中。

7.6 小结

在本章中，我们以一种实用的方式展示了测试设计的层次结构，即从 UAT 的测试基础中导出测试条件、测试用例和测试脚本，然后添加测试数据，使测试脚本能够运行。本章通过实例对这些技术进行了说明，并在 UAT 结构化方法的第二步中将这些技术应用到我们的案例研究中。
阅读本章后，你应该能够回答以下问题：

• 如何从测试基础中提取测试条件？
• 如何创建测试用例来验证测试条件？
• 如何选择有效的测试用例来练习系统的不同方面？
• 如何从测试用例中构建测试脚本？
• 如何创建测试数据以填充测试脚本？

7.7 参考答案

7.7.1 问题1

两个测试脚本之间没有任何联系，因此使用同一台 UA 测试先进行第一个测试，然后再进行第二个测试是合乎逻辑的。一个脚本的输出不等于第二个脚本的输入或输入的一部分。实质上，两个脚本都在检查同一屏幕上的正确信息，但登录的角色不同。如果有时间，UAT 应该对整个合同流程进行端到端测试。因此，让一名测试人员以团队成员的身份登录，另一名测试人员以团队经理的身份登录（理想情况下，测试人员既是团队成员又是团队经理），让他们使用由团队成员创建的相同合同，并一起完成流程的所有阶段。

团队成员可以将合同发送给经理审批，经理也可以审批合同，同时他们都要检查所使用的屏幕是否符合要求。
可以测试一些替代流程，包括拒绝合同，这代表了一种替代路径。如果测试脚本由同一测试人员按顺序执行，测试人员就必须以团队成员的身份登 出，然后再以团队经理的身份登录，这将非常耗时，而且在我们的示例中，这并不代表 用户在实际生活中将如何使用系统。

7.7.2 问题2

几乎有无数的条目不符合允许条目示例的标准，因此是一个否定的测试。可以通过使用用户或测试人员生成的代表错误类型的情景，将数量限制在某些类型的负面测试中，并加以细化。
通过用户或测试人员生成的场景来完善，这些场景代表了用户最有可能犯的错误：
1.字符数错误；根据 BVA，我们可以尝试输入 0、1、6 和 7 个字符。
2.将必填字段留空；上一示例中的 0 字符条目已经涵盖了这一点。
3.字符类型错误，* & = -；我们希望找到最可能的候选字符，例如外来字母字符 é。
4.大写字母。
5.插入有效字符但同时按下 shift 或 control 键产生的任何字符。

7.7.3 选择题

• Q1 A

答案 B 不正确。可追溯性是一种机制，而不是一种措施。
答案 C 不正确。可追溯性可以确保对每个需求进行测试，但不能确保测试数据完整。
答案 D 不正确。对可追溯性来说，每个需求都有一个唯一的 ID 是很重要的，但可追溯性不是实现这一点的手段。

• Q2 C
  答案 A 不正确。这是测试的先决条件。
  答案 B 不正确。功能集合不称为测试条件。
  答案 D 不正确。退出标准与测试条件不同。

• Q3 A、C、D
  答案 B 不正确。测试人员的可用性与测试设计无关，而是计划因素。
  答案 E 不正确。风险是测试策略的主要驱动因素，可用于确定测试的优先次序，但个别 UA 测试用例主要针对需求、流程和用户界面。

• Q4 C
  答案 A 不正确。BVA 的确有助于尽量减少测试用例总数，但并非所有测试用例都是负面的。
  答案 B 不正确。BVA 无法识别所有负面测试用例。事实上，没有一种技术能做到这一点；负面测试用例的数量可能非常大。
  答案 D 不正确。边界识别分区的边缘，但 BVA 是用于测试边界，而不是识别边界。

7.7.4 简答题：

1. 测试用例已经创建。在决定测试用例的放置顺序时，项目经理希望您关注风险，而项目发起人则希望您关注流程。如何决定它们的顺序？

最重要的是要知道项目经理所说的风险是什么意思，以及他们希望降低哪些风险。系统的某个部分可能是成功或失败的关键，如果失败将产生最大的财务影响，或者可能是系统中被视为高调的部分。业务流程可能已经涵盖了高风险和高调的功能。如果没有，应确保项目经理和其他利益相关者就应首先测试哪些功能达成共识。如果系统中被认为风险最高的部分是日常流程的一部分，则可将这两种方法结合起来，再加上您希望纳入的任何其他考虑因素，以创建一种符合项目经理和发起人标准的方法。

2. 在 UAT 的第一天，一半的团队成员因感冒请假。您将如何决定是否进行测试？您认为可以进行哪些测试？

您可能需要做一些调查，将需要整个团队输入的流程或复杂的、需要多个不同用户一起测试的流程与简单的或独立的流程区分开来。如果这项工作需要花费大量时间，或者会对测试造成很大干扰，则可能需要推迟 UAT。