? ? ? ? 對于接口測試，大多數(shù)人下意識想到的后端接口剪撬，其實摄乒，除了后端接口，前端也有對應(yīng)的打點接口的残黑，那這些打點接口有什么用呢馍佑？一般來說這些打點接口是前端用來記錄前端的相關(guān)參數(shù)在不同的界面跳轉(zhuǎn)的時候，驗證查看相關(guān)的數(shù)據(jù)是否讀取與傳入梨水，方便自己調(diào)試的時候查看相關(guān)的數(shù)據(jù)拭荤，除此之外，這些打點數(shù)據(jù)可以用來做一些統(tǒng)計數(shù)據(jù)疫诽，查看前端哪些頁面的訪問情況舅世，可以收集這些情況做大數(shù)據(jù)的分析。所以前端的接口奇徒，我們錄制了主要了為了模擬移動端的打點雏亚，方便做數(shù)據(jù)統(tǒng)計分析用的，也可以作為移動端的一個壓力測試逼龟，模仿用戶高并發(fā)訪問頁面的數(shù)據(jù)评凝。
? ? ? ?一般來說，前端的打點數(shù)據(jù)接口和后端有些不一樣腺律，為了打點奕短，除了會傳入一些通用的字段數(shù)據(jù)外宜肉，還需要輸入特定動作的字段，并且特定動作的字段翎碑，還會根絕不同的來源類型進行區(qū)分谬返，所以相對后端接口來說，需要設(shè)置的選項多了不少日杈。例如我自己現(xiàn)在錄制的一個沙箱環(huán)境的微商城的查看商品的打點接口：
GET /s/pi-mall/1531564428887/i2.gif? 這個接口看起來和后端的接口很多不一樣遣铝，只有一個模塊的區(qū)分，很多內(nèi)容需要根據(jù)傳入的數(shù)據(jù)進去區(qū)分的莉擒，具體的抓包截圖如下：
從截圖上可以看出酿炸，這個前端的打點接口需要傳入2個url，
一個是左側(cè)的網(wǎng)關(guān)接口（host?）：?gateway.master.sandbox.terran.wxpai.cn
一個是商品詳情頁面的地址（url）這個地址才是我接口的真正頁面地址：http://31612.sandbox.terran.wxpai.cn/mall/mobile/2.4.0/?#/detail?id=17810
然后下面是需要傳入的20多個參數(shù)涨冀。
開始錄制的時候填硕，為了方便，我是用了fiddler的headers頁面的 request header的內(nèi)容鹿鳖，這樣可以一次性傳入所有的參數(shù)
復(fù)制的時候扁眯，發(fā)現(xiàn)有部分傳入的參數(shù)的符號被改了編碼樣式：
GET /s/pi-mall/1531642985754/i2.gif?url=http%3A%2F%2F31612.sandbox.terran.wxpai.cn%2Fmall%2Fmobile%2F2.4.0%2F%3F%23%2Fdetail%3Fid%3D17810&title=%E5%95%86%E5%93%81%E8%AF%A6%E6%83%85&ua=Mozilla%2F5.0%20(Linux%3B%20Android%207.0%3B%20KNT-AL20%20Build%2FHUAWEIKNT-AL20%3B%20wv)%20AppleWebKit%2F537.36%20(KHTML%2C%20like%20Gecko)%20Version%2F4.0%20Chrome%2F57.0.2987.132%20MQQBrowser%2F6.2%20TBS%2F044109%20Mobile%20Safari%2F537.36%20MicroMessenger%2F6.7.1321(0x26070030)%20NetType%2FWIFI%20Language%2Fzh_CN&screen_width=360&screen_height=640&pixel_depth=32&screen=360x640&referer=http%3A%2F%2F31612.sandbox.terran.wxpai.cn%2Fmall&uid=55527&ent_id=31612&app_type=pi&domain=31612.sandbox.terran.wxpai.cn&user_mark=&device=KNT-AL20%20Build%2FHUAWEIKNT-AL20&os=Android&os_version=7.0&pf=wechat&pf_version=6.7.1321&ch=&prev_ch=&client_type=web&app=pi-mall&log_type=pageview&prev_page=%2Findex¤t_page=%2Fdetail%3Fid%3D17810&path=%2Fdetail%3Fid%3D17810&mod_path=%23%2Fdetail&prev_mod_path=%23%2Fdetail&product_id=17810&sharer_id=&_=1531642985753.49f305a6 HTTP/1.1
開始以為是被加密的時候改碼顯示了，所以手動一個個改回圖一第一次看到參數(shù)的格式翅帜，并且把 可能會換動的參數(shù)給參數(shù)化姻檀，例如 ent_id 、user_id涝滴、product_id 這一類的變量用 ${ent_id} 的格式進行才參數(shù)化绣版，這樣可以在錄制循環(huán)前面加個加個自定義變量進行一次性輸入。但是發(fā)現(xiàn)地址好長歼疮，需要對應(yīng)著一個個參數(shù)位置去來回修改僵娃，看的眼睛都花了，而且調(diào)試了半小時腋妙，發(fā)現(xiàn)很容易改錯了地方默怨，老提示報錯。于是決定采用parameters 部分逐個添加對應(yīng)的參數(shù)和數(shù)值骤素，這樣就不用擔心改錯了參數(shù)了匙睹，并且可以和圖一的參數(shù)表格一一對應(yīng)，然后完成后的結(jié)果如下：
開始以為這樣就可以設(shè)置成功了济竹，于是單擊執(zhí)行這個任務(wù)測試了下痕檬，發(fā)現(xiàn)報錯了：
java.net.URISyntaxException: Illegal character in fragment at index 180:
但是仔細的對著每一個參數(shù)和抓包的圖一的數(shù)據(jù)對照，發(fā)現(xiàn)沒寫錯什么啊送浊，為什么會報這個錯的梦谜？然后百度了一下這個錯誤，才知道原來前端的打點接口后面接的是url，很多格式需要轉(zhuǎn)碼唁桩，具體的解釋如下：
（解答參考地址：https://blog.csdn.net/maybe_frank/article/details/78714449）
于是按照這個格式一個個的改會轉(zhuǎn)碼的格式(原來是自己一個錯誤的理解闭树，擅自改回正常的顯示格式引起的錯誤，一直以為前段打點接口傳入?yún)?shù)內(nèi)容和后端接口一直荒澡，原來是需要轉(zhuǎn)碼的)报辱，這個坑踩的不冤，于是按照這個格式修改完畢后单山，重新執(zhí)行了一次就OK了
終于順利的完成了第一個前段打點接口的錄制了。
