我们在前面屡次强调了场景的重要性,今天终于到了要把实际场景拿出来解析的时候了。
在本篇文章中,为了保证数据的连续性,我用之前的项目资料来作明确地说明。同时为了模糊关键业务信息,以及让场景的描述更通用性,我会把所有的业务名隐去。
根据之前我们所说的,基准性能场景是为了测试出单业务的最大容量,以便在混合容量场景中判断哪个业务对整体容量最有影响。
今天的场景设计需要说明两个前提条件:
1、这些业务都是实时的业务,不涉及批处理、大数据等业务。
2、因为本篇着重讲场景的设计和具体项目的操作,所以不加系统资源的分析,避免信息混乱。
在这个场景设计中,首先,我们要列出自己要测试的业务比例、业务目标 TPS 和响应时间指标。
在这个项目中,响应时间指标是统一的,就是不大于 100ms。
其实我们在做项目的时候,经常会这样制定一个统一的响应时间指标,这样做也不是完全因为懒,更多的是根本不知道如何定每个业务的时间。但我们性能测试人员要知道,这显然是不对的,因为业务不同,响应时间指标也应该不同,合理的做法是给出每个业务的响应时间指标。下面我们还会遇到响应时间定得不够细致的问题。有了这个列表,下一步就是做基准性能测试了。
基准性能场景
有很多人做接口测试的时候,觉得接口的 TPS 真是高呀,于是就按照最高的 TPS 跟老板汇报。但我们一定要知道的是,接口的 TPS 再高,都无法说明容量场景的情况,除非这个服务只