675 財經資訊

什麼？性能測試（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(鏈路)默認就是循環執⾏，可以增加⼀個參數，隻執⾏⼀次，⽐如登錄場景