我想知道做一个完整的性能测试的流程是什么样的

1. 日活量 20W 和日开户 20W 的概念不一样吧？
   
2. 如果是日开户 20W，需要估算一下转换为每秒大概是多少并发量（根据业务模型来估算峰值）。 压测的时候可以以这个值为参照，设置对应的并发数（一般系统的承受量要比估算的峰值高）。
3. 日活 20W，那么说明系统其它的接口也会产生对应的请求。同样需要估算有哪些接口、每个接口的请求数大概如何。对应的是需要设置不同接口的权重。

首先明确一下开户接口调用的时间分布 最高一段时间会有多少人 然后转换到一秒会有多少 tps 给这个值 *2 就当你的目标 然后看看用户行为 会有同时注册这种情况吗如果有就要增加一个抢注册这样场景 并发需要设置集合点 其他可以再看看会有持续比较长时间一值有人注册的场景 可以模拟这个场景看系统较长时间运行情况

以上纯属拍脑袋

日活量 开户 20W，那需要掉用很多接口，可以考虑下在某一接口上做并发，比如发送验证码，用户四要素验证并发，入库并发。账号激活并发

个人愚见，列出大概步骤：
一、单接口的容量测试
1、单机部署测试单接口的容量，阶梯测试方法；
2、双机集群部署测试单接口的容量，评估扩容能力，以及预估线上当前可支持的最大容量；
二、场景测试
1、整理出系统的主业务场景，监控历史数据，设计出场景模型，即场景比例和场景的漏斗请求转换比例；
2、根据当前业务模型，测试性能情况，分析是否满足业务场景；
3、对主要被测业务适当调整流量比例，进行摸高测试，评估在高流量情况下，性能情况。

压测是往死里压，压出一台设备或者一个集群的瓶颈，还有就是否在特殊场景下压力导致系统崩溃。举个例子：数据库在没有 redis 缓存的情况吓被击穿，此时的压力数能承受多少。一般系统架构设计没问题，承受的压力是有预估的，出问题更多的是不高可用性引起的性能问题。

同 3 楼，先找出业务发生主要的时间点，如果没有明确的需求，那就 2/8 原则来弄：80% 的业务发生在 20% 的时间内
80%*20W/(3600*20%*8)=28，也就是每秒至少完成 28 笔，如果是 30 秒内就要完成 20W 笔那就是另外一回事了，直接除：20W/30=6667，每秒 6667 笔
如果每笔业务最慢能接受的响应时间是 2S，那并发就好算了：28 * 2 或者 6667 * 2，就是需要分别确保在 56 和 13334 并发的情况下响应时间在 2S 以内，服务器资源使用率在可控范围内便可……至于是否有其他的额外事物时间，就需要根据自己的业务来了
楼主的测试需求属于容量范畴，不应该单纯的考虑压力测试场景，压力测试的主要目标是限定资源、持续加压，找到系统 fail 的点，这跟需要在多久时间内完成多少笔业务其实是两个维度的事情。

为什么 3600×20% 之后还要×8 呢？

80% 的业务发生在 20% 的时间内，日活——日，一般就是拿工作时间作为参考基准时间窗口的，人家又没说是时活

哦哦，明白了。谢谢解惑了