SOAPless
無料で始める
ブログへ戻る
soap-apitestingtoolscomparison

SOAP API テストツール比較 2026：SoapUI、Postman、そして生の XML を触る人数を減らす方法

SOAPless Team7 min read

SOAP API のテストが重いのは、HTTP が難しいからではありません。XML エンベロープ、名前空間、WS-Security、Fault の扱いまで、接続先の都合を引き受ける必要があるからです。

つまり本当の論点は、「どのツールが便利か」だけではなく、「チームの何人まで生の SOAP を直接触るべきか」です。

この記事では、2026 年時点の主要ツールを比較しつつ、その責務分担も含めて整理します。

ツール比較の早見表

ツールSOAP 対応WSDL インポートWS-Security自動テスト価格
SoapUI (Open Source)ネイティブありありGroovy スクリプト無料
SoapUI Pro (ReadyAPI)ネイティブありありGUI + スクリプト有料
Postman限定的なし手動JavaScript無料 / 有料
curl手動なし手動シェルスクリプト無料
Insomnia限定的なし手動なし無料 / 有料
JMeterありプラグインプラグインあり無料

SoapUI（Open Source 版）

SOAP テストのデファクトスタンダードです。WSDL を読み込むだけで、すべてのオペレーションのテストリクエストを自動生成します。

セットアップと基本操作

  1. SoapUI 公式サイト からダウンロード
  2. File → New SOAP Project を選択
  3. WSDL の URL を入力
  4. オペレーション一覧が自動生成される

テストリクエストの例

SoapUI が WSDL から自動生成するリクエストテンプレート:

<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"
                  xmlns:ser="http://example.com/services">
   <soapenv:Header/>
   <soapenv:Body>
      <ser:GetUserRequest>
         <!--Required:-->
         <ser:userId>?</ser:userId>
      </ser:GetUserRequest>
   </soapenv:Body>
</soapenv:Envelope>

? の部分を実際の値に置き換えて実行するだけでテストできます。

WS-Security の設定

SoapUI では GUI から WS-Security を簡単に設定できます。

  1. プロジェクトのプロパティを開く
  2. WS-Security Configurations タブを選択
  3. Outgoing WS-Security Configuration を追加
  4. UsernameToken エントリを追加してユーザー名・パスワードを設定

Groovy スクリプトによる自動テスト

// SoapUI の Groovy テストスクリプト例
import groovy.json.JsonSlurper

// SOAP レスポンスから値を抽出
def response = context.expand('${GetUser#Response}')
def xml = new XmlSlurper().parseText(response)

def userName = xml.Body.GetUserResponse.user.name.text()
assert userName == "田中太郎" : "ユーザー名が期待値と異なる: ${userName}"

def email = xml.Body.GetUserResponse.user.email.text()
assert email.contains("@") : "メールアドレスの形式が不正: ${email}"

log.info("テスト成功: ユーザー名=${userName}, メール=${email}")

SoapUI の長所と短所

長所:

  • WSDL からの自動テスト生成
  • WS-Security のネイティブサポート
  • アサーション機能（XPath、XQuery、スキーマ検証）
  • Mock サービスの生成

短所:

  • GUI が古く、動作が重い
  • Java ベースのためメモリ消費が大きい
  • チームでの設定共有がやりにくい
  • CI/CD パイプラインとの統合にはコマンドラインツールが別途必要

Postman での SOAP テスト

Postman は REST API テストの定番ツールですが、SOAP リクエストの送信も可能です。ただし、WSDL の自動インポートはサポートしていないため、XML エンベロープを手動で構築する必要があります。

Postman での SOAP リクエスト設定

  1. 新しいリクエストを作成（POST メソッド）
  2. URL にサービスのエンドポイントを入力
  3. Headers を設定:
    • Content-Type: text/xml; charset=utf-8
    • SOAPAction: オペレーションの SOAPAction URI
  4. Body → raw → XML を選択
  5. SOAP エンベロープを手動入力
<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:tns="http://example.com/services">
  <soap:Body>
    <tns:GetUserRequest>
      <tns:userId>42</tns:userId>
    </tns:GetUserRequest>
  </soap:Body>
</soap:Envelope>

Postman のテストスクリプト

// Postman の Tests タブで XML レスポンスを検証
pm.test("ステータスコードが 200", function () {
    pm.response.to.have.status(200);
});

pm.test("レスポンスに SOAP Fault がない", function () {
    const responseBody = pm.response.text();
    pm.expect(responseBody).to.not.include("soap:Fault");
});

pm.test("ユーザー名が返却される", function () {
    const responseBody = pm.response.text();
    // XML パースは手動で行う必要がある
    const match = responseBody.match(/<.*:name>(.*?)<\/.*:name>/);
    pm.expect(match).to.not.be.null;
    pm.expect(match[1]).to.eql("田中太郎");
});

Postman の長所と短所

長所:

  • 直感的な UI
  • 環境変数とコレクション機能
  • Newman（CLI ツール）による CI/CD 統合
  • チームでの共有が容易

短所:

  • WSDL のインポート非対応
  • XML エンベロープを手動構築する必要がある
  • WS-Security の自動処理なし
  • XML のアサーションが手動

curl を使ったコマンドラインテスト

最もシンプルで、CI/CD パイプラインに直接組み込みやすい方法です。

#!/bin/bash
# SOAP API のテストスクリプト

ENDPOINT="https://example.com/service"
SOAP_ACTION="http://example.com/services/GetUser"

# リクエスト送信
RESPONSE=$(curl -s -w "\n%{http_code}" \
  -X POST "$ENDPOINT" \
  -H "Content-Type: text/xml; charset=utf-8" \
  -H "SOAPAction: \"$SOAP_ACTION\"" \
  -d '<?xml version="1.0" encoding="UTF-8"?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
               xmlns:tns="http://example.com/services">
  <soap:Body>
    <tns:GetUserRequest>
      <tns:userId>42</tns:userId>
    </tns:GetUserRequest>
  </soap:Body>
</soap:Envelope>')

# HTTP ステータスコードとボディを分離
HTTP_CODE=$(echo "$RESPONSE" | tail -1)
BODY=$(echo "$RESPONSE" | sed '$d')

# 検証
if [ "$HTTP_CODE" -ne 200 ]; then
  echo "FAIL: HTTP ステータスコード = $HTTP_CODE"
  exit 1
fi

if echo "$BODY" | grep -q "soap:Fault"; then
  echo "FAIL: SOAP Fault が返却された"
  echo "$BODY"
  exit 1
fi

echo "PASS: GetUser テスト成功"

JMeter での負荷テスト

JMeter は SOAP API の負荷テストに最適です。

<!-- JMeter のテスト計画（抜粋） -->
<HTTPSamplerProxy guiclass="HttpTestSampleGui" testclass="HTTPSamplerProxy">
  <stringProp name="HTTPSampler.domain">example.com</stringProp>
  <stringProp name="HTTPSampler.path">/service</stringProp>
  <stringProp name="HTTPSampler.method">POST</stringProp>
  <elementProp name="HTTPsampler.Arguments">
    <collectionProp name="Arguments.arguments">
      <elementProp name="" elementType="HTTPArgument">
        <stringProp name="Argument.value">${__FileToString(soap-request.xml)}</stringProp>
      </elementProp>
    </collectionProp>
  </elementProp>
</HTTPSamplerProxy>

# JMeter をコマンドラインで実行
jmeter -n -t soap-load-test.jmx \
  -l results.jtl \
  -Jthreads=50 \
  -Jrampup=10 \
  -Jduration=300

用途別の推奨ツール

用途推奨ツール理由
初回の動作確認SoapUIWSDL 自動インポートで即座にテスト可能
チーム開発の日常テストPostmanコレクション共有、環境変数管理が便利
CI/CD パイプラインcurl + シェルスクリプト依存なし、どの環境でも動作
負荷テストJMeter同時接続のシミュレーション
回帰テストSoapUI ProGUI でテストスイート管理

テストの手間を根本から減らす

SOAP API のテストが大変な理由は、テストツールの問題ではなく、SOAP というフォーマット自体の複雑さにあります。XML エンベロープの構築、名前空間の管理、WS-Security ヘッダーの設定は、どのツールを使っても必要な手順です。

SOAPless で SOAP サービスを REST API に変換すれば、テストも REST の標準的な方法で行えます。Postman で JSON を送信するだけ、curl でワンライナーを打つだけ。WSDL の URL を入力して 30 秒で REST エンドポイントが得られるので、テスト環境の構築時間も大幅に短縮できます。SOAP の XML を組み立てる時間を、テストケースの充実に使いましょう。

ブログへ戻る