写在前面

在软件系统日益复杂的今天，性能已经成为软件质量重要的衡量标准之一，这一点尤其体现在和Web相关的系统上。对Web应用来说，一般以用户感受到的响应时间来描述系统的性能。

  介绍性能测试过程中的一些相关术语：响应时间、并发用户数、事务响应时间、吞吐量、吞吐率、TPS（每秒事务响应数）、性能计数器等。

1.1 性能测试相关术语

1.1.1 并发用户数

关于并发用户的数量，有两种常见的错误观点：一是把并发用户数量理解为使用系统的全部用户的数量，理由是这些用户可能同时使用系统；二是把用户在线数量理解为并发用户数量。实际上，在线用户不一定是并发用户，原因是在线用户不一定就与系统进行了数据交互，例如正在浏览网页信息的用户，对服务器是没有任何影响的。但是，用户在线数量是统计并发用户数量的主要依据之一。

并发主要针对服务器而言，是否并发的关键是看用户的操作是否对服务器产生了影响。因此，并发用户数量的正确理解是，在同一时刻与服务器进行交互的在线用户数量。

并发用户数量的统计方法目前还没有准确的公式，因为不同的系统会有不同的并发特点。例常见的管理系统的并发用户数一般是在线用户的5%-20%左右，所以并发用户数很大程度上是根据经验和行业的一些标准来计算的。

1.1.2 响应时间

  响应时间是指应用系统从发出请求开始到客户端接收到所有数据所消耗的时间。页面响应时间可以分解为“网络响应时间”和“应用程序与系统响应时间”之和

1.1.3 事务响应时间

事务可能由一系列请求组成，事务的响应时间主要针对用户而言，是为了向用户说明业务响应时间而提出的。例如：跨行取款事务的响应时间就是由一系列的请求组成的。

1.1.4 吞吐量

吞吐量是指单位时间内服务器处理客户请求的数量，吞吐量通常使用请求数/秒来衡量，其直接体现服务器的承载能力。

1.1.5 吞吐率（Throughput )

通常用来指单位时间内网络上传输的数据量，也可以指单位时间内处理的客户端请求数量。它是衡量网络性能的重要指标。但是从用户或业务角度来看，吞吐率也可以用“请求数／秒”或“页面数／秒”、“业务数／小时或天”、“访问人数／天”、“页面访问量／天”来衡量。

1.1.6 TPS ( Transaction Per Second )

每秒系统能够处理的交易或事务的数量。它是衡量系统处理能力的重要指标。TPS 是LoadRtumer 中重要的性能参数指标。

1.1.7 点击率（Hit per second )

每秒用户向从Web 服务器提交的HTTP 请求数。这个指标是Web应用特有的一个指标：从Web应用是“请求一响应”模式，用户发出一次申请，服务器就要处理一次，所以“点击”是Web应用能够处理交易的最小单位。如果把每次点击定义为一次交易，点击率和TPS 就是一个概念。不难看出，点击率越大，对服务器的压力也越大。点击率只是一个性能参考指标，重要的是分析点击时产生的影响。

需要注意的是，这里的点击不是指鼠标的一次“单击”操作，因为在一次“单击”操作中，客户端可能向服务器发出多个HTTP 请求。

1.1.8 资源利用率

资源利用率指的是对不同系统资源的使用程度，例如服务器的CPU利用率、磁盘利用率、内存利用率、网络等。资源利用率是分析系统性能指标进而改善性能的主要依据，通过比较配置调优前后系统资源的利用率来判断调优的效果。

1.1.9 思考时间（Think Time）

思考时间是指用户在进行操作是，每个请求之间的时间间隔。对于交互系统来说，用户不肯能持续不断的发生请求，一般情况下，用户在向服务器端发生一个请求后，会等待一段时间再发送下一个请求。在实际的测试过程中，如何设置思考时间是性能测试工程

1.2 性能测试划分

  性能测试的方法主要包括以下几种：

4 负载测试（Load Testing）

4 压力测试（Stress Testing）

4 配置测试（Configuration Testing）

4 并发测试（Concurrency Testing）

4 可靠性测试（Reliability Testing）

2.1   执行策略

主要内容：根据当前版本约束和环境限制，说明性能测试的约束和计划，表明测试的目的，预期达到的效果。

当前性能测试主要从以下几个方面开展：

1.   模拟现网环境。

真实交付的现网环境相似的性能测试环境，所有性能测试的服务器都放置在同一个机房，属于同一个网段，服务器与服务器之间的网络交互通过交换机进行，在这里性能测试既要结合场景评估网络可能带来的性能瓶颈，同时也要在自己的组网中注意规避可能出现的网络性能瓶颈

2.   性能测试数据分为基础数据和业务数据两部分。

性能测试数据库和功能测试环境相互独立。性能测试数据分为基础数据和业务数据两部分。基础数据，指为了使表中的数据达到一定的数量级而填充的数据，目的是测试出数据库索引是否足够优化、表空间、索引空间是否足够；业务数据，指为了使被测系统能够按业务逻辑运行起来的数据，简单地说，就是功能测试所使用的数据，目的是测试出SQL语句是否足够优化、代码是否足够优化等。从另一个角度看，一个指的是配置类规格，一个是能力类规格

3.   屏蔽缓存，模拟最坏的情况。

缓存，是页面性能优化的手段之一。对于非频繁变化的数据，可以在容器中缓存起来，提高读的性能，同时减轻数据库压力。另外，缓存失效后需要重启缓存，即在系统刚发布、重新缓存过程中，用户访问速度会变慢、数据库压力也会加大。

为了避免类似系统刚上线，系统就受到Load过高的场景。在性能测试过程中，我们需要模拟没有缓存的场景。 一切测试的出发点均是指合理的场景内最坏的情况

4.   先单场景，后混合场景，确保每个性能瓶颈都得到调优。

性能测试过程中，选择先执行单场景，后执行混合场景的策略。

单场景执行，可以详细测试到某个页面、某个功能点等单点的性能，这种方式有利于定位性能瓶颈，优化代码。混合场景，在单场景都优化完成后，按照一定的比例对各种场景进行组合，测试整个应用系统的总体性能表现。

5.   拆分，隔离分析，定位性能瓶颈。

性能测试过程中出现的小概率事件，往往隐藏着大的性能瓶颈。为了精确定位到瓶颈，需要将各个功能，或者一个功能的各个步骤进行拆分分析，然后在可能有问题的部分进行再排查，直到瓶颈定位到为止。

6.   根据性能测试通过标准，来判断被测性能点通过与否。

性能测试将结合性能基线，以及互联网的一些业界标准，来评估判断被测试点是否通过

2.2   执行评估

制定性能测试策略之后，在实施性能测试之前，需要对被测系统做相应的评估。实施前的评估，主要目的是明确是否需要做性能测试和确立性能点。性能测试一般要求系统要支撑至少半小时的测试压力，我们要对系统在测试前后状态，以及测试期间各项能力的表现作出分析和评估。

1.  关键业务。

2.  可能的PV量。

3.  逻辑复杂度。

关键业务

首要维度，是确定被测项目是否属于关键业务，有哪些主要的业务逻辑点，特别是跟客户息息相关的功能点。云业务批量购买，批量实施，服务目录展示，性能告警等等

如果项目（或功能点）不属于关键业务（或关键业务点），则可转入第二、三个维度进行评估。

日PV量

第二个维度，是界定被测项目各功能点的PV量。如果PV量很高，系统压力很大，而且又是关键业务，该项目需要做性能测试；而且其关键业务点，可以被确定为性能点。例如，上述例子中的批量购买、批量实施。

如果PV量不高，系统压力不大，但却是关键业务点，则依据第三个维度来判断。

逻辑复杂度

第三个维度，是判定被测项目各功能点的逻辑复杂度。如果一个主要业务的PV量不高，但是逻辑很复杂，则也需要通过性能测试。原因是，当某一个环节响应较慢，就会影响到其它环节，造成连带效应。

其它

以上3个评估维护，是相辅相成、环环相扣的。在实际测试中，应该具体问题具体分析。例如，当一个功能点不满足以上3个维度，但又属于内存高消耗、CPU高消耗时，也可列入性能测试点行列，这就需要我们结合系统在测试中不断完善我们的性能测试策略。

2.3   测试模型

业务模型

当前方案根据个人理解设计各个业务的客户端请求模型，后期可以根据实际商用情况进行调整。

根据请求的动态变化情况，常见的为四种类型——固定式请求模型、浪涌式请求模型、振荡式请求模型和动态式请求模型。以固定式为主进行性能测试。

依照场景和实际商用需求确定业务组合测试模型（未完待续）