一、先把性能拆成三类互不相同的负载
财务系统的负载不是一种，而是三类，它们的资源诉求彼此冲突。如果压测只测其中一类，得到的结论会误导容量规划。
| 负载类型 | 典型动作 | 主要消耗 | 可接受的劣化方式 |
|---|---|---|---|
| 在线交互 | 填写报销单、审批、查询单据、打开报表页 | CPU 与数据库随机读、连接数 | 响应变慢但必须成功，不能丢单 |
| 批量处理 | 凭证自动生成、付款指令推送、折旧计提、内部交易冲销 | 数据库写入与事务吞吐、磁盘 IO | 可排队等待，但不允许部分成功 |
| 报表计算 | 科目余额表、辅助核算账、合并报表、跨年对比分析 | 大范围扫描、临时空间、内存 | 可以限流，但结果必须准确且可重复 |
三类负载混在一起压，会得到一个「总体还行」的模糊结论：报表计算占满了 IO，在线交互的响应时间被拉长，而批量任务在队列里排队，谁都不算通过谁都不算失败。合理做法是分别设计三组场景，各给各自的通过线。
设计压测方案前必须确定的四件事
- 拟真的数据量：不是造一万条，而是按现有数据量放大到上线三年后的规模
- 拟真的分布：单据金额、附件数量、科目层级、辅助核算维度的分布要接近真实
- 明确的通过线：每类负载分别定义响应时间与成功率的门槛，而不是一个总分
- 可复现的环境：记录硬件规格、参数配置、数据版本，否则结论无法复现也无法归因
二、造数比压测本身更花时间
压测最常见的失败不是工具用错，而是数据失真。用一万条干净数据测出来的结论，放到两千万条真实数据上完全不成立，因为索引深度、统计信息、缓存命中率都会变化。造数的原则是按比例放大，而不是按比例缩小。
- 量级对齐：主数据（供应商、科目、辅助核算项）按现状的一点五倍造，业务数据（单据、凭证）按上线三年后的预计累计量造
- 分布对齐：不要用随机数，科目使用频次要符合实际（少数科目承载大部分凭证量），附件大小要包含大文件与零附件两种情况
- 状态对齐：数据里必须包含已记账凭证、已核销往来、已归档单据，只造「新生状态」数据会让压测偏乐观
- 边界对齐：包含跨年数据、期末结账后的数据、做过红冲与调整的数据，这些才是慢查询的高发区
还有一条容易被忽略：压测完成后要记录数据版本。同一套脚本在数据增长一倍之后重跑，结论往往不一样。把数据量、数据生成时间与脚本一起归档，后续做容量复盘时才有参照。
三、并发模型要贴近真实使用节奏
把并发数设成一个固定值持续施压，是最省事也最不真实的做法。企业用户的行为有明显的时段特征：早上集中在审批待办，午休前后集中提交单据，月末集中在查询与对账。压测脚本应当按这些节奏设计阶梯与峰值。
- 确定并发用户基数：以财务与业务侧同时在线人数的峰值为基准，而不是以注册用户总数
- 设计阶梯：从基准的三成开始，每三到五分钟上一档，找到响应时间开始明显抬升的拐点
- 叠加脉冲：在阶梯之上叠加一次短时峰值（例如集中审批场景），观察系统是排队还是报错
- 持续观察：找到拐点后不要立刻停止，至少持续运行三十分钟，排除缓存造成的假象
- 记录恢复过程：压力撤除后系统能否自动恢复，还是需要重启中间件或数据库
最后一条常被跳过，但对生产环境最有价值。压测中出现的挂起、连接池耗尽、线程堆积，往往在压力撤除后仍然存在，需要人工介入才能恢复。这类问题如果在上线后发生，就是一次真实的业务中断。
四、月结批处理才是压垮系统的那个环节
在线交互的瓶颈通常在数据库连接数与索引设计上，而月结批处理的瓶颈在事务吞吐和锁竞争上。它的特点是短时间内集中执行大量写操作，并且存在严格的顺序依赖——凭证未全部入账不能结账，这是规范层面的硬约束。
《会计软件基本功能和服务规范》（财会〔2024〕12号）第二十四条规定，会计软件应当提供会计数据按照规定会计期间进行结账的功能，结账前应当自动检查本期输入的会计凭证是否全部登记入账，全部登记入账后才能结账；同时鼓励会计软件提供跨应用、跨系统的智能结账功能，满足单位多应用、多系统情况下加强结账任务协同、提升结账效率。这条要求落到压测上，就意味着月结不是一个动作，而是一条串行链路。
- 凭证批量生成：单次处理量、失败重试是否会放大数据量
- 批量过账与期间校验：是否全量扫描未过账凭证，是否存在全表排序
- 折旧与摊销计提：是否按资产卡片逐笔产生凭证，笔数往往被低估
- 往来与内部交易抵销：跨组织取数是否触发重复查询
- 结账检查与报表计算：结账前检查本身可能就是最慢的一步
压测这批任务时，关注点不是单笔耗时，而是总时长与失败处理。一个典型的坑是批处理中途失败后重跑，会重复生成已成功的部分，导致凭证重复。因此在设计测试用例时，必须包含「中途中断再重跑」这一项，并核对结果是否一致。同一部规范第二十一条明确要求会计软件应具备经办、审核、审批等必要的审签程序并防止电子会计凭证重复入账，并提供不可逆的记账功能——重复生成在业务上不是性能问题，而是合规问题。
五、瓶颈定位按顺序排查，不要跳步
性能测试报告里最常见的一句话是「系统较慢」。这句话没有信息量。定位瓶颈要按固定顺序走，因为后面的层级都会被前面的层级掩盖。
- 应用层：先看应用日志里的耗时打点，确认时间花在业务逻辑、外部调用还是数据库访问
- 数据库层：查看慢查询与执行计划，重点看是否出现全表扫描、隐式类型转换、缺少联合索引
- 连接与线程：确认连接池、线程池是否被打满，是否存在连接泄漏
- 存储层：检查磁盘 IO 等待与队列深度，批量写入场景下这往往是真瓶颈
- 网络与中间件：多节点部署时排查节点间通信与负载均衡策略是否导致请求倾斜
- 参数与配置：最后再调参数，参数调优只能放大已有架构的上限，不能弥补设计缺陷
顺序不能颠倒的原因很实际：如果在数据库仍有全表扫描的情况下先去调大连接池，只会让更多慢查询并发执行，把系统推向更差的状况。
六、压测报告要写到能被复现
压测的价值取决于结论能否被他人复现。国家标准《系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》（GB/T 25000.51-2016）确立的就绪可用软件产品质量要求与测试文档集要求，把测试计划、测试说明、测试结果作为文档集的必备组成部分。把这套结构用在企业自建的压测上，至少应当包含以下内容。
| 报告要素 | 应记录的内容 | 常见缺失 |
|---|---|---|
| 环境 | 硬件规格、操作系统与数据库版本、部署架构、参数配置基线 | 只写「生产同构」，没有具体配置 |
| 数据 | 数据量、分布特征、数据生成方式与时间 | 只写「某企业真实数据脱敏」 |
| 场景 | 并发模型、阶梯与峰值曲线、各场景通过线 | 只给一个并发数字，不给曲线 |
| 结果 | 响应时间分位数、吞吐量、失败率、资源水位 | 只给平均值，掩盖长尾 |
| 异常 | 出现的挂起、超时、报错及恢复方式 | 回避异常，只报顺利的场景 |
| 结论 | 容量上限、拐点位置、扩容建议与兜底动作 | 给一个「性能良好」的结论 |
两份要素里最值得坚持的是响应时间分位数与异常记录。平均值会掩盖长尾——财务月结期间，5% 的请求慢十倍，就意味着每天的审批动作都会被几个人卡住，体验上的感受远比平均值差。而异常记录是上线预案的输入：知道超过拐点之后系统是排队还是报错，才能决定限额、限流与降级策略。
《会计软件基本功能和服务规范》（财会〔2024〕12号）第十条要求会计软件性能应当具备稳定性，能够有效防范和消除用户误操作和恶性操作而产生系统错误甚至故障，能够通过自动或手工方式消除运行环境造成的影响，快速恢复正常运行。这句话的落点是「快速恢复正常运行」，也就是压测要回答的最后一个问题：出问题之后，多久能回来。
资料来源：《会计软件基本功能和服务规范》（财会〔2024〕12号）第十条、第二十一条、第二十四条；《系统与软件工程 系统与软件质量要求和评价（SQuaRE） 第51部分：就绪可用软件产品（RUSP）的质量要求和测试细则》（GB/T 25000.51-2016，2016-10-13 发布 / 2017-05-01 实施，现行）。