这个问题略大，不知道怎么回答你。以自己理解简单说下把：

首先需求只有个 峰值 20w 用户 ，是不能直接转化为场景的。需要分析抢券这个场景涉及哪些接口请求（比如查券接口 - 抢券接口），然后这些接口请求的频率大概会多高（比如查券可能一秒一次，抢券从头到尾只有一次），把需求转换为抢券时各个接口大概每秒会承受多少次请求，即要达到多少 tps，接口请求之间比例大概多少这些。这些最好和后端开发沟通下，他们对自己系统最熟悉

建议可以买些书或者极客时间的课程看下，这样效果才好。个人推荐极客时间高楼老师的课，讲得比较简单易懂。

好的，谢谢哥

可以把这个业务场景需要哪些最外部的接口都给列出来，然后分析调用的时序 (先调 a->b->c 如果支持多种选路径最短和产生数据压力最大的) 和执行一次，这些接口分别调用次数，写成一个文件
如果需要程序 mock 一些接口的，需要确定 mock 掉的接口对于你现有流程是有压力的。
这个就是分析时序的地方，需要分析哪些可 mock，哪些不建议 mock，比如 mock 后把后面整段逻辑都砍了，这样压测也是没压力的，因为一个小的完整链路是空壳子。
然后根据时序的文件去添加一个字段叫调用频率，这个调用频率会等比缩放到你压测连接数上面。
还要知道最终压测目标是高频压负载还是只是跑稳定性等等，或者是先压核心模块在全量压等等

我是不是需要线上服务器和测试服务器的相关参数，然后根据测试服务器压出来的数据去判断线上的一个大概情况。我需要给出需求方活动页面线上服务器能承受的一个大概人数