Diretrizes de Teste de Serviço

Para poder testar um serviço, você deve configurar seu ambiente de teste e incorporar essas diretrizes para produzir testes confiáveis.

Pré-requisitos do Teste

Antes de criar testes de serviço, pode ser necessário desempenhar algumas tarefas iniciais. Essas tarefas dependem dos protocolos de transporte e de segurança implementados pelo serviço da web em teste.
  • HTTP: Esse método de transporte é suportado por padrão; não é necessária configuração adicional.
  • SSL: A área de trabalho deve conter os arquivos keystore do certificado (JKS) que são necessários para autenticação única ou dupla.
  • JMS (Java™ Message Service): A sintaxe WSDL (Web Services Description Language) deve ser compatível com os requisitos do produto. Consulte o Verificando a Conformidade da Sintaxe do WSDL para Serviços do JMS.

Geração de Teste

Quando o teste é gerado, são criados envelopes de chamadas de mensagens de acordo com o XSD (XML Schema Definition). Durante este processo, campos obrigatórios são criados e opções padrão são assumidas. Você pode modificar esses elementos no editor de teste.
Nota: Durante a gravação, você pode fornecer detalhes de autenticação que não são relevantes para o aplicativo real em teste. Para excluir tais ações do teste gerado, em Janela > Preferências > Teste > Editor de teste > Teste de serviço, assegure-se de que a caixa de seleção Exibir a coluna 'Ignorar se vazio' no visualizador de árvore XML esteja marcada. Para selecionar os elementos XML vazios que você deseja ignorar, no editor de teste, selecione os elementos na coluna Ignorar se vazio.

Criptografia e Segurança

O JRE (Java Runtime Environment) que o ambiente de trabalho utiliza deve suportar o nível de criptografia necessário para o certificado digital que você selecionar. Por exemplo, você não pode utilizar um certificado digital que requer criptografia de 256 bits com um JRE que suporta apenas criptografia de 128 bits. Por padrão, o ambiente de trabalho é configurado com cifras restritas ou de força limitada. Para utilizar algoritmos de criptografia com menos restrição, você deve fazer o download e aplicar os arquivos de políticas de jurisdição ilimitada (local_policy.jar e US_export_policy.jar).

É possível fazer download dos arquivos de políticas de jurisdição ilimitada deste site: http://www.ibm.com/developerworks/java/jdk/security/50/

Clique em Arquivos de Políticas do SDK IBM e, em seguida, efetue login no developerWorks para obter os arquivos de políticas de jurisdição ilimitada. Antes de instalar esses arquivos de políticas, faça o backup dos arquivos de políticas existentes caso deseje restaurar os arquivos originais futuramente. Em seguida, sobrescreva os arquivos no diretório /jre/lib/security/ pelos arquivos de políticas de jurisdição ilimitada.

Autenticação SSL

Os testes de serviços suportam mecanismos de autenticação SSL simples ou dupla:
  • Autenticação simples (autenticação do servidor): Nesse caso, o cliente de teste precisa determinar se o serviço pode ser confiado. Não é necessário configurar um keystore. Se você selecionar a opção Sempre confiar, não é necessário fornecer um keystore de certificado do servidor.

    Se você realmente desejar autenticar o serviço, poderá configurar um armazenamento confiável de certificado, que contém os certificados de serviços confiados. Nesse caso, o teste esperará receber um certificado válido.

  • Autenticação dupla (autenticação do cliente e do servidor): Nesse caso, o serviço precisa autenticar o cliente de teste de acordo com sua autoridade-raiz. É necessário fornecer o keystore de certificado do cliente que precisa se criado para autenticar o teste como um cliente de certificado.

Ao gravar um teste de serviço através de um proxy, o proxy de gravação situa-se entre o serviço e o cliente. Nesse caso, é necessário definir as configurações do SSL do proxy de gravação para autenticar a si mesmo como o serviço real para o cliente (para autenticação simples) e como o cliente para o serviço (para autenticação dupla). Isso significa que é necessário fornecer o proxy de gravação com os certificados adequados.

Ao usar os stubs de serviço, também é possível definir as configurações SSL do serviço de stub para autenticar a si mesmo como o servidor real. Isso significa que é necessário fornecer o stub de serviço com o certificado adequado.

Autenticação NTLM e Kerberos

O produto suporta autenticação Microsoft NT LAN Manager (NTLMv1 e NTLMv2) e Kerberos. As informações sobre autenticação são registradas como parte do teste durante a fase de gravação.

Para ativar suporte NTLMv2, você deve incluir uma biblioteca de terceiros no ambiente de trabalho. Para obter mais informações, consulte Configurando o Ambiente de Trabalho para a Autenticação do NTLMv2.

Certificados digitais

Você pode testar serviços com certificados digitais para protocolo de segurança SSL e SOAP. Os certificados digitais devem estar contidos em recursos de armazenamento de chaves JKS (Java Key Store) acessíveis na área de trabalho. Ao tratar de arquivos de armazenamento de chaves, você deve configurar a senha necessária para acessar as chaves tanto no editor de segurança quanto no editor de teste. Para a segurança SOAP, talvez seja necessário fornecer um nome explícito para a chave e fornecer uma senha para acessar as chaves privadas no armazenamento de chaves.

Limitações

A matrizes não são suportadas.

Em razão de falta de especificação, os anexos não são suportados com o transporte JMS (Java Message Service). O envelope é enviado diretamente utilizando-se a codificação UTF-8.

Todos os algoritmos de segurança nem sempre estão disponíveis para cada implementação Java Runtime Environment (JRE). Se uma implementação de segurança específica não estiver disponível, inclua as bibliotecas necessárias no caminho de classe do JRE utilizado por este produto.

O testador de serviço genérico exibe o envelope conforme refletido no documento XML. No entanto, os algoritmos de segurança consideram o envelope como binário. Portanto, é necessário definir a configuração de segurança do SOAP para que as mensagens de entrada e saída sejam criptografadas corretamente, mas permaneçam decriptografadas no teste.

Desempenho

O desempenho do usuário virtual depende da implementação do aplicativo do contêiner. Para um transporte HTTP, o produto foi testado com um número máximo de 900 usuários virtuais simultâneos no Windows e 600 no Linux. No JMS, um número máximo de 100 usuários virtuais simultâneos, embora esse número possa variar em razão da implementação assíncrona do JMS. Além desses valores, poderão ocorrer erros de conexão e a taxa de transação diminuirá.


Feedback