假设一个内部系统要求响应时间在 3s 以内，支持最大用户数为4万。根据二八原则，80%用户在20%时间使用系统，(4w80%)/(24h20%)≈1.9点击/秒。并发数=TPS（运行时间+思考时间）=1.9（3+0.5+0.3+3+0.5+0.3+0.5+3）=21。
注意：二八原则计算的结果并非是并发数，而是系统要达到的处理能力（吞吐量），初学者容易被误导，拿着这个数据就去设置并发数，这是错误的哦。 如果你的系统性能要求更高，也可以选择一九原则或更严格的算法，二八原则比较通用，一般系统性能比较接近这个算法而已，大家应该活用。
基于以上，如果我们通过测试得到的最大吞吐量大于计算出来的吞吐量（TPS≈1.9），且各项性能指标均达标，那么系统就是安全的。如果用户发帖遵循正态分布，那么并发请求数峰值还肯定会大于上述估算的吞吐量（并发数大于吞吐量？？？）。
一、场景设计
场景编号：001 - 基准测试
目的：验证测试环境、验证脚本，得到系统的性能基准，为后续测试提供参考。
| 涉及业务 | 业务占比 | 运行时间 | 并发数 |
|---|---|---|---|
| 浏览任务 | 20% | 5分钟 | 1 |
| 登录 | 20% | 1 | |
| 新建任务 | 20% | 1 | |
| 配置任务 | 20% | 1 | |
| 删除任务 | 20% | 1 |
场景编号：002 - 配置测试
目的：优化配置，测试当前软、硬件配置是否能够满足性能指标。
| 涉及业务 | 业务占比 | 运行时间 | 并发数 |
|---|---|---|---|
| 浏览任务 | 38% | NA | 8 |
| 登录 | 28% | 6 | |
| 新建任务 | 19% | 4 | |
| 配置任务 | 10% | 2 | |
| 删除任务 | 5% | 1 |
场景编号：003 - 负载测试
目的：分析性能变化趋势，找出性能瓶颈与风险，对系统进行定容定量。
| 涉及业务 | 业务占比 | 运行时间 | 并发数 |
|---|---|---|---|
| 浏览任务 | 38% | NA | 8/16/24 |
| 登录 | 28% | 6/12/18 | |
| 新建任务 | 19% | 4/8/12 | |
| 配置任务 | 10% | 2/4/6 | |
| 删除任务 | 5% | 1/2/3 |
场景编号：004 - 稳定性测试
目的：长时间（>8小时）运行大量负载，确定系统软硬件环境是否运行稳定。
| 涉及业务 | 业务占比 | 运行时间 | 并发数 |
|---|---|---|---|
| 浏览任务 | 38% | >12小时 | 42 |
| 登录 | 28% | ||
| 新建任务 | 19% | ||
| 配置任务 | 10% | ||
| 删除任务 | 5% |
二、场景实现
单线程组实现测试场景
假设业务比例为 “查看详情(8)：登录(6)：新建任务(4)：(配置任务)2：(删除任务)1”。差不多每3个登录会有4个查看任务，新建2个任务，配置1个任务；每6个登录，删除1个任务。我们使用 If逻辑控制器 + ${__counter(arg1, arg2)}函数来实现。
- 新建任务的If控制器条件：登录(3)/新建(2)
${__counter(true,i)}%2==1||${__counter(true,i)}%3==0 - 配置任务的If控制器条件：登录(3)/配置(1)
${__counter(true,i)}%3==0 - 删除任务的If控制器条件：登录(6)/删除(1)
${__counter(true,i)}%6==0 - 查看任务：因为配置和删除操作包含查看的业务，所以单独的登录/查看比为6：(8-2-1)，即6:5。
${__counter(true,i)}%5!=0||${__counter(true,i)}%6==0
多线程组实现测试场景
多线程组的场景设计需要注意的是业务关联关系。比如查看任务可以不需要登录的；新建、配置、删除任务都需要登录且并发数的和大于登录，说明有些场景是登录后执行了多业务的；查看详情的并发数小于登录，所以有部分用户可能是登陆后只查看了详情。按照 “查看详情(8)：登录(6)：新建任务(4)：(配置任务)2：(删除任务)1” 的比例，以及用户实际使用场景来算，得到如下场景：
- 登录(2)-新建任务(2)
- 登录(2)-新建任务(2)-配置任务(2)-查看详情(2)
- 登录(1)-查看详情(1)-删除任务(1)
- 登录(1)-查看详情(1)
- 查看详情(4)
两种脚本实现方式的对比
| 对比 | 单线程组 | 多线程组 |
|---|---|---|
| 优势 | 参数化容易，保证运行的线程间的参数的唯一性。 | 线程组间互不干扰，简单明了，易于维护。 |
| 劣势 | 脚本顺序执行，相互之间有影响；脚本复杂度高。 | 多个线程组相当于多个不同的脚本，需要分开参数化，保证每个线程取到参数的唯一性。 |
三、测试执行
场景编号：001 - 基准测试
基准测试采用单用户、单业务场景的执行方式。测试时间尽可能长，尽量执行多次（通常建议3次以上），取相对稳定的结果，目的是统计响应时间的取样更多，测试结果越准确。对于发现的异常，如果不熟悉就请开发团队告诉你有哪些作业任务，这些作业任务的频度是否适中。
结论：满足性能需求3s以内，事务正确率100%，且CPU、内存、磁盘表现正常（局域网不考虑网络影响）。测试环境检查通过，脚本检查通过，可以考虑对系统进一步的测试。
场景编号：002 - 配置测试
先确定配置测试的目标：
（1）JVM配置
（2）Tomcat线程池配置
（3）数据库连接池配置
（4）数据库的一些配置
配置测试场景一般为混合场景（多个业务同时执行）。
（1）JVM Heap大小及不同代的大小指定？？？Heap回收算法的选择？？？（P316）
（2）Tomcat线程数配置？？？
（3）数据库缓存、临时表空间，大表水平切分，主从结构、读写分离、主从备份、主主备份等？？？。
结论：随着并发数的增加，响应时间也逐渐增加，但仍然满足3s以内的性能指标；事务正确率100%；查看详情、登录、新建任务、配置任务、删除任务各业务之比接近6:8:4:2:1；TPS未出现明显拐点；CPU、内存、磁盘均正常。性能表现能够满足需求，系统性能瓶颈风险在CPU。
场景编号：003 - 负载测试
负载测试在满足系统性能指标的基础上进行测试，寻找性能的拐点。负载测试分为单场景与混合场景。单场景有利于分析性能问题，因为排除了其他业务干扰；混合场景更贴近用户实际使用习惯，是一个综合的性能评估。建议先做单场景测试，再做混合场景测试。
我们一般采用二分法，如总的线程数递增为21/42/84，当发现线程增大后性能降低，再对该区间进行二分尝试，最后对拐点附近精细尝试得到最大吞吐量。
结论：执行过程中，CPU首先出现性能瓶颈，利用率接近100%。响应时间开始大于3s，TPS降低，出现失败的事务。此时的内存、磁盘、网络均表现正常。此时应优先解决CPU的瓶颈问题，再反复进行负载测试，直到在没有硬件瓶颈的条件下找到系统的性能拐点。
场景编号：004 - 稳定性测试
稳定性测试在正常性能阀值下尽量加大负载。什么是阀值呢？比如响应时间要求3s以内，3秒就是阀值；比如CPU利用率70%以下，70%就是阀值。假设满足性能要求的负载是B，那么稳定性测试时负载一般是1.5B~2B。
在此案例中我们满足性能需求的并发量是21，那么在做稳定性测试时，并发量应该是1.521~221即32~42之间。运行时间原则上越长越好，惯例要求不低于8小时。有些隐藏较深的诸如内存溢出的问题是需要长时间运行才能反映出来的。如果各项性能指标都在阀值内，且性能表现平稳，则可以认为通过稳定性测试。
除了分析响应时间、TPS和服务器硬件性能外，我们也要关注JVM内存回收情况，MySQL有无慢查询等。
