configure web service settings

新しい設定を適用するために、ウェブサービスにJSON文字列リクエストを送信します。
名前説明タイプ修飾子
values

新しい設定を適用するために、JSON文字列リクエストをWebサービスに送信します。

重要：　
プロファイルを作成するために必要な基本的なJSON構文は次のとおりです:

  • JSONデータは名前：　値のペアとして書かれます。例：　
                    "firstName" : "John"
  • JSONオブジェクトは中括弧内に書かれ、複数の名前：　値のペアを含むことができ、カンマで区切られます。例：　
                    { "firstName" : "John" , "lastName" : "Doe" }
  • JSON配列（JSONオブジェクトの配列）は角かっこ内に書かれ、カンマで区切られます。例：　
                    
                    "employees":[
                        {"firstName":"John", "lastName":"Doe"},
                        {"firstName":"Anna", "lastName":"Smith"},
                        {"firstName":"Peter","lastName":"Jones"}
                    ]
こちらでJSONの構文について詳しく学ぶことができます。

Stringなし
なし
このアクションは、次のプロジェクト項目で使用できます：　テストモジュールおよびユーザー定義アクションです。
次の設定はこのアクションに適用可能です：　 remove double quotes from cells.
例：　プロキシ設定

ケース１：　ユーザー定義のプロキシ設定：　

以下のプロキシ設定を追加すると仮定します：　

  1. ホスト名：　192.168.167.29
  2. ポート：　8888
  3. プロトコル：　http
  4. プロキシ認証
    • ユーザー名：　john
    • パスワード：　doe

JSON文字列は以下のようになるべきです：　

            
                {"proxy":{"hostname":"192.168.167.29","port":8888,"scheme":"http","username":"john","password":"doe"}}
            
        

        
        	values		
configure web service settings	{"proxy":{"hostname":"192.168.167.29","port":8888,"scheme":"http","username":"john","password":"doe"}}		
&nbsp			
create http request			
&nbsp			
	key	value	
add http header	content-type	application/json	
add http header	Authorization	application/json	
&nbsp			
	content		
add http body	#body value authenticate		
&nbsp			
	uri	method	variable
send http request	#api authenticate righteyes	POST	#"_response"&" "& ds number

ケース２：　システムのプロキシ設定：　

ホスト名とポートにシステムプロキシ設定を適用すると仮定します：　

  1. ホスト名：　system
  2. ポート：　systen
  3. プロトコル：　http
  4. プロキシ認証：　
    • ユーザー名：　john
    • パスワード：　doe

JSON文字列は以下のようになるべきです：　

            
                {"proxy":{"hostname":"system","port":"system","scheme":"http","username":"john","password":"doe"}}
            
        

        
        	values		
configure web service settings	{"proxy":{"hostname":"system","port":"system","scheme":"http","username":"john","password":"doe"}}		
&nbsp			
create http request			
&nbsp			
	key	value	
add http header	content-type	application/json	
add http header	Authorization	application/json	
&nbsp			
	content		
add http body	#body value authenticate		
&nbsp			
	uri	method	variable
send http request	#api authenticate righteyes	POST	#"_response"&" "& ds number
例：　SSL構成

ケース１：　SSLの検証なし
例えば、サーバーが無効なSSL証明書を使用しているため問題が発生した場合、最も簡単な対処方法は全てのホストを信頼することです。

JSON文字列は以下のようになるべきです：　

            
                {"ssl":"skip"}
            
        

        
        	values		
configure web service settings	{"ssl":"skip"}		
&nbsp			
create http request			
&nbsp			
	key	value	
add http header	content-type	application/json	
add http header	Authorization	# tm token	
&nbsp			
	uri	method	variable
send http request	# api test https	GET	_response_TC_02
&nbsp			
	response	status	
parse http reponse	#_response_TC_02	tm status_TC_02	
&nbsp			
	text	fragment	
check text contains	# tm status_TC_02	200

ケース２：　SSLクライアント検証
以下の証明書認証を使用してSSLを構成すると仮定してください。

  1. クライアント証明書を検出する際に使用するキーストアへのパス C:/Test\_Folder/newkeystore.jks
  2. キーストアのパスワード：　123456
  3. 使用する信頼ストア：　C:/Test\_Folder/cacerts
  4. 信頼ストアのパスワード：　changeit

JSON文字列は以下のようになるべきです：　

            
                {"ssl":{"pathToKeyStore":"C:/Test_Folder/newkeystore.jks","keyStorePassword":"123456","pathToTrustStore":"C:/Test_Folder/cacerts","trustStorePassword":"changeit"}}
            
        

        
        	values		
configure web service settings	{"ssl":{"pathToKeyStore":"C:/Test_Folder/newkeystore.jks","keyStorePassword":"123456","pathToTrustStore":"C:/Test_Folder/cacerts","trustStorePassword":"changeit"}}		
&nbsp			
create http request			
&nbsp			
	key	value	
add http header	content-type	application/json	
add http header	Authorization	# tm token	
&nbsp			
	uri	method	variable
send http request	# api test https	GET	_response_TC_03
&nbsp			
	response	status	
parse http reponse	#_response_TC_03	tm status_TC_03	
&nbsp			
	text	fragment	
check text contains	# tm status_TC_03	200
例：　Cookieの設定

以下のクッキーをサーバーに送信すると仮定します：　

  1. yummy\_cookie=choco
  2. tasty\_cookie=strawberry

JSON文字列は以下のようになるべきです：　

            
                {"cookies":{"yummy_cookie":"choco","tasty_cookie":"strawberry"}}
            
        

        
        	values			
configure web service settings	{"cookies":{"yummy_cookie":"choco","tasty_cookie":"strawberry"}}			
&nbsp				
create http request				
&nbsp				
	uri	method	variable	
send http request	# tm url	POST	tm_result	
&nbsp				
	response	status	header	body
parse http response	# tm_result	tm_status	tm_header	tm_body
&nbsp				
	text	fragment		
check text contains	# tm status_TC_03	200
例・ケース４：　エンコーダ構成

以下のエンコーダーの設定を指定すると仮定します

  1. 特定のコンテンツタイプに使用するデフォルトの文字セット。
    • application/json=UTF-8
    • text/plain=US-ASCII
  2. クエリパラメータのデフォルトの文字セット。
    • defaultQueryParameterCharset=US-ASCII
  3. REST AssuredはURLをエンコードしません
    • urlEncodingEnabled=false

JSON文字列は以下のように見えます：　

            
                {"encoder":{"contentTypeToDefaultCharset":{"application/json":"UTF-8","text/plain":"US-ASCII"},"defaultQueryParameterCharset":"US-ASCII","urlEncodingEnabled":"false"}}
            
        

        
        	values		
configure web service settings	{"encoder":{"contentTypeToDefaultCharset":{"application/json":"UTF-8","text/plain":"US-ASCII"},"defaultQueryParameterCharset":"US-ASCII","urlEncodingEnabled":"false"}}		
&nbsp			
create http request			
&nbsp			
	key	value	
add http header	path	# tm path	
&nbsp			
	content		
add http body	#tm text body content		
&nbsp			
	uri	method	variable
send http request	# tm encode url	POST	_response_TC_03_1
例・ケース５：　Decoder構成

以下の設定をデコーダーに指定すると仮定します：　

  1. 特定のコンテンツタイプに使用するデフォルトの文字セット。
    • application/octet-stream=us-ascii
  2. 適用するコンテンツデコーダー：　圧縮なし。
    注意: 
    　 これを行うと、Accept-Encoding ヘッダーがリクエストに自動的に追加され、レスポンス本文はエンコードされません。この場合、圧縮なしを示すidentity値が有効になります。

JSON文字列は以下のように見えます：　

            
                {"decoder":{"contentDecoders":"identity","contentTypeToDefaultCharset":{"application/octet-stream":"us-ascii"}}}
            
        

        
        	values		
configure web service settings	{"decoder":{"contentDecoders":"identity","contentTypeToDefaultCharset":{"application/octet-stream":"us-ascii"}}}			
&nbsp				
create http request				
&nbsp				
	key	value		
add http header	encoding	deflate		
add http header	media_type	#tm content type		
add http header	path	# cf server attachment location & "\" & tm input		
add http header	output_path	# cf server attachment location & "\" & tm output		
add http header	type	deflate		
&nbsp				
	uri	method	variable	
send http request	# api decoder	GET	tm result	
&nbsp				
	response	status	header	body
parse http response	# tm result	tm status	tm header	 tm body
&nbsp				
	value	expected		
check value	# tm status	200
例・ケース６：　リダイレクトの設定

以下のリダイレクト設定を構成すると仮定します：　

  1. リダイレクトに従います。
    • followRedirects=true
  2. 循環リダイレクトを許可します。
    • allowCircularRedirects=true
  3. 相対的なリダイレクトを拒否します。
    • rejectRelativeRedirect=true
  4. リダイレクトの最大数：　50.
    • maxRedirects=50

JSON文字列は以下のように見えます：　

            
                {"redirect":{"followRedirects":"true","allowCircularRedirects":"true","rejectRelativeRedirect":"true","maxRedirects":50}}
            
        

        
        	values			
configure web service settings	{"redirect":{"followRedirects":"true","allowCircularRedirects":"true","rejectRelativeRedirect":"true","maxRedirects":50}}			
&nbsp				
create http request				
&nbsp				
	key	value		
add http header	Content-Type	application/json		
&nbsp				
	uri	method	variable	
send http request	# ds url	GET	tm result	
&nbsp				
	result	description		
report check	# ds report check	# ds expected 1		
&nbsp				
	response	status	header	body
parse http response	# tm_result	tm_status	tm_header	tm_body
&nbsp				
	value	expected		
check value	#tm_status	# ds status
  • ビルトインアクション create http request を使用する前に、ウェブサービスの設定をその構成で宣言する必要があります。
  • TestArchitectでサポートされているウェブサービスの設定の全リストについては、サポートされているウェブサービスの設定以下を参照してください。
  • ウェブサービスの設定を単一のアクション configure web service settings または複数のアクション configure web service settings で宣言できます。ただし、同じ設定が同時に宣言された場合、後者の設定が前者の設定を上書きします。"
サポートされているウェブサービスの設定
  1. Proxy: 手動プロキシサーバーを定義します。
    覚えておく：　
      プロキシが使用されていないことを指定するには、テスト手順でプロキシ設定を使用してウェブサービス設定を構成しないようにしてください。
    • 手動プロキシ設定のためのJSON文字列は、以下のように定義する必要があります。
                              
                            {"proxy":{"hostname":"<value>","port":<value>,"scheme":"<value>","username":"<value>","password":"<value>"}}
      キー詳細
      ホスト名- （必須）使用するプロキシホストです。
      ポート- （必須）使用するプロキシポートです。
      スキーム- （任意）プロキシのスキームです。
      - このキーの値が空の場合、デフォルトでHTTPの値が使用されます。
      - サポートされるスキーム：　HTTP
      制限：　
      REST Assuredは、HTTP Builderをベースに構築されたRESTベースのサービスのテストを簡素化するためのJavaフレームワークであり、現在TestArchitectで使用されていますが、プロキシサーバーを介したHTTPS接続を完全にサポートしていません。
      ユーザー名- （任意）プロキシ認証のために送信されるユーザー名です。
      - この引数のキーが空の場合、このキーは自動化中に無視されます。
      パスワード- （任意）プロキシ認証のために送信されるパスワードです。
      - この引数のキーが空の場合、このキーは自動化中に無視されます。
    • サンプルのJSON文字列は、次のようになる可能性があります。
    • システムのプロキシを明示的に使用するには、ホスト名とポートにシステムの値を適用します。
                              
                            {"proxy":{"hostname":"system","port":"system","scheme":"<value>","username":"<value>","password":"<value>"}}
      注意：　
      • REST Assuredは、Java設定、環境変数、ブラウザ設定、およびオペレーティングシステムの設定を調べて、システムプロキシを自動的に判別します。
      • TestArchitect はミックスモードをサポートしています。特に、システムのホスト名をユーザー定義のポートと組み合わせて使用したり、その逆を行ったりすることができます。
  2. SSL：　SSL構成を定義します。TestArchitectでは3つのサポートされているモードがあります。
    1. サーバー検証：　HTTPSを通常どおり実行し、SSL検証はサーバーサイドで処理されます。
      • 定義されたJSON文字列：　
                                        {"ssl":"trusted"}
    2. SSL検証なし：　TestArchitect は relaxed HTTP validation し、すなわちSSL検証をスキップします。SSL証明書が無効であるかどうかに関係なく、全てのホストを信頼します。このモードを使用することで、キーストアやトラストストアを指定する必要はありません。
      • 定義されたJSON文字列：　
                                        {"ssl":"skip"}
    3. SSLクライアント認証：　Javaのキーストアファイルを利用して、より詳細に設定でき、それをREST Assuredと一緒に使用することができます。
      • JSON文字列は次のように定義する必要があります。
                                        
                                    {"ssl":{"pathToKeyStore":"<value>","pathToTrustStore":"<value>","keyStorePassword":"<value>","trustStorePassword":"<value>","port":<value>}}
        オプション詳細
        pathToKeyStore- （必須）クライアント証明書を探す際に使用するキーストアへのパスです。
        覚えておく：　
        事前にキーストアファイルを持っていることを確認してください。それ以外の場合、この リンクに従って、「Keystore Creation」を参照してください。
        - サポートされているキーストアの種類（詳細はこちらを参照してください）
        jceks: SunJCEプロバイダによって提供される専有のキーストア実装です。
        jks: SUNプロバイダによって提供される専有のキーストア実装です。
        pkcs12: PKCS12で定義された個人のアイデンティティ情報の転送構文です。
        JSON内のディレクトリを分離するには、四連続のバックスラッシュ（\）を使用するか、代替としてスラッシュ（/）を使用します。
        keyStorePassword- （任意）キーストアのパスワードです。
        pathToTrustStore- （任意）信頼ストアファイルへのパスです。
        - この引数のキーが空の場合、REST Assuredは自動的にセキュリティプロパティディレクトリに存在するcecartsという名前の証明書ファイルを検索します。セキュリティプロパティディレクトリは、java.home/lib/securityディレクトリにあり、java.homeは実行環境のディレクトリです。（詳細はこちら）
        - JSON内でディレクトリを区切るには、四連続のバックスラッシュ（\）を使用するか、代替として単一のスラッシュ（/）を使用します。
        trustStorePassword- （任意）信頼ストアのパスワードです。
        - この引数のキーが空の場合、このキーは自動化中に無視されます。
        port- （任意）SSL接続用のポートです。
        注意：　
        ほとんどの場合、ポートを指定する必要はありません。REST Assuredは、URIで定義されたHTTPSポートに構成を適用します。
        - この引数のキーが空の場合、このキーは自動化中に無視されます。
      • サンプルのJSON文字列は、以下のようになります。
  3. Cookies: サーバーに送信されるHTTPクッキーを指定します。
    • HTTPクッキーのJSON文字列は、以下のように定義する必要があります。
                              
                            {"cookies":{"<cookie-name>":"<cookie-value1>","<cookie-name2>":"<cookie-value2>","<cookie-name3>":"<cookie-value3>"}}
      注意：　
      "<cookie-name>":"<cookie-value>" の形式で表された名前-値のペアのリストです。リスト内のペアはコンマで区切られています。
    • サンプルのJSON文字列は、次のようになる可能性があります。
  4. エンコーダー: エンコーダーの構成を指定します。
    • エンコーダー用のJSON文字列は、次のように定義する必要があります。
                              
                            {"encoder":{"contentTypeToDefaultCharset":{"<content-type1>":"<charset1>","<content-type2>":"<charset2>"},"defaultQueryParameterCharset":"<value>","defaultContentCharset":"<value>","urlEncodingEnabled": "<value>","addDefaultContentCharsetToContentType":"<value>"}}
      オプション詳細
      contentTypeToDefaultCharset- （任意）特定のコンテンツタイプに使用するデフォルトの文字セットを指定します。
      - デフォルトの文字セットを各特定のコンテンツタイプに対して "<content-type>":"<charset>"の形式で表したペアのリストです。リスト内のペアはコンマで区切られています。
      - サポートされているキーストアのタイプです。（詳細はこちらを参照してください）
      - 利用可能なコンテンツタイプの一覧については、こちらを参照してください。
      - 利用可能な文字セットの一覧については、こちらを参照してください。
      - この引数のキーが空の場合、このキーは自動化中に無視されます。
      defaultQueryParameterCharset- （任意）query parameters のデフォルトの文字セットを指定します。
      - この引数のキーが空の場合、デフォルトではUTF-8の値が使用されます。
      - URLでクエリパラメータをエンコードしたくない場合、urlEncodingEnabledをfalseに設定することを強くお勧めします。
      defaultContentCharset- （任意）リクエスト仕様の本文/コンテンツのデフォルトの文字セットを指定します。
      - この引数のキーが空の場合、デフォルトではISO-8859-1の値が使用されます。
      - contentTypeToDefaultCharsetとdefaultContentCharsetが同時に定義されている場合、contentTypeToDefaultCharsetが優先されます。
      urlEncodingEnabled- （任意）（ブール値） URLが自動的にエンコードされるかどうかを指定します。通常、これはお勧めですが、一部の場合、例えば、クエリパラメータがREST Assuredに提供される前に既にエンコードされている場合、URLエンコーディングを無効にすると便利です。具体的には、クエリが既にURLエンコードされているため、二重エンコーディングを防ぐためにREST AssuredのURLエンコーディングを無効にする必要があります。
      - この引数のキーが空の場合、デフォルトではtrueの値が使用されます。
      addDefaultContentCharsetToContentType- （任意）（ブール値） REST Assuredが、コンテンツの文字セットが明示的に定義されていない場合、コンテンツタイプヘッダーに自動的にコンテンツの文字セットを追加するかどうかを指定します。
      - この引数のキーが空の場合、デフォルトではtrueの値が使用されます。
    • サンプルのJSON文字列は、以下のようになる可能性があります。
  5. デコーダー: デコーダーの構成を指定します。
    • デコーダーのJSON文字列は、次のように定義する必要があります。
                              
                            {"decoder":{"contentDecoders":"<value>","contentTypeToDefaultCharset":{"<content-type1>":"<charset1>","<content-type2>":"<charset2>"}}}
      オプション詳細
      contentDecoders- （任意）リクエストを行う際にサーバーに提供されるコンテンツデコーダーを指定します（Accept-Encodingヘッダーを使用）。サーバーがこれらのエンコーディングをサポートしている場合、REST Assuredは自動的にレスポンスのデコーディングを行います。
      - サポートされるモード：　
      1. default:（デフォルト） REST Assuredではgzipとdeflateが使用されます。
      - DecoderConfig.ContentDecoder.GZIP
      - DecoderConfig.ContentDecoder.DEFLATE
      2．identity: 圧縮なし（詳細はこちらを参照してください）。
      contentTypeToDefaultCharset- （任意）特定のコンテンツタイプに使用するデフォルトの文字セットを指定します。
      - "<content-type>":"<charset>" の形式で、各特定のコンテンツタイプに使用するデフォルトの文字セットのペアのリストです。
      リスト内のペアはコンマで区切られています。
      - 利用可能なコンテンツタイプの一覧については、こちらを参照してください。
      - 利用可能な文字セットの一覧については、こちらを参照してください。
      - この引数のキーが空の場合、このキーは自動化中に無視されます。
    • サンプルのJSON文字列は、以下のようになります。
  6. リダイレクト: リダイレクトの設定を構成します。
    • リダイレクトのためのJSON文字列は、以下のように定義する必要があります。
                              
                            {"redirect":{"followRedirects":"<value>","allowCircularRedirects":"<value>","rejectRelativeRedirect":"<value>","maxRedirects":<value>}}
      オプション詳細
      followRedirects- （任意）（ブール値）リダイレクトを自動的に処理するかどうかを定義します。
      - この引数のキーが空の場合、デフォルトではtrueの値が使用されます。
      allowCircularRedirects- （任意）（ブール値）同一の場所へのリダイレクト（同じ場所へのリダイレクト）を許可するかどうかを定義します。
      - この引数のキーが空の場合、デフォルトではfalseの値が使用されます。
      rejectRelativeRedirect- （任意）（ブール値）相対的なリダイレクトを拒否するかどうかを定義します。HTTP仕様では、場所の値は絶対URIである必要があります。
      - この引数のキーが空の場合、デフォルトでfalseの値が使用されます。
      maxRedirects- （任意）（ブール値）たどるべきリダイレクトの最大数を定義します。リダイレクトの数に制限を設けることは、壊れたサーバーサイドスクリプトによる無限ループを防ぐためのものです。
      - この引数のキーが空の場合、デフォルトで100の値が使用されます。
    • サンプルのJSON文字列は、以下のようになります。
Copyright © 2024 LogiGear Corporation. All rights reserved. LogiGearはLogiGear Corporationの登録商標であり、Action Based TestingおよびTestArchitectはLogiGear Corporationの商標です。ここに記載されているその他の商標は、各所有者の財産です。

LogiGear Corporation

1730 S. Amphlett Blvd. Suite 200, San Mateo, CA 94402

Tel: +1 (650) 572-1400

 
プライパシーポリシー | 利用規約