猫拽智库
结论先行：低代码压测的成败不在工具，而在指标口径与场景选择。上线前先把 P95 响应时间、TPS、并发用户数、错误率、资源水位五个口径写进验收文档，再按登录、分页、复杂查询、批量导入、流程提交、报表导出六类场景逐项压。只压登录页和首页、不压导入导出，是低代码项目最常见的「假通过」。
一、先定指标：五个口径写进验收文档
压测报告最容易失效的地方，是「响应时间」没有定义。有人在浏览器里掐秒表，有人在脚本里统计全部请求的平均值，两种结果能差一倍。
五个口径必须提前写清，并且写明取值位置：是服务端耗时还是端到端耗时，是单接口还是整条业务链路。
| 指标 | 口径定义 | 经验参考线 |
|---|---|---|
| P95 响应时间 | 95% 的请求在该时间内完成，剩下 5% 允许更慢 | 交互页面 ≤ 3 秒，列表 ≤ 2 秒 |
| TPS | 每秒成功完成的事务数，失败请求不计入 | 达到峰值并发目标且曲线平稳 |
| 并发用户数 | 同时在线的活跃用户，不等于同时发起请求的线程数 | 按峰值在线数的 1.2 倍准备 |
| 错误率 | 非 2xx 响应加业务失败（如校验不通过、超时）的占比 | 低于 0.5% |
| 资源水位 | CPU、内存、数据库连接池、慢查询数量 | CPU 低于 70%，连接池低于 80% |
其中 P95 最该被写进验收条款。平均值会被大量快速请求拉低，一个卡死的导出接口在平均值里几乎看不见，但员工每天都会碰到它。
并发口径也要分清「在线」和「请求」。低代码系统里多数用户处在浏览和填表状态，真正同时提交的只是一小部分。把在线人数直接换算成压测线程数，结论会被放大十倍。从在线人数推导压力值的方法，可以参考 并发容量规划的估算思路。
环境也要能自己控制。自托管平台（例如 Apache-2.0 的猫拽低代码 CatPull）可以直接部署一套同规格实例做压测；SaaS 平台则要在合同里确认厂商是否提供独立压测环境。
二、六类必压场景与通过标准
低代码应用功能面很宽，压测不需要覆盖所有页面。抓住六类高消耗场景就够，它们分别压到数据库、渲染、文件和事务四类资源。
| 场景 | 数据量准备 | 通过标准（经验区间） | 重点观察指标 |
|---|---|---|---|
| 登录与鉴权 | 全量账号，含多角色 | P95 ≤ 2 秒，无锁账号 | 会话创建耗时、单点登录回调延迟 |
| 列表分页 | 主表百万行级 | 前三页 P95 ≤ 2 秒 | 慢查询数、扫描行数、排序方式 |
| 复杂条件查询 | 多字段组合、含子表 | P95 ≤ 3 秒，错误率 < 0.5% | 执行计划、是否命中索引 |
| 批量导入 | 单文件万行级 | 无超时，失败可定位到行 | 导入事务大小、内存峰值、锁等待 |
| 流程提交与流转 | 同类单据高并发提交 | P95 ≤ 3 秒，无重复任务 | 任务表锁等待、消息队列积压 |
| 报表导出 | 十万行级结果集 | 10 万行内 60 秒内完成 | 服务端内存曲线、磁盘写入速度 |
批量导入和报表导出最容易被漏掉。它们的特征是「平时没人用，一到月底全员用」，压测必须用接近真实的数据量，拿几十行测试数据跑出来的结论没有意义。
三、工具选型：JMeter、k6、Locust 的适用差异
三款工具都能压 HTTP 接口，差别在组织方式和使用门槛，这里只做定性比较，不涉及具体脚本写法。
- JMeter：图形界面，插件生态完整，适合不写代码的测试同事；分布式压测配置繁琐，脚本文件体积大，不适合放进流水线。
- k6：脚本即代码，单机资源占用低，天然适合做每次发版前的性能门禁；需要团队里有人能写 JavaScript。
- Locust：用 Python 描述用户行为，最适合模拟「一个员工连续点五个页面」这类业务链路；压测机自身容易先成为瓶颈。
选择标准只有一条：谁能长期维护这份脚本。压测脚本和接口是绑定的，接口一改脚本就废。把脚本放进代码仓库、跟着版本走，比选哪款工具更重要。
四、低代码特有的六类瓶颈
低代码平台把 SQL、渲染、权限都封装了，性能问题也随之藏进看不见的地方。以下六类最典型，压测时要专门设计用例。
动态拼接 SQL
条件查询由配置生成 SQL，字段一多就容易拼出没有命中索引的语句。表现是查询条件越多越慢，甚至加上一个无关字段就慢一倍。压测时要抓取生成的 SQL 原文，逐条看执行计划。
N+1 查询
列表的每一行再单独查一次关联表，20 行数据时毫无感觉，500 行时直接把数据库连接打满。判断方法很简单：一次列表请求产生了多少条 SQL，这个数字应该是个常数，而不是随行数增长。
权限过滤子查询
数据权限通常表现为「在 where 里追加一段可见范围条件」。当这段条件本身是子查询、又作用在大表上时，索引会失效。典型症状是有权限的普通员工查询慢、管理员反而快，这类问题只能用真实账号压出来。
表单渲染节点过多
一张表单配到上百个字段、嵌套多层子表后，首屏渲染开销会超过接口耗时。这类瓶颈在服务端监控里完全看不到，必须用浏览器性能面板加真机测试来验证。
附件上传
附件吃的是带宽和磁盘 IO，大文件并发上传会拖慢同机房的所有接口。要单独设计场景，并且把附件存储放在独立路径上，避免和业务库抢资源。
工作流锁表
工作流引擎在流转时若对任务表加锁，高并发提交同一类单据会出现排队，表现为 TPS 上不去而 CPU 很闲。压测时观察锁等待时间，比看响应时间更有效。
五、大数据量怎么验
数据量不够，压测结论一定偏乐观。三类验证必须做，缺一类都不算完成。
- 百万行分页：准备百万级主表数据，分别压第 1 页、第 100 页和最后一页。深度翻页明显变慢，说明没有走游标或覆盖索引。
- 索引命中：用真实查询条件看执行计划，确认过滤字段和排序字段都在索引里。低代码生成的 SQL 常把排序放在最后，很容易触发文件排序。
- 流式导出：导出十万行时观察服务端内存曲线。内存一路上涨说明是一次性加载到内存再写文件，正确做法是分批查询、边查边写。
如果客户端是 App 或小程序，导出等待体验和长列表滚动流畅度还要单独验证，这两项属于端侧问题，服务端压测覆盖不到。
六、压测报告必须写的四项结论
一份能用来做上线决策的压测报告，只需要四段结论，其余都是附件。
- 容量结论：当前配置下能稳定支撑多少人、多少 TPS，对应业务上的哪个峰值时段。
- 瓶颈结论：第一个被打满的资源是什么，是数据库连接、CPU、磁盘，还是某个接口的串行锁。
- 风险结论：哪些场景没有通过、在什么条件下会被触发、上线后用什么指标监控。
- 建议结论：加机器、加索引、改导出方式、做限流，各自能改善多少，按性价比排序。
写报告时把「未通过」的场景放在最前面，不要藏在附录里。压测的价值是提前暴露问题，不是给上线找一张合格证。
FAQs
Q1：压测需要一套独立环境吗？
A：需要。压测和功能测试、开发调试共用环境时会互相抢资源，测出的数字没有参考价值。至少准备与生产同规格的数据库，并灌入接近真实规模的数据。
Q2：没有专业测试人员，业务人员能自己压吗？
A：能，但要限定范围。把六类场景写成固定脚本，业务人员只负责调整数据量和并发数，结论由技术负责人解读，避免让非技术人员自己判断瓶颈原因。
Q3：压测通过就代表上线没问题吗？
A：不代表。压测验证的是稳态容量，上线后的风险多来自数据增长、定时任务叠加和第三方接口变慢。上线两周内要保持同口径监控，定期对比压测基线。
