提到性能测试，大家想到的就是使用工具对应用进行加压，看看应用能承受多少并发，TPS（Transactions Per Second）是多少，交易响应时间是否在接收的范围内。不错，这些都是大家最关心的应用的性能指标，也是每个性能测试项目输出的结果。然而，要实现这样的效果却并不是一件简单的事情，因为性能测试是一个十分复杂的系统工程，对测试人员的能力水平提出了更高的要求，需要性能测试人员具备非常全面的知识与技能，能够定位应用的性能瓶颈，并提出适当的优化方案。
通常，要对一个应用进行性能测试需要经历需求调研、环境准备、脚本开发、数据预埋、场景设计、场景执行、应用监控分析、瓶颈定位、瓶颈修复、回归测试、结果整理、输出报告等多个环节。
性能测试的场景设计
性能测试的场景如何定义？我们可以理解为功能测试中的用例，即性能测试的场景就是性能测试的用例。性能测试的场景是为了要实现特定的测试目标而对应用执行的压测活动。性能测试场景的设计与执行是整个性能测试活动的核心与灵魂，没有完整的场景设计就无法达到我们的测试目的，没有合理的场景设计就不会发现系统的性能缺陷。我们所开发的测试脚本，所预埋的测试数据都是为了实现特定场景所准备的。
一个性能测试场景包含诸多要素，图1中列出了一些必备的要素，其中测试模型作为测试场景的基础与输入。
在线Web类的应用，测试指标一般包括在线用户数、最优并发用户数、最大并发用户数、交易平均响应时间、目标TPS等等。对于接口调用类的应用测试指标一般包括目标TPS、平均响应时间等。
测试模型就是被测试系统的各交易在线运行时承受的交易数量（或请求数量）的比例而不是并发用户的比例。为什么不是并发用户的比例呢？因为实际的用户的操作具有不确定性，使用测试工具很难模拟真实用户的行为。另外，在进行运营数据分析时很难获取用户的操作行为，而应用的交易记录却很容易通过查询的方式获取。应用实际承受的压力是用户的实际操作请求，在线用户如果没有进行实际操作那么他最多将消耗一个连接线程，而应用CPU并不会有什么资源消耗。100个用户平均每个花费10秒下一个订单和10个用户每1秒钟下一个订单对应用带来的压力是一样的。所以，在场景中能用最少的并发用户来模拟真实的请求是最经济的选择方式。
那么，测试模型到底该如何确定呢？通过需求调研获得。下面介绍的两点是我们常用的调研方式：
∙对于还未上线运营的新系统，我们一般会让应用的产品经理或负责人给出一个预估的比例；但是这个预估需要我们进行评估，不是随意的。对于一个以提供下单交易为主的应用，通常下单交易是占整个模型的较大比例，如果需求方提出的模型是查询比例较高，那么我们就有理由怀疑该模型的合理性。对于这种情况，我们建议选择几个常见的典型的模型来配合需求模型进行场景设计。
∙对于已上线运营的应用，我们一般会分析实际的交易数据来确定交易比例，这样会更加精准。例如一个应用对用户提供下单、查询、退款三个交易，我们通过DBA在线查询某日的交易数据总量
为200000笔，其中交易下单160000笔、查询38000笔，退款2000笔，由此我们算出各交易的比例是80%、19%、1%，那么这个比例就是我们的测试模型。
被测交易或使用的脚本
测试脚本是测试场景的基础，脚本包括对应的测试数据，例如登录所需要的用户名与密码、下单交易可能需要的银行卡号等等。考虑到性能测试是多用户并发的测试，所以需要提前准备相应的测试数据，例如一个场景要对一个含登录操作的交易进行压测，那么我们在场景设计时就要考虑可用的用户名与密码数量；又如，要对退款交易做测试，那么就需要提前准备好可以退款的数据，这就需要提前做好数据预埋准备。
一般情况下，为了方便我们统计TPS，建议一个脚本只包含一个完整的交易，不要把多个交易放到一个脚本中。因为，不同的交易其响应时间会不同，响应时间较长的交易会成为“瓶颈”。另外，我们设计测试场景时需要考虑不同交易的占比，如果多个交易存在同一个脚本里，场景的设计就无法实现。
上文提到的“被测交易”是我们压测的对象，也是应用的入口。当然，并不是被测应用的每个交易都需要进行压测，这要视具体情况而定。如果被测应用提供的交易非常多，我们可以考虑只选取占比比较大的交易进行压测，而占比较低的交易可以忽略。
并发用户数量或并发线程数量
并发用户和并发线程其实是同一个概念，只是在不同的性能测试工具中其叫法不同而已。在下文中我们统称“并发用户”。当然，这些用户是虚拟用户，是压力测试工具使用进程或线程来模拟真实用户请求的一种方式。并发用户是每个场景提供不同压力的直接来源，场景不同其需要的并发用户数量可能会不同。那么是什么因素决定一个场景要并发用户的多少呢？主要是被测交易的响应时间和场景的目标TPS。交易响应时间的快慢是决定并发用户数量的主要因素，例如一个应用的某个交易响应时间是50ms，如果要实现100TPS的目标，那么只需5个并发用户即可达到（目标TPS*交易平均响应时间=并发用户量）。如果响应时间是100ms，那么实现同样的TPS需要的并发用户就会多一倍。
加压策略
加压策略就是并发用户以什么样的“步调”开始对应用发起请求。常用的并发策略有同时加载、指定间隔时间的加载，梯度加载等方式。加压策略的不同主要是模拟生产环境不同的情况，下面分别做简单介绍。
同时加载方式是指所有并发用户在场景启动时同时发起交易请求而不包含任何等待，这样会对被测应用带来突然的压力，用于考察应用在突然加压下的表现是否符合预期。一般有用户突增的业务特点的应用会设计这样的场景，例如，某些抢购系统、铁路售票系统的按时放票功能等。当然，对于那些并发用户较少的场景也可以采用这种用户加载方式。而对于有些应用如果同时加载大量的并发用户可能会出现异常或超时，导致部分并发用户失败。
指定间隔时间的加载方式是我们最常用的，这是为了模拟生产的实际情况，一般生产系统接收用户请求都是逐渐增加的，到当日交易的高峰时段达到最大。在场景设计时，根据并发用户的多少可以设置适当的增加频率，一般是“多长时间增加多少用户”。例如，每一秒钟增加一个用户、每两秒增加5个用户等等。
梯度加压策略也是我们常用的一种用户加载方式，但是这种方式严格来说应该是一种梯度加压场景。该场景一般是预先设置几个并发用户的梯度，每个梯度执行几分钟，这样就可以通过一个场景的执行基本上找到应用的最大TPS。在下文场景类型中，我们会详细介绍这种场景。
运行时间
每个类型的场景其执行时间是不同的。表1为大家提供一个参考值。运行时间是不包含用户的加载时间和退出时间的，即全部用户都在执行的这段时间。
表1 各种典型场景运行时间设置
