客户关系管理系统性能测试

客户关系管理系统性能测试
课题名称客户关系管理系统性能测试
系/专业
班级
学号
学生姓名
指导教师：
目录
第一章测试计划 (3)
1.1 人力资源 (3)
1.2 测试环境 (3)
1.3 业务模型创建 (3)
1.4 场景模型创建 (4)
1.5 测试数据准备 (6)
第二章测试用例 (7)
第三章执行测试 (11)
3.1 脚本开发 (11)
3.2 场景设计 (15)
3.3 计数器设置 (19)
第四章结果分析 (22)
第五章测试结论 (24)
第一章测试计划
1.1 人力资源
性能测试作为测试的一部分工作，根据测试计划，性能测试允许的时间为25个工作日，计划需要一个人进行测试。

1.2 测试环境
在进行测试前，必须先搭建好测试平台。

服务器按章操作系统为Windows 2003系统，其中数据库和应用服务器安装在同一台机器上。

测试机安装的操作系统为Windows XP系统，因为测试的并发用户最多为100个，其中Controller和负载机为同一台及其。

测试机和服务器在同一个局域网内。

详细的测试机与服务器软硬件配置，见表1-1所示；
1.3 业务模型创建
测试环境准备好之后要对业务模型进行设计，知道录制脚本时的业务流程及业务背景，如表1-2所示；
表1-2 业务模型
1.4 场景模型创建
业务模型是用来规范业务如何活动的。

那么场景又如何控制呢？这就需要创建一个场景模型。

什么叫场景模型？场景模型用来约束和规范业务活动时的场景环境，指导场景如何设计。

也就是说，如果没有定义好场景模型，那么就无法很好地去定义Control部分的场景设计或者测试出来的结果和真实的结果还存在很大的差异。

这几个模块具体的场景模型，如表1-3所示；
表1-3 场景模型：
1.5 测试数据准备
完成以上工作后，接下来就要为业务模型准备数据，一般准备数据可以从以下几个方面入手：
1）数据可以来自于以前的历史数据。

如登陆模块，测试10个用户同时登陆的情况，如果已有10个真实的用户账号信息，那么在准备数据时，就可以直接调用这些现有的数据。

2）手动添加准备数据。

如登录模块，如果现在没有10个现成的真实用户账号信息，那么就需要自己手动去创建，当然创建的方式就有很多种了，可以使用LoadRunner进行创建，也可以写一段小程序去创建，当然还可以选择手动创建。

但是当数据量很大时，选择手动创建就是一件很困难的事，如测试BOSS（Business & Operation Support System）系统，几千个虚拟用户并发，如果手动去准备这些数据就很麻烦。

3）数据以何种形式调用。

如登陆模块的这10个账号信息，在测试过程中如何调用，这里会出现两种不同的情况。

一是文本形式，文本形式有一个缺点是，LoadRunner参数列表中最多允许100行参数，那么如果参数很多就不能用这种方式了，二是数据库的方式，如果大量参数要被调用的话，就应选择数据库的形式，因为数据库形式没有受记录的限制。

各模块数据准备情况，见表1-4。

表1-4 准备数据
这些数据都选择loadRunner生成，100个用户账号信息存储在数据库中，以方便参数化时调用。

第二章测试用例
根据测试计划，设计了包括用力编号、测试目的、开发用户数、模拟用户行为和预期结果五大部分的测试用例。

登陆
进入联系人管理界面
新增联系人
进入客户管理界面
新增客户记录
进入商机管理界面
新增商机记录
进入线索管理界面
新增线索记录
第三章执行测试
3.1 脚本开发
根据业务模型和场景模型可以开始开发测试脚本，主要涉及到测试脚本实现过程和脚本的结构。

虚拟用户脚本的开发情况见表3-1
表3-1 虚拟用户脚本开发情况
1.登陆
进入Loadrunner主界面，如图3-1所示；
图3-1 LoadRunner
点击“Create/Edit Scripts”，启用后新建一个用户脚本，因为我们要测试的是Web应用所以如下所示，选择Web(HTTP/Html)协议，如图3-2所示；
图3-2 Web(HTTP/Html)协议
在录制脚本中定义一个集合点“并发登陆”，用来保证虚拟用户真的进行了并发登录操作。

定义一个事务“提交登陆”，这样来统计登陆所花费的时间。

添加文本检查点，检查登陆的用户名是否正确。

所有代码都放在Action部分。

并发登陆实例的脚本结构如图3-3所示。

图3-3 登陆用例脚本结构
对登陆的用户名进行参数化，将参数化的文件放在一个专门管理参数化数据的文件夹中，将参数列表中读取参数的路径由绝对路径更改为相对路径。

在这里并未对密码进行参数化，为了测试方便，在准备数据时，用户名密码统一设置为“Admin”。

故不需要对密码进行参数化。

2. 进入联系人管理界面
在进入联系人管理界面的脚本中，只需对登陆的用户名进行参数化，这里没有对密码进行参数化，因为所有用户名、密码都是一样的。

设置集合点，确保所有虚拟用户并发进入联系人管理界面。

其脚本结构图，如图3-4所示。

图3-4 进入联系人管理界面
3. 新增联系人信息
新增联系人脚本是最重要的脚本之一。

录制完成脚本之后，对脚本进行回放，回放后进入系统查看是否已添加脚本中的新增联系人信息，此时发现，该
脚本中新增用户信息并未被添加（录制脚本使用的登录用户名为test1,添加的联系人姓名为hehel，脚本调试过程中对登陆用户名进行参数化，参数内容为test1和test2），即用户test2中并没有联系人hehel的信息，这说明脚本出现问题。

这时分析回放日志，但并未发现异常日志，这时一种猜测是脚本应该需要关联，前面讲了脚本关联的几种方法，下面进行以下分析处理：
1）使用两个用户test1 和test2 分别录制业务流程一样的脚本。

2）再使用LoadRunner自带的WDiff工具比较两个脚本，此时发现在提交新增联系人信息的过程中“Name=last_name”的内容不一致，如图3-5所示。

图3-5 WDiff比较脚本
这说明每次提交一个新增联系人信息时，“Name=last_name”的值是服务器分配的，并且每次的值都不一样，这就说明需要对该ID进行关联，接着找到需要关联ID的左右边界，手动创建一个关联规则，重新录制脚本即可，关联后代码如图3-6所示。

图3-6 脚本关联
关联后再次进行回放，发现admin下面还是没有添加那个联系人，这说明脚本还是有问题，但实在是想不出哪里有问题，然后手动用admin这个用户名登陆系统，添加刚才的联系人，结果提示：“存在同名的联系人，是否正确添加”。

到这里说明脚本已经成功添加了联系人，只是在联系人列表中未看到添加的联系人信息，如图3-7所示。

图3-7 联系人列表
这说明脚本在处理业务流程时已经出现问题，接下来应该分析添加联系人的业务流程，添加联系人界面如图3-8所示。

图3-8 添加联系人
经过分析发现，在提交新增联系人信息时，有一项“负责人”一直都是当前的用户名，再看一下联系人列表中的“负责人”栏，只有当前负责人添加的联系人信息才会显示出来，而test2用户下其实是添加了hehel这个联系人的，之所以看不到是因为在脚本运行的时候“负责人”项一直都是test1，原因找到了，最后只需要对“负责人”项进行参数化，并且负责人应该和登陆用户保持一致，但问题是不知道脚本中哪一项是负责人信息，又没有其他的技巧，后来经过多次手动试验一项一项的排除后才找到了“负责人”项在脚本的位置，下面是修改后的脚本，如图3-9所示。

图3-9 对负责人的值进行参数化
3.2 场景设计
场景设计主要是对Controller（控制器）进行设置，设置脚本运行时的环境。

这里只对登陆、进入联系人管理界面和新增联系人三个模块进行详细的描述，其他的模块都大同小异，在此不进行详细的描述。

1.登陆
这里场景组设置10个虚拟用户，如图3-10所示。

图3-10 场景组设计
场景策略的设置，在脚本运行时对所有的虚拟用户进行初始化，每5秒加载一个虚拟用户，虚拟用户加载完成后，持续运行5分钟，运行结束后每5秒释放一个虚拟用户，直到所有用户释放完成，如图3-11所示。

图3-11 场景策略设置
启动IP欺骗功能，脚本中所有集合点都设置为使用状态，如图3-12所示。

图3-12集合点设置
2.进入联系人管理界面
场景组设置10个虚拟用户，如图3-13所示。

图3-13场景组设置
和登录模块一样，负载发生器没有进行设置。

场景策略设置，在脚本运行时对所有的虚拟用户进行初始化，每5秒加载一个虚拟用户，虚拟用户加载完成后，持续运行5分钟，运行结束后每5秒释放一个虚拟用户，直到所有虚拟用户释放完成，如图3-14所示。

图3-14 场景策略设置
启动IP欺骗功能，脚本中所有集合点都设置为使用状态，如图3-15所示。

图3-15 集合点设置
3.新增联系人管理信息
场景组设置10个虚拟用户，如图3-16所示。

图3-16场景组设置
场景策略设置，在脚本运行时对所有的虚拟用户进行初始化，每5秒加载一个虚拟用户，虚拟用户加载完成后，持续运行5分钟，运行结束后每5秒释放一个虚拟用户，直到所有虚拟用户释放完成。

如图3-17所示。

图3-17场景策略设置
启动IP欺骗功能，脚本中所有集合点都设置为使用的状态，如图3-18所示。

图3-18集合点设置
3.3 计数器设置
计算器设置主要是设置在场景运行时，需要监控那些资源。

在这里所有的脚本都对Windows资源和数据库服务器进行监控。

这里以登录模块为例，其他的模块设置一致。

1.Windows计数器
添加windows 计数器，具体如何添加在前面讲述过，这里就不再详细描述，监控的对象为需要监控的某台服务器（数据库服务器或应用服务器的Windows 资源），当然因为这里两个服务器都安装在同一台机器，不存在这些之分。

Windows 资源计数器如图3-19所示。

图3-19 Windows资源监控图
2.MySQL数据库计数器
MySQL数据库计数器的添加方式与Windows计数器的添加放肆一样。

被监控的机器为数据库服务器。

MySQL数据库计数器如图3-20所示。

图3-20 MySQL数据库计数器
在添加数据库计数器时，有时场景状态栏输出窗口会提示如图3-20所示的错误信息，如图2-21所示；
图3-21 数据库计数器添加报错
出错的原因是计数器的这些信息和Windows的这些信息名称不相符引起的，有时候在Windows计数器中也会出现。

出错后这些指标的值LoadRunner无法获取。

但是为什么与Windows资源的名称不相符就会报错，并且没有值显示呢？原因是因为LoadRunner的这些计数器的值其实不是自己创建的，而是从Windows系统中调用出来的，故如果名称不一样就无法从系统中读到这些指标的值，这样这些指标的值就无法被Loadrunner显示出来，场景状态栏就会弹出错误提示信息。

Windows操作系统内部监视器如图3-22所示。

图3-22 Windows操作系统监视器
Windows操作系统监视器也可以添加计数器，这和LoadRunner添加的计数器如出一辙。

所以其实这些指标并不是LoadRunner自己去创建的，而是直接从Windows操作系统中“挖过来的”。

3.4 场景监视
在场景运行过程中必须对场景进行监控，通过监控场景运行时的情况来获
得一些信息，这样有利于对性能测试结果进行分析，以下几个方面的信息需要监控。

在这里需要监控场景组中所有虚拟用户运行的情况，同时也可以对虚拟用户运行的情况进行控制，如图3-23所示。

图3-23场景组中虚拟用户运行的情况
同时还需要监视虚拟用户组中每个虚拟用户运行的情况，并且一定要观察日志文件的情况，如图3-24所示。

图3-24 监视虚拟用户组运行的情况和日志文件
监视场景状态图中信息的情况，最重要的是关注错误事务的情况，如图3-25所示。

图3-25 监视场景运行状态图
如果在运行过程中场景状态出现Errors的信息，那么一定要查看输出对话框错误信息的情况，可以帮助调试脚本和分析结果，如图3-26所示。

图3-26 监视输出对话框的提示信息
1.监视数据库
在数据图部分主要监视5个视图的变化（正运行虚拟用户数、事物的响应时间、每秒点击率、Windows计数器和MySQL计数器），如图3-27所示。

图3-27监视数据图的信息
第四章结果分析
1.登陆
场景是模拟100个虚拟用户并发登陆，当虚拟用户增加到50个时，每加载一个虚拟用户时，场景状态栏的失败事务数和错误信息就在增多，如图4-1所示。

这说明当加载到50个虚拟用户后，服务器无法处理客户端的请求。

图4-1 失败事务和错误信息
接下来分析平均事务响应时间，如图4-2所示。

平均事务响应时间一直在增加，也同样说明服务器无法处理客户端的请求，事务一直无法处理完成。

到这里可以得到结论应该是服务器已经出现问题，但还不明确是什么原因导致的。

图4-2 平均事务响应时间
再看一下Windows计数器捕捉到的数据，可以看到CPU的使用率达到100%，内存也存在问题，但是网络没有问题，这说明服务器的硬件配置无法处理100个虚拟用户并发登陆，硬件平台成为性能瓶颈。

为了验证这个判断，可以在脚本运行过程中，手动登陆一次试一下，结果发现系统几乎无法动弹。

这说明判断是正确饿的，系统硬件资源成为系统性能的瓶颈。

要解决这个问题，必须优化系统配置，否则系统无法处理100个虚拟用户并发登陆。

在这里是因为进行实例讲述，不方便去优化系统配置，但可以降低并发用户数，测试35个虚拟用户并发的情况。

在35个虚拟用户时， CPU 的使用率还是几乎达到100%，内存Page/sec的指标超过80，说明硬件配置在35个虚拟用户并发登陆时，还不是最好的，但是并没有失败的事务，这说明处理35个虚拟用户并发登陆时没有任何影响，在这里就不再继续测试下去了，有兴趣的朋友可以自己试试。

通过上面的结果可以得知，系统无法处理100个虚拟用户同时并发登陆，在使用50个虚拟用
户并发登陆时，虽然没有失败的事务，但是事务的处理时间过长，平均时间大概在60秒。

这是因为服务器的硬件配置引起的。

2.进入联系人管理界面
从上图可以看到平均时间在33.188秒，这个时间应该不是很确切，从曲线图中可以看到大概是在40秒，但不管哪个时间，这个平均时间显示是太长了，这样的系统性能不能让人满意。

3.新增联系人
场景运行完成后，首先分析平均事务响应时间，平均事务响应时间为15.893秒，这个时间也是很长的一个时间，并且平均事务响应时间像波浪一样有规律的出现，该页面是在新增加一条联系人记录并保存后进入的页面，本来应该是显示当前添加的信息人信息，但在试验过程中，添加联系人后，系统无法从数据库只能够读取该数据库，导致页面出错，这就是为什么平均事务响应时间达到15.893秒的原因，同时也可以解释为什么平均事务项波浪一样。

因为在新增联系人时，这个页面有时访问成功，有时访问不成功。

第五章测试结论
每个模块的测试结果如下:
1.登陆
登陆模块，服务器当前的配置无法处理100个虚拟用户并发的活动，测试50个虚拟用户并发时，发现事务都能被成功的处理，但是登陆的时间过长，平均时间为60秒，系统资源也超过安全指标，但应用服务器正常，可以通过优化服务器的配置来提高性能。

2.进入联系人管理界面
进入联系人管理界面模块，在25个虚拟用户并发时，平均事务响应时间在40秒，同时网络传输时间明显过长，系统资源使用超过安全指标，再试验20个虚拟用户并发，发现平均事务响应时间为5秒，网络传输也正确。

这说明通过调优系统配置可以提高性能。

3.增加联系人
25个虚拟用户并发，平均事务响应时间为15.893秒，服务器无法处理25个虚拟用户
并发，有页面访问出错的现象，主要可以通过调节系统配置来优化性能，与应用服务器、数据库服务器的关系不大。