作用域: 指作用范圍(比如編程語言的變量),指當前組件對哪些范圍的取樣器生效
分類:
-
取樣器自身:
-
無所謂作用域，因為在作用域作為參考物存在的
-
-
以結果樹為代表的大多數組件:
-
測試計划下: 對所有取樣器生效
-
線程組下: 對當前線程組的取樣器生效
-
取樣器下: 對當前取樣器生效
-
-
以邏輯控制器為代表的部分組件:
-
只對子級取樣器生效
-
1.2執行順序
JMeter 中組件的執行順序與添加順序不一定有關系，JMeter 的組件有默認的執行順序
各元件之間的執行順
1) 配置元件(config elements) == HTTP信息頭管理器、HTTP請求默認值....（執行初始化數據）
2) 前置處理器(Pre-processors) == 用戶參數(封裝取樣器所需數據)
3) 定時器(timers) == synchronizing Timer、Constant Throughput Timer....(控制取樣器的執行規則)
4) 取樣器(Sampler) == HTTP請求、JDBC請求...(核心:向服務器發送請求)
5) 后置處理程序(Post-processors) == XPath、正則表達式提取器...(提取取樣器的執行結果)
6) 斷言(Assertions) == 響應斷言、大小斷言、斷言持續時間...(判斷響應結果)
7) 監聽器(Listeners) == 查看結果樹、聚合報告...(查看所有組件的最終運行結果)
口訣: 先兩頭，再核心，最后中間
1、制定測試計划,分配任務
| 任務名稱 | 任務描述 | 責任人 | 工期 | 開始日期 | 結束日期 | 進度 | 備注 |
|---|---|---|---|---|---|---|---|
| 環境搭建 | 安裝並運行學生管理系統 | 運維組葫蘆娃 | 1 | 01/01 | 01/02 | 進行中 | |
| 學院模塊接口測試 | 測試學院增刪改查接口 | 測試一組凹凸曼 | 3 | 01/02 | 01/05 | 未開始 | |
| 班級模塊接口測試 | 測試班級增刪改查接口 | 測試一組穿山甲 | 3 | 01/02 | 01/05 | 未開始 | |
| 學生模塊接口測試 | 測試學生增刪改查接口 | 測試二組哥斯拉 | 4 | 01/02 | 01/06 | 未開始 | . |
2、從 API 文檔中提取接口清單
-
API 文檔為了保證易讀性，說明性信息較多，導致測試過程中，API 文檔內容稍顯冗余
-
需要從 API 文檔提取測試必須的數據，摒棄冗余數據(提取結果: 接口清單)
3、設計測試用例並參數化覆蓋測試用例
4、編寫腳本實現，並導入設計的測試數據
核心知識點: 參數化之 CSV 數據文件設置
5、測試結果匯總，BUG提交
3.1 概念
3.項目實現之功能測試
功能測試: 所有接口逐一測試(覆蓋率 100%)，測試時需要模擬用戶的多樣性操作提交各種測試數據
3.2 實現
3.2.1 測試用例設計
1)、設計測試用例
測試用例的設計原則
1. 覆蓋所有的必選參數
2. 組合可選參數
3. 參數邊界值 = 征兵系統，年齡:[18-24],既要設計 18 又要設計 24，邊界值后端算法實現比較容易出問題
4. 越界的數據 = 征兵系統，年齡:[18-24],超出了區間取值的一些數據
5. 如果參數的取值范圍是枚舉變量，需要覆蓋所有枚舉值=性別既要測試男也要測試女排序既要測試正序又要測試倒序
枚舉值: 程序中的常量,比如性別、排序方式....
6. 空數據 = 字段錄入時是一些空格或無錄入
7. 包含特殊的字符 = 字段錄入時，使用了 #$%@.... 等特殊符號
8. 錯誤的數據 = 邏輯錯誤、格式錯誤...
2)、參數化覆蓋測試用例
-
使用 CSV文件存儲測試數據
-
測試數據設計時，參考測試用例
3.2.2 測試腳本編寫
知識點: 參數化 CSV 數據文件設置
-
編寫被復用的腳本
-
設計 CSV 文件存儲測試數據,注意:
-
路徑選擇，建議和腳本平級(保證腳本的可移植性)
-
編碼使用 UTF-8
-
-
添加中間件關聯腳本與數據
-
R = 讀取 CSV 文件
-
W = 將數據導入腳本
-
循環讀寫
-
3.2.3 測試報告生成
| 功能名稱 | 用例描述 | 預期結果 | 實際結果 | 是否BUG | 備注 |
|---|---|---|---|---|---|
| 學院新增 | dep_id有特殊字符 | 添加失敗 | 添加成功 | 是 | dep_id 左右兩側有空格，去除屬於合理操作 |
| 學院新增 | dep_id超長 | 添加失敗 | 添加成功 | 是 | . |
4.項目實現之自動化測試
4.1 概念
自動化測試: 程序驅動代替人工驅動實現的測試
4.2 作用
場景: 程序升級時，會實現自動化測試
舉例:
-
今日頭條程序升級,從版本 5.0 升級到版本 6.0
-
今日頭條添加新的功能實現
-
新增的功能(新接口)可能會影響原有的功能(接口)
上線之前，必須測試原有的接口是否能夠正常運行(使用自動化測試完成的)
4.3 實現
自動化測試原則:
1.只需測試重要的或被重復調用的接口(覆蓋率不必 100%)? 新增的接口影響有限
2.只需設計正向用例(只是測試接口是否能正常運行，之前已經實現了功能測試)
3.自動化腳本可以重復執行(功能測試腳本不能重復執行,重復執行前需要刪除數據庫)?怎么實現的重復執行?
4.一個線程組只設計一個取樣器(符合封裝的思想,解耦合)
....
自動化測試知識點分析:
-
參數化生成測試數據
-
使用斷言判斷響應結果
-
使用 tearDown 線程組執行最后的數據刪除操作,使用 setUp 新增數據
-
HTTP 請求默認值、用戶定義的變量
-
跨線程組關聯(重點) == setProperty 與 property 和 提取器
-
還可以通過直連數據庫獲取新增學院的 ID
PS: 自動化測試時建議順序 = 增改查刪,怎保證順序，保證改查的編寫順序，勾選獨立運行每個線程組
5.項目實現之性能測試
5.1 概念
性能測試: 模擬生產環境下的各種場景，向服務器施加負載，測試各項性能指標是否達標
-
場景: 並發、高頻率、區間多用戶.....
-
指標: 響應時間、錯誤率、吞吐量 .....
5.2 作用
1.技術選型
2.測試當前程序所能支持的最大負載
3.發現程序中性能瓶頸, 提高資源利用率
4.提升用戶體驗
.........
5.3 實現
5.3.1 設計原則(了解)
1.線程組：增刪改查每一個功能點，都需建立單獨線程組，而避免在同一個線程組內添加多個取樣器
一個線程組只設計一個取樣器(符合封裝的思想,解耦合)
2.參數化：參數化盡量避免采用從外部讀取參數(CSV 組件)，而是使用 前綴_函數 生成測試數據?
避免資源耗費,性能測試資源開銷本身就比較客觀，應該盡量杜絕一些無意義的資源占用
3.察看結果樹：必須清除單個接口內或線程組內的察看結果樹，建議一個測試計划就一個結果樹?
同上
4.報告：性能報告可根據實際需求選擇，建議保留添加 聚合報告?
可以對所有結果匯總並統計，結果顯示更為直觀(平均響應時間、錯誤率、吞吐量....)
5.分布式：如並發數量大，采用分布式測試
6.新增/刪除/修改：建議不要采用時間模式(定時器:常量吞吐定時器、同步定時器...)來壓測，直接使用線程數和循環
因為實際場景中，用戶操作最常用的是查。
5.3.2場景1:模擬半小時之內 1000 個用戶訪問服務器資源，要求平均響應時間在3000ms內，且錯誤率為0
區間多用戶
5.3.3場景2:模擬 100 個用戶同時訪問服務器資源，要求平均響應時間在3000ms內，且錯誤率為千分之五之內 (高並發)
同步定時器
5.3.4場景3:模擬2個用戶以20QPS的頻率訪問服務器資源持續10秒,要求平均響應時間在3000ms內,錯誤率為0(高頻率)
常量吞吐定時器
5.3.5 生成圖形化測試報告
在 JMeter 中可以以圖形化（餅狀圖、柱狀圖...）的方式顯示腳本運行結果，較之於聚合報告或查看結果樹組件實現更直觀，用戶體驗更友好
前提: 配置 PATH 環境變量
生成圖形化測試報告，命令:
Jmeter -n -t 腳本 -l 日志文件 -e -o 目錄
-n: 無圖形化運行
-t: 被執行的腳本
-l: 日志文件
-e: 生成測試報告
-o: 指定輸出目錄
PS:
保證日志文件為空或不存在
保證目錄為空或不存在