什么？性能测试（PTS）居然还有这么多隐藏技能?

最近性能测试服务（PTS）的产品经理提了很多需求（郑重声明，来源于客户），虽然开发GG说已经上线了，但是我*，作为产品经理的智商愣是没找到。。。
看完开发GG的介绍和文档，我内心的OS是：“我!@#¥%... ...&&,这货估计被魂⽃罗和97残害了十⼏年，←→←→←→←→AC,↑↓↑↓↑↓↑↓BD,↑←↓→↑↓BC,上、上、下、下、左、右、左、右、B、A、B、A。。。。。。”

给你们举例子，比如Header和Cookie设置：

基础版⾥Header的设置是这样的，在新增脚本或编辑脚本的页面，将光标移至请求链接上方，将出现链接的编辑选项，单击高级属性。

Header 项中 POST 请求默认添加 Content Type 请求头，值为 application/x-www-form- urlencoded。

铂⾦版里是这样的:

然后你发现大有文章。。。。

比如Header和Cookie的设置，其实直接支持批量在参数文件⾥设置了，⽽且超简单：格式为 “header::key=value”。
如果有多个 Header，请使用 & 隔开，与普通参数的区别是 Header 有⼀个前缀 header::，跟普通参数放在⼀起，没有顺序要求。而Cookie 是一种特殊的 header，也可以参照设置 header ⽅式来设置，例如:
开发GG说这样便于构造大量的压测数据，随导随⽤，而且有开发背景的⽤户一看就懂, 我。。。。。。。。

然后，远还没有结束，类似这种开发视⻆的，geek风的设计还有，⽐如业务场景⾥很常见的串行实践:

对于同⼀个业务系统，链路和链路之间存在⼀定的逻辑关系。链路串⾏主要适⽤用于这种存在参数依赖的场景。建议不要将只是逻辑上存在依赖的链路串⾏起来。

开发GG还不忘把理念也输出。

具体的他⽤了商城系统抽奖活动为例说明，本次活动会引导⽤户进⼊首⻚进⾏抽奖，预估的访问⾸页的峰值 TPS 为 10000，其中有 8000 TPS 进⾏了抽奖，抽中的概率为50%，那么会有⼤大概 4000 TPS 对商品进⾏浏览，根据历史的数据⽤户下单付款的概率在 10% 左右。我们可以抽象出“⾸⻚”、“抽奖”、“查看详情⻚”和“下单”等四个业务链路，从业务的维度来说存在⼀定的逻辑关系，但是我们进⼀步分析可以发现，除了首页之外，“查看详情页”和“下单”都依赖“抽奖”的结果。因此可以将后⾯三条链路串⾏起来。

然后怎么串起来呢？他说这⾥编排，呐，这⾥

开发GG是这么一本正经的给(hu)我(shuo)解(ba)释(dao)的:

编排是通过json格式实现的，就是数组和对象的组合，最外侧的数组就是表示并⾏的⼏个业务场景

单个场景⾥是串⾏的，然后重点来了，在单场景的数组⾥可以定义很多指令(directive)，⽐如:
chain(链路)
wait(思考时间)
cookieStore(存储cookie)
cookieGet(获取cookie)
condition(条件判断)
prepare(具备监听和指挥的功能，互相关联，配合cookie的操作，⽐如需要⼏个⽤户完成登录再
进⾏其他场景的开始)
dam(集合点)

其中
chain(链路)默认就是循环执⾏，可以增加⼀个参数，只执⾏⼀次，⽐如登录场景