活动：设计测试

工作量分析

执行工作量分析将生成工作量分析文档，该文档可用于性能测试。工作量分析文档包括以下主要输入：

• 软件开发计划
• 用例模型
• 设计模型
• 补充规约

工作量分析内容包括：

1. 明确性能测试的目标与用例。
2. 确定模型中要实施的用例。
3. 确定性能测试中要模拟的主角和主角特征。
4. 确定性能测试中要模拟的工作量（以主角、主角类和主角简档的数目计算）。
5. 确定性能评测方法与标准。
6. 复审待实施的用例，确定执行频率。
7. 选择最频繁调用的用例及给系统带来最大负载的用例。
8. 为上一步中确定的每个用例生成测试用例。
9. 为每个测试用例确定关键评测点。

请参见工件：工作量分析文档与指南：工作量分析文档以获得其他信息。

确定并说明测试用例

对于每项测试要求，应：

• 分析应用程序工作流程
• 确定并说明测试用例
• 确定测试用例数据

分析应用程序工作流程

该步骤的目的在于确定并说明主角与系统交互时的操作和/或步骤。这些测试过程说明将进一步用于确定与描述测试应用程序所需的测试用例。

请注意：这些初期的测试过程说明应是较概括的说明，即：对操作的说明应尽可能笼统，而不应具体引用实际构件或对象。

对各个用例或需求，应

• 复审用例事件流，或
• 走查并描述主角与系统交互时采取的操作/步骤

确定并说明测试用例

该步骤的目的是为每项测试需求编写适当的测试用例。

请注意：如果已测试过以前的版本，则测试用例已经存在。应复审这些测试用例，供回归测试及其设计使用。回归测试用例应包括在当前迭代中，并应与处理新行为的新测试用例结合使用。

用于确定测试用例的主要输入包括：

• 在某一点可遍历测试对象（系统、子系统或构件）的用例。
• 设计模型。
• 任何技术或补充需求。
• 测试对象应用程序映射表（由自动测试脚本生成工具生成）。

要说明测试用例，应阐明：

• 受测试的测试条件（或对象状态、应用程序状态）。
• 用例、用例场景或测试用例所依据的技术与补充需求。
• 以输出状态、条件或数据值表示的预期结果。

请注意：没有必要对所有用例、用例场景及技术或补充需求都进行测试。

执行本步骤将得到一份测试用例表格。表中说明测试条件、构成测试条件的对象、数据或对系统的影响，以及预期的结果。

请参见工件：测试用例与指南： 测试用例以获得其他信息。

确定测试用例数据

使用上面生成的表格，复审测试用例，并确定支持这些测试用例的实际值。本步骤将确定用于以下三种目的的数据：

• 用作输入的数据值
• 用作预期结果的数据值
• 用作支持测试用例所需的数据（但是对一个特定测试用例，该数据不会用作输入或输出数据）

请参见工件：测试用例、指南： 测试用例与指南：测试数据以获得其他信息。

确立并结构化测试过程

执行下列操作：

• 复审应用程序工作流程或应用程序映射表
• 开发测试模型
• 使测试过程结构化

复审应用程序工作流程或应用程序映射表

复审应用程序工作流程及先前说明的测试过程，查看是否已对用例作出任何改动，影响到测试过程的确定和结构安排。

如果利用自动测试脚本生成工具，则应复审生成的应用程序映射表（用于生成测试脚本），以确保 UI 对象分层列表（代表测试对象用户界面中的控件）正确无误，并与您的测试和/或受测试的用例相关。

复审进行的方式与前面的分析方式相同：

• 复审用例事件流，并且
• 复审所描述的测试过程，还要
• 走查主角在与系统交互时采取的步骤，还可选择
• 复审应用程序映射表

测试模型的目的在于传达以下信息：测试内容、测试方式以及实施测试的方式。对各个说明的测试过程（或应用程序映射表与生成的测试脚本），需要完成以下步骤以生成测试模型：

• 确定本测试过程与其他测试过程（或生成的测试脚本之间）的关系或顺序。
• 确定本测试过程的起始条件/状态与结束条件/状态。
• 指明本测试过程（或生成的测试脚本）要执行的测试用例。

开发测试模型时应考虑以下问题：

• 很多测试用例互为变体，这意味着可以通过同一测试过程实现这些用例。
• 很多测试用例要求执行的行为可能会交叉。为了能够重复实施这些行为，可使测试过程结构化，使同一测试过程可用于几个测试用例。
• 很多测试过程包含了大多数测试用例或其他测试过程常用的操作与步骤。这种情况下，应决定是否需要专门创建一个结构化的测试过程（对那些常用步骤），而测试用例特有的步骤仍另外保留在一个结构化的测试过程中。
• 使用自动测试脚本生成工具时，应复审应用程序映射表和生成的测试脚本，以确保测试模型反映了以下内容：

  • 正确的（或期望的）控件已包含在应用程序映射表和测试脚本中。
  • 控件按照所需顺序执行。
  • 为那些需要测试数据的控件确定了测试用例。
  • 指定了要在其中显示控件的窗口或对话框。

请参见工件：测试模型。

使测试过程结构化

上述测试过程的说明对实施与执行测试来说并不充分。需要调整测试过程的结构，即修改已说明的测试过程，让它至少应包括以下信息：

• 设置：如何为接受测试的测试用例创建条件，需要哪些数据（无论是输入数据还是测试数据库中的数据）。
• 结构化测试过程的起始条件、状态或操作。
• 对执行的说明：测试员实施与执行测试所采取的详细步骤/操作（说明应详细到对象或构件这一级）。
• 输入的数据值（或引用的测试用例）。
• 每个操作/步骤的预期结果（条件或数据，或引用的测试用例）。
• 评估结果：对得到的实际结果与预期结果进行比较的分析方法与步骤。
• 结构化测试过程的结束条件、状态或操作。

请注意：一个已说明的测试过程，在进行结构化时，可能分解为几个结构化测试过程，它们必须按顺序执行，这样做是为了获取最大的复用性，并使测试过程的维护成本最小化。

测试过程可象测试脚本（用于自动执行）一样手动执行或实施。自动执行测试过程时，生成的计算机可读文件就是测试脚本。

请参见工件：测试过程。

请参见工件：测试脚本。

复审并评估测试覆盖

应执行以下操作：

• 确定测试覆盖评测方法
• 生成并分发测试覆盖报告

测试覆盖评测方法用于确定测试当前或将要达到的完全程度。

确定测试覆盖评测方法

有两种确定测试覆盖的方法：

• 基于需求的覆盖。
• 基于代码的覆盖。

这两种方法都确定了将接受（或已接受）测试的全部可测试项的百分比，但它们使用不同的收集与计算方式。

• 基于需求的覆盖依据：使用用例、需求、用例流或测试条件作为全部测试项的评测方法，这种方法可在测试设计中应用。
• 基于代码的覆盖将生成的代码作为全部测试项，并评测测试中执行的代码特征（如执行的代码行或遍历的分支数）。这种覆盖评测方法只有当代码生成后才能够实施。

确定要使用的方法，并指明如何收集评测结果、如何解译数据及如何在流程中运用指标。

生成并分发测试覆盖报告

测试计划中确定了时间表，说明了何时生成、何时分发测试覆盖报告。这些报告至少应分发给以下角色：

• 所有测试角色
• 开发人员代表
• 股东代表
• 涉众代表

© 1987 - 2001 Rational Software Corporation。版权所有。

Rational Unified Process