客户关系管理系统性能测试.docx
《客户关系管理系统性能测试.docx》由会员分享，可在线阅读，更多相关《客户关系管理系统性能测试.docx（21页珍藏版）》请在冰豆网上搜索。
客户关系管理系统性能测试
项目名称
客户关系管理系统网站性能测试
院系
计算机与软件学院
专业
班级
学号
学生姓名
摘要
以一个客户关系管理系统网站网站为测试背景，使用loadrunner对该系统进行了性能测试，规划测试计划、搭建测试环境、设计及执行测试用例以及进行测试总结，建立了一个较为完整的客户关系管理系统网站的性能测试方案。
关键词：
客户关系管理系统网站；性能测试；缺陷
1测试方案及计划
1.1人力资源
性能测试作为软件测试的一部分工作，并且性能测试一般都是在系统测试完成后，或者是在系统测试阶段中评估系统功能比较稳定，对性能测试没有影响的情况下进行的。
根据测试计划，性能测试允许的时间为5个工作日，故计划需要1个人进行测试。
1.2时间进度
性能测试的计划和时间进度安排，见表1-1
表1-1性能测试计划
性能测试
5个工作日
2011年10月24日
性能测试用例设计
半个工作日
2011年10月24日
测试环境搭建
半个工作日
2011年10月24日
测试数据准备
1个工作日
2011年10月25日
脚本开发
1个工作日
2011年10月26日
测试执行
1个工作日
2011年10月27日
测试结果分析
1个工作日
2011年10月28日
1.3测试环境准备
在进行测试前，必须先搭建好测试平台。
服务器安装操作系统为Windows2003系统，其中数据库服务器和应用服务器安装在同一台机器上，服务器的IP地址为192.168.14.25。
测试机安装的操作系统为WindowsXP系统，因为测试的并发用户数最多为10个，故只要一台测试机即可，其中Controller和负载机为同一台机器。
测试机与服务器在同一个局域网内。
1.4业务模型创建
测试环境准备好之后要对业务模型进行设计，什么叫业务模型？
业务模型是用来约束和规范业务活动的，指导录制脚本时的业务流程及业务背景。
如果没有定义好业务模型那么就很难去录制脚本或者是录制好的脚本无法满足客户的需求。
这几个模块具体的业务模型，见表1-2。
表1-2业务模型
指标种类
业务模型
登录
10个虚拟用户同时并发测试
业务
联系人
1.准备10条联系人记录
2.进入联系人管理界面的并发用户数为10个人
3.新增联系人活动并提交的并发用户数为10个人
客户
1.准备10条联系人记录
2.进入联系人管理界面的并发用户数为10个人
3.新增客户记录并提交的并发用户数为10个人
商机
1.准备10条联系人记录
2.进入联系人管理界面的并发用户数为10个人
3.新增商机记录并提交的并发用户数为10个人
线索
1.准备10条联系人记录
2.进入联系人管理界面的并发用户数为10个人
3.新增线索并提交的并发用户数为10个人
创建业务模型应该注意一下几点：
1）对于某个业务流程，用户在使用过程中式如何操作的？
2）一个业务包含多个字业务时，子业务的先后顺序和子业务的关系如何处理？
3）为了更好地接近用户的使用习惯，确定业务流程需要哪些支持（如数据准备）
4）确定虚拟用户并发数和系统在线用户数。
1.5场景模型创建
场景模型是用来约束和规范业务活动时的场景环境，指导场景如何设计。
也就是说如果没有定义好场景模型，那么就无法很好地去定义Control部分的场景设计或者测试出来的结果和真实的结果还存在很大的差异。
这几个模块具体的场景模型，见表1-3：
表1-3场景模型
指标种类
场景模型
登录
1.启用脚本中的集合点
2.每5秒加载一个虚拟用户，虚拟用户加载完成后，场景持续运行5分钟，结束后，每5秒钟释放一个虚拟用户
3.使用IP欺骗，IP欺骗新建15个IP地址
4.添加Windows计数器
5.监控虚拟用户运行日志文件
业务
联系人
1.启用脚本中的集合点
2.每5秒加载一个虚拟用户，虚拟用户加载完成后，每5秒钟释放一个虚拟用户
3.使用IP欺骗，IP欺骗新建15个IP地址
4.添加Windows计数器
5.监控虚拟用户运行日志文件
客户
1.启用脚本中的集合点
2.每5秒加载一个虚拟用户，虚拟用户加载完成后，每5秒钟释放一个虚拟用户
3.使用IP欺骗，IP欺骗新建15个IP地址
4.添加Windows计数器
5.监控虚拟用户运行日志文件
商机
1.启用脚本中的集合点
2.每5秒加载一个虚拟用户，虚拟用户加载完成后，每5秒钟释放一个虚拟用户
3.使用IP欺骗，IP欺骗新建15个IP地址
4.添加Windows计数器
5.监控虚拟用户运行日志文件
线索
1.启用脚本中的集合点
2.每5秒加载一个虚拟用户，虚拟用户加载完成后，每5秒钟释放一个虚拟用户
3.使用IP欺骗，IP欺骗新建15个IP地址
4.添加Windows计数器
5.监控虚拟用户运行日志文件
创建场景模型还需注意以下几点：
1）确定虚拟用户如何加载？
如何释放？
以及场景持续运行的时间，这些数据可以通过以往系统使用的历史记录获得。
如果以前没有相关的这方面的记录，那么可以通过类似或同行业的情况来做参考。
2）确定集合点使用的情况
3）确定是否使用IP欺骗技术？
4）确定要添加哪些计数器？
1.6测试数据准备
完成以上工作后，接下来就要为业务模型准备数据，一般准备数据可以从以下几个方面入手：
1）数据可以来自于以前的历史数据。
如登录模块，测试10个用户可以同时登录的情况。
如果已有10个真实的用户账号信息，那么在准备模块时，就可以直接调用这些现有的数据。
2）手动添加准备数据。
如登录模块，如果现在没有10个现成的真实用户账号信息，那么就需要自己手动去创建。
当然创建的方式就有很多种了，可以使用LoadRunner进行创建，也可以写一段小程序去创建，当然还可以选择手动创建。
但是当数据量很大时，选择手动创建就是一件很困难的事，如测试Boss（Business&OperationSupportSystem）系统，几千个虚拟用户开发，如果手动去准备这些数据就很麻烦。
3）数据以何种形式调用。
如登录模块的这10个用户账号信息，在测试中如何调用，这里会出现两种不同的情况。
一是文本形式，文本形式有一个缺点是：
LoadRunner参数列表中最多允许100行参数，那么如果参加很多就不能用这种方式了。
二是数据库的方式，如果大量参数要被调用的话就应该选择数据库的形式，因为数据库形式没有受记录的条件设置。
各模块数据准备情况，见表1-4。
表1-4准备数据
指标种类
准备数据
登录
准备好10个正确的用户帐号信息
业务
联系人
准备好12000条联系人记录
客户
准备好2400条客户记录
商机
准备好2400条商机记录
线索
准备好12000条线索记录
2测试用例
测试用例是进行性能测试过程中最重要的环节之一。
一般的，一个性能测试用例，必须包括用例编号，测试目的，并发用户数，模拟用户行为和预期结果这五大部分
1.登陆
用例编号：
LI_001
测试目的：
测试10个虚拟用户并发时，系统登陆的响应时间
并发用户数：
10
模拟用户行为：
1进入登陆界面
2输入用户名和密码
预期结果：
系统登陆的响应时间不能超过5秒
2.进入联系人管理界面
用例编号：
TM_001
测试目的：
测试进入联系人管理界面活动，系统进入联系人管理界面的响应时间
并发用户数：
10
模拟用户行为：
1进入登陆界面
2输入用户名和密码
3进入首页，在导航条处点击“联系人管理”按钮，进入联系人管理界面
预期结果：
系统处理进入联系人管理界面的响应时间不能超过5秒
3.新增联系人
用例编号：
TM_002
测试目的：
测试提交新增联系人活动，系统提交新增联系人的响应时间
并发用户数：
10
模拟用户行为：
1进入登陆界面
2输入用户名和密码
3进入首页，在导航条处点击“联系人管理”按钮，进入联系人管理界面
4在联系人管理界面，点击“新增联系人”按钮
5填写待新增联系人信息，并提交
预期结果：
系统处理提交新增联系人管理界面的响应时间不能超过8秒
4.进入客户管理界面
用例编号：
CL_001
测试目的：
测试进入客户界面活动，系统进入客户界面的响应时间
并发用户数：
10
模拟用户行为：
1进入登陆界面
2输入用户名和密码
3进入首页，在导航条处点击“客户管理”按钮
预期结果：
系统处理进入客户管理界面的响应时间不能超过5秒
5.新增客户记录
用例编号：
CL_002
测试目的：
测试提交客户记录，系统提交客户记录的响应时间
并发用户数：
10
模拟用户行为：
1进入登陆界面
2输入用户名和密码
3进入首页，在导航条处点击“客户管理”按钮
4在客户管理界面，点击“新增客户”按钮
5填写待新增客户信息，并提交
预期结果：
系统处理新增客户信息的响应时间不能超过8秒
6.进入商机管理界面
用例编号：
BC_001
测试目的：
测试进入商机管理界面活动，系统进入商机管理界面的响应时间
并发用户数：
10
模拟用户行为：
1进入登陆界面
2输入用户名和密码
3进入首页，在导航条处点击“商机管理”按钮
预期结果：
系统处理进入商机管理界面的响应时间不能超过5秒
7.新增商机记录
用例编号：
BC_002
测试目的：
测试新增商机记录，系统新增商机的响应时间
并发用户数：
10
模拟用户行为：
1进入登陆界面
2输入用户名和密码
3进入首页，在导航条处点击“商机管理”按钮
4在商机管理界面，点击“新增商机”按钮
5填写待新增商机信息，并提交
预期结果：
系统处理提交新增商机的响应时间不能超过8秒
8.进入线索管理界面
用例编号：
TH_001
测试目的：
测试进入线索管理界面活动，系统进入线索管理界面的响应时间
并发用户数：
10
模拟用户行为：
1进入登陆界面
2输入用户名和密码
3进入首页，在导航条处点击“线索管理”按钮
预期结果：
系统处理进入线索管理界面的响应时间不能超过5秒
9.新增线索记录
用例编号：
TH_002
测试目的：
测试提交新线索活动，系统新增线索的响应时间
并发用户数：
10
模拟用户行为：
1进入登陆界面
2输入用户名和密码
3进入首页，在导航条处点击“线索管理”按钮
4在线索管理界面，点击“新增线索”按钮
5填写待新增线索信息，并提交
预期结果：
系统处理进入商机管理界面的响应时间不能超过8秒
3
执行测试
3.1脚本开发
根据业务模型和场景模型可以开发测试脚本，主要涉及到测试脚本实现过程和脚本的结构。
虚拟用户脚本的开发情况见表3-1。
表3-1虚拟用户脚本开发情况
用例编号
用例名称
开发情况
LI001
并发登录
在脚本中对用户名和密码进行参数化，参数调用是通过读取数据库中的数据来获得，设置文本检查点，检查登录的用户名是否正确
TM001
进入联系人管理界面
该脚本和LI001合并，在LI001登录后，其中有10个虚拟用户进行并发进入联系人管理界面操作
TM002
新增联系人
该脚本和LI001合并，在LI001登录后，其中有10个虚拟用户进行并发提交新增联系人活动操作
CL001
进入客户管理界面
该脚本和LI001合并，在LI001登录后，其中有10个虚拟用户进行并发进入客户管理界面操作
CL002
新增客户记录
该脚本和LI001合并，在LI001登录后，其中有10个虚拟用户进行并发新增客户记录操作
BC001
进入商机管理界面
该脚本和LI001合并，在LI001登录后，其中有10个虚拟用户进行并发进入商机管理界面操作
BC002
新增商机
该脚本和LI001合并，在LI001登录后，其中有10个虚拟用户进行并发新增商机记录操作
TH001
进入线索管理界面
该脚本和LI001合并，在LI001登录后，其中有10个虚拟用户进行并发进入线索管理界面操作
TH002
新增线索记录
该脚本和LI001合并，在LI001登录后，其中有10个虚拟用户进行并发新增线索操作
对于脚本的结构分析，在此登陆、进入联系人管理界面和新增联系人三个业务活动为例。
其他的大同小异，不做详细介绍。
1.登陆
在录制脚本中定义一个集合点“并发登陆”，用来保证虚拟用户真的进行了并发登陆操作。
定义一个事务“提交登陆”，这样来统计登陆所花费的时间。
添加文本检查点，检查登陆的用户名是否正确。
所有代码都放在Action部分。
并发登陆用例的脚本结构如图3-2所示。
图3-2登陆用例脚本结构
2．进入联系人管理界面
在进入联系人管理界面的脚本中，只需对登陆的用户名进行参数化，这里没有对密码进行参数化，因为所有用户名密码都是一样的。
设置集合点，确保所有虚拟用户并发进入联系人管理界面。
其脚本结构图，如图3-3所示。
图3-3进入联系人管理界面脚本结构
3.新增联系人信息
新增联系人脚本是最重要的脚本之一。
录制完成脚本之后，对脚本进行回放，结果如图3-4所示：
图3-4新增联系人脚本
手动添加相同名称的联系人，结果提示：
“存在同名的联系人，是否确定添加”。
到这里说明脚本已经成功添加了联系人，只是在联系人列表中未看到添加的联系人信息，如图3-5所示。
图3-5联系人列表
这说明脚本在处理业务流程时已经出现问题，接下来应该分析添加联系人的业务流程，添加联系人界面如图3-6所示。
图3-6添加联系人
新增联系人脚本结构图，如图3-7所示。
图3-7脚本结构图
其他模块脚本开发和进入联系人管理界面、新增联系人信息的脚本大同小异，故在这里就不对剩下的模块进行一一描述。
3.2场景设计
场景设计主要是对Controller（控制器）进行设置，设置脚本运行时的环境。
这里只对登陆、进入联系人管理界面和新增联系人三个模块进行详细的描述，其他的模块大同小异，在此不进行详细的描述。
1.登录
这里场景组设置10个虚拟用户，如图3-8所示。
图3-8场景组设计
注意：
在这里没有对负载发生器（LoadGenerators）进行设置，因为在试验时只使用了一台机器作负载发生器，并且负载发生器和控制器在同一台机器上，故看到的负载发生器只有Localhost，但是如果在测试过程中有多台时，就得对负载发生器进行配置。
还有一点就是如果有多台负载发生器，为了达到负载均衡的目的，需要将所有的负载平均地施压到服务器上，即负载均衡技术。
场景策略的设置，在脚本运行时对所有的虚拟用户进行初始化，每5秒加载一个虚拟用户，虚拟用户加载完成后，持续运行50秒，运行结束后每5秒释放一个虚拟用户，直到所有虚拟用户释放完成，如图3-9所示：
图3-9场景策略设置
启动IP欺诈功能，脚本中所有集合点都设置为启动状态，如图3-10所示：
图3-10集合点设置
2.进入联系人管理界面
场景组设置10个虚拟用户，如图3-11所示：
图3-11场景组设置
和登录模块一样，负载发生器没有进行设置。
场景策略设置，在脚本运行时对所有虚拟用户进行初始化，每5秒加载一个虚拟用户，虚拟用户加载完成后，持续运行50秒，运行结束后，每5秒释放一个虚拟用户，知道所有的虚拟用户释放完成，如图3-12所示：
图3-12场景策略设置
启动IP欺骗功能，脚本中所有集合点都设置为使用的状态，如图3-13所示：
图3-13集合点设置
3．新增联系人信息
场景组设置10个虚拟用户。
和登录模块一样，负载发生器没有进行设置。
场景策略设置，在脚本运行时对所有虚拟用户进行初始化，每5秒加载一个虚拟用户，虚拟用户加载完成后，持续运行50秒，运行结束后，每5秒释放一个虚拟用户，知道所有的虚拟用户释放完成，如图3-14所示：
图3-14场景策略设置
3.3场景监视
在场景运行过程中必须对场景进行监控，通过监控场景运行时的情况来获得一些信息，这样有利于对性能测试结果进行分析，以下几个方面的信息需要监控。
1.场景组运行控制信息
在这里需要监控场景组中所有虚拟用户运行的情况，同时也可以对虚拟用户运行的情况进行控制，如图3-15所示：
图3-15场景组中虚拟用户运行情况
同时还需要监视虚拟用户组中每个虚拟用户运行的情况，并且一定要观察日志文件的情况，如图3-16所示：
图3-16监视虚拟用户组运行的情况和日志文件
2.监视场景状态图
监视场景状态图中信息的情况，最重要的是关注错误事物的情况，如图3-17所示：
图3-17监视场景运行状态图
4
结果分析
1登录的分析：
场景是模拟10个虚拟用户并发登录，当虚拟用户加载到5个时，没加载一个虚拟用户，场景状态栏的失败事物数和错误信息就增多，如图4-1所示：
这说明当加载到5个虚拟用户后，服务器无法处理客户端的请求
4-1失败事物和错误信息
场景进行完成后，事物都运行成功。
平均事物相应时间如图4-2所示：
图4-2平均事物响应时间
2进入联系人管理界面
场景进行完成后，没有失败事物，事物都运行成功。
平均事物相应时间如图4-3所示：
图4-3平均事物响应时间
而每秒点击数则如图4-4所示：
图4-4每秒运动频率
3.新增联系人
场景运行结束后，首先分析平均事物响应时间，如图4-5所示：
图4-5平均事物响应时间
而吞吐量则如图4-6所示：
图4-6吞吐量图
5
测试结论
每个模块的测试结果如下：
1.登陆模块，服务器当前的配置处理10个虚拟用户并发的活动，测试10个虚拟用户并发时，发现数万都能被成功的处理，登陆的时间还可以，，系统资源也能符合安全指标，应用服务器正常，也可以通过优化服务器的配置来提高性能。
2.进入联系人管理界面
进入联系人管理界面模块，在10个虚拟用户并发时，网络传输时间还可以，系统资源使用也能符合安全指标，再试验20个虚拟用户并发时，发现平均事务响应时间缩短，网络传输也正常，只是系统会出现报错。
通过调优系统配置可以提高性能。
3.新增联系人
10个虚拟用户并发，平均事物响应时间还可以。
但是服务器无法处理25个虚拟用户并发，有页面访问出错的现象，主要可以通过调节系统配置来优化性能，与应用服务器、数据库服务器的关系不大。
升级会员 