概述
软件质量是在不同的方面(包括可靠性、功能和性能)进行评估的(请参阅概念:质量方面)。创建工作负载分析模型(请参阅工作产品:工作负载分析模型)是为了确定和定义不同变量,这些变量影响应用程序或系统的性能以及评估性能所需的度量。组成模型的工作负载概要信息代表一些条件的候选者,这些条件要在一个或多个测试环境配置下根据目标测试项进行模拟。工作负载分析模型由以下角色使用:
-
测试分析人员(请参阅角色:测试分析人员)使用工作负载分析模型确定测试构想并定义不同测试的测试用例
-
测试设计员(请参阅角色:测试设计员)使用工作负载分析模型定义适当的测试方法,并确定不同测试的可测试性需要
-
测试员(请参阅角色:测试员)使用工作负载分析模型更好地理解要正确实施、执行并分析其执行的测试的目标
-
用户代表(请参阅角色:项目干系人)使用工作负载分析模型评估工作负载的适当性和测试的适当性,其中的测试对于针对该工作负载分析模型有效地评估系统行为是必需的
工作负载分析模型中包含的信息专注于以下主要区域中的特征和属性:
-
要在测试期间执行和评估的用例场景(或实例,请参阅工作产品:用例)
-
要在测试期间模拟/仿真的参与者(请参阅工作产品:参与者)
-
工作负载概要信息 - 表示同时出现的参与者实例的数目和类型、这些参与者实例执行的用例场景和与每个用例场景相关联的在线响应或吞吐量。
-
要在执行和评估测试期间使用的(实际、模拟或仿真的)测试环境配置(请参阅工作产品:测试环境配置。 另请参阅工作产品:软件体系结构文档中的“部署视图”,它应构成测试环境配置的基础)
应将测试考虑为度量和评估测试目标在不同工作负载下运转时的特征和行为。成功地设计、实施和执行这些测试需要确定这些工作负载概要信息的现实数据和例外数据。
为此类测试选择场景要考虑用例的两个方面:
-
关键用例包含了要在测试期间进行度量和评估的关键用例场景
-
重要用例包含可能影响关键用例场景行为的用例场景
这些测试并不一定需要在测试目标中实施的所有用例场景。关键用例包含将是测试焦点的用例场景,即它们的行为会进行度量和评估。
要确定关键用例,请确定满足以下一项或多项条件的用例场景:
-
需要基于工作负载概要信息的度量和评估
-
由一个或多个最终用户(参与者实例)频繁执行
-
代表高百分比的系统使用率
-
消耗大量的系统资源
列出要在测试中包含的关键用例扫描程序。当确定它们时,应复审用例事件流。执行了用例场景之后,开始确定参与者(类型)和系统之间的特定事件顺序。
此外,确定(或验证)以下信息:
-
用例的前置条件,例如数据的状态(什么数据应该/不应该存在)和测试目标的状态
-
可能不变(相同)的数据或一个用例场景必须与另一个不同的数据
-
用例和其他用例之间的关系,例如执行用例时必须采用的顺序。
-
执行用例场景的频率,包括诸如同时发生的用例实例数,和每个场景带给系统的负载占总负载的百分比之类的特征。
与关键用例场景(它们是测试的主要焦点)不同,重要用例场景是可能影响关键用例场景的性能行为的用例场景。重要用例场景包括符合以下一项或多项条件的用例场景:
-
它们必须在执行关键用例前后执行(从属的前置条件或后置条件)
-
它们由一个或多个参与者实例频繁执行
-
它们代表高百分比的系统使用率
-
它们需要大量的系统资源
-
它们将在关键用例场景执行时在所部署的系统上例行执行,例如电子邮件或后台打印
当确定和列出重要的用例场景时,请如对关键用例场景所做的处理那样,复审用例事件流和附加信息。
成功的性能测试不仅需要确定执行关键用例场景和重要用例场景的参与者,还需要模拟/仿真参与者行为。即,参与者的一个实例可以在执行与该参与者的另一个实例相同的用例场景时,与测试目标进行不同的交互(花更长时间响应提示、输入不同的数据值等)。请考虑下面的简单用例:
ATM 机器中的参与者和用例。
执行用例场景的“客户”参与者的第一个实例可能是一个经验丰富的 ATM 用户,而“客户”参与者的另一个实例可能在使用 ATM 方面经验不足。经验丰富的“客户”快速在 ATM
用户界面中浏览,并花很少的时间阅读每个提示,而是直接按下按钮。但是,经验不多的“客户”阅读每个提示,并在响应之前耗费大量的时间理解该信息。 现实的工作负载概要信息反映了这种不同,以确保精确地评估测试目标的行为。
以确定上面确定的每个用例场景的参与者开始。然后确定可能执行每个用例场景的不同的参与者概要信息。在上述 ATM 示例中,我们可以有以下参与者构造型:
-
经验丰富的 ATM 用户
-
经验不多的 ATM 用户
-
ATM 用户的帐户在 ATM 的银行网络“内”(用户的帐户在拥有 ATM 的银行内)
-
ATM 用户的帐户在 ATM 的银行网络外(竞争对手的银行)
对于每个参与者概要信息,确定不同的属性及其值,例如:
-
思考时间 - 参与者响应测试目标的个别提示所需的时间
-
输入速率 - 参与者与界面交互的速率
-
请求速率 - 参与者对测试目标做出请求的速率
-
重复因子 - 用例或请求在顺序中重复的次数
-
交互方法 - 参与者所使用的交互方法,例如使用键盘输入值、切换到某个字段、使用加速键等等,或使用鼠标来进行“定位和单击”、“剪切和粘贴”等等
此外,对于每个参与者概要信息,确定它们的工作负载概要信息,指定它们执行的所有用例场景、参与者执行这些场景所耗费的时间百分比或工作量比例。确定此信息用于确定和创建现实负载(请参阅下面的“负载和负载属性”)。
测试环境配置中唯一确定环境的特定属性和变量也必须进行确定,因为这些属性也会影响行为的度量和评估。这些属性包括:
-
物理硬件(CPU 速度、内存量、磁盘高速缓存等)
-
部署体系结构(服务器数、处理的分发等)
-
网络属性
-
可以同时安装到测试目标并执行的其他软件(和用例)
确定并列出将要考虑包含在测试中的系统属性和变量。此信息可以从若干来源获得,包括:
如前所述,工作负载是影响测试目标行为的重要因素。精确确定将用于评估目标行为的工作负载概要信息是非常重要的。通常,涉及工作负载的测试使用不同的工作负载概要信息执行若干次,每次都代表下面描述的属性的一个变化:
-
与测试目标同时交互的参与者实例数
-
与测试目标交互的参与者的概要信息
-
每个参与者实例执行的用例场景
-
每个关键用例场景执行的频率以及重复的频率
对于用于评估测试目标的性能的每个工作负载概要信息,确定每个上述变量的值。在不同的负载中每个变量所使用的值可以通过观察参与者或者与参与者会谈而得出,或者可以从业务用例模型(如果有可用的业务用例模型)中得出。定义一个或多个以下工作负载概要信息是常见的:
-
最优 - 反映可能的最好部署状况的工作负载概要信息,例如最少数目的参与者实例与系统交互、仅执行关键用例场景、测试期间仅有最少的其他软件和工作负载在执行。
-
平均(AKA 正常)- 反映预期或实际平均使用状况的工作负载概要信息。
-
瞬态峰值 - 反映预期或实际瞬态高使用率状况(这种情况在正常操作期间短时间发生)的工作负载概要信息。
-
峰值 - 反映预期或实际高使用率状况的工作负载概要信息,例如最大数目的参与者实例、执行大量用例场景、测试期间许多其他软件和工作负载在执行。
当工作负载包括压力测试(请参阅概念:性能测试和技术:测试类型)时,应该确定若干个其他负载,其中每个负载都针对系统(该系统处于已部署系统的预期正常容量之外的异常或意外状态)的特定方面。
只有度量了测试并且评估了工作负载行为的情况下,才可能实现成功的工作负载测试。在确定工作负载度量和标准时,应考虑以下因素:
-
要进行什么度量?
-
哪里/什么是测试目标/用例执行中的关键度量点。
-
要用于确定可以接受的性能行为的标准是什么?
性能度量
在测试执行期间,有许多可以进行的不同度量。确定要进行的重要度量,并解释它们为什么是最重要的度量。
下面列出的是监视或捕获的更常见的性能行为:
-
测试脚本状态 - 对测试执行当前状态或进度的图形表述。
-
响应时间/吞吐量 - 对于响应时间或吞吐量(通常以每秒事务数表示)的度量(或计算)。
-
跟踪 - 捕获参与者(测试脚本)和测试目标之间的消息/对话,或执行期间的数据流和/或处理流程。
关于其他信息,请参阅技术:关键测试度量
关键性能度量点
在上面的“用例和用例属性”部分中,已注明了并不是为性能测试执行所有用例及其场景。类似地,对每个执行的用例场景也不是进行所有性能度量。
通常仅针对特定的用例场景进行度量,或在特定的用例场景中有特定的事件序列将进行度量以评估性能行为。应谨慎地为度量性能行为选择最重要的起始“点”和结束“点”。最重要的起始和结束“点”通常是最明显的事件序列的点,或我们可以通过更改软件或硬件而直接影响的点。
例如,在上面确定的“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%
发生在规定的标准之内,则不记下任何失败。
|