性能2
上一篇 / 下一篇 2008-01-24 10:59:42 / 个人分类：性能
2.1负载压力测试
负载测试是通过逐步增加系统的负载，测试系统性能的变化，并最终确定在满足性能指标的情况下，系统所能承受的最大负载的测试。该测试的特点：
（1） 这种测试方法主要目的是找到系统处理能力的极限
（2） 这种测试需要在给定的测试环境下进行，通常需要考虑被测系统的业务压力量和典型场景，使的测试结果具有业务上的意义
（3） 这种测试方法一般用来了解系统的性能容量，或是配合性能调优来使用
压力测试是通过逐步增加系统的负载，测试系统性能的变化，并最终确定在什么负载条件下系统性能处于失效状态，并以此来获得系统能够提供的最大服务级别的测试。通俗的讲，压力测试是为了发现在什么条件下系统的性能会变的不可接受。可见，压力测试是一种特定类型的负载测试。
负载压力测试有助于确认被测系统是否能支持性能需求，以及预期的负载增长等。负载压力测试不只是关注不同负载场景下的响应时间等指标，它也要通过测试来发现在不同负载场景下会出现的，例如速度变慢、内存泄露等问题的原因。因此，应该在开发过程中尽可能早的进行负载压力测试。
负载压力测试是性能测试的重要组成部分，负载压力测试包括并发测试、疲劳强度测试、大数据量测试等内容。
1，并发测试
并发测试方法通过模拟用户的并发访问，测试多用户并发访问同一个应用、同一个模块或者数据时是否存在死锁或者其他性能问题。系统的并发测试是负载压力测试的最主要的组成部分。
并发测试方法具有以下特点：
（1）以真实的业务为依据，选择有代表性的、关键的业务操作设计测试案例，主要目的是发现系统中隐藏的并发访问时的问题。例如系统中的内存泄露、线程琐和资源争用等方面的问题。下面列出一些主要关注的问题：
问题类别 | 问题描述 |
内存问题 | 是否有内存泄露 |
是否有太多的临时对象 | |
是否有太多的超过设计生命周期的对象 | |
数据库问题 | 是否有数据库死锁 |
是否经常出现长事务 | |
线程/进程问题 | 是否出现线程/进程同步失败 |
其他问题 | 是否出现资源争用导致死锁 |
是否没有正确处理异常导致系统死锁 |
（2）这种性能测试方法可以在开发的各个阶段使用，需要相关的测试工具配合和支持。
并发测试可以针对整个系统进行，也可以仅仅为了验证某种架构或是设计的合理性而进行，因此其可以在开发的各个阶段使用。一般来说，并发测试除了需要性能测试工具进行并发负载的产生外，还需要一些其他工具进行代码级别的检查和定位。如：Devpartner工具、JProfile工具、JProbe工具等可以在这方面发挥作用。
2，疲劳强度测试
疲劳测试是采用系统稳定运行情况下能够支持的最大并发用户数，持续执行一段时间，通过综合分析交易执行指标和资源监控指标来确定系统处理最大工作量强度性能的过程。
Ø 日常业务疲劳强度模拟
日常业务疲劳强度测试就是模拟系统的日常业务，持续执行一段时间，暴露系统的性能问题，例如内存泄露、资源争用等，分析与调整的方法与并发测试是非常相似的。
Ø 高峰业务疲劳强度模拟
一般情况系统运行都有其高峰期，所以疲劳强度测试必须要模拟这样的高峰业务。我们可以看到这样的负载是对系统的双重考验，既包括负载，又包括长时间。这里我们需要对“一段时间”有个合理的选择，这个时间指标要满足两个主要条件，一是这段时间所处理的交易量要达到系统疲劳强度需求的业务量；二是这段测试周期中必须通过加大负载，以及尽可能长的测试周期来保证疲劳强度测试。
3，大数据量测试
大数据量测试可以分为两种类型：针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试；与压力负载性能测试、疲劳性能测试相结合的综合数据量测试方案。
Ø 独立数据量测试
针对某些系统存储、传输、统计、查询等业务进行大数据量的独立数据量测试。例如，对某些系统经常会有上传、下载的操作，操作的对象可能就是大数据量，包括图片文件、音频文件或者视频文件等。还有些系统存在大量的批处理任务，批处理任务就是指一次操作将对数据库中大量数据进行互斥访问的数据库事务。这种类型的事务通常是更新同一个数据库表中数千项乃至更多的数据。
Ø 综合数据量测试
我们提出“一定的数据量是并发测试与疲劳强度测试的基础”，在并发测试和疲劳强度测试的过程中，如果不考虑数据量对系统性能的影响，无疑会带来一个缺陷。因此在测试实施过程中，我们要采用并发测试、疲劳强度测试以及大数据量测试相结合的综合测试方案。
2.2配置测试
配置测试方法通过对被测系统的软/硬件环境的调整，了解各种不同环境对系统性能影响程度，从而找到系统各项资源的最优分配原则。这种测试有如下特点：
（1） 这种测试方法的主要目的是了解各种不同因素对系统性能影响的程度，从而判断出最值得进行的调优操作。此配置测试方法不同与功能测试并列的那个“配置测试”方法。对整个系统来说，配置测试是针对软件而言，其主要目的是验证软件能否在不同的软硬件环境中正常运行，其主要是功能验证。而这里提到的配置测试方法，是在性能测试领域内的配置测试方法，它的主要目的是了解各种因素对系统性能的影响程度，从而判断出对性能影响最大的因素。
（2） 这种测试方法一般在对系统有初步了解后进行。需要在确定的环境和操作步骤、确定的压力条件下进行。该方法在每次操作执行测试时更换、扩充硬件设备，调整网络环境，调整应用服务器和数据库服务器的参数设置，比较每次测试结果，从而确定各个因素对系统的影响，找出影响最大的因素。
（3） 这种性能测试方法一般用于性能调优和能力规划。
2.3失效恢复测试
失效恢复测试是针对有冗余设备和负载均衡的系统设计的。这种测试方法可以用来检验如果系统局部发生故障，用户是否能够继续使用系统；以及如果这种情况发生，用户将受到多大程度的影响。该方法具有以下特点：
（1） 该测试方法主要目的是验证在局部故障情况下，系统能否继续使用。失效恢复测试方法可以模拟一台或几台设备故障，验证预期的恢复技术是否能够发挥作用。
（2） 这种测试方法还需要指出，当问题发生时“能支持多少用户访问”的结论和“采取何种应急措施”的方案。
（3） 一般来说，不是所有的系统都需要这种类型的测试，只有对系统持续运行指标有明确要求的系统才需要进行这种类型的测试。
三性能测试应用领域
3.1能力验证
能力验证是性能测试中最简单也是最常用的一个应用领域。一个典型的能力验证问题会采用这样的描述方式“某系统能否在A条件下具有B能力”。能力验证领域的主要特点如下：
（1） 要求在以确定的环境下运行。
能力验证要求运行环境必须是确定的，只有在一个确定的环境上，软件性能的规划和承诺才是有意义的。因为无法或是很难根据系统在一个环境上的表现去推断其在不同环境中的表现，因此要求测试环境已确定。
（2） 需要根据典型测试场景设计测试方案和用例。
能力验证需要了解被测试系统的典型场景，并根据典型场景设计测试方案和用例。一个典型场景包括操作序列、并发用户数量等条件。在设计测试用例时需要确定相应的性能指标。
3.2规划能力
规划能力和能力验证有所不同，能力验证应用领域关心的是“在给定条件下，系统能否具有预期的能力表现”，而规划能力应用领域关心的是“应该如何才能使系统具有我们要求的性能能力”。规划能力领域的特点如下：
（1） 是一种探索性的测试。
规划能力领域侧重的是“规划”。也就是说，这个领域内的测试不依赖于预先设定的用于比较的目标，而是要求在测试过程中了解系统本身的能力。
（2） 可被用来了解系统的性能以及获得可扩展性能的方法。
规划能力领域的问题是期望了解系统的能力，或是获得可扩展系统性能的方法。在测试过程中，除了要通过负载测试等方法获得系统的性能外，还需要通过更换设备、调整参数等方法获得系统的可扩展的元素。
3.3性能调优
性能调优应用领域主要对应于系统性能进行调整。一般来说，性能调优活动会和其他的性能测试应用领域活动交杂在一起。性能调优由于可以调整的对象众多，而且并不要求系统完全完整后才进行调优（在开发阶段就可以针对某个设计或是某种实现方式进行调优），因此可以在多种不同的测试阶段和场合下使用。
对于已经部署在实际生产环境下的应用系统来说，对其进行的性能调优可能会首先关注应用系统部署环境的调整，例如，对服务器的调整、对数据库参数的调整及对应用服务器的参数的调整等；但对于正在开发的系统来说，性能调优会更多地关注应用逻辑的实现方法、应用中涉及的算法、数据库访问层的设计等因素，此时并不要求测试环境是实际的生产环境，只要整个调优过程中具有一个可用于比较的测试基准测试环境即可。
确定基准环境、基准负载和基准性能指标 调整系统运行环境和实现方法， 执行测试 记录测试结果进行测试分析
性能调优的标准过程图
一个标准的性能调优过程描述如下：
（1）确定基准环境、基准负载和基准性能指标。
所谓基准负载是指一种可以被用来衡量和比较性能调优测试结果的标准应用环境，测试操作脚本和可被用来衡量调优效果的性能指标。所谓“标准”是指每次运行性能测试的环境要严格保持一致。在实际的性能调优过程中常见的错误包括以下两种：一是没有保证每次执行时数据库具有相同的数据环境，特别是，当执行一次或多次性能测试之后，数据库中会增加许多新数据，这时对系统进行调优并在调优后执行性能测试，得到的结果与以前的结果具有不可比较性；二是对于某些建立在J2EE应用服务器或是dot Net应用服务器上的应用，在应用服务器需要重新启动时，没有注意在测试之前首先进行一段时间的“预热”。因为大部分的J2EE和dot Net应用服务器使用一种在JAVA中被成为hot-spot的技术，这种技术允许应用服务器在第一次运行应用的时候将字节码编译成本地码并执行，这样在后续的执行过程中，应用执行速度会大大加快。但对于应用的第一次运行来说，由于需要增加一个将字节码编译成本地码的过程，因此速度会特别的慢。
（2）调整系统运行环境和实现方法，执行测试。
这个步骤是性能调优的核心步骤。对于一个应用系统来说，包括以下3个方面的调整。
1，硬件环境的调整：主要对系统运行的硬件环境进行调整，包括改变系统运行的服务器、主机设备环境，调整网络环境等。
2，系统设置的调整：主要对系统运行的基础平台设置进行调整，例如，根据应用需要调整系统的核心参数，调整数据库的内存池大小，调整应用服务器使用的内存大小，或是采用更高版本的JVM环境等。
3，应用级别的调整：主要是对应用实现本身进行调整，包括选用新的架构，采用新的数据访问方式或是修改业务逻辑的实现方式等。
在实际的性能调优过程中，具体调整那些部分的内容要视情况而定。如果调整的对象是一个已经在实际生产环境上部署完成的系统，调优的重点可能会放在前两种方式上，因为调整前两种方式的内容容易达到一个比较高的投入/产出比。但对于一个正在开发的应用，或是通过前两种调整仍不能达到一个比较理想的结果的已部署系统，还是需要在应用级别上进行调整。应用级别上进行调整需要使用到多种专门针对代码的性能测试和性能评估工具，如：Devpartner、JProfile、JProbe等。
在性能调优的过程中，不要一次调整过多的参数或是应用实现方法，否则，很难判断具体是哪个调整对系统性能产生了较为有利的影响。根据经验，一次调整3——5个地方是比较合适的方法。
（3）记录测试结果，进行分析。
这个步骤和上一个步骤构成了性能调优过程中的循环，循环的出口是“达到预期的性能调优目标”。
四性能测试组织
4.1性能测试团队的人员构成
要顺利进行性能测试，首要条件是要有一支合适的性能测试队伍。下面主要列下性能测试团队的角色、职责及技能要求。
角色 | 职责 | 技能 | ||||||||||||||||||||||||||||||||||||||||||||||||||||
测试经理 | 1.制定测试计划 2.监控测试进度 3.发现和处理测试中的风险 | TAG:
性能
| ||||||||||||||||||||||||||||||||||||||||||||||||||||
