SOAPはまだ廃れていません。銀行システム、決済ゲートウェイ、政府サービス、古いエンタープライズプラットフォームは依然としてSOAPエンドポイントを公開しており、誰かがそれらをテストする必要があります。RESTとJSONでキャリアを積んできた人にとって、SOAPサービスは馴染みのないものに感じるかもしれません。プロトコルはより厳格で、ペイロードはXMLであり、契約は別のWSDLファイルに存在します。
良いニュースは、SOAP APIが実際に何を求めているかを理解すれば、オンラインでテストすることは難しくないということです。このガイドでは、SOAPテストがRESTテストとどのように異なるか、実際の要求を段階的に説明し、SOAPを苦労せずに扱えるオンラインツールを紹介します。
SOAPテストが異なる理由
RESTはスタイルです。SOAPはルールのあるプロトコルです。この違いが、テスト方法のすべてを形作っています。
SOAPメッセージは常に、エンベロープにラップされたXMLドキュメントです。エンベロープには、認証やルーティングなどのメタデータ用のヘッダーと、実際の操作とそのパラメーターを保持するボディが含まれています。単にJSONオブジェクトを送信することはできません。構造は必須であり、不正な形式のエンベロープはロジックが実行される前に拒否されます。SOAPはまた、データを読み取るだけの操作であっても、ほぼ常にHTTP POSTを介して送信され、特定のContent-Type（通常はtext/xmlまたはapplication/soap+xml）を期待します。
最大の実用的な違いはWSDLです。WSDL、つまりWeb Services Description Languageファイルは、サービスが提供するすべての操作、各リクエストとレスポンスの正確な形式、およびエンドポイントアドレスをリストする、機械可読な契約です。RESTでこれほど厳格なものが提供されることはめったにありません。SOAPをテストする際、WSDLはあなたの地図となります。優れたオンラインSOAPテスターはWSDLを読み取り、リクエストテンプレートを生成してくれるので、記憶に頼ってエンベロープを手入力する必要がありません。より広範な契約の全体像を知りたい場合は、API契約テストに関する弊社の説明で、厳格な契約がなぜ資産となるのかを解説しています。
実際のSOAPリクエストの例
通貨換算サービスに対する現実的なSOAPリクエストを以下に示します。エンベロープ、名前空間宣言、およびボディ内にネストされた操作に注目してください。
POST /CurrencyService.asmx HTTP/1.1
Host: rates.example.com
Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Header>
<cur:AuthToken>e9f2a1c7-4b8d-4c2a-9f31-7d6e5a4b3c21</cur:AuthToken>
</soap:Header>
<soap:Body>
<cur:ConvertAmount>
<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
</cur:ConvertAmount>
</soap:Body>
</soap:Envelope>
レスポンスも同様にラップされて返されます。
<?xml version="1.0" encoding="utf-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:cur="https://rates.example.com/">
<soap:Body>
<cur:ConvertAmountResponse>
<cur:ConvertAmountResult>231.45</cur:ConvertAmountResult>
</cur:ConvertAmountResponse>
</soap:Body>
</soap:Envelope>
2つの詳細が人々を困惑させます。SOAPAction HTTPヘッダーは多くのサービスで必須であり、操作と一致している必要があります。一致しない場合、フォルトが発生します。また、何らかの障害が発生した場合、SOAPは整然としたメッセージとともにHTTP 400を返しません。ボディ内に<soap:Fault>要素を含むHTTP 200を返します。呼び出しが本当に成功したかどうかを知るためには、テストはボディを解析する必要があります。ステータスコードをチェックするだけでは不十分であり、これが構造化されたAPIアサーションがRESTよりもここで重要となる理由の1つです。
SOAP APIをテストするためのオンラインツール
Apidog
Apidogは、REST、GraphQL、WebSocketとともにSOAPを一箇所で処理します。WSDLをインポートすると、リクエスト構造が生成されるため、エンベロープを手動で作成する必要はありません。XML要素に対するアサーションを追加したり、リクエストをシナリオに連結したり、全体を自動化されたスイートとして実行したりできます。APIの設計とモックも行うため、実際のサービスが準備できる前にSOAPレスポンスをモックすることも可能です。Apidogをダウンロードして、無料枠でSOAPサービスをテストしましょう。
SoapUI
SoapUIは、SOAPテストツールの元祖であり、今でも最も奥深いツールです。WSDLを指定すると、すべての操作を含むプロジェクトを構築します。オープンソース版は無料で、機能テストやデータ駆動型SOAPテストに強力です。より重厚なJavaデスクトップアプリケーションであり、最も洗練されたレポート機能は有料のReadyAPIティアに含まれています。詳細については、SoapUIとは何か、どのように機能するかをご覧ください。
Postman
PostmanはSOAPリクエストを送信できます。ボディを生XMLに設定し、Content-TypeとSOAPActionヘッダーを手動で追加し、エンベロープを貼り付けます。これは機能しますが、PostmanはWSDLを解析しないため、エンベロープは自分で構築する必要があります。一時的な確認には問題ありませんが、大規模なSOAPインターフェースにはあまり適していません。
ブラウザベースのSOAPテスター
いくつかの軽量なウェブツールでは、WSDLのURLを貼り付けてブラウザのタブからリクエストを送信できます。何もインストールせずに迅速な検証を行うのに便利です。しかし、その限界はすぐに現れます。アサーションサポートが乏しい、自動化がほとんどまたはまったくない、実際のテストスイートを整理する方法がないなどです。これらはエンドポイントが生きていることを確認するために使用し、回帰テストスイートを構築するためには使用しないでください。
簡単なSOAPテストのワークフロー
- WSDLを取得する。 ほとんどのSOAPサービスは、エンドポイントURLに
?wsdlを追加することでWSDLを公開しています。開いて、読み込みを確認してください。 - WSDLをツールにインポートする。 ApidogやSoapUIは、WSDLからリクエストテンプレートを生成します。これは、時間短縮において最も重要です。
- 操作パラメーターを入力する。 実際の値を使用してください。通貨換算を実際の金額と有効な通貨コードでテストします。
- ヘッダーを設定する。
Content-Typeと、必要に応じてSOAPActionを確認します。SOAPActionがないことが、原因不明のフォルトの最も一般的な原因です。 - 送信してボディを検査する。 HTTPステータスだけで判断しないでください。レスポンスボディを開き、
<soap:Fault>がないか確認します。 - アサーションを追加する。 特定の要素が存在し、期待される値を保持していることをアサートします。次に、フローが必要とする場合は、後続の呼び出しを連結します。
これらを保守可能なセットにまとめるには、API自動化のためのテストスイート構築に関する弊社のガイドがSOAP作業にも直接適用できます。
SOAPフォルトとそれに対するアサーション方法
SOAPフォルトは、プロトコルのエラー構造です。faultcode、faultstring、そして時にはdetail要素を含みます。HTTP 200とともに返されるため、ステータスのみをチェックするテストは、失敗した呼び出しに対しても合格してしまいます。これは、静かで危険な偽陽性です。
SOAPアサーションはボディの内部を調べるように記述してください。成功パスでは<soap:Fault>要素が存在しないことをアサートします。意図的なエラーパスでは、反対にフォルトが出現し、faultcodeが期待するものと一致することをアサートします。SOAPサービスは、拒否されたトランザクションのようなビジネスルールをデータではなくフォルトとしてエンコードすることが多いため、失敗ケースのテストは正常パスのテストと同じくらい重要です。正式な詳細が必要な場合は、W3C SOAPフォルトのドキュメントで構造が説明されています。
WS-Securityは別の層を追加します。多くのエンタープライズSOAPサービスは、署名された、またはトークンを含むセキュリティヘッダーを期待します。認証フォルトでリクエストが失敗した場合、WSDLまたはサービスドキュメントには、どのセキュリティプロファイルが使用されているかが記載されています。SoapUIやApidogのようなツールでは、XMLを手動で作成するのではなく、これらのヘッダーを設定することができます。
WSDLで迷子にならずに読み解く方法
WSDLファイルは、初めて開くと威圧的に見えるかもしれません。長く、深くネストされたXMLであり、そのほとんどは機械的な配管です。すべてを読む必要はありません。実際に必要な情報は4つの部分に含まれています。
typesセクションはデータ構造を定義し、通常はXMLスキーマとして記述されるため、各パラメーターの正確な形式と制約をここで知ることができます。message要素は、各操作の入力と出力を記述します。portTypeは、実行可能な呼び出しである操作自体をリストします。serviceとbindingセクションは、具体的なエンドポイントアドレスとトランスポートの詳細を提供します。WSDLをツールにインポートすると、これら4つすべてを読み取り、編集可能なリクエストに変換してくれます。これが、手入力よりもインポートが常に優れている理由です。
知っておくべき詳細が1つあります。WSDLはimportステートメントを使用して複数のファイルに分割でき、多くの場合、スキーマを別々の場所から取り込みます。ツールが型が見つからないと報告した場合、参照されたファイルの解決に失敗した可能性が高いです。インポートされたすべてのURLが、ツールが実行されている場所から到達可能であることを確認してください。このような契約の依存関係こそが、チームがWSDLをサーバー上のみに存在するものではなく、バージョン管理された成果物として扱う理由です。
データ駆動型SOAPテスト
SOAPサービスは厳格なビジネスルールを持つことが多く、単一の正常パスリクエストだけではほとんど何も証明できません。通貨サービスは、有効な通貨ペア、サポートされていない通貨、ゼロの金額、負の金額でテストする必要があります。決済サービスは、承認されたカード、拒否されたカード、有効期限切れのカードでテストする必要があります。これらを一つ一つ手で入力するのは時間がかかり、間違いも起こりやすいです。
データ駆動型テストはこれを解決します。プレースホルダーを使ってリクエストを一度作成し、その後、入力行と期待される結果のテーブルを供給します。ツールは各行に対してリクエストを実行し、それぞれの結果をチェックします。SoapUIは何年も前からこのパターンをサポートしており、Apidogもシナリオランナーを通じてこれをサポートしています。その結果、SOAPサービスがフォルトとしてエンコードしがちなエッジケースを実際に網羅することができます。より広範なパターンについては、CSVおよびJSONを使用したデータ駆動型APIテストに関する弊社のガイドで入力データの構造方法を説明しており、これはRESTと同様にSOAPにも適用されます。
よくある質問
SOAPテストとRESTテストの違いは何ですか？
SOAPテストは、WSDL契約、必須のエンベロープ、HTTP 200のボディ内部で返されるフォルトを持つ厳格なXMLプロトコルに対して行われます。RESTテストは通常、JSON、より緩やかな規約、意味のあるHTTPステータスコードを扱います。SOAPテストでは、成功を確認するためにレスポンスボディを解析する必要がありますが、RESTテストでは多くの場合、ステータスコードを信頼することができます。
SOAP APIをテストするにはWSDLが必要ですか？
正確なエンベロープ構造をすでに知っていれば、WSDLなしでSOAPリクエストを送信できます。しかし、ツールがWSDLから正確なリクエストテンプレートを生成するため、WSDLはテストをはるかに容易にします。ほとんどのサービスは、エンドポイントURLに?wsdlを追加することでWSDLを公開しています。常にそこから始めましょう。
SOAPリクエストのステータスが200なのにフォルトが返されるのはなぜですか？
SOAPはエラーをHTTPエラーコードとしてではなく、ボディ内の<soap:Fault>要素として報告するため、フォルトを伴う200は正常です。一般的な原因としては、SOAPActionヘッダーの欠落または誤り、不正な形式のエンベロープ、名前空間の不一致、またはセキュリティチェックの失敗が挙げられます。具体的な理由についてはfaultstringを読んでください。
SOAP APIをオンラインで無料でテストできますか？
はい、可能です。Apidogは無料枠でSOAPをサポートし、WSDLファイルをインポートできます。また、SoapUIのオープンソース版もSOAP用に構築されています。軽量なブラウザテスターも簡単な確認のために存在しますが、それらは実際のアサーションや自動化のサポートに欠けています。
SOAP APIテストを自動化するにはどうすればよいですか？
WSDLをインポートし、操作を順番に連結するシナリオを構築し、レスポンス要素およびフォルトの不在に対するアサーションを追加します。その後、ツールのランナーから、またはCIパイプラインで実行します。SoapUIとApidogは両方とも、スケジュールされたSOAPスイートおよびパイプラインによってトリガーされるSOAPスイートをサポートしているため、SOAPの回帰テスト実行はRESTと同じ自動化フローに適合します。