不考虑数据重复，用 yes 命令，创建 10G 文件 10 来秒，考虑数据复杂度，可以用 tpcds 来造数据

前置的需求分析与测试设计，后置的性能分析与性能调优都是不可或缺的关键。

认同，测试只是种手段，如何分析需求，分析架构链路，设计性能测试场景，将业务模型转为脚本模型才是比较重要的，不然做出来的结果也没意义，指标数据只是执行后的死数字罢了。

并发只是提高 TPS 或 QPS 的一种手段，实际操作中线程数=并发数，但是不等于处理并发能力

秒级 1000 并发需求可以有两种理解：

1. 场景可以支持 1000QPS 或 TPS，不论是高并发还是低并发，能达到就可以（达不到加资源），同时观察响应时间和错误率在合理范围内，给出达到预期的最小并发，另外如果资源冗余再看下资源能支撑的最高并发以及可达到的最高 TPS 或 QPS，评估是否符合预期（适用于流量高峰持续场景）
2. 当前资源下、1000 并发场景下的服务能力在合理范围（响应时间、错误率、资源指标），直接起 1000 并发，看资源情况（适用于秒杀活动那种场景）

这种都要结合实际的性能测试需求，看是哪一种再决定怎么做，不用纠结于字眼。以登陆接口为例的话，我理解更多的是 1000QPS 的概念，而不是 1000 个并发。

是的，测试用例评审就是拉齐产品与开发，开发与测试，测试与产品对项目需求的认知，防止出现返工扯皮

开发不想听的用例评审：点这个按钮，输入这个东西，......（🥱，好无聊）
开发想听的用例评审：这个场景下。。。这个逻辑下。。。（卧槽，这个逻辑好像没考虑到）

评审时注意引导讨论，简单 case 快速过，涉及到场景逻辑的要一条条认真对，不确认的 case 要提前标注与 RD、PM 讨论
测试经验比较少的经常写一堆前端 case，不考虑前端操作带来的后端逻辑，写了几百条看不到重点，异常逻辑分支重后端，前端操作几条就够了

我经历过的 case 评审都是在与开发对场景逻辑中度过，要么测试帮开发补充逻辑场景，要么开发帮测试补充逻辑场景，这样才是测试用例评审的意义，测试用例不是宣讲，是对齐。

测试可以做很多事情来提升自我价值，这些价值也可以被上下游认可，但问题是大部分的测试缺少这样创造价值的土壤
让做
你能做
做完落地
落地能推广
推广产生业务价值

很多做的事情死在其中的步骤中。开发从无到有可以依赖业务方、产品提供原型创造符合业务需要的软硬件产品，测试很难创造落地东西，因为没有明确的需求方。现在各种平台层出不穷，我觉得开发这些平台给自身带来的技术享受、技术提升应该是要大于平台本身对质量、效率、团队带来的价值成就的。

其实不用否认，不用证明，测试在研发测试流程中是必不可少的，但是测试人员是很容易被替代的，幸运的是我们很卷，开发卷，产品也卷，需要快速迭代，需要开发不停的写业务而不是写单测，这样给了测试生存空间，就像上面说的存在即是价值，不用怀疑自己价值，不用拔高自己价值，不要一昧追求技术广度，单一领域内的技术深耕、业务深耕可能对混口饭吃更有帮助

不能，你后面的如果反而是全链路压测更应该考虑的问题或者是关键问题。。。。压测形式、接口等等只不过是做压测必要参与条件，怎么做好反而需要考虑数据污染、流量来源、业务场景、流量比例等等这些东西

质量内建：内部没事找事
研发赋能：外部没事找事
敏捷驱动：快速做完业务然后没事找事

玩笑一下，无意排斥或怎样

质量内建：从 QA 角度出发，找到 QA 可以主导的测试质量提高的建设的事情，例如测试准入准出流程规范建设、代码提交环境部署的流水线建设，各种自动化测试提效等等。
研发赋能：从 QA 角度出发，找到可以对上下游产生影响的测试建设的事情，例如测试左移的一些事情，环境维护、单测、代码覆盖率检查，亦或者是质量内建中沉淀的测试工具、平台等放开给到研发，提高研发自测效率质量等等，或者是右移的一些事情，例如一些质量监控的东西反馈到研发、产品等等，提前暴露解决一些问题等等。
敏捷驱动：就是快速迭代，通过自动化的手段，当然不光是测试自动化包括提测上线等等，快速对齐，快速开发，快速回归测试，快速上线，线上即时反馈，再快速循环等等，但是实际真正能把敏捷用好的寥寥，这要求整个团队能在各个层面对齐，认知、技术、能力等等。

多学习多干活对个人成长提高是好事情，技术虽好，莫要贪杯内卷哦

web: console 报错给前端，接口报错给后端，都没报错给前后端
app: 接口 200 给前端，非 200 给后端
【手动狗头】

节点 1 后再增加并发，qps 仍然增加，说明节点 1 的瓶颈不是服务端瓶颈，可能是并发太少或者发压机瓶颈导致 qps 上不去
节点 2 后再增加并发，qps 不增加或者反而降低说明有可能是服务端瓶颈，还要结合响应时间、资源情况、服务 log 去排查原因

qps 上不去的原因是多种多样的，要结合压测服务的链路配置等去调整，并没有特定的规律，压测过程中流量 qps 只是其中一个指标，要结合服务器资源、数据库资源、网关等链路的每个点去看对应的指标情况，这样你才能分析出 qps 为什么会出现这样的曲线