---

前言

1、项目性能需求分析案例

1）本次性能测试的目的是什么？

是验证新服务的最大性能表现、安全容量，还是验证该新服务对应的技术架构性能和稳定性表现？

如果是验证最大性能表现和安全容量，那需要挑选出该服务的核心业务场景，并按照预估的线上流量和业务量制定流量模型，准备测试数据，然后再执行压测。

如果仅是验证该新服务技术架构(特指MySQL分库分表)的性能和稳定性表现，则创建SQL语句直接压测数据库即可。

目的不同，则具体的实施方案和准备事项不同。

2）如何设计该性能需求的三大模型？

设计出正确合理的性能测试三大模型，是性能测试能否正确开展的核心工作。

业务模型：订单业务的核心一般有创建订单、订单支付、订单列表、订单详情，这些都是正向业务流程，按照经验来说会占到订单服务大概90%以上的流量。压测时一般仅需要验证这几个核心场景的性能表现即可。

流量模型：找到核心业务场景后，按照这几个业务场景的预估请求量占比(比如预计日均1W单，其中创建订单5K、订单支付3K、订单列表和订单详情各1K)来制定流量模型。

流量模型的制定并不是拍脑袋制定的，一方面需要和业务方多沟通，另一方面还要考虑到技术实现的内部调用关系和调用次数，以及强弱依赖。如果有线上监控或线上已有服务(老订单服务)数据作为参考，则更好。

在制定流量模型时，还需要注意一点：流量模型的制定可以参考业务转化漏斗。

数据模型：有了业务模型和流量模型，数据模型的制定则比较简单。比如创建订单峰值QPS毛估200，单次压测执行10分钟，则创建订单接口所需的测试数据，最少需2001060=120000条数据。

以此类推，准备好核心业务场景对应的API中，请求入参需要参数化的数据，然后执行压测即可。

3）独立的性能测试环境是性能测试能否正确实施的基础。

很多同学觉得性能测试不就是找个环境部署好服务，然后直接用工具模拟高并发嘛，很简单，其实不然。

独立的性能测试环境很重要，主要体现在如下几个方面：

提前进行性能验证，发现并修复问题；
独立的性能测试环境可以避免其他测试动作的影响；
提前进行各种手段的性能测试，降低线上出现问题的修复成本；
至于是否有那个时间和成本预算搭建独立性能测试环境，因地制宜，是具体情况而定。

在成本和需求都满足的情况下，搭建独立性能测试环境可以参考如下几点建议：

和生产等比最小化，即1个服务1台机器；
如果是云服务，尽量部署在不同可用区；
机器配置类型和生产保持一致(cpu类型/几核几G)；
如果是云服务，选择按量收费，而不是包年(降低成本)；
非核心服务(调用量不大/重要性低)，可以多个服务部署同一个机器；
数据量缩小，数据库隔离降配(8C64G的数据库实例足够满足日常压测所需)；
该有的链路追踪/基础监控/应用监控等技术设施必须部署，便于问题定位排查；

2、确定项目性能测试指标

如何确定性能指标？

从我的角度来看，性能指标是一个相对概念，如果没有参考或者技术目标，那性能测试活动开展是很难拿到好结果的。

就像打靶射箭一样，在子弹出膛之前，需要知道子弹射向哪里，然后根据距离、风向等因素调整射击角度。性能技术指标就是那个靶子，告诉我们目标是什么。

同样，性能技术指标是一个滞后的参考值，它只有在有测试结果之后才能发挥真正的作用。

至于性能测试的结果和性能指标之间的关系，我认为性能指标是一个参考值。与之相比更重要的是，最终的性能测试结构是否能被团队或项目中其他角色认可和接受。

在性能测试开展之前要确定性能测试指标，这是按照比较标准的模版或者套路往下走，更适合初学者或者没太多实践的同学。

但对于技术能力强有丰富实践经验的同学来说，遇到问题解决问题从来都是因地制宜的，而不是纯粹的参考或者遵循模版或套路。

作为测试同学特别是专职的性能测试同学，有责任也有义务在需求不明确时，牵头搞定这个问题。

需求不明确，那就找相关干系人(产品/研发/运维)沟通确认，帮他们捋清思路，确认需求。作为专业的性能测试人员，你要自信在性能测试领域，绝大多数业务开发和运维，是不如你专业的，术业有专攻。

以上述问题为例：提出需求的人最关心的是系统上线后的能否承载用户访问并正常提供服务。从这里入手，你可以通过沟通获得一些基本信息，比如注册用户数，日活数，或者业务峰值的网关QPS。

没有具体数值也没事，重点在于通过获得的信息来评估出几个性能技术指标，并说明背后的逻辑，和对方达成一致。

下面是几年前我负责的一个项目案例，供大家参考：

业务目标：双11当天，预估平均客单价为500，单日GMV为10亿，那么支付订单量为10亿/500=200W。

技术指标：

假设日常支付订单量为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数值。

下面是我整理的2025年最全的软件测试工程师学习知识架构体系图

一、Python编程入门到精通

二、接口自动化项目实战

三、Web自动化项目实战

四、App自动化项目实战

五、一线大厂简历

六、测试开发DevOps体系

七、常用自动化测试工具

八、JMeter性能测试

九、总结（尾部小惊喜）

人生最动人的风景，往往藏在最难攀爬的高处。当你觉得力竭时，请记住：每一次坚持都在雕刻更强大的自己。别问路有多远，只管迈步向前；别怕山有多高，向上攀登就是答案！

你体内沉睡着改变世界的力量！每个清晨都是改写命运的新机会，每次挫折都是精心包装的礼物。当全世界都在说"不可能"时，正是你证明"可能"的最好时机！