SoapUI - Guia rápido

SOAP é a sigla para Simple Object Access Protocol. É definido pelo World Wide Web Consortium (W3C) emhttps://www.w3.org/TR/2000/NOTE-SOAP-20000508 como segue -

SOAP é um protocolo leve para a troca de informações em um ambiente distribuído descentralizado. É um protocolo baseado em XML que consiste em três partes: um envelope que define uma estrutura para descrever o que está em uma mensagem e como processá-la; um conjunto de regras de codificação para expressar instâncias de tipos de dados definidos pelo aplicativo; e uma convenção para representar chamadas e respostas de procedimento remoto.

SOAP - Recursos importantes

A seguir estão alguns recursos importantes do SOAP.

É um protocolo de comunicação projetado para se comunicar via Internet.
Ele pode estender HTTP para mensagens XML.
Ele fornece transporte de dados para serviços da web.
Pode trocar documentos completos ou chamar um procedimento remoto.
Ele pode ser usado para transmitir uma mensagem.
É independente de plataforma e linguagem.
É a maneira XML de definir quais informações são enviadas e como.
Ele permite que aplicativos cliente se conectem facilmente a serviços remotos e invoquem métodos remotos.

Embora o SOAP possa ser usado em uma variedade de sistemas de mensagens e possa ser entregue por meio de uma variedade de protocolos de transporte, o foco inicial do SOAP são as chamadas de procedimento remoto transportadas via HTTP. Outras estruturas, como CORBA, DCOM e Java RMI, fornecem funcionalidade semelhante ao SOAP, mas as mensagens SOAP são escritas inteiramente em XML e, portanto, são exclusivamente independentes de plataforma e linguagem.

Uma mensagem SOAP é um documento XML comum contendo os seguintes elementos -

Envelope- Define o início e o fim da mensagem. É um elemento obrigatório.
Header- Contém quaisquer atributos opcionais da mensagem usados no processamento da mensagem, seja em um ponto intermediário ou no ponto final final. É um elemento opcional.
Body- Contém os dados XML que constituem a mensagem enviada. É um elemento obrigatório.
Fault - Um elemento Fault opcional que fornece informações sobre erros que ocorrem durante o processamento da mensagem.

Todos esses elementos são declarados no namespace padrão para o envelope SOAP -

https://www.w3.org/2001/12/soap-envelope

O namespace padrão para codificação SOAP e tipos de dados é -

https://www.w3.org/2001/12/soap-encoding

Note- Todas essas especificações estão sujeitas a alterações. Portanto, mantenha-se atualizado com as especificações mais recentes disponíveis no site W3.

SOAP - Estrutura da Mensagem

O bloco a seguir descreve a estrutura geral de uma mensagem SOAP -

<?xml version = "1.0"?> 
<SOAP-ENV:Envelope 
xmlns:SOAP-ENV = "http://www.w3.org/2001/12/soap-envelope" 
SOAP-ENV:encodingStyle = "http://www.w3.org/2001/12/soap-encoding">  
   <SOAP-ENV:Header> 
      ... 
      ... 
   </SOAP-ENV:Header>  
   <SOAP-ENV:Body> 
      ... 
      ... 
      <SOAP-ENV:Fault> 
         ... 
         ... 
      </SOAP-ENV:Fault>  
   </SOAP-ENV:Body>  
</SOAP_ENV:Envelope>

REST é a sigla para Representational State Transfer. Pode ser definido como um estilo arquitetônico de design de softwares. REST não é uma especificação ou padrão W3C. Portanto, é mais fácil trabalhar com RESTful Services. Não requer nenhuma estrutura de especificação de middleware.

REST - Recursos importantes

A seguir estão alguns recursos importantes do REST.

Ele se baseia em protocolo de comunicação sem estado, cliente-servidor, que pode ser armazenado em cache - virtualmente em todos os casos, o HTTP é usado.
É uma alternativa leve de WebService e RPC (Remote Procedure Call) como SOAP-WSDL.
Ele representa tudo em ID ou URIs exclusivos.
Faz o uso de métodos HTTP padrão, como GET, POST, PUT, DELETE.
Ele liga as fontes.
Os recursos REST podem ter várias representações.
Qualquer informação nomeada é considerada um recurso. Por exemplo: Uma imagem, uma pessoa, um documento, todos podem ser considerados como um exemplo de recurso e representados como um ID único ou um URI.
A própria World Wide Web, baseada em HTTP, pode ser vista como uma arquitetura baseada em REST.

Os serviços REST são independentes da plataforma e do idioma. Por ser baseado em padrões HTTP, pode funcionar facilmente na presença de firewalls. Como WebServices, REST não oferece nenhuma segurança embutida, gerenciamento de sessão, garantia de QoS, mas eles podem ser adicionados construindo sobre HTTP. Para criptografia, REST pode ser usado em cima de HTTPS.

SoapUI é uma ferramenta que pode ser usada para testes funcionais e não funcionais. Não se limita a serviços da web, embora seja a ferramenta de fato usada em testes de serviços da web.

SoapUI - Recursos importantes

A seguir estão alguns recursos importantes do SoapUI.

É capaz de desempenhar o papel de cliente e serviço.
Ele permite que os usuários criem testes funcionais e não funcionais de forma rápida e eficiente em um único ambiente.
Ele é licenciado sob os termos da GNU Leaser General Public License (LGPL).
É puramente implementado usando a plataforma JAVA.
Suporta Windows, Mac, vários dialetos Linux.
Ele permite que os testadores executem testes funcionais, de regressão, de conformidade e de carga automatizados em diferentes APIs da Web.
Ele oferece suporte a todos os protocolos e tecnologias padrão para testar todos os tipos de APIs.

SoapUI pode ser usado para testar testes completos de API RESTful e serviço da Web SOAP. Suporta testes funcionais, testes de desempenho, testes de interoperabilidade, testes de regressão, testes de carga e muito mais.

É amigável e fácil de converter testes funcionais em testes não funcionais, como testes de carga e estresse.

SoapUI é rico nos cinco aspectos a seguir -

Teste funcional
Teste de Segurança
Teste de carga
Protocolos e tecnologias
Integração com outras ferramentas

Vamos aprender mais sobre cada um desses recursos.

Teste funcional

SoapUI permite que os testadores escrevam testes funcionais de API em SoapUI.
SoapUI suporta o recurso Drag-Drop que acelera o desenvolvimento do script.
SoapUI oferece suporte à depuração de testes e permite que os testadores desenvolvam testes orientados a dados.
SoapUI oferece suporte a vários ambientes, facilitando a alternância entre ambientes QA, Dev e Prod.
SoapUI permite scripts avançados (o testador pode desenvolver seu código customizado dependendo dos cenários).

Teste de Segurança

SoapUI executa um conjunto completo de varredura de vulnerabilidade.
SoapUI impede a injeção de SQL para proteger os bancos de dados.
O SoapUI verifica estouros de pilha, causados por documentos de grande tamanho.
O SoapUI verifica a existência de scripts entre sites, que ocorre quando os parâmetros de serviço são expostos nas mensagens.
SoapUI executa varredura difusa e varredura de limite para evitar o comportamento errático dos serviços.

Teste de carga

SoapUI distribui os testes de carga em um número n de agentes LoadUI.
SoapUI simula alto volume e testes de carga do mundo real com facilidade.
SoapUI permite relatórios personalizados avançados para capturar parâmetros de desempenho.
SoapUI permite o monitoramento de desempenho do sistema de ponta a ponta.

Protocolos e tecnologias

SoapUI oferece suporte a uma ampla gama de protocolos -

SOAP - Protocolo de Acesso a Objetos Simples
WSDL - linguagem de definição de serviço da Web
REST - Transferência de Estado Representacional
HTTP - protocolo de transmissão de hipertexto
HTTPS - protocolo de transmissão de hipertexto protegido
AMF - Formato de Mensagem de Ação
JDBC - conectividade de banco de dados Java
JMS - Java Messaging Service

Integração com outras ferramentas

Projeto Apache Maven
HUDSON
JUnit
Apache - Formiga e mais….

SoapUI é uma ferramenta de versão gratuita de código aberto com recursos básicos de teste, enquanto SoapUI NG Pro é uma ferramenta comercializada com recursos avançados de relatórios, funcionalidade orientada a dados e muito mais.

Comparação

A tabela a seguir compara e contrasta os vários recursos do SoapUI e do SoapUI NG Pro.

Características	SoapUI	SoapUI NG Pro
Supported Technologies
SABONETE	sim	sim
WSDL / WADL	sim	sim
DESCANSAR	sim	sim
JMS	sim	sim
AMF	sim	sim
JDBC	sim	sim
HTTP	sim	sim
General Features
Aplicativo autônomo	sim	sim
Suporte a vários ambientes	Não	sim
Licença Flutuante	Não	sim
Cobertura WSDL	Não	sim
Cobertura de solicitação / resposta	Não	sim
Asserção de Mensagem	sim	sim
Refatoração de Teste	Não	sim
Executando vários testes	sim	sim
Teste baseado na fonte de dados	Não	sim
Bibliotecas de scripts	Não	sim
Relatório de Unidade	Não	sim
Etapas de teste manual	sim	sim
Reporting
Relatórios Junit	Não	sim
Relatório de exportação de dados	Não	sim
Relatório HTML WSDL	sim	sim
Cobertura do Test Suite	Não	sim
Cobertura de caso de teste	Não	sim
Cobertura de afirmação	Não	sim
Cobertura de gravação de mensagens	Não	sim

SoapUI é uma ferramenta de plataforma cruzada. Suporta sistemas operacionais Windows, Linux e Mac.

Pré-requisitos

Processor - Processador de 1 GHz ou superior de 32 ou 64 bits.
RAM - 512 MB de RAM.
Hard Disk Space - Mínimo 200 MB de espaço no disco rígido para instalação.
Operating System Version - Windows XP ou posterior, MAC OS 10.4 ou posterior.
JAVA - JAVA 6 ou posterior.

Processo de download

Step 1- Acesse www.soapui.org e clique em Baixar SoapUI.

Step 2- Clique em 'Get It' para baixar o código aberto do SoapUI. O download do arquivo .exe de 112 MB será iniciado no sistema. Espere até que o processo de download seja concluído.

Processo de Instalação

Step 1 - Após o download, execute o arquivo .exe como “Executar como administrador”.

O Windows iniciará o processo de configuração conforme mostrado na imagem a seguir.

Step 2 - Uma vez configurado, a janela de processo exibe a seguinte tela, clique em Avançar.

Step 3 - Aceite o contrato de licença e clique em Avançar.

Step 4- Escolha o diretório de instalação ou mantenha-o como o caminho padrão selecionado pelo sistema. Clique em Avançar.

Step 5- Escolha os componentes que deseja instalar. Clique em Avançar.

Step 6 - Aceite o Contrato de Licença do HermesJMS e clique em Avançar.

Step 7 - Selecione o diretório de destino para salvar os tutoriais e clique em Avançar.

Step 8 - Escolha o local da pasta do menu iniciar ou deixe o local padrão como está e clique em 'Avançar'.

Step 9 - Ative a caixa de seleção 'criar um ícone na área de trabalho' e clique em 'Avançar'.

Agora, a instalação começa. Isso levará alguns minutos para ser concluído.

Step 10 - Após a conclusão da instalação, clique em Concluir no assistente a seguir.

Ao clicar em Concluir, o SoapUI é iniciado.

Barra de menu
Barra de ferramentas
Barra de Navegação do Projeto
Propriedades do espaço de trabalho
Painel de Log

Processo de Configuração

A primeira etapa é criar um espaço de trabalho que pode conter vários projetos.

Step 1 - Vá para Arquivo → Novo espaço de trabalho.

Step 2 - Adicione o nome do espaço de trabalho e clique em OK.

Step 3 - Agora, selecione o caminho onde o xml do espaço de trabalho será salvo.

Step 4 - Selecione o caminho e clique em Salvar.

O espaço de trabalho é criado conforme mostrado na captura de tela a seguir. As propriedades do espaço de trabalho também são exibidas.

WSDL significa Web Services Description Language. É um formato padrão para descrever um serviço da web. WSDL foi desenvolvido em conjunto pela Microsoft e IBM. WSDL é pronunciado como 'wiz-dull' e soletrado como 'WSD-L'.

WSDL ─ Uma breve história

WSDL 1.1 foi submetido como uma nota W3C pela Ariba, IBM e Microsoft para descrever os serviços para a atividade XML W3C em protocolos XML em março de 2001.

WSDL 1.1 não foi endossado pelo World Wide Web Consortium (W3C), no entanto, acaba de lançar um rascunho para a versão 2.0 que será uma recomendação (um padrão oficial) e, portanto, endossado pelo W3C.

WSDL ─ pontos a serem observados

WSDL é um protocolo baseado em XML para troca de informações em um ambiente descentralizado e distribuído. Alguns dos outros recursos do WSDL são os seguintes -

As definições WSDL descrevem como acessar um serviço da web e quais operações ele executará.
É uma linguagem para descrever como interagir com serviços baseados em XML.
É parte integrante da Universal Description, Discovery, and Integration (UDDI), um registro de negócios mundial baseado em XML.
WSDL é a linguagem que o UDDI usa.

Uso WSDL

WSDL é freqüentemente usado em combinação com SOAP e XML Schema para fornecer serviços da web pela Internet. Um programa cliente que se conecta a um serviço da web pode ler o WSDL para determinar quais funções estão disponíveis no servidor. Quaisquer tipos de dados especiais usados são incorporados ao arquivo WSDL na forma de Esquema XML. O cliente pode então usar o SOAP para realmente chamar uma das funções listadas no WSDL.

Compreendendo WSDL

WSDL divide os serviços da web em três elementos específicos e identificáveis que podem ser combinados ou reutilizados uma vez definidos.

Os três principais elementos do WSDL que podem ser definidos separadamente são -

Types
Operations
Binding

Um documento WSDL possui vários elementos, mas eles estão contidos nesses três elementos principais, que podem ser desenvolvidos como documentos separados e, em seguida, podem ser combinados ou reutilizados para formar arquivos WSDL completos.

Neste tutorial, estamos seguindo CurrencyConverter WSDL: http://www.webservicex.net

Formato e Elementos

O WSDL de CurrencyConverter será semelhante ao seguinte -

WSDL ─ Tipo de porta

O elemento <portType> combina vários elementos de mensagem para formar uma operação unidirecional completa ou de ida e volta. Por exemplo, um <portType> pode combinar uma solicitação e uma mensagem de resposta em uma única operação de solicitação / resposta. Isso é mais comumente usado em serviços SOAP. Um portType pode definir várias operações.

Exemplo

O elemento portType define uma única operação, chamada ConversionRate.
A operação consiste em uma única mensagem de entrada ConversionRateHttpPostIn.
A operação para mensagem de saída é ConversionRateHttpPostOut.

Padrões de Operação

WSDL suporta quatro padrões básicos de operação -

Mão Única

O serviço recebe uma mensagem. A operação, portanto, tem um único elemento de entrada. A gramática para operação unilateral é -

<wsdl:definitions .... >  
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Solicitar ─ Resposta

O serviço recebe uma mensagem e envia uma resposta. A operação, portanto, tem um elemento de entrada, seguido por um elemento de saída. Para encapsular erros, um elemento opcional de falha também pode ser especificado. A gramática para uma operação de solicitação-resposta é -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Solicitar ─ Resposta

O serviço envia uma mensagem e recebe uma resposta. A operação, portanto, tem um elemento de saída, seguido por um elemento de entrada. Para encapsular erros, um elemento opcional de falha também pode ser especificado. A gramática para uma operação de solicitação de resposta é -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken" parameterOrder = "nmtokens"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
         <wsdl:input name = "nmtoken"? message = "qname"/> 
         <wsdl:fault name = "nmtoken" message = "qname"/>* 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

Notificações

O serviço envia uma mensagem. A operação, portanto, tem um único elemento de saída. A seguir está a gramática para uma operação de notificação -

<wsdl:definitions .... > 
   <wsdl:portType .... > * 
      <wsdl:operation name = "nmtoken"> 
         <wsdl:output name = "nmtoken"? message = "qname"/> 
      </wsdl:operation> 
   </wsdl:portType > 
</wsdl:definitions>

WSDL ─ Ligação e serviço

o <binding>O elemento fornece detalhes específicos sobre como uma operação portType será realmente transmitida pela rede.

As ligações podem ser disponibilizadas por meio de vários transportes, incluindo HTTP GET, HTTP POST ou SOAP.
As ligações fornecem informações concretas sobre qual protocolo está sendo usado para transferir operações portType.
As ligações fornecem informações sobre onde o serviço está localizado.
Para o protocolo SOAP, a ligação é <soap: binding> e o transporte são mensagens SOAP no topo do protocolo HTTP.
Você pode especificar várias ligações para um único portType.

Serviço

o <service>elemento define as portas suportadas pelo serviço da web. Para cada um dos protocolos suportados, há um elemento de porta. O elemento de serviço é uma coleção de portas.

Os clientes de serviço da Web podem aprender o seguinte com o elemento de serviço -

Onde acessar o serviço,
Por meio de qual porta acessar o serviço da web, e
Como as mensagens de comunicação são definidas.

O elemento de serviço inclui um elemento de documentação para fornecer documentação legível por humanos.

<wsdl:service name = "CurrencyConvertor">
   <wsdl:port name = "CurrencyConvertorSoap" binding = "tns:CurrencyConvertorSoap">
      <soap:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorSoap12"binding = "tns:CurrencyConvertorSoap12>
      <soap12:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:port name = "CurrencyConvertorHttpGet" binding = "tns:CurrencyConvertorHttpGet">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port>
   <wsdl:portname = "CurrencyConvertorHttpPost"binding = "tns:CurrencyConvertorHttpPost">
      <http:address location = "http://www.webservicex.net/CurrencyConvertor.asmx" />
   </wsdl:port> 
</wsdl:service>

O projeto SoapUI é o ponto central em todos os testes SoapUI. Depois que o projeto é criado, o usuário pode criar e executar testes funcionais, testes de carga, criar serviços simulados e muito mais.

Neste capítulo, discutiremos duas coisas - Como -

Crie um projeto SOAP
Adicionar um WSDL

Crie um projeto SOAP

Step 1 - No navegador do lado esquerdo da tela, clique com o botão direito do mouse em “Projeto” e selecione “Novo Projeto SOAP”.

Ou vá para Arquivo e selecione Novo Projeto de Sabão.

Na seleção, uma nova janela pop-up abre -Novo projeto de sabonete.

Step 2 - Project Name: Insira um nome de projeto - é o campo de entrada do usuário. Initial WSDL: Não é obrigatório. Depende do usuário. O usuário pode fornecer WSDL ou adicionar após a criação do Projeto.

Nesse caso, criamos um projeto e adicionamos o WSDL posteriormente.

Step 3- Clique em OK. Ele criará um novo projeto e ficará visível no painel de navegação do lado esquerdo.

Adicionar um WSDL

Projetos SOAP são baseados em WSDL. Não é necessário começar importando um WSDL, mas torna o teste mais fácil, pois o WSDL contém todas as informações necessárias para testar um serviço da web, como informações sobre as solicitações e respostas, o que elas contêm e muito mais, o que simplifica o teste de SoapUI.

Step 1 - Para adicionar um WSDL, clique com o botão direito no nome do Projeto (SOAP - Exemplo) e selecione Adicionar WSDL.

Na seleção, o assistente WSDL é exibido.

Step 2 - WSDL Location: Insira um WSDL como http://www.webservicex.com ou navegue no computador.

Step 3- Assim que WSDL for inserido, 3 caixas de seleção - Criar Solicitações, Criar TestSuite, Criar MockServices serão habilitadas. Com base na necessidade, o usuário pode marcar uma ou várias caixas de seleção.

Por padrão, a caixa de seleção Criar solicitações está marcada.

Step 4- Clique em OK. WSDL foi adicionado com sucesso no projeto. Isso pode ser verificado observando o painel de navegação esquerdo. Dentro do projeto, existem várias operações e as solicitações são adicionadas de acordo com WSDL.

Visualização de detalhes

Para obter mais detalhes do Projeto, clique duas vezes no Nome do Projeto, uma nova janela será aberta com vários detalhes.

Na guia Visão geral, várias informações são fornecidas, como -

File Path - Exibe a localização do xml do projeto salvo.
Interface Summary - Nome da interface e WSDL associado a ela.
Test Summary - Exibe suítes de teste, casos de teste, etapas de teste, asserções adicionadas ao projeto.

O usuário pode clicar duas vezes no nome da interface para obter os detalhes da interface. Ele abrirá uma nova janela e exibirá as informações relacionadas ao WSDL. Eles são muito úteis para navegar e examinar um WSDL.

Na guia Visão geral, ela lista Definições WSDL, partes de definição e detalhes de operação.

Da mesma forma, Service Endpoints lista os detalhes dos endpoints.

Na guia Conteúdo WSDL, todos os detalhes de WSDL no formato XML / esquema são fornecidos conforme mostrado na captura de tela a seguir.

TestSuiteé uma coleção de casos de teste que podem ser usados para agrupar testes funcionais em unidades lógicas. Qualquer número de TestSuites pode ser criado dentro de um projeto SoapUI para suportar cenários de teste massivos.

Criação do TestSuite

Step 1 - Em um projeto, clique com o botão direito do mouse na interface (ao lado do nome do projeto) e clique em 'Gerar TestSuite'.

Aqui, SOAP - Exemplo é um nome de projeto enquanto CurrencyConvertorSoap e CurrencyConvertorSoap12 são interfaces.

Step 2- Um novo assistente é aberto. Selecione as opções com base no requisito.

Step 3 - Depois de fazer a seleção, clique em OK.

Step 4- Marque a caixa de seleção de Generate LoadTest. Isso irá gerar um LoadTest para cada TestCase criado neste TestSuite.

Step 5 - Digite o nome do TestSuite no novo assistente e clique em OK.

O TestSuite criado é exibido no painel de navegação, conforme mostrado na captura de tela a seguir.

Step 6- Clique duas vezes no Nome do TestSuite e a janela TestSuite será aberta no painel direito. Como nenhum TestCases é adicionado, ele fica em branco.

As propriedades do TestSuite podem ser vistas na parte inferior do painel de navegação. Novas propriedades personalizadas podem ser adicionadas no nível do TestSuite.

Um TestCase é uma coleção de TestSteps montados para testar algum aspecto específico de serviço (s) da web. O usuário pode adicionar n número de TestCases a um TestSuite e até mesmo modularizá-los para chamar uns aos outros para cenários de teste complexos.

Criação de TestCase

Step 1- Dentro de um TestSuite, o usuário pode adicionar vários casos de teste. Clique com o botão direito no Test Suite e selecione “New Test Case”.

Step 2 - Insira o nome do TestCase e clique em OK.

O TestCase criado tem zero etapas de teste a partir de agora. TestCase é adicionado com zero TestSteps para todos os tipos de testes disponíveis. Assim que os TestSteps forem adicionados, os números entre colchetes mudariam automaticamente. O TestStep funcional deve ir para 'Etapas de teste', enquanto um TestStep de desempenho deve ir para 'Teste de carga', e um TestStep de segurança deve ir para 'Testes de segurança'.

Step 3- Clique duas vezes no Nome do TestCase e uma janela TestCase será aberta no painel do lado direito. Como não há TestSteps adicionados, ele está em branco, conforme visto na imagem a seguir.

TestSteps são os "blocos de construção" dos testes funcionais no SoapUI. Eles são adicionados a um TestCase e usados para controlar o fluxo de execução e validar a funcionalidade do (s) serviço (s) da web a ser testado.

Inserção de TestStep

Step 1- Clique com o botão direito em TestSteps. Adicione Step e selecione um TestStep apropriado na lista. Por exemplo, se o usuário tiver que testar um WebService REST, ele selecionará a Solicitação de Teste REST.

Step 2 - Adicione um TestStep para validar a solicitação SOAP importada, selecionando TestSteps → Adicionar etapa → Solicitação SOAP.

Step 3 - Insira o nome do TestStep e clique em OK no assistente.

Ao clicar em 'OK', uma caixa de diálogo aparece para selecionar a operação a ser chamada. Todas as operações são listadas e os usuários podem selecionar a operação que gostariam de invocar.

Existem duas operações que serão listadas. Ambas as operações são iguais, exceto a versão SOAP usada.CurrencyConvertorSoap usa SOAP versão 1.1 enquanto, CurrencyConvertorSoap12 usa SOAP versão 1.2.

Step 4 - Selecione o primeiro - CurrencyConvertorSoap e clique em OK.

Ao adicionar um TestCase, diferentes asserções padrão podem ser adicionadas. As asserções também são chamadas de pontos de verificação / pontos de validação de solicitação / resposta SOAP.

Step 5 - Vamos criar um TestCase com uma opção padrão, o que significa criar um TestStep SEM nenhum dos seguintes pontos de validação -

Verifica se a mensagem de resposta é SOAP, ao executar o teste.
Verifica se o esquema de resposta é válido.
Verifica se a resposta SOAP contém FAULT.

Step 6 - Ao clicar em OK, a seguinte captura de tela do XML de solicitação é exibida.

A contagem de etapas de teste agora é incrementada para um como um TestStep funcional adicionado. Da mesma forma, ao adicionar TestSteps de carga e segurança, o número correspondente aumenta automaticamente com base no número de etapas adicionadas.

Solicitar configuração

Aqui, faremos a conversão da moeda de INR para USD.

FromCurrency - INR
ToCurrency - USD

Em seguida, insira essas entradas no lugar do ponto de interrogação que será enviado como um XML de solicitação. Depois de colocar esses valores nas tags XML correspondentes, clique no botão 'Enviar solicitação' para verificar a resposta.

Resposta

Ao enviar uma solicitação, a solicitação de serviço da web é processada pelo servidor da web e envia de volta uma resposta, conforme mostrado na captura de tela a seguir.

Ao ler a resposta, pode-se concluir que 1 unidade de INR = 0,0147 unidades de USD.

Pedido HTTP

As mensagens SOAP são transportadas pelo protocolo HTTP. Para visualizar a solicitação HTTP, clique em RAW na janela Solicitação SoapUI (lado esquerdo).

A solicitação é postada no servidor da web. Portanto, o método POST de Http é usado.

A solicitação SOAP é transportada no corpo da mensagem http, que é mostrada a seguir.

POST http://www.webservicex.com/currencyconvertor.asmx HTTP/1.1 
Accept-Encoding: gzip,deflate 
Content-Type: text/xml;charset = UTF-8 
SOAPAction: "http://www.webserviceX.NET/ConversionRate" 
Content-Length: 353 
Host: www.webservicex.com 
Connection: Keep-Alive 
User-Agent: Apache-HttpClient/4.1.1 (java 1.5)

Resposta HTTP

Clique na guia 'RAW' na janela de resposta SOAP-UI para entender como a resposta é enviada via HTTP.

Depois de processar a solicitação, o código de resposta http (200) é mostrado, o que significa que foi um sucesso. O servidor web processou com sucesso.

A resposta SOAP é enviada de volta ao cliente como parte do corpo da mensagem HTTP.

HTTP/1.1 200 OK 
Cache-Control: private, max-age = 0 
Content-Type: text/xml; charset = utf-8 
Content-Encoding: gzip 
Vary: Accept-Encoding 
Server: Microsoft-IIS/7.0 
X-AspNet-Version: 4.0.30319 
X-Powered-By: ASP.NET 
Date: Sun, 22 Jan 2017 19:39:31 GMT 
Content-Length: 316

Os seguintes códigos HTTP são usados para enviar respostas pelo servidor da Web e são muito úteis para depuração.

Código HTTP	Descrição
1xx:	Informational - Isso significa que uma solicitação foi recebida e há um processo contínuo.
2xx:	Success - A ação foi recebida, compreendida e aceita com sucesso.
3xx:	Redirection - Isso significa que outras ações devem ser tomadas para concluir a solicitação.
4xx:	Client Error - Isso significa que a solicitação contém uma sintaxe incorreta ou não pode ser atendida.
5xx:	Server Error - O servidor falhou em atender a uma solicitação aparentemente válida.

As propriedades são um aspecto central de testes mais avançados com SoapUI. As propriedades do Teste Funcional são usadas para parametrizar a execução e funcionalidade dos testes.

As propriedades podem ser usadas para conter os terminais de serviços, facilitando a alteração dos terminais reais usados durante a execução do teste.
As propriedades podem ser usadas para manter as credenciais de autenticação, facilitando o gerenciamento em um local central ou em um arquivo externo.
As propriedades podem ser usadas para transferir e compartilhar ids de sessão durante a execução do teste, para que várias etapas de teste ou casos de teste possam compartilhar as mesmas sessões.

Definindo Propriedades

As propriedades podem ser definidas em vários níveis em um projeto.

As propriedades que são comuns no nível do projeto podem ser definidas no nível do projeto.
Da mesma forma, as propriedades específicas de TestSuite e TestCase podem ser definidas em seus respectivos níveis.
As propriedades específicas do projeto são definidas na guia Propriedades personalizadas.

Por exemplo, uma propriedade “ToCurrency” pode ser definida no nível do projeto clicando no símbolo "+" e inserindo o nome e o valor da propriedade.

Acessando propriedade

Uma propriedade pode ser acessada em qualquer lugar no Projeto usando a Expansão de Propriedade.

A estrutura seria como -

$ {# Project # PropertyName} - para o nível do projeto
$ {# TestSuite # PropertyName} - para o nível Test Suite
$ {# TestCase # PropertyName} - para o nível do caso de teste
$ {TestStepName # PropertyName} - para o nível da etapa de teste
$ {# MockService # PropertyName} - para a propriedade MockService
$ {# Global # PropertyName} - Para propriedades globais, encontradas em Arquivo → Preferência → guia Propriedades globais. Esta propriedade pode ser usada em todos os projetos
$ {# System # PropertyName} - Para a propriedade do sistema, encontrada em Ajuda → Propriedades do sistema
$ {# Env # PropertyName} - para variável de ambiente

A mesma estrutura pode ser colocada em Request XML para obter o valor de um atributo específico durante o tempo de execução.

Uma propriedade também pode ser considerada uma variável em um programa de computador. Se o usuário quiser definir algo que também possa ser usado em outro lugar, as Propriedades são muito úteis. As propriedades também podem ser definidas dinamicamente, mas dependem do script Groovy.

Às vezes, é necessário extrair algum valor de uma mensagem de resposta e incluí-lo na (s) solicitação (ões) subsequente (s). Nesse caso, precisamos ter um mecanismo para recuperar um valor especificado e transferi-lo para os outros elementos do projeto. SoapUI oferece suporte a essa funcionalidade por meio do Property Transfer TestStep.

Adicionando Transferência de Propriedade

Step 1 - Selecione TestCase ou TestStep, clique com o botão direito → Adicionar etapas → Transferência de propriedade.

Step 2 - Insira o nome TestStep e clique em OK.

Step 3 - A etapa RateTransfer é adicionada e um novo assistente será aberto.

Step 4- Clique no ícone Adiciona um novo ícone de transferência de propriedade + no canto superior esquerdo da janela de transferência de propriedade. Será solicitado que você insira um nome para a transferência. Insira a taxa e clique em OK.

Transferência de uma propriedade

Assim que a transferência for criada, Source e Target panesprecisa especificar as expressões XPath relevantes para extrair e substituir os valores de propriedade. Na caixa suspensa ao lado de Origem, vários níveis de projetos SoapUI são listados e podem ser usados como a origem de transferências de propriedade. Por padrão, o TestStep mais próximo será mostrado.

Neste caso, é o Request – INR to USDTestStep. A lista suspensa ao lado de Propriedade mostra a propriedade de origem usada na transferência, que pode ser solicitação, resposta ou ponto de extremidade de serviço.

Step 1- Selecione Resposta e vá para o idioma do caminho. O usuário pode selecionar XPath, Xquery ou Jason para definir a propriedade. Nesse caso, selecione XPath.

Step 2 - Para obter a declaração do xml de origem, clique em ns e especifique XPath.

Step 3- Especifique o destino para o qual o valor extraído da expressão XPath acima deve ser transferido. O painel de destino é usado na parte inferior da janela de transferência de propriedade para isso.

Step 4 - Transferir o valor extraído de ConversionRateResult da resposta da etapa RequestINRtoUSD.

Target - Propriedades

Property - ConversionRate (uma nova propriedade adicionada, ela não tem nenhum valor inicialmente).

Step 5 - Depois que o caso de teste é executado com sucesso, a propriedade “ConversionRate” é atualizada com base na resposta.

A seguir está a imagem inicial.

A seguir está a captura de tela após uma execução bem-sucedida.

Da mesma forma, Target pode ser um próximo Request XML. Se o destino for uma solicitação SOAP, precisamos fornecer XPath para identificar o atributo de destino.

O painel Logs armazena as informações completas sobre a transação entre o cliente e o servidor. Os usuários poderão ver as várias guias do painel de registro. Discutiremos os painéis de log mais comumente usados enquanto trabalhamos com SoapUI neste capítulo.

Log SoapUI

O log SoapUI exibe as informações de resposta do servidor da web. As mesmas informações são armazenadas no arquivo soapui.log da pasta SOAP-UI instalada no diretório 'bin'.

Log HTTP

O log HTTP exibe todas as transferências de pacotes HTTP. Todas as informações em 'RAW' são mostradas no log HTTP.

Log de Erros

O log de erros exibe todos os erros encontrados durante toda a sessão do projeto. As mesmas informações estão disponíveis em 'soapui-errors.log' presente no diretório 'bin' do local de instalação do SoapUI.

Registro de memória

Esta guia monitora o consumo de memória e o exibe na forma de gráfico, conforme mostrado na captura de tela a seguir. É realmente útil quando uma operação com uso intenso de memória é executada.

A afirmação pode ser interpretada como um ponto de verificação ou um ponto de validação. Assim que uma solicitação é enviada a um servidor da web, uma resposta é recebida. É necessário validar a resposta que contém os dados esperados ou não. Para validar a resposta, o SoapUI possui um recurso de asserções.

Pontos a serem observados

Assertions são usados para validar a mensagem recebida por um TestStep durante a execução.
Ele compara a parte da mensagem ou a mensagem inteira com algum valor esperado.
Qualquer número de asserções pode ser adicionado a um TestStep, cada um validando algum aspecto e conteúdo diferente da mensagem de resposta.
Depois que um TestStep é executado, todas as suas asserções são aplicadas à resposta recebida e, se alguma delas falhar, o TestStep é marcado como falhado na visualização TestCase.
A entrada com falha é exibida no log de execução do teste.

Tipo de afirmações

SoapUI oferece suporte a uma ampla gama de afirmações em resposta.

A seguir está a lista de afirmações suportadas pelo SoapUI.

Afirmação	Descrição
Property Content
Contém	Verifica a existência da string especificada. Ele também suporta expressão regular.
Não contém	Verifica a inexistência da string especificada. Ele também suporta expressão regular.
XPath Match	Usa a expressão XPath para selecionar o nó de destino e seus valores. Compara o resultado de uma expressão XPath com um valor esperado.
XQuery Match	Usa uma expressão Xquery para selecionar o conteúdo da propriedade de destino. Compara o resultado de uma expressão XQuery com um valor esperado.
Compliance, Status, Standards
HTTP DOwnload todos os recursos	Baixa todos os recursos referidos como um documento HTML (imagens, scripts, etc.) e valida se todos eles estão disponíveis. Aplicável a qualquer propriedade que contenha HTML.
Códigos de status HTTP inválidos	Verifica se o TestStep de destino recebeu um resultado HTTP com um código de status que não está na lista de códigos definidos. Aplicável a qualquer TestStep que receba mensagens HTTP.
Não é falha SOAP	Valida se a última mensagem recebida não é uma falha SOAP. Aplicável a SOAP TestSteps.
Conformidade de Esquema	Valida se a última mensagem recebida é compatível com a definição de esquema WSDL ou WADL associada. Aplicável às etapas de teste SOAP e REST. O URL de definição de esquema oferece suporte a Expansões de propriedade (por exemplo, $ {# System # my.wsdl.endpoint} / services / PortType? Wsdl).
Falha SOAP	Valida se a última mensagem recebida é uma falha SOAP. Aplicável a SOAP TestSteps SOAP Request - valida se a última solicitação recebida é uma solicitação SOAP válida. Aplicável apenas às etapas de teste MockResponse.
Resposta SOAP	Valida se a última resposta recebida é uma Resposta SOAP válida. Aplicável apenas às etapas SOAP TestRequest.
Códigos de status HTTP válidos	Verifica se o TestStep de destino recebeu um resultado HTTP com um código de status na lista de códigos definidos. Aplicável a qualquer TestStep que receba mensagens HTTP.
Solicitação de endereçamento WS	Valida se a última solicitação recebida contém cabeçalhos WS-Addressing válidos. Aplicável apenas a MockResponse TestSteps.
Resposta WS-Addressing	Valida se a última resposta recebida contém cabeçalhos WS-Addressing válidos. Aplicável apenas às etapas SOAP TestRequest.
Status de segurança WS	Valida se a última mensagem recebida continha cabeçalhos WS-Security válidos. Aplicável às etapas de teste SOAP.
Script
Asserção de Script	Permite que os usuários executem um script personalizado para realizar validações definidas pelo usuário. Aplicável apenas a TestSteps (ou seja, não a propriedades)
SLA
SLA de resposta	Valida se o tempo de resposta da última resposta recebida estava dentro do limite definido. Aplicável a Script TestSteps e TestSteps que enviam solicitações e recebem respostas.
JMS
Status JMS	Valida se a solicitação JMS do TestStep de destino foi executada com sucesso. Aplicável ao Request TestSteps com um terminal JMS.
Tempo Limite JMS	Valida se a instrução JMS do TestStep de destino não demorou mais do que a duração especificada. Aplicável ao Request TestSteps com um terminal JMS.
Security
Exposição de informações confidenciais	Verifica se a mensagem de resposta não expõe informações confidenciais sobre o sistema de destino. Podemos usar esta asserção para REST, SOAP e HTTP TestSteps.
JDBC
Status JDBC	Valida se a solicitação JDBC do TestStep de destino foi executada com êxito. Aplicável apenas a JDBC TestSteps.
Tempo Limite JDBC	Valida se a instrução JDBC do TestStep de destino não demorou mais do que a duração especificada. Aplicável apenas a JDBC TestSteps.

No SoapUI, os usuários enfrentam muitos problemas comuns genéricos que podem ser resolvidos com um pouco de atenção. Alguns desses problemas mais comuns são os seguintes -

Issue- O namespace está definido incorretamente. Use o namespace correto. O namespace deve ser a URL onde o serviço da web está localizado.

Solution - Se um erro for lançado durante o desenvolvimento de uma declaração de script, use 'log.info' para imprimir o conteúdo das variáveis.

Issue - Se um código de falha for recebido como XML de resposta, pode ser devido à entrada inválida.

Solution - Verifique a entrada do XML de solicitação.

Example - No conversor de moeda, se a entrada de 'FromCurrency' for '123' que não existe, a saída lança um código de falha como 'SOAP-Client', o que significa que o problema é com o parâmetro que está sendo passado do lado do cliente.

Solicitação

Resposta

Issue - Nenhuma correspondência na resposta atual ao usar XPath ou XQuery.

Solution -

Use a sintaxe correta ao definir XPath ou XQuery.
Verifique se dois pontos são usados e não um ponto ao declarar o namespace.
Certifique-se de que XPath e XQuery estejam corretos.

O teste de desempenho é um dos pontos de verificação importantes mais comuns no teste de Web Service. Teste de desempenho é definido como criar ou simular artificialmente a carga e medir como o ambiente a trata.

Isso significa que não é necessário que seja como o sistema funciona sob carga alta, mas também como funciona sob carga básica ou carga esperada. Ele nem mesmo precisa ser estruturado, automatizado ou criado em TestWare como SoapUI; simplesmente atualizar o navegador da web continuamente e muito rápido também é um teste de carga.

Tipos de teste de desempenho

A seguir estão os tipos de teste de desempenho -

Baseline Testing - Examina o desempenho de um sistema sob carga normal ou esperada e cria uma linha de base com a qual os outros tipos de testes podem ser comparados.
Load Testing- Inclui aumentar a carga e ver como o sistema se comporta sob carga maior. Durante os testes de carga, o usuário pode monitorar os tempos de resposta, rendimento, condição do servidor e muito mais. O objetivo do Teste de Carga não é quebrar o ambiente de destino.
Soak Testing - O objetivo do teste é garantir que nenhum comportamento indesejado apareça por um longo período de tempo.
Scalability Testing- O Teste de Escalabilidade é muito parecido com o Teste de Carga, porém ao invés de aumentar o número de solicitações, ele aumenta o tamanho ou a complexidade das solicitações enviadas. Por exemplo, enviar solicitações grandes, anexos grandes ou solicitações profundamente aninhadas.

Aspectos chave no serviço da Web

Dois aspectos se destacam nas características únicas de desempenho do Web Service.

Primeiro Aspecto

No lado do servidor, o processamento XML / JSON está em andamento, tanto a análise XML / JSON quanto a serialização . O que geralmente falha primeiro é o processamento das cargas úteis. As razões do fracasso podem ser múltiplas; pode estar na plataforma, nos pontos fracos do servidor de aplicativos ou pode ser um problema de implementação na forma de WSDLs desnecessariamente complexos. Também pode significar que o código está fazendo uma solicitação a um banco de dados que está demorando para responder.

Testing Aspect- A complexidade de analisar a carga útil XML / JSON significa que é necessário colocar um foco extra no teste de escalabilidade. Isso também significa que os WSDLs devem ser examinados de perto. Se as solicitações e respostas forem complexas ou maiores, ou se incluírem anexos grandes, o foco deve ser enfatizar a complexidade e ver como ela se comporta sob carga.

Segundo Aspecto

Outro fator freqüentemente encontrado é a segurança. Os sites seguros por trás de HTTPS têm desempenho consideravelmente inferior e nos testes de Web Service podemos adicionar uma camada de WSSecurity à camada de segurança HTTP, diminuindo ainda mais o desempenho.

Testing Aspect- A questão dos meios de segurança, há uma necessidade de focar na realização de testes de solicitações que são seguras. Se todo o serviço da Web for seguro, significa que o teste de carga é mais importante, especialmente se WS-Security e manipulação de token são usados.

Load testingé uma forma específica de teste de desempenho que é conduzido para avaliar o comportamento do sistema sob uma carga específica. No SoapUI, geralmente usamos o termo "teste de carga" para todos os tipos de teste não funcional; no entanto, o SoapUI oferece suporte a todos os tipos de avaliações de desempenho de serviços da web, como carga, estresse e resistência.

Pontos a serem observados

O teste de carga é único no SoapUI; um caso de teste funcional que permite criar e modificar testes de desempenho rapidamente.
O principal diferencial é que os testes de desempenho no SoapUI geralmente são criados a partir dos testes funcionais existentes. Isso permite criar rapidamente testes de desempenho avançados.
O desempenho do serviço da Web pode ser validado em diferentes cenários de carga. Mantenha validações funcionais para ver se elas não quebram sob carga, execute vários testes de carga simultaneamente para ver como eles afetam uns aos outros e muito mais.

Criação de Teste de Carga

Step 1 - Clique com o botão direito em Caso de teste funcional e selecione Novo teste de carga.

Step 2 - Insira o nome do Teste de carga e clique em OK no assistente de diálogo.

O teste de carga será aberto e o teste de carga será criado conforme mostrado na captura de tela a seguir.

Execução de Teste de Carga

Quando um novo teste de carga é criado, ele é pré-configurado para ser executado por 60 segundos (canto superior direito) com 5 threads usando a estratégia de carregamento simples.

Modifique esses valores conforme o requisito e execute. Note - O usuário deve estar ciente da configuração e dos conceitos do Teste de Carga.

O usuário verá a tabela de estatísticas no meio, começando com a coleta de dados e após 60 segundos deve ter um LoadTest concluído.

Adicionando uma Asserção

Step 1 - No editor LoadTest, selecione a guia LoadTest Assertion na parte inferior do editor.

Step 2 - Clique no botão Adicionar asserção na barra de menus do LoadTest Assertion para adicionar uma asserção.

Step 3- A caixa de diálogo Adicionar asserção será aberta. Selecione Etapa máxima. Selecionar Máximo define um Tempo Máximo em milissegundos que as respostas podem levar; se o tempo exceder o que definimos, o teste falhará. Clique OK.

Step 4- A janela TestStep Max Assertion será aberta. Conforme visto na imagem a seguir, permitimos uma resposta máxima de um segundo, 1000 milissegundos. Não vamos modificar nada. Clique OK.

A asserção Step Maximum será agora adicionada com sucesso.

Step 5- Agora execute o teste novamente. Se as respostas demorarem muito, você verá que os números na coluna de erro se somam rapidamente.

Um serviço da web é uma coleção de protocolos e padrões abertos usados para trocar dados entre aplicativos ou sistemas. Os aplicativos de software escritos em várias linguagens de programação e executados em várias plataformas podem usar serviços da web para trocar dados em redes de computadores, como a Internet, de maneira semelhante à comunicação entre processos em um único computador. Essa interoperabilidade (por exemplo, entre aplicativos Java e Python ou Windows e Linux) se deve ao uso de padrões abertos.

Os serviços da Web baseados na Arquitetura REST são conhecidos como Serviços da Web RESTful. Esses serviços da web usam métodos HTTP para implementar o conceito de arquitetura REST. Um serviço da web RESTful geralmente define um URI (Uniform Resource Identifier), que é um serviço que fornece representação de recursos, como JSON e um conjunto de métodos HTTP.

Todos os recursos de teste REST do SoapUI são baseados em uma representação lógica conhecida como serviço REST. Não devemos confundir isso com o termo "serviço" aqui, uma vez que não é uma implementação de serviço, mas um mapeamento do serviço RESTful que está sendo chamado. Podemos adicionar tantos serviços REST quanto pudermos em um projeto SoapUI. Cada um representa um serviço RESTful específico. Eles são os seguintes -

REST - Configuração do Projeto
REST - WADL
REST - Pedido
REST - Resposta
REST - Métodos HTTP

SoapUI permite gerenciar a operação do banco de dados usando um TestStep chamado JDBC Request.

Step 1 - Clique com o botão direito em TestStep e selecione Adicionar etapa → Solicitação JDBC.

Step 2 - Insira o nome da etapa e clique em OK.

Etapa JDBC adicionada. Clique duas vezes na etapa e o assistente JDBC será aberto.

Para criar uma conexão JDBC, o usuário precisa fornecer um driver e uma string de conexão válidos. Esses parâmetros são usados para identificar o tipo de banco de dados e criar uma conexão para usar o banco de dados.

Para MySQL, o driver de banco de dados pode ser com.mysql.jdbc.Driver. Da mesma forma, para outro banco de dados, há um driver predefinido que pode ser encontrado na seção de documentos do banco de dados.

Step 3 - String de conexão deve estar no seguinte formato -

Jdbc:mysql://[host]:[port]/[database]?[property][=value]

Aqui, a propriedade é o nome de usuário e a senha junto com outros parâmetros necessários para conectar-se a um banco de dados.

Por exemplo,

jdbc:mysql://localhost:8089/xxx_DB?user=root&password=root

Step 4- Clique em Testar conexão. Na conexão bem-sucedida, ele exibirá SUCCESS, caso contrário, fornecerá os detalhes da falha.

O JDBC possui sua própria seção Adicionar propriedade que pode ser usada como uma variável no SQL Query.

Vamos ver como se comporta -

Suponha que a Consulta SQL que precisa ser executada na etapa JDBC seja Select * from Currency onde CurrencyCode = 'xxx'.

Nesse cenário, CurrencyCode pode ser alterado com base na entrada da solicitação. Se o usuário fornecer um valor embutido em código, a etapa JDBC não será executada para a moeda fornecida na solicitação.

Para superar tais cenários, o JDBC suporta a propriedade add, onde um código de propriedade pode ser definido e continuará mudando usando a Etapa de transferência de propriedade.

O SQL Query será executado com base no valor atual do Código da Propriedade e o SQL Query irá parametrizar o CurrencyCode =: Code.

Clique em Adicionar Propriedade + e no nome como Código e forneça o valor ou mantenha em branco para usar a etapa de Transferência de Propriedade para fornecê-lo.

A solicitação JDBC também pode usar a maioria das asserções com TestSteps de solicitação SOAP. Em SoapUI, a maioria dessas afirmações são independentes de TestSteps. Portanto, as asserções como Contains e XPath Match podem ser usadas com JDBC Request TestStep.

Ao clicar no Add an assertion ícone no menu superior do JDBC Request TestStep, o usuário pode descobrir quais asserções são suportadas pelo TestStep.

Além das asserções genéricas, existem duas asserções específicas do JDBC Request TestStep -

JDBC Timeout - Esta asserção pode ser usada para verificar se a consulta SQL atual é executada dentro do valor da propriedade Query Timeout especificado.

JDBC Status - Para verificar se a instrução SQL foi executada com sucesso, podemos usar a asserção de status JDBC.

Para definir o Tempo limite da consulta, forneça o valor respectivo do Tempo limite da consulta da propriedade no lado esquerdo da tela. Lembre-se de que ele aceita valores em milissegundos (ms).