客户关系管理系统性能测试精编WORD版

客户关系管理系统性能测试精编W O R D版 IBM system office room 【A0816H-A0912AAAHH-GX8Q8-GNTHHJ8】客户关系管理系统性能测试课题名称客户关系管理系统性能测试系/专业班级学号学生姓名指导教师：目录第一章测试计划.....................................................1.1 人力资源....................................................1.2 测试环境....................................................1.3 业务模型创建................................................1.4 场景模型创建................................................1.5 测试数据准备................................................ 第二章测试用例.....................................................第三章执行测试.....................................................3.1 脚本开发 (11)3.2 场景设计....................................................3.3 计数器设置..................................................第四章结果分析.....................................................第五章测试结论.....................................................第一章测试计划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 计数器设置计算器设置主要是设置在场景运行时，需要监控那些资源。