bananan_wの日記： 英語勉強日記#7(翻訳がんばろう日記)
日記 by
bananan_w
さて、1-6章と19章まで翻訳終わり。
これで一通りのテスト計画を作るために必要なJMeterの基本的な動作の概念が理解できているはず。
この先はJDBCとかFTPとかLDAPの試験とかわりかしどーでもいい点なのでザックリと飛ばして
次は13章以降にしたい感じ。18章を除けば今月中に終わるんじゃないかな？
なかなかいいペースだね。18章だけで2週間はかかる(早くて)だろうから、今年中の完成（するのか？)を
目指してまったり行きましょう。
6. Building an Advanced Web Test Plan
6. 高度なテスト計画の構築
In this section, you will learn how to create advanced Test Plans to test a Web site.
このセクションではウェブサイトに高度なテストを実施する方法を習得します。
For an example of a basic Test Plan, see Building a Web Test Plan .
基本的なテスト計画の例はウェブテスト計画の構築(訳注:Aタグ注意)を参照してください。
6.1 Handling User Sessions With URL Rewriting
6.1 URLリライトによってユーザセッションを制御
If your web application uses URL rewriting rather than cookies to save session information, then you'll need to do a bit of extra work to test your site.
ウェブアプリケーションがセッション情報を保持するためにクッキーではなくURLリライトを使用する場合、サイトのテストを実施するために少しだけ追加作業が必要です。
To respond correctly to URL rewriting, JMeter needs to parse the HTML received from the server and retrieve the unique session ID. Use the appropriate HTTP URL Re-writing Modifier to accomplish this. Simply enter the name of your session ID parameter into the modifier, and it will find it and add it to each request. If the request already has a value, it will be replaced. If "Cache Session Id?" is checked, then the last found session id will be saved, and will be used if the previous HTTP sample does not contain a session id.
URLリライトに正確に対応するには、サーバから応答されたHTMLを解析し、ユニークなセッションIDをJMeterが読み出す必要があります。適切なHTTP URLリライト変換子を使用して実現させます。単純にセッションIDパラメータを変換子に入力すると、セッションIDを発見する度にそれぞれのリクエストにIDを追加します(訳注:ここitまみれでかなり原文ヒドイです。)。リクエストが既に値を保持している場合には、その値を置換します。”セッションIDをキャッシュする"をチェックしている場合には、最後に発見したセッションIDを保持し、直前のHTTPサンプルにセッションが含まれていない場合には保持しているものを使用します。
URL Rewriting Example
URLリライト例
Download this example . In Figure 1 is shown a test plan using URL rewriting. Note that the URL Re-writing modifier is added to the SimpleController, thus assuring that it will only affect requests under that SimpleController.
この例をダウンロード(訳注:Aタグ注意)してください。図1(ここは図6.1では？)にテスト計画でURLリライトを使用する方法を示します。URLリライト変換子はシンプルコントローラに追加されており、シンプルコントローラ配下のリクエストだけに効果を保証する事に注意してください。
Figure 1 - Test Tree
図1(訳注:6.1であるべき。)テストツリー
In Figure 2, we see the URL Re-writing modifier GUI, which just has a field for the user to specify the name of the session ID parameter. There is also a checkbox for indicating that the session ID should be part of the path (separated by a ";"), rather than a request parameter
図2(訳注:6.2が望ましい)ではURLリライト変換子のGUIを示します。ここではセッションIDパラメータの名前の項目だけを指定しています。また、セッションIDがリクエストパラメータではなく、パスの一部(";"で分割される)である事を指示するためのチェックボックスが存在します。
Figure 2 - Request parameters
図2(訳注:6.2であるべき) - リクエストパラメータ
6.2 Using a Header Manager
6.2 ヘッダマネージャの使用
The HTTP Header Manager lets you customize what information JMeter sends in the HTTP request header. This header includes properties like "User-Agent", "Pragma", "Referer", etc.
HTTPヘッダマネージャによってJMeterの送信するHTTPリクエストのヘッダ情報をカスタマイズできます。このヘッダには"User-Agent"、"Pragma"、"Referer"などの属性が含まれます。
The HTTP Header Manager , like the HTTP Cookie Manager , should probably be added at the Thread Group level, unless for some reason you wish to specify different headers for the different HTTP Request objects in your test.
HTTPヘッダマネージャはHTTPクッキーマネージャに似て、大概スレッドグループに追加されますが、何らかの理由によってテスト中の他のHTTPリクエストとは事なるヘッダを指定したい場合にも使用します。
これで一通りのテスト計画を作るために必要なJMeterの基本的な動作の概念が理解できているはず。
この先はJDBCとかFTPとかLDAPの試験とかわりかしどーでもいい点なのでザックリと飛ばして
次は13章以降にしたい感じ。18章を除けば今月中に終わるんじゃないかな？
なかなかいいペースだね。18章だけで2週間はかかる(早くて)だろうから、今年中の完成（するのか？)を
目指してまったり行きましょう。
6. Building an Advanced Web Test Plan
6. 高度なテスト計画の構築
In this section, you will learn how to create advanced Test Plans to test a Web site.
このセクションではウェブサイトに高度なテストを実施する方法を習得します。
For an example of a basic Test Plan, see Building a Web Test Plan .
基本的なテスト計画の例はウェブテスト計画の構築(訳注:Aタグ注意)を参照してください。
6.1 Handling User Sessions With URL Rewriting
6.1 URLリライトによってユーザセッションを制御
If your web application uses URL rewriting rather than cookies to save session information, then you'll need to do a bit of extra work to test your site.
ウェブアプリケーションがセッション情報を保持するためにクッキーではなくURLリライトを使用する場合、サイトのテストを実施するために少しだけ追加作業が必要です。
To respond correctly to URL rewriting, JMeter needs to parse the HTML received from the server and retrieve the unique session ID. Use the appropriate HTTP URL Re-writing Modifier to accomplish this. Simply enter the name of your session ID parameter into the modifier, and it will find it and add it to each request. If the request already has a value, it will be replaced. If "Cache Session Id?" is checked, then the last found session id will be saved, and will be used if the previous HTTP sample does not contain a session id.
URLリライトに正確に対応するには、サーバから応答されたHTMLを解析し、ユニークなセッションIDをJMeterが読み出す必要があります。適切なHTTP URLリライト変換子を使用して実現させます。単純にセッションIDパラメータを変換子に入力すると、セッションIDを発見する度にそれぞれのリクエストにIDを追加します(訳注:ここitまみれでかなり原文ヒドイです。)。リクエストが既に値を保持している場合には、その値を置換します。”セッションIDをキャッシュする"をチェックしている場合には、最後に発見したセッションIDを保持し、直前のHTTPサンプルにセッションが含まれていない場合には保持しているものを使用します。
URL Rewriting Example
URLリライト例
Download this example . In Figure 1 is shown a test plan using URL rewriting. Note that the URL Re-writing modifier is added to the SimpleController, thus assuring that it will only affect requests under that SimpleController.
この例をダウンロード(訳注:Aタグ注意)してください。図1(ここは図6.1では？)にテスト計画でURLリライトを使用する方法を示します。URLリライト変換子はシンプルコントローラに追加されており、シンプルコントローラ配下のリクエストだけに効果を保証する事に注意してください。
Figure 1 - Test Tree
図1(訳注:6.1であるべき。)テストツリー
In Figure 2, we see the URL Re-writing modifier GUI, which just has a field for the user to specify the name of the session ID parameter. There is also a checkbox for indicating that the session ID should be part of the path (separated by a ";"), rather than a request parameter
図2(訳注:6.2が望ましい)ではURLリライト変換子のGUIを示します。ここではセッションIDパラメータの名前の項目だけを指定しています。また、セッションIDがリクエストパラメータではなく、パスの一部(";"で分割される)である事を指示するためのチェックボックスが存在します。
Figure 2 - Request parameters
図2(訳注:6.2であるべき) - リクエストパラメータ
6.2 Using a Header Manager
6.2 ヘッダマネージャの使用
The HTTP Header Manager lets you customize what information JMeter sends in the HTTP request header. This header includes properties like "User-Agent", "Pragma", "Referer", etc.
HTTPヘッダマネージャによってJMeterの送信するHTTPリクエストのヘッダ情報をカスタマイズできます。このヘッダには"User-Agent"、"Pragma"、"Referer"などの属性が含まれます。
The HTTP Header Manager , like the HTTP Cookie Manager , should probably be added at the Thread Group level, unless for some reason you wish to specify different headers for the different HTTP Request objects in your test.
HTTPヘッダマネージャはHTTPクッキーマネージャに似て、大概スレッドグループに追加されますが、何らかの理由によってテスト中の他のHTTPリクエストとは事なるヘッダを指定したい場合にも使用します。
英語勉強日記#7(翻訳がんばろう日記) More ログイン