测试策略其实是解决压什么，怎么压的问题
如上图所示，压测无非就是模拟客户端对客户端并发请求，查看服务端的响应情况如何，很明显，对于java后台接口，压的就是接口
接口初步可分为两种类型，一种是单个接口，一种是接口组合
那什么时候压测单个接口，什么时候压测接口组合呢？
单个接口
- 调试单个接口的性能瓶颈
- 上下游的接口，可知道上游最大请求下游该接口的并发数
- 针对系统请求量较大的接口的并发数
接口组合
接口组合有两种方式，一种是依据故事场景的方式，一种是按照线上或者估算的接口请求数占比组合方式
- 可以测试整个系统处理故事场景的tps
- 测试系统支持主要核型接口的tps
解决了压什么，接下来看看怎么压的问题
个人理解大致可以分为两种方式，集合点和持续并发
集合点
集合点可以简单得理解为一种控制虚拟用户行为的机制，该机制可以达到在一定时间范围内将一定数量的虚拟用户阻挡在一个操作行为点前的位置进行互相等待，在条件（达到虚拟用户数量或超时）到达后唤醒全部等待中的虚拟用户，从而达到使得一定数量的虚拟用户可以同时进入下一个操作行为点的目的。
往往其使用初衷是为了实现最大意义上的并发来考察系统应对此种极端情况的表现
但是，集合点真的就给服务端增大压力么？
单独业务点上虽然看似集合后压力增大了，但是这个要分析具体情况，首先，在释放阻塞之前，用户会处于互相等待的状态中，对服务端的压力逐渐减小，服务端的压力得到明显缓解
持续并发
持续循环执行脚本，给服务端持续造成压力，这样可以测试出服务端的性能情况和在长时间的压力下是否可以持续稳定的运行