1.什么是性能測試
1.什么是性能


就像這兩個車一樣,雖然都是代步工具,構造都是一樣的,但是路虎的發動機要比捷達好.路虎的百米加速卻是比捷達快的,我們就知道路虎的性能要比捷達好?.
那么什么是軟件的性能呢?我們分析一下
2.常見的性能測試指標
2.1并發數
并發數是指在同一時間點上,系統能夠同時處理的請求或任務的數量.比如:"雙十一電商大戰".此時各大電商平臺在某一時間段突然涌入大量的用戶,下單商品.如果系統承受不住高并發的壓力,就會掛掉.
2.2 吞吐量
單位時間內處理的并發數,直接體現軟件系統負載承受能?。吞吐量越?,系統承受的并發越
多,性能越好。
吞吐量反映了系統在一定時間內完成工作的能力。例如,在網絡通信中,吞吐量可以表示為單位時間內成功傳輸的數據量
2.3 響應時間
應?系統從請求發出開始,到客?端接收到最后?個字節數據所消耗的時間。
響應時間反映了系統對請求的處理速度。在不同的應用場景中,響應時間的具體含義和重要性有所不同。例如,在網頁瀏覽中,響應時間是指從用戶點擊鏈接或提交表單到瀏覽器接收到完整頁面內容并顯示出來的時間。對于在線交易系統,響應時間則是從用戶提交交易請求到系統返回交易結果的時間
2.4 并發數,吞吐量,響應時間的關系

當并發??較少,系統吞吐量低,系統響應時間較短,我們認為系統處于空閑區間。隨著系統并發??增加,系統吞吐量開始呈線性增?,系統性能進?了線性增?區間。 吞吐量在某個點上達到了飽和點,也稱之為拐點。在這之后??請求不再被?即處理,響應時間隨之 變?,吞吐量也逐漸降低,系統性能進?了過飽和區間。
2.5 事務
?個接?可以是?個事務,多個接?也可以是事務,?個流程可以是事務,事務代表?個完整的功
能。用戶登錄接口我們就視為一個事務.而我們的下單事務,可能包含多個接口,比如商品下單,支付信息等,包含很多接口,我們把這個也稱為一個事務.銀行轉賬系統中,從一個賬戶扣除一定金額并將其添加到另一個賬戶的操作就是一個事務。
TPS和QPS
TPS:每秒處理事務數,?于衡量系統在?定時間內能夠處理的事務數
QPS:每秒查詢率.是用于衡量系統每秒能夠處理的查詢請求數量的指標,常用于評估數據庫、搜索引擎、Web 服務器等系統的性能。
資源利用率
觀察CPU,內存,硬盤的使用信息
3.性能測試分類
3.1基準測試
基準測試(Benchmark Testing)?稱單??測試,主要?于監測被測系統在較低壓?下的運?狀
況并記錄相關數據。當性能測試環境確定以后,通常選取業務模型中的重要業務做基準測試,對
被測系統施加?定壓?,從?獲取被測系統在單??運?情況下的各項性能指標,為多??并發
測試和混合場景測試等提供參考依據
3.2并發測試
并發測試(Concurrency Testing)?于評估被測系統的某些特定操作同時發?時的性能表現,例
如,被測系統被多個??同時登錄時的響應能?,或系統的某?功能被多個??同時操作時的性
能表現。
3.3負載測試
負載測試是通過逐步加載的?式來確定系統的處理能?。負載測試
類似于舉重運動,通過不斷給運動員增加重量,確定運動員在其?體狀況保持正常的情況下所能
舉起的最?重量。通過負載測試可以獲取系統能夠達到的峰值指標。
例如,?個軟件系統的響應時間要求不超過2秒,如果在這個前提下不斷增加??訪問量,系統
的響應時間就會變?。假設當訪問量超過1萬?時系統的響應時間超過2秒,那么就可以確定在系
統響應時間不超過2秒的前提下,系統的最?負載量是1萬?。負載測試可?于系統的性能驗證、
性能診斷和性能調優等場景
3.4壓力測試
進?壓?測試時通常采?逐步增加系統負載的?式,使系統某些資源達到飽和甚?失
效,從?發現那些只有在?負載條件下才會出現的缺陷,如同步問題、內存泄漏等。通過對被測
系統進?壓?測試,也能找出被測系統的性能拐點,獲得系統所能提供的最?服務級別(系統所
能承受的最?壓?),評估系統在峰值負載或超出最?負載情況下的處理能?。壓?測試主要?
于性能診斷、性能調優和容量規劃等場景
負載測試是在保持性能指標要求的前提下測試系統能夠承受的最?負
載,?壓?測試則是測試系統性能達到極限的狀態.
4.性能測試實戰
4.1安裝性能測試工具
1.性能測試工具我們這里使用jmeter.
Apache JMeter - Apache JMeter?
https://jmeter.apache.org/2.打開jmeter

3.每次打開都很費勁,所以我們添加環境變量在命令行打開


4.2操作 jmeter進行性能測試
4.2.1添加線程組
線程組就是模擬用戶發送請求
?

4.2.2添加請求

這一步就是構造訪問請求,接下來我們對登錄接口進行性能測試

構造完請求之后我們要觀察結果,所以加入"查看結果樹"

接下來我們運行觀察結果,我們看到返回的結果都是正確的

?4.2.3 重要組件
前面我們已經使用了線程組和HTTP請求組件,接下來我們介紹一些比較常用的組件
4.2.3.1 HTTP請求默認值
每次對一個接口進行性能測試都要在HTTP請求器中輸入IP,端口,十分麻煩.所以我們就可以使用HTTP請求默認值這個組件來將IP地址和端口號設置成默認值,這樣我們就不要每次發送請求的時候重復輸入了


設置好了之后后續我們構造HTTP請求器的時候就不用輸入了
4.2.3.2 CSV數據文件格式
以登陸接?為例,當我們執?登陸接?的性能測試時,?動配置了??名和密碼為固定的username和password,然?實際使?中不可能只有?個??登陸,為了模擬更真實的登錄環境,我們需要提供更多的??username和password來實現登錄操作
文件名: 填寫csv?件的路徑。建議使?絕對路徑。(創建一個excel表格,寫完數據之后存儲到本次創建的測試項目路徑下)
文件編碼:UTF-8
變量名稱( 從csv數據?件中讀起的數據需要保存到的變量名。有多個變量時?逗號分隔)
是否忽略??:是否從csv數據?件第??開始讀取
分隔符:要求與csv數據?件中多列的分隔符?致
遇到?件結束符再次循環:若選擇為True當數據不夠的時候會從頭取。若選擇False,則需要勾選
下?的配置,遇到?件結束符停?線程,這?如果不勾選,請求將會報錯。
1.創建csv文件

2.修改登陸接?及其他涉及到username和password獲取的參數

修改完該配置后,登陸接?發起請求時將從csv?件中獲取配置好的username和password參數,獲取順序為從上往下依次獲取
3. 修改線程組中線程數,使得每次取到的username和password都不?樣
4.運行結果
4.2.3.3 JSON提取器
在我們設計后端服務器代碼的時候,為了防止用戶跳過登錄,直接訪問我們的其他頁面,我們設置了攔截器,訪問頁面必須要攜帶token或者session.而只有在登錄的時候才會生成.我們通過url直接訪問頁面就會受到攔截.
但是在我們做性能測試的時候,都是對一個一個接口進行測試,不是完整的測試一個流程.所以其他的接口不會攜帶token或者session,所以返回的就是失敗.所以我們就要用到json提取器.將token從登錄返回的響應中提取出來,放到HTTP信息頭管理器中,其他的接口也就可以拿到token,進而可以訪問了



如何從登錄中獲取token,這里我們使用JSON提取(其實還有很多方法,這里就不一一列舉了)

4.2.3.4 JSON斷言
接口請求成功返回狀態碼200并不能完全代表接口請求成功,我們還要關注返回的數據是否符合預期
(1)添加斷言

針對某?個HTTP請求接?添加JSON斷?
(2).添加JSON斷言配置
注意:
1)若不選Additionally assert value,表?添加斷?值,則可?來判斷字段是否存在
2)選擇Additionally assert value,則必須添加Expected Value期望的斷?值
3)若不選Match as regular expression正則匹配,則Expected Value必須填寫完整,少?個字符都
會導致斷?失敗
4)若選擇Match as regular expression正則匹配,則Expected Value可以僅寫上部分關鍵詞即可斷
?成功
4.2.3.5 同步定時器

JMeter同步定時器的作?主要在于模擬多??并發訪問的場景,確保多個線程能夠同時執?某個操
作,以達到真正的并發效果。
當多個線程同時啟動時,它們可能會在不同的時間間隔內執?,這樣就?法達到真正的并發效果。同 步定時器的作?就是將這些線程的執?時間同步,使它們在同?時間點執?。它可以在多個線程之間 制造?定的延遲,直到同時到達指定時間點,再同時執?后續的操作。
此外,同步定時器可以理解為集合點,當線程數量達到指定值后,再?起釋放,可以瞬間產?很?的 壓?。這樣,可以更好地模擬真實的??并發訪問場景,提?測試的準確性和可靠性。
在性能測試過程中,為了真實模擬多個??同時進?操作以度量服務器的處理能?,可以使?同步定 時器來設置集合點。不過,雖然通過加?集合點可以約束請求同時發送,但不能確保請求同時到達服 務器,所以只能說是較真實模擬并發
現實?活中,紅綠燈就相當于?個集合點,有?先到達,有?后達到,但必須等到綠燈后所有?才能開始過??道。
4.2.3.6 事務控制器
Meter事務控制器的作?主要?于測試執?嵌套測試元素所花費的總時間。這相當于模擬??進??系列操作的測試。
在進???性能測試或API性能測試時,事務控制器是?個?常重要的?具。它可以幫助測試?員更準確地評估系統性能,尤其是在涉及多個接?或操作的復雜場景中。例如,在訂單提交的過程中,可能 需要調?多個接?,并且某些接?可能依賴于前?個接?的結果。在這種情況下,使?事務控制器可以將這些接?統?視為?個事務進?性能測試,從?得到更接近真實場景的性能測試結果
4.2.3壓力測試
4.2.3.1 安裝管理插件
Install :: JMeter-Plugins.org A custom set of plugins for Apache JMeter, not affiliated with Apache Software Foundation, graphs, load shapers, new functions.
https://jmeter-plugins.org/install/Install/下載監聽器插件

下載線程組插件

安裝完后

4.2.3.2?Stepping Thread Group(梯度壓測)


This group will start:啟動多少個線程,同線程組中的線程數
First, wait for:等待多少秒才開始壓測,?般默認為0
Then start:?開始有多少個線程數,?般默認為0
Next,add:下?次增加多少個線程數
threads every:當前運?多?時間后再次啟動線程,即每?次線程啟動完成之后的的持續時間;
using ramp-up:啟動線程的時間;若設置為5秒,表?每次啟動線程都持續5秒
thenhold loadfor:線程全部啟動完之后持續運?多?時間
finally,stop/threadsevery:多?時間釋放多少個線程;若設置為5個和1秒,表?持續負載結束之后
每1秒鐘釋放5個線程
4.2.3.3 監聽器
聚合報告


Response Times Over Time
Response Times Over Time的圖形展?中,橫坐標通常代表運?時間,?縱坐標則代表響應時間(單位是毫秒)。測試?員可以根據圖形中的趨勢線來判斷響應時間的穩定性以及是否存在?的波動。例如,如果響應時間在某個時間點突然增加,這可能意味著系統在該時間點遇到了性能問題。
Transactions per Second(TPS)
JMeter中的Transactions per Second(TPS)監聽器是?個?于分析系統吞吐量的重要?具。TPS
即每秒事務數,表??個客?機向服務器發送請求后服務器做出反應的過程。這個指標反映了系統在 同?時間內處理業務的最?能?。TPS值越?,說明系統的處理能?越強
在使?TPS監聽器時,橫坐標通常代表運?時間,?縱坐標則代表TPS值。通過監聽器展?的圖表,可 以清晰地看到TPS值隨時間的變化情況。在圖表中,紅?通常表?通過的TPS,?綠?可能表?失敗的TPS。這有助于我們快速識別系統性能的變化和瓶頸
4.2.4測試報告
JMeter測試報告是?個全??詳細的?檔,它提供了關于測試執?結果的詳細信息,幫助??全?評估系統的性能并進?性能優化。?成性能測試報告的命令
Jmeter -n -t 腳本?件 -l ?志?件 -e -o ?錄
-n : ?圖形化運?
-t : 被運?的腳本
-l : 將運?信息寫??志?件,后綴為 jtl 的?志?件
-e : ?成測試報告
-o : 指定報告輸出?錄
注意:?志?件和?錄可以不存在,若為已經存在的情況下需要保證內容為空,否則會出現錯誤!?


運行后:
