8b. 拡張 LDAP テスト計画の構築

このセクションでは、LDAP サーバーをテストするための基本的なテスト計画を作成する方法を学習します。

Extended LDAP Sampler は高度な設定が可能なため、正しいテスト計画を作成するには時間がかかることも意味します。ただし、ニーズに合わせて正確に調整できます。

LDAP サーバーで 9 つのテストの要求を送信する 1 人のユーザーを作成します。また、ユーザーにテストを 1 回実行するように指示します。したがって、リクエストの総数は(1 ユーザー) x (9 リクエスト) x (1 回繰り返す) = 9 LDAP リクエストです。テスト計画を構築するには、次の要素を使用します:
スレッド グループ、
LDAP 拡張要求デフォルトの
追加 、LDAP 要求の追加、および
テスト結果を表示/保存するためのリスナーの追加

この例では、LDAP サーバーがldap.test.comで利用可能であることを前提としています。

経験の浅い LDAP ユーザーのために、複雑なテスト計画の構築に使用できるいくつかの LDAP 操作を簡単に説明する 小さな LDAP チュートリアルを作成します。

識別名に LDAP 特殊文字を使用する場合は注意してください。その場合 (識別名に+記号を使用する場合など)、その文字の前に「 \」記号を追加して文字をエスケープする必要があります。追加の例外: (追加または名前変更操作で) 識別名に\文字を追加する場合は、4 つのバックスラッシュを使用する必要があります。

例:

cn=ドルフ\+スミッツ
cn=dolf+smitsのような名前のエントリを追加/検索するには
cn=ドルフ \\ スミッツ
cn=dolf \ smitsという名前のエントリを検索するには
cn=c:\\\\log.txt
cn=c:\log.txtのような名前のエントリを追加するには

8b.1 ユーザーの追加

すべての JMeter テスト計画で行う最初のステップは、スレッド グループ要素を追加することです。スレッド グループは、シミュレートするユーザーの数、ユーザーが要求を送信する頻度、送信する要求の数を JMeter に伝えます。

まずTest Planを選択し、マウスの右ボタンをクリックしてAddメニューを表示し、 Add → Threads (Users) → Thread Groupを選択し てThread Group要素を追加します。Test Planの下にThread Group要素が表示されます。要素が表示されない場合は、テスト計画要素をクリックしてテスト計画ツリーを「展開」します。

図 8b.1。 デフォルト値を持つスレッド グループ
図 8b.1。デフォルト値を持つスレッド グループ

8b.2 LDAP 拡張要求デフォルトの追加

LDAP Ext Users 要素を選択することから始めます。マウスの右ボタンをクリックして [追加] メニューを表示し、[追加] → [構成要素] → [ LDAP 拡張要求のデフォルト] を選択します。次に、この新しい要素を選択して、そのコントロール パネルを表示します。

ほとんどの JMeter 要素と同様に、LDAP Extended Request Defaultsコントロール パネルには変更可能な名前フィールドがあります。この例では、このフィールドをデフォルト値のままにします。

図 8b.2 テスト計画の LDAP デフォルト

図 8b.2 テスト計画の LDAP デフォルト

さまざまな操作ごとに、いくつかのデフォルト値を入力できます。すべての場合で、デフォルト値が入力されると、これが LDAP 拡張要求に使用されます。要求ごとに、LDAP 拡張要求サンプラーに値を入力することでデフォルトをオーバーライドできます。テストに必要な値が入力されていない場合、テストは予測できない方法で失敗します。

非常に小さなテストプランを作成するため、ここではデフォルト値を入力しません。そのため、LDAP 拡張サンプラーを追加するときに、すべての異なるフィールドについて説明します。

8b.3 LDAP リクエストの追加

テスト計画では、9 つ​​の LDAP 要求すべてを使用したいと考えています。

  1. スレッドバインド
  2. 検索テスト
  3. 比較テスト
  4. シングルバインド/アンバインドテスト
  5. テストを追加
  6. テストの変更
  7. エントリの名前変更 (moddn)
  8. テストの削除
  9. スレッドアンバインド

JMeter は、ツリーに追加した順序でリクエストを送信します。

LDAP 拡張要求を LDAP Ext Users 要素に追加する (
Add → Sampler → LDAP Ext Request )。次に、ツリーでLDAP Ext Request要素を選択し、次のプロパティを編集します。

8b.3.1 スレッドバインドリクエストの追加

  1. 要素の名前を変更します: " 1. Thread bind "
  2. 「スレッドバインド」ボタンを 選択します。
  3. サーバー名フィールドに LDAP サーバーからのホスト名の値を入力します。
  4. ポートフィールドに LDAP サーバーからのポート番号 ( 636 : ldap over SSL) を 入力します。
  5. (オプション) DN フィールドに baseDN を入力します。この baseDN は、検索、追加、削除などの開始点として使用され
    ます。たとえば、すべての情報が保存されている場合など、すべての要求に対してこれが最上位の共有レベルである必要があることに注意してください。ou=Users、dc=test、dc=comの下では、この値を basedn で使用できます。
  6. (オプション)認証に使用するユーザーの識別名を入力します。このフィールドを空のままにすると、匿名バインドが確立されます。
  7. (オプション)認証するユーザーのパスワードを入力します。空のパスワードも匿名バインドにつながります。
  8. (オプション) LDAP との接続タイムアウトの値を入力します
  9. (オプション) [LDAP over SSL (ldaps) でアクセスする場合はセキュア LDAP プロトコルを使用する] チェックボックスをオンにします。
  10. (オプション)クライアントがすべての証明書を信頼するようにする場合は、[TrustAll] ボックスをオンにします。

図 8b.3.1。 スレッドバインドの例
図 8b.3.1。スレッドバインドの例

8b.3.2 検索リクエストの追加

  1. 要素の名前を変更します: " 2. 検索テスト"
  2. 「検索テスト」ボタンを 選択します。
  3. (オプション)検索を実行する検索ベースを、スレッド バインド リクエストで使用される basedn に関連して入力します。
    空のままにすると、basedn が検索ベースとして使用されます。このファイルは、「ベース エントリ」または「1 レベル」検索を使用する場合に重要です (以下を参照)。
  4. 検索フィルターを入力します。適当な LDAP 検索フィルターで十分ですが、ここでは、(sn=Doe)や(cn=*)などの単純なものを使用します。
  5. (オプション)スコープ フィールドにスコープを入力します。3 つのオプションがあります。
    1. baseobject 検索
      指定された検索ベースのみが使用され、属性または存在をチェックするためだけに使用されます。
    2. onelevel search
      指定された検索ベースの 1 レベル下の検索のみが使用されます
    3. subtree search
      指定された basedn の下の任意のポイントでオブジェクトを検索します
  6. (オプション)サイズ制限。返されるエントリの最大数を指定します。
  7. (オプション)制限時間。SERVER が検索の実行に使用できる最大ミリ秒数を指定します。アプリケーションが待機する最大時間ではありません。
    非常に高速なサーバーから非常に低速な回線を介して非常に大きなリターンセットが返される場合、検索リクエストが完了するまで何年も待たなければならない場合がありますが、このパラメーターはこれに影響しません。
  8. (オプション)検索回答に必要な属性。これは、特にオブジェクトに非常に大きな属性 ( jpegPhoto など) がある場合に、回答のサイズを制限するために使用できます。次の 3 つの可能性があります。
    1. 空のままにします (デフォルト設定も空にする必要があります)。これにより、すべての属性が返されます。
    2. 空の値 ( "" ) を 1 つ入力すると、存在しない属性が要求されるため、実際には属性は返されません。
    3. 属性をセミコロンで区切って入力します。要求された属性のみを返します
  9. (オプション)オブジェクトを返します。オンにすると、すべての java-object 属性が返され、上記で指定したように、これらが要求された属性に追加されます。
    チェックを外すと、java-object 属性は返されません。
  10. (オプション)別名の逆参照。チェックされている場合は参照に従うことを意味し、チェックされていない場合は従わないことを示します。
  11. (オプション)検索結果を解析しますか?。チェックを入れると応答データですべての結果を取得することを意味し、チェックを外すと取得しないことを示します。

図 8b.3.2。 検索依頼例
図 8b.3.2。検索依頼例

8b.3.3 比較リクエストの追加

  1. 要素の名前を変更します: " 3. Compare Test "
  2. 「比較」ボタンを 選択します。
  3. 「 cn=jdoe,ou=Users」 のように、比較操作を行うオブジェクトのエントリ名を basedn に対して相対的に入力します。
  4. 比較フィルタを入力します。これは、「属性=値」 の形式にする必要があります。例: 「mail=jdoe@test.com」

図 8b.3.3。 比較例
図 8b.3.3。比較例

8b.3.4 単一のバインド/バインド解除の追加

  1. 要素の名前を変更します: " 4. Single bind/unbind Test "
  2. [シングル バインド/バインド解除] ボタンを 選択します。
  3. 認証に使用するユーザーの完全な識別名を入力します。
    例cn=jdoe,ou=Users,dc=test,dc=com このフィールドが空の場合、匿名バインドが確立されます。
  4. 認証するユーザーのパスワードを入力します。空のパスワードも匿名バインドにつながります。
注意: この単一のバインド/バインド解除は、実際には 2 つの別個の操作ですが、簡単に分割することはできません!

図 8b.3.4。 シングルバインド/アンバインドの例
図 8b.3.4。シングルバインド/アンバインドの例

8b.3.5 追加リクエストの追加

  1. 要素の名前を変更します: " 5. Add Test "
  2. 「追加」ボタン を 選択します。
  3. basedn に関連する、追加するオブジェクトの識別名を入力します。
  4. 「 add test 」テーブルに 行を追加し、属性と値を入力します。
    同じ属性が複数回必要な場合は、新しい行を追加し、属性を再度追加して、別の値を追加します。
    テストに合格するには、必要なすべての属性と値を指定する必要があります。画像を参照してください。
    (サーバーが属性「objectClass=top」を追加する場合があり、これにより問題が発生する可能性があります。

図 8b.3.5。 追加リクエスト例
図 8b.3.5。追加リクエスト例

8b.3.6 変更リクエストの追加

  1. 要素の名前を変更します: " 6. テストの変更"
  2. [テストの変更] ボタンを 選択します。
  3. basedn を基準にして、変更するオブジェクトの識別名を入力します。
  4. 「 add」ボタン を使用して、「 modify test」テーブルに 行を追加します。
  5. 変更する属性、(オプション) 値、およびオペコードを入力する必要があります。このオペコードの意味:
    追加
    これは、属性値 (この場合はオプションではない) が属性に追加されることを意味します。
    属性が存在しない場合は作成され、値が追加されます。属性が存在
    し、複数の値が定義されている場合は、新しい値が追加されます。
    存在するが単一の値の場合、失敗します。
    交換
    これにより、指定された新しい値で属性が上書きされます (ここではオプションではありません)
    属性が存在しない場合は、作成され
    、値が追加されます。既存の場合は、古い値が削除され、新しい値が追加されます。
    消去
    値が指定されていない場合、すべての値が削除されます 値が指定され
    ている場合、その値のみが削除されます指定され
    た値が存在しない場合、テストは失敗します
  6. (オプション) 「変更テスト」テーブルに変更を追加します。
    変更テストに合格するには、指定されたすべての変更が成功する必要があります。1 つの変更が失敗すると、変更はまったく行われず、エントリは変更されません。

図 8b.3.6。 修正例
図 8b.3.6。修正例

8b.3.7 名前変更リクエストの追加 (moddn)

  1. 要素の名前を変更します: " 7. エントリの名前を変更 (moddn) "
  2. [エントリの名前を変更] ボタンを 選択します。
  3. 「古いエントリ名」フィールド に、baseDN に相対的なエントリの名前を入力します。
    つまり、「cn=Little John Doe,ou=Users」の名前を変更する場合、baseDN を「dc=test,dc=com 」に設定すると、「 cn=John Junior Doe,ou=Users」と入力する必要があります。 "古いエントリ名の-Field.
  4. 「新しい識別名」フィールド に、baseDN に関連するエントリの新しい名前を入力します。
    RDN のみを変更すると
    、別のサブツリーも追加するとエントリの名前が変更されます。たとえば、cn=john doe,ou=Usersからcn=john doe,ou=oldusersに変更すると、エントリが移動します。完全なサブツリーを移動することもできます (LDAP サーバーがこれをサポートしている場合!)。たとえば、 ou=Users,ou=retiredをou=oldusers,ou=usersに移動します。これにより、完全なサブツリーに加えて、サブツリー内のすべての退職者が移動します。木の新しい場所。

図 8b.3.7。 名前の変更の例
図 8b.3.7。名前の変更の例

8b.3.8 削除リクエストの追加

  1. 要素の名前を変更します: " 8. テストの削除"
  2. 「削除」ボタン を 選択します。
  3. [削除]フィールド に、baseDN に関連するエントリの名前を入力します。
    つまり、「cn=John Junior Doe,ou=Users,dc=test,dc=com」を削除したい場合、baseDN を「dc=test,dc=com 」に設定すると、「 cn」と入力する必要があります。=John Junior Doe,ou=Users " を[削除]フィールドに入力します。

図 8b.3.8。 削除例
図 8b.3.8。削除例

8b.3.9 アンバインドリクエストの追加

  1. 要素の名前を変更します: " 9. Thread unbind "
  2. 「スレッドのバインド解除」ボタンを 選択します。現在の接続を閉じるだけなので、これで十分です。必要な情報は、システムによって既に認識されています

図8b.3.9。 アンバインドの例
図8b.3.9。アンバインドの例

8b.4 テスト結果を表示/保存するためのリスナーの追加

テスト計画に追加する必要がある最後の要素はリスナーです。この要素は、LDAP 要求のすべての結果をファイルに保存し、データのビジュアル モデルを提示する役割を果たします。Thread グループ要素を選択し、View Results Treeを追加します( Add → Listener → View Results Tree ) 。

図8b.4。 結果ツリー リスナーの表示
図8b.4。結果ツリー リスナーの表示

このリスナーには、表示する 3 つのタブ (サンプラーの結果、要求、および応答データ) があります。

  1. サンプラーの結果には、応答時間、リターンコード、およびリターン メッセージのみが含まれます。
  2. リクエストは、行われたリクエストの簡単な説明を提供します。実際には、ここには関連情報は含まれていません。
  3. 応答データには、送信された要求の完全な詳細と、受信した回答の完全な詳細が含まれています。これは (自己定義された) xml スタイルで提供されます。 完全な説明はここにあります。

Go to top
Copyright © 1999 – 2021 , Apache Software Foundation
Apache, Apache JMeter, JMeter, the Apache feather, and the Apache JMeter logo are trademarks of the Apache Software Foundation.
br es de fr jp kr zh