指南：工作量分析文档

工作量分析文档

工作量分析文档用于在不同的性能测试中确定要使用的变量并定义变量值，利用这些性能测试可以模拟主角特征、最终用户业务功能(用例)、负载和容量。

主题

软件质量要从不同的维度来进行评估，其中包括可靠性、功能和性能(请参见)。创建工作量分析文档(请参见)是为了识别并定义不同的变量，这些变量会影响应用程序或系统的性能，并会影响到评估性能所需的评测。工作量分析文档由以下角色使用：测试设计员(请参见)使用工作量分析文档来为不同的性能测试生成测试用例

测试员(请参见)使用工作量分析文档来更好地了解测试的目标并正确地实现该目标

用户代表(请参见)使用工作量分析文档来评估在进行性能评估时所执行的工作量、测试用例和测试的适当性。

工作量分析文档中包括的信息侧重于以下主要变量的特征和属性：要在性能测试过程中执行和评估的用例(请参见)

要在性能测试过程中模拟/仿真的主角(请参见)

负载 - 同时参与的主角的数量和类型、被执行的用例的数量和类型以及时间或吞吐量百分比。

将用来执行并评估性能测试的部署系统(实际的、模拟的或仿真的)(请参见，部署视图)

如其名称所示，性能测试是为了评测和评估测试对象的性能特征或行为而执行的。为了成功地设计、实施和执行性能测试，需要确定并使用代表实际情况的变量值，以及这些变量的例外值。

可以为性能测试确定并使用两种类型的用例：- 在性能测试中所评测和评估的用例

- 可能对关键用例的性能行为产生影响的非关键用例

并非在测试对象中实施的所有用例都是性能测试的对象。关键用例是那些将成为性能测试重点的用例，这意味着它们的性能行为将得到评测和评估。

要确定关键用例，可确定用例是否符合一条或多条以下标准：用例需要评测和评估性能

用例被一个或多个主角频繁执行

用例表现出较高的系统使用率百分比

用例需要使用重要的系统资源

列出关键用例，以将其包括在性能测试中。

在确定并列出关键用例的同时，应检查事件的用例流。特别是，应开始确定当执行用例时在主角(类型)和系统之间的特定事件序列。

另外，还需确定(或核实)以下信息：用例的前提条件，如数据的状态(什么样的数据应/不应存在)和测试对象的状态

可能是常量(相同量)的数据，或从一个用例实例到下一个用例实例必须不同的数据

该用例与其他用例之间的关系，例如在执行该用例时必须遵循的顺序

用例的执行频率，例如同时执行的用例实例的数量，或用例占系统总负载的百分比

与关键用例不同，关键用例是性能测试的重点，而重要用例是那些可能影响关键用例性能行为的用例。重要用例包括符合一条或多条以下标准的用例：用例必须在执行关键用例之前或之后执行

用例被一个或多个主角频繁执行

用例表现出较高的系统使用率百分比

用例需要使用重要的系统资源

用例在执行关键用例的同时在部署系统上定期执行，如电子邮件或后台打印。

在确定并列出重要用例的同时，应检查事件的用例流和附加信息(类似于上面对关键用例进行的检查)。

成功的性能测试不仅需要确定执行关键用例和重要用例的主角，还必须模拟/仿真主角行为。也就是说，一个主角实例在执行与另一个主角实例相同的用例和事件用例流的同时，可以与测试对象进行不同的交互(响应提示、输入不同数据值等活动需要更长的时间)。可考虑以下的简单用例：

一台 ATM 机器的主角和用例。

主角“顾客”在用例执行的第一个实例中是一位有经验的 ATM 用户，但在另一个主角实例中却是一位没有经验的 ATM 用户。有经验的 ATM 主角迅速浏览 ATM 用户界面，他几乎不会花时间来阅读每条提示，而是按照记忆按动按钮。但没有经验的 ATM 主角则要阅读每条提示，并且在作出响应之前要用较多的时间来理解信息。符合实际的性能测试反映了这种差异，从而可确保准确地评估在部署测试对象时的性能行为。

首先确定以上列出的各个用例的主角。然后确定可能执行各个用例的不同主角原型。在上面的 ATM 示例中，可能有以下主角原型：有经验的 ATM 用户

没有经验的 ATM 用户

ATM 用户的帐户位于该 ATM 的银行网络“之内”(用户的开户银行为拥有该 ATM 的银行)

ATM 用户的帐户位于该 ATM 的银行网络之外(其他竞争银行)

对于每个主角原型，需确定主角属性的不同值，例如：思考时间 -主角响应测试对象的各项提示所用的时间

按键速度 -主角与接口交互的速度

请求速度 - 主角向测试对象提出请求的速度

重复次数 - 按顺序重复用例或请求的次数

交互方法 -主角所使用的交互方法，例如使用键盘输入值、切换到某个子段、使用快捷键等，或使用鼠标“指向并单击”、“剪切并粘贴”等。

此外，对于每个主角原型，应确定它们的工作简档，并指定它们要执行的所有用例和流程，以及执行用例的主角所用时间的百分比或工作量的比例。这些信息可用于确定和创建符合实际的负载(请参见下面的“负载和负载属性”)。

另外，还必须确定唯一标识环境的部署系统特定属性和变量，因为这些属性也会影响性能的评测和评估。这些属性包括：物理硬件(CPU 速度、内存、磁盘缓存等)

部署构架(服务器的数量、处理活动的分布等)

网络属性

可以与测试对象同时安装和执行的其他软件(和用例)

确定并列出性能测试中可以包括的系统属性和变量。该信息可以从多处获得，其中包括：软件构架文档(请参见，部署视图)

前景文档(请参见)

涉众请求(请参见)

前面已经提到过，负载是影响测试对象的性能行为的因素之一。负载的定义为：“模拟的最终用户与测试对象进行交互的实例，以及影响系统使用和性能的变量”

准确地确定将被用来执行和评估性能行为的负载是很关键的。一般情况下，性能测试要在不同的负载下执行多次，每种负载都是下列属性的一种变形：与测试对象同时进行交互的主角数量

与测试对象进行交互的主角类型(以及每个主角所执行的用例类型)

各个关键用例的执行频率，及其按顺序执行的频率(重复频率)

对于用于评估测试对象性能的每种负载，应确定以上各变量的值。各个变量在不同的负载中所使用的值可以从业务用例模型(请参见)中获得，或通过观察和访问主角获得。至少应获得三种负载：最佳 - 反映最佳可能部署条件的负载，例如，只有一个或少数几个主角与系统进行交互、只执行关键用例，这种负载在测试过程中很少执行或根本不执行额外的软件或用例。

额定 - 反映当前部署条件的负载。

峰值 - 反映最差部署条件的负载，例如，最大数量的主角、执行最大数量的关键用例，这种负载要同时执行许多或所有额外的软件和用例。

如果性能测试包括强度测试(请参见和)时，应确定几种额外的负载，每种负载都针对于一个系统或负载变量，并将其设置到部署系统的正常预期容量之上。

只有在对测试进行评测并对性能行为进行评估后，性能测试才能获得成功。在确定性能评测和标准时，应考虑以下因素：要进行哪些评测？

在执行测试对象或用例的过程中，关键的评测点在哪里/是什么？

判断性能行为是否可以接受的标准是什么？

性能评测

在执行测试的过程中可以进行多种不同的评测。要确定将进行的最重要的评测，并证明它们为什么最重要。

下面列出了所监测或捕获到的最常见的性能行为：测试脚本状态或状况 - 以图形化方式描述测试执行过程的当前状态、状况或进度

响应时间/吞吐量 - 评测(或计算)响应时间或吞吐量(通常表述为每秒钟处理的事务数)。

统计性能 - 使用统计方法(如平均数、标准偏差和百分位数)对响应时间/吞吐量进行评测性(或计算性)的描述。

追踪 - 捕获执行期间主角(测试脚本)与测试对象之间的来往消息或会话，或者数据流和/或流程。

有关详细信息，请参见。

关键性能评测点

在上面的“用例和用例属性”部分中已经提到，不必为性能测试执行所有用例。同样，不必为每个被执行的用例进行所有性能评测。通常会有一个(或几个)特定的用例流程专门用于评测。或者，在特定的事件用例流中可能存在特定序列的事件，这些事件将为评估性能行为而进行评测。应谨慎地为性能行为的评测选择最重要的起“点”和终“点”。它们通常是最显而易见的事件序列，或者是我们可以通过更改软件或硬件来直接影响的点。

例如，在上面提到的 ATM - 提款用例中，从主角进行提款操作的起点到该用例结束的终点(即主角收到他的银行卡而 ATM 准备接受另一张卡)，我们可以评测整个用例的性能特征，如下图中黑色的“总计花费时间”所示：

但请注意，有很多事件序列会影响总计花费时间。我们可以控制某些事件序列(例如阅读卡中信息、核实卡类型、开始与银行系统的通信等，如上图中的 B、D 和 E 项)，但却无法控制其他序列(例如主角在输入他们的提款金额之前输入他们的 PIN 或阅读提示，如上图中的 A、C 和 F 项)。在上例中，除了评测总计花费时间外，还要评测序列 B、D 和 E 的响应时间，因为这些事件的响应时间对主角来说最为显而易见(并且我们可以通过用于部署的软件/硬件来影响这些响应时间)。

性能评测标准

一旦确定了关键性能评测和评测点，就要检查性能标准。性能标准在补充规约(请参见)中列出。如有必要，应修订该标准。

性能评测通常要使用两项标准：响应时间或吞吐率

百分位数

按秒评测的响应时间或按所处理的事务(或消息)量评测的吞吐率是主要的标准。

例如，在“提款”用例中，所规定的标准为“每个 B、D 和 E 事件(参见上图)都必须在 3 秒钟之内发生(合并后总计为 9 秒)”。如果在测试过程中，我们注意到每个被确定为 B、D 或 E 的事件所花费的时间超过了规定的 3 秒标准，就要记录一项失败。

百分位数评测可以同响应时间和/或吞吐率结合使用，它们用于“在统计上忽略”在规定标准以外的评测。例如，现在规定的用例性能标准为“B、D 或 E 事件的 90% 都必须在 3 秒钟之内发生...”。在测试执行过程中，如果我们评测到所有性能评测中的 90% 都发生在规定标准之内，就不记录失败。