1. パフォーマンステストの理論
1.1 パフォーマンステストが必要なシステムはどのようなものですか?
- ユーザー数が多くPVも高いシステム
- システムコアモジュール/インターフェース
- ビジネスロジック/アルゴリズムが比較的複雑
- プロモーション・イベントプロモーション企画
- 新しいシステム、新しいプロジェクト
- オンラインパフォーマンスの問題の検証と調整
- 新技術の選択
- パフォーマンス容量の評価と計画 (容量評価の場合、特定の容量を見積もる)
- 日次のシステムパフォーマンスの低下
1.2 パフォーマンステストの指標
- 事務
- パフォーマンス テストの分野では、システムのパフォーマンスの測定は主に、システムが単位時間あたりにどれだけのビジネスを処理できるかによって決まります。
- トランザクションはビジネス操作を表し、トランザクションは 1 つのビジネスまたは複数のビジネス操作を表すことができます。
- TPS/QPS: 1 秒あたりに処理されるトランザクション数
- 反応時間
- 応答時間 = ネットワーク総伝送時間 + 各コンポーネントの業務処理時間
- 平均応答時間: テスト中にすべてのリクエストに費やされた平均時間。(追記: サンプル数が少ない場合、平均値を使ってデータを見ると異常な結論になります。例えば、あるインターフェースが 1ms で、別のインターフェースが 1s の場合、平均値は不合理です。)
- トップの応答時間
- Tp90 (90% の応答時間): リクエストの 90% が一定時間未満にかかる
- Tp95 (95% の応答時間): リクエストの 95% が一定時間未満にかかる
- Tp99 (99% の応答時間): リクエストの 99% が一定時間未満にかかる
- アルゴリズム: すべてのリクエストの応答時間を大きいものから小さいものまで並べ替え、リクエストの指定された割合が一定の時間未満であることを計算します。このメトリクスは、ほとんどのリクエストにかかる時間を測定します。
Tp90を例に挙げます
| インターフェース A が 10 回連続で応答する | シリアル番号を要求する | 応答時間ミリ秒 |
|---|---|---|
| 1 | 800 | |
| 2 | 600 | |
| 3 | 500 | |
| 4 | 900 | |
| 5 | 950 | |
| 6 | 750 | |
| 7 | 400 | |
| 8 | 500 | |
| 9 | 300 | |
| 10 | 500 |
ステップ 1: リストを降順に並べ替える
| インターフェース A が 10 回連続で応答する | シリアル番号を要求する | 応答時間ミリ秒 |
|---|---|---|
| 5 | 950 | |
| 4 | 900 | |
| 1 | 800 | |
| 6 | 750 | |
| 2 | 600 | |
| 3 | 500 | |
| 8 | 500 | |
| 10 | 500 | |
| 7 | 400 | |
| 9 | 300 |
90%*10=9、最後から 9 番目まではすべて 900ms 未満であるため、900ms が境界線として使用されます。
- 高周波数インターフェイスの一般的な応答時間は 200 ミリ秒、低周波数インターフェイスの一般的な応答時間は 100 ミリ秒です。高周波数インターフェイスは最適化する必要があります。静的リソースはテストする必要がなく、すべて CDN に保存されます。
- 同時実行数/仮想ユーザー: ストレス テスト ツールで設定された同時スレッド/プロセスの数
- 成功率: リクエストの成功率
- PV (ページビュー): ページ/インターフェースへの訪問数
- UV (ユニークビジター): ページ/インターフェースの毎日のユニークビジター
- スループット: ネットワーク内のアップストリーム トラフィックとダウンストリーム トラフィックの合計
- スループットはネットワークのトラフィックを表し、TPS (1 秒あたりのリクエスト数) が高いほどスループットも大きくなります。
1.2.1 TPS、応答時間、同時実行数の関係
- システムロードのパフォーマンスボトルネックの前では、TPS は同時実行数に比例します
- 応答時間（単位：秒）が前提となります。
- TPS = 1 / 応答時間 * 同時実行数
- TPS = 同時実行数/応答時間
- パフォーマンス テストを実行した後、その結果から TPS を計算することができ、値に大きな差がなければ、結果は適切であると考えられます。
- 複数のインターフェースが並行している場合は、各インターフェースの応答時間を追加する必要があります。
-
1.3 パフォーマンス監視指標
- オペレーティング システムの監視レベル
- CPU 使用率、メモリ使用率、ネットワーク IO (入力/出力)、ディスク (読み取り/書き込み/ユーティリティ)
- ミドルウェアの監視
- 接続数、長い接続と短い接続、メモリ使用量
- アプリケーション層の監視
- スレッドステータス、JVMパラメータ、GC頻度、ロック
- データベース層の監視
- 接続数、ロック、キャッシュ、メモリ、SQL効率
1.4 パフォーマンステストのプロセス
- 研究を依頼する
- 研究範囲
- プロジェクトの背景
- 試験範囲
- ビジネス ロジックとデータ フローの方向 (データ: データはどこから来たのか、キャッシュはあるのか、サードパーティのインターフェイスを呼び出すかどうか、これを理解することで問題のトラブルシューティングに役立ちます)
- システム アーキテクチャ (ロード バランシング、メッセージ ミドルウェア、ロード バランシングなど、使用されるデプロイされたアーキテクチャとコンポーネント)
- 構成情報 (CPU コアやメモリなどのハードウェア構成、一部の企業ではパフォーマンス テスト環境があり、オンラインとの一貫性を保つように努めます)
- テストデータの量 (大きさは一貫している必要があります)
- 外部依存関係 (モック)
- システム利用シナリオ、ビジネス比率（ログインおよび登録インターフェイスなど、実際のシナリオには必ず同時シナリオが存在します。ビジネス比率は、ログインする人数と同時に登録する人数として理解できます）
- 一日の取引量（PV）
- 期待される指標
- オンライン時間
- 研究範囲
- テスト計画
- プロジェクトの説明
- ビジネスモデルと業績指標（需要調査における期待指標）
- テスト環境の説明
- テストリソース
- テスト方法とシナリオ設計の原則
- ベンチマーク テスト: パフォーマンスのベンチマークを見つけるために、通常は一連の操作を同時に長時間実行します。つまり、インターフェイスを最適化した後のデータと最適化前のデータを比較することで、最適化の効果を確認できます。 ; ただし、パフォーマンスの変曲点を確認したい場合は、ストレス テストに高い同時実行性を使用する必要があります。
- 単一トランザクション負荷テスト (一般的に使用されます) : 単一ビジネスおよび単一インターフェースのテストを指します。
- 混合シナリオテスト（一般的に使用されます）：たとえば、ログインインターフェイスと登録インターフェイスでは、必ず最初に単一トランザクション負荷テストを実行して、各インターフェイスに問題がないことを確認してから、特定の比率（から取得）に従ってストレステストを実行します。需要調査）
- 高可用性テスト (通常はオンライン クラスター用)
- テスト方法: クラスター内のノードをハングアップして、クラスターが正常に実行できるかどうかを確認します。ノードの再起動後に、ハングしたノードを再度実行して、クラスターが正常に使用できるかどうかを確認します。
- 異常シナリオのテスト: たとえば、ネットワークが弱いシナリオでは、リクエストを送信すると、ネットワークが弱いにもかかわらず高い同時実行性が発生します。弱いネットワーク下でのトランザクションなどの異常な状況が発生し、インターフェイスが実行されません。特定のトリガーがトリガーされるため、初回はこのメカニズムを無効にし、インターフェイスを再実行すると、2 つのオーダーが生成される可能性があります。
- 安定性テスト（一般的に使用されます）：メモリリークなどの問題がないかどうかをテストするために、長時間（12時間など）の圧力テストが必要です
- その他の特別なシーン
- 環境設定ハードウェア構成
- 予防
- オンラインとの一貫性を保つよう努める
- システムバージョンはオンラインバージョンと一致しています
- テスト環境では最小のオンラインユニットモジュールを導入
- アプリケーション、ミドルウェア、データベースの構成はオンラインのものと一致している必要があります
- その他の特殊な構成
- 予防
- データの準備
- テストデータは、基本データ、パラメータ化されたデータに分類されます。
- データ構築方法：
- ビジネスインターフェース
- 複雑なデータテーブル関係に適しています
- 利点: データの整合性が向上
- ストアドプロシージャ
- 少数のテーブルとシンプルさに適しています
- 利点: 最速
- スクリプトのインポート
- 複雑なデータロジックに最適
- 比較的自由度が高い
- スクリプト作成
- ツールを選択します (Loadrunner、Jmeter、Locust など)。
- プロトコルの選択 (HTTP、TCP、RCP)
- パラメータ化する
- 協会
- チェックポイント
- ビジネス上の判断
- 圧力試験の実施
- 分散実行
- モニター
- Linux
- JVM
- データベース
- モバイルテストの結果
- データ分析
- ボトルネックの場所
- 回帰の調整
- パフォーマンスのチューニングはチーム全体で完了する必要があります
- 何度も試してください
- 回帰検証
- 監視ツール
- フルリンクのトラブルシューティング
- ログ分析
- モジュールの絶縁
- テストレポート
1.5 HTTPプロトコル
1.5.1 http の概要
1. クライアント/サーバー モードをサポートします。
2. シンプルかつ高速: クライアントがサーバーにサービスを要求する場合、要求メソッドとパスを送信するだけで済みます。一般的に使用されるリクエスト メソッドは、GET、POST、PUT、および DELETE です。各メソッドは、異なるタイプのクライアント/サーバー接続を指定します。
HTTPプロトコルがシンプルなため、HTTPサーバーのプログラムサイズが小さく、通信速度が非常に速いです。
3. 柔軟性: HTTP では、あらゆる種類のデータ オブジェクトの送信が可能です。転送されるタイプは Content-Type によってマークされます。
4. 接続なし: 接続なしの意味は、各接続が 1 つのリクエストのみを処理するように制限することです。サーバーがクライアントの要求の処理を完了し、クライアントの応答を受信すると、接続が切断されます。この方法により、送信時間が節約されます。
5. ステートレス: HTTP プロトコルはステートレス プロトコルです。ステートレスとは、プロトコルにトランザクション処理用のメモリ機能がないことを意味します。状態がないということは、後続の処理で以前の情報が必要な場合にその情報を再送信する必要があることを意味し、接続ごとに転送されるデータ量の増加につながる可能性があります。一方、サーバーが以前の情報を必要としない場合、サーバーの応答は速くなります。
1.5.2 http プロトコルの構造
チップ：
ストレステスト、負荷テスト、性能テストの概念の区別に関する質問
1. 上記 3 つの概念については、業界で統一された規格や定義はなく、さまざまな資料や説明が存在します
。 3.覚えておいてください
: 実行するすべてのテストはパフォーマンス テストになります。実際の企業では、それらは [ストレス テスト] と呼ばれます。 4.
最大同時ユーザー数をテストするのか、安定性をテストするのか、最高のテストをテストするのかについては、 tps、これらはすべてパフォーマンス テストであり、単なるテストです。目的が異なります。目的が異なり、異なるテスト シナリオに合わせて設計されているためです。
二、Jmeter
2.1 インストールと構成
公式 Web サイト: https://jmeter.apache.org/
1. このマシンで Java 環境変数を構成します。
2. 公式 Web サイトから圧縮パッケージをダウンロードし、任意のディレクトリに解凍します。
3. 構成ファイルを変更し、jmeter.properties を開きます。 Jmeterのbinディレクトリを変更します
language=zh_CN #中国語と英語環境の
sampleresult.default.encoding=utf-8 #文字化けを防ぐ
アイコンのサイズを調整する
jmeter.toolbar.icons.size=32x32
jmeter.tree.icons.size=32x32
メッセージ本文のデータサイズを変更する
jsyntaxtextarea.font.family= Hack
jsyntaxtextarea.font.size=36
インターフェイス要素のサイズを
true に変更して、
jmeter.hidpi.mode=true
でサイズを制御できるようにします
jmeter.hidpi.scale.factor=2.0
変更した設定が有効にならない場合は、jmeter.bat に次のコードを追加します。
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.controlFont=Dialog-20
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.systemFont=Dialog-20
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.userFont=SansSerif-20
set JVM_ARGS=%JVM_ARGS% -Dswing.plaf.metal.smallFont=SansSerif-20
4. Jmeterのbinディレクトリに入り、jmeter.batをダブルクリックして起動します。
2.2 スクリプト作成
2.2.1 入参
3種類の入力
| インターフェース名 | インターフェースの種類 | パラメータ |
|---|---|---|
| パラメータはキー=値です | 役職 | ユーザー名=”123”&パスワード=”123” |
| パラメータはjson型です | 役職 | {ユーザー名=“123”、パスワード=“123”} |
| パラメータはkey=json型です | 役職 | キー = {ユーザー名 = “123”、パスワード = “123”} |
2 番目のタイプ: json 型
[メッセージ本文データ] には、json 型の入力パラメーターが入力されます。メッセージ本文データにデータがある場合、[パラメーター] は操作できません。 注: パラメーターが json
型の場合、 http 情報は、管理のためにヘッダーを追加する必要があります。コンポーネントを構成するときは、構成コンポーネントの有効なドメインにも注意する必要があります。インターフェイスのすべての入力パラメータがこのタイプであるとは限りません。HTTP ヘッダー管理: PS: 415 エラーが発生し
た
場合と報告されている場合は、ヘッダーが追加されているかどうかを確認してください。
3つ目の方法：key=json型
便利な方法：下部の[クリップボードから追加]から直接貼り付けることができます
2.2.2 断言
結果ツリーに表示される成功ステータスは、インターフェース呼び出しが成功したこと(response code=200のため)のみで、業務が完了したかどうかは判断できないため、アサーションを追加する必要があります。
2.2.2.1 JSON アサーション
1.アサーションの追加：
JSONパス式：$.codeはJSONのコードフィールド名を表します（詳細参考：https://github.com/json-path/JsonPath）
さらにアサート値を確認する必要があり、正規表現として一致します
PS : アサーションは、アサーション ファイルの保存場所にも注意してください。ストレージ レベルが異なり、有効なドメインも異なります。たとえば、途中でログイン インターフェイスの下に保存された場合、アサーション ファイルが保存される場所でのみ有効になります。ログイン インターフェイス。最外層に配置すると、ドメイン全体に影響します。
2. json には配列が含まれており、次のように処理できます。
json の例:
{
"store": {
"book": [
{
"category": "reference",
"author": "Nigel Rees",
"title": "Sayings of the Century",
"price": 8.95
},
{
"category": "fiction",
"author": "Evelyn Waugh",
"title": "Sword of Honour",
"price": 12.99
},
{
"category": "fiction",
"author": "Herman Melville",
"title": "Moby Dick",
"isbn": "0-553-21311-3",
"price": 8.99
},
{
"category": "fiction",
"author": "J. R. R. Tolkien",
"title": "The Lord of the Rings",
"isbn": "0-395-19395-8",
"price": 22.99
}
],
"bicycle": {
"color": "red",
"price": 19.95
}
},
"expensive": 10
}
加工方法：
| JsonPath | 結果 |
|---|---|
| $.store.book[*].author | すべての本の著者 |
| $…著者 | すべての著者 |
| $.store.* | 本も自転車もすべて |
| $.store…価格 | あらゆるものの価格 |
| $…本[2] | 3冊目の本 |
| $…本[-2] | 最後から2番目の本 |
| $…本[0,1] | 最初の2冊 |
| $…本[:2] | インデックス 0 (これを含む) からインデックス 2 (これを除く) までのすべての書籍 |
| $…本[1:2] | インデックス 1 (含む) からインデックス 2 (含まない) までのすべての書籍 |
| $…本[-2:] | 最後の2冊 |
| $…本[2:] | インデックス 2 (両端を含む) から最後までのすべての書籍 |
| $…本[?(@.isbn)] | ISBN 番号のあるすべての書籍 |
| $.store.book[?(@.price < 10)] | 店内のすべての本が 10 冊より安い |
| 間違った@ |
$…本[?(@.price <= $['高価'])] | 店内にある「高くない」すべての本 |
| $…本[?(@.author =~ /.REES/i )] | 正規表現に一致するすべての書籍 (大文字と小文字は無視) |
| $… | すべてを私に与えてください |
| $…book.length() | 冊数 |
2.2.2.2 応答アサーション
応募先：
- メイン サンプルのみ: このアサーションはメイン リクエスト用です。
- main sample and sub-sample：该断言针对主、次请求，例如重定向的场景，可能会使用到该选项
测试字段：选择需要对哪个数据做判断
- 忽略状态：忽略jmeter默认的状态判断，来跑响应断言中对于状态的断言
响应断言模式匹配规则：
- 包括（Contains）：如果响应中包含了指定的字符串，判断为成功，支持正则表达式
- 匹配（Matches）：如果响应完全匹配指定的字符串，判断为成功，支持正则表达式
- 相等（Equals）：如果响应完全匹配指定的字符串，判断为成功，不支持正则表达式
- 字符串（Substring）：如果响应中包含了指定的字符串，判断为成功，不支持正则表达式
- 最常用的是字符串，性能测试只需要判断业务是否跑通，无需写过于复杂的断言
2.2.3 测试计划
定义全局变量，例如域名及端口号
接口中可通过${变量名称}配置
2.2.4 参数化
2.2.4.1 通过【函数助手】生成各种函数
功能位置：工具栏倒数第二个
常用的函数例如：
- 生成随机数：Random函数
输入完范围后，点击【生成】按钮，复制【当前JMeter变量】的语句，粘贴至【参数】的【值】中
- 随机字符串：RandomString
点击【生成】按钮后，${__RandomString(8,abcdefghijklmQ39589fsafdgAAA,)} 函数字符串会自动复制到剪切板
- 时间戳
两个参数皆为可选填，都不填也可，直接点击生成就可以直接用
填了参数
- uuid：
2.2.4.2 文件参数化
1、**CSVRead：**从文本文件中读取数据
优点：该函数适用于使用登录后，仍然需要用这些账号进行一系列操作的压测
第一个参数填文件的绝对路径，第二个参数填第几列，例如下图中：第一列是登录接口的用户名，第二列是密码
注意：接口轮询中使用txt文件中的用户数据数量，取决于线程数的数量
线程数=1时，无论循环次数为几，皆使用文件中的第一条用户数据
线程数=2时，调了两条txt中的用户数据
线程数=4时，重复调用了两遍文件中的两条数据
使用函数生成的参数来替换接口中的参数，如下图中的mobile、password字段
PS：存储函数的变量名
2、CSV Data Set Config
功能添加路径：线程组→添加→配置元件→CSV Data Set Config
- Allow quoted data（是否允许带引号）：选择true，读取中文时会导致参数值出现乱码
文件编码：可以不填
-
如果接口中的参数是用西文逗号隔开的（例如：“user”：“username，password”），那么txt数据就不可以再用逗号隔开,可以用【\t】代替，在txt中为用tab键隔开，也可以用别的符号隔开
| Recycle on EOF（遇到文件结束符再次循环？） | Stop thread onEOF（遇到文件结束符停止线程？） | 参数效果 |
| — | — | — |
| True | False | 重复 |
| False | True | 唯一 | -
参数效果=唯一 举例：txt有四条数据，线程数=2，循环次数=3，此时接口只会跑四次，取的txt中四条数据，第五条因需重头取，导致数据重复，所以不会继续运行
-
参数替换方式
注意：使用CSV Data Set Config读取数据，无论线程数与循环次数是几，每次查询都是查询下一条数据，若所有数据都读取了一遍，则会从头读取第二遍
线程数=1，循环次数=2时，会使用文件中的两条用户数据
假设txt中是四条用户数据，线程数=2，循环次数=2，在轮询时，会依次读取文件中的四条用户数据
2.2.5 线程组
线程数：假设有多少用户正在同时使用
多用户场景时，无需参考查看结果树中的接口顺序，其实是同时发生的
2.2.6 数据关联
2.2.6.1 方法一：后置处理器———JSON提取器
apply to：一般选main sample only （主请求）
Name of created values：对提取的变量起名
JSON Path expression：要提取的变量（用jsonpath写）
- 切记，如遇到数据在json中的数组下，记得指定取数组中的第几个，不然会取不出来数据
- 1、提取最深层某字段的其中一个数据：$.docGroups[0].documents[0].docId
{
"responseStatus": {
},
"docGroups": [
{
"documents": [
{
"docId": 38604724,
"startTime": 1673406999
},
{
"docId": 2,
"startTime": 1673406998
}
],
"events": []
}
- 2、提取某字段在该响应中的所有数据$.docGroups[0].documents[*].docId
{
"responseStatus": {
},
"docGroups": [
{
"documents": [
{
"docId": 1,
"startTime": 1673406999
},
{
"docId": 2,
"startTime": 1673406998
}
],
"events": []
}
Match No：想提取第几个数据
- Match No = 0，则会随即返回其中一个数据
- 填几，则会返回几个
- Match No =-1，返回所有的数据
若其他接口想调用取到的值，如下图catalogId字段一样使用即可
2.2.6.2 调试取样器
调试取样器可以打印出来Jmeter运行过程中保存下来的参数，需要配合查看结果树使用，无需配置任何数据
结果树中可看到获取到的get_docID值
2.2.6.3 方法二：后置处理器——正则表达式提取器
可以通过正则表达式来获取http请求返回的数据 
引用名称：匹配后的结果，保存到一个参数中，如param
正则表达式：
三步走:
1、拷贝目标数据和左右边界
2、把目标数据用括号括起来
3、把目标数据用.+?代替
模板： 1 1 1表示取匹配到的第一组数据， 2 2 2为第二组
匹配数字：当某组数据中包含多少个参数时，0代表随机，1代表该组的第一个参数，2表示第二 个。。。-1代表获取全部的参数，这个时候，引用名称就变成了参数数组，可以通过param_n来 获取指定的参数，当有多组数据时，第一组为param_1_g1，第二组为param_1_g2
结果：看倒数第四行的re_docid字段，是通过正则提取器提取到的第一个文章id
2.2.7 聚合报告
模拟用户使用时，循环次数要选【永久】
聚合报告结果：
#样本: 表示一共发出了多少个请求Average:平均响应时间
中位数：类似于50% Line90% Line: 假设该值为20，那么90%用户的响应时间小于等于20msMin:最小响应时间
Max/最大值: 最大响应时间
Error%/异常%: 错误率，出现错误的请求数量/请求的总数Throughput:吞吐量KB/Sec: 每秒从服务器端接收到的数据量
吞吐量：默认情况下表示每秒完成的请求数（Request per Second） 对于接口测试来说，Jmeter里的吞吐量=TPS
保存结果：聚合报告底部可保存结果数据
tip：
1、若两接口在同一线程组下，TPS值一致，但响应时间不一定一致
2、有关联关系的接口放在同一个线程组下，无关联的接口们需独立存放在不同的线程组下
2.2.8 定时器
1、Jmeter中的定时器类似于loadrunner中的pacing值和think_time
1）定时器是在每个sampler（采样器）之前执行的，而不是之后
2）定时器是有作用域的；当执行一个sampler之前时，所有当前作用域内的定时器都会被执行。且所有的sampler执行前都会执行定时器
3）如果希望定时器仅应用于其中一个sampler，则把该定时器作为子节点加入
2、常用的定时器
- 固定定时器：设置一个固定的延迟时间，单位ms
- 同步定时器（synchronizing timer）：在该定时器处，使线程等待，一直到指定的线程个数达到 后，再一起释放。可以在瞬间制造出很大的压力。它和loadrunner的集合点差不多的功能
- 集合点
- 集合点是为了增加瞬间并发压力的一种机制，在脚本中增加一个标记，所有虚拟用户执行到标记 处会进行等待，等所有用户都到达后，再同时继续执行下一步操作。
- 优点：对服务器来说，会产生一种瞬间高并发
- 缺点：对服务器来说，平均压力会降低
- 需要加集合点的场景 ：
- 根据业务来选择，如果业务场景是瞬间高并发类型的，如抢购、秒杀等，需要加集合点； 其他的场景都不需要加，一般加了集合点后，就不使用tps来衡量系统性能 集合点功能要慎重选择，因为加了集合点后，系统的平均压力会降低
- 超时时间=0，则不会发生超时；超时时间>0，等待X毫秒后，已处理完上一步的的线程组数进行并发
- 集合点
- 常量控制器：可以控制每分钟tps的总量，限制最高tps （线上测试最好加该控制器，以防压爆线上）
2.2.9 逻辑控制器
常用的逻辑控制器：
1、循环控制器：可以设置该控制器内的sampler执行的次数，循环次数与线程的循环次数各自独立
- 主要作用于多个请求时
此条件下，【获取专栏详情页的资讯列表】接口仅执行1次，【请求2】接口执行会执行6次
2、if控制器：根据判断条件决定是否执行该控制器内的请求，如果是字符串比较条件，参数和字符串 都需要加引号
条件格式：
KaTeX parse error: Expected group after '_' at position 2: {_̲_jexl3(条件表达式)}<…{__jexl3(KaTeX parse error: Expected 'EOF', got '}' at position 11: {num} > 5)}̲、 <br />2、若相比较的…{__jexl3(“${ip}”） == “xxxxx”)}
3、仅一次控制器：该控制器内的请求只执行一次，无论线程循环多少次
- 针对单个线程
此种情况下本应【请求2】【请求3】皆执行6次，但因为【请求3】在【仅一次控制器】下，最终结果为：
【请求2】执行6次【请求3】执行1次
4、foreach控制器，可以遍历某个参数数组，循环获取数组中的参数
参数是通过其他接口通过提取器提取出来的参数数组，再把参数循环附入需要这些参数的接口
结束循环字段：${get_docId_matchNr}取字数组末尾的get_docId_matchNr=12，方便标记，也不会产生写死的情况（只能获取到get_docId_9的情况）
输入变量法前缀：取自于结果树中get_docId(名字是自己在提取器中设置的变量名）
2.2.10 Http cookie管理器
2.2.10.1 cookie和session
cookie数据保存在客户端，session数据保存在服务器端。cookie有安全隐患，但是Session过多的时候会消耗服务器资源
- Cookie 机制：正统的 Cookie 分发是通过扩展 HTTP 协议来实现的，服务器通过在 HTTP 的响应头中加上一行特殊的指示以提示浏览器按照指示生成相应的 Cookie。然而纯粹的客户端脚本如 JavaScript 或者 VBScript也可以生成 Cookie。而 Cookie 的使用是由浏览器按照一定的原则在后台自动发送给服务器的。浏览器检查所有存储的 Cookie，如果某个 Cookie 所声明的作用范围大于等于将要请求的资源所在的位置，则把该 cookie 附在请求资源的 HTTP 请求头上发送给服务器。
- Session 机制：Session 机制是一种服务器端的机制，服务器使用一种类似于散列表的结构（也可能就是使用散列表）来保存信息。
Cookie 存在一定的全安隐患。Cookie 像我们以前用的存折，用户的存钱、取钱都会记录在这张存折上（即浏览器中会保存所有用户信息），那么对于有非分想法的人可能会去修改存折上的数据（这个比喻忽略掉银行同样会记录用户存取款的金额）。相对于存折，银行卡要全安的得多，客户拿到的只是一个银行卡号（即浏览器只保留一个 Sessionid），那么用户的存钱、取钱都会记录在银行的系统里（即服务器端），只得到一个 sessionid 是没有任何意义的，所以相对于 Cookie 来说就会安全很多。
cv文章~~
2.2.10.2 cookie管理器
位置：
使用：
1、名称：取自抓包接口中cookie下，对应的cookie名称，具体其中哪个字段作为cookie需问开发
2、值：即对应的cookie值，配置的cookie必须是有效的，无效接口会有对应的提示：比如用户无效啊，用户未登录~之类的
3、域：接口的域名，全局配置的话，可用 i p 对应的名称 写，配置如下图中，可写为 {ip对应的名称}写，配置如下图中，可写为 ip对应的名称写，配置如下图中，可写为{ip}
无需每次通过抓包获取cookie的便捷方法：
调用login接口获取cookie，http cookie管理器无需填写内容、接口中无需调用，管理器会自动获取接口中cookie塞到需要cookie的接口中
2.2.11 token接口处理
简单了解一下token的使用~
- 前端登陆的时候向服务器发送请求，服务器验证成功，会生成一个token
- 前端会存储这个token，放在session或cookie中，用于之后的业务请求身份验证
- 拿着这个token，可以在当前登录的账号下进行请求业务，发送请求时，token会放在请求头里，服务器收到这个业务请求，验证token，成功就允许这个请求获取数据
- token可以设置失效期
token知识~
从登录接口中提取token，若是在请求头里需要增加该参数，则在HTTP信息头管理器中添加对应的key、value
2.2.12 上传、下载文件（可以忽略该小节）
内容不全也无真实实例可展示（手头接口不支持）需要细了解请自行搜索
上传文件小点~：
1、文件上传原理：浏览器将本地文件内容通过HTTP发送到服务器，服务器收到数据后重新创建一个文件
2、文件上传的HTTP请求content-type:multipart/form-data，MIME类型为application/octet-stream
3、文件上传一般有表单上传和ajax上传两种方式
实现步骤：
1、需要用到的图片本地地址填在txt文本里
2、把需要读取的txt文件配置在【CSV数据文件设置】中
3、
下载：
1、文件下载的原理：服务器将文件内容通过HTTP发送到浏览器，浏览器接受到数据后在本地创建一个文件
2、创建文件是浏览器的自沈从文，测试文件下载不需要在本地创建文件
3、文件下载是一个普通的HTTP GET类型请求
2.2.13 WebService接口脚本编写
1、接口配置为http请求
- 提供http接口的网站：http://www.webxml.com.cn/zh_cn/web_services.aspx
- PS：http访问接口默认端口为80；https访问接口默认端口为443
2、添加header：Content-Type:text/xml;chartset-
2.2.14 TCP接口脚本编写
要发送的文本：可能是xml、也可能是十六进制的一串数据，具体数据格式需要找开发了解
2.2.15 JDBC请求脚本编写
1、添加数据库jar包
- mysql-connector-java-8.0.29.jar阿里盘地址： https://www.aliyundrive.com/s/cW8XgHNyF98
- 方式一：拷贝mysql驱动包到jmeter/lib目录下
- 方式二：测试计划处添加驱动jar包（仅针对该测试计划添加某jar包）
3、配置JDBC Connect Configuration
红框中为需要填写的参数；
Database URL：jdbc:mysql://{ip}:{port}/{dbname}?useUnicode=true&characterEncoding=utf8
JDBC Driver class：选择所需使用的数据库
4、**JDBC Request **
- Variable Name of Pool declared in JDBC Connection Configuration：该字段填写【JDBC Connection Configuration】中【Variable name of createdpool】字段值
- Query Type:语句类型
- Select statement：查询语句类型（select），只支持一条查询语句，多条查询语句只执行第一条
- Update statement：更新语句类（insert，update，delete），只支持一条更新语句，多条更新语句只执行第一条
- Prepared Select statement：支持多条查询（select）语句，查询响应数据只展示第一条SQL的查询结果
- Prepared Update statement：支持多条更新（insert，update，delete）语句，响应数据展示多条更新提示（做参数化最好选择该类型）
- Callable Statement：支持多条查询、更新（insert，update，delete，select）语句，响应数据展示展示多条数据更新结果。如果是多条select语句同时查询，建议使用Callable Statement，响应数据可以展示多条查询结果值
- Parameter values：填写参数的具体的值，或者参数的名称（代替sql语句中问号的值）。可以利用此字段对SQL语句进行参数化
- Parameter types：指Parameter Values参数的数据类型，例如：integer，String，double类型
- Parameter values 和Parameter types：必须成对出现，且SQL语句中有多个参数，就必须有多少个parameter values 和Parameter types。
- Variable names：自己设置的变量名称，用于存放select操作返回的查询结果。有多个字段返回时，需用逗号隔开
- Result variable name:用于存放select操作返回的查询结果集
- Query timeout：查询超时时间
- Handle result set：定义如何处理由callable statements 语句返回的结果
若想保存查询出的数据
1、添加【调试取样器】
2、【JDBC Request】中【Variable names】赋值
调试取样器中可查看到保存下来的结果
2.3 插件便捷管理
http://jmeter-plugins.org/downloads/all
1、下载jmeter-plugins.jar
2、把jar文件放入%Jmeter_Home%\lib\ext，重启jmeter
3、点击工具栏中的图标
，可对插件进行管理
可能会用到的插件：
- 3 基本グラフ: Windows で使用可能なリアルタイム TPS および応答時間プラグイン
- カスタム JMeter 関数
- ランダムCSVデータセット構成
- PerfMon: サーバー側のパフォーマンスのリアルタイム監視プラグイン
インストール:
1. 必要なプラグインを検索して確認します。
2. クリックして待ちます。ダウンロードが完了すると、自動的に再起動します。