系统介绍                                                            

图1（客户关系管理系统模块关系图）

需求分析

一、性能指标

　　性能指标分析，根据客户需求与本系统相结合，用户希望模块能满足下表所列的性能指标。

图2（性能指标）

　　很明显，上面的需求是不具可操作性的，这就像和客户谈需求一样，客户只是很简单地描述了需求，而如果仅仅从上面这个简单的表格来进行性能测试，是很难的一件事情，并且很可能测试出来的结果与实际结果存在很大的差距，这样就需要对需求进行详细分析。
　　有一点需要说明的是，本书只是借助这个系统对一个案例的性能测试的实践做深入的分析，故只选择了部分模块进行测试，并没有对整个系统每个模块的性能测试过程进行详细的分析。

二、需求详细分析

　　既然上面的需要对实际测试指导意义不大，那么就必须对需求作进一步的详细分析。

1、登录

　　目前情况该公司大概有700名员工，但只有500名员工使用该系统，部分员工是不使用该系统的，但5年后，公司大概有800名员工会使用系统，故确定测试100个用户同时并发进行登录操作。所有客户端都在公司的局域网内。

2、联系人管理模块

　　从需求可以看出联系人管理有两部分内容，一是统计进入联系人管理界面的时间，二是新建联系人并提交需求的时间。
　　并发用户数，将进入联系人管理界面和提交新建联系人信息的用户数设置为相同的用户数。即使这样这条需求还是有两层意思：一是有多少用户同时在线；二是在线的用户不一定都进行新建联系人活动的操作，也就是说有多少用户在并发进行新建联系人活动。
　　首先，虽然有500名员工会用到这个系统，但统计日常访问量，同时在线的用户大概是40名左右，即使5年后也差不多是60人同时使用该系统。这样就确定同时在线的用户大概在60名左右。接着，要确定多少用户同时并发进行新建联系人活动，根据日常统计，现在并发用户应该在15个左右，即使是5年后也大概是在25个左右，这样就又确定了同时并发的用户数为25个。
但这样还是不够的，现在系统的记录条数比较少，如果5年后系统中有大量的联系人记录后情况又将怎么样？根据统计每天新增的联系人记录大概在10条左右，一个月大概是200条，这样5年后大概是12000条。这样就可以很清楚地对它进行性能测试了。

3、客户管理模块

　　与联系人管理模块分析相同。

4、商机管理模块

　　与联系人管理模块分析相同。

5、线索管理模块

　　与联系人管理模块分析相同。

测试方案及计划

一、人力资源

　　性能测试作为软件测试的一部分工作，并且性能测试一般都是在系统测试完成后，或者是在系统测试阶段中评估系统功能比较稳定，对性能测试没有影响的情况下进行的。根据测试计划，性能测试允许的时间为25个工作日，故计划需要一个人进行测试。

二、时间进度

图3（时间进度）

三、测试环境准备

　　在进行测试前，必须先搭建好测试平台。服务器安装操作系统为windows2003系统，其中数据库服务器和应用服务器安装在同一台机器上，服务器的IP地址为192.168.14.25。测试机安装的操作系统为windows xp系统，因为测试的并发用户数最多为100个，故只要一台测试机即可，其中controller和负载机为同一台机器。测试机与服务器在同一个局域网内。详细配置如下表。

图4（配置表）

　　测试拓扑结构如图5所示（测试工具：LoadRunner 9.1；录制协议：HTTP/HTML）

图5（拓扑图）

四、业务模型创建

　　测试环境准备好后还要对业务模型进行设置。业务模型是用来约束和规范业务活动的，指导录制脚本时的业务流程及业务背景。如果没有定义好业务模型就很难去录制脚本或者是录制好的脚本无法满足客户的需求，这几个模块具体的业务模型如下表。

图6（业务模型）

　　创建业务模型应该注意以下几点：
1. 对于某个业务流程，用户在使用过程中是如何操作的
2. 一个业务包含多个子业务时，子业务的先后顺序和子业务的关系如何处理。
3. 为了更好地接近用户的使用习惯，确定业务流程需要哪些支持（如数据准备）
4. 确定虚拟用户并发数和系统在线用户数

五、场景模型创建

　　业务模型是用来规定业务如何活动的，那么场景又如何控制呢？这就需要创建一个场景模型。场景模型是用来约束和规范业务活动时的场景环境，指导场景如何设计。也就是说，如果没有定义好场景模型就无法很好地去定义control部分的场景设计或者测试出来的结果和真实的结果还存在很大的差异。这几个模型具体的场景模型如下表所示。

图7（场景模型）

　　创建场景模型应该注意以下几点：
1. 确定虚拟用户如何加载？如何释放？以及场景持续运行的时间，这些数据可以通过以往系统使用的历史记录获得，如果以前没有相关的这方面记录，那么可以通过类似或同行业的情况来做参考。
2. 确定集合点使用的情况
3. 确定是否使用IP欺骗技术
4. 确定要添加哪些计数器

六、测试数据准备

　　完成以上工作后，接下来就要为业务模型准备数据，一般准备数据可以从以下几个方面入手：
1. 数据可以来自于以前的历史数据。如登录模块，测试10个用户同时登录的情况，如果已有10个真实的用户账号信息，那么在准备数据时，就可以直接调用这些现有的数据。
2. 手动添加准备数据。如登录模块，如果现在没有10个现成的真实用户账号信息，那么就需要自已手动去创建，当然创建的方式就有很多种了，可以使用LR进行创建，也可以写一段小程序去创建，当然还可以选择手动创建。但当数据量很大时，选择手动创建就是一件很困难的事，如测试BOSS系统，几千个虚拟用户并发，如果手动去准备这些数据就很麻烦。
3. 数据以何种形式调用。如登录模块的这10个用户账号信息，在测试过程中如何调用，这里会出现两种不同的情况。一是文本形式，文本形式有一个缺点是，LR参数列表中最多允许100行参数，那么如果参数很多就不能用这种方式了，二是数据库的方式，如果大量参数要被调用就应选择数据库的形式，因为数据库形式受记录条件的限制。
各模块数据准备情况如表

图8（数据准备）

　　这些数据都选择LR生成，100个用户账号信息存储在数据库中，以方便参数化时调用

测试用例                                                              

　　测试用例是进行性能测试过程中最重要的环节之一，一般地，一个性能测试用例必须包括用例编号、测试目的、并发用户数、模拟用户行为和预期结果这五大部分。

图9（测试用例表）

执行测试                                                                

一、脚本开发

　　根据业务模型和场景模型可以开始开发测试脚本，主要涉及测试脚本实现过程和脚本的结构。虚拟用户脚本的开发情况如下表

图10（脚本开发用例）

　　对于脚本的结构分析，这里以登录、进入联系人管理界面和新增联系人信息3个业务活动为例。（当然只是理论的提及一下）
1、 登录
在录制脚本中定义一个集合点“并发登录”，用来保证虚拟用户进行了并发登录操作。定义一个事务“提交登录”，这样来统计登录所花费的时间。添加文本检查点，检查登录的用户名是否正确。还有对登录的用户名和密码进行参数化。当然为了测试的方便，在准备数据时，用户名的密码统一设置为1，这时便不需要对密码进行参数化。
2、 进入联系人管理界面
在进入联系人管理界面的脚本中，只需对登录的用户名进行参数化，因为所有用户名和密码都是一样的，所以不用对密码进行参数化。设置集合点，确保所有虚拟用户并发进入联系人管理界面。
3、 新增联系人信息
录制完成脚本后，对脚本进行回放，回放后进入系统查看是否已添加脚本中的新增联系人信息，如果没有的话，则要分析一下是否对脚本进行关联。

二、场景设计

　　场景设计主要是对controller（控制器）进行设置，设置脚本运行时的环境。
　　这里按场景模型创建中所设计的模型来设置就可以了。比如登录模块：在场景组设置100个虚拟用户；在场景策略中，在脚本运行时对所有的虚拟用户进行初始化，每5s加载一个虚拟用户，虚拟用户加载完成后，持续运行5min，运行结束后每5s释放一个虚拟用户，直到所有虚拟用户释放完成。启用IP欺骗功能，脚本中所有集合点都设置为使用的状态。
　　注：在这里没有对负载发生器（load generators）进行设置，因为在试验时只使用了一台机器作负载发生器，并且负载发生器和控制器是在同一台机器上，故看到的负载发生器只有localhost，但是如果在测试过程中有多台时，就得对负载发生器进行配置。还有一点就是如果有多台负载发生器，为了达到负载均衡的目的，需要将所有的负载平均地施压到服务器上，即负载均衡技术。

三、计数器设置

　　计数器设置主要是设置在场景运行时，需要监控哪些资源。在这里所有的脚本都对windows资源和数据库服务器进行监控。可添加如下计数器：windows计数器、MySQL数据库计数器。

四、场景监视

　　在场景运行过程中必须对场景进行监控，通过监控场景运行时的情况以获得一些信息，这样有利于性能测试结果进行分析。如场景组运行控制信息、监视场景状态图、监视输出对话框、监视数据图。（这些在controller面板中都可以直接看到）

结果分析                                                              

　　脚本执行完成后，就得分析测试结果了，每个模块执行的结果都要进行分析。比如登录模块：

　　场景是模拟100个虚拟用户并发登录，当虚拟用户加载到50个时，每加载一个虚拟用户，场景状态栏的失败事务数和错误信息就在增多。这说明当加载到50个虚拟用户后，服务器无法处理客户端的请求。
　　接下来分析平均事务响应时间，可以在analysis中看到结果图，平均事务响应时间一直在增加，也同样说明服务器无法处理客户端的请求，事务一直无法处理完成。到这里可以得出结论，应该是服务器已经出现问题，但还不明确是什么原因导致的。
　　再来看下windows计数器捕捉到的数据，很明显地看到CPU的使用率达到100%，内存也存在问题，但是网络没有问题，这说明服务器的硬件配置无法处理100个虚拟用户并发登录，硬件平台成为性能瓶颈。为了验证这个判断，可以在脚本运行过程中手动登录试一下，结果发现系统几乎无法动弹，这说明判断是正确的。
　　要解决这个问题，必须优化系统配置，否则系统无法处理100个虚拟用户并发登录。

测试结论                                                              

　　分析完成后，每个模块都要写测试结果。比如登录模块：服务器当前的配置无法处理100个虚拟用户并发的活动，测试50个虚拟用户并发时，发现事务都能被成功地处理，但是登录的时间过长，平均时间为60s，系统资源也超过安全指标，但应用服务器正常，可以通过优化服务器的配置来提高性能。

备注：文字讲解来自《深入性能测试--LoadRunner性能测试、流程、监控、调优全程实战剖析》（黄文高、何月顺编著）一书，我是新手，参照此教程做了下实践，顺便将学到的东西写下来。----此篇完全是从书上摘抄下来的理论实战，后续实战后会补上详细的实战操作说明