性能测试流程

一.资源指标分析

1.判断CPU是否瓶颈的方法

一般情况下CPU满负荷工作，有时候并不能判定为CPU出现瓶颈。比如Linux总是让CPU尽可能最大化使用。
判断CPU瓶颈的条件：CPU空闲持续为0 ；运行队列大于CPU核数（经验值3——4倍）
造成瓶颈的因素：应用程序不合理，硬件资源不足。比如SQL语句引起，则要优化CPU使用过高的SQL语句。

2.判断内存是否瓶颈的方法

一般至少有10%可用内存，内存使用率可接受上限85%。空闲内存过小可能是内存不足或内存泄漏引起的。

3.判断磁盘I/O是否瓶颈的方法

（1）计算每磁盘I/O数。

RAID类型	计算方法
RAID 0	(Reads+Writes)/Numbers of Disks
RAID 1	(Reads+2*Writes)/2
RAID 5	[Reads+(4*Writes)]/Numbers of Disks
RAID 10	[Reads+(2*Writes)]/Numbers of Disks

经过计算得到的每磁盘I/O数超过磁盘标称的I/O能力，则说明存在磁盘的性能瓶颈。
（2）监控磁盘的读/写。如果磁盘长时间进行大数据量读/写操作，且CPU等待超过20%，则说明磁盘I/O存在问题，考虑提高磁盘I/O读/写性能。

4.判断网络带宽是否是瓶颈的方法

通过减小网络带宽，查看并发用户数，响应时间与事务通过率等性能指标是否不能接受。反之，增加网络带宽，性能指标是否明显提高。
如果性能测试始终报连接超时，实际手工访问正常，可以用ping命令查看网络是否同，如果出现网络严重延迟或丢包，则说明网络不稳定。

二.系统指标分析

1.平均响应时间
如果持续并发性能测试，监控平均响应时间逐渐变长，这时需要借助监控到的资源指标，首先排除资源方面的限制元素，再从应用本身进行定位。
2.并发用户数
一般选用高吞吐量，高数据I/O，高商业风险的业务功能进行并发用户访问测试。
3.事务成功率，超时出错率
4.吞吐量
吞吐量通常由QPS（TPS）和并发数两个因素决定。
QPS（TPS）= 并发数/平均响应时间

三.性能调优

性能优化策略：用空间换时间，用时间换空间，简化代码，并行处理。

总结：性能指标是要结合分析的，这种指标都是相关联的，性能调优也是有多方面调优，需要对数据库，算法，网络，代码熟悉，根据积累的经验进行调优。

四.理解业务模型

从生产数据统计，怎么转化到具体的场景中的业务模型。

1.生产数据统计

首先我们从生产环境取出数据，粒度到秒级，取出所有业务的交易量数据。

从这样的数据中取出业务量最高的一天，最大的业务量是 2000 万左右。

从图可看出9点和16点业务量大

2.业务模型计算过程

• 通用业务场景模型。
  就是将这一天的所有业务数加在一起，再将各业务整天的交易量加在一起，计算各业务量的比例。
  
  将上面的 0% 的业务全部删除，再计算一次百分比，得到测试场景中的业务比例。
  
  假如这个系统是 24 小时系统，所以我用 24 小时来计算。得到如下值：TPS1=24∗360020000000​=231也就是说通用场景中，TPS 不能低于 231。

• 9 点钟的业务模型
  
  从小时图中看到，9 点的业务量总和有 120 万左右。拿 120 万来计算。它的生产 TPS 就是：1,200,000 / 3600 = 333。这个模型下做场景时就不能低于 333TPS。

• 16点钟的业务模型
  
  从小时图中，我们可以看到，16 点的业务量总和有 100 万左右。为了方便，这里我拿 100 万来计算。它的生产 TPS 就是：TPS3=1,000,000/3600​=277显然，这个模型下做场景时就不能低于 277TPS。

有了这个计算过程，当我们把这些比例设计到场景中去的时候，一定要注意这些 TPS 的比例在运行过程中，不能发生大的变化。一旦压力发起后，由于各业务的响应时间随着压力的增加发生的变化量不同，就会导致运行过程中业务比例出现很大的偏差。通常，在 LoadRunner 里，会用pacing来控制 TPS，而用 JMeter 的，则会用Constant Throughput Timer来控制 TPS。

五.场景设计

以下场景设计需要说明两个前提条件：
1.这些业务都是实时的业务，不涉及批处理、大数据等业务。
2.不加系统资源的分析
首先，我们要列出自己要测试的业务比例、业务目标 TPS 和响应时间指标：响应时间指标是统一的，就是不大于 100ms。

在做项目的时候，经常会这样制定一个统一的响应时间指标，因为根本不知道如何定每个业务的时间。但是性能测试人员要知道业务不同，响应时间指标也应该不同，合理的做法是给出每个业务的响应时间指标。

1.基准性能场景

基准性能场景是为了测试出单业务的最大容量，以便在混合容量场景中判断哪个业务对整体容量最有影响。

• 业务1：场景执行时长17 分钟
  
  由上图可得出结论：
  1.场景是递增的。
  2.压力线程上升到 55（第四个阶梯）时，TPS 达到上限 680 左右，但是明显的，性能在第三个阶梯就已经接近上限了，
  3.在压力线程达到 55 时，响应时间达到 85ms 左右，这个值并不高。

• 业务2
  
  由上图可得出结论：
  1.这个单业务的最大 TPS 在 6000 以上。
  2.响应时间变化比较小，基本上都在 10ms 以下，但也能明显看出在线程增加的过程中，响应时间也是在增加的。
  3.这个业务由于 TPS 太高，响应时间太短，实在没啥可分析的。

• 业务3
  
  由上图可得出结论：
  1.最大 TPS 将近 5000。
  2.响应时间随着用户的增加而增加，在达到 4500TPS 时，响应时间在 6.5ms 左右。

• 业务4
  
  由上图可得出结论：
  1.最大 TPS 超过了 300。
  2.响应时间随着用户的增而增加，在达到 300TPS 时，响应时间在 70ms 左右。

• 业务5
  
  由上图可得出结论：
  1.最大 TPS 在 550 左右。
  2.响应时间随着用户的增而增加，在达到 550TPS 时，响应时间在 55ms 左右。

• 业务6
  
  由上图可得出结论：
  1.最大 TPS 超过了 2500。
  2.响应时间随着用户的增加而增加，在达到 2500TPS 时，响应时间在 16ms 左右。

• 总结
  
  最后结果我们看得出来6个业务的TPS都达到目标了，响应时间都小于100ms，业务 1 已经接近100ms指标了，也就是说这个业务如果在活动或促销期，有可能出现峰值最大 TPS 超过承受值的情况，超过了前面制定的响应时间指标。

2.容量性能场景

重点：场景不断。控制比例。
这里只说一个容量性能场景，并且这个场景是峰值业务场景。如果在你的项目中，有特定的业务日，那就要根据业务日的业务比例，重新做一个针对性的场景。
满足了最开始提到的业务比例之后，我们不断增加压力，得到如下结果：

从上面的结果可以看到，业务 4 和业务 5 的响应时间，随着业务的增加而增加，这显然在容量上会影响整体的性能。

注意：并不是说，看到了性能瓶颈就一定要解决，事实上，只要业务指标可控，不调优仍然可以上线。这一点也是很多做性能测试的人会纠结的地方，感觉看到这种有衰减趋势的，就一定要把它给调平了。其实这是没有必要的。我们做性能是为了让系统能支持业务，即使性能衰减已经出现，性能瓶颈也在了，只要线上业务没有超出容量场景的范围，那就仍然可以上线。

从上面的数据中看到，业务目标 TPS 已经达到，响应时间也没有超过指标。这个容量就完全满足业务需求了。如果业务要扩展的话，有两个业务将会先受到影响，那就是业务 4 和业务 5，因为它们的测试 TPS 和最大 TPS 最为接近。

3.稳定性性能场景

稳定性场景的时间长度取决于系统上线后的运维周期。
业务 + 运维部门联合给出了一个指标，那就是系统要稳定运行一周，支持 2000 万业务量。运维团队每周做全面系统的健康检查。
针对前面给出的容量结果，容量 TPS 能达到 3800（业务 1 到业务 6 的容量测试结果 TPS 总和）。所以稳定性场景时间应该是：20000000/3800 = 1.46 小时。

结论：业务 2 和业务 3 对总 TPS 的动荡产生了影响，但系统并没有报错。其他的业务都比较正常，也比较稳定，没有报错。总体业务量达到 27299712，也达到了稳定性业务量级的要求。

4.异常性能场景

异常性能场景要看架构图：

这里运行的场景是：用容量场景中最大 TPS 的 50% 来做异常的压力背景。

异常性能场景的目标是为了判断所要执行的操作对系统产生的影响，如果 TPS 不稳定，怎么能看出来异常点？当然是稳定无抖动的 TPS 是最容易做出异常动作产生的影响了。所以这里的 50% 是为了得到更为平稳的 TPS 曲线，以便做出正确的判断。

• 业务应用服务器。
  停下如下区域的一半应用服务器，查看 TPS、响应时间及其他服务器压力。
  kill 区域三：17:02；
  kill 区域一：17:15；
  kill 区域二：17:20；
  kill 区域五：17:25。

• 基础架构服务器。
  停下一半的基础架构主机，查看 TPS、响应时间及另外主机压力的恢复情况。
  kill 一台基础架构主机中的某个服务的某个节点：17:30。

• 数据库服务器。
  停下 master 数据库，查看切换时间，slave 的压力及 TPS 的恢复情况。
  reboot DB-20：17:36。6 分钟之后恢复；
  reboot DB-26：18:07。1 分钟左右恢复；
  reboot DB-2：18:20。2 分钟之后恢复。

• 启动 master 数据库。

• 启动被停的应用服务。
  start 区域五：18:28；
  start 区域三：18:33；
  start 区域一：18:38；
  start 区域二：18:43。

• 启动被停基础架构主机中的某个服务的某个节点。
  start 基础架构主机中的某个服务的某个节点：18:48。

• 测试结果
  TPS图：
  

1 ：17:02kill 区域三
2：17:15kill 区域一
3：17:20kill 区域二
4：17:25 kill 区域五
5： 17:30kill 一台基础架构主机中的某个服务的某个节点
6：17:36停下reboot DB-20。6 分钟之后恢复；
7：18:07停下 reboot DB-26。1 分钟左右恢复；
8： 18:20reboot DB-2。2 分钟之后恢复。
9：18:28start 区域五
10：18:33start 区域三
11：18:38start 区域一
12：18:43start 区域二
13：18:48start 基础架构主机中的某个服务的某个节点

从上图中的 TPS 趋势可以看出：
1.停掉一半的区域三应用服务器后，对 TPS 有明显的影响。
2.停掉基础架构服务器时，TPS 有下降，但很快恢复了，非常好。
3.停掉区域一、二、五的一半应用服务器，影响不大，TPS 有些许下降，但并没有报错，这个结果还可以接受。
4.理论上，用一半的压力，停了一半的服务器，即便当前正在运行在被停掉的服务器上的 session 受到了影响，那 TPS 也应该会恢复的，但是 TPS 没恢复。所以先这里提个 BUG。
细分TPS图：

从图上看，并不是所有的 TPS 都在步骤 1 的时候受到了影响。受影响的只有业务 2 和业务 3。显然只有业务 2 和业务 3 走到了这个区域。但是这仍然是一个 BUG！！！

六.监控设计

1.监控设计步骤

• 分析系统的架构
  在知道架构中使用的组件之后，再针对每个组件进行监控。
• 先全局，后定向定量分析
  监控要有层次，要有步骤。有些人喜欢一上来就把方法执行时间、SQL 执行时间给列出来，直接干到代码层，让人觉得触摸到了最顶级的技能。常不这么做，应该是先全局，后定向定量分析。
• 找到完整的证据链
  通过分析全局、定向、分层的监控数据做分析，再根据分析的结果决定下一步要收集什么信息，然后找到完整的证据链

2.监控技术图谱

3.全局监控

• OS 层（CentOS 为例）
  一般进到系统中，看的就是 CPU、I/O、内存、网络的使用率，这是很常规的计数器。
  
  针对 OS，我通常看上图中红色计数器的部分，这是 OS 查看的第一层。有第一层就有第二层，所以才需要定向的监控

• DB 层（MySQL 为例）
  

4.定向监控

• CPU 消耗得多
  
• OS 全局监控图中的 Network 中的 Total 总流量比较大时
  
• 查询和排序的报表有问题时
  
• 锁数据的时候
  

定向监控部分，不建议一开始就列，主要原因有三个：
1.耗费太多时间；列出来也可能半辈子也用不上；
2.照搬列出来的定向监控逻辑，有可能误导你对实时数据的判断。
所以最好的定向监控就是在实际的性能执行过程中，根据实际的场景画出来。这帮助我在工作中无往不利，理清了很多一开始根本想不到的问题。

5.监控工具

有了这些监控工具，基本上对每个组件的全局监控就解决了。

七.监控工具

1.JMeter+InfluxDB+Grafana ：TPS、响应时间、错误率

在这个结构中，JMeter 发送压力到服务器的同时，统计下 TPS、响应时间、线程数、错误率等信息。默认每 30 秒在控制台输出一次结果（在 jmeter.properties 中有一个参数 #summariser.interval=30 可以控制）。配置了 Backend Listener 之后，将统计出的结果异步发送到 InfluxDB 中。最后在 Grafana 中配置 InfluxDB 数据源和 JMeter 显示模板。

用 JMeter 的 Backend Listener 帮我们实时发送数据到 InfluxDB 或 Graphite 可以解决这样的问题。Graphite Backend Listener 的支持是在 JMeter 2.13 版本，InfluxdDB Backend Listener 的支持是在 JMeter 3.3 的版本，它们都是用异步的方式把数据发送出来，以便查看。

• JMeter 的 Backend Listener 配置 InfluxDB

JMeter 的 Backend Listener 配置 InfluxDB：先配置好 influxdb Url、application 等信息，application 这个配置可以看成是场景名。

• Grafana 中的配置
  首先，要配置一个 InfluxDB 数据源。在这里配置好 URL、Database、User、Password 之后，直接点击保存即可。
  
  然后添加一个 JMeter dashboard，我们常用的 dashboard 是 Grafana 官方 ID 为 5496 的模板。导入进来后，选择好对应的数据源。
  

2.node_exporter+Prometheus+Grafana：操作系统资源

我们要监控的是这几大模块：CPU、I/O、Memory、Network、System、Swap。

（1）监控命令

监控的思考逻辑：正是因为你要监控 CPU 的某个计数器才执行了这个命令，而不是因为自己知道这个命令才去执行。

（2）监控工具

• 官网下载node_exporter
  

# 启动命令
[root@7dgroup2 node_exporter-0.18.1.linux-amd64]#./node_exporter --web.listen-address=:9200 &

• 配置 Prometheus

# 下载命令，然后解压
[root@7dgroup2 data]# wget -c https://github.com/prometheus/prometheus/releases/download/v2.14.0/prometheus-2.14.0.linux-amd64.tar.gz

# 先配置prometheus.yml，再启动，启动命令
[root@7dgroup2 data]# ./prometheus --config.file=prometheus.yml &

在prometheus.yml中添加如下配置：

 - job_name: 's1'
    static_configs:
    - targets: ['172.17.211.143:9200']

• 配置 Grafana：
  
  再配置一个 node_exporter 的模板，比如我这里选择了官方模板（ID：11074）
  

八.性能测试分析思路

1.性能测试分析的能力阶梯视图

能力进步阶梯：压力工具的使用——清晰数值代表的含义——数值分析，趋势分析，现象分析，证据链分析——调优
1.工具操作：包括压力工具、监控工具、剖析工具、调试工具。
2.数值理解：包括上面工具中所有输出的数据。
3.趋势分析、相关性分析、证据链分析：就是理解了工具产生的数值之后，还要把它们的逻辑关系想明白。这才是性能测试分析中最重要的一环。
4.最后才是调优：有了第 3 步之后，调优的方案策略就有很多种了，具体选择取决于调优成本和产生的效果。

2.性能分析思路

（1）瓶颈的精准判断：通过TPS曲线准确的判断瓶颈点

• TPS 曲线可以明确：
  1.有没有瓶颈：其实准确说所有的系统都有性能瓶颈，只看我们在哪个量级在做性能测试了。
  2.瓶颈和压力有没有关系：TPS 随着压力的变化而变化，那就是有关系。不管压力增不增加，TPS 都会出现曲线趋势问题，那就是无关。

注意：TPS曲线不能找到清晰的拐点，大部分系统其实是没有明确的拐点的，所以我们不能使用拐点来判断。

响应时间图：

线程图：

TPS曲线图：

由上图可得：到第 40 个线程时，TPS 基本上达到上限，为 2500 左右。响应时间随着线程数的增加而增加了，系统的瓶颈显而易见地出现了。（其实我们只看TPS曲线图就能得出系统有瓶颈，并且和压力有关）

• 问题：为什么不需要响应时间曲线来判断呢？
  响应时间是用来判断业务有多快的，而 TPS 才是用来判断容量有多大的。

（2）线程递增的策略：连续，有梯度

• 线程递增的策略不同，产生的响应时间完全不同
  场景1线程是一次性加到500，场景2是递增。
  
  在场景的执行过程中，首先，响应时间应该是从低到高的，而在场景 1 中不是这样。其次，线程应该是递增的，而场景 1 并没有这样做。
  其实在生产环境中，像场景 1 这样的情形是不会出现的。如果它出现了，那就是你作为性能测试的责任，因为你没有给出生产环境中应该如何控制流量的参数配置说明。
• TPS曲线出现了抖动
  场景2的TPS曲线：
  
  在每个阶梯递增的过程中，出现了抖动，这就明显是系统设置的不合理导致的。设置不合理，有两种可能性：1. 资源的动态分配不合理，像后端线程池、内存、缓存等等；2. 数据没有预热。

注意：秒杀场景，有人觉得用大线程并发是合理的，其实这属于认识上的错误。因为即使线程数增加得再多，对已经达到 TPS 上限的系统来说，除了会增加响应时间之外，并无其他作用。所以我们描述系统的容量是用系统当前能处理的业务量（TPS 、RPS、HPS ，它们都是用来描述服务端的处理能力的），而不是压力工具中的线程数。

• 线程递增策略
  线程图：
  
  场景中的线程递增一定是连续的，并且在递增的过程中也是有梯度的。场景中的线程递增一定要和 TPS 的递增有比例关系，而不是突然达到最上限。上面两点针对的是常规的性能场景。对于秒杀类的场景，我们前期一定是做好了系统预热的工作的，在预热之后，线程突增产生的压力，也是在可处理范围的。这时，我们可以设计线程突增的场景来看系统瞬间的处理能力。如果不能模拟出秒杀的陡增，就是不合理的场景。
• 性能场景递增的经验值
  
  并不是所有系统都适合这个递增幅度，还是要根据实际的测试过程来做相应的判断。

（3）性能衰减的过程：有判断性能衰减的能力

通过红线的大致比对可以知道，当每线程每秒的请求数降到 55 左右的时候，TPS 就达到上限了，大概在 5000 左右，再接着往上增加线程已经没有用了，响应时间开始往上增加了。

只要每线程每秒的 TPS 开始变少，就意味着性能瓶颈已经出现了。但是瓶颈出现之后，并不是说服务器的处理能力（这里我们用 TPS 来描述）会下降，应该说 TPS 仍然会上升，在性能不断衰减的过程中，TPS 就会达到上限。

是不是应该在性能衰减到最大 TPS 时就停止场景呢？
不一定。因为停不停场景，取决于场景目标，如果只是为了得到最大 TPS，那确实可以停止场景了。但是，如果要扩大化性能瓶颈，也就是说为了让瓶颈更为明显，就完全不需要停止场景，只要不报错，就接着往上压，一直压到响应时间变长，需要拆分。

（4）响应时间的拆分：找到问题出现在什么地方

在性能场景中，不管是什么原因，只要系统达到了瓶颈，再接着增加压力，肯定会导致响应时间的上升，直到超时为止。在判断了瓶颈之后，我们需要找到问题出现在什么地方。在压力工具上看到的响应时间，都是经过了后端的每一个系统的。那么，当响应时间变长，我们就要知道，它在哪个阶段时间变长了。
拆分的前提需要熟悉系统的架构，拆分的目的是要知道每个环节消耗的时间，拆分的方法可以通过日志，可以通过监控工具，也可以通过抓包。

• 系统架构：Nginx+TOmcat+Mysql
  
  通过日志查看 Nginx 上的时间：请求时间的 28ms，后端响应时间的 28ms
  通过日志查看Tomcat 上的时间：请求时间消耗了 28ms，响应时间消耗了 27ms
  前端时间消耗：
  
  Waiting for server response（TTFB）：从发出请求到接收到第一个字节，即 TTFB 是 346.78ms
  Content Download：内容下载用了 28.96ms

Tomcat 上基本上是消耗了处理的所有时间，当然这中间也包括了 MySQL 花费的时间。而前端看到的其他时间就消耗在了网络中。

那么网络上的消耗时间怎么样呢？很多人用 TTFB 来描述网络的时间，TTFB 包括了后端一系列处理和网络传输的时间，用 TTFB 描述网络的健康状态并不合理。如果用 Content Download 来描述会更为合理。

• 系统架构：多系统关联
  
  想知道每个系统消耗了多长时间，那么我们就需要链路监控工具来拆分时间，从 User 开始，每个服务之间的调用时间，都需要看看时间消耗的监控。
  

（5）构建分析决策树：解决办法

分析决策树是对架构的梳理，是对系统的梳理，是对问题的梳理，是对查找证据链过程的梳理，是对分析思路的梳理。它起的是纵观全局，高屋建瓴的指导作用。
知道时间消耗在了哪个节点上，就要找到根本的原因才可以。分析决策图：

从压力工具中，只需要知道 TPS、响应时间和错误率三条曲线，就可以明确判断瓶颈是否存在。
再通过分段分层策略，结合监控平台、日志平台，或者其他的实时分析平台，知道架构中的哪个环节有问题，然后再根据更细化的架构图一一拆解下去。

• 数据库分析决策树：有非常多的相互依赖关系
  

a.MySQL 中的索引统计信息有配置值，有状态值。我们要根据具体的结果来判断是否需要增加 key_buffer_size 值的大小。

Buffer used 3.00k of 8.00M %Used: 0.0004

从上面的数据可以看到，key buffer size 就用到了 4%，显然不用增加。
b.状态值达到配置值

       __Tables_______________________
    Open             2000 of 2000    %Cache: 100.00
    Opened         15.99M     4.1/s

    Slow 2 s        6.21M     1.6/s

配置值为 2000 的 Open Table Cache，已经被占满了。显然这里需要分析。再看Slow的，应该先去处理慢 SQL 的问题。
注意：看到状态值达到配置值并不意味着我们需要赶紧加大配置值，而是要分析是否合理，再做相应的处理。

• 操作系统分析决策树
  

（6）场景的比对：确定哪个环节出现性能瓶颈

当我们不知道系统中哪个环节存在性能瓶颈时，对架构并不复杂的系统来说，可以使用这样的手段，来做替换法，以快速定位问题。
系统架构如下：

从 TPS 曲线中，我们可以明显看到系统是有瓶颈的，但是并不知道在哪里。
a.增加一台server A


曲线图差不多
b.增加JMeter 机器


TPS明显增加

九.性能测试案例

1.项目背景

2.实施规划

（1）需求分析

• 新版本上线前
  一般直接在生产环境上进行性能测试，进行压力测试，配置测试。
  测试目标：验证系统在饱和负荷下的业务处理能力；发现系统瓶颈并通过相关参数调优，提高整体系统处理能力。

• 新需求版本上线前
  一般在测试环境进行性能测试，进行基准测试。
  测试目标：测试整体系统修改前后监控指标的变化；测试新需求是否达到预定的性能指标。

• 页面测试
  侧重于测试关键业务的整体性能，例如登录，开户，变更等常用业务模块。
  在页面上录制登录，业务操作，受理提交，退出系统的全流程，然后添加验证点，处理关联信息，精简脚本。

• 接口测试
  侧重抽取底层，业务量大，响应时间要求高的业务模块测试，比如查询，业务开通类接口。
  检查环境，检验报文，准备测试数据。

（2）测试方案

1.测试目标：新需求是否满足设计预期，改造需求是否有性能下降。

场景类型	业务模块	接口编号	场景描述	性能指标
接口	指标查询	43543	尝试不同并发下的接口调用，在TPS达到指标要求时，验证响应时间是否达标	TPS>=6;平均响应时间<=3000ms
页面	群组套餐变更	无	尝试不同并发下测试新旧版本，在TPS达到指标要求时，检验响应时间是否下降>=5%	新版本较旧版本的响应时间是否下降>=5%

2.测试环境：环境性能差异，中间件的参数配置都需要记录。硬件基本信息，中间件参数配置，数据库。
3.测试场景：初步确定一个业务的并发场景，比如5并发，10并发，20并发。

序号	业务名称	业务指标	性能指标
1	套餐变更	TPS>=6,平均响应时间<3000ms	CPU <=85%,内存空闲率为80%，磁盘I/O没有出现分页现象
2	添加成员	TPS>=12,平均响应时间<3000ms	CPU <=85%,内存空闲率为80%，磁盘I/O没有出现分页现象

4.测试数据
5.职责分工
6.测试环境准备
7.测试工具

软件名称	说明
Load Runner	性能测试工具
soapUI	接口功能调试工具
HttpWatch	页面连接加载测试工具
Nmon	主机资源监控工具

3.性能测试执行

1.录制脚本，录制接口
2.测试策略
3.监控

4.结果分析