测试用例集构建_第2部分。为生产前测试构建测试用例

在上一篇文章中，我们了解了开发团队和运营团队之间的协作方法如何帮助确定对生产环境中新系统的执行有影响的一组非功能性需求（NFR）。 然而，确定需求只是故事的一半。

为了在将新系统引入IT产品组合和基础架构中时最大程度地降低风险，我们必须确定可以证明新系统稳健性的生产前测试，并建立起对其在商业用途中的适用性的信心。

我们首先要考虑的是，每个非功能性需求都是新系统的利益相关者（Rozansy和Losacco）确定的业务需求的技术后果。 例如，当商务人士说“一类用户必须在一年中的任何时候，任何一天的任何一天都可以访问该系统”时，在IT术语上转换为“该系统必须24x7全天候可用”。 其他用户，例如在工作时间从后台使用系统的员工，可能需要不同的可用性窗口。 如果物理体系结构的拓扑包括用于Internet连接和后台连接的单独通道，则24x7可用性NFR将不会影响运行后台通道的Web服务器。

我们的第二个考虑因素是，某些NFR对新系统执行的影响很少彼此独立。 例如，保证对一次有效使用的亚秒响应时间与保证10,000个并发用户具有相同的性能不同。 以相同的方式，如果系统拓扑包括通过排队系统在内部组件之间进行的通信，则响应时间测试必须包括预期的并发用户数所产生的工作负载，并且对队列的大小和速度具有相同的物理约束。将在生产系统中。

其他文章（引自Alexander和Cripps）用冲突力的概念表达了这一事实，这与建筑物上存在的载荷和力相似，是土木建筑师进行结构设计的基础。 我们将检查这些力的组合以识别相应的应力情况，即在生产期间实际发生的NFR组合。

在我们提出的方法中，压力案例，系统的实际使用案例以及特定的测试环境之间的关系确定了我们的生产前测试。

识别生产前测试

非功能需求（NFR）源自系统涉众的业务需求。 由于利益相关者通常在组织中扮演不同的角色（例如，最终用户，应用程序开发人员和IT运营），因此这些利益相关者之间的协作方法可以导致达成一套一致的要求。

为了理解需求如何导致压力案例以及它们与用例之间的关系，一个很好的起点是操作环境图（引自Losacco）。 该系统上下文图着重于系统的非功能特性。 它的参与者通常是UML参与者（用户和外部系统），以及最终与实际系统进行交互的各种IT专业人员类别。

对于每个参与者，该图标识了源自系统使用或访问系统的通道的要求。 其他NFR可能来自利益相关者，他们不与实际系统互动，而仅与系统开发过程互动，例如IT架构师或安全人员。

我们将继续使用第一篇文章中使用的示例。 我们考虑在现有数据中心中引入新系统（例如，基于拍卖的电子市场）的情况。

图1.电子拍卖的操作环境图

显而易见，该图突出显示了每个参与者自己的非功能需求

例如，未注册的并发用户数预计将是注册用户数的10倍。

注册用户在拍卖期间需要一个ReactSwift的系统； 另一方面，对于只能浏览未来拍卖的未注册用户而言，这并不重要。

检查非功能性需求

我们的第一步是为非功能需求构建冲突表。 我们的出发点是操作上下文图中可用的NFR列表。 该表分为以下几个区域：

• 在第一个区域中，行列出了参与者排序的NFR；
• 在第二个中，行代表了生产前测试的关键用例。

这些列包含所有NFR，包括与参与者相关的NFR，以及由其他（非参与者）利益相关者发起的NFR。

图2.冲突的需求矩阵

对于每行，加号表示NFR（列）在行标题中对操作者NFR产生不利影响的地方，这会通过对系统施加更大的压力来实现。

单行中加号的总和表示压力情况。 它代表了可能对系统造成压力的负载组合。 这些压力情况将在我们的生产前测试中实施。

确定压力案例的条件

该过程的第二步是确定导致出现压力情况的功能条件。 功能通常通过用例表示。 因此，我们从（相关）用例列表开始。 对于每个用例，我们确定在执行过程中可能发生的NFR。 例如，投标项目用例由注册提供者参与者执行。 在这种情况下，可能有200个用户同时对同一拍卖的同一物品出价。

在现实生活中，没有唯一的方法来定义什么是“相关”用例，从而定义“正确”列表。 一方面，列表不能包含新系统的所有用例，另一方面，它不能仅针对每个压力用例包含一个用例。 作为简单的规则，我们将从先前测试中自动化的用例开始。 如果这些不可用，我们可以使用在系统设计期间已确定并被认为是关键的具有体系结构意义的用例。

用于生产前测试的用例的“良好”清单必须满足以下条件：

• 涵盖所有列出的NFR
• 包括新系统的所有主要功能
• 包括高风险或高度敏感的功能

确定用例

定义我们的生产前测试计划的第三步是确定将哪些用例与每个压力用例相关联。 例如，我们的第一个压力案例试图证明我们的系统可以维持注册供应商进行9个小时的拍卖而不会受到干扰。 在感兴趣的供应商执行随机R / O访问的同时，在批处理窗口内的合同系统中注册交易。

要重现这种情况，我们至少需要使用以下用例：投标项目，重新订购项目，浏览拍卖。 它们都必须同时运行。

另一方面，某些情况需要更复杂的判断：可以通过多种使用案例选择来验证“最多200个并发R / W用户”要求。 为了做出好的选择，您必须考虑这些情况的相关性以及在实际操作中产生特定压力条件的可能性。 在某些情况下，可能需要多个测试用例来充分测试压力用例（例如，一个基于投标项目的测试用例和另一个基于列表有效拍卖的测试用例）。 此外，“最多200个并发R / W用户”测试都必须具有并行运行的“噪声”脚本，以产生压力情况所需的背景负荷水平。

可以为多个压力案例选择一些用例。 尽管用例可能相同，但是测试用例可以具有不同的测试环境，例如持续时间，负载，用户数量等，因为每个压力用例都对新系统在生产上的可行性表示自己的看法。 。

为了以正式的方式描述压力案例，因此，我们需要一个工具，该工具能够将用例与测试环境链接到计划和执行结果测试用例。

在本文的其余部分中，我们将探索Rational Quality Manager支持此任务的功能。

使用Rational Quality Manager管理测试活动

Rational Quality Manager是一种协作解决方案，支持软件开发项目中质量管理的各个阶段。 每个活动都分配给不同的角色或团队成员。 定义，资产和工件可以集中收集，以便团队成员始终可以使用它们，并且可以在测试用例，测试计划或项目之间重用。 实时跟踪和分析每个任务的进度以及整个质量管理项目的进度。

除了支持测试团队计划和构建测试计划之外，该工具还提供了实验室管理功能，该功能用于管理资源（例如可用于测试的物理和虚拟系统）。

这些资源是您用来构建测试环境的资源：它们可以是单系统或复杂的多系统配置。 测试人员可以保留预定义的资源，也可以请求特定的配置和构建。

在执行阶段，该工具协调测试活动，支持执行手动测试，并与用于自动化测试的外部工具集成。 所有测试的结果都会存储，并且有大量可供使用的报告可用于以下分析：

• 监视工作分配和执行进度，以优化测试过程和资源分配
• 监视应用程序质量（缺陷数量，严重性，已修复的缺陷等），其在整个版本中的变化情况，直至符合退出标准
• 检查测试计划是否充分满足所有要求

将压力案例转化为测试案例

为了建立生产前的测试计划，我们使用了Rational Quality Manager提供的几种功能和资源：

• 要求：我们的生产前测试必须验证新系统是否真的可以满足生产要求。 到目前为止，我们已经看到，生产需求是相互增强的非功能需求的组合。 在这一点上，我们不跟踪用例或原子NFR的测试，但可以跟踪压力案例的测试范围。 这些是我们的RQM要求。
• 脚本：脚本将用例转换为一系列手动或自动步骤。 脚本是我们用来向实验室测试环境施加压力以验证压力情况的元素。 当确定了重现压力条件所需的用例时，我们需要构建手动和自动脚本来运行它们。
• 测试环境：原子NFR成为我们测试环境的规范。 例如，通过使用电子表格的RS1行中的信息，我们可以在图3（以下）中构建图形，该图形是对可用性测试的测试环境的关键元素的描述。 我们使用这些图形作为我们需要构建的测试环境的高级视图。

图3.可用性测试环境

• 实验室资源：实验室资源是测试环境的基础。 它们可以是物理机或虚拟机。 在我们的RQM测试环境规范中，我们需要做的是确定构建它的资源。 这在可用性测试中显示在图4（下）和图5中，在响应时间测试中显示在图6中。 请注意，实验室资源的定义可能比我们的工作表中表示的要复杂得多。 但是，在定义测试环境时，我们仅关注对我们的测试目标重要的那些特征，即与我们的操作相关要求有关的那些特征。

图4.可用性测试的实验室资源

图5. Rational Quality Manager中的实验室资源定义

图6.用于响应时间测试的实验室资源

• 机器和单元：机器是真实或虚拟测试系统的表示。 可以通过预定使机器可供测试。 测试用例的（真实）测试环境由一组测试机器表示，并称为测试单元。 测试单元是测试环境的物理实现。 机器是具有匹配特征的实验室资源的物理实现。
• 测试用例：需求，脚本和测试环境都与RQM测试用例相关。 通过将适当的测试环境链接到可以按需对系统施加压力的功能的执行，测试用例有助于验证需求。 通过跟踪结果测试用例的执行情况，我们检查了生产要求是否满足。

现在，您可以进行良好的生产前测试（...，并且希望生产顺利）。

摘要

我们已经研究了如何识别代表新系统上实际压力条件的生产前测试。 我们使用技术来确定哪些非功能性需求相互加强，为新系统构建压力案例，然后确定充分测试所需的测试案例。

然后，我们使用Rational Quality Manager将压力案例转换为用于生产前测试的测试脚本和测试环境，以确保测试阶段充分验证新系统的预期负载和执行约束。

---

翻译自: https://www.ibm.com/developerworks/rational/library/define-track-operational-requirements/index.html