转：性能测试业务场景设计

1测试过程中出现的问题

      最近一段时间，我们的团队连续承担了几个基于J2EE架构的分布式系统的测试工作。在测试过程中，我们多次发现一个问题，就是我们在测试环境中得到的性能指标与生产环境中的性能指标差距较大，理论上应该是测试环境的性能指标优于生产环境的指标，但实际结果是生产环境的性能指标大大优于测试环境下的性能指标。经过不断摸索、总结，我们发现出现以上问题的原因是测试需求分析不到位，导致业务场景设置不合理、不全面，因而出现问题。在这里我们就场景设计方面谈一些自己的看法。

2业务场景分析

      性能测试中涉及的基本场景有两种，即单一业务场景和混合业务场景，这两种业务场景缺一不可，缺少任何一种都不能准确评估系统性能，定位系统瓶颈。如果只做单一业务场景，得到的结果与实际生产环境差距较大，没有实际指导意义；如果只做混合业务场景，不能快速定位系统性能快速降低的原因，起不到定位瓶颈、系统调优的作用。只有两种场景互为补充，才可以获取最符合客户要求的测试结果。下面分别就两种测试场景的具体设计方法结合一个论坛系统进行讨论，一个论坛系统包含三个主要单一业务流程，即用户登陆、发表文章、阅读文章。该论坛支持100人同时在线，支持20人同时发表文章，阅读文章。

3单一业务场景

      单一业务场景主要针对单一业务流程而设计，主要考察某一项单一业务在各种情况下的响应时间，系统资源占用，事务成功率等指标。对于响应时间这个指标，目前国内国际上还没有明确的标准，业界普遍采用的评价准则是2/5/10标准，即2秒以内优秀，5秒以内可以接受，10秒是极限。但是在实际当中，并不仅限与这个标准，例如邮件系统的登录功能可以遵守这个标准，因为只是一个登录功能；但是针对上传附件这个功能，如果附件本身较大，响应时间自然会比较长，所以我们应该灵活掌握标准，以实际需要为准则，确定预期响应时间。事务成功率这个指标，业界采取的一般标准是90%，但是对于一些精密程度要求较高的系统，如金融、证券、银行等系统，事务成功率要求更高，应该达到98%以上，部分功能甚至要求达到100%。下面我们就单一业务场景在标准、极限、超载三种情况下的设计进行讨论。

3.1标准场景

      设计标准场景的目的是验证系统单一业务是否达到所承诺的性能指标，此时系统应该表现良好，响应时间短，事务成功率高，资源利用率合理，如果不能达到以上要求，则说明系统存在瓶颈，应进一步确定瓶颈，并进行系统调优。但是在实际测试过程中，我们往往片面的认为标准场景就是标准用户数，而忽略了操作对象、操作频率也是非常重要的场景内容，如果这样我们设计的操作场景将会如下（以发表文章为例）：

这个场景初看起来没有任何问题，但是我们如果更深入的考虑一下，就会发现一些问题。例如，发表文章，文章的大小对系统的压力是否有影响呢？发表一个1K的文章，和发表一个1M的文章是否有区别呢？一个用户是否会持续不断的发文章呢？如果不是，发文章的频率是多少呢？这需要我们进一步在测试需求中明确，这样设计出来的场景才是真正的标准情况下的测试场景，新的测试场景如下：

新的测试场景增加了标准的迭代时间和标准大小的操作对象，这样的测试场景才是真正的标准测试场景，获得的各项性能指标才具有实际指导作用。

3.2极限场景

      设计极限场景的目的是为了验证系统单一业务否达到承诺的极限情况，在极限的情况下，能否正确完成相应的工作，并保证客户数据安全，响应时间在可接受范围内，资源利用不超标。根据标准场景的分析，我们可以指导极限场景的设计应包括以下部分，即虚拟用户极限，并发用户极限，迭代时间极限，操作对象极限；持续时间极限属于疲劳强度测试，这里不进行讨论。得到的极限测试场景如下：

以上得到共计15种极限情况，由于实际测试过程中资源有限，不可能进行如此全面的测试，可以根据实际情况进行取舍，以用户要求为主导，选择需要的测试场景进行测试。在加压过程中，如果响应时间明显加长，资源利用率异常上升，吞吐量没有随用户增加正比增长则说明系统已到达瓶颈，可以停止测试，转而进行瓶颈确认、系统调优等工作。

3.3超载场景

      设计超载情况测试场景的目的是为了验证系统单一业务在超载的情况下，何时出现性能拐点，何时系统失效，失效对数据库已有数据是否有影响。根据标准场景的分析，我们可以指导超载场景的设计应包括以下部分，即虚拟用户超载，并发用户超载，迭代时间超载，操作对象超载。得到的超载测试场景如下：