最近在工作中遇到 2 个性能测试的项目，需求如下，请大佬帮忙分析一下，如何设计性能测试的场景，TPS 如何安排比较的合理：
- 项目 A：后台管理系统。要求 30 个用户，每年的事务总数是 300W，性能测试运行一个小时。这样的条件的话，我们怎么安排 TPS 比较合理？
- 项目 B：一个类似 OA 的系统。要求 2500 个用户同时访问，提交审批流程。但是每年只有 5000 个流程的申请需求。这样的情况，我们如何设计 TPS？
还请大佬赐教。
TPS 如果没有线上业务数据，我一般是用 28 原则来算，A 项目的 300 万事务量都不用乘 0.8，算 365*0.2=73 天全部跑完，每天业务量 300 万/73 约等于 4 万，4 万按 28 原则算也不乘 0.8 了，40000/(24*3600*0.2) 约等于 2.3，所以实际业务 TPS 预估到 3 就够，一般这种情况，我会给客户方一点面子，乘以个 10，TPS 定 30。这个是指标要求，跑一个小时无所谓，这个是验证一定压力下的短时间稳定性，关注重点在系统业务处理是否报错，系统资源是否问题。至于 B 项目就有点扯淡，你得直接回怼回去，2500 人提交审批又不是定个定时器来提交，如果要支持 2500 并发，需要另外设置场景，但 2500 并发的场景你得确定要达到的性能要求，性能要求高的话除了优化代码和配置策略外，大概率需要大集群来支持。至于 TPS，我还是觉得按业务量来算，不过你可以再给客户方留点面子。。。
设计 QPS 吧，TPS 是服务器的处理能力
条件不足，无法安排
一年的量换算到每天是什么级别，实际使用时是个什么场景都不知道
第二个项目， 一年 5000 个流程申请，要 2500 个用户同时访问？ 看着像是什么时间节点扎堆访问，得描述清楚才行
我只想知道这么扯蛋的性能需求是谁提出来。
CKL的思考
回复
哈哈，系统验收的必要过程，需要一个性能测试的报告。所以就觉得为难，每年的事物数实在是少，如果不限制 TPS，一个小时能跑好几年的需求。
TPS 如果没有线上业务数据，我一般是用 28 原则来算，A 项目的 300 万事务量都不用乘 0.8，算 365*0.2=73 天全部跑完，每天业务量 300 万/73 约等于 4 万，4 万按 28 原则算也不乘 0.8 了，40000/(24*3600*0.2) 约等于 2.3，所以实际业务 TPS 预估到 3 就够，一般这种情况，我会给客户方一点面子，乘以个 10，TPS 定 30。这个是指标要求，跑一个小时无所谓，这个是验证一定压力下的短时间稳定性，关注重点在系统业务处理是否报错，系统资源是否问题。至于 B 项目就有点扯淡，你得直接回怼回去，2500 人提交审批又不是定个定时器来提交，如果要支持 2500 并发，需要另外设置场景，但 2500 并发的场景你得确定要达到的性能要求，性能要求高的话除了优化代码和配置策略外，大概率需要大集群来支持。至于 TPS，我还是觉得按业务量来算，不过你可以再给客户方留点面子。。。
数据不足，没有办法设计。可以反问业务峰中是多少，根据峰值进行拆解。
建议不用做性能测试，没必要。这点事务量建议人工。不用麻烦机器了。
建议按数据量来，量运行多了，可能影响
这种场景我建议你直接把系统的性能瓶颈测出来扔他脸上就完了，当然如果你们连这点性能要求都达不到那就直接退款把！
第二个就也可以先看下自身瓶颈，如果相差较大就和他讨论需求太扯淡，如果差别不大就以理服人，如果直接意料之外的锰就先说他太扯淡再来个以理服人