什么?性能测试(PTS)居然还有这么多隐藏技能?

  1. 云栖社区>
  2. 博客>
  3. 正文

什么?性能测试(PTS)居然还有这么多隐藏技能?

中间件雁溪 2017-10-30 15:20:23 浏览2656
展开阅读全文

最近性能测试服务 (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(集合点),这个厉害了,适配很多真实的业务场景,秒杀、抢票、查成绩等等。

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

网友评论

登录后评论
0/500
评论
中间件雁溪
+ 关注