手寫腳本
什么時候要手寫？
可以有條件手寫腳本的場景有兩類：
- 有接口說明文檔
- 沒有借口說明文檔，要去錄制，錄制不了，抓包手寫
所需函數
我們這里講的例子是基於 http 協議的，也是常見的兩種請求類型：get+post，主要有以下 3 個函數
- web_url
- web_custom_request
- web_submit_data
我們用開源的接口去試試這幾個函數：https://www.apiopen.top/api.html
用法
那么，這三個函數的用法是怎樣的的？什么請求最好用什么函數呢？
1、web_url
web_url 最好用於 get 請求
2、web_custom_request
可用於 GET和POST，且 json 形式的請求只能寫在這函數內
附：Encording Type
- text/html——文本方式的網頁文件，默認是此方式。
- text/plain——窗體數據以純文本形式進行編碼，其中不含任何控件或格式字符。空格轉換為 “+” 加號，但不對特殊字符編碼
- application/x-www-form-urlencoded——默認地，表單數據會編碼為 “application/x-www-form-urlencoded”。就是說，在發送到服務器之前，所有字符都會進行編碼，空格轉換為 “+” 加號，特殊符號轉換為 ASCII HEX 值。 窗體數據被編碼為：名稱/值對，這是標准的編碼格式。
- multipart/form-data——窗體數據被編碼為一條消息，頁上的每個控件對應消息中的一個部分，上傳附件用到。在使用包含文件上傳控件的表單時，必須使用該值。
- application/json——數據以json形式進行編碼。
- application/xml——數據以xml形式進行編碼，application/xml會根據xml頭指定的編碼格式來編碼。
- text/xml——文本方式的xml文件，text/xml忽略xml頭所指定編碼格式而默認采用US-ASCII編碼。
3、web_submit_data
可用於 GET和POST，POST 請求的 key - value 只能寫進 body 里面
手寫的方式
- 瀏覽器 f12 大法
- fiddler 抓包
fiddler 抓包設置一下過濾：
寫一條正則，把 js、css等過濾掉
REGEX:\.(js|css|js|png|gif|ico|gif\?.*|css\?.*|js\?.*|png\?.*)$
檢查點
概念
檢查點的實質是從請求的response里判斷有沒有返回某個字符串，從而判斷請求有沒有成功。壓測要保證請求的成功率，檢查點會影響請求成功率，通常與金錢相關的要求成功率為100%，其他的為99%、99.9%、99.99%，視具體項目而定。
什么情況加檢查點
問題1：腳本中一定要加檢查點嗎？
檢查點影響性能，不必要的檢查點不加。
問題2：如何確定是否要加檢查點？
● 數據庫的 add、update、delete 操作不用檢查點（跑完數據庫查）；
● 數據庫的查詢操作一定要有檢查點；
問題3：檢查點的位置要放在哪？
當然是要檢查的請求的前面，函數是哪一個呢：web_reg_find
用法：
Search for specific Text 中填入要查找的內容
Search in ：可以選擇要查找的內容：ALL表全部，Body 為響應的消息體，Header就是響應頭了
Save Count ：表示匹配出來的字段出現的次數
Fail if ：表示沒找到或者找到了就報錯
補充：還有個函數是 web_find
- 這兩個函數函數類型不同，WEB_FIND是普通函數，WEB_REG_FIND是注冊函數
- WEB_FIND使用時必須開啟內容檢查選項，而WEB_REG_FIND則不沒有此限制
- WEB_FIND只能只用在基於HTML模式錄制的腳本中，而WEB_REG_FIND沒有此限制
- WEB_FIND是在返回的頁面中進行內容查找，WEB_REG_FIND是在緩存中進行查找
- WEB_FIND在執行效率上不如WEB_REG_FIND
事物
概念
loadrunner里響應時間指的是事物的響應時間、TPS指的是每秒通過的事物數，因此事物是loadrunner跑腳本的基礎。事物是用來計時用的，把一個或多個請求圈起來放在一起，統計這一個或多個請求的時間。定義事物時保證事物的准確性（干凈）
● 一個事物里就放一個被測請求，這樣事物響應時間就是請求響應時間；● 除了被測試請求外，事物中不放任何其他東西，檢查點、集合點全放在事物外面；
● 錄制時用純的URL，這樣一個URL就是一個請求；
● 修改錄制腳本中Mode=“HTTP”；
單場景壓測與混合場景壓測
● 單場景測試：先測單個接口是否滿足要求，不用考慮其他依賴
● 多場景測試：對多個接口共同進行壓測
問題1：對於用戶來說，用戶要注冊必須得先進入首頁，要壓測注冊請求是不是要模擬用戶的實際操作來壓接口？
要壓注冊不用腳本中不用加首頁，單場景壓測腳本的干凈性會影響響應時間和TPS，如同樣是壓注冊，小A的腳本里有首頁和注冊兩個請求，小B的腳本里只有注冊。同樣運行5分鍾小A的注冊TPS肯定會小於小B的注冊TPS。
問題2：單個場景壓測，用戶操作注冊動作，除了注冊單個API，還有js、css等請求也會對服務器有壓力，怎么處理？
Js、圖片、css樣式都不用管，一方面有專門的前端性能測試會去測試，另一方面現在都是采用緩存技術，訪問一次這些圖片等靜態資源資源全部緩存下來了，后面發的都是純的接口請求。
添加事物
LoadRunner 一定要添加事務，壓測過程是以事務為單位來計算的，除非設置每個請求作為事務，否則 pass 的事務為 0
● 可錄制時加事物也可錄制完成后再添加事物，錄制時添加事物，容易有冗余，不干凈；
● 錄制完后加事物，可ctrl+T,也可點擊下圖圖標
● 錄制時加事物，點擊如下圖標
集合點
概念
當通過controller虛擬多個用戶執行該腳本時，用戶的啟動或運行步驟不一定都是同步的。集合點是在腳本的某處設置一個標記，當有虛擬用戶運行到這個標記處時，停下等待，直到所有的用戶都達到這個標記處時，再一同進行下面的步驟。這樣能夠用最大的用戶並發去做下面的操作，就像集合再前進一樣。集合點是為加大瞬時並發的概率，通常搶購、秒殺會用到。
插入集合點
思考時間
概念
控制單位時間段內向服務器發起請求的數量，以達到控制服務器壓力的目的，從而影響測試的響應時間以及tps。
Run-time setting中開啟think time
思考時間如何影響響應時間
例1：已知注冊TPS=1,RT=1s，分別以1個vu和兩個vu跑，RT分別為多少？
1個並發時，RT=1
2個並發：
vu1_1 RT=1s----vu2_1 RT=2s（1s等待+1s處理）
vu1_2 RT=2s（1s等待+1s處理）----vu2_2 RT=2s（1s等待+1s處理）
vu1_3 RT=2s（1s等待+1s處理）----vu2_3 RT=2s（1s等待+1s處理）
......
可以看出當時間足夠長時，2個並發RT=2
例2：已知注冊TPS=1,RT=1s，腳本中注冊前加思考時間1s,分別以1個vu和兩個vu跑，RT分別為多少？
1個並發時，RT=1
2個並發：
vu1_1 RT=1s----vu2_1 RT=1（思考時間1s，剛好把等待時間耗完）
vu1_2 RT=1s（思考時間1s）----vu2_2 RT=1s（思考時間1s）
vu1_3 RT=1s（思考時間1s）----vu2_3 RT=1s（思考時間1s）
......
可以看出當時間足夠長時，2個並發RT=1s
思考時間如何影響TPS
假如TPS很大，單位時間內發的請求越多，TPS就越大。那么加思考時間會讓單位時間內發送的請求數變少，從而使TPS減少。
例：服務器tps=100,每次處理時間為0.1s
1個vu,1s能發10個請求，則tps=10
1個vu,思考時間1s，處理1s,則tps=1
TPS 簡單說明
* 1s是按過去的上一秒算的，過去1s內處理的事物數，
* tps忽略思考時間，只算處理時間
添加思考時間
