性能测试的研究（3）

压力测试

压力测试是使用高于系统承受能力的数据压力对程序进行测试。其手段是快速消耗资源从而使得程序在“零”资源情况下运转。例如，超负载的用户登录数，大量消耗处理器和内存，剥夺了其他模块获得资源的机会，使得这些模块处于“暂停”状态。

压力测试的目的是为了在高负荷条件下挖掘那些潜在的程序问题。

常见的问题有：
•	同步问题
•	资源竞争
•	内存泄漏
•	网络拥塞导致的数据丢失

和负载测试不同，压力测试是有明确针对性的测试。具有明确的性能指标，明确的测试场景，明确的数据量。负载测试往往是单一的场景测试，而压力测试往往是多个场景的复合测试。负载测试往往没有特殊的先决条件，而压力测试都是在特殊的指定测试环境下进行的。负载测试一般都是用来发现一个问题，而压力测试往往是用来复现一个问题。负载测试一般都是针对业务逻辑进行测试，而压力测试可以是一个简单的对象，例如一个指定的存储过程。

进入文档

执行压力测试的进入文档一般有如下几个：
•	程序的特性（特殊的场景）
•	潜在的问题（隐含的场景）
•	需要的压力数据的特性
•	瓶颈峰值（由负载测试得到的阀值）

步骤

进行压力测试需要的六步流程如下所示：流程包含的步骤如下：
1.	选择测试场景。根据要测试的缺陷，选择相关的测试场景。
2.	设计测试数据。依照测试场景，和由负载测试获得的阀值，来设计所需的测试数据。
3.	指定性能指标。针对测试的缺陷，来指定在压力测试中要监察的性能指标。
4.	创建测试用例。基于测试场景，数据集和缺陷来创建针对性的测试用例。
5.	执行测试用例。在特定的测试环境中执行测试用例。
6.	分析测试结果。 对得到的结果进行分析。

步骤一 选择测试场景

进行压力测试要确定多个测试方案。每个方案都依赖于一个单一的测试场景。一般来说，只有一对一的场景测试，才能更好的发现潜在的性能问题。如下是常用选择场景的原则：
•	选择那些对整体性能有影响的场景。
•	选择那些最有可能影响性能的操作。例如，频繁的锁定操作，同步操作，长事务操作和那些磁盘密集型操作。
•	基于负载测试的结果。通过负载测试，可以探知一些系统的瓶颈。而一般围绕这些瓶颈进行压力测试是一个很好的选择。通过对瓶颈进行更大的压力测试，从而使得程序部分功能阻塞，从而揭显出那些隐藏的问题。

对一个电子商务应用来说，典型压力测试如下：
•	订单处理场景中，程序需要实时的更新产品的库存。所以，会出现数据库数据同步和假死锁的可能。
•	用户在搜索的场景中，使用了一个会返回大量值的关键词。这种搜索会占用大量的内存而使得利用率降至极低。并且很大程度上是一次无效的搜索，浪费了资源。

步骤二 设计测试数据

用于压力测试的数据负载量，首先必须超过阀值。然后，不断调整负载来观察程序的行为。

其中一个设计理念就是对负载测试的反向设计。负载测试是要保证所有影响程序性能的性能指标是处于正常运行的状态下。所以压力测试只要破坏其中任意一个性能指标就可以压垮程序。通过不断的压垮程序的压力数据集，你也可以获得对抗这种潜在的高峰压力的方法。

负载测试的持续时间一般都是有个明确的值。而压力测试的持续时间测很难判断，不但会跟测试环境相关，也跟具体的场景有关。所以，不断的更换测试环境的配置是很有必要的补充，而在负载测试中，测试环境都是要求稳定的一致。

步骤三 指定性能指标

在压力测试前，要明确每个场景存在的隐患所可能涉及到的性能指标。这些性能指标一般都是预设的性能要求或者是根据明确的用户需求推导出来的潜在需求。一般来说，这些性能指标都是和负载测试的指标相同。可以共用同一种方法来获得。例如，在代码中加入的计时器，就可以被二者共享。但是，压力测试的性能指标获得都要比负载测试的过程复杂。

例如，在提交订单这个场景中，最主要的性能指标是资源竞争。除了负载测试需要关心的基本信息，需要获得一些额外的信息：步骤四 创建测试用例

基于以上步骤，创建所需要的压力测试用例。例如一个提交订单的测试用例如下：

触发条件：
•	十万个模拟用户
•	每秒随机两次操作
•	用户异步触发
•	持续两天

性能参数（期望值）：
•	死锁（无硬死锁）
•	接受请求数（不小于25次/秒）
•	驳回请求数（不高于50次/秒）
•	死锁率（不高于35%）
•	解除死锁率（长度不超过100个/秒）

步骤五 执行测试

可以使用手工或者自动化工具对测试用例进行执行。一般执行的时间可以分为两种：
第一种，固定时间。例如，每个模块完成集成测试后，开始执行功能测试前。
第二种，固定阶段。例如，在功能测试完成后进行。

步骤六 分析测试结果

通过分析测试结果，与负载测试的数据进行对比，从而发现那些隐藏的瓶颈的成因。为了更好的修复问题，还需要做如下的额外工作：
•	重新审读设计文档
•	重新审核源代码
•	修改架构并测试来验证结论