1：性能測試關鍵指標
衡量性能測試的參數
一：響應時間
二：並發用戶數
三：吞吐量
四：系統性能計數器（資源使用率）
五：思考時間
功能性測試：pass和fail
性能測試指標：多維度的指標衡量：快不快，強不強，好不好
多（支持最大的用戶訪問量） 快（響應時間多快） 好（持久運行） 省（資源節省）
多：並發量 快：延時，響應時間 好：穩定性，長時間運行 省：資源使用率 +一個思考時間
一個好的系統就是多快好省的一個系統
2：響應時間
對請求做出響應所需要的時間，是用戶感知軟件性能的主要指標
如上典形的三層模型：客戶端（瀏覽器），應用服務器，數據庫服務器 所有的應用服務器和數據庫都是基於操作系統的
客戶端在桌面上打開一個電腦，輸入網址，通過http請求先發送到web服務器，web服務器根據鏈接查找文件，有網絡接收時間
有處理時間A1，之后如果要查數據（比如登錄驗證用戶名密碼）需要訪問數據服務器，有個N2網絡時間發過去，
如果數據服務器和web服務器是同一台，那么N2和N3基本認為可以沒有了，變成了程序時間的進程通信，本機交互
如果web就在web服務器打開網頁請求，那么N1和N4就沒有了，三合一就沒有網絡時間了
響應時間包括上面的全部：N1,A1,N2,N3,A3,N4
用戶不知道經過多少服務,只看打開頁面和接受的時間（兩者時間差），客戶感知的感應時間：是端到端的（不管中間經過多少請求，多少處理不管）
發出請求多久能受到
測試工程師需要關注：N1到N4所有的請求的時間 web服務器和數據庫服務器的網絡響應時間N2和N3：linux ping命令查看兩台系統的響應時間，簡單
這是網絡時間，不是處理時間
響應時間多少合理：
對於一個web系統，普遍接受的時間標准為2/5/8秒
2秒鍾之內響應客戶是非常好的
5秒鍾之內響應客戶是可以接受的
8秒鍾是客戶能夠接受響應的上限
響應時間包括：
1：用戶客戶端呈現時間
2：請求/響應數據網里傳輸時間
3：應用服務器處理時間
4：數據庫處理時間
3：並發用戶數
用戶三種類型：
系統用戶數：1w個人注冊了，下載了app並且注冊了，保存在數據庫里面真正的一條條數據（app熱不熱門看app的注冊量，不是下載量）
注冊用戶數對系統影響不會太大，主要影響磁盤空間，存儲上面，內存也會受到影響，cpu也會受到影響
響磁盤空間滿和空對於系統查詢來說是有很大影響的，系統性能測試的時候一定記得初始化環境
裝的東西多了，找東西更花時間，撈數據更慢
性能測試需要部署這部分系統用戶數，存量用戶，系統的環境
系統性能測試需要構造出跟現場差不多的環境，數據庫空的，和數據庫有一億數據的是有很大差別的
存儲區域滿的的需要尋址去寫入數據，空白的寫和塞滿了找空格去寫，寫的速度一樣，找地址的速度相差很大
沒有經過初始化的性能環境==沒有作用的環境（現場的配置，現場的用戶量，還有網絡環境，測試的時候數據a機器，服務器b機器，兩個機器背靠背網線一連接
交換機都不過，這樣進行系統測試也是沒有什么意義的，現場a機器上海，b服務器北京，一測就是gg
測試時候：a-b可能就是0.0001s，現場：a-b可能就需要2s了，這時候找運維：注入延時，兩台電腦的防火牆上面注入延時
linux系統注入網絡延時的方法，windwos注入網絡延時（命令工具注入都可以）規定必須2s才能牽手）
在線用戶數：
登錄了，但是沒有行為，什么都不干，對系統就沒什么壓力
12306：在線被踢了，登錄不上系統
在線用戶數影響：
內存（web的session會話需要保持，會話放在內存里的，同時在線需要保持登錄狀態，內存消耗很大）
cpu：在線用戶數和cpu有關系但是關系不大，
cpu：時間片，cpu基於時間戳的，每個進行任務分個固定時間，看狀態好不好執行，執行好了執行下一個，保持業務任務公平執行
每一個進行都有個時間片，用完了下一個，排隊，全部塞在內存里面的進程，在線用戶就是一個session，cpu會看里面有沒有動作
一個個過掉了，因為用戶沒有操作，沒有行為，會花時間，基本上很少，切換的很快的，和cpu關聯不大
磁盤：一丁點關系
網絡：一丁點關系
對什么要求最高，什么就容易產生瓶頸，系統測試就是在木板里挑選一個短板，
並發用戶數：秒殺了，同時在線做操作，
1：嚴格並發 所有的人再同一個時間做同一件事，同一時間點一個按鈕
2：廣義並發 不嚴格並發，你點你的按鈕，我點我的按鈕，你打開頁面，我登錄，你查詢，我下單 這也是並發
性能測試需要兩個都在，極端情況下做一個最敏感的，秒殺雙11搶購，平時有秒殺的，查詢的，改訂單的，等做成一個不同的場景出來
用不同的jemert去洪他，所以性能測試只有一個jemeter是不合格的，只有一種場景不得行，（性能測試需要幾個jemert，腳本需要幾套）
極端的可能就一種情況，但是一般需要規划的：100個用戶，25個登錄，25注冊，25查詢，25評價
一般嚴格並發和廣義並發都要測試---這就是性能的規划了
並發用戶數的計算公式
知道平均的每天多少訪問量，一天內登錄導退出的平均響應時間，總共觀察多少時間得到一個這樣的公式
每天多少訪問量，每個人訪問的時間，考察的時間長度（一天或者半天）來進行計算，就是平均並發用戶量
3000用戶，平均每天400個系統訪問系統，典形用戶一天只在8小時內使用改系統，從系統登錄到退出系統的平均時間4小時
C=nL/T=400*4/8=200 得出並發用戶數200 估算
C^=200+3*根號C
如果系統不熟悉，並發用戶數怎么計算
並發用戶數量的統計的方法目前沒有准確的公式
不同系統會有不同的並發特點
假如QA系統統計並發用戶數量的經驗公式為：使用系統用戶數量*(5%~20%) (系統注冊用戶數量的百分之5-20)
1w人注冊，固安一下500人的並發量
前面用戶量從0-500，系統還好的響應時間基本不變，后面用戶量達到500了時候，突然升到很高，這里就是性能拐點，
到了這個臨界點性能就很糟糕了，500用戶量達到性能瓶頸了，用戶響應時間超長，用戶還可能沒有響應了，500這個並發量就是
性能拐點，jemter有監聽和統計報表
4：吞吐量
吞吐量：單位時間內系統處理用戶的請求數，單位時間，比如1個小時，系統讓1w個人正常訪問
吞吐率：單位時間變成1s，每秒鍾多少，一般關注吞吐率，一秒鍾能處理多少，這時候TPS出來，每秒鍾處理的事務數
一個事務可能包含幾個消息，TPS吞吐率，js有這種空間計算的
吞吐率吞吐量有不同的方式，每秒鍾多少字節，多少請求，一般使用請求數的比較多
吞吐量的估算計算公式
100個並發，每個VU間隔1s法出一個請求
吞吐量=100*1/1=100
圖形分析
隨着用戶量的上升，吞吐量上升，再上升的時候就平了，並發用戶再多的時候，不變了，瓶頸了，上不去了，飽和了，性能瓶頸了
這時候需要加一套服務器或者看一下內存滿了還是cpu滿了，還是磁盤滿了，資源監控和分析
這里面出現飽和的基本上都是網絡原因比較多，cpu和內存的問題不會一條線那么絕對會不變動，會有波浪
這時候可能是網絡臃塞了，需要加帶寬了，網絡丟包了，很無情，滿了就丟
內存滿了會和磁盤進行交換，用交換空間，會震動一下
cpu滿了有時候會下來一些，，空閑時間突然可能好了一點，會波浪線上上下下，一條線這么絕對可能就是網絡
后面可以網絡命令監控一下
5：性能計數器（資源使用率）
性能計數器：描述服務器或操作系統性能的一些數據指標
比如：
內存
cpu
磁盤等資源使用率
6：思考時間
消息和消息之間留一個等待時間，發一條消息，然后等1s再發一條信息，更加真實模擬用戶的行為，
Think Time：業務角度來看，這個時間指用戶進行操作時每個請求之間的間隔時間
在做性能測試時候，為了模擬這樣的時間間隔，引入了思考時間這個概念，更加真實的模擬用戶操作
7：系統環境初始化：重點
網絡方面：注入延時
對於數據庫：不是很敏感的數據，把數據庫dump過來，導出來，備份還原進去、數據很敏感，根據數據的表格格式
姓名，密碼，電話號碼，郵箱，等，知道格式后使用數據庫腳本創建就行了，模擬出來，構造出來
知道結構和量就行了，1千萬的數據腳本刷進去就行了
對於在線用戶數：warm up熱機，熱身，讓用戶跑進去，把內存填起來，不要為空，讓系統接近於正在運行的系統，讓系統查詢速度更快
，數據從磁盤進入內存的一個過程，正常跑的系統，里面大部分用戶數據在內存里面的，速度更快，
一開始跑，特別是查詢的時候，速度很慢，長時間跑的數據片和數據區在內存里都存在，直接從內存里調導cpu去
什么都沒跑過的，什么都要從磁盤里面去拉，內存和磁盤速度相差幾千幾萬倍的差別，性能之前需要熱機
1：磁盤用戶調入內存 2：讓內存接近現實場景，更加精准
熱機：jemeter先洪一洪，洪一段時間然后再開始算響應的時間，jemeter跑一跑再算時間，前面熱機的時間不要算時間
盡量讓用戶都進去，跑半個小時之后再計算性能的響應時間，tps，資源使用率，系統進入穩定期才開始計算
8：測試下這個web系統的性能，看能支持多少並發
在確定並發用戶數之前，必須先對用戶的業務進行分析，分析出其中的典形業務場景（用戶最常見的，最關注的業務操作），然后基於場景獲得其並發用戶數
常見場景：訪問網站首頁，登錄功能，核心業務功能，個人中心
9：jemeter性能測試工具簡介
多線程框架，
進程：啟動jemeter是一個java進程
線程：java並發去創建用戶數，這個用戶數就是java進程里面的線程
多線程框架：jemeter里面可以創建很多線程數（用戶數）
對服務器的模擬負載：
性能測試兩個級別，用戶線程級別的，用戶進程級別的，行業用的比較多的都是線程級別的
jemeter可以模擬很多線程，一個線程就是一個用戶數，然后去壓測服務器，對服務器進行模擬負載的測試
模擬一千個用戶在線：通過jemeter可以實現
支持各種服務器的性能測試：
web的，數據庫，FTP的各式各樣的都可以，可以專門測試某些接口，也可以測試對應的這個數據庫都可以
開源，存java，可二次定制化開發
jemeter發tcp協議的時候，發現自帶的tcp取樣器有時候結尾是uf結尾的，有時候協議不太支持，這時候需要進行二次開發
10：jemeter運行環境搭建
jemeter下載好電腦有java環境就ok了
工具一般不用最新的，除非需求新工具的新需求，
jdk：一般是帶開發小組件的，可以開發程序的工具包
jre：java運行時環境，如果只運行java程序要jre就行，不需要jdk
jvm：java虛擬機
jmeter.bat windows批處理文件，jmeter在windows環境運行的按鈕，雙擊就可以啟動
jmeter.log jemeter日志文件，跑的東西都在這里面記錄下來
jmeter.properties jemeter屬性文件，很多屬性在里面設置
jmeter.sh .sh表示linux服務器啟動的執行文件
jmeter-server 啟動單台jmeter在windows里面jmeter.ba這個就可以啟動單台，如果通過分布式去做的話需要jmeter-server使用這個
分布式：一台電腦能承受多少用戶數
每一條機器能創建多少個用戶數：
內存（物理內存32g）
jmeter本身是一個java進程，進程需要消耗一定的內存資源（堆內存）
所以一台機器能虛擬多少用戶數，一個是本機物理內存多大，另一個是給jmeter這個進程多大的堆內存
端口號：端口號分配不均，不合理也達不到很好的發揮
所以很多時候虛擬5000個用戶機器牛逼就行了，還需要多台機器做分布式，
主機下面很多從機
如果需要虛擬4000個用戶，找四台機器，主機下面四台從機，每個從機都是1000，主從的方式實現分布式
正常性能測試一台機器搞不定的，
分布式：負載均衡，用戶負載，找幾個哥們分擔用戶數
jmeter是java進程，每個進程會消耗一定的內存，所以打開jmeter的時候有個默認的堆內存，堆內存是提供java進行使用的內存空間
jmeter環境設置：
jmeter home和path路徑
dos運行命令：里面有個path路徑，輸入jmeter的時候會到每個path路徑去找，有沒有這個命令，有就能運行，沒有就會提示不內部或者外部指令
找環境變量
用戶變量：a用戶設置的變量b用戶使用不了了，一般設置系統變量
系統變量：
gui：帶窗口的界面化模式，gui模式，jmeter一般不使用gui模式去做負載測試，因為gui會消耗一定的資源
windows和linux系統的差別：gui模式會有很多資源處理頁面的一些操作，會消耗很多性能資源的，性能下降
這就是為什么設設置path路徑使用命令行模式
HEAP：堆， jmeter配置了堆之后cmd顯示得還是不會改 ，顯示得時候寫死了，設置8g顯示還是256m，正常設置是生效得
這個只是個提示
11：jmeter工具的使用
文件
新建
模板：其他請求的模板（不太知道的接口不知道怎么寫，里面對着寫就行）
編輯
啟用：某些原件本次測試不需要，右鍵禁用就可以，禁用后選項不起作用了
禁用：
運行：
遠程啟動：遠程啟動兩台機器，多台機器，其他機器來跑也是可以的，腳本自己會同步的，不需要傳，只要自己關聯好
主機控制從機去運行（分布式）
參數化：怎么做，文件怎么放，放到那里去，復制幾份，內容怎么分盤，放哪個目錄，不同版本目錄要求不一樣
選項
一些皮膚外觀或者語言的設置，放大縮小
語言設置目前是臨時設置，如果想永久生效需要修改jmeter.properties的37行，保持重啟jmeter
下面還有一些分布式的設置也在jmeter.properties里，如下
Tools工具
創建html_report報告：
聚合報告的查看：聚合報告匯總的一個窗口信息
libei：請求的名稱
樣本：請求個數
平均值——最大值：響應時間，單位ms
異常：錯誤率
吞吐量TPS：單位時間內系統處理用戶的請求數，單位時間，比如1個小時，系統讓1w個人正常訪問
接收：
發送：
12：jmeter生成html報告
一：點擊html_report
二：通過下面的頁面使用csv文件生成報告
1：Results file：結果文件，兩種格式，csv，grl都是數據文件，選擇瀏覽，選中桌面的csv文件即可
2：user.preperfiles file：用戶的屬性文件，很多設置都在屬性文件設置的，不同的屬性文件代表jmeter配置不一樣的
找到jmeter文件——>bin——>jmeter.properties
3：output directory：導出的html報告放在哪里，可以放在一個html_report的空目錄去
4：generate report：點擊生成報告，生成html頁面，多少錯誤率，多少數據都能記錄
13：線程組，setup和teardown的區別
線程組：普通的線程組，正常運行的，初始化
setup：無論怎么放都是第一個運行的，與位置無關
teardown：無論怎么放都是最后與一個運行的，退出恢復的，環境清除
14：jmeter性能測試腳本開發
一：什么是jmeter腳本
俗稱：用戶操作被測軟件系統某場景的動作流程
jmeter：用戶操作被測軟件系統某場景的請求
性能前功能肯定ok的，功能測試和性能測試最大的差別：功能一個用戶就可以了，功能實現就ok了
性能測試需要n個用戶，n個用戶取決場景的需求，需要多少用戶
用戶從1到n的區別
被測項目的性能測試，模擬用戶量，並發數，不止一個用戶，n個用戶操作需要一個劇本，
腳本就是用戶操作被測系統某些場景的動作流程，讓用戶干什么
jmeter操作的流程翻譯成jmeter能識別執行的對應的腳本
性能測試腳本流程 ：
1：找到測試哪個場景，
2：場景如何去做，步驟
3：開發對應的腳本
腳本開發一開始都是用一個用戶去跑，一個用戶沒有問題根據需求去並發n個用戶去做性能測試，通了再說
二：快速開發漂亮的腳本
准確：最基本要求，腳本可以正常運行，只是能通
快速：借助技術手動快速高效完成腳本開發
漂亮：腳本邏輯，維護性高
整個性能測試重點是性能的監控分析調優
三：開發腳本方案
1："代理"劍
最合適的腳本方案：文檔+fiddler抓包，最快速靠譜的，
通過jmeter代理錄制的，這個腳本的錄制腳本很亂，都是需要調試的，工作量也很大
jmeter有個代理服務器的原件，抓包工具和工具自帶的錄制都是代理的
代理在pc和server中間加個中轉站，通過代理轉發http請求，請求和響應都會在代理服務器全部捕獲到
fiddler和jmeter的代理錄制的方式都是一模一樣的，所有錄制都是輔助腳本開發的，
15：jmeter腳本的保存
保存之后就有對應的工程了，
2：創建線程組，腳本在線程組使用，錄制的地方放在這個里面去的
3：設置一個代理，jmeter本身有代理的，點擊一下右鍵增加非測試元件，選擇http代理服務器
如下：
目標控制器就是腳本放在什么地方的：選擇測試計划>線程組
global settings：代理服務器的端口號，瀏覽器訪問的時候就需要經過這個代理了，pc瀏覽器也需要設置包經過代理
pc瀏覽器設置手動代理，讓他去訪問這個代理服務器，抓取對應數據，保存到腳本
瀏覽器設置代理服務器如下
127.0.0.1 8888 然后點擊保存
瀏覽器設置了代理我們的web端現在是訪問不了服務器的，因為jmeter的代理沒開，需要點擊啟動打開一下
然后啟動jmeter的代理服務器，代理就是jemert本身，點擊一下上面圖片的啟動按鈕，現在就可以進行抓包了
現在jmeter錄制的腳本很粗糙，里面很多靜態資源，圖片的，js的，增加一個排除模模式
先過濾掉這四個，都是常用的，還有js也可以過濾
現在過濾一部分請求了可以少抓很多請求了，過濾，不過濾太麻煩了
上面就是代理服務器的錄制方法：兩大步
1：瀏覽器代理的設置
2：jmeter代理的設置
16：badboy錄制腳本
現在很少用了，已經不更新了，也能錄制腳本
17：fiddler進行腳本錄制（把抓包的會話轉成jmx文件）
fiddler原理：正向代理，打開fiddler自己打開代理，關閉的時候自己關閉代理
fiddler抓包后——>file——>export sessions——>all Sessions——>導出一個jmx文件
jmx文件直接拖到jmeter里面就行
19：文檔+fiddler開發腳本是最快的，實在不會寫還可以借助錄制的腳本對比一下，看錄制本身怎么構建請求的
文檔為主還是必須的
20：token腳本實戰
任何腳本里面都需要創建一個線程組，線程組里有用戶數，
一百個客戶，五百個客戶都是在線程數里面設置的，開發前期都選擇一，搞通了再往下
一：線程里面增加一個什么協議的，比如取樣器選擇對應的哪個就行了 如下
選擇http請求，然后在頁面修改一下接口名稱，添加注釋
然后一下基本信息按照接口文檔填寫：ip地址，端口號，請求方式，路徑，編碼（看請求，如果有中文加utf-8就可以了，沒有就不要寫）如下
接口名稱，協議，ip、地址，端口號，方式，路徑必須填寫
參數：一般表單形式比較多，變量等於值這種類型
消息體數據：一般放json格式的，或者xml格式的，也可以放表單（a=1&c=2）
文件上傳：文件上傳的接口里面需要放到，比如文件路徑，文件名稱，文件格式
二 最后記得寫一下請求頭，很多時候默認版本不一樣的，寫一下：
名稱：Content-Type 值：application/json 寫在請求頭里面
http請求頭的添加需要配置原件：如下 線 程組右擊鼠標
找到http信息頭管理器，整個jmeter有個很關鍵的東西：作用域：
消息頭管理器放在整個線程組里面表示整個線程組所有請求都是共享它的，
所有如果不想在整個線程組生效，只是單個接口生效，把針對這個請求的請求頭拖拽到get_token這個請求里面就行了
現在消息頭管理器就到接口里面去了，作用域變了，只對這個請求有作用 重點
操作如下：
基本請求和頭寫好了后，還需要一個監聽的 如下：
三：增加監聽器
添加查看結果樹后點run一下，請求就成功了，很簡單
現在就能成功看到響應結果，這個接口就完成了，單個接口ok
還可以切換格式查看請求結果
如果想把參數提取出來：輸入 $.token test一下就可以了
把這個值復制給一個變量，以后所有的接口都可以使用這個變量了，token共享了，關聯接口，其他接口都需要這個令牌直接使用這個變量，參數化來做，
用的時候把變量放到頭里面，這樣就行了
后續響應數據是json的不要用正則，$.token 這個更簡單，錯不了，很清晰（json提取器）
后續接口需要用到這個接口的token的，關聯技術，獲取token復制給變量就可以使用了，
增加一個后置處理器，json提取器
21：性能測試規范流程
場景提取
腳本開發
場景設計
場景執行
監控分析
調優
回歸
22:jmeter主要元件的講解
配置元件
監聽器元件
其他常用元件
什么場景需要什么元件get到
23：配置元件 config
http請求默認值：
http消息頭管理器：
http cookies管理器：
http cache管理器：緩存
一：請求默認值
1：保存一個測試計划：類似工程一樣的東西，計划不要放在bin里面，千萬謹記：如下保存，這是一個工程，保存完成之后是一個測試計划
2：有了測試計划后增加一個線程組，本身性能測試就是多組賬戶和用戶的，並發數,線程數就代表用戶數
本身jmeter是多線程的，Ld有個多線程模式
3:線程組增加好了之后增加一個請求叫 取樣器，增加http請求
80：http默認端口
8080：tomcat默認端口
8888：一般是代理服務器用的端口號
443：https的默認端口
4:填寫http接口請求信息：參數和消息體數據和文件上傳三個是互鎖的，只能填寫一個
參數填寫表單，消息體數據寫json，xml，表單都可以
5：使用查看結果樹查看結果是否成功
監聽器就是查看結果的，通過查看結果樹的響應查看結果
前期調試使用一個線程組，腳本正確再考慮並發，腳本通了才行
返回綠色的不代表成功，只是說明有返回，需要看請求和響應數據是不是正常
6:需要增加一個http——>配置元件——>http信息頭管理器
這個元件是有作用域的，如果放在線程組下面會對線程組所有的請求都是共享的
如果只是單個接口是有拖到登錄接口里面去，改變作用域
填寫消息頭是個表單形式
7：請求頭還需添加cookie cookie是通過一個請求獲取的，
登錄接口第一次直接訪問不得行的，需要前面加一個訪問首頁獲取cookie的請求
訪問首頁接口可以獲取cookie值。訪問首頁不需要頭，可以刪了
要注意順序寫：請求cookie接口在前面就寫前面執行，登錄接口就寫在后面執行的
請求在前先執行的，請求在后后執行的，jmeter默認順序從上至下依次運行的
訪問首頁放前面，獲取到cookie值，然后cookie傳到登錄接口就可以了
接口需要帶cookie，所有需要一個前置獲取cookie的操作，把兩個請求關聯
可以把訪問首頁的sessionid值拿出來再組裝，用正則表達式提取sessionid值組裝到請求頭里面
jmeter為了方便自己提供了cookie管理器，希望訪問首頁的cookie值能給登錄接口來用
選擇組里增加配置元件：http cookie管理器，放前面去 這樣就不需要提取
這個管理器自己會幫忙管理cookie，自動關聯的，這樣請求就有cookie值了
利用好jmeter自帶的元件，讓測試變得更加便捷
一個項目很多接口，協議一樣的，ip地址一樣的，端口號一樣的，測試環境
測試環境：
預生產環境：
生產環境：
性能測試這個ip地址是測試環境的ip地址，如果腳本想放到預生產環境測試，端口號和ip都需要修改 ----參數設置成默認的
8：http請求默認值，把我們的一些參數全部填上去就可以了
請求默認值：所有的線程組下面的請求都會利用默認值，以后增加的請求一些內容就不用寫了，只要寫請求方法和請求路徑就可以了方便
所以以后項目環境改變了只要改http請求默認值就可以實現 整體修改：類似配置全局參數
9：http請求cache緩存，緩存用的不太多
瀏覽器有緩存的，項目改了東西，頁面修改了一些東西，很多靜態資源不是從服務器獲取的，靜態資源里拿，拿的是以往老版本的數據
所以需要清緩存，-----jmeter cache管理器也是做這個事情的
24：監聽器元件
一：查看結果樹
1：分析查看具體某一個請求的詳情：請求頭，請求體，響應頭，響應體
2：性能場景的時候分析錯誤的請求的原因
分析某個請求的內容，
做高並發跑場景的時候幾十個幾萬個請求：幾萬個請求查看結果樹里面的信息會一直拼命的刷新
有錯誤率也一般找不到，正確一般不看，腳本通的，需要看一下為什么報錯，勾選 僅錯誤日志
就可以了，這時候只顯示錯誤的，成功不顯示，不勾選這玩意根本看到錯誤率
勾選了正確不顯示一個，一旦錯誤就有了
二：接口請求還能增加斷言 使用響應斷言
這是根據響應文本進行斷言的，斷言成功綠色，斷言失敗紅色，如果查看結果勾選了 僅錯誤日志，就只會顯示斷言失敗的
僅僅顯示錯誤的，正常的不顯示，幾萬個請求，跑一個場景半個小時，如果不僅錯誤日志這么設置，如果有錯誤率那么就看不到為什么錯誤了
只能看日志，可以查看為什么斷言失敗，都正確的一個都不顯示，場景腳本都通的，不用看正確的，看錯誤是為什么發生的
三：聚合報告
匯總統計的結果：里面包含
請求數，響應時間（平均的，百分之90的，百分之95的，百分之99的，最大max，最小min）單位是ms毫秒
錯誤率：越低越好，
吞吐量：TPS 越高越好
發送/接收---帶寬
上面就是聚合報告，兩個請求的一些數據，
四：表格查看結果
請求什么時候發的什么時候結束的，中間間隔多少時間里面是有的，這個更細
表格查看結果如上：會顯示請求什么時候發的，可能沒有聚合報告那么細，但是帶時間的，詳情都會有，
五：圖形結果
一般發一個請求查看圖形界面沒什么意義，發很多請求會由一個曲線圖，每個線表示什么意思
如果請求失敗了，想分析請求為什么失敗用 察看結果樹
如果想查詢性能跑了半個小時想查詢整體性能的概要，概述 聚合報告
如果想看整個場景，做了一些定制器，想看請求到底什么時候起的，怎么規划請求發送的 查看表格結果
整體效果看曲線圖 圖形結果
根據具體場景選擇
25：其他常用的元件
斷言不能放線程組里面去：jmeter很嚴格的作用域的問題，如果作用域放錯了就全局gg，
斷言放整個線程組里面會對整個線程組所有的請求都起效果，謹記相對哪個請求做斷言，把斷言拽到某個請求的里面去
作用域的問題，不能亂放
一：前置處理器 以請求作為分界線
請求發之前執行的控制器（元件） 比如：加密（md5），
如上:選擇最后的Bean shell預處理程序，放在請求里面，這里面會順序執行的，請求發之前處理，做一些加密
二：后置處理器
請求發之后得到響應執行的控制器（元件）比如：正則表達式，json表達式提取數據
三：定時器
1：固定定時器 slepp，思考時間 jmeter本身請求時間是沒有延時的，發請求只會立馬發，不等，實際工作人去操作項目會有延時
有等待，先等，等會再點，服務器不管你干嘛，只要是兩個請求之間間隔一段時間就人為這是思考，休息時間
模擬用戶習慣加一個思考時間（固定定時器）
2：同步定時器 集合點 很多商城，三折，五折，告訴你9點開始活動，用戶聚集在這一塊，這時候就是集合點，把人按照一定條件集合在一塊
然后到底一定時間或者條件的時候把這個阻礙器拉掉，高並發過去同時訪問----嚴格的並發（比如秒殺操作）
3：隨機定時器 隨機點 定時器的時間是隨機的，
4：吞吐量定時器 分流的效果
項目中一些常用的元件
線程上的延時和集合點上的延時不一樣： 線程上的延時指的是整個性能組啟動前的延時，集合點是在性能里面的
線程組延遲多少時間啟動 集合點：在整個線程組里面的對於請求而已的
26：jmeter參數化技術實戰
參數化，數據驅動
一：什么時候需要參數化技術
某一個接口用一組參數去，
登錄：單點，多點
單點：一個賬戶登錄，這個賬戶再登前面的賬戶會被頂號 前面賬戶outline掉線，
這種接口做性能測試不能使用一個a賬戶，那么只有一個能成功，其他都會失敗 ---一定需要參數化
很多接口里面，假如增加用戶的接口，手機號碼唯一的，每新增一個賬號，這個接口手機號碼必須唯一，這時候一組手機號碼做性能測試不行
手機號碼需要采取參數化技術，
多點：可以不做參時化，但是最好最一下模擬真實環境
二：參數化技術是什么
寫好一個腳本跑通了，里面的數據不是寫死的
參數化是自動化測試腳本的一種常用技巧
簡單來說，參數化的一般用法就是將腳本中的某些輸入使用參數來代替，在腳本運行時指定參數的取值范圍和規則
比如下面獲取token的接口，賬號密碼寫死的，意味着如果並發100個用戶，100個用戶都是用這組數據
可以理解成常量的概念，寫死的 采取參數化常量不能使用一個數據需要使用變量
三：參數化的流程：
1：先找出需要做參數化的數據
2：准備提供給參數化需要數據源
3：腳本里的常量——>變量(使用前面的數據源數據)
四：jmeter參數化方式
1：csv方式--需要配置元件的 config
使用場景：賬號密碼，
token有時效：1：固定使用一個月（固定時間），不管用不用到期就干掉
2：從不用的時候開始一計算段時間
一：找出需要參數化的數據 賬號+密碼
二：准備參數化需要數據源 數據賬號密碼要有效的，不要亂編寫
三：數據源和腳本里面的常量替換成變量
jmeter和文件打交道需要一個元件配置——>添加——>配置元件——csv配置元件設置
作用域參數化只對一個請求有效放請求里面去
參數化對整個線程組有效放在線程組里面去
對整個測試計划放在測試計划下面
作用域很重要
文件名稱（需要些路徑），如果分布式多機，jmx腳本文件寫成固定的g盤的某個目錄，
腳本給別人用，不一定跑的起來，可能沒g盤，有時候運行jmeter沒有任何反應，很可能腳本問題，路徑的問題可能出現這種場景
做項目的時候配置文件最好放在jmeter目錄的bin文件，這樣誰使用腳本就可以跑，
文件編碼：utf8
變量名稱：現在配置文件式兩列的，csv式格式統層，數據中間用英文逗號,隔開，一列式username，二列password
忽略首行，csv文件可能首行式列名，不起作用這時候噶False改成True就行了，不存在列名，第一列就可以使用的使用False就可以
分隔符：英文逗號 ,
是否允許引號：False
遇到文件結束符再次循環：True
遇到文件停止符停止線程：False
線程共享模式：當前線程組，不對外有用 如下：
每個參數需要了解，現在把數據源文件通過jmeter元件數據導入進來，接下來需要把變量用起來，腳本里的常量——>變量
參數里面填寫變量需要使用${}這樣來寫
如果想跑五個或者多個在線程組里面設置 :如下
線程數5，1s起一個就五個賬號密碼去請求
2：函數式 很多簡單的不需要使用外置文件，
參數化數據可能不需要自己搞定：訂單號，編碼號，可以借助函數來搞定
隨機數
time時間函數：時間戳，默認ms 13位數據
計數器counter
如上，把get_token獲取的值提取出來給新增用戶接口使用，否則新增不了課程，兩個接口做關聯，用關聯關聯起來
json表達式可以使用json語法提取 如下：
響應式一個json格式使用json表達式語法，不需要那么復雜，
把：Result[0]=eyJhbGciOiJIUzI1NiJ9.eyJqdGkiOiJKMjAxOTAzMDcwMDU4Iiwic3ViIjoiSjIwMTkwMzA3MDA
1OCIsImlhdCI6MTYxNjAwOTY0Mn0.luaI9-MA-DnLPIsR-8vdSOMH2X2vBrJ_tG5hZroItPQ
這個數據存儲到變量里面去，這個變量給到新增接口的請求頭就完成工作了 -----思路 使用后置處理器
前置后置對請求而言的，前置是請求前處理的，后置是請求發之后處理的，用后置處理器
$：根目錄 .表示調用關系
現在添加一個debug調試器 如下：查看token的值
所以現在getToken變量是有值顯示的 下面還顯示賬號密碼 debug調試器相當於編碼里面的debug模式
現在取值到getToken變量變量了需要和接口關聯，放在下面的請求的消息頭管理器里面
按照接口文檔加上token頭參數就能實現 如下
現在又出現客戶必須為中文，新增用戶接口里面參數有中文，需要加個內容編碼utf-8
現在請求就沒問題了 -----前期腳本調試的階段，腳本的參數化和相互關聯
問題解決
1："msg": "TOKEN值為空", 解決方案：請求頭里增加一個token的
2："message": "客戶姓名必須為中文??" 解決方案：設置請求編碼為utf-8
3：該客戶手機已經存在 解決方案：對手機號碼必須參數化，
搞個csv文件沒有必要，可以搞一些隨機號和時間戳來，如下
打開函數助手，打開隨機數函數，生成后復雜到請求里面就行
在這里之間符號替換就可以了，123+一個八位隨機數
現在再請求新增用戶就成功了 手機號碼操作的時候需要符號后代校驗 ---簡單的編碼類random
3：變量操作
內置變量
全局變量
測試環境好幾個，沙箱，測試環境，預生產環境不一樣 可以設置ip地址：
測試計划——>配置元件——>用戶自定義變量 如下：
設置好了后就可以在每個請求使用$ 符號調用變量，使用ip地址，以后便於維護，修改用戶自定義變量就行了
嚴格注意一下元件的作用域
腳本調試ok的化調試取樣器后期可以禁用了，本身調試使用的，
4：編程式
一：引入外部的jar包，java class
二：使用beanshell編程
高級部分
一些數據不好生成采取編程方式，編程方式看開發提供什么格式，一般來說提供jar包比較多
開發寫好一段加密的算法類的，數據的產生數據環境的東西都可以寫在jar包里面的，jar包直接導入進來
會使用編程語言beanshell，beanshell和java很像，自定義變量
最牛皮的jmeter可以修改源代碼，可以定制化里面的東西
27：jmeter關聯技術
一：關聯描述
二：關聯的作用 對上一個請求做數據提取，兩個請求的關聯 關聯的核心是提取數據
關聯核心是提取
斷言重點是對比
token：賬號密碼進行一個算法，生成一大串字符串
三：jmeter中的關聯
請求之間數據的傳遞
jmeter使用正則表達式提取器提取響應中的特點內容
還有一些json提取器
四：正則表達式 .*?
（） 括起來的部分就是要提取的
. 匹配任意字符串
+ 一次或者多次
？ 放量詞后面表示非貪婪模式，找到第一個匹配項后停止
正則表達式提取多個字符串，有幾個就寫幾個
MYREF什么都不寫表示提取的內容，寫 g0表示全部，g1表示第一個，g2表示第二個
五：使用場景
第二個請求參數中需要加入第一個請求的返回值時
通過正則提取器可以提取第一個請求返回值中指定的字段信息並復制，在第二個
六：創建的時候是使用后置處理器
等請求完成之后再做提取
28：正則表達式提取器實戰操作