分享一篇老文章，略作修改。
前几天星球里有同学在问性能测试工具JMeter吞吐量控制器的使用问题，对这个问题深挖之后，发现他的疑惑其实是因为流量模型和数据模型没有参考，想着用工具来解决。
从我的实践经验来说，如果无法对系统和业务有足够的了解，没有较为精准的性能测试三大模型，则性能测试的结果无法对线上容量规划起到明显的参考价值。
今天这篇文章算是性能测试知识的科普内容，我会聊聊在实际工作中开展性能测试，前期最核心的工作。即业务模型、流量模型和数据模型这三大模型，该如何评估和建立。
在性能测试工作中，业务模型、流量模型和数据模型是至关重要且必须在项目中构建的，否则很可能导致测试的场景和实际差距很大，测试结果也无法为性能分析和优化提供足够有说服力的支撑。为了便于大家理解三大模型，我会以电商业务下单的场景来举例说明，如下图：
业务模型
大家可以将业务模型看作功能测试中的业务场景。在性能测试中要构建业务模型，我们要考虑如下几个因素：
商品库存是否足够；
下单的商品是否可参与营销活动；
下单的用户是否是vip会员，有会员折扣；
下单的用户是否有优惠券，该优惠券是否满足本订单的优惠条件；
............
其实业务模型和功能测试时候的业务场景分析没什么区别，都是为了针对被测业务和服务进行分析，确保测试的场景和需求是一致的。如果是更复杂的业务和更大范围的测试需求，可能还要考虑线上业务的流量入口、风控等因素。
当然在实际的工作或项目中，建议通过分析需求，梳理出压测涉及到的业务和场景，绘制成一个业务模型思维导图，这样便于后续的工作开展。
业务模型思维导图可以用树状图也可以用类似上图的样子，便于理解即可。
流量模型
单机单接口基准测试
单机混合链路容量测试
生产环境全链路压测场景
梯度加压：为了探测集群模式下系统的最大吞吐量（避免压垮服务，造成事故）； 固定并发：验证系统长期处于负载下的稳定性； 脉冲并发：探测系统的健壮性、验证限流熔断等服务保护措施的正确性&可用性； 超卖验证：对电商业务来说，主要针对一些限时抢购&秒杀的场景（一般这种场景，会涉及到分布式锁、缓存、数据一致性等技术点；玩不好的话，容易造成客诉、资损、甚至服务异常宕机！）；
构建流量模型
假设日常支付订单量为50W，支付转化率为40%，订单支付QPS峰值为200。预估大促时的支付转化率为60%，则可得：大促峰值订单支付QPS为（200/40%）*60%*（200W/50W）=1200QPS。为了留有一定冗余空间，上浮30%，即订单支付的QPS预估为1500； 电商的导购下单支付链路为：首页→商品详情→创建订单→订单支付→支付成功，这是类似漏斗的一个转化逻辑。假设首页→商品详情转化率为40%，商品详情→创建订单转化率为40%，创建订单→订单支付转化率为40%，那么可得：创建订单QPS为1500/40%=3750，商品详情QPS为3750/40%=9375，首页QPS为9375/40%=23437； 按照核心链路之间的依赖调用关系，借助trace追踪，可得到大促期间所有核心应用及核心链路的QPS数值。
数据模型
基础数据
热点数据
是否有热点数据相关的操作：比如说所有用户秒杀同一件商品； 不同类型数据处理逻辑有差异时，需通过测试数据多样化提高性能测试代码覆盖率；
缓存数据
构建数据模型
构建业务模型； 构建流量模型(压测模型)； 罗列出业务和流量模型所需要的测试数据以及对应关系； 将准备好的参数化数据从数据库取出来生成对应的不同的参数化数据文件； 在压测脚本中设置对应的数据匹配关系，保证业务模型、流量模型和数据模型匹配，模拟生产真实场景。
本周最后一个工作日，吆喝一下我的知识星球，目前第三季，新朋友现在加入享受早鸟价399元，可永久阅读前面的所有内容，名额有限，下个月恢复原价。
知识星球主要提供简历优化、面试辅导、职场发展规划等1V1咨询服务。目前已累计200+“学员案例”，开展了30+“职来职往”和30+“技术案例私享”，还有技术案例roadmap和大厂面试案例。
十五大专业模块，超过80万字的内容交付。欢迎扫码加入。
