使用QALoad做性能测试简要介绍

使用QALoad做性能测试简要介绍

1 引言 
2 产品组成 
2.1 Scrip Development Workbench 
2.2 Conductor 
2.3 Player 
2.4 Analyze 
2.5 协同工作 
3 典型的工作流程 
3.1 录制脚本 
3.2 编辑脚本 
4 脚本特点 
4.1 Transaction 
4.2 DataPool 
4.3 Checkpoint 
4.4 计数器 
4.5 Verify 
4.6 Validate 
5 配置Session 
5.1.1 Test Information 
5.1.2 scrīpt Assignment 
5.1.3 Machine Configuration 
5.1.4 Monitoring Options 
5.1.5 Machine Assignment 
6 Analyze 
6.1.1 报告的基本模式 
6.1.2 具体的报告介绍 

 
使用QALoad做性能测试简要介绍

1 引言
QALoad是一个主流的商业的性能测试工具（据说是最好的性能测试工具）。因为它是我使用的第一个商业的性能测试工具，所以对它的功能，我无法给出一个和同类产品比较的结果。而只能说说我自己的认识和感受。
从我个人初步使用经验来说，QALoad功能强大，且概念清晰，易于理解，配套设施也很完善。

2 产品组成
QALoad从产品组成来说，分为4各部分, Scrip Development Workbench，Conductor，Player， Analyze。

2.1 Scrip Development Workbench
这个可以看作是录制，编辑脚本的IDE。它支持的协议包括WWW，数据库访问等等。录制的动作序列最终可以转换为一个cpp文件。

2.2 Conductor
对于脚本运行时的配置，由Conductor负责。对于实际的一个测试，特别是性能测试，下面一些细节都需要确定
· 部署在那些player上面
· 有多少虚拟用户(virtual user)
· 每个用户运行多少次Transaction
· 等等
QALoad把所有这些配置数据用一个概念来表达: Session.并可以存在一个以ID结尾的文件里。这样，对于负责的配置，可以一次配置，多次使用。

2.3 Player
Player就是一个Agent，一个运行测试的agent，可以部属在网络上的多台机器上。

2.4 Analyze
Analyze是测试结果的分析器。它可以把测试结果的各个方面展现出来。

2.5 协同工作
总的来说，这4个工具工作起来大概是这个样子，箭头表示文件的传递。

1. workbench 产生测试脚本，cpp编译后的dll文件
2. conductor产生一个session文件，里面 保存了player信息和dll信息
3. conductor执行一个session，把dll交给player来运行
4. player执行dll，产生一个timing文件
5. conductor把所有player产生的timing文件交给Analyze分析
6. analyze生成各种报表，把测试结果展现给用

3 典型的工作流程
对开发者来说，一个典型的工作流程是这样的：
· 在workbench里录制脚本，然后根据时间测试的需要修改录制的原始cpp文件。最后编译cpp文件为dll文件；
· 在conductor里，配置一个test session
· 在conductor里，执行此session。执行文件会自动发送到player那里执行。
· 执行完毕后，conductor会自动启动analyze来分析此次执行的结果

3.1 录制脚本
商业的自动化测试工具都把 易用性作为卖点。所以录制过程是相当的简单。以WWW协议为例(本文档都以WWW协议为例)，点击 录制 按钮后，它会自动打开IE，然后你在IE上完成所需要的步骤，点击 停止按钮就可以了。

一个录制过程的结果是一个capture文件（以cap为后缀名）。对开发者来说Capture文件没有什么用。它的作用是转化为visual tree文件（以vistree为后缀名）。

转化命令在capture文件条目上的右键菜单里。转化的结果是两个同名的文件，一个vistree文件和一个cpp文件，比如xxx.cap转化为xxx.vistree和xxx.cpp.

Visual tree文件的目的是，把测试脚本的流程 (包括步骤和验证等) 用一棵可视化的树来表现。这种功能的动机是可以理解的，但如果你熟悉了它的机制，并且测试逻辑比较复杂，很显然，直接编辑代码会方便得多。

在这里，我建议不要直接修改xxx.cpp,因为workbench会假设xxx.cpp和xxx.vistree在内容上是一致的，并且如果你在vistree上操作的话，workbench会自动维护二者的一致。如果二者存在不一致，可能会发生问题。所以，如果你要编辑自己的cpp文件，最好还是从xxx.vistree创建另外一个cpp文件,比如yyy.cpp.

在workshop中，双击打开xxx.vistree,然后在右边的tree的任意一个节点上点右键，选择”Create Editable scrīpt File …”

3.2 编辑脚本
QALoad测试脚本具有下面的特点
1） 脚本语言是c++语言；
2） 对每一种协议，QALoad提供了一些协议相关的函数，使得在此协议上的工作更容易。比如对于www，QALoad提供了Navigate_To来发送一个到Server的Get请求；
3） Transaction。Transaction是QALoad测试脚本运行和结果分析的核心，在下面有详细的介绍。
4） QALoad提供了几种机制来让你更好的完善测试脚本，其中重要的包括

数据池(datapool)
计数器
checkpoint
Verify

对于具体的协议来说，相应的操作函数在manual里有详细的介绍，这里无需多言。

4 脚本特点
下面分topic介绍一些重要特点的使用方法和注意事项。

4.1 Transaction

1） 一个测试脚本有且只能有一个transaction；
2） 所有的需要测试的步骤都必须组织在transaction里面；
BEGIN_TRANSACTION();
//your test logic code
END_TRANSACTION ();
3） 虽然在脚本里看上去transaction只会运行一次，但实际上在配置session时，你能够定义transaction被多次执行。
4） Transaction里的错误处理有三种方式
    a） Continue。就当没有发生，继续执行下一行代码
    b） Abort。Transaction立即退出，执行此transaction的虚拟用户也随即退出
    c） Restart。跳转到transaction的清理部分执行，然后开始下一个transaction。这种方式只有部分协议支持，WWW是其中之一。

注意，对于Restart方式，首先在scrīpt里需要加上clean up的代码，RESTART_TRANSACTION_TOP(); RESTART_TRANSACTION_BOTTOM(); 然后在Conductor里配置Session时，需要指定使用 运行时 使用Restart方式处理异常

4.2 DataPool
数据池可以让你把scrīpt和测试数据分开。Datapool支持两种形式
1） Central Datapool
数据文件放在Conductor机器上。Player需要它的时候，向Conductor索取。注意，对一个测试脚本来说，只能使用一个Central Datapool。
2） Local datapool
存放在player所在的机器上。一个测试脚本可以使用最多64个datapool文件。

配置并使用Datapool的过程
1） 创建datapool。
Workbench menu: File->New->Datapool
Datapool就是一个Matrix。比如创建一个两列的datapool，第一列命名为username，第二列命名为password。
2） 使用Datapool的代码
a） Central Datapool

BEGIN_TRANSACTION();
…
 GET_DATA(); 
 char *name = VARDATA(1);
 char *pswd = VARDATA(2);
 …
END_TRANSACTION();

b） Local Datapool

#define DP_ACCOUNT 2 /* Identifier for a datapool file*/
OPEN_DATA_POOL("scuser.dat", DP_ACCOUNT, TRUE);
…
BEGIN_TRANSACTION();
 …
 READ_DATA_RECORD(DP_ACCOUNT); // Read one record.
 char* name = GET_DATA_FIELD(DP_ACCOUNT, 1); //read col 1
 char* pswd = GET_DATA_FIELD(DP_ACCOUNT, 2); //read col 2
 …
END_TRANSACTION();

3） 在conductor里为session配置datapool
Conductor Tab：scrīpt Assignment->External Data.

问题：如果使用Local Datapool，在测试运行时，conductor是否会自动把datapool数据文件copy到player所在的机器？

4.3 Checkpoint
Checkpoint用来收集执行某段代码的时间。Checkpoint分为自定义checkpoint和自动的checkpoint

对于自定义的checkpoint，它的使用非常简单
比如：
 Char *url =http://xxx/login?user=user1&pswd=pswd1;
 BeginCheckpoint("Login");
 Navigate_To(url);
 EndCheckpoint("Login");
在运行时，执行chekcpointer之间的代码的时间被精确的统计。

自动的checkpoint是对QALoad自己定义的函数，比如上面提到的Navigate_To，自动生成的checkpoint。你可以用 Set (NEXT_REQUEST_ONLY, CHECKPOINT_NAME, "get logo pic"); 来给下一个自动checkpoint命名。

我建议尽量使用自定义checkpoint。

4.4 计数器
在QALoad里，计数器是一个很有用的概念。Counter的作用是收集运行中的一些数据，在分析测试结果时，在Analyze中可以很方便的把counter的数目查询和显示出来。在Analyze中有一个counter面板，里面可以查看所有的计数器。

QALoad自己也使用了很多计数器。比如“功的Transaction数目”就是用counter来计数的。

使用counter非常简单，只需要下面两个函数(宏), DEFINE_COUNTER ， 和COUNTER_VALUE。Manual里有详细的用法。

4.5 Verify
QALoad没有提供一个通用的Assertion机制，像unit test framework里的assert机制在QALoad里没有提供。

针对WWW，它提供了一个Verify函数，但只能处理page title的验证。

Verify函数的调用结果根据 运行时 错误处理机制的不同有不同的行为。
如果错误处理设置为 Continue,那么它返回一个False值，程序继续执行。如果错误处理设置为Restart，程序会跳到ESTART_TRANSACTION_BOTTOM()执行。

4.6 Validate
在QALoad Workbench里，你不能Debug你的scrīpt，有时候非常不方便。但是，Workbench也提供了另外一种方法能让你快速排错，那就是validate。

Validate能让你在workbench里立即运行一个测试脚本，而无需创建一个session，然后在player里运行。DEBUG的时候写一些print语句，然后validate应该很管用。

Validate命令在editor编辑文档的右键菜单里。

5 配置Session
在Conductor里配置Session。作为通用工具，Conductor提供了很多参数，但很多我们都无需关心。我们重点关注下面2点
· 如果配置虚拟用户
· 如何配置Transaction
配置好的Session可以保存为文件，方便下次调用。Session的配置一共分5页

5.1.1 Test Information
配置基本信息

5.1.2 scrīpt Assignment
在这里配置Transaction
· scrīpt：选择要运行的脚本
· Type：协议类型
· Transaction：每个VU要运行多少个Transaction
· Debug Options：调试选项，一般不修改
· Error Handling：错误处理，参加前面的错误处理介绍。根据测试要求选择一种
· Sleep Factory%：睡眠因子。所有用DO_SLEEP(st)的st在执行时都要乘上睡眠因子。比如DO_SLEEP(100), Sleep Factory = 10, 那么在运行时实际睡眠时间时100X10% = 10 Seconds
· Pacing: Transaction依次启动的间隔时间
· Time Option：一般不修改
· External Date：配置DataPool在此。如果在脚本里使用到了DataPool，一定要在这里配置，否则运行时会找不到DataPool。

5.1.3 Machine Configuration
其实就是配置Player

5.1.4 Monitoring Options
集成ServerVantage。ServerVantage部署在目标server上用来收集目标server的performance信息。现在没有用到。

5.1.5 Machine Assignment
在这里配置VU
· scrīpt：运行的scrīpt
· WWW：协议类型
· Starting VU：启动的时候有多少VU
· VU Increment：每次增加几个VU
· Time Interval：增加VU的时间间隔
· Ending VU：最多加多少VU
· Machine：Player所在的Machine
· Mode：Thread模式或者Process模式，在windows上一般选择thread，如果在linux/unix上，可以选择process 

6 Analyze
Analyze再次体现了商业工具的价值。从Analyze可以得到测试相关的各个方面的数据。

6.1.1 报告的基本模式
在查看令人眼花缭乱的各种report之前，我们需要了解这些报告的基本模式。

Player收集数据的模式是 周期性的 对运行系统做快照。那么自然地，在report地时候，都是以运行时间为X坐标轴，数据值为Y坐标轴。

6.1.2 具体的报告介绍
理解了这一点，那么也就能理解所有的Report。比如在Report Panel里report：
1） Summary
基本的统计信息。主要是执行时间，Transaction失败数目，主要的Checkpoint的时间。
2） Session
Session里配置的信息
3） Concurrent User
整个执行时间段，VU数目的变化情况
4） Response Time Analysis
整个执行时间段，每种Transaction的响应时间变化情况
5） Output
错误信息输出
6） Client Throughput
整个执行时间段，client端的一些信息，比如接受到的数据，发送的数据，随时间变化的信息。
7） Transaction Throughput
 整个执行时间段，Transaction个数随时间变化的信息
8） Top Ten Longest Checkpoint Duration
显示最耗时的Checkpoint，因为Checkpoint总是和特定的步骤相关，所以实际显示了最耗时的步骤。

其他的3个panel，Checkpoints，Counters，Player Performance Counters，其数据展示都是以运行时间为X坐标轴，数据值为Y坐标轴这种形式。