3 测试基础

我们从 UAT 的定义中知道，我们设计的测试必须是正式的，因此我们需要知道如何进行正式测试，尽管我们的目标是根据我们对用户需求的常识性理解来生成简单的测试。我们还需要一系列不同类型的测试，以涵盖 UAT 的所有方面，因此我们需要一系列设计技术。

在本章中，我们将建立我们需要的测试工具包，以便在构建 UAT 测试时能有效地使用它。在此过程中，我们将解释需要注意的关键术语和基本流程，然后构建几个简单的测试，作为练习技能的方法。
本章涉及的主题

• 什么是测试？
• 测试类型
• 测试过程
• 测试用例设计技术
• UAT 的测试方法
• 评审

3.0 习题

3.0.1 选择题

• 1. 以下哪项最恰当地描述了测试覆盖率？
     A. 测试覆盖率是已测试功能与总功能的比率
     B. 测试覆盖率是对已运行测试的数量的统计
     C. 测试覆盖率是对一个测试所测试的不同事物数量的衡量
     D. 测试覆盖率是测试的范围
• 2. 以下哪项是使用评审来评估文档的好处？
     A. 评审让测试人员有机会批评开发人员的工作
     B. 执行评审的成本很低
     C. 评审能发现文档中的所有缺陷
     D. 评审鼓励团队合作
• 3. BVA 测试用例设计技术测试什么？
     A. BVA 测试用户是否能输入无效数据
     B. BVA 测试系统是否能识别数据是否在指定范围内
     C. BVA 分析系统在极端条件下的表现
     D. BVA 生成的测试用例应该全部失败

3.0.2 简答题

• 1.您所在的组织不愿意让 UA 测试人员参与审查过程。克服这种不情愿的最佳方法是什么？
• 2.在您开始作为用户体验测试员工作之前，我们为您提供了一个培训课程。您对为期一天的课程有什么要求？假设您可以接受为期三天的培训。您的要求会有哪些变化？

3.1 什么是测试？

"测试"这个词会让人联想到什么？它可能是用来测试汽车的假人，以确保汽车可以安全驾驶；也可能是我们在办公室使用的电子表格上进行的基本检查；还可能是专业开发人员进行的更严格的测试，以确保他们的代码在提交之前可以正常工作。这些都不是我们需要为 UAT 做的测试。
我们所需要的 UAT 是一种 “正式 ”的测试，它能让我们检查系统是否完成了它应该做的所有事情，以及它不应该做的任何事情。我们可能会接受一个非常昂贵的东西，它应该改变我们的业务，但如果出现任何问题，就可能会损害我们的业务。这种测试是非常严肃的事情；它需要稳健、可靠和严格。这就是我们选择正式测试的原因。

3.1.1 正式测试

测试是根据标准对系统（或软件）进行客观、结构化的评估。评估必须客观而非主观，这样我们才能确信测试结果是可靠的；测试必须绝对确定软件是否符合其规格（标准）。不能有个人意见、判断或猜测。测试必须有条理，这样才能确保我们已完全按照要求对系统进行了评估，即每个要求都至少测试过一次。结构化方法使我们能够确保每个需求都至少经过一次测试。

此外，如果我们假设在测试过程中发现的任何缺陷和不足都需要纠正，那么测试还必须提供客观证据，说明系统出了什么问题，以便开发团队能够快速、准确地找出缺陷或不足的根源并加以纠正。这是结构化评估的另一个方面。

测试与调试等活动不同，后者的目的是在开发阶段发现并消除缺陷。在调试过程中，开发人员会选择他们认为可能会破坏系统的输入，以便消除缺陷。实际上，由于开发人员在这一阶段既是专家又是缺陷修复者，因此他们可以自己进行测试和缺陷修复。在 UAT 中，与所有正式测试一样，测试和缺陷修复活动是有意分开的。最终用户可以发现错误，但不能修复错误；开发人员可以修复错误，但不能进行测试。

UAT 的主要目的是告诉我们一个系统或一个软件的状态，特别是（在我们的例子中）它是否适合发布。为此，测试必须

• 系统化，这样我们才能清楚地知道哪些已测试，哪些未测试；
• 从系统应该做什么的规范中推导出来，这样我们就能确保所有需要测试的东西都能真正得到测试；
• 可重复，这样如果我们发现了缺陷，我们知道开发团队可以重复我们的测试并得到相同的结果，以帮助他们找到缺陷；
• 记录在案，以便我们评估测试质量。

测试有多种形式和规模，但所有正式测试都符合这些相同的标准。这些是 UAT 与其他类型软件测试的共同特点，但 UAT 在某些方面也是独一无二的。

3.1.1.1 测试级别

在第 2 章中，我们了解了软件开发的生命周期，即 V 生命周期。在这个生命周期中，我们有几个测试阶段，这些阶段被称为测试级别（因为它们是在系统从单个代码单元逐级建立起来的过程中测试软件的）。每个测试级别都有自己独特的目标。

例如，在单元测试层面，我们要寻找单元功能正确的证据；在集成测试层面，我们要寻找单元能相互通信并共同发挥作用的证据；在系统测试层面，我们要寻找整个系统能按规定运行的证据。

每个测试级别都是基于该级别规范的正式测试，因此单元测试将基于单元规范，以此类推。因此，相关规范被称为该级别的测试基础。
在每个测试级别，我们可能要考虑软件或系统的许多不同方面，如功能性、可靠性、可用性、安全性等。我们测试的系统的每个方面都需要特定的测试类型。功能测试旨在测试特定级别的功能在测试基础方面是否正确。安全测试的目的是测试特定级别的安全要求是否得到满足，等等。

UAT 是最高的测试级别，因为它代表了制定要求的级别。在 UAT 开始之前，UAT 以下的每个级别都应进行过测试，因此 UAT 是对已构建的系统是否满足最终用户和赞助商要求的最后检查。

3.2 测试类型

一组测试活动，目的是测试一个组件或系统，重点是特定的测试目标，即功能测试、可用性测试、回归测试等。一种测试类型可在一个或多个测试级别或测试阶段进行。

在所有可定义的测试类型中，有两种类型对 UAT 特别有用：功能测试和结构测试。

3.2.1 功能测试

功能测试正如其名：测试所需的功能是否存在，是否能正常工作。
功能测试:基于对组件或系统功能规范的分析进行测试。这通常也被称为黑盒测试。
功能测试设计技术:在分析组件或系统功能规格的基础上推导或选择测试用例的程序，而不参考其内部结构。

我们必须分析业务需求以确定所有功能需求，定义测试条件并生成测试用例

我们根据测试条件创建了一个功能测试用例。然后，将测试用例中指定的输入数据应用于待测试功能的规范（在业务需求或更详细的规范中，如果有的话），以发现输入应产生的输出。这些都记录在测试脚本中。

执行测试时，测试脚本将用于确定所需的数据输入，此时实际输出将记录在测试脚本中。然后，可以比较实际输出和预期输出，以确定测试是通过了还是失败了。
为 UAT 生成的绝大多数测试脚本都是功能性的。

3.2.2 结构或白盒测试

结构测试结构（白盒）测试基于对组件或系统内部结构的分析。

白盒测试最常与测试代码联系在一起，但它对测试任何具有内部结构的东西都很有用。在 UAT 中，我们需要测试菜单结构等系统组件，还需要确保系统在业务流程中正确运行。在这些情况下，我们可以利用白盒测试来探索相关结构，并确保通过结构测试所有可能的路径（一种（结构）测试覆盖形式）。

以业务流程为例，我们知道通过业务流程的每条路径都会触发一个或多个用例，这些用例将执行系统功能并产生输出。然后，业务流程可能会以某种方式利用这些输出。

如果我们启动业务流程，向系统生成输入，并从系统消耗输出，这就是端到端测试的一个例子。业务流程的成功完成表明端到端测试用例的成功，在该测试用例中，功能测试用例将被用来转换数据。

下图显示了一个简单的业务流程，它有三条路径，分别对应流程中嵌入的两个问 题的答案。如果对 “现有客户？”的回答是 “是”，流程就会进入下一个问题 “新账户类型？”，如果回答也是 “是”，流程就需要执行两个操作： 生成授权 “和 ”发送给客户(路径 3）。每个活动都有一个用例，我们可以从中生成功能测试用例。因此，路径 3 的端到端测试涉及用户使用系统操作一个业务流程，并通过两个测试用例完成该流程，可能还需要手动生成一份邮寄给客户的邮件。流程从开始流向结束。

如果我们对路径 1 和路径 2 采用相同的测试方法，我们将完成整个业务流程；也就是说， 我们将实现对业务流程 100%的结构覆盖，同时利用一些现有的测试用例。

假设：我们有一个包含 100 个需求的系统，我们给三个测试人员布置了尽可能好地测试这个系统的任务。测试人员 1 进行了 100 次测试，测试人员 2 进行了 200 次测试，测试人员 3 进行了 1000 次测试。哪个测试人员的测试最有效？
答案是我们无法判断。虽然测试员 3 执行了最多的测试，但我们无法确定测试了哪些内容，因此无法知道测试的实际效果如何。
如果我们规定每个需求都必须至少测试一次，并重复进行测试，那么结果将截然不同。测试员 1 进行 100 次测试，测试员 2 进行 200 次测试，测试员 3 进行 1000 次测试。除了所有三个测试员现在都声称所有需求都已测试过之外，没有任何变化。我们能得出什么结论呢？
如果测试员 1 已经覆盖了所有需求，那么这组测试一定比其他两个测试员的测试更有效率，因为它以更少的努力实现了相同的结果。
但我们仍然不知道这三组测试是否同样有效。这个故事的寓意是，更多并不一定意味着更好，测试的有效性需要基于其他标准。这个标准就是覆盖率。

覆盖率是衡量每个测试到底测试了系统的哪些部分。如果我们能证明（这需要一些文件证明），我们的测试设计使每个需求都至少被测试过一次，那么我们就达到了 100%的需求覆盖率，而达到 100%覆盖率的最小测试集是最有效的。

顺便提一下，测试文档也能让我们检查测试是否有效。大约 10%的测试失败通常是由测试中的缺陷而不是系统中的缺陷造成的，因此在运行测试之前，我们应该对测试进行检查。

在 UAT 中，我们特别关注业务需求的覆盖率。如果我们规定测试覆盖率为 100%，那么我们的意思是每个需求都定义了一个或多个测试，并且在执行这些测试时，我们可以确定 100%的需求都经过了测试。稍后，我们将介绍测试用例设计技术，这些技术能让我们达到理想的测试覆盖率水平，并高效地测试我们的系统，也就是说，我们将使用最少的时间和资源来达到给定的测试覆盖率水平--这就是测试的圣杯。
但要注意的是，一个测试可能不足以完全测试一个需求，因此 100%的需求覆盖率可能意味着每个需求都至少经过一个测试。如果我们想做得更彻底（也许是针对更关键的需求），我们可能必须为某些需求设计一个以上的测试，并相应地调整我们的覆盖率衡量标准。
我们必须不断思考的一个问题是："业务需求到底是什么？我们需要为 UAT 提供一个测试基础，而我们知道，最初的 RS 不可能是一个充分的测试基础。我们将在计划 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

3.3 测试流程

我们希望能够以最高效、最及时的方式完成 UAT。为此，我们需要两个关键流程：一个是 FTP（fundamental test process ） 流程，它可以帮助我们确保在正确的时间做正确的事情；另一个是测试开发（fundamental test process ）流程，它可以确保我们设计出正确的测试类型，从而明确系统是否满足业务需求和验收标准。

3.3.1 基本测试流程 正如我们在第 1 章中所定义的，基本测试流程（FTP）有五个步骤：

• 测试计划、监测和控制；
• 测试分析和设计
• 测试实施和执行
• 评估退出标准和报告
• 测试结束活动。

我们将使用这个简单的流程来构建第 6-10 章中的分步指导。
它为我们提供了实现目标所需的活动顺序，还为我们可能需要的输出类型提供了有用的指针，使我们能够在最后对验收做出合理的决定。

3.3.2 测试开发流程

测试开发流程（TDP test development process）描述了生成有效测试的机制，以达到所需的测试覆盖水平。该流程分为三个阶段，每个阶段都与 FTP 中的一个步骤相一致。

TDP 有三个组成部分：测试条件、测试用例和测试脚本。所有这些在 ISTQB 术语表中都有定义，并可重复使用。

• 测试条件 可由一个或多个测试用例验证的组件或系统的项目或事件，如功能、事务、特征、质量属性或结构元素。
• 测试用例 针对特定目标或测试条件开发的一组输入值、执行前置条件、预期结果和执行后置条 件，例如，用于练习特定程序路径或验证是否符合特定要求。
• 测试剁成规范 指明执行测试动作序列的文件。也称为测试脚本或手动测试脚本。

3.3.2.1 测试条件

测试条件的目的是将业务需求的某些方面（功能、事务、特性、质量属性或结构元素）以某种形式表达出来，并据此构建一个或多个特定的测试。测试条件可以是 “真 ”或 “假”，测试条件的值可通过运行测试用例来确定。

如果某个功能描述了使用用户名和密码安全登录系统的功能，那么就可以编写一些测试条件：

• 如果输入了有效的用户名和正确的密码，用户就登录了系统。
• 如果输入了有效的用户名和错误的密码，则会出现错误信息。
• 如果输入了无效用户名和密码，则会出现错误信息。
  除上述三个测试条件外，还可根据业务需求编写其他测试条件。
  请注意，每个测试条件都代表了功能的一个组成部分，可以评估为真或假。只有当三个条件都为真时，该功能才算正确实现。
  我们可以为每个测试条件创建一个表格，以确定测试条件的含义，如下所示。

表中的每个条目现在都可以用一个测试用例来测试，测试用例的结果为 TRUE 或 FALSE。

3.3.2.2 测试用例

我们需要确定与每个测试条件相关的输入和预期输出，以便生成特定测试，确定测试条件是否为真。
前置条件和后置条件分别确定测试执行前系统必须处于的状态和测试执行后系统将处于的状态。
每个测试条件可编写一个或多个测试用例。

前置条件和后置条件对测试排序很有用，例如，如果一个测试的前置条件是用户已登录系统，那么确保在登录系统的测试用例之前不运行该测试用例就很有意义。
在编写所有可能的测试条件列表时，可能会出现某些测试条件重复的情况。如果结果（登录）取决于有效的用户名和匹配的有效密码，那么可以认为测试用例 3 和测试用例 4 是重复的，因为非有效的用户名将不允许最终用户登录，无论他们的密码是有效的还是非有效的。事实上，你也可以说，无效的用户名不可能有有效的密码。不过，在我们的示例中，我们要测试的是不同的有效和无效输入的组合是否能产生所需的结果。在测试用例 3 中，我们可以输入一个有效的用户名，该用户名包含一个错误，并带有相应的有效密码。测试用例 4 可以测试黑客通过随机输入无效用户名和密码试图进入系统的情况。

3.3.2.3 测试脚本（测试过程规范）

测试脚本提供了运行我们定义为测试用例的测试的机制和文档。测试用例是通用的；它定义了输入和预期输出的性质，并为使用实际数据构建测试脚本提供了模板。用户体验测试人员需要掌握一系列测试脚本，并按特定顺序执行。

我们定义了一个成功登录的模板。我们可以使用该模板生成一个测试脚本，例如，登录 10 个有效用户（如果我们有自动输入的方法，就会特别有用）。但更有趣的是，我们可以定义一个测试脚本，以执行与所有四个测试条件相关的测试用例，然后使用有效和无效用户名以及有效和无效密码混合运行该脚本。

下面是一个与上述测试用例 1 相对应的简单测试脚本。

下面测试脚本用于测试特定的测试用例，唯一标识为测试用例 4.11。

• 测试条件：
  • 检查最终用户能否使用有效的用户名和密码登录系统。
  • 检查最终用户是否可以使用无效的用户 ID 登录系统。
  • 检查最终用户能否使用无效密码登录系统。

测试 #1 - 检查最终用户能否使用有效的用户 ID 和密码登录系统。

注意，我们（真实）示例中使用的术语与本书中使用的术语不同。在示例中，测试脚本就是我们所说的场景，反之亦然。这种情况在 UAT 中很常见，只要需要交付的所有阶段都被理解，并且术语被普遍使用，那么这些阶段在你的组织中使用不同的名称就不那么重要了。还要注意的是，脚本只有三个测试条件，因为在这种情况下，测试无效用户名和无效密码的条件被认为是不必要的。
每个脚本都包含：测试用例编号和版本、测试描述、需求编号、测试人员、流程步骤编号、流程步骤描述、要使用的测试数据、预期结果、错误描述、通过/失败结果、测试日期和 UA 测试人员的注释。在包含多个测试脚本的方案中，除上述内容外，还应包括以下内容：

• 场景名称和编号；
• 场景描述
• 测试脚本名称、编号、版本和日期；
• 测试脚本涵盖的测试用例和需求的 ID；
• 测试用例描述；
• 任何前提程序。
  测试脚本编号是测试文档可追溯性的一部分。它可用于衡量 UAT 期间涵盖了多少测试脚本、测试用例、要求和验收标准。测试脚本还可以在更新版本号和日期后重复使用，以便进行回归测试。

3.3.3 测试覆盖率

如前所述，测试覆盖率是衡量已完成多少测试的重要标准。
如果一个需求产生 50 个测试条件，那么需要对这 50 个测试条件进行评估，以达到 100%的覆盖率。如果运行了 100 个测试，但其中只有一个与测试条件相关，那么就只达到了 2%（50 个中的 1 个）的覆盖率。测试覆盖率的衡量方法因测试用例设计技术的不同而不同，但在任何情况下，测试覆盖率的衡量都是将目前已进行的测试次数与使用特定技术对被测软件可能进行的测试次数进行比较。测试覆盖率是衡量已完成测试数量的客观标准，因此也是衡量统一测试结果是否全面的标准。

UAT设计计划要求从需求中提取一系列测试条件，以达到为测试指定的测试覆盖水平。最后，创建一套测试脚本，使用户体验测试人员能够执行所有测试并记录结果。上述登录示例（3.2），假设条件 3 和 4 不重复，则测试条件会产生四个测试用例，所有这些测试用例都是完整评估测试条件所必需的。这四个测试用例各占该特定需求覆盖率的 25%，需要运行全部四个测试用例才能 100%覆盖该需求。

3.4 测试用例设计技术

测试用例设计技术适用于各种不同的软件对象测试方法，其中许多已在 Hambling 等人（2010 年）的著作中作了介绍。这些技术中的任何一种都可用于设计测试用例，其中有些技术肯定能提高整体工作效率，尤其是在易于理解和使用的情况下。

3.4.1 等价分割（EP）和边界值分析（BVA）

等价分割（EP Equivalence partitioning ）和边界值分析（BVA boundary value analysis ）是两种相关的测试用例设计技术，在 UAT 环境中非常有用。尽管这两种技术的名称听起来很长，但使用起来却非常简单直观，因此非常值得熟悉。

EP 有助于了解当数据值处于连续范围（如 1 到 10 之间的所有整数）时应使用哪些值。它提供了一种简单的方法，让我们确信系统能正确处理范围内的所有值，因此它能为我们提供高效而完整的测试。
下面是一个简单的例子。如果姓氏的数据输入字段最多可包含 50 个字母字符，那么测试组成姓名的所有字母字符的不同组合就没有任何好处。即使我们想测试，也做不到--50 个字母字符的可能组合数量是个天文数字，而且这还只是有效的例子。
EP 允许我们假设任何有效组合的行为都与任何其他有效组合相同，因此我们只需测试一个示例，就能合理地确信系统将接受任何有效的字符组合。我们把这个非常大的 可能的输入集合称为有效分区。在这个分区中，任何有效的字符组合都能证明数据输入是可行的，因此代表一个有效的测试案例。在这个等价类中，输入 25 个有效字符与输入长度少于 51 个字符的任何其他有效字符组合一样，都是有效的测试，只需测试一个。请注意，在本例中，我们选择使用分区的中间部分作为有效案例。
如果有一个有效分区，那么至少也会有一个无效分区。事实上，在本例中我们必须考虑到三种不同的无效分区：

• 包含至少一个无效字符（例如数字字符）的 1-50 字符的任何组合；
• 少于一个字符的组合（即无字符）；
• 包含 50 个以上有效字符的组合。

我们需要每种情况下的一个例子来组成等价分区的完整测试集。
需要注意的是，只有当输入结构为列表、序列或其他集合时，EP 才能为我们节省时间和精力。这是一个限制，但并不是太大的限制，因为输入数据字段通常都是结构化的。
BVA 是 EP 的天然搭档。BVA 考虑到了一个观察到的特点，即发生在数据边界或边缘的应用错误比其他任何地方都多。
开发人员通常使用循环来处理结构化数据，而在进入或终止循环时出现的错误会在边界（例如序列中要处理的第一个或最后一个项目）处造成问题。同样，“边缘情况 ”也是我们在业务流程中经常出错的地方，因此开发人员可能会从一个错误的指定边界值开始工作。由于这些原因，边界案例是查找问题的好地方。
BVA 通过对边界测试进行聚类来利用这些观察结果，而分区的一个好处就是它们总是有边界的。在我们上面的 EP 示例中，边界是 1 个字符和 50 个字符的组合。在 UAT 中，我们可以测试实际的边界值和每个边界外的一个值。所谓 “恰好超出”，是指超出情况下可能的最小值。在我们的例子中，字符组合的长度只能增加或减少一个，因此 “刚好超出 ”就是超出一个。
将 BVA 应用于我们的示例将导致以下测试案例：

• 在正值的边界上有两个值： 1 个字符和 50 个字符；
• 边界外的两个值： 0 字符和 51 字符。

您可能还记得，我们已经选择了一个 0 字符的测试用例，因此无需重复。现在，使用分区中间的值作为有效值的想法是合理的；反正我们也要在边缘进行测试。
现在，我们已将天文数字般的可能测试缩减为四种测试：输入 25 个有效字符、输入 25 个字符且其中一个或多个无效、空输入框和输入 51 个有效字符。这样做既省力，又不影响测试质量。
您还可以探索许多其他测试用例设计技术，但 EP 和 BVA 本身就能为我们需要运行的测试提供大量支持。

3.5 UAT 测试方法

我们在前面提到，UAT 在某些方面是独特的。这种独特性源于 UAT 中的 U。UAT 由最终用户（或系统实施后的最终用户）独特驱动。换句话说，测试人员不应该是软件或测试专业人员，也不应该有任何测试经验。事实上，情况恰恰相反；最终用户远离开发专业，相对接近业务专业，这使他们具有独特的视角，而不会受到所建系统的内容或方式的影响。在这种情况下，只有最终用户才能做到客观，而且由于他们最终将操作系统，因此他们的任何直觉或经验都会为这项工作带来价值。
UAT 还有一个独特之处。所有其他类型的测试都是根据规范对结果进行测试，而 UAT 则不同，它基于三个要素：

• 业务需求；
• 业务流程
• 用户期望。
  我们可以说，业务需求已记录在规范（RS）中。
  但正如我们已经看到的，RS 不一定是测试的有效依据。我们还可以说，业务流程已经明确，但事实并非总是如此。用户的期望不仅没有记录在案，而且会随着用户经验的积累而发生变化。
  因此，我们需要一种能反映这三个要素的测试方法。

3.5.1 基于需求的测试用例

测试用例必须涵盖业务需求，因为需求就是 UAT 要测试的内容。为了表明基于需求的测试用例与特定需求相关，测试用例应包含一个将其与业务需求相联系的 ID。在这一点上，我们应该增加一层复杂性，那就是测试设计的时间安排。到目前为止，我们假定测试用例是在项目结束时作为 UAT 准备工作的一部分创建的。然而，你可能会发现测试用例是在 RS 发布后不久编写的，而且现有的测试用例已经过时，必须根据新审查的 RS 进行更新。因此，使用需求驱动测试用例的缺点是，如果需求包含错误，测试用例也会出错。

3.5.2 基于业务流程的测试用例

基于业务流程的测试用例是为确保交付的系统能专门支持业务流程而编写的测试用例。
测试用例必须能够证明需求已得到满足，并能反映组织将如何使用系统。对于基于业务流程的测试，必须对测试进行排序，以反映流程，从而检查测试是否反映了这些流程的路径。

3.5.3 UI驱动的测试用例

用户界面驱动的测试用例是围绕需要完成的表单或屏幕构建的。测试用例基于数据输入、屏幕交互和报告。
在每种情况下，这些测试用例都将通过一个场景进行关联，以便以一种现实的方式操作数据。当业务流程涉及数据输入、交互或报告时，基于用户界面的测试用例可嵌入基于业务流程的测试用例中。用户界面测试可包括

• 制表符顺序--制表符顺序是否正确？
• 必填字段 - 是否标记了必填字段，是否需要输入？
• 数据类型错误 - 是否只能以正确的格式（日期、数字、货币）输入数据？
• 保存和删除确认 - 在关闭和确认删除之前，系统是否提示用户保存更改的数据？
• 快捷键 - 快捷键是否有效？
• 无效菜单项 - 显示的菜单项是否与用户当前所处的上下文无关？
• 链接 - 链接是否有效？
• 菜单 - 菜单项是否正确？

3.5.4 确定优先级--基于风险的测试

UAT测试的最后一个方面是，我们将在时间压力下进行测试，因为我们是在系统发布之前进行测试的。如果系统迟迟不能进入 UAT 阶段，我们将面临更大的压力。有鉴于此，我们需要一种方法，在有限的时间内做到最好。为此，我们采用了一种优先级机制，以确保我们首先运行最重要的测试，从而保证任何无法完成的测试的重要性都低于我们已经完成的测试。我们称之为基于风险的测试。

如果我们了解了系统的哪些方面最重要，如果测试无效可能会导致严重问题，也就是说，这些方面代表着风险，那么我们就可以按风险等级确定测试的优先次序，并首先测试风险最高的领域。首先，我们可以确定每个需求或每组需求的风险等级，并按优先顺序排列。这至少是开发测试用例的一个实用起点。
基于风险的测试可与其他方法结合使用。例如，我们可以将基于需求的测试作为实现需求覆盖的一种方法，然后在基于需求的测试中应用基于风险的测试，以确保我们首先测试最重要的领域。

3.5.5 关于测试方法的最后一个想法

虽然我们对软件是否能正常运行感兴趣，但开发人员和测试人员已经对此进行了测试，特别是软件是否按照技术规范运行。我们关心的不是是否符合技术规范。如果系统完成了我们希望和需要它完成的工作，但却缺少了技术规范的某些细节部分，那么这将是我们应该报告的一个结果，但对我们来说，这可能并不是一个 “拦路虎”。另一方面，如果系统符合技术规范和 RS 的所有要求，但我们发现使用起来很麻烦，或者不能支持关键的业务流程，那么我们就有理由担心了。

这就是最终用户感知的本质。我们进行测试，以确保我们得到所需的东西，即使这与规定的不符。客户永远是对的。

3.6 评审

我们需要熟悉的另一种测试技术是审查技术。
评审：是对产品或项目状态的评估，以确定与计划结果的差异，并提出改进建议。例如，管理评审、非正式评审、技术评审、检查和走查。
正如定义所示，审查有很多种，但目的始终如一：评估和改进。我们将把评审作为评估和改进 RS 和测试条件、测试用例和测试脚本的重要工具。我们将专注于一种非常简单和非正式的评审，即定义中提到的 “走一遍 ”的变体，其基本流程如下：

• 单独阅读文档，找出任何问题或疑问。
• 与文件作者和其他审阅者会面，让作者 “浏览 ”文件并回答任何问题。
• 将任何未解决的问题或疑问记录在文件中，以便在评审后交给作者。

评估是通过每个审阅者提出意见来实现的，这样作者就能找出需要修改或纠正的地方；改进来自作者在审阅会后做出的修改。

评审给团队带来的好处远远超过对文件的改进。例如

• 评审是一项团队活动，因此有助于团队建设和相互了解。
• 所有参与者都能了解评审文件的状态和改进情况，因此评审有助于让每个人都参与进来并了解情况。
• 向文件作者提问的机会提供了学习的机会，使团队成员能够积累系统和测试方面的知识。
• 共同承担评审文件的质量责任，因此每个人都与质量息息相关。
• 有机会向更有经验的同事学习，从而在团队中有效地汇集知识和经验。

3.7 总结

本章介绍了生成有效测试用例的一些关键测试流程和技术，并演示了如何根据 UAT 的具体需求对这些流程和技术进行调整和调整重点。
本章还介绍了一般评审，特别是走查技术，作为评估和改进文档的重要技术，也有助于团队的发展。
阅读本章后，您应该能够回答以下问题：

• 我要遵循哪些步骤才能确保完成 UAT？
• 为 UAT 建立一套有效的测试需要遵循哪些步骤？
• 如何利用审查来确保我获得的文档适合作为测试基础？
• 有哪些可用的技术？

3.8 参考答案

第 3 章 你学到了什么的答案 Q1 A（严格来说，A 是功能覆盖，但它是唯一与测试覆盖思想相关的答案）
答案 B 不正确。它只是计算运行的测试总数，与覆盖率没有直接联系。
答案 C 不正确。测试通常是为实现一个测试目标而设计的。
答案 D 不正确。范围是测试的广度，是对测试内容和未测试内容的另一种衡量。测试覆盖率衡量测试覆盖了多少范围内的功能。
问题 2 D 答案 A 可能是对的，但不是正确答案，因为它不是评审作为评估文档的一种手段的好处。
答案 B 不正确。审核的成本并不低，事实上，它们会耗费宝贵的精力，这就是为什么它们必须能有效地发现缺陷。
答案 C 不正确。审核只能发现部分缺陷，但足以使付出的努力物有所值，因为用其他方法发现缺陷或找不到缺陷的成本会更高。
问题 3 B 答案 A 不正确。测试技术利用用户输入无效数据时发生的情况来发现缺陷，但不影响用户可以输入的内容。
答案 C 不正确。边界是分区的边缘，而不是极端条件。有些边界可能是极端条件，例如系统能处理的最高值，但测试是边界测试，因为它处于分区的边缘，而不是因为它使用了极端值。
答案 D 不正确。只有边界外的测试用例才会失败，而边界内或边界上的测试用例才会通过。
我们对需要考虑的问题的答复 1. 您的组织不愿意让 UA 测试人员参与评审过程。克服这种不情愿的最佳方法是什么？
找出这种不情愿的原因会很有帮助。是担心人满为患，还是担心某些反对意见会延误项目？最初的 CHAOS 报告显示，项目失败的第二大原因是缺乏参与。审查过程的目的是确保需求与企业的需求相匹配，企业应该参与这一过程。

附录 B 答案与评论 即使其他利益相关者也参与了评审，用户或用户代表（如主题专家）在场也会有助于实现评审的目 的。让参与审查的每个人都了解审查的目的，并强化这样一个信息，即在审查过程中不 需要决定系统需要做什么改变，只需要确定当前的需求是什么，这可能是有益的。
2. 2. 在您开始 UA 测试员工作之前，将为您提供一个培训课程。您对为期一天的课程有何要求？假设您可以接受为期三天的培训。您的要求会有哪些变化？
这个问题很难回答，但值得考虑。我们将在第 4 章和第 5 章中提供一些帮助，但现在也是一个很好的时机来思考一下，您需要什么来应对自己组织中的 UAT。例如，如果您查看一下公开课程的内容，就可以了解通常会提供哪些课程，并找出哪些课程对您来说是空白。了解您将要测试的系统、了解开发团队是如何测试系统的，以及熟悉您可能需要使用的工具等，都是通用课程无法提供的内容。您需要自己想办法获取这些信息。
时间就是一切。一天的时间不足以让您了解所有可能需要了解的信息，从而为测试做好准备，但最好还是将您的想法提炼出来，看看一天的时间可以做些什么。然后再给自己三天的时间，考虑如何以不同的方式完成任务。这些思想实验将为您学习第 4 章和第 5 章中关于建立和培训有效的 UAT 团队的内容打下良好基础。
您已经掌握了最重要的知识，因为您是用户。一天时间的最大价值可能来自于对需求的熟悉（你自己也可以提出一些需求，以确保从培训中获得一些实用价值）。第二件事是学习如何从评审中获得最佳效果。你可以从书本中获得一些基本的测试知识。
在为期三天的课程中，你可以增加一些测试基础知识，但额外时间的主要好处是让你能够在审核和编写测试脚本（如果可能，基于你自己的需求）方面得到一些练习。