秒杀主要关注消息队列

之前测试期货交易的时候会把前端和接口返回的参数分别遍历组合一次执行下单（我们有 2 套前端逻辑、以及公用的 1 套接口逻辑），每个单子开仓、平仓、强平、部分平仓过程的前、中、后都会校验一次系统资金状态、正确性。

需求不能量化，能量化的是指标
你可以先把需求转化为（评测的）指标，然后对指标进性量化
你已经有一些比较具体的需求（20 万、持续时间 5min），涉及接口数 n
从需求来讲，就是：20 万个用户，在持续 5 分钟内，连续调用这 n 个接口的整个过程里面：流畅、稳定、成功率高
所以，这里的评测指标除了你已经提到的：TPS
应该至少还包括：各接口的平均响应时间、响应时间方差、（n 个接口作为一个事务的）事务通过率

如果是，不考虑逻辑的前提下，那覆盖率能达到多少呢？如果覆盖率足够高也有一定意义
这样业务逻辑上可以通过 UI 自动化补充实现

用 1、10、20 个线程分别跑个 10 分钟得出一个基准场景，看看主要的开销是在 CPU 还是内存还是带宽出口，在开销达到瓶颈的范围内的可产生的负载就是该机器最大的负载，所以，还得看脚本针对的业务场景，大批量静态文件下载产生的压力小一点，相对简单的表单提交可能大一点

原来大家都是差不多，插句话，关于需求调研，和产品那边沟通大概就是 把期望转成需求，把需求转成指标，依据经验对指标的量化做出阈值界定，最好别让太多人掺和太多性能指标和阈值相关的事情。

写的基本都是接近验收阶段的测试了

因为大部分系统的业务知识价值低

1、由于测试时间不足，所以：花 1 天时间评估系统大概的业务流程、业务角色、场景，评估紧急上线过程所产生的性能风险；

2、由于没有人配合你，所以：尽可能抓住你所理解的重点进行测试，在开干之前，出一个简要的性能测试方案以尊重目前时间进度紧张的客观事实，简要方案里面包括：

• 你理解的系统项目背景、系统业务
• 你准备采用的测试策略
• 你所理解的测试场景
• 你所估算的进度计划
• 你要求的最小资源
• 你认为目前紧张进度下你所能覆盖范围
• 你所认为的关注点（责任人的关注点、你依据他的关注点帮他敲定上线标准）
• 这次测试由于测试时间不足导致你无法覆盖哪些场景最后所引发的那些问题 然后带着这个简要方案找到项目责任人进行评审 ；

3、依据 评审 意见，修改方案，看看责任人是协调资源给你解决、还是增加测试时间、还是带着风险上线；

尽量不要瞎操心给项目增加无谓工作量，说不定系统压根就没有人用呢？

app 的启动页发