DEV Community

Cover image for Como Testar API SOAP Online: Ferramentas e Exemplo Prático
Lucas
Lucas

Posted on • Originally published at apidog.com

Como Testar API SOAP Online: Ferramentas e Exemplo Prático

SOAP não desapareceu. Sistemas bancários, gateways de pagamento, serviços governamentais e plataformas empresariais mais antigas ainda expõem endpoints SOAP, e alguém precisa testá-los. Se você passou sua carreira em REST e JSON, um serviço SOAP pode parecer estranho: o protocolo é mais rígido, os payloads são XML e o contrato fica em um arquivo WSDL separado.

Experimente o Apidog hoje

A boa notícia: testar uma API SOAP online fica simples quando você entende o que o serviço espera. Neste guia, você verá as diferenças práticas entre SOAP e REST, como montar uma requisição real, quais cabeçalhos validar e como automatizar testes com ferramentas que leem WSDL.

Por que o teste SOAP é diferente

REST é um estilo arquitetural. SOAP é um protocolo com regras formais. Essa diferença muda a forma como você testa.

Uma mensagem SOAP é sempre um documento XML dentro de um envelope. Esse envelope contém:

  • Header: metadados, como autenticação, roteamento ou WS-Security.
  • Body: operação chamada e seus parâmetros.
  • Namespaces XML obrigatórios.
  • Um Content-Type específico, normalmente text/xml ou application/soap+xml.

Você não envia um JSON solto. Um envelope malformado pode ser rejeitado antes de chegar à lógica da aplicação.

Outra diferença importante é que SOAP quase sempre usa HTTP POST, mesmo para operações de leitura.

O ponto central é o WSDL. Um WSDL, ou Web Services Description Language, é o contrato que descreve:

  • operações disponíveis;
  • formato exato das requisições;
  • formato esperado das respostas;
  • namespaces;
  • endpoint real do serviço;
  • binding e protocolo de transporte.

Ao testar SOAP, trate o WSDL como seu mapa. Um bom testador SOAP online importa o WSDL e gera modelos de requisição, evitando que você escreva envelopes manualmente. Se quiser entender melhor esse tipo de contrato, veja também este guia sobre teste de contrato de API.

Como uma requisição SOAP realmente se parece

Aqui está uma requisição SOAP realista para um serviço de conversão de moeda:

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>
Enter fullscreen mode Exit fullscreen mode

A resposta segue o mesmo padrão:

<?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>
Enter fullscreen mode Exit fullscreen mode

Ao testar, valide pelo menos estes pontos:

HTTP status: 200
Content-Type: text/xml ou application/soap+xml
Ausência de <soap:Fault>
Presença do elemento esperado no Body
Valor retornado compatível com o cenário
Enter fullscreen mode Exit fullscreen mode

Dois detalhes costumam causar erro:

  1. Muitos serviços exigem o cabeçalho HTTP SOAPAction.
  2. Uma falha SOAP pode vir com HTTP 200.

Ou seja: verificar apenas o status HTTP não é suficiente. Seu teste precisa analisar o XML da resposta e procurar por <soap:Fault>. É aqui que asserções de API estruturadas fazem diferença.

Ferramentas online para testar APIs SOAP

Apidog

Apidog lida com SOAP junto com REST, GraphQL e WebSocket em um único lugar.

Fluxo prático:

  1. Importe o WSDL.
  2. Escolha a operação SOAP.
  3. Edite os parâmetros gerados.
  4. Configure headers como Content-Type, SOAPAction e autenticação.
  5. Envie a requisição.
  6. Adicione asserções sobre elementos XML.
  7. Encadeie chamadas em um cenário.
  8. Execute como teste automatizado.

Como o Apidog também projeta e simula APIs, você pode simular uma resposta SOAP antes que o serviço real esteja pronto. Baixe o Apidog para testar serviços SOAP na versão gratuita.

SoapUI

SoapUI é uma das ferramentas mais tradicionais para teste SOAP. Você aponta para um WSDL, e ele cria um projeto com as operações disponíveis.

Use SoapUI quando precisar de:

  • testes funcionais SOAP;
  • execução orientada a dados;
  • validações detalhadas de XML;
  • suporte amplo a cenários SOAP legados.

A edição open source é gratuita e robusta. A experiência é mais pesada por ser uma aplicação desktop Java, e relatórios mais avançados ficam na versão paga ReadyAPI. Para mais contexto, veja o que é o SoapUI e como funciona.

Postman

Postman pode enviar requisições SOAP, mas exige configuração manual.

Checklist mínimo no Postman:

  1. Método: POST.
  2. Body: raw.
  3. Tipo: XML.
  4. Header Content-Type: text/xml; charset=utf-8.
  5. Header SOAPAction, se o serviço exigir.
  6. Envelope SOAP completo no corpo.

Funciona bem para verificações pontuais. Porém, como o Postman não interpreta o WSDL automaticamente, você precisa montar os envelopes por conta própria.

Testadores SOAP baseados em navegador

Ferramentas web leves permitem colar uma URL WSDL e disparar requisições direto do navegador.

Use para:

  • confirmar se o endpoint está ativo;
  • validar rapidamente uma operação;
  • reproduzir um erro simples.

Evite para:

  • regressão automatizada;
  • testes orientados a dados;
  • asserções complexas;
  • organização de suítes de teste.

Um fluxo de trabalho rápido para testes SOAP

Siga este fluxo para testar uma API SOAP sem perder tempo com XML manual.

1. Obtenha o WSDL

Muitos serviços expõem o WSDL adicionando ?wsdl ao endpoint:

https://example.com/CurrencyService.asmx?wsdl
Enter fullscreen mode Exit fullscreen mode

Abra no navegador e confirme que o XML carrega.

2. Importe o WSDL na ferramenta

Use uma ferramenta como Apidog ou SoapUI para importar o contrato. Ela deve gerar modelos de requisição para cada operação.

3. Escolha uma operação

Exemplo:

ConvertAmount
Enter fullscreen mode Exit fullscreen mode

Verifique os parâmetros esperados:

FromCurrency
ToCurrency
Amount
Enter fullscreen mode Exit fullscreen mode

4. Preencha valores reais

Exemplo:

<cur:FromCurrency>USD</cur:FromCurrency>
<cur:ToCurrency>EUR</cur:ToCurrency>
<cur:Amount>250.00</cur:Amount>
Enter fullscreen mode Exit fullscreen mode

Evite começar com dados fictícios inválidos. Primeiro valide o caminho feliz.

5. Configure os headers

Headers comuns:

Content-Type: text/xml; charset=utf-8
SOAPAction: "https://rates.example.com/ConvertAmount"
Enter fullscreen mode Exit fullscreen mode

Se a API usa SOAP 1.2, o Content-Type pode ser:

Content-Type: application/soap+xml; charset=utf-8
Enter fullscreen mode Exit fullscreen mode

6. Envie e inspecione o corpo

Não pare no status HTTP. Abra o XML de resposta e procure por:

<soap:Fault>
Enter fullscreen mode Exit fullscreen mode

Se existir, a chamada falhou, mesmo que o HTTP status seja 200.

7. Adicione asserções

Em um cenário de sucesso, valide:

  • ausência de <soap:Fault>;
  • existência do elemento de resposta;
  • valor esperado;
  • tipo ou formato do valor;
  • tempo de resposta, se relevante.

Exemplo de expectativa:

Não deve existir: //soap:Fault
Deve existir: //cur:ConvertAmountResult
Valor esperado: 231.45
Enter fullscreen mode Exit fullscreen mode

Para organizar esses testes em uma suíte sustentável, veja este guia sobre construção de conjuntos de testes para automação de API.

Falhas SOAP e como asserir sobre elas

Uma falha SOAP é a estrutura de erro do protocolo. Ela normalmente contém:

  • faultcode;
  • faultstring;
  • detail, quando há informações adicionais.

Exemplo:

<soap:Fault>
  <faultcode>soap:Client</faultcode>
  <faultstring>Invalid currency code</faultstring>
  <detail>
    <errorCode>UNSUPPORTED_CURRENCY</errorCode>
  </detail>
</soap:Fault>
Enter fullscreen mode Exit fullscreen mode

Como essa falha pode chegar com HTTP 200, uma automação que valida apenas o status cria falsos positivos.

Em testes de sucesso, adicione uma asserção como:

<soap:Fault> não deve existir
Enter fullscreen mode Exit fullscreen mode

Em testes de erro esperado, valide o oposto:

<soap:Fault> deve existir
faultcode deve ser soap:Client
faultstring deve conter Invalid currency code
Enter fullscreen mode Exit fullscreen mode

Isso é importante porque serviços SOAP frequentemente representam regras de negócio como falhas, por exemplo:

  • transação recusada;
  • cartão vencido;
  • moeda não suportada;
  • token inválido;
  • usuário sem permissão.

A documentação de falhas SOAP do W3C descreve a estrutura formal.

Atenção ao WS-Security

Muitos serviços SOAP empresariais exigem WS-Security. Nesses casos, a autenticação pode estar dentro do Header, não apenas em um header HTTP comum.

Exemplo simplificado:

<soap:Header>
  <wsse:Security>
    <wsse:UsernameToken>
      <wsse:Username>usuario</wsse:Username>
      <wsse:Password>senha</wsse:Password>
    </wsse:UsernameToken>
  </wsse:Security>
</soap:Header>
Enter fullscreen mode Exit fullscreen mode

Se suas chamadas retornarem falha de autenticação, verifique:

  • o WSDL;
  • a documentação do serviço;
  • o perfil WS-Security exigido;
  • necessidade de assinatura;
  • token;
  • certificado;
  • timestamp;
  • namespace correto.

Ferramentas como SoapUI e Apidog permitem configurar esses headers sem escrever todo o XML manualmente.

Lendo um WSDL sem se perder

Um WSDL pode parecer intimidador, mas você não precisa ler tudo. Foque em quatro partes.

types

Define as estruturas de dados, geralmente com XML Schema.

Procure aqui:

  • campos obrigatórios;
  • tipos;
  • tamanho máximo;
  • enumerações;
  • formatos aceitos.

message

Descreve as mensagens de entrada e saída.

Use para entender:

  • request;
  • response;
  • parâmetros esperados;
  • elemento raiz da operação.

portType

Lista as operações disponíveis.

Exemplo:

ConvertAmount
GetExchangeRate
ValidateCurrency
Enter fullscreen mode Exit fullscreen mode

binding e service

Indicam:

  • protocolo;
  • formato da mensagem;
  • endpoint real;
  • endereço para envio da requisição.

Um detalhe importante: um WSDL pode importar outros arquivos:

<xs:import namespace="..." schemaLocation="..."/>
Enter fullscreen mode Exit fullscreen mode

Se a ferramenta informar que um tipo está ausente, provavelmente algum schema importado não foi resolvido. Verifique se todas as URLs referenciadas estão acessíveis a partir do ambiente onde a ferramenta está rodando.

Teste SOAP orientado a dados

Uma única chamada de caminho feliz raramente cobre o comportamento real de um serviço SOAP.

Para um serviço de moeda, teste pelo menos:

Caso FromCurrency ToCurrency Amount Esperado
Conversão válida USD EUR 250.00 Sucesso
Moeda inválida USD XXX 250.00 Falha
Valor zero USD EUR 0 Regra esperada
Valor negativo USD EUR -10 Falha

Para um serviço de pagamento, teste:

Caso Entrada Esperado
Cartão aprovado cartão válido sucesso
Cartão recusado cartão recusado falha de negócio
Cartão vencido validade expirada falha
Token inválido auth inválida falha de segurança

O padrão é:

  1. Criar uma requisição SOAP com placeholders.
  2. Alimentar a execução com uma tabela de dados.
  3. Executar uma chamada para cada linha.
  4. Validar a resposta esperada por caso.

Exemplo conceitual de placeholders:

<cur:ConvertAmount>
  <cur:FromCurrency>{{fromCurrency}}</cur:FromCurrency>
  <cur:ToCurrency>{{toCurrency}}</cur:ToCurrency>
  <cur:Amount>{{amount}}</cur:Amount>
</cur:ConvertAmount>
Enter fullscreen mode Exit fullscreen mode

O SoapUI suporta esse padrão há anos, e o Apidog também permite executá-lo por meio de cenários. Para o padrão mais amplo, veja este guia sobre teste de API orientado a dados com CSV e JSON.

Checklist para depurar erros SOAP

Quando uma requisição SOAP falhar, revise nesta ordem:

  1. O WSDL carrega corretamente?
  2. O endpoint usado é o mesmo definido em service?
  3. O método HTTP é POST?
  4. O Content-Type está correto para SOAP 1.1 ou SOAP 1.2?
  5. O SOAPAction está presente quando exigido?
  6. Os namespaces do envelope estão corretos?
  7. A operação está no namespace certo?
  8. Todos os campos obrigatórios foram enviados?
  9. O serviço exige WS-Security?
  10. A resposta contém <soap:Fault>?
  11. O faultstring indica erro de autenticação, schema ou regra de negócio?

Perguntas frequentes

Qual a diferença entre o teste SOAP e REST?

O teste SOAP trabalha com um protocolo XML rígido, contrato WSDL, envelopes obrigatórios e falhas retornadas dentro do corpo da resposta. O teste REST geralmente usa JSON, convenções mais flexíveis e códigos HTTP mais significativos. Em SOAP, sempre analise o corpo da resposta para confirmar se a chamada realmente foi bem-sucedida.

Preciso do WSDL para testar uma API SOAP?

Você pode enviar uma requisição SOAP sem WSDL se souber exatamente como montar o envelope. Mas o WSDL facilita muito, porque ferramentas conseguem gerar modelos corretos automaticamente. A maioria dos serviços expõe o WSDL adicionando ?wsdl à URL do endpoint.

Por que minha requisição SOAP retorna uma falha mesmo com status 200?

Porque SOAP pode reportar erros como <soap:Fault> dentro do corpo da resposta, mesmo com HTTP 200. Causas comuns incluem SOAPAction ausente ou incorreto, envelope malformado, namespace errado, parâmetro inválido ou falha de autenticação.

Posso testar APIs SOAP online gratuitamente?

Sim. Apidog suporta SOAP na versão gratuita e importa arquivos WSDL. A edição open source do SoapUI também é voltada para SOAP. Testadores baseados em navegador servem para verificações rápidas, mas têm limitações em automação e asserções.

Como automatizo testes de API SOAP?

Importe o WSDL, crie cenários com as operações necessárias, adicione asserções sobre o XML da resposta, valide a ausência ou presença de <soap:Fault> e execute a suíte no runner da ferramenta ou em um pipeline de CI. SoapUI e Apidog suportam esse tipo de fluxo para regressão SOAP.

Top comments (0)