比例，可以线上对应的业务调用量

建议拉一份生产的请求日志，然后写个简单的脚本处理一下看看各个场景占比各多少，或者分析性能需求，需要什么就测什么。

类似的步骤可以有：

• 测试需求分析：测试中涉及的性能指标的定义，要看用户的明确需求和隐含需求

• 测试对象分析：测试中涉及的业务及系统内部模块的定义，分析各个模块的调用关系，理清系统架构

• 测试重点分析：测试执行策略、测试监控策略、测试风险的定义，分析测试重点，一般来说性能测试都不会进行全面的测试，而是对测试重点进行测试

• 测试环境分析：测试中涉及到的服务器资源、测试软件、测试数据、测试桩定义，性能测试环境往往和生产环境不是 1:1 的，这些对测试结果的影响是需要分析确定的

• 测试场景构建：从性能负载、接口、疲劳角度定义测试场景

• 性能测试执行：按照预设的计划利用工具完成测试过程，注意系统资源的监控

• 测试数据分析：分析上述过程中产生的数据，得出结论

还有未上线的

您好，感谢详细的回复，你这边意思是选择调用频繁的接口进行处理吗？然后通过日志来明确各个接口的比例？

不完全是这个意思，希望能从实际场景出发，分析实际场景中各个接口的比例（这一步会用到请求日志），然后来决定如何设计测试计划。

由于我们这边项目更新变化比较大，不同的行方版本就不同，线上没有啥具体意义，更多偏向功能测试
你的意思是各个模块来测试吗

多个接口比例，个人理解本质上是根据业务场景确定的。

已上线：可以基于线上数据获取，比如流量录制，或者通过日志来分析。而且要注意想办法多拿几次数据，确定要有哪几种场景。
未上线：找项目相关的开发、产品、运营一起评估下用户最常用的场景，分析场景里接口调用情况，然后把它作为一个大致的基准。

虽然有点卖广告，但还是推荐看看高楼老师极客时间的《性能测试实战 30 讲》，里面 13、14 讲就是特别讲这块的，个人觉得也是相对科学的方法。

接口比例一般是通过生产流量的分析建模来确定的，如果没有生产流量，那就要预估和建模。一个系统不可能什么分析都没有，总有一些期望的数据的，比如 PV、订单数、业务量、数据量等，把这些对应到接口去，就是一个不错的建模。
真没有的话，先问选型是怎么选的，架构是怎么设计的，不可能完全没有输入。

感谢，决定与看看《性能测试实战 30 讲》

嗯嗯，发现楼上大家说的基本一致，感谢

还有其他材料分享吗，感谢

可以社区里搜一些性能测试相关文章看看。

性能测试比较花多杂乱，建议自己不断实践不断学习吧。