聊到并发测试，在百度上搜搜，大部分返回的是JMeter、LoadRunner等关键字，大概大部分的新手入门都是从用这些工具开始的，那么我们先从工具讲起吧。
器
常见的模拟并发的工具，可以按照支持的协议类型简单分下类：
1）应用层协议：
这是目前场景最多的，互联网的朋友们几乎都是用这块，如jmeter、LoadRunner、postman、soupui…
LoadRunner是一款商业软件，本身的功能比较全，支持比较好的图形化交互，场景设计，各种并发控制，常见的协议如http、https等都支持的很好，实用的功能也很多，如ip欺骗、流量录制就是很优秀的功能，扩展性上也很好，支持自定义dll扩展；
JMeter是一款开源软件，特点是轻量级、开源（自己可以针对业务做一些定制化开发）。
2）网络层协议：
在通信大厂干过的同学应该有感受，对城域网入口级别的路由器、交换机、防火墙等设备，需要模拟的并发、压力流量是非常大的，这时如果要用JMeter、LoadRunner就需要较多的二次开发，而且需要有分布式压力机设计，这时就可以用专业的测试仪，如ixia，可以模拟大规模流量并发。
那么怎么选择工具呢，先给个答案：最适合自己业务的工具，才是最好的工具？
有个朋友，平时只选贵的，不选对的，平时吃个快餐都要强行加个鸡腿。而我们在选择工具时，不是一定贵的商业工具就是最好，而是要适合自己的业务，如果多看看几家公司，你会发现小创业团队一般会用LoadRunner，因为上手快，功能全，而且能用盗版，而大型公司用商业软件一定是有不得不用的理由，如上面说的城域级别的通信设备测试；在阿里大部分团队会选择基于JMeter做二次开发，因为业务会有一些特性，支持的协议的多种多样，不只是简单的http、https就够了，这时JMeter这种工具就很好用了，有并发的框架，工具团队再针对业务的特点去开发对应的支持协议、丰富支持的编程语言、扩展点等等，再换个名字就变成了内部一个很好用的工具。
术
如果对比测试过程和开发过程，开发要经历需求-系统分析-开发-上线的过程，做并发测试也要经过1）测试需求 – 2）测试分析 – 3）并发脚本开发 – 4）执行并发测试分析结果 的过程。那么选对了工具其实解决的是步骤3、4的问题，而最关键的其实测试分析，或者说是如何设计场景的问题。以下简单的讲一下完整的过程：
1）拿到业务的容量模型：
拿一个具体场景展开下吧，比如某月某日需要做一次大规模线上营销活动，我们需要提前验证我们的系统容量，并让上下游所有系统都整体做好机器准备和预案：首先会有大的业务目标，如今年会有多少营销活动、多少商家、用户参与，根据这个数据大致评估出技术侧的目标，如达到交易量10w/s、支付量5w/s；再把这个大的技术指标分拆到各个系统级别的指标，这里就需要一些具体的业务分析，如a接口、b接口、c接口分别占比多少，不同的接口之间的调用顺序，前后依赖，再分解到底层中间件和资源，如应用服务器的容量多少，DB的容量多少，分布式缓存的容量多少等等。
2）设计业务场景
基于上面得到的业务模型，再来设计具体测试场景，这里的场景需要考虑到如何混合流量、发起流量的前后顺序、控制并发时间、分析的时间点、结果曲线等等，如常见的测试方案可以简单分类下：a）性能测试：在日常需求下采集性能基线；b）负载测试：压力变化下的系统性能变化；c）极限测试：找系统的性能拐点；d）稳定性测试：长时间运行下的性能是否稳定；e）容量测试：为达到指定容量需要多少机器。
还是以上面的例子继续做，这里就需要设计各种混合流量场景，描述清楚哪些场景需要长时间运行，重点的关注点，分析点在哪，重点关注的指标是哪些。
3）性能调优
如果只是简单的拿到并发压测后的性能结果，这一步就没了，但其实这一步才是最能体现深度的，当我们按照上一步的场景做了测试后，可能会发现系统的表现远远未达到，CPU占用超高、内存经常爆掉、DB超时…那么这个时候需要去看是什么问题引入的，Dump下出问题时候的内存，对应的看看代码。是否系统本身问题，如并发设计不够好、代码缺陷，或者是应用、容器、JVM的参数可以调整下，如数据库连接数、JVM堆栈设置等等，或者就是资源不够，需要定位到具体的性能瓶颈是什么，是该加机器还是加DB还是加什么。调整后再发起并发流量，再次去看是否达到了预期调优的效果。
道
并发测试的本质是什么：通过扩大/调整业务量来找到系统的稳定性问题？并发只是找到稳定性问题的一个方法，但不是唯一的方法，如果从目标出发，我们就是要找到稳定性问题，那么可以做的不仅仅是上面并发测试的需求-分析-工具执行-分析的这些事情。
首先，所有的软件问题都是架构问题。一个业务量只有1tps的系统和业务，和一个业务量1000tps，和业务量10w的系统，架构是不一样的，所面对的稳定性问题也是不一样的，1tps的系统大概搞个开源的spring-boot，搭建一个mvc框架，简单搞搞就能上了，而上w tos的系统，各种异步化、水平/垂直拆分、CAP的设计和取舍、单元化部署、异地容灾… 那么对应的稳定性问题会有哪些，基本可以提前分析出来一大部分。
明白了这些地方，这件事情可以流程、与业务形态结合来看。如基于日常流量录制，分单机、集群、同城做容量模型的自动构建，定期自动化的基于变更去做容量回归；对一些大型活动做容量预测；基于影子数据隔离的全链路线上压测；定期自动化的容灾演练；高度模拟生产环境的仿真环境…
