一 核心业务功能的TPS测试

1.1 登录接口测试用例

1.2 进入首页接口测试用例

10个用户并发的响应时间为4s，吞吐量为TPS 2.3
30个用户并发的响应时间为12s，吞吐量为TPS 2.4
说明服务器进入首页操作的TPS最高只有2.4， 无法达到100TPS要求，存在性能问题

1.3 添加购物车接口测试用例

当并发数为10时，响应时间为138ms，吞吐量TPS为15.7
当并发数为30时，响应时间为592ms，吞吐量TPS为15.1
说明系统最大的吞吐量TPS只能达到15.7左右，无法满足性能要求

1.4 结算和下订单接口测试用例

模拟10个用户并发时，结算和提交订单的请求的TPS都达到11，满足需求要求的10，同时响应时间小于需求要求的3秒，因此结算和下订单的接口满足性能要求

1.5 系统资源使用率

在第一次模拟5个用户并发时，无论TPS和响应时间能否满足要求，如果系统资源使用率超过要求，都必须提出问题并优化，优化后再进行后续性能测试（模拟10，20，30用户）

1.6 单接口测试中一个测试的各个成员接口要单独做性能统计

二 业务流程（多接口组合）的压测

1. 通常是在所有的单接口性能指标都达到性能要求时，再进行业务流程的测试;
2. 根据业务流程的脚本需要，提前准备好测试数据（用户、商品、地址）和修改脚本（多用户登录购买商品）；
3. 按照用例的要求分别模拟5/10/30/50/100用户并发请求，监控性能指标并分析结果

三 稳定性测试

3.1 稳定性测试分析

1. 模拟正常业务负载（用户实际使用时系统的业务负载/模型），进行长时间的性能稳定性测试；
2. 实际的业务模型获取方法：通过运营数据的统计来收集和分析；
3. 业务负载是来自运营数据统计或来自之前压测得到的最优负载；

例如：模拟200个用户，通过运营数据统计，发现200用户在不同业务操作的分布如下：

稳定性测试时，就需要针对不同的业务操作，分别模拟不同的用户数，进行长时间的稳定性测试（所有脚本并行执行）

3.2 稳定性测试中每个业务要作为一个整体事务来统计性能

1. 添加事务控制器
   
2. 勾选事务控制器的选项 Generate parent sample

3. 将线程组中该业务的所有接口请求都拉入这个事务控制器

3.3 稳定性测试执行

1. 需要在JMeter中针对不同的线程组，按照之前分析的虚拟用户数的值进行配置；
2. 注意所有的线程组是否有前后依赖关系，稳定性测试时所有脚本并行执行，有依赖关系的脚本不能执行；
3. 对有多个请求的线程组，如果想作为一个事务来统计，需要添加事务控制器，并将所有请求放入事务控制器中；