8 实施测试

到目前为止，我们已经规划了我们的 UAT 演习，并制定了测试的总体战略，然后设计了所有测试并编写了测试脚本。现在，我们已准备好实施计划和进行测试。
在本章中，我们将介绍如何安排所有测试，以实现我们的测试策略，并根据验收标准评估系统。为此，我们需要记录所有测试，以便确定测试何时完成，并收集判断系统状态所需的数据。
本章涉及的主题

• 测试日程表
• 执行测试日程表
• 确定进度
• 状态报告
• 测试后总结

8.0 习题

8.0.1 选择题

• 1. 测试人员发现缺陷后，UAT 负责人应立即做什么？
     A. 检查测试脚本是不是导致故障的原因 B．尝试重新创建缺陷 C. 确保缺陷记录足够详细，并确定严重程度 D. 以上都是
• 2. 由于脚本中的一个错误，测试失败了。您该怎么办？
     A. 提出事故报告 B. 不提出事故报告；修改脚本并重新运行 C. 不提出事故报告；修改脚本并安排在以后测试 D. 提出事故报告，修改脚本并重新运行
• 3. 测试日志记录了什么？
     A. 完成剩余测试还需要多少时间 B. 已完成哪些测试及其结果 C. 事故及其严重程度 D. 已完成哪些测试

8.0.2 简答题

1.测试进行到一半时，要求您提供完成 UAT 的固定日期。您将如何回答这一要求？

8.1 测试日程表

测试日程表就像其他日程表一样，它将各项活动按照正确的顺序排列，最好还能估计出每项活动的时间。
测试日程表：测试过程中的活动、任务或事件清单，确定其预定开始和结束日期或时间，以及相互依赖关系。
测试日程表 实际上是一个非常重要的步骤，因为

• 它能确保包含测试策略所需的所有测试。
• 对测试进行排序，以便最有效地利用时间和资源。
• 按照业务流程安排测试顺序。
• 为测试活动分配测试资源。
• 使我们能够记录测试并跟踪进度。
• 使我们能够在遇到问题时重新安排时间。

测试日程表对于测试执行的作用，就像测试计划对于我们的总体战略的作用一样；它将原则转化为我们可以操作、跟踪和修改的现实。经验告诉我们，没有任何计划是完整的，也没有任何事情是完全按计划进行的。测试日程表是我们在面对变化时保持对测试项目控制的机会，并确保我们始终能充分利用可用的时间和资源。

8.1.1 高层次测试日程表

高层次日程表的目的是将测试策略所需的大型 “构件 ”整合到一个顺序中，使其符合我们的策略，并充分利用可用的时间和资源。
高层次日程表直接基于 UAT 战略。例如，如果测试策略是基于风险的，那么高级测试计划就会提前安排所有高风险测试项目。如果是基于相对重要性，则会先测试最重要的功能。
测试时间安排必须考虑到影响何时测试的各种因素。这些因素包括:

• 测试的优先级
• 测试环境的可用性
• 测试人员的可用性。

8.1.1.1 测试的优先级

由 UAT 战略确定的优先次序决定了测试的主要顺序，但可能会因优先次序的冲突或测试环境和测试人员等基本资源的不可用而有所变动。

8.1.1.2 测试环境的可用性

我们需要测试环境来替代现实世界或系统中因某些原因而无法进入的部分。
在某些情况下，进入真实世界是不可行的，例如，一个跨时区实时交互运行的系统需要一个复杂、可靠、可能安全的通信网络。该网络可能已经投入使用，也可能尚未建成。无论哪种情况，复制网络的测试环境都是不切实际的。测试环境可以模拟现实世界的某些方面来进行测试，也可以创建一个简化版的真实硬件或软件来进行测试。在本例中，这两种方法中的任何一种都可能过于复杂和昂贵，因此必须确定其他测试系统的方法。
在整个 UAT 过程中使用测试环境时，可能会出现竞争使用特定环境的情况，因此需要安排测试以避免或尽量减少竞争。

8.1.1.3 测试人员的可用性

显然，测试需要测试人员的可用性。某些测试领域可能需要特定的技能或用户背景，在安排测试时需要考虑到这一点。
没有什么是可以保证的，因此时间安排不是一次性的，而是一项持续的审查和重新安排活动。

8.1.2 详细的测试日程表

详细的测试日程表从高层次日程表中提取构件，并将其分解为单个测试。不过，单个测试的计划流程可能会因每个阶段的被测软件（SUT）状态而中断。如果任何测试失败都会发现 SUT 存在缺陷，那么测试序列就会中断。

8.1.3 被测软件（SUT）在每个阶段的状态

SUT 是指在任何特定时间或特定测试中正在测试的系统的特定区域。随着测试的进行，重点将从系统的一个区域转移到另一个区域。
在任何特定阶段，都可能有未完成的事故报告，或正在调查或纠正的缺陷。因此，特定时间的 SUT 可用性永远无法确定。在安排测试时，应尽可能考虑到所安排测试的 SUT 特定区域的预期可用性。
任何使测试退出测试队列的行为，都会以某种方式影响计划的安排。上图展示了已排定的测试产生重新排定的方式：

• 如果测试受阻，就需要重新安排；
• 缺陷纠正后需要重新测试；
• 回归测试的需要。

如果发现严重缺陷，可能需要优先纠正缺陷，这可能会阻碍那些依赖于缺陷模块的测试。当缺陷修正被安排为优先测试时，它还会取代测试，从而需要重新调整计划。测试受阻的方式有很多种。当我们的测试计划受阻时，我们必须重新安排测试计划，使测试继续进行，并将受阻的测试安排在稍后进行。

缺陷纠正后需要重新测试：显然，发现的任何缺陷都可能导致缺陷纠正（但如果缺陷不太严重，且缺陷纠正不会对完成 UAT 产生重大影响，则缺陷纠正可以推迟）。如果缺陷得到纠正，则需要对纠正进行测试；这将是原计划之外的测试，因此有必要对测试计划进行一些修改。

回归测试的必要性：我们可以假设在 UAT 期间需要进行一些回归测试，但我们无法轻易预测何时进行。我们有两种选择：一种是定期计划回归测试活动；另一种是在需要时进行回归测试，并重新安排测试时间。

计划回归的优点是不会导致重新安排时间，而且如果不需要回归测试，还能在计划中创造一些 "空闲 "时间，以吸收其他原因造成的变化。缺点是计划回归会减少其他测试的时间。如果我们在需要时才计划回归测试，就必须接受其他测试的重新安排，这可能会带来不便，并可能导致延迟。如果我们采用这种方法，就应假设我们不会完成最初计划的所有 UAT（除非时间范围延长），因此我们需要确保后面的测试具有相对较低的优先级或重要性。

8.1.4 简化

详细的测试计划通过利用按自然顺序排序的机会来简化测试。
下面是一些精简的例子：

• 如果一个测试的前置条件与另一个测试的后置条件相匹配，那么按顺序运行这些测 试可能是有利的（即使高级计划表不要求这样的顺序）。一个很好的例子是，测试 1 将测试数据处理成测试 2 需要的输入形式。
• 如果测试是按时间顺序进行的，就应该把它们放在一起。
• 在需要输入数据的情况下，最好同时测试数据输入功能。这可能包括错误处理，即使错误处理在概念上属于单独安排的测试块。
• 即使业务流程的某一部分比另一部分更优先，也不应将业务流程分隔到计划的不 同部分。在整个流程中处理测试数据并检查输出结果的优势，通常大于调整时间表以适应流程的劣势。

详细的测试计划将是一个逐个测试的序列，它能最有效地利用资源，并在 UAT 战略规定的总体限制范围内提供系统行为的最佳可见性。表 8.1 是测试计划的一个示例。

• 练习 8.1

在第 7 章中，我们使用了一个测试脚本示例（为方便起见，转载如下）
我们知道，当测试脚本涉及系统不同部分的同一过程时，例如登录到每个 Excelsior 模块，就可以快速创建测试脚本。
1.2.1 测试方案
1.检查未经验证的用户是否可以登录 Contracts。
2.检查通过验证的用户能否登录合同系统。

用同样的例子来说明日程安排工作：
1.这些测试应按顺序排列，一个紧接着一个？
2. 是否可以将这些测试作为另一个或多个方案的一部分来运行？

8.2 实施测试日程

实施是将详细测试计划中的活动分配给各个测试人员，并确保他们拥有必要的测试脚本和测试环境。然后，测试人员根据测试脚本设置并运行测试，通过在测试脚本上批注来确定任何困难，记下确切结果，并在测试未产生预期结果时提交事件报告。

8.2.1 分配任务

测试任务可按 "先到先得 "的原则分配，即任何可用的测试员都可执行下一个预定的测试脚本，也可对测试脚本进行注释，供特定专业的测试员（如最终用户、经理或业务分析员）执行。
任务分配完成后，测试人员应找到相应的测试脚本
以及执行测试的工作站。

8.2.2 执行测试脚本

测试人员按照测试脚本中的规定设置测试，并使用指定的测试数据运行脚本。
如果测试通过，测试人员将完成输入和输出数据以及任何其他输出事件，然后将测试结果添加到测试脚本中。如果测试失败，测试员将提交一份事件报告，让 UAT 小组组长知道发生了什么。
所有测试活动都由 UAT 小组组长记入测试日志。

8.2.3 记录测试日志

测试日志最初是详细测试计划的副本，上面会添加一些信息，说明谁进行了每项测试、何时进行、结果如何等。
测试日志是一份 "活 "文件。随着测试的完成，信息会不断添加到日志中，并根据需要创建新的活动，以满足以下需要：

• 报告事故，纠正缺陷，要求重新测试。
• 因延迟或缺乏资源而重新安排测试。
• 围绕重新测试重新安排测试。
• 增加回归测试。
• 测试反馈表明需要增加或减少测试。
  计划表确定了在任何阶段仍需完成的测试，测试日志则确定了已完成的测试。从这两份文件中，我们可以确定进度计划和验收标准的完成情况。我们还可以得出其他有价值的测试指标，如提出和结束的事件数量，以及测试的平均时间。这些指标将帮助我们改进对何时完成 UAT 的估计。

8.2.4 从 UAT 中提出问题

如果测试因任何原因无法圆满完成，应咨询 UAT 小组负责人以解决问题。

如果测试正确执行，但产生的输出与测试脚本的预期输出不同，则应提交事件报告。在可能的情况下，谨慎的做法总是尝试重新运行测试，以确认测试的设置和执行是正确的，但这并不总是可能的（例如，如果数据已更改且无法重置）。如果问题与测试用例或测试脚本中的错误有关，则需要修改文档并重新安排测试。图 8.2 提供了一个简单的事件报告示例。
完成的事件报告应交给 UAT 小组组长进行评估，并转交给开发小组。

8.2.5 评估问题的重要性

事件的相对重要性取决于事件的严重程度和对测试的预期影响。事件的严重性通常基于项目经理与用户共同制定的准则。严重性与缺陷对系统的影响有关，因此也与系统运行时对业务的影响有关。因此，高严重性事件通常是指威胁到系统所支持的关键业务流程的可行性的事件。对测试的影响在一定程度上取决于严重性（因为严重事件可能会在调查期间停止测试），但也取决于系统相关领域正在进行的其他测试。就 UAT 而言，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

8.3 确定进度

测试日志确定已完成的测试和结果。测试计划总结了 UAT 仍需完成的工作--我们无法准确确定仍需完成的工作，因为我们不知道软件中还可能存在哪些缺陷。测试计划和测试日志中的趋势信息对估算很有帮助。

8.3.1 进度与日程表的对比

进度与日程表的对比是对迄今为止已完成多少计划测试的衡量。如果我们预计在某个日期完成一半的测试，而测试日志显示我们只完成了不到一半，那么我们就落后于计划了。落后的程度取决于延误的原因。测试环境或测试人员不可用造成的延误可能不会产生任何连锁反应，只要不可用的原因不可能造成进一步的延误。缺陷修正和重新测试造成的延误可能会产生更大的影响。与已发现缺陷的数量和严重程度、纠正和重新测试所需的平均时间以及随后对测试计划的平均影响有关的指标，将为估计缺陷的未来影响提供依据，尽管我们必须假定缺陷率将与测试前半期保持一致，或估计缺陷率在后半期可能发生的变化。

在缺陷数量相对较高的情况下，很难准确估计延迟，但我们通常不会将这种情况应用到 UAT 中。更有可能的情况是，由于在系统测试期间，甚至在开发生命周期的更早阶段对缺陷进行了修正，导致 UAT 的开始时间被推迟。不过，无论延迟源于何处，都需要对其进行评估，并将其预测到进度表的剩余部分，以便项目经理了解项目完成的潜在延迟。

8.3.2 对照验收标准的进度

对照验收标准的进度取决于标准是什么。为便于说明，我们假设主要标准与测试覆盖率和完成 UAT 时的未解决缺陷有关。
测试覆盖率是可以直接衡量的，测试的设计也是为了达到所要求的覆盖率水平，因此，对覆盖率进行跟踪的测试的完成情况就能衡量出该标准的进展情况。如果没有对覆盖率进行直接跟踪，我们就应该能够看到还需要完成哪些测试才能达到要求的覆盖率。
缺陷计数的进展情况较难评估，但历史记录会为我们提供信息。如果迄今为止缺陷计数一直很高，我们就应该预计缺陷计数会保持在较高水平，并据此估计完成情况。如果迄今为止缺陷数量一直很低，我们可以合理地假设缺陷数量将保持低水平，并估计对预定完工日期的延误很小或没有延误。
将与每项验收标准相关的潜在延误加起来，我们就能得到一个总体完工时间估算，并将其与计划测试的完工时间估算结合起来。我们不能指望这些估算精确到几小时甚至一天左右，但我们应该能够确定完成 UAT 的时间是否会被推迟。

8.4 状态报告

UAT 状态报告是所有进度信息、预计完成 UAT 的时间和建议的汇总，并附有支持这些建议的数据。
下图为简短的测试总结报告提供了一些标题。在小规模的 UAT 项目中，这可能只是一份附有注释的电子表格。在持续数周的大型 UAT 项目中，这可能是一份定期提交的正式报告，也许是每周一次。

状态报告为项目经理列出我们的衡量标准和估算依据，以便他们确定是否可以接受任何预期延迟。如果不能接受，就需要寻求某种形式的妥协。
在这一阶段，我们不能指望在发布之前弥补系统中的任何根本性缺陷，因此我们只能选择放宽验收标准、推迟交付日期或两者兼而有之。

8.5 测试后总结

在 UAT 结束后，或者当我们接到停止测试的指示时，我们需要编写一份报告，其中包含 UAT 结束前的所有总结信息，并提供对系统状态的准确评估。该评估将是第 9 章的主题。

8.6 小结

本章讨论了运行测试、记录问题和评估进展的实际问题。一致的流程和准确的报告的重要性无论怎样强调都不为过，我们的收获将是能够找出需要解决的问题，并明确我们与验收标准的关系。
读完本章后，你应该能够回答以下问题：
测试计划告诉我什么？

• 运行测试时应记录什么？
• 如果发现问题，应该报告什么？
• 如何发现与验收标准相关的问题？
• 向利益相关者提交的总结报告应包含哪些内容？
• 我应该多久报告一次？

8.7 参考答案

8.7.1 练习1

在我们的示例中，在测试脚本 #1 中，测试人员以不允许访问 “合同 ”模块的用户角色登录， 而在测试脚本 #2 中，测试人员以允许访问 “合同 ”模块的用户角色登录。如果让这些测试脚本在同一场景中相互跟进，效率会很低，因为这涉及到退出登录和重新登录。将每个脚本添加到一组需要登录的测试中会更有用。

如果可能，测试应包含在涵盖合同功能的一个或多个流程中。由于需要不同的角色来测试这个流程，而这些角色又在流程的进展中扮演一定的角色，因此对模块登录的检查可以放在这些不同角色的合同流程测试的开头。因为他们需要登录访问模块才能使用它，所以他们可以同时测试这一功能。

8.7.2 选择题

• 1 D

答案 A、B 和 C 都没有错，但只有答案 D 是完整的。

• 2 D
  答案 A 正确，但不完整。
  答案 B 不正确。因为测试脚本已经创建，它是正式测试文档的一部分，我们需要记录测试失败和随后的更正。
  答案 C 不正确，原因与 B 相同。

• 3 B
  答案 A 不正确。这是估计值。
  答案 C 不正确。事故可以记录在测试日志上，但不是唯一的记录信息。
  答案 D 不正确。与 C 一样，这是正确的，但不完整。

8.7.3 简答题

• 1. 测试进行到一半时，有人要求您提供完成 UAT 的固定日期。您将如何回答这一要求？

可以根据完成 UAT 前半部分所需的时间来估算完成 UAT 所需的时间。这并不能提供保证，因为可能会出现一些意料之外的问题，也许是前半部分测试中没有出现的关键问题。如果要求一个固定的日期，就有可能无法完成所有测试。重要的是要确定这种风险是存在的，而且这种风险比错过最后期限的风险要小或更容易接受。如果验收标准包括 UAT 签收所需的覆盖率百分比，而遗漏的测试影响了覆盖率百分比。
如果验收标准包括 UAT 签收所需的覆盖率，而遗漏的测试影响了可实现的覆盖率，那么验收标准也需要进行调整。
我们应该从上半年的 UAT 中吸取教训。如果任何延误都是由于事故和缺陷修正造成的，我们就可以估计类似程度的事故可能会对下半年的 UAT 产生的影响（或根据我们认为下半年可能会遇到的挑战多还是少来确定影响的大小）。如果延误是由于人员、设备或技能短缺造成的，我们可以确定这些问题是否已经解决，并做出相应的估计。