【2】性能测试平台从设计到实现-中控系统之资源管理

本着由浅入深，层层递进的讲述方式，先把平台的大致轮廓以更加感官的方式呈现给的各位同学。我们今天来聊一聊资源管理。在最初的设计中，任务以pipeline+duty的方式串联起各个可复用的资源【包括但不限于计划、用例、数据、压力模型、执行节点、监控、通知等】，而在这其中，一个任务必备的四要素是：用例+数据+压力模型+执行节点。其他都是可挂载的非必须要素；

首先先来看用例，我们的用例提供两种方式，即UI模式和脚本模式，其中UI模式，参考POSTMAN的KV-Editor的交互设计，供用户使用。

UI用例的优劣势明显，针对简单的单接口压测，同POSTMAN编写接口功能测试一样，几乎没有学习成本，操作简单，便捷。但由于提高了易用性，必然会对功能性做裁剪，所以像场景链路串联、丰富的自定义断言等，我们都没有提供，本着提供20%的功能覆盖80%场景的原则，我们推荐用户在做基本单接口压测时，选择UI用例。

那如果是复杂的场景串联，设计流量按漏斗比例分配又如何处理呢？脚本是一种不错的选择，由于脚本方式远程支持压测引擎的全部功能，又可以使用第三方库来做响应的补充。堪称完美，对于习惯了写代码做调试的码农，更推荐这种方式。

看完上述的脚本，大家应该能猜到我们的压测引擎选的是什么了吧？后面会有一章来对主流的开源压测引擎做对比介绍，包括JMeter、Gatling、Locust和K6。

聊完用例，我们来看看压力模型，并发数和QPS。我们更多用并发数模型来验证秒杀这种瞬时大流量的场景，用QPS来模拟日常流量做系统稳定性的评估。在两大类模型下，我们又可以基于一次性注入、斜率加压、恒定加压、梯度加压来构造我们的自定义压力，根据设置我们来绘制预估压力模型图，便于大家更加直观的验证设置是否符合自己的预期。