最近性能测试服务 （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(链路)默认就是循环执⾏，可以增加⼀个参数，只执⾏⼀次，⽐如登录场景
wait(思考时间)⽀持三种：固定时间、区间随机、正态分布，分别如下图:
cookieStore(存储cookie)，⼀般在登录完成之后，如果有并⾏的场景需要共享cookie则使⽤
cookieGet(获取cookie)，主要⽤于并⾏的其他场景共享使⽤
condition(条件判断)，⽀持return/continue/jump，可以通过链路ID.key来获取作为判断的依据,下⾯的例⼦中这个值分别为3、4、5时对应的是return、continue、jump

prepare，这⾥的prepare就是指挥型的
这⾥的prepare是监听型的，监听上⾯这个prepare，业务侧看就是9个⽤户完成了登录就可以开始这边的业务场景了
dam(集合点)，这个厉害了，适配很多真实的业务场景，秒杀、抢票、查成绩等等。


实践出真知，现在就动手吧，不客气

