彩票走势图

• 项目背景
• 项目特点
• 性能测试过程
  • 测试前期准备
  • 测试工具引入
  • 测试计划
  • 测试设计与开发
  • 测试执行与管理
  • 测试分析
• 案例小结

一、项目背景

出于市场考虑，某集成商准备面向中小企业推出一套基于其开发的J2EE应用的解决方案，该解决方案不仅仅是一套开发完成的产品包，而是包括应用系统、应用服务器、数据库服务器、服务器在内的解决方案包。从市场策略方面考虑，该解决方案面向的是相对较低的中小企业市场，因此整个解决方案包要求在满足客户要求的情况下具有最大的性价比。

解决方案能够为客户提供的功能当然是解决方案包首要考虑的问题，但除了功能外，作为整体推出的解决方案包必然需要提供良好的性能；另一方面，由于要求该解决方案包在满足客户要求的情况下具有最大的性价比，也就必须通过容量规划的方式，选择最合适的硬件设备、操作系统、应用服务器和数据库的配合。通过前期的选型和决策，拟采用IBM Open Power 710作为服务器，IBM Wep Shpere 9.0作为应用服务器，Oracle 10g作为数据库服务器，操作系统则从几个不同的Linux发行版本中选择最适合的。因此，对本项目来说，性能选型测试一方面需要验证系统是否满足预期的性能要求；另一方面，也要求能够从多种不同的组合方式中选择出最具有性价比的解决方案架构。

二、项目特点

该项目是针对整体解决方案的选型测试，项目中的Web应用系统采用J2EE架构，服务器拟选用IBM Open Power 710，应用服务器选用IBM Web Sphere 9.0，数据库采用Oracle 10g，操作系统则需要从几个不同的Linux发行版（Suse、Redhat、Redflag、Turbo）中选取具有最佳性能的一个。

该项目是一个典型的性能选型测试，测试过程中，需要根据不同的组合方式，用同样的负载条件进行测试，测试目的是找出各种组合中具有最佳性能的那个。

对这种类型的性能选型测试来说，需要重点关注两个方面：一是规划合理的组合方式和需要关注的性能指标；二是需要保证每次测试的相同负载条件。

三、性能测试过程

本节描述性能测试的全过程，根据本书第5章的性能测试过程描述，按照PTGM模型分别对性能测试的各阶段进行阐述。

测试前期准备

在了解该项目的基本状况之后，首先开始测试前期准备工作。

1.系统基础功能验证

在本案例中，系统基础功能验证工作不包括在选型测试工作中。

2.组建测试团队

根据该项目的具体情况，建立一个3人的团队负责本次测试工作。团队的3个成员中，1名是系统工程师，1名是性能测试设计和分析人员，1名是性能测试开发和实施人员。所有的成员均来自组织内部，且接受了必要的培训。

该团队中的系统工程师承担的工作较多，一方面需要搭建各种不同的环境；另一方面，在测试过程中，必须保持和相关厂商的联系，确保操作系统已经经过仔细调优，得到的测试结果是在当前操作系统下的最佳结果。

3.测试工具需求确认

根据系统测试的要求，综合工具成本和测试团队已有技能考虑，最终确定测试工具至少能满足：

• 支持对Web系统的性能测试，支持HTTP和HTTPS协议。
• 负载生成器和调度工具运行在Windows平台上。
• 支持对WebSphere、Oracle和Linux Server的性能计数器进行监控。

4.性能预备测试

本次性能选型测试需要针对各种不同配置进行，在不同配置下进行相同的测试，我们并没有安排对每个不同配置下的系统进行性能预备测试。

测试工具引入

测试工具引入在本性能测试过程中不作为一个关键的过程，根据本性能测试对工具的功能需求以及团队成员本身使用工具的经验，最终选择Mercury公司的LoadRunner 8.0版本工具作为本次测试使用的主要工具。

测试计划

对本案例来说，由于并不是对系统进行能力验证的性能测试，因此在测试计划阶段，需要重点关注的是选择典型的业务和场景，该业务和场景从以往对Web应用的测试中获取。

1.性能测试领域分析

根据对项目背景的了解，本性能测试要解决的主要问题是在何种配置条件下系统具有最佳的性能表现，根据领域分析，本测试应该落在规划能力领域。

2.用户活动剖析与业务建模

该解决方案中的Web业务系统已经在多个客户现场运行了一段时间，并已经经历过多次能力验证领域的性能测试。因此，在本案例中，可以很容易地从以前的测试计划中获取典型的业务和场景。

本案例中，选取典型业务的原则是：

• 选取业务量较大的业务。
• 选取业务量不大但消耗系统资源多的业务。
• 选取需要重点关注的业务。

表1描述了在选型测试中将会使用到的所有业务，可以以此为基础来进一步分析用户场景，并据此设计相应的测试方案和用例。

表1 选取的业务

当然，按照的要求，需要为每个业务准备其相应的业务操作描述（用例），在其他3个案例（《某省电信公司业务系统的性能测试》、《某通信企业Web业务系统的性能测试》）中，已经展示了对业务操作进行描述的方法，在本案例中这部分内容不是重点，因此不再赘述。

3.确定性能目标

本性能测试的应用领域是规划能力，由于解决方案包面对的是中小企业，预期的用户数量主要从营销部门获得：

• 页面响应时间小于5秒。
• 能够支持的并发用户数不小于50，最大支持并发用户数要求为100。
• 在50个并发用户条件下，服务器的CPU平均使用率小于70%，内存使用率小于75%；在100个并发用户的条件下，服务器CPU平均使用率小于90%，内存使用率小于85%。

4.制订测试时间计划

本案例中，测试时间计划安排如表2所示。

表2 测试时间计划

测试设计与开发

本案例中，由于需要在多个不同的环境中进行性能测试，因此测试环境搭建和测试执行占了主要的时间。

1.测试环境设计

本性能测试需要给出“在何种配置条件下系统具有最佳的性能表现？”这个问题的答案。因此，在性能测试中，需要安排多个不同的配置环境，在不同的配置环境下检查应用系统的性能，并对不同配置条件下的系统测试结果进行分析。

根据该案例的背景描述，需要为不同的操作系统搭建不同的测试环境。最终确定的测试环境为4个，每个环境上除了操作系统不同外，其他内容都相同，如表3、4、5、6所示。

表3 测试环境1

表4 测试环境2

表5 测试环境3

表6 测试环境4

本案例的数据环境设计根据系统环境进行了简单估算。以两个月作为基准的数据存储周期，大致的数据规模如下。

1. 工单数据数量：19800条。
2. 知识经验库数据数量：10000条。
3. 作业计划数据数量：2800条。

对本案例来说，保证数据环境在每次测试中一致非常重要，否则很可能由于数据基础的不同而导致对测试结果的分析出现失误，因此在首次生成基础的数据记录后，通过数据库的export命令将数据导出为本地文件并保存，每次测试开始前，都通过数据库的import命令将数据直接导入到数据库，保证数据环境的一致性。

2.测试场景设计

在表1的基础上，直接使用选择的每一个业务形成一个场景。此外，还对部分业务形成了组合场景。

3.测试用例设计

确定测试场景之后，原有的业务操作描述，可以更进一步完善为可映射为脚本的测试用例描述。

本案例中，以“新建工单”业务为例，可以给出相应的测试用例描述。

用例编号：TC_XXXX_XX-1

用例条件：用户已登录，登录用户具有新建工单的权限

用户步骤和验证方法。

1. 用户单击“新建工单”链接，进入新建工单页面。
   【验证】销售单页面标题为“新建工单”。
2. 用户在新建工单页面中输入工单信息，包括“工单标题”、“工单内容”和“工单要求答复时间”3个域，其他保留默认值，单击“提交”按钮。
   【验证】返回HTTP200，转向的页面标题为“工单新建成功”。

4.脚本和辅助工具的开发

按照测试用例的描述方式，通过测试工具录制用例的步骤，并在测试工具中对脚本进行调试和修改，保证脚本能够达到测试要求，这就是脚本开发过程。本案例设计的业务过程相对简单，按照用例描述直接录制即可。

需要注意的是对脚本的参数化等处理。脚本录制完成后，一般需要对其进行修改操作，包括参数化、关联和增加检查点。第12章中以LoadRunner为例，描述了这几种不同操作的方法和步骤。

辅助工具的开发取决于测试本身的需要，本案例没有使用任何辅助工具。

测试执行与管理

在测试执行与管理之前的过程和活动中，己经明确规划了本性能测试的环境、场景和脚本，在本过程中，只需要按照前面阶段的要求，将测试场景和脚本进行部署，然后执行测试并记录结果即可。

1.建立测试环境

建立测试环境就是按照测试设计中设计的环境设计内容部署测试环境，在本案例中，由于测试的目标之一是要找到硬件配置是否是制约系统性能的主要因素，因此一个较大的风险是能否保证各测试环境之间，体现在测试结果上的差异主要是由操作系统差异导致的，也就是说，在测试环境中，要尽量保证测试的结果不会受到其他因素的影响。为了实现这点，在本测试过程中使用了CheckList来检查具体的数据库设置和应用服务器设置，并由系统工程师对其进行了仔细的调整。

2.部署测试脚本和测试场景

部署测试脚本和测试场景通过LoadRunner来控制。LoadRunner本身提供了较为完善的对测试脚本和场景进行部署和管理的机制。

本案例使用的场景类型是Manual Scenario类型，即完全由用户设定场景的条件。

3.执行测试和记录结果

LoadRunner工具能够在运行测试的过程中自行保存测试的结果，因此无需特别设计方法来记录vu的响应时间等数据，同时，LoadRunner还能够记录部分主机和应用服务器的资源使用信息。

根据设计，最终需要运行的测试内容如表7所示。

表7 需要实际执行的测试项目

测试分析

根据表7的描述，列出执行的各种不同测试结果，并进行分析。为了不使描述显得过于重复，我们没有给出全部测试项目的图表，只是有选择性地给出了具有代表性的分析过程。以下分析结果以“查询知识经验库”和“新增作业计划”为例进行说明。

（1）Suse操作系统上50、100用户条件下的Running Vusers-Average Transaction Response Time曲线如图1和图2所示。

图1 50并发用户条件下的Running Vusers-Average Transaction Response Time曲线

图2 100并发用户条件下的Running Vusers-Average Transaction Response Time曲线

从图1和图2可以看到，当并发用户数超过50时，系统出现了一个明显的性能瓶颈，根据性能下降曲线分析，在Suse操作系统环境下，性能的拐点应该出现在48个Vuser左右。而在50并发用户情况下，系统的平均响应时间在3～5秒之间。

（2）Redhat操作系统上50、100用户条件下的Running Vusers-Average Transaction Response Time曲线如图3和图4所示。

图3 50并发用户条件下的Running Vusers-Average Transaction Response Time曲线

图4 100并发用户条件下的Running Vusers-Average Transaction Response Time曲线

从图3和图4可以看到，当并发用户数超过58时，系统出现了一个明显的性能瓶颈，根据性能下降曲线分析，在Redhat操作系统环境下，性能的拐点应该出现在58个Vuser左右。而在50并发用户情况下，系统的平均响应时间在2～4秒之间。

因此，单从系统能够支持的并发用户数考虑，在Redhat环境下的系统比Suse环境下的系统有一定的优势。

（3）Redffag操作系统上50、100用户条件下的Running Vusers-Average Transaction Response Time曲线如图5和图6所示。

图5 50并发用户条件下的Running Vusers—Average Transaction Response Time曲线

图6 100并发用户条件下的Running Vusers—Average Transaction Response Time曲线

从图5和图6可以看到，当并发用户数超过55时，系统出现了一个明显的性能瓶颈，根据性能下降曲线分析法，在Redffag操作系统环境下，性能的拐点应该出现在55个Vuser左右。而在50并发用户情况下，系统的平均响应时间在3～5秒之间。

从曲线上看，Redffag上的性能表现与Suse上的性能表现基本相当。

（4）Turbo操作系统上50、100用户条件下的Running Vusers-Average Transaction Response Time曲线7和图8所示。

图7 50并发用户条件下的Running Vusers-Average Transaction Response Time曲线

图8 100并发用户条件下的Running Vusers-Average Transaction Response Time曲线

从图形上可以明显地看到，相对于其他3个操作系统，Turbo操作系统下的性能表现明显要差一些。在100并发用户条件下，从30个并发用户开始，响应时间就大于20秒；而在50并发用户条件下，在25个并发用户处，系统有一个明显的性能瓶颈。

由于所有操作系统的优化调整都是由厂商的工程师直接进行的，不排除在调整过程中出现厂商没有很好地进行操作系统设置优化，导致测试结果存在明显差异的情况。

（5）其他测试项目分析。

以上仅从系统能够支持的并发用户数角度对各种不同配置下的系统进行了比较，其实对选型测试来说，需要比较的内容还远不止这些。表8给出了总体的比较结果。

表8-1

表8-2 总体比较结果

从表8可以看到，在不同的操作系统上，CPU、内存使用情况都会有一些差异，但从总体来看，差异并不明显。也就是说，不同的Linux操作系统并不是影响性能的关键性因素。综合总体比较结果以及前面分析的各不同配置条件对并发用户数的支持来看，RedHat操作系统相对来说具有较优的性能。

四、案例小结

该案例的重点在于演示性能选型测试的过程，并进一步演示了如何使用LoadRunner进行结果分析。

性能选型测试/容量规划测试是实际工作中较为常见的一类性能测试要求，一般而言，这种类型的测试都需要通过性能测试的手段从不同的配置中选取具有最佳性能的配置。这种类型的测试需要在两个方面特别注意：一是环境的一致性；二是确定性能测试的主要比较指标。

最后要说明的是，本案例仅描述了一个笔者亲身经历过的选型测试，其中包含的数据不能用来说明本案例涉及的Linux操作系统的性能优劣。