很多时候会遇到这样的性能需求“系统需要能够在一分钟能处理50笔业务”，对于这样的性能需求怎么做性能测试才能算达标？
1.需求合理 假设这个需求用户是给的正确的，那么性能测试目标就非常简单了，既然50笔业务每分钟，也就是50/60=0.833TPS，也就是说如果系统的每秒处理能力大于0.8333就可以认为一分钟内能处理掉50笔业务了，适当缩放可以简单就用1TPS作为最终测试标准。
2.需求不合理 用户给出的这个需求可能只是一个平均值，不能代表真的峰值，而且如果50笔业务同时出现，会导致部分业务等待时间接近1分钟的情况，所以在没有设置用户最大等待时间这个前提下，按照上面的1TPS来做是不太合理的，因为1TPS会导致50笔业务同时进入，最慢的业务要等50秒，这样的话用户是不能接受的。
3.补充需求 假设用户将需求再次细化为“系统需要能够在一分钟最多处理50笔业务，每笔业务的等待时间不超过2秒”，这个时候的需求就变了，假设在这1分钟内，所有用户是同时进入的，那么系统就需要做到50/2=25TPS才能满足；如果认为用户不会在一分钟内全部进入系统，而是最大10笔业务，剩余分散在剩下的时间内，那么10/2=5TPS即可满足需求了。
在这里还会涉及到一个在线用户的问题，在线并不一定会产生请求，所以在考虑处理能力时并不用考虑在线的问题。
补充在线、处理能力的关系： 简单可以理解成一个饭店，厨师决定了出菜的处理能力，厨师越多，相对来说出菜的TPS就越高。（如果细分可以理解成：厨师是CPU、配菜、点菜是内存、送菜是IO或网络） 那么在线用户就可以理解成进入饭店的顾客，饭店的面积越大，餐桌越多，那么能够同时在饭店吃饭的人就越多，这就是在线用户，但是所有在饭店的人不可能同时点菜，也有些是在等人，所以并不是所有的在线用户都会产生负载，最终只要用户点菜后，在可控时间内上完菜就行了，这就是为什么现在很多饭店流行如果上菜速度慢于多少秒就免单这样的规定了。 太多的餐桌配不上处理能力会导致顾客等菜影响体验，太多的厨师如果没有配套的餐桌会会导致厨师闲着没事，所以平衡系统用户与处理能力是一个很有趣的事情。
